[cap-talk] Confessions of a C programmer
Stiegler, Marc D
marc.d.stiegler at hp.com
Mon Sep 21 20:19:06 PDT 2009
For Bill, who only learns a new language once every 20 years or so, he should make the leap to Ocaml/F# direct. If he learns C# instead, he'll have to wait another 20 years before he can learn a language that doesn't require all those endless type declarations :-)
--marcs
> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Ben
> Kloosterman
> Sent: Monday, September 21, 2009 4:55 PM
> To: 'General discussions concerning capability systems.'
> Subject: Re: [cap-talk] Confessions of a C programmer
>
> Ocaml/F# looks very interesting from the point of view of
>
> - Easy Multi threaded /Asych code
> - Quick development ( ie Research) / Python/Perl Script replacement
> - Functional with C like performance
> - VS2010 which you can download as a trial ( 3Gb) includes F#
> as a full member ( which is important for productivity as you
> et full intelisence)
>
> Not convinced whether it will be great in the OO large scale
> development world as C# and Java have a lot of momentum. That
> said WCF ( SOA) and WPF (Xaml UI) would match very well with
> a functional language.
>
> Going functional is a big leap though in the way you think.
> You may be better of going C# and .NET ( to learn the libs
> and some functional code) and then moving to F# if its an
> important project if you have a few small/play project maybe
> consider a straight jump.
>
> I should note with the .NET libs you are dependent on a few
> things in the runtime ( CLR/Mono) to make some sys calls (
> mainly malloc ) in the Managed OS we don't need this as we
> change the compiler to output x86 and call an OS function
> directly for allocation.
>
> Note Mono ( the Open source .NET libs) are changing all
> their external calls to partial classes that way you can
> change the external call to suit the OS without affecting the
> rest of the framework. Mono runs on x86 and Arm but not much
> else I think.
>
> Regards,
>
> Ben
>
> >-----Original Message-----
> >From: cap-talk-bounces at mail.eros-os.org [mailto:cap-talk-
> >bounces at mail.eros-os.org] On Behalf Of Stiegler, Marc D
> >Sent: Tuesday, September 22, 2009 12:34 AM
> >To: General discussions concerning capability systems.
> >Subject: Re: [cap-talk] Confessions of a C programmer
> >
> >Markm's recommendation of Emily, and Ben's recommendation of
> C#/DotNet,
> >suggest that Ocaml is the place to start -- learn Ocaml, and you are
> >already writing Emily (if you want to go to ocap guarantees) and F#
> >(which has a subset so similar to Ocaml that it compiles
> Ocaml, with a
> >couple of caveats).
> >
> >Learning Ocaml from the standard texts on the web will be painful. I
> >did actually write a draft of Emily in a Walnut that I could
> dig up for
> >you if you are serious. The difference is, traditional texts
> focus on
> >functional programming and mention imperative programming in
> passing.
> >I, on the other hand, focus on imperative, c-style programming, and
> >mention functional programming in passing :-) And I can give you a
> >short course on it at a Friday meeting :-)
> >
> >Ocaml is already used for soft-real-time device drivers
> despite having
> >automatic garbage collection -- the collector is really fast
> and pause-
> >resistant. It was even used to write an operating system, as
> a graduate
> >student exercise. As markm mentioned, it compiles to C and
> launches as
> >fast as C. However, there is no way with ocaml to launch
> true threads,
> >which you might care about. For concurrent Ocaml, I built a promise
> >pipelining library that used linux processes, pretty
> heavyweight. There
> >is a variant, jocaml, about which I know nothing but it's
> designed for
> >concurrency, one way or another. F# has other alternatives for
> >multithreading. The benchmark for F# I saw was so good that I'm
> >suspicious it was incorrect. F# has a properly tricked out
> IDE, there
> >are plugins with both Mono on Linux and with Visual Studio.
> >
> >Ocaml's type checking is powerful enough so that null pointer
> >exceptions are literally impossible, unless it bubbles up from a
> >library package written in C. F# allows you to write
> programs that can
> >only get null pointer exceptions from dotnet and c libraries, but to
> >work smoothly with dotnet, reintroduced the ability for the
> programmer
> >to create his own null pointer exceptions if he wants to ("you can
> >write FORTRAN in any language" :-)
> >
> >--marcs
> >
> >> -----Original Message-----
> >> From: cap-talk-bounces at mail.eros-os.org
> >> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Mark Miller
> >> Sent: Monday, September 21, 2009 2:24 AM
> >> To: General discussions concerning capability systems.
> >> Subject: Re: [cap-talk] Confessions of a C programmer
> >>
> >> On Sun, Sep 20, 2009 at 11:51 PM, Bill Frantz
> <frantz at pwpconsult.com>
> >> wrote:
> >> > We all know a long list of reasons why writing in memory-safe
> >> > languages produces safer, more reliable code than writing in
> >> > memory-unsafe languages such as C. So why do I, and others,
> >> continue to write in C?
> >> >
> >> > My last major project was the web-key server for CapROS.
> Like most
> >> > real-world programming, it faced a deadline. What I
> needed from a
> >> > language
> >> > was:
> >>
> >> I suggest Emily on OCaml.
> >>
> >>
> >> > Familarity - I learn languages slowly, and time spent
> >> learning a new
> >> > one
> >> > needs to be justified.
> >>
> >> -1. But you may find OCaml either excessively easy or hard
> to learn,
> >> depending on how your brain is wired. It might help if you
> could get
> >> a certain someone developer to write Emily in a Walnut ;).
> >>
> >>
> >> > Reliability - I don't want to spend time debugging the
> >> compiler and I
> >> > really don't want to debug a code generator which changes the
> >> > semantics
> >> > of my program.
> >>
> >> +1.
> >>
> >> > Minimal environment - The compiler and runtime should
> not depend
> >> > on
> >> > anything but the non-privileged architecture of the
> >> hardware platform.
> >> > All privileged instructions/system calls should come
> from library
> >> > routines[1].
> >>
> >> +1.
> >>
> >> > Library routines for required subsystems - I needed a SSL/TLS
> >> > implementation and ended up using OpenSSL, which is
> written in C.
> >> > Being
> >> > able to call C programs would cover a lot of this requirement.
> >>
> >> +1?
> >>
> >> > Support for the target platform(s).
> >>
> >> IIUC, OCaml is implemented by portable compilation to C, and so
> >> should be supportable everywhere C is supported.
> >>
> >>
> >> > The question is, what memory-safe languages even begin to
> >> meet these
> >> > requirements? BitC, which is designed for formal
> verification and
> >> > low-level system implementation might be a possibility.
> >>
> >> Now that both Shap and Swaroop are at Microsoft, what is BitC's
> >> status? I would guess that it is abandoned. Has someone
> else picked
> >> it up?
> >>
> >> > Are there any others? It
> >> > would be worth some effort to learn at least one of
> these languages
> >> > and help it grow up to have the reliability needed for
> >> deadline-driven work.
> >> >
> >> > Cheers - Bill
> >> >
> >> > [1] While GCC only generates user-mode instructions, the
> >> documentation
> >> > does not state which library calls generate system calls.
> >> This issue
> >> > was particularly difficult with OpenSSL, where I had to
> stub out a
> >> > number of library routines which issue system calls. To
> >> make it even
> >> > more interesting, these routines had slightly different
> >> names on the
> >> > two platforms (arm and x86).
> >>
> >> I would guess OCaml inherits this problem from C.
> >>
> >>
> >> >
> >>
> ---------------------------------------------------------------------
> >> -
> >> > --- Bill Frantz | The first thing you need when |
> >> > Periwinkle
> >> > (408)356-8506 | using a perimeter defense is a | 16345
> >> Englewood
> >> > Ave www.pwpconsult.com | perimeter. |
> >> Los Gatos,
> >> > CA 95032 _______________________________________________
> >> > cap-talk mailing list
> >> > cap-talk at mail.eros-os.org
> >> > http://www.eros-os.org/mailman/listinfo/cap-talk
> >> >
> >>
> >>
> >>
> >> --
> >> Text by me above is hereby placed in the public domain
> >>
> >> Cheers,
> >> --MarkM
> >> _______________________________________________
> >> cap-talk mailing list
> >> cap-talk at mail.eros-os.org
> >> http://www.eros-os.org/mailman/listinfo/cap-talk
> >>
> >_______________________________________________
> >cap-talk mailing list
> >cap-talk at mail.eros-os.org
> >http://www.eros-os.org/mailman/listinfo/cap-talk
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
More information about the cap-talk
mailing list