Forgot your password?
typodupeerror
Programming

OCaml For the Masses 338

Posted by timothy
from the cue-up-the-language-bigots dept.
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.'"
This discussion has been archived. No new comments can be posted.

OCaml For the Masses

Comments Filter:
  • by tulcod (1056476) on Tuesday October 04, 2011 @02:01PM (#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: (Score:2, Interesting)

      by gstoddart (321705)

      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 hate

      • by makapuf (412290)

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

        • Re: (Score:3, Funny)

          by gstoddart (321705)

          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

      • by Darinbob (1142669)

        Lisp is used for just about everything possible. Compilers, editors, games, window systems, etc. Lisp isn't really in the same category as pure functional languages like Haskell. But pure functional languages have been used to do a whole lot of larger applications as well, editors, compilers, etc.

        The big problem is that in a lot of programs you need more than just the pure functions; you need I/O and other side-effects. Functional languages have these but they often feel like odd bits tacked on that cor

        • Re: (Score:2, Offtopic)

          by gstoddart (321705)

          The big problem is that in a lot of programs you need more than just the pure functions; you need I/O and other side-effects.

          See, a computer language without IO is generally something which doesn't do anything useful. If all they are is something which is elegant and pretty, it's hard not to write them off as something that academics crow over but which have no actual value.

          Obviously, that's a gross overstatement, but usually I get the impression that people fawn over it because it's pretty and plays into

          • Haskell has monads for I/O, which are very elegant. They also give you things like software transactional memory (which is great for concurrent code) in a way that's both easy to implement and easy to reason about.
      • by fusiongyro (55524)
        You missed the part about the author being at Jane Street Capital?
    • 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

      • by HiThere (15173) <charleshixsn@@@earthlink...net> on Tuesday October 04, 2011 @04:20PM (#37603668)

        You misunderstand thing. General purpose languages, such as the C or Algol family (which includes, among others Java, Python, and Ruby) do, indeed, include concepts from functional languages. But they don't RESTRICT you to those concepts. It's the insistence that everything be unchanging that is the weakness in the purely functional languages. The Scheme family is the only group of that to have any measurable use. (Note that Lisp is NOT a functional language, even though the concept originated via a subset of Lisp.)

        There's much to be said for having the ability to have invariant elements in functions. There's very little in having the requirement that everything be that way. Note that many existing languages that have invariant strings ALSO have mutable strings. Java to name just the most popular example. So by all means allow functions to declare their values invariant. This allows lots of different kinds of optimization. But don't insist that all functions do so. And definitely don't insist that everything be invariant.

        • What functional language makes everything immutable always? Typically, immutability is the default behavior, but not the only behavior.
  • by Anonymous Coward on Tuesday October 04, 2011 @02:05PM (#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: (Score:3, Insightful)

      by Anonymous Coward

      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?

      • by Waffle Iron (339739) on Tuesday October 04, 2011 @03:17PM (#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.

      • 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.
    • by m50d (797211)

      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.

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

      I think procedural programming is easier for humans who have spent prior time studying procedural and/or imperative programming to understand. I'm not convinced its any easier to understand starting from scratch, though.

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

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

  • 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 th

    • 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 ha

      • by Animats (122034)

        It's just that immutability is default, and you have to sprinkle "mutable" in your data structures where you actually need it.

        That's a related idea to functional programming - single-assignment languages. [c2.com] The idea is that all (or at least most) names are "const" - they can only be assigned a value once. This works a lot like functional programming, but there's not so much nesting, and most things have names, rather than being anonymous within some nested expression.

        Pure functional languages force programs into a tree form, with one output. A single assignment language forces programs into directed acyclic graph form, with multi

    • by dkleinsc (563838) on Tuesday October 04, 2011 @02:31PM (#37602088) Homepage

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

    • Agreed that Python is similarly terse, that's one reason I like it. But static typing does eliminate a whole class of errors if done properly. The ML family and Haskell languages do have an amazing static type system, which provides guarantees that I don't have when I program in Python. It's more powerful than the type systems of other statically typed languages whilst being not verbose.

      To a large extent, for some functions, when something got through the ML typechecker correctly I generally found most o

  • I have the perfect hammer.

    Everything should be a nail.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      I have the perfect hammer.

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

    • by mbone (558574)

      No, no no. It should be:

      I have the perfect hammer.

      Everything is a nail.

    • by Duhavid (677874)

      With C/C++, everything can be!

  • by grimmjeeper (2301232) on Tuesday October 04, 2011 @02:27PM (#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.

    • by mbone (558574) on Tuesday October 04, 2011 @02:44PM (#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.

      • 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

    • by toby (759)

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

      • I have, and my point still stands. A minimalist Lisp language may have a simpler syntax but that's not what I'm referring to when I call the languages simpler. The point is that the concepts behind building software with procedural languages are far more simple than using functional languages. The average office worker can cobble together enough thought process to write basic macros in a spreadsheet. Try getting those same people to use a functional language to do the same thing and then tell me how "sim

      • by Alomex (148003)

        Maybe you haven't seen Scheme.

        Or maybe he has like all other people who took programming languages in their (CS undergrad (and (completely '(hated it))))

  • Place your bets.

     

  • by digitig (1056110) on Tuesday October 04, 2011 @02:43PM (#37602240)
    APL is very concise and is famously easy to read and maintain. Oh, wait...
  • 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?

    • 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
      • I can see that sort of mismatch as a serious problem.

        However, the Wikipedia article I reference was definitely discussing a difference in design philosophies between OOP and RDBMS, which I understood to be essentially that objects are understood to be both function and data structure, but databases are concerned only with data structures, which complicates moving data back and forth.

      • what type would you use for a 32-bit integer in Oracle?

        Umm... INTEGER? (or maybe PLS_INTEGER if you want to be Oracle specific).

        In any case, I really don't think the mapping of datatypes has anything to do with OR impedance mismatch. It has to do with how data structures are represented in code vs how data is stored in an RDBMS (OOD vs relational tables). For instance, the concept of inheritance does not exist in an RDBMS. While tables can be constructed to implement the concept, it's generally a bit of a kludge, a kludge that ORM middleware was invented to ma

  • by toby (759)

    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]

  • by istartedi (132515) on Tuesday October 04, 2011 @03:28PM (#37602970) Journal

    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!

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

  • I have no experience in functional programming languages, so I'm curious to hear from those who have developed real applications. How does functional programming do when having to create UIs? Or reading/writing to a database and dealing with transactions? Or creating a web-service? Or enforcing business logic?

    Functional programming seems ideal for writing algorithms, but does it have any drawbacks?

  • The guy started his career writing in VBA and moved to OCaml via Java. Is it any wonder he finds OCaml so great?

What this country needs is a dime that will buy a good five-cent bagel.

Working...