[cap-talk] Confessions of a C programmer

Mon Sep 21 16:54:32 PDT 2009

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