Slashdot Mirror
OCaml For the Masses
CowboyRobot writes "Yaron Minsky of Jane Street argues that the time has come for statically-typed functional languages like OCaml and Haskell. He cites many reasons and illustrates what he says is the most important, concision: 'The importance of concision is clear: other things being equal, shorter code is easier to read, easier to write, and easier to maintain.'"
haskell for "the masses" is possible as soon as "the masses" has a degree in mathematics. java and php are copy-and-paste languages, functional languages simply take more thinking to compile at all, and i think many programmers are not prepared to do that to the required degree, although i'd love to be proved wrong.
All other things are not equal though, are they? Procedural programming is easier for humans to understand: most of us do no not think in a way that maps easily to functional programming.
Both Ocaml and Haskell can compile directly to native machine code and aren't tied to decrepit virtual machines. In particular, Haskell's compiler is written in Haskell for optimal bootstrappy fun.
Ita erat quando hic adveni.
You mean like right now? Haskell's pretty mature, and it's been able to compile to native code for years. It's pretty straight forward to talk to C (the universal ABI) with Haskell (well, as straight forward as anything is in Haskell).
OCaml has been mature for nearly a decade, by the way. Without the success it's had, languages such as Haskell and F# wouldn't be around. It also can compile to native code, and has been able to since inception.
PS, the .NET VM isn't really decrepit, it's much more performant than the JVM is. Sadly, mono isn't nearly as mature as the actual .NET virtual machine.
They compile to native machine code, FYI.
Take a look at Scala collections.
Scala lists look and feel immutable, but under the covers they are really mutable to remain more performant.
Huh? No it isn't. The API may most often be expressed in C, but the ABI is language agnostic.
Huh? The C standard doesn't define anything in terms of "bytes", "half-words" or "double words". In fact those terms are largely meaningless in the context of C: the standard offers very few guarantees about the width and endianess of it's native types. C didn't even gain portable fixed-width types until C99.
Syllable : It's an Operating System
This is why I think Scala will succeed.
Scala has all the advantages that the article mentions AND you can integrate and reuse your old Java or .NET code and libraries.
It's there. The tooling doesn't suck half bad anymore. The world just needs to find out.
I personally think that Scala will win over the 10% best Java programmers as soon as the tooling is comparable to Javas.
And that might happen within the next 1-2 years.
'The importance of concision is clear: other things being equal, shorter code is easier to read, easier to write, and easier to maintain.'
But there's the rub. Other things are not equal. Functional languages require the developer to approach problems with an entirely different mindset. There is a steep learning curve to really understand how they work. And I'm not talking about just the syntax. Functional languages are fundamentally different than procedural languages. Truly understanding how they work requires a lot more brainpower than procedural languages.
While it's admirable to espouse what you see to be a more elegant and "better" solution, you need to be pragmatic. Getting the millions of software developers in the world to put the effort to completely change their way of thinking just isn't going to happen. The cost/benefit ratio is questionable at best, given that a lot of people could train for a long time and still have difficulty with the basic concepts of functional languages.
Procedural languages are the norm because they're a lot simpler. Procedural languages (including "C with classes" and the like that masquerade for OOP/OOD) are useful to many more people simply because there is less to understand about how they work. It's easier for people to approach problem solution in a procedural way than it is for them to think about it functionally. And that's why functional languages, no matter how elegant or "great" they may be, will never really break into the mainstream.
I have the perfect hammer.
Would that be the C family of languages used all over the place?
My favorite code to read is OOP stuff written by coders who understand and make use of functional programming concepts. They know how to write things that are stateless when that makes sense, and use state in an appropriate manner when that makes sense.
And yes, by all means use it when appropriate. But don't think that Lisp is always the right language for scripting your text editor (dodges blow from Emacs partisan).
I am officially gone from
Glascow Haskell Compiler:
GHC compiles Haskell code either directly to native code or using LLVM as a back-end. GHC can also generate C code as an intermediate target for porting to new platforms. The interactive environment compiles Haskell to bytecode, and supports execution of mixed bytecode/compiled programs.
If shorter, more concise code was always better, we'd have switched to APL years ago.
We didn't.
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
APL is very concise and is famously easy to read and maintain. Oh, wait...
Quidnam Latine loqui modo coepi?
True, so on one end you have bloated, verbose languages like Java and Cobol and on the other end you have terse, unreadable languages like Perl and APL. So the key is finding the right balance. Ideally you want a language which is both readable and expressible. One that encourages reduction of repetitious code. One that allows you to build the abstractions to best express your intent as a programmer in a maintainable way.
I'm of the opinion that C syntax is not best suited for this. Lisp is better, but everyone screams about the parens despite the fact that you have curly braces, parens, square braces and semicolons all over the place in the C languages.
F# is essentially OCaml for .Net, so you get the full access to the .Net library. Also the best thing about F#, in my opinion, is since it is a .Net language, you can mix and match it with C#. So you can use functional approach for most part of your program, yet drop to C# when you require.
We have found the problem with the software business.
Bad news: It's you and your 100,000,000 ignorant & unwilling to learn clones.
you had me at #!
Are there any studies to back up the "smaller code is better" thesis? My own experience and that of many others leads us to diasgree; but our anecdote and/or sentiment is no better than theirs.
1. Quantify terseness.
2. Assign terseness value to language.
3. Quantify qualities of interest (maintainability, etc.).
4. ???
5. Science!
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Functional languages are good for inplementing algorithms and imperative languages are good for handling data. It happens that in most real-life situations we need the latter.
First ghost!