Slashdot Mirror

Request granted (at least for calling C). SML has an even nicer FFI and most certainly builds native executables.

Adhering to the platform ABI makes little sense -- the "platform" ABI on e.g. UNIX is meant for C programs and is not expressive enough for other languages (keep in mind the only types in C are bytes, half-words, words, double words, ...).

For one thing, ML-oid languages have Hindley-Milner type inference.

This is a formal ("mathematical") guarantee at code safety/correctness (in the web scenario it means code injection attacks do not type-check). All C-oid languages (and Java, Python, etc.) cannot offer a true (i.e., *formal* guarantee), simply because, compared to the theoretical background of ML-oid languages, they are merelly hacks, with lots of corner cases, ad-hoc "featuritis" and many loopholes - which, BTW, spawned a whole industry (anti-virus software). Talk about giving you a problem and then selling the solution...

Even though ML-oid languages were developed by true brainiacs, we're now witnessing inroads at mainstream programming (F#, for example, from Microsoft, or the use of OCaml in the financial sector (*))

Being statically-typed, these systems are also good for performance (**)

For a nice layman-friendly explanation of Hindley-Milner you may like: http://www.codecommit.com/blog/scala/what-is-hindley-milner-and-why-is-it-cool
-------
(*) Many years before these new commercial uses of ML-oid languages, the French Aerospace industry used OCaml to formally verify C programs that were deployed in at least one model of Airbus aircrafts. Also, the makers of Matlab (Mathworks) sell a code-checking tool that relies on SML (Standard ML) (see: http://www.mathworks.com/products/polyspace/index.html)
(**) This guy claims his OpenGL bindings for MLTon whole code optimizing compiler yielded faster than C++ performance at 10% of the code. MLTon may be found here: http://mlton.org/.

To ask a stupid question, have you ever tried benchmarking your code in another language, or did you just automatically assume "fast = C++" without any research at all? If the latter (which I assume is the case), then I'm going to put you in the "habit" category.

I had a guy on my team who's a genuinely great programmer do some benchmarking (to check what we already suspected), and he confirmed that Java couldn't keep pace for tight, math-intensive code like what we had to write.

We're also constrained, for practical purposes, to languages that are known to many programmers, and that can be compiled for all reasonable desktops and super-computers. Those two constraints limited the list to C/C++ and Java. (If these constraints didn't exist, I probably would have even considered MLTON. But that's just not the situation I had.)

To make a stupid observation, you left out C as a viable choice. It's a lot like C++, but with fewer ways to shoot yourself in the foot. (Also, you used to be able to natively compile Java, I'm not sure if that's still the case.)

To be honest I probably didn't give C enough consideration, because I have much more experience with C++. But it turns out that for the parts of our code that aren't tight computational kernels, C++'s templates, polymorphism, and the STL are serving us quite well. So even if I had given C more consideration, I suspect I would have chosen C++ anyway.

Don't forget Polyspace, which I personally have never used - but I would love to. Polyspace is a Standard ML (a higher-order functional programming language) success story, because it relies heavily on the SML MLton compiler. Another thing that makes it a success story is the fact the Mathworks (makers of Matlab) bought it.

The C/C++ version does MISRA-C (the C used in the automotive industry) too.

There's also a version for Ada, of course.

Both Objective Caml and SML (using, say MLton) can be compiled to ELF executables for the x86.

Anyway, native-code compilation versus bytecode compilation isn't a property of a language, it's a property of an implementation. The GNU Compiler for Java exists.

These were pretty arbitrary examples: there are plenty of options for native code executables besides C/C++.

I don't mean to slight D, though!

Regarding write-once variables: the reviewer makes it sounds as though this is some terrible burden or restriction that functional programmers must deal with. I offer the contrary point: immutable structures are an *invariant* that make programming much, much easier. Have you ever been in a situation where some other part of the code has an alias to something you're working with, and is modifying it when you don't want it to? Functional programming totally avoids that by having a language-enforced invariant of immutability.

That (along with all of the other features that functional languages typically have that languages like Java and C don't, like higher order nested lexically-scoped functions, polymorphism, algebraic data types and pattern matching, parameterized modules, tuple and sum types, etc.) is the reason to do functional programming. Of course, SML and O'Caml allow you to program imperatively too, since some activities are more naturally expressed that way.

I used to be a total C cowboy, and now I love functional programming. You can just do so much more great stuff with it.

IMO, mlton is a great compiler with which to start functional (SML) programming. The performance is incredibly good, it behaves like a real compiler from the command line, and it's free (GPL) software.

Of course, there are also hard real-time garbage collectors (ie Cheng's), though I don't think you'll find them in general-purpose production compilers. However, you will find good garbage collectors in a number of real production compilers (say, in mlton). It's definitely worth benchmarking.

I wish people didn't (for whatever reason) equate Virtual Machines with language-level safety. It's true that Java was the first mainstream OO language with C-like syntax, but is this really the only experience that anyone has with safe languages?

Let me try to set the record straight: The features of Java that make it good for writing secure code are independent from the VM. Those features are things like array bounds checking, lack of pointer arithmetic, checked casts, and garbage collection. All of these things can be, and are, done in native code. The VM is not what makes your code safe, it's what allows you to check a binary that you download to make sure it is safe. If you're compiling the code yourself, you can easily target native code and pay very little performance overhead.

For instance, mlton (mlton.org) is a high performance native code compiler for Standard ML. It doesn't use a virtual machine, but it's impossible to write code with exploitable buffer overflows, integer overflows, double-frees, etc.. (In my opinion, it's also a much cooler language than C or Java). O'caml is another good language in the same family that can target either bytecode or native code. There exist native compilers for Java, though I've never used them.

VM => portable byte code.
safe language => secure code.

Be wary of people who tell you that all we need is properly written C code. The days of grepping for "strcpy" are long gone -- the new age of exploitable holes are trickier things, usually living in hand-written parsing routines. C programmers will always have to live with buffer overflows, integer overflows, and double-frees.