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

111–120 of 132 posts

Re: Why OCaml, why now? (2014)

#111

Post by microtonal »

wyager wrote: post #64
mercurial wrote: post #39

Earlier quoted context omitted.

The language itself is not very big. The category-theory based abstractions built on top of it, on the other hand... Just look at the lens library.

That's fair. But I don't think it's reasonable to lump learning about lenses (or other abstractions that aren't part of the prelude) into learning Haskell.

Except that lens is being used by a quickly growing chunk of the ecosystem:

http://packdeps.haskellers.com/reverse/lens

(Yes, I am guilty too, but I inherited the dependency via Chart ;).)

Re: Why OCaml, why now? (2014)

#112

Post by mercurial »

wyager wrote: post #97
aphexairlines wrote: post #90

Earlier quoted context omitted.

Judging the ecosystem is fair in the same way that Java is lumped together with the reams of j2ee, spring, AbstractFactoryFactory sort of libraries that it yields. For better or worse, switching to Haskell does entail asking yourself how hard it'll be for your team to become comfortable with things like http://learnyouahaskell.com/functors-applicative-functors-an...

That's a good point. I suppose people do judge Java by the popular Java libraries and their styles. However, I don't really consider those things when talking about how difficult Java is to learn. Learning Haskell may well be easier than using it, although the same is true for most languages.

But you don't learn Java just to learn Java, usually. You learn it in order to solve a problem. Which means working with the ecosystem. And personally, I'd rather use libraries I can understand if needed.

Re: Why OCaml, why now? (2014)

#113

Post by mboes »

jonsterling wrote: post #52

Nice post! There are a lot of good reasons to use OCaml over Haskell which are more compelling than “JavaScript”, though. A few of them are: 1. modularity (and now that they have added generative functors à la SML, you can have true abstraction) 2. benign effects: in Haskell "proper", you do not have effects; rather you have "codes" for effects, which get interpreted into effects by the RTS; this rules out the possib…

> 3. strictness: arguments abound about whether laziness or strictness is better; for me, it comes down to the fact that with some pain, you can embed laziness in a strict language with effects, but you cannot embed full-on ML-style strictness into a language like Haskell; moreover, strictness-by-default permits safe uses of benign effects.

I've seen this claimed before, but I'm not sure I can subscribe to any sense in which this statement is true. It's been known since at least John Reynolds that you can make programs evaluation order oblivious by means of a CPS transformation: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.110..... Just as thunkification is a program transformation to simulate call-by-name, the call-by-value CPS program transformation is a way to simulate call-by-value.

Moreover, Haskell has strictness annotations, so strict programming is possible if you pepper all the arguments of all your functions with strictness annotations and you use only strict datatypes. In fact in the future a language pragma will do this for you: https://ghc.haskell.org/trac/ghc/wiki/StrictPragma. That's less invasive than a CPS transformation.

Re: Why OCaml, why now? (2014)

#114

Post by justincormack »

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…

The financial DSL paper is a good example as although it was Haskell based, Jane Street eventually chose OCaml for production.

Re: Why OCaml, why now? (2014)

#115

Post by emillon »

yodsanklai wrote: post #44

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.

> Also, when your programs use abstract data types you lose the benefits of pattern matching.

In some cases you can also use "private ADTs". Modules seeing such a type can use pattern matching on them but can not apply the constructors.

Re: Why OCaml, why now? (2014)

#116

Post by p0nce »

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…

Hi from "the sea". I think the Functional Programmers crowd overestimates how much better languages can really improve software development.

Projects in the industry would be massively improved by: more focus on quality (eg. decoupling), technical debt awareness, enhanced communication, enhanced architecture, internal engineer mobility, more thoughts given on social dynamics and productive work environments.

It pains me to say this but supposedly "bad" languages like C++/Java (which are actually really well done) are not the bottleneck for software development. It is only a distant factor among many that lead to software being the permanent tragedy it is in our era.

Re: Why OCaml, why now? (2014)

#117

Post by the_why_of_y »

microtonal wrote: post #110
ignoramous wrote: post #38

Unless start-ups or top companies [0] start adopting OCaml, I doubt its rise would be meteoric. Take go-lang, for example. It performs no better than Java on JVM, but is gaining tremendous traction because Google is putting all its weight behind it. I believe C# gets far less credit than it deserves... and MSFT knows exactly what its doing by open sourcing it. I digress. I feel, one is better off investing time in Cl…

Take go-lang, for example. It performs no better than Java on JVM, but is gaining tremendous traction because Google is putting all its weight behind it. That's definitely a large factor. But let's not forget that Go already took off when it was barely beyond being a 20% project. Go also fills some niches, three particular ones I can think of are: - People who like Java, but favor the UNIX approach of small programs…

> People who like Java, but favor the UNIX approach of small programs over the JVM.

Ah, that must be why the golang toolchain does not support bloated enterprise features like dynamic linking, so a hello world binary ends up almost 2MB. Go UNIX!

Re: Why OCaml, why now? (2014)

#118

Post by the_why_of_y »

tel wrote: post #13
dbpatterson wrote: post #5

I think the author doesn't give enough credit to things that OCaml has that Haskell doesn't have: a powerful module system (ie, functors), polymorphic variants/subtyping, etc.

Haskell has subtyping, it just doesn't use it a whole lot. That said, you can make arbitrary subtyping hierarchies using it if you like.

Actually Haskell doesn't have subtype polymorphism, at least not Haskell 98 (but maybe there is some new GHC extension nowadays that I'm missing - please elaborate if that is what you refer to).

Re: Why OCaml, why now? (2014)

#119

Post by mattgreenrocks »

paulrpotts wrote: post #42
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, t…

Learning Haskell is not out of the question for most devs. The real question is whether they're willing to let go of a lot of their programming experience so as to admit a different style of programming.

It's more akin to studying than anything else. I've had evenings where I've been unable to proceed because I can't write one line. It's OK; it's part of learning. No one said it would be easy.

Beginner's mind is key.

Re: Why OCaml, why now? (2014)

#120

Post by sixbrx »

frowaway001 wrote: post #91
aphexairlines wrote: post #89

Earlier quoted context omitted.

The problem with Scala is that you don't just get ML -- you have to accept everything else that comes along -- so F# can be a more comfortable choice.

It might be easier to accept the additional parts of Scala, because the creators didn't design them to be an tacked-on, intentionally horrible feature. (OO in F#/OCaml anyone?) Plus, sane typeclasses and higher-kinded types. :-)

I agree and I think F# would look a lot more attractive to functional programmers if it had some type of polymorphism other than the C#-like generics and traditional OO subtyping.

I can understand not choosing to go the ML route "down the Functor rat hole" as one of its developers said. But then it also chooses not to do the simpler type classes either. Apparently a proper impl would need CLR changes which is a downside to the reified generics, they are baked in as C#/VB imagined them. That leaves a language that conceptually is very close to C#/VB, with a somewhat different syntax.

I find either of typeclasses or an ML-like module system far preferable for expressing abstractions than traditional ("left-biased") OO, even if OO can (clumsily) get the same results in other ways.

Or I may have missed some developments in F# since I last looked. I really hope so, F# does have a lot going for it.

Post reply on HN