Why OCaml, why now? (2014) • Hacker News Board

Re: Why OCaml, why now? (2014)

#121

Post by glaebhoerl » Sun, Feb 15, 2015, 3:45 PM UTC

jonsterling wrote: post #85

peter-fogg wrote: post #84

Earlier quoted context omitted.

> 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 possibility of, e.g., using effects to implement a semantically pure interface. On the other hand, OCaml has actual effects, which can be used in an open-ended way to implement all sorts of functional interfaces. So, to be all pedantic and stuff... Y…

1. that's why I qualified it "proper". Of course there is unsafePerformIO, but in the presence of laziness, this is really unsafe . as opposed to ML, where doing IO may harm your ability to reason about stuff, but it won't be unsafe. Debug.Trace is also unpredictable; actually, it's perfectly predictable if you understand laziness, but it's still not what's really wanted in most cases. 2. ST is a single instance of a…

With regards to 2., could you briefly mention some other instances? I have no idea what I should be thinking of.

Re: Why OCaml, why now? (2014)

#122

Post by jonsterling » Sun, Feb 15, 2015, 4:09 PM UTC

mboes wrote: post #113

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…

Nope! You may be able to get evaluation order out of it, but the main reason I care about strictness is not CBV evaluation order. It is the following:

1. Reasoning by induction: not possible with a lazy function space

2. Non-pointed types: also not possible in Haskell

3. Compatibility with a proper treatment of effects

It's great that you can do strictness annotations in Haskell! But they don't accord one the above facilities at all.

Re: Why OCaml, why now? (2014)

#123

Post by dllthomas » Sun, Feb 15, 2015, 4:25 PM UTC

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…

Regarding your first point, it doesn't even require the claimant to be better in any particular sense - it could be that their prior knowledge was simply a better fit to the new concepts.

Regarding the second, I don't think it makes sense to consider "difficulty in learning Haskell" to be "difficulty in learning all of everything anyone's done with Haskell." Even SPJ has (or at least recently had) a pretty shallow understanding of Kmett's lens library. The two important questions are 1) how much do I need to learn to get things done in Haskell, and 2) how much do I need to learn to participate usefully in the Haskell community. 1 is less than 2, which is less than what you described.

"There is more stuff to learn that can make you even more productive, but you can get by without it and still be productive" often gets treated as a negative, and I find that strange...

Re: Why OCaml, why now? (2014)

#124

Post by galaxyLogic » Sun, Feb 15, 2015, 5:02 PM UTC

bojo wrote: post #104

wyager wrote: post #96

Earlier quoted context omitted.

Does it demonstrate a lack of humility to be honest about how difficult something was for me? I'm sorry my truthful assessment offends you. If humility means pretending things are harder than they are, then I guess I don't have any humility.

You seem kind of hooked up on the "easy for you" part, which really isn't the part anyone cares about. I can't even comprehend how you came to the conclusion that you are being asked to lie. Maybe a more constructive (humble?) approach would be to show others why it was easy for you, subjective as that may be, and how they can achieve faster comprehension levels based on your own experiences.

I'd like to see examples that start with a Java or JavaScript program, then try to translate them to Haskell and documents the thought-process of figuring out how the Haskell solution is and needs to be different.

Haskell aims to be a terse language, right? That's one reason that makes it difficult to "read" it and if you can't read it it's hard to learn it.

Think about learning to read and write Chinese when all you know is English. The only way to do it is to have a text-book that shows you sentences in both English and Chinese. I don't think it is necessarily "difficult" to learn Chinese, but you need learning materials targeted to an English-speaker.

Re: Why OCaml, why now? (2014)

#125

Post by frowaway001 » Sun, Feb 15, 2015, 6:34 PM UTC

MichaelGG wrote: post #105

lmm wrote: post #73

Earlier quoted context omitted.

I think most people who wanted a cross-platform, VM-based, corporate-ecosystem-integrated ML derivative with good concurrency support have already found Scala :P.

I've looked but not touched Scala. My impressions are A: Rather verbose. B: Carries a lot more OO/Java baggage. C: I've heard that the performance can be underwhelming.

A: Sometimes there is a small price to pay for gracefully unifying OO and FP (for example using sealed trait/case classes for ADTs, instead of having standard OO classes + a special additional ADT feature)

But it doesn't really matter. Some pieces might be slightly more verbose, but Scala is more concise in the long run, not because of saving some syntactic stuff here and there, but due to being able to express things which just aren't expressible in OCaml or F#.

If you want some shorter, more ML-like syntax, just pick a different parser https://github.com/lihaoyi/Scalite and have fun.

B: Unlike in OCaml/F#, OO is not "baggage". Scala took the good parts of OO and made them even better. OCaml/F# feel like the language creators tried to make a point about disliking OO by making OO support terrible on purpose. Scala demonstrates that having good FP support doesn't mean OO support need to be terrible.

Some of the stuff for Java support is a bit annoying, though, but doesn't matter in practice.

C: Performance is on par with Java. Scala can leverage the most powerful JIT-compilers and the world's best Garbage Collectors known to man. Does OCaml have working support for concurrency yet?

Re: Why OCaml, why now? (2014)

#126

Post by spyder81 » Sun, Feb 15, 2015, 10:19 PM UTC

wyager wrote: post #106

spyder81 wrote: post #101

Earlier quoted context omitted.

Whether we find it offensive or not isn't relevant. Your comments are degrading to those who find it difficult, and you are actively hostile when they complain or we point this out. Your attitude is one I see too often in the FP community, and well-meaning or not it holds us all back.

>Your comments are degrading to those who find it difficult Again, what do you propose I do about it? Should I never say anything positive about anything, lest I offend someone who had a bad experience? >Your attitude is one I see too often in the FP community Which attitude is that? Optimism?

> Should I never say anything

Well if you can't understand why your phrasing turns a positive idea into making somebody feel bad, probably.

> Which attitude is that? Optimism?

A version of it, yes. The "if you don't find it easy you are the problem" attitude.

Re: Why OCaml, why now? (2014)

#127

Post by spyder81 » Sun, Feb 15, 2015, 10:21 PM UTC

galaxyLogic wrote: post #124

bojo wrote: post #104

Earlier quoted context omitted.

You seem kind of hooked up on the "easy for you" part, which really isn't the part anyone cares about. I can't even comprehend how you came to the conclusion that you are being asked to lie. Maybe a more constructive (humble?) approach would be to show others why it was easy for you, subjective as that may be, and how they can achieve faster comprehension levels based on your own experiences.

I'd like to see examples that start with a Java or JavaScript program, then try to translate them to Haskell and documents the thought-process of figuring out how the Haskell solution is and needs to be different. Haskell aims to be a terse language, right? That's one reason that makes it difficult to "read" it and if you can't read it it's hard to learn it. Think about learning to read and write Chinese when all you…

That's exactly why most FP articles and tutorials around the net didn't help me, but Dan Grossman's "programming languages" coursera course did.

If (when) I ever learn enough to talk about why OCaml is better in detail, it will be with concrete examples not buzzword bingo :)

Re: Why OCaml, why now? (2014)

#128

Post by tel » Sun, Feb 15, 2015, 11:00 PM UTC

the_why_of_y wrote: post #118

tel wrote: post #13

Earlier quoted context omitted.

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

It has width subtyping on type variable constraint sets. For instance, `forall a . a` is a subtype of `forall a. C a => a` and the compiler will automatically make the conversion by adding the unnecessary constraint. You also get the whole covariant/contravariance bit arising (solely) from function types.

This is a subtyping relation and you can treat it like one (and even abuse it quite a lot if you like) but since it's not key to think of it that way to understand Haskell's polymorphism then most of the literature just ignores it.

Re: Why OCaml, why now? (2014)

#129

Post by vog » Mon, Feb 16, 2015, 9:22 AM UTC

p0nce wrote: post #116

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…

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…

Agreed mostly, but I beg to differ with your conclusion that this makes the coice of language insignificant.

The point of modern languages (name them functional or not) is to erade whole classes of bugs. Also, it is about making it simple to define good interfaces between components.

So at least your points "focus on quality" and "enhanced architecture" are directly influenced by the programming language. Of course you should train your people to focus on quality, but you also shouldn't make it too hard to get things right in the first place. Of course you should train your people to develop a sense for good architechtures, but you should also provide a formal language that makes it more natural to express their architectural and design decisions.

That way, your training can focus 100% on the real issues, rather than 5% on the real issues and 95% on how to apply them in your programming language, as you need lots of workarounds, wrapper classes and so on. And you don't only have to write them - others also have to read that bunch of mess, and reduce this to the "real point" in their heads. This may be considered a nice mental exercise, but in the end, it's just boring, prone to errors/misunderstandings, and a finally waste of time.

Re: Why OCaml, why now? (2014)

#130

Post by tome » Mon, Feb 16, 2015, 10:09 AM UTC

jonsterling wrote: post #85

peter-fogg wrote: post #84

Earlier quoted context omitted.

> 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 possibility of, e.g., using effects to implement a semantically pure interface. On the other hand, OCaml has actual effects, which can be used in an open-ended way to implement all sorts of functional interfaces. So, to be all pedantic and stuff... Y…

1. that's why I qualified it "proper". Of course there is unsafePerformIO, but in the presence of laziness, this is really unsafe . as opposed to ML, where doing IO may harm your ability to reason about stuff, but it won't be unsafe. Debug.Trace is also unpredictable; actually, it's perfectly predictable if you understand laziness, but it's still not what's really wanted in most cases. 2. ST is a single instance of a…

Could you say something about why `unsafePerformIO` is unsafe in the presence of laziness?

I know `unsafePerformIO` can be used to violate the type system in combination with `IORef`s, for example, but I don't see what laziness has to do with it.