Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why OCaml, why now? (2014)

spyder.wordpress.com

Post reply on HN
Print view View original

41–50 of 132 posts

Re: Why OCaml, why now? (2014)

#41

Post by lomnakkus »

jordwalke wrote: post #37
lomnakkus wrote: post #29

Earlier quoted context omitted.

Naw, Harper is SML-all-the-way (AFAICT). Btw, Haskell is technically not "lazy", it's "non-strict". Now, I think he has a good point, but I don't think think there's any general consensus within the FP community which one of non-strict/strict is "better". Personally, I don't think there's a "right" answer. Earlier on in my career, I would have said that "non-strict/strict" should have a part of the type of a term, bu…

One thing I find interesting, is that our industry is basically a gigantic sea full of Java/C++ programmers. Within that ocean, there is a small portion of Functional Programmers who have come to a realization that a set of finer grained abstractions would improve the industry productivity at large. Within that small subset, you have a set of people who believe that static type systems aren't ready for widespread use…

I won't claim any special knowledge, nor do I have any actual solid research to back up my intuitions.

I can certainly recognize the feeling that O'Caml makes you more productive from when I first discovered it, but that was mostly just because of algebraic datatypes. (And pattern matching which, while not terribly useful in general circumstances, is hugely useful in practical CRUD-like applications.) Polymorphic variants also made the "pro" list.

The biggest boost to my productivity I've ever felt(!) was when explicitly separating different types of effects. (Not just "pure vs. impure", but "uses-network" vs. "uses-filesystem" vs. "pure"... which is why I'm currently sticking with Haskell because it enforces that kind of discipline.

(I'm sure there'll be something better coming along any day now, but...)

Mostly, I hope that problem is mostly a lack of (appropriate) advocacy and education. There's also an absurd amount of inertia which is due to sheer entrenched interests/industries.

EDIT: ... or maybe it's a generational thing. After all this kind of thing happens in every other fast moving discipline without terribly rigorous theoretical underpinnings[1], e.g. medicine or biology.

[1] Don't get me wrong, CS is basically math which is unassailable, but we still have no idea how to (reproducibly) produce stable/well-functioning software.

Re: Why OCaml, why now? (2014)

#42

Post by paulrpotts »

wyager wrote: post #19

I honestly don't get how people can claim that Haskell is unusually hard to learn. I started learning Haskell with zero functional programming experience, and after getting over that initial pure+functional learning curve (which took two or three weeks of casual learning), it was smooth sailing. Haskell is actually a very simple language compared to popular languages like python or C++; you just have to do a bit of t…

Keep in mind that writing something like this is not actually going to be perceived as helpful to most people who may have difficulty with Haskell. Consider a couple of possibilities.

First, you may be unusually quick, gifted, clever -- whatever you might want to call it. In this case, the new concepts in functional programming might come easy for you. That's great, but to people for whom they don't come so easily, this could easily be considered discouraging, or else bragging.

Second, consider that maybe you haven't advanced as far in learning Haskell as you think you have. In my estimation Haskell can take you up an abstraction ramp, that has no clear and obvious "end." As a research language, higher up that curve is some really mind-blowing stuff. So unless you're SPJ or beyond, I wouldn't be quick to claim that Haskell isn't "unusually hard to learn."

Third, you may be a stage in your life where you can put a lot of free time into learning, but recognize that not everyone is there. In my twenties, I worked much more than full time, and in my spare time worked on yet more programming, teaching myself other languages and environments. Really in retrospect it's fortunate I didn't damage my physical or mental health more than I did. But not everyone is in that boat now. In particular people who are older and have "work/life balance," who are professionals in some form of software development, may find that their employment doesn't offer them much in the way of opportunities to learn another language, and the life part of that work/life balance doesn't allow much time to do so.

Me, I'm somewhere partway up that ramp and proud of how far I've come (I feel like I can use at least simple monads now) but still very aware that there is a lot I don't fully grok (currently trying to get my mind around arrows). And I agree, I completely recommend it, but just maybe don't be so glib to claim it is not hard.

Re: Why OCaml, why now? (2014)

#43

Post by paulrpotts »

alayne wrote: post #35
wyager wrote: post #19

I honestly don't get how people can claim that Haskell is unusually hard to learn. I started learning Haskell with zero functional programming experience, and after getting over that initial pure+functional learning curve (which took two or three weeks of casual learning), it was smooth sailing. Haskell is actually a very simple language compared to popular languages like python or C++; you just have to do a bit of t…

From your website, you appear to be a college student. Perhaps your expectations and uses are different than commercial developers.

College students often feel at the time that they are completely overloaded with work and barely getting through (in some cases that is true, especially students who are working or non-traditional). But looking back, it is pretty clear that although I worked hard in school, I could have worked so much harder, and also that never in my life again will I be in an environment that was so _supportive_ of just learning. Not just in classes; in fact, my college experience was _especially_ supportive things learned outside of classes. And also, at 20, 21, 22 -- there are very good reasons those are the traditional college years. Our brains are just able to _soak_ up ideas so quickly at that age. They aren't wise, they can't necessarily integrate everything, but we are _sharp_ then! (Usually...)

Re: Why OCaml, why now? (2014)

#44

Post by yodsanklai »

One thing I don't like about OCaml is that I always find myself writing the same things, like "to_string" functions for my variant types (although there must be some ways to alleviate this burden).

Also, when your programs use abstract data types you lose the benefits of pattern matching. In that case, I'm happier with languages like Go or Ada with a friendlier syntax.

Re: Why OCaml, why now? (2014)

#45

Post by jordwalke »

lomnakkus wrote: post #30
jordwalke wrote: post #12

Earlier quoted context omitted.

There's a bunch of other nice features of OCaml such as named arguments, fast compile times, strictness, c-types, and reasonable records. To achieve (some of the feature in) Elm style "structural subtyping" records in OCaml you use the more verbose "object" keyword which is just a record with row polymorphism. Most choose to stick with standard records because they compile to more efficient code. I think the ML modul…

Agreed on the ML module system. It's a damn shame that Haskell has this anemic probably-historical-accident namespacing-only module system that we're stuck with. On the plus side, there seems to be some real impetus to implement the Backpack system, though there are still unexplored points in the design space behind Backpack, especially wrt. type classes. FWIW, I think type classes are actually what make Haskell more…

One thought on the verbosity of type classes vs. ML modules/functors: As a framework developer, if I have a more powerful abstraction (supposing ML functors/modules really are more powerful), then even if abstracting is more verbose, it might result in an even better end-developer experience, if that explicitness is limited to the core internal part of the framework.

In other words, that verbose application of functors etc, might only need to be written once in the internals of the framework, but could enable more powerful features for users of the framework with little or no additional verbosity. This is just one thing I've noticed happen in a very specific case and it might not be true in general. Really learning Haskell type classes is still on my list of things to do, so please forgive me if I've misspoken.

Re: Why OCaml, why now? (2014)

#46

Post by lomnakkus »

jordwalke wrote: post #45
lomnakkus wrote: post #30

Earlier quoted context omitted.

Agreed on the ML module system. It's a damn shame that Haskell has this anemic probably-historical-accident namespacing-only module system that we're stuck with. On the plus side, there seems to be some real impetus to implement the Backpack system, though there are still unexplored points in the design space behind Backpack, especially wrt. type classes. FWIW, I think type classes are actually what make Haskell more…

One thought on the verbosity of type classes vs. ML modules/functors: As a framework developer, if I have a more powerful abstraction (supposing ML functors/modules really are more powerful), then even if abstracting is more verbose, it might result in an even better end-developer experience, if that explicitness is limited to the core internal part of the framework. In other words, that verbose application of functo…

That was actually my main objection to modules vs. typeclasses: The burden often seemed to land on the users of libraries. Typeclasses are usually effortless as a user, though there may be a multitude of sins[1] hidden behind them.

EDIT: Don't get me wrong, there are also advantages to being able to explcitly declare two structurally identical modules as different, but in practice I find that newtypes suffice.

[1] FlexibleInstances, UndecidableInstances, etc. :)

Re: Why OCaml, why now? (2014)

#47

Post by tpetricek »

jordwalke wrote: post #37
lomnakkus wrote: post #29

Earlier quoted context omitted.

Naw, Harper is SML-all-the-way (AFAICT). Btw, Haskell is technically not "lazy", it's "non-strict". Now, I think he has a good point, but I don't think think there's any general consensus within the FP community which one of non-strict/strict is "better". Personally, I don't think there's a "right" answer. Earlier on in my career, I would have said that "non-strict/strict" should have a part of the type of a term, bu…

One thing I find interesting, is that our industry is basically a gigantic sea full of Java/C++ programmers. Within that ocean, there is a small portion of Functional Programmers who have come to a realization that a set of finer grained abstractions would improve the industry productivity at large. Within that small subset, you have a set of people who believe that static type systems aren't ready for widespread use…

Can I please quote your debating which particular brand of natural spring water should be given to millions of people who are thirsty in the desert when I get a chance :-)? It is a great summary of the problem with functional programming.

As a person with academic background interested in real-world FP (using F# in my case), this is exactly why I'm not very enthusiastic about most functional programming papers that appear in conferences like ICFP - they might be solving fun problems, but I'm not convinced they are problems that actually matter if we're going to ignore the main issue.

I think interesting functional libraries that demonstrate how to apply FP to some interesting problem can help here - for example, the paper on financial DSLs (http://research.microsoft.com/en-us/um/people/simonpj/papers...) or the original paper on Functional Reactive Programming (http://conal.net/papers/icfp97/).

Re: Why OCaml, why now? (2014)

#48

Post by ezy »

lomnakkus wrote: post #41
jordwalke wrote: post #37

Earlier quoted context omitted.

One thing I find interesting, is that our industry is basically a gigantic sea full of Java/C++ programmers. Within that ocean, there is a small portion of Functional Programmers who have come to a realization that a set of finer grained abstractions would improve the industry productivity at large. Within that small subset, you have a set of people who believe that static type systems aren't ready for widespread use…

I won't claim any special knowledge, nor do I have any actual solid research to back up my intuitions. I can certainly recognize the feeling that O'Caml makes you more productive from when I first discovered it, but that was mostly just because of algebraic datatypes. (And pattern matching which, while not terribly useful in general circumstances, is hugely useful in practical CRUD-like applications.) Polymorphic var…

(Note, not being critical of you, just placing this here because I was thinking about it recently)

Maybe because CS is so young, there is a tendency to confuse theory and practice.

Whether a particular language makes one more productive isn't math, it's engineering. When we talk about how monads might allow you to separate concerns and relieve a mental load -- we are talking engineering. When we talk about how monads compose, we are talking abut the math/science that enables the engineering. They are both related, just like mechanics is related to mechanical engineering, but they aren't the same and they have different concerns.

Be wary when you start thinking in terms of "entrenched interests". It's tempting to go down that road, but the reality is that those "entrenched interests" actually have good engineering reasons to be that way[1]. It isn't like a million other programmers haven't noticed that FP-style programming offers some benefits -- but often the benefits end up not out-weighing the drawbacks in the languages, ecosystems, and practical performance and hardware concerns.

This should be obvious, but I think people start muddying the waters -- especially when they focus on the ideological purity of their programming language. Programming languages are tools. The most popular ones are engineering tools -- and there are some not so popular ones that are tools for exploring the math behind the language itself. There are too many tradeoffs to have a language which occupies both spheres successfully.

In particular, the FP advocates go round and round on this issue. Just because something is elegant mathematically, does not mean it's good engineering practice. Haskell, for example, can be practical, but it struggles between the math and the reality of limited machines and human cognition[2]. Likewise, when you start talking about SML vs OCaml, you're talking engineering, not math -- and possibly a language tailored to engineering vs math.

You see this in languages like C++ too, where practicality starts giving way to a kind of semi-mathematical, yet totally non-scientific, dogma about how programs should be constructed based on their respective committee-designed[3] standard libraries.

[1] not always, but more than people really give others credit for.

[2] I still maintain Haskell is a write-only language, like an opposing pole to perl. Not (completely) because of the language itself, but because of the culture surrounding it which glorifies one-liner lambda calculus/laziness tricks over engineering pragmatics.

[3] e.g. compromises made in absence of any real on-the-ground engineering constraints.

Re: Why OCaml, why now? (2014)

#49

Post by paulbutcher »

jordwalke wrote: post #37
lomnakkus wrote: post #29

Earlier quoted context omitted.

Naw, Harper is SML-all-the-way (AFAICT). Btw, Haskell is technically not "lazy", it's "non-strict". Now, I think he has a good point, but I don't think think there's any general consensus within the FP community which one of non-strict/strict is "better". Personally, I don't think there's a "right" answer. Earlier on in my career, I would have said that "non-strict/strict" should have a part of the type of a term, bu…

One thing I find interesting, is that our industry is basically a gigantic sea full of Java/C++ programmers. Within that ocean, there is a small portion of Functional Programmers who have come to a realization that a set of finer grained abstractions would improve the industry productivity at large. Within that small subset, you have a set of people who believe that static type systems aren't ready for widespread use…

I agree that this was the situation a while ago. But, recently, I've seen very encouraging signs that the wider programming community is waking up to the value of FP. Languages like Scala and Clojure, whatever else you think about them, will hopefully act as gateway drugs.

Re: Why OCaml, why now? (2014)

#50

Post by jordwalke »

tpetricek wrote: post #47
jordwalke wrote: post #37

Earlier quoted context omitted.

One thing I find interesting, is that our industry is basically a gigantic sea full of Java/C++ programmers. Within that ocean, there is a small portion of Functional Programmers who have come to a realization that a set of finer grained abstractions would improve the industry productivity at large. Within that small subset, you have a set of people who believe that static type systems aren't ready for widespread use…

Can I please quote your debating which particular brand of natural spring water should be given to millions of people who are thirsty in the desert when I get a chance :-)? It is a great summary of the problem with functional programming. As a person with academic background interested in real-world FP (using F# in my case), this is exactly why I'm not very enthusiastic about most functional programming papers that a…

No need to ask permission to quote me, but thanks for asking anyways. I definitely agree that shifting focus towards industrial use cases is what we need.
Post reply on HN