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

91–100 of 132 posts

Re: Why OCaml, why now? (2014)

#91

Post by frowaway001 »

aphexairlines wrote: post #89
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.

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

Re: Why OCaml, why now? (2014)

#92

Post by bojo »

wyager wrote: post #69
paulrpotts wrote: post #42

Earlier quoted context omitted.

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…

>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 No, but hopefully it well help people who have yet to learn Haskell that not everyone thinks it's particularly difficult. I'm not interested in convincing the people who've tried and given up on it. >That's great, but to people for whom they don't come so easily, this cou…

Maybe consider a little humility first.

Re: Why OCaml, why now? (2014)

#93

Post by swhipple »

wyager wrote: post #69
paulrpotts wrote: post #42

Earlier quoted context omitted.

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…

>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 No, but hopefully it well help people who have yet to learn Haskell that not everyone thinks it's particularly difficult. I'm not interested in convincing the people who've tried and given up on it. >That's great, but to people for whom they don't come so easily, this cou…

So what do you propose? That I pretend it's really hard for me, even though it's not? What effect do you think that's going to have?

Again, what do you propose? Lie and tell people that it's super hard, so I don't hurt their feelings if they can't figure it out?

I don't anybody is suggesting lying about your own personal experience with Haskell. Rather your posts state that it was easy for you and that it should be relatively easy for everyone.

I think that when programmers from other languages are having trouble figuring out how to write a particular program in Haskell, whether it be due to documentation, the behavior of the code execution, or even language syntax, it doesn't make sense to claim that it should be relatively easy for them.

In my (limited) experience with Haskell, there can be hang-ups that someone with experience in strictly-evaluated languages isn't expecting. [1]

[1] https://wiki.haskell.org/Iteratee_I/O#The_problem_with_lazy_...

Re: Why OCaml, why now? (2014)

#94

Post by tel »

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…

I would love to talk to you a little about these kinds of things. I've been digging more seriously into OCaml the last few weeks and would love some signposts for making the Haskell->OCaml transition.

Re: Why OCaml, why now? (2014)

#95

Post by tel »

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…

I would love to talk to you a little about these kinds of things. I've been digging more seriously into OCaml the last few weeks and would love some signposts for making the Haskell->OCaml transition.

Re: Why OCaml, why now? (2014)

#96

Post by wyager »

bojo wrote: post #92
wyager wrote: post #69

Earlier quoted context omitted.

>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 No, but hopefully it well help people who have yet to learn Haskell that not everyone thinks it's particularly difficult. I'm not interested in convincing the people who've tried and given up on it. >That's great, but to people for whom they don't come so easily, this cou…

Maybe consider a little humility first.

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.

Re: Why OCaml, why now? (2014)

#97

Post by wyager »

aphexairlines wrote: post #90
wyager wrote: post #64

Earlier quoted context omitted.

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.

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.

Re: Why OCaml, why now? (2014)

#98

Post by jonsterling »

tel wrote: post #94
jonsterling wrote: post #85

Earlier quoted context omitted.

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…

I would love to talk to you a little about these kinds of things. I've been digging more seriously into OCaml the last few weeks and would love some signposts for making the Haskell->OCaml transition.

Hi! Please feel free to email me at any time. I can't promise that I will know everything you want to know (since I only know very little), but I would be happy to help with what I do know. jon [at] jonmsterling [dot] com.

BTW, I looked at your OCaml stuff yesterday, and it seemed pretty cool.

Re: Why OCaml, why now? (2014)

#99

Post by jonsterling »

spyder81 wrote: post #82
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…

Thanks! (I'm the author). I focussed on JavaScript because it's what I know, it's my day job, and I wanted to share a bit of my research while trying to introduce AltJS to it. I wasn't (and am still not) really enough of an expert in either Haskell or OCaml to talk about other differences; including a bunch of dot points I don't understand wouldn't help anyone :)

Hi! Thanks for writing the post. I didn't mean to criticize you for talking about what you know; I hope I was able to help give a broader perspective on some of the other issues at hand too. :)

Re: Why OCaml, why now? (2014)

#100

Post by jordwalke »

jonsterling wrote: post #80
jonsterling wrote: post #63

Earlier quoted context omitted.

After numerous discussions with Bob Harper (and reading Derek Dreyer's work, who has been the biggest proponent for applicative functors), I have come to understand that there are only two compelling use-cases for applicative functors: 1. higher order functors. 2. modular type classes Higher order functors are kind of cool, but IMO Standard ML does not seem to be suffering too much from the lack of them. I'm not too…

lps25: > Consider the case of a set implemented as a binary tree. The type of such a set should be parametrised by the type of the elements and the ordering used. With applicative functors this is the case as your set type will be `Set(O).t` where `O` is a structure containing the type and the ordering. With generative functors each individual set type is abstract -- so the type itself is not parameterised by the ord…

>> since otherwise, you can just bind the result of the functor to a structure once..

My understanding was that of lpw25's. I wanted to use applicative functors in the same way type classes (or OCaml's modular implicits) would make use of them, but even without type class's implicit resolution (explicitly specifying them). I agree there isn't too much difference from doing the same with generative functors, but the main difference is, as you said, I would need to find a place (some appropriately accessible location in the namespace) by which to access the result of these generative functor applications, and that's just an extra point of friction (if I understand correctly). It's not the end of the world as you said either way because we can do either.

Thanks for the help, jonsterling/lpw25.

Post reply on HN