Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

OCaml For the Masses

timothy posted about 3 years ago | from the cue-up-the-language-bigots dept.

Programming 338

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.'"

Sorry! There are no comments related to the filter you selected.

haskell for the masses? sure, but only... (4, Insightful)

tulcod (1056476) | about 3 years ago | (#37601688)

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.

Re:haskell for the masses? sure, but only... (1, Interesting)

gstoddart (321705) | about 3 years ago | (#37602034)

Yeah, every now and then I've known someone who firmly believed we should all be writing in Haskell and the like.

Mostly it seems like they're suggesting it because they're geeky people who like some of the features they claim the language has, and because this meets some level of mathematical elegance that resonates with them.

My recollection of functional programming from university was that it was kind cute, seemed to be geared to solving a problem domain I never found a use for, but that ultimately I hated the syntax and structure of it. I never really "got it", or really understood what it was supposed to be useful for.

Other than someone doing an Othello game in lisp, I'm not sure I've ever actually seen these languages used for anything ... at least, not outside of AI type things or university.

But, that was a long time ago. To me it's mostly theorists talking about how clean and pretty the code is, but it just doesn't seem like it's all that useful in the real world.

And, really, let's face it ... I don't recall ever seeing "wanted, one haskell programmer". So, do people actually use it for commercial software?

Re:haskell for the masses? sure, but only... (1)

makapuf (412290) | about 3 years ago | (#37602384)

Functional languages ... Err code editors perhaps (emacs) ? Games (jak & daxter) ?

Re:haskell for the masses? sure, but only... (2, Funny)

gstoddart (321705) | about 3 years ago | (#37602908)

See, as an old school user of vi, emacs doesn't make the case for a functional language being useful.

In fact, quite the opposite. :-P

Re:haskell for the masses? sure, but only... (1)

Anonymous Coward | about 3 years ago | (#37602736)

http://www.haskell.org/haskellwiki/Haskell_in_industry

Re:haskell for the masses? sure, but only... (0)

Anonymous Coward | about 3 years ago | (#37603046)

Other than someone doing an Othello game in lisp, I'm not sure I've ever actually seen these languages used for anything

erlang is used pretty heavily in the financial and telecom sectors.. (though, more for its parallelism) it's also a functional language.

Re:haskell for the masses? sure, but only... (0)

Anonymous Coward | about 3 years ago | (#37602050)

Haskell is only for professors. No one does real work in Haskell, unless it is experimental work (i.e., in an experimental research language, focused on the "theory of the perfect programming language", whatever that is... arguments mainly).

Re:haskell for the masses? sure, but only... (0)

Anonymous Coward | about 3 years ago | (#37602618)

I'm sorry to say that you're mistaken. Please read up some more on how and for what people use Haskell, before saying such things (without proof).

Re:haskell for the masses? sure, but only... (2)

rvw (755107) | about 3 years ago | (#37602862)

I'm sorry to say that you're mistaken. Please read up some more on how and for what people use Haskell, before saying such things (without proof).

If I enter "Haskell" in Monsterboard, I get zero results. You probably refer to academic work, but where in the commercial world is Haskell used?

Re:haskell for the masses? sure, but only... (2)

gilleain (1310105) | about 3 years ago | (#37602912)

I'm sorry to say that you're mistaken. Please read up some more on how and for what people use Haskell, before saying such things (without proof).

Oh please no - that proof ... it doesn't have to be written in Haskell, does it?

Re:haskell for the masses? sure, but only... (0, Informative)

Anonymous Coward | about 3 years ago | (#37602158)

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.

Functional languages are very easy to master, much much easier than Java or C++; and no you certainly don't need a degree in mathematics to understand and program in Scala or Haskell or Ocaml.
The problem is the mas of sunday day programmers out there that think that javascript or php are the end all to computer languages.

Re:haskell for the masses? sure, but only... (1)

sourcerror (1718066) | about 3 years ago | (#37602470)

I've been programming Prolog quite a lot (a bit CLP too), but still don't get monads, so I just shrug off your snobbish nonsense.

Re:haskell for the masses? sure, but only... (1, Insightful)

gilleain (1310105) | about 3 years ago | (#37603020)

I've been programming Prolog quite a lot (a bit CLP too), but still don't get monads, so I just shrug off your snobbish nonsense.

Me either; I don't even think that the higher order concept like monads or arrows are even relevant to most programming. Also, I find actual maths easier to read than Haskell or lisp - it's not just a question of not 'getting' the language; it's not very gettable.

(I hope no-one from lambda-the-ultimate comes across this comment thread or they'll be irritated.)

Re:haskell for the masses? sure, but only... (1)

bbn (172659) | about 3 years ago | (#37603066)

I get monads. But Prolog? I never learned to do more than asking what color is the ball in the third hut? Can you actually make real programs with that?

Re:haskell for the masses? sure, but only... (1)

TuringTest (533084) | about 3 years ago | (#37603196)

It took me a while to grasp why monads use is so widespread in Haskell. But that's not primarily because of their inherent complexity (one understood, they're a rather simple Abstract Data Type) but because the uncountable monad tutorials make a terrible work at explaining their context, why they're useful for, and in which cases you should use them. These tutorials usually introduce monads with super-abstract metaphors and mathematical descriptions, that aren't useful for someone with a background in programming.

The lead paragraph of the Wikipedia article for monads [wikipedia.org] tries to explain this context in terms that are familiar to a general programmer. Basically a monad is a framework to handle side-effects (or other complex control flows) in a small imperative block (the infamous do-block) inside your pure functional, side-effect-free Haskell language. Any state that you could get embedded in the semantics of an imperative language, you can model it explicitly in your library instead - the monad exposes into Haskell definitions the inner workings of the imperative engine.

Once this is understood, they're a pretty effective way to implement the problems that are simple to program in an imperative language but get complicated by a pure functional approach.

Re:haskell for the masses? sure, but only... (1)

alphabetsoup (953829) | about 3 years ago | (#37602758)

Modern imperative languages are constantly adding elements from functional languages. For example, take C++ templates - template metaprogramming is a pure functional style of programming. C++ 1x has added lambdas. Also things like STL algorithms such as accumulate and for_each or boost::bind - are essentially functional programming. C++ 1x was to have concepts which was removed but will hopefully return in the next standard. C# has added async and await. So your "masses" cannot avoid functional programming - they will be forced to learn it - since all imperative languages are going in that direction.

The advent of multicore programming will force this issue. Functional programs are much easier to execute in parallel. C++ has Microsoft PPL or Intel Threads libraries which are essentially functional algorithms. parallel_for with a lambda is one of the most useful parallel programming techniques. The equivalent imperative program will be far more verbose and cumbersome.

I actually believe C++ with the addition of Concepts and pure functions will make a very useful functional language. Yes it will be much more verbose than Haskell. Everything is. But then we will be able to use imperative style where required and functional style everywhere else. The functional parts can be easily parallelized. They can throw exceptions with impunity. Of course, there are some issues as to what constitutes "pure objects" and how to work around C++'s lack of a garbage collector. However people are already working on it. I believe Andrei Alexandrescu was working on something similar for D, which may be adopted to C++.

Needs platform adoption first. (0)

Kenja (541830) | about 3 years ago | (#37601698)

Until I can write a useful, stand alone application for a popular platform, I cant really bring myself to care about OCaml or simular languages. Without adoption by a mainstream platform they will remain in the fringe, talked about by comp-sci majors and few others.

Re:Needs platform adoption first. (0)

Anonymous Coward | about 3 years ago | (#37601890)

OCaml (From wikipedia):

The native code compiler is available for many platforms, including Unix, Microsoft Windows, and Apple Mac OS X. Excellent portability is ensured through native code generation support for major architectures: IA-32, IA-64, AMD64, HP/PA; PowerPC, SPARC, Alpha, MIPS, and StrongARM.

Re:Needs platform adoption first. (0)

Stormtrooper42 (1850242) | about 3 years ago | (#37603106)

Support? Sure.
Adoption? Not so much.

Re:Needs platform adoption first. (1)

StormShaman (603879) | about 3 years ago | (#37601950)

Pandoc is written in Haskell, but you can download a 3MB Windows installer for it.

Re:Needs platform adoption first. (3, Interesting)

Laz10 (708792) | about 3 years ago | (#37601996)

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.

Re:Needs platform adoption first. (0)

Anonymous Coward | about 3 years ago | (#37602438)

Scala has all the advantages that the article mentions

Not really. For example, Scala's local, flow-based type inference is not as powerful as the Hindley-Milner type inference found in OCaml and Haskell. And while Scala's syntax is much less cluttered with boilerplate and ceremony than is Java's, Scala's syntax is still not as clean and concise as OCaml's. In both of these instances, the weakness of Scala relative to OCaml is the result of conscious choices to allow for easy interoperation with the whole Java ecosystem -- which OCaml doesn't do. So, in the end you need to pick which features/capabilities are most important to you, because there isn't one language that is the best at everything. My choice is Scala, but the isolation of Jane Street's code and their critical need for very strong type inference and checking (especially exhaustiveness checks) means that OCaml is a better choice for them.

Use F# (2, Interesting)

alphabetsoup (953829) | about 3 years ago | (#37602298)

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.

Re:Needs platform adoption first. (1)

bondsbw (888959) | about 3 years ago | (#37602354)

F# is an OCaml variant built to run in .NET. While not 100% compatible with OCaml, many programs can be cross-compiled.

F# includes features such as units of measure (numeric parameters) and computation expressions. It has many more, those are just the ones I like most.

Re:Needs platform adoption first. (1, Interesting)

bondsbw (888959) | about 3 years ago | (#37602426)

Ah, and I forgot, F# 3 will have type providers, which gives you a hook into the compiler to provide types however you please. It is mostly used to create statically-typed elements from a dynamic resource such as a cloud database.

Good news! (2, Interesting)

toby (759) | about 3 years ago | (#37602400)

We have found the problem with the software business.

Bad news: It's you and your 100,000,000 ignorant & unwilling to learn clones.

Re:Needs platform adoption first. (0)

Anonymous Coward | about 3 years ago | (#37602436)

Until I can write a useful, stand alone application for a popular platform, I cant really bring myself to care about OCaml or simular languages. Without adoption by a mainstream platform they will remain in the fringe, talked about by comp-sci majors and few others.

F# would fit that bill as it is a mainstream platform and is an ML based functional language with good tooling support. YMMV as you may or may not want to target .Net personally. However your requirement statements prove to be met.

Re:Needs platform adoption first. (1)

Electricity Likes Me (1098643) | about 3 years ago | (#37602876)

The Unison file synchronizer is written in OCaml.

It's all about state (0)

Alomex (148003) | about 3 years ago | (#37601708)

From TFA: A complete commitment to immutability is a commitment to never building anything real.

If only all other functional languages learned this....

Re:It's all about state (0)

Anonymous Coward | about 3 years ago | (#37601772)

A complete commitment to immutability is a commitment to never building anything real.

Erlang would suggest otherwise, although it is a logic-based language.

Re:It's all about state (0)

Anonymous Coward | about 3 years ago | (#37602188)

And it's not pure functional. That's not a bad thing, but it's the truth. That's also why it's less brain bending than Haskell when you want to do something real.

Re:It's all about state (2)

Laz10 (708792) | about 3 years ago | (#37601878)

Take a look at Scala collections.

Scala lists look and feel immutable, but under the covers they are really mutable to remain more performant.

No way (1)

TuringTest (533084) | about 3 years ago | (#37603120)

Are you aware that there is a State object in the Haskell library just to represent mutable objects? There's nothing in functional languages preventing you to handle state, not even in the purest ones, at least since the application of monads to programming [wikipedia.org] .

With monads you can create sequences of pseudo-imperative actions ("do blocks") that behave like a language with mutable states, but where the only possible side-effects are the ones you have previously embedded in the monad declaration; every other side effect is logically impossible.

Basically a monad is an implementation for an imperative micro-machine that handles one particular type of state changes. What this buys you is simplifying the number of cases you have to take care of (you avoid race conditions, exceptions thrown by rare cases in the input data...)

The cost for it is that you must know what you're doing - you have to know how to create a miniature programming language, so it's not a job for the typical java copy-paste-debug programmer.

Re:No way (1)

Alomex (148003) | about 3 years ago | (#37603290)

Yup, I know about monads. A clear step forward particularly in terms of reasoning about state in an immutable language, but still a bit of a kludge.

By the way, observe that functional language != immutable language. People often confuse the two.

To prove its usefullness, (1)

Anonymous Coward | about 3 years ago | (#37601730)

A pac-man clone-game should be written in this language and it should be called, "Nom Nom Nom Chomsky"!

Re:To prove its usefullness, (0)

Anonymous Coward | about 3 years ago | (#37601872)

Challenge accepted.

They're not equal though... (5, Insightful)

Anonymous Coward | about 3 years ago | (#37601744)

The importance of concision is clear: other things being equal, shorter code is easier to read, easier to write, and easier to maintain.

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.

Re:They're not equal though... (3, Insightful)

Anonymous Coward | about 3 years ago | (#37601904)

Or most of us didn't learn to program in a functional language, so our brains are used to thinking imperatively. Or were you born understanding code?

Re:They're not equal though... (3, Insightful)

Waffle Iron (339739) | about 3 years ago | (#37602820)

Or most of us didn't learn to program in a functional language, so our brains are used to thinking imperatively. Or were you born understanding code?

Our brains think imperatively because life is imperative.

Imperative languages dominate computing because the real world is imperative.

Re:They're not equal though... (1)

TheRaven64 (641858) | about 3 years ago | (#37602882)

Understanding code, no, but understanding imperative programming? Absolutely. Children are given sequences of instructions to follow from a very early age. If you can understand a recipe, you can understand imperative programming. Functional programming requires a much more detailed understanding of mathematics.

Re:They're not equal though... (1)

Anonymous Coward | about 3 years ago | (#37602594)

Procedural programming is easier for humans to understand: most of us do no not think in a way that maps easily to functional programming.

That's just an artifact of training and experience. Referential transparency and the quarantining of shared, mutable state in functional programming means that both machine and human understanding of and reasoning about functional code is actually easier than for comparable imperative code with which most programmers are more familiar.

Re:They're not equal though... (2)

m50d (797211) | about 3 years ago | (#37602632)

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.

Quite the opposite actually, and that's the real advantage of functional programming; I don't think "do this to the first item in the list, then do it to the second, then...", I think "do this to every item in the list". Procedural was popular because it corresponded to what the computer was doing, and in the early days knowing exactly what the computer was doing was very important, but functional maps much more closely to human reasoning.

Give me a call when... (0)

Suiggy (1544213) | about 3 years ago | (#37601746)

...the compiler toolchain and libraries for Ocaml or Haskell are more mature, have support for compiling directly to native machine code and interfacing with platform specific ABIs, and aren't tied to decrepit virtual machines such as the JVM or .NET framework.

Re:Give me a call when... (2, Informative)

tuffy (10202) | about 3 years ago | (#37601792)

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.

Re:Give me a call when... (2, Informative)

Anonymous Coward | about 3 years ago | (#37601816)

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.

Re:Give me a call when... (1)

TheRaven64 (641858) | about 3 years ago | (#37602920)

LLVM supports the GHC calling conventions now, so it's also relatively easy to call into Haskell from other languages.

Re:Give me a call when... (1)

Unknown Lamer (78415) | about 3 years ago | (#37601820)

Request granted [inria.fr] (at least for calling C). SML has an even nicer FFI [mlton.org] 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, ...).

Re:Give me a call when... (0)

Anonymous Coward | about 3 years ago | (#37601884)

What types does the CPU support that the platform ABI doesn't?

Re:Give me a call when... (2)

Vanders (110092) | about 3 years ago | (#37601990)

the "platform" ABI on e.g. UNIX is meant for C programs

Huh? No it isn't. The API may most often be expressed in C, but the ABI is language agnostic.

keep in mind the only types in C are bytes, half-words, words, double words

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.

Re:Give me a call when... (1)

Unknown Lamer (78415) | about 3 years ago | (#37602766)

The ABI defines how data is represented at the machine level, how functions are called, etc. The C ABI is insufficient for representing languages like Common Lisp, OCaml, Haskell, ... for a number of reasons. One is that the calling convention is not powerful enough for them, another is that it is difficult to express types from these languages in terms of the C ABI. It could probably be done, but then you'd need a lot of run time support and it would be really difficult for a human to actually call things from C. Then you have things like the stack -- SML/NJ at least doesn't even use the C control stack (opting instead to keep a list of activation frames on the heap -- this makes call/cc O(1) instead of O(N) proportional to the length of the activation chain).

As long as they provide a main entry point does it really matter?

Re:Give me a call when... (1)

Vanders (110092) | about 3 years ago | (#37603012)

What C ABI? There is no "C" ABI: just the ABI of the platform the code is running on. The machine ABI is, by it's very nature, a very low level construct: it defines things like which CPU registers are used to pass arguments, which registers may be clobbered during a call etc. How would you propose to implement an ABI in say, Haskell, that doesn't eventually describe how the CPU registers are used, or doesn't describe how the stack is used, or any other very low level details you must cover to implement a usable ABI?

Eventually, all languages become individual CPU instructions. That's the level that the machine ABI deals with.

As long as they provide a main entry point does it really matter?

Yes, very very much. Even defining enough of an ABI to even get to the executables entry point is a pretty big task!

Re:Give me a call when... (0)

Anonymous Coward | about 3 years ago | (#37601846)

But can we write SkyNet with it?

Re:Give me a call when... (2)

Nimatek (1836530) | about 3 years ago | (#37601862)

They compile to native machine code, FYI.

Re:Give me a call when... (1)

iusty (104688) | about 3 years ago | (#37602458)

Not sure what you mean by "native code". Haskell and Ocaml can both be compiled down to native code. What exactly do you want and is lacking in these two?

Re:Give me a call when... (1)

Soluzar (1957050) | about 3 years ago | (#37602652)

That post was a statement, not a question. The subject line was inherited. You'll need to look further up the thread to find the post to which yours is admittedly a completely valid reply.

Re:Give me a call when... (1)

iusty (104688) | about 3 years ago | (#37603016)

Sorry, indeed realised after posting. I'm still surprised about the original parent's statement though (.net and JVM in relation to OCaml and Haskell??)

Re:Give me a call when... (2)

Korin43 (881732) | about 3 years ago | (#37602136)

Glascow Haskell Compiler [haskell.org] :

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.

It's also easier to test... (0)

Anonymous Coward | about 3 years ago | (#37601750)

I'm learning Clojure recently and, honestly, the fact that it is dynamic is a gigantic drawback. There are a few projects for adding more "typing" to Clojure (it's a Lisp-1 dialect after all, so you can do *anything* ; ) but I'm seriously considering Haskell now.

Type inference rocks. People have been killed due to inches/centimeters programming mistakes. I for the f**ck of my life cannot understand why people agree to pass things they're not supposed to to methods/functions. This kind of uber-stupidity should be caught at compile time (wait, no, even better: at editing time, because you're IDE/Emacs/whatever *should* be able to compile even an impartial AST and tell you immediately that you got your types wrong).

And, no, I don't buy the argument that "you don't really need type in truly dynamic languages".

Read Tony Morris's (ex-IBM JVM engineer) weblog on Haskell and understand how very little you know about programming...

Also, the reason why, you, as a programmer, aren't making the $$$ that TFA author is making, is because you don't understand why OCaml and Haskell obviously rock big times.

Re:It's also easier to test... (1)

Oligonicella (659917) | about 3 years ago | (#37602098)

"Also, the reason why, you, ... is because you don't understand ...."

So, if I find a programmer making more money than TFA author, his language of choice is perforce better than OCaml and Haskell?

Re:It's also easier to test... (0)

Anonymous Coward | about 3 years ago | (#37602108)

you, as a programmer, aren't making the $$$ that TFA author is making, is because you don't understand why OCaml and Haskell obviously rock big times.

I'm making pretty good money, probably because I'm not wasting my time converting business processes from a list of processes into a recursive series of functions.

Then again, I'm also not using dynamically typed procedural languages either.

Re:It's also easier to test... (1)

garyebickford (222422) | about 3 years ago | (#37602350)

(wait, no, even better: at editing time, because you're IDE/Emacs/whatever *should* be able to compile even an impartial AST and tell you immediately that you got your types wrong).

I would like to agree with this (long ago I even work with an 'Interactive Incremental Compiler' for FORTRAN that did the syntax checking on a line by line basis as you typed). But there is a major problem - the editor basically has to include a complete, correct copy of the language compiler/interpreter in its own logic. Since most languages these days are built based on various token-tools, perhaps it would be possible to base the checking on the input definitions to those tools (sorry I can't remember what they are called.) That would be an interesting exercise, and might make it possible to build a multilanguage editor that had that capability.

Many editors (Vim, e.g.) have pretty good syntax coloring which is a good half-step in this direction. And the APL environment worked that way, and there have been others. I think languages that have adopted C-like syntax will be the last because C syntax is so ... baroque.

Ah Haskell (1)

Haedrian (1676506) | about 3 years ago | (#37601752)

I remember using it during my uni times and finding it very cool.

However it is less useful than Iteratative or OOP languages unless you NEED to use mathematics and recursion all the time, in which case its easier.

I disagree, it'll always be a niche language which isn't for 'the masses'.

Re:Ah Haskell (1)

Lemming Mark (849014) | about 3 years ago | (#37603268)

Part of the problem there is in the teaching of it though; my university taught Standard ML and almost went out of their way to avoid teaching us how to write anything in it that would be useful in the real world. There are some quite practical real-world software packages written in ML / OCaml / Haskell. Plus I find functional-style constructs incredibly useful to sprinkle in Python code I write.

Another functional programming fan (1)

Animats (122034) | about 3 years ago | (#37601798)

OK, somebody posted their resume.

Python is similarly terse, and isn't statically typed. So this isn't about static typing. It's another functional programming fan.

Functional programming is a good fit to a certain class of algorithms. For the 65 programmers of a trading house, it makes sense.

Functional programming has its downsides. It tends to result in heavily nested code. It's hard to fan out results, so programs tend to be trees with a single result. Persistent state and I/O don't fit well with the functional model.

OCaml has some features that ought to be in more languages, like Djykstra's "guards" for choosing multiple alternatives.

Re:Another functional programming fan (1)

shutdown -p now (807394) | about 3 years ago | (#37601980)

The nice thing with OCaml is that it has all the good old imperative goodness - it even has while and for loops. It's just that immutability is default, and you have to sprinkle "mutable" in your data structures where you actually need it.

One thing that I personally find awesome about OCaml, though, is not so much its FP side, but rather it's 100% structural OOP approach. This lets them do pervasive type inference, even for operations such as method calls. And yet their object model is very powerful - it has multiple inheritance, parametric types etc.

Re:Another functional programming fan (5, Interesting)

dkleinsc (563838) | about 3 years ago | (#37602088)

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).

Shorter code? (2)

value (2182292) | about 3 years ago | (#37601940)

Perl also has shorter code, and it's not easier to read.

Re:Shorter code? (4, Insightful)

shmlco (594907) | about 3 years ago | (#37602138)

If shorter, more concise code was always better, we'd have switched to APL years ago.

We didn't.

Re:Shorter code? (0)

Anonymous Coward | about 3 years ago | (#37602334)

If shorter, more concise code was always better, we'd have switched to APL years ago.

We didn't.

Obligatory quote :

"APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums. -- Edsger Dijkstra"

Re:Shorter code? (2, Insightful)

Anonymous Coward | about 3 years ago | (#37602296)

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.

Re:Shorter code? (1)

garyebickford (222422) | about 3 years ago | (#37602402)

APL FTW! :D Occasionally described as the first 'Write-only language'. But it was remarkably good at describing the pure problem efficiently, without all the syntactic fiddling most languages require. Cross-product was just 'cross-product' - no nested for loops. But the programmer had to think completely in terms of the abstract problem being solved, not piecewise refinement of all the fiddly details.

Two line summary of TFA (1)

idontgno (624372) | about 3 years ago | (#37601988)

I have the perfect hammer.

Everything should be a nail.

Re:Two line summary of TFA (2, Informative)

Anonymous Coward | about 3 years ago | (#37602068)

I have the perfect hammer.

Would that be the C family of languages used all over the place?

Re:Two line summary of TFA (1)

mbone (558574) | about 3 years ago | (#37602268)

No, no no. It should be:

I have the perfect hammer.

Everything is a nail.

Re:Two line summary of TFA (1)

Duhavid (677874) | about 3 years ago | (#37602676)

With C/C++, everything can be!

Most comments are missing the point... (1)

Anonymous Coward | about 3 years ago | (#37601992)

TFA gives a wonderful example where the type system detects that the list function is missing one case. This is huge. This is huger can you can imagine if you don't understand what it's all about.

The problem is that we've got "programmers" that have no formation whatsoever in computer science and that play cry-babies as soon as something looking a tiny bit like some kind of mathematical notation appears. It's really, really, very sad. The list example in TFA is spot on and is simply wonderful.

Fix Ocaml threading.. (0)

Anonymous Coward | about 3 years ago | (#37602012)

so it really works and we'll look at it. We've been looking at a plan-b
in case oracle screws up java beyond use. Right now it looks like
Erlang.

Re:Fix Ocaml threading.. (1)

Medievalist (16032) | about 3 years ago | (#37602994)

We've been looking at a plan-b in case oracle screws up java beyond use. Right now it looks like Erlang.

Well, if a thousand unbelievably crappy, unstable, and resource-inefficient erlang programs hit the streets in a couple of years, I'll know it wasn't actually the Java language that was the problem after all, it was the Java programmers. Which is what I suspect, frankly.

Practicality drives use (2, Interesting)

grimmjeeper (2301232) | about 3 years ago | (#37602028)

'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.

Re:Practicality drives use (4, Insightful)

mbone (558574) | about 3 years ago | (#37602252)

'The importance of concision is clear: other things being equal, shorter code is easier to read, easier to write, and easier to maintain.'

That was the idea behind APL. You could do amazing things in one line of code. I never, however, knew anyone who used it who thought it was easier to read, easier to write or easier to maintain.

Re:Practicality drives use (1)

grimmjeeper (2301232) | about 3 years ago | (#37602328)

Agreed. In fact, just about everywhere I work has a coding standard that says you shouldn't cram a whole lot of stuff into one line of code specifically because it's hard to write correctly, not to mention difficult to read and maintain. Perhaps that's a symptom of the chosen languages but I suspect it goes deeper than that. It's been my experience that one needs to be able to strike a balance between complexity/elegance and readability. I've been known to write code so clever and elegant I have no idea what it does just months after I write it.

Re:Practicality drives use (0)

Anonymous Coward | about 3 years ago | (#37602910)

This is all true but OCaml and other such languages don't achieve concision like that.
They essentially allow you to remove a lot of useless boiler plate, code duplication etc.
For instance, type inference is really nice. It lets you write code like in python where you are not writing types on every line in a rather verbose way and at the same time your expressions are more precisely typed than in Java (Ocaml has serious 'generics').

There is also support for object data structures and pattern matching that makes for really concise algorithm code. And at the same time it's quite readable (3 or 4 rules describing the structure of input and what to do to in based on that is usually more readable than a bunch of if-then-else).

In the end I am still doing python stuff as it's more mainstream and the lack of type inference is manageable for the stuff I do. But I have often wondered if I should not use ocaml or something like that instead...

 

Ahem (1)

toby (759) | about 3 years ago | (#37602784)

"Procedural languages are the norm because they're a lot simpler"

Maybe you haven't seen Scheme.

Procedural programming isn't simpler. Its popularity and mindshare (like that of say, Windows) is accidental, and needs to end for the industry to move forward. Minsky's not the first or last to point this out.

Re:Practicality drives use (0)

Anonymous Coward | about 3 years ago | (#37602898)

To me, functional languages are actually more intuitive.

My problem is that they tend to want to assume hardware doesn't exist,or should be abstracted away.

This comes up in all sorts of ways: I/O is a pain in haskell, both it and ocaml are behind in concurrency and parallellism, and scala is wedded to the jvm (which is fine in itself, but not designed for scala) in a frankenstein arrangement.

If the functional world wants first-class status, it has to start embracing hardware, not badmouthing it as somehow being lower class.

Re:Practicality drives use (1)

goertzenator (878548) | about 3 years ago | (#37603038)

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.

What's easiest is what you're used to. The most popular programming system on earth is Excel, which is firmly in the functional camp.

multicore (0)

Dr. Tom (23206) | about 3 years ago | (#37602056)

but can haskell effectively leverage multicore? one school of thought suggests that parallel processing is perfect for non-deterministic functions, which can be trivially implemented in Haskell. But I read that about Prolog. Not Haskell.

Re:multicore (0)

Anonymous Coward | about 3 years ago | (#37602294)

prolog can do parallel processing trivially; these days it's actually faster in many cases to run a non-deterministic computation using a breadth-first strategy and finding the solution that way; serial attempts are of course very slow. Not that parallel programming is easy, just easier in a language that supports non-determinism

Re:multicore (1)

sourcerror (1718066) | about 3 years ago | (#37602566)

My only problem with non-determinism and Prolog was that it was really hard to find where unnecessary choicepoints are. (e.g. you get the same results multiple times) Prolog could definitely use better debugging tools.

Wrong question: (1)

toby (759) | about 3 years ago | (#37602830)

The real question is, can NON-FP systems effectively leverage multicore? Functional programming has extremely powerful tools to exploit new hardware. Pthreads and explicit locking do not. Have you heard of Erlang?

OCaml vs Javascript (1)

Colin Smith (2679) | about 3 years ago | (#37602154)

Place your bets.

 

Concision? (2)

digitig (1056110) | about 3 years ago | (#37602240)

APL is very concise and is famously easy to read and maintain. Oh, wait...

academic language (0)

Anonymous Coward | about 3 years ago | (#37602270)

Ocaml was designed by academics, for academics. I've used it for a few years, it does what it does pretty good, but unless you're into formal proofs and all that it's not worth your time. It might be useful for very specific applications but the "for the masses" is a huge joke.

Also its concision and very static typing means that it's a mostly write-once.

irrelevant (-1, Offtopic)

Dr. Tom (23206) | about 3 years ago | (#37602306)

Most of the posts here are missing the point ... Oh wait, this is slashdot. Funny: 5 trumps actually useful information ...

F# (0)

Anonymous Coward | about 3 years ago | (#37602552)

I thought F# was Ocaml for the masses...

Functional languages and RDBMS? (1)

FoolishOwl (1698506) | about 3 years ago | (#37602558)

I'm no developer, and only a novice with programming and databases, so this may be a naive question.

I remember reading about Object-relational impedance mismatch [wikimedia.org] . I thought, if object oriented programming is a poor fit, conceptually, with the relational database model, perhaps functional programming would be a better fit: the code leaves the management of state to the database, which is its specialty.

Does that make any sense?

Re:Functional languages and RDBMS? (1)

purpledinoz (573045) | about 3 years ago | (#37602906)

The Object-Relational Impedence Mismatch has nothing to do with OOP vs Functional programming. There's an intrinsic difference between how data is represented in a database, and how it is represented in code. For example, what type would you use for a 32-bit integer in Oracle? NUMBER(10) would fit all 32-bit integers, but it can also contain numbers that are larger than a 32-bit Integer. NUMBER(9) will guarantee that anything in the database will fit into a 32-bit Integer, but will not be able to store all possible values of 32-bit integers. There are a ton of other issues, but I don't see how functional programming would solve any of them.

Déjà vu (1)

toby (759) | about 3 years ago | (#37602918)

All the fear and uncertainty coming from those who've never tried functional languages here sound just like the mobs in 1965 insisting 'compiled languages will never catch on'.

Smell the coffee. Learn something. The industry needs to change. [loper-os.org]

Any studies to back up the "small code" thesis (2)

istartedi (132515) | about 3 years ago | (#37602970)

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!

shorter code is begging the question (0)

Anonymous Coward | about 3 years ago | (#37603088)

If you start doing anything in Haskell like using SQL databses, networking, regex matching, etc you won't be any more terse than any other language. It's just terse because the only thing you do with it is Scheme-like sample programs. People complain Perl is hard to read, too, but then they point to other languages like Python which don't have regexes or string processing built into them. If you write a string processing program in Python with a lot of regexes, it will be as hard to read as Perl. Programs that do anything non-trivial are going to be non-trivial. I haven't looked at Haskell as much as Erlang, but Erlang is the only serious programming language I've ever seen that implements the COME FROM statement in INTERCAL - flow of control magically gets transferred to a point in the program for no obvious reason. Takes a very special person to grok that kind of weird stuff.

What will happen is what always happens - the best ideas will be co-opted by Java and C# once they prove themselves.

Data vs algorithm (2)

Hentes (2461350) | about 3 years ago | (#37603230)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?