Live data from Hacker News

Advanced programming languages (2009)

matt.might.net

21–30 of 208 posts

Re: Advanced programming languages (2009)

#21
post #12

This post is very fortuitous for me. I've been looking to learn a functional language and I had more or less narrowed my options to Haskell, OCaml and Scala. I liked the breakdown between these languages and the resources. Can anyone who programs in Haskell or OCaml regularly tell me the current state of standard and third party library support? I'm very attracted to Scala because it has JVM support, which sounds fan…

Ocaml has opam, a package manager, with currently 1227 packages in it. https://opam.ocaml.org/ The standard library of ocaml is quite basic, so usually, you use either Core (https://github.com/janestreet/core) or Batteries Included (https://github.com/ocaml-batteries-team/batteries-included) I personnally prefer Batteries because it tries to stay compatible with the standard library.

Re: Advanced programming languages (2009)

#22
I would argue that a well-known language is fairly expressive in the sense that it is well-known.

Imagine English itself was a programming language - this is the best. But for now I would recommend using those who are commonly used in the common platforms of interest (Java, javascript, C etc)

Re: Advanced programming languages (2009)

#23
post #12

This post is very fortuitous for me. I've been looking to learn a functional language and I had more or less narrowed my options to Haskell, OCaml and Scala. I liked the breakdown between these languages and the resources. Can anyone who programs in Haskell or OCaml regularly tell me the current state of standard and third party library support? I'm very attracted to Scala because it has JVM support, which sounds fan…

I've spent some time with both Haskell and Scala.

Haskell's big pluses are purity and rigor. Most functions can't affect external state; they can only return results. Haskell also has strict typing, which is great for catching mistakes up front, and takes most of the pain out of using it through really great type inference. Unfortunately the community around Haskell is very small, so if you use it for a project larger than one person you could run into hiring problems.

I wrote some more about the pluses and minuses of Haskell here: http://short-sharp.blogspot.ca/2016/06/should-you-use-haskel...

Scala's big advantage is that it works well with legacy code in Java. Unfortunately it straddles the boundary of OO and FP, and making both programming models work requires a large and complicated language. I'd prefer something simpler.

If we were to take another swing at FP, I'd look hard at Scheme and in particular at the Racket system. The big plus of Scheme is a certain elegance, which is very appealing. And lots of people have learned Scheme in school.

Re: Advanced programming languages (2009)

#25
post #15

I personally would really hesitate before picking a language that will be hard to hire for to build a business around. Yes, you'll be more productive in the short-term, but a business is more than just code and you will need to wear those hats too before you'll have enough understanding and resources to hire those out. At this point, I'm fairly certain your first hire should be someone to take the engineering load of…

Jane Street Capital's Yaron Minsky once said that contrary to popular belief hiring for OCaml developers was easier because the signal to noise ratio in the OCaml community is so much better than other, more approachable languages. He would send a job post to the OCaml mailing list, get 15 responses, interview 10 people, bring five onsite and ultimately hire three new people. I don't have direct experience with this,…

I've got managerial experience hiring (on both ends of the spectrum of talent) and engineering experience in computational finance at a prop firm similar to Jane Street. He has a fast-hire ability and high-signal to noise for sure but he works at a prop firm. His hiring practices are a market anomaly simply because he can pay effectively whatever a competent developer wants. Jane Street can basically throw money at the problem. What you have at a 'normal' company is a real difficult time finding someone who can tell me when to use a lens and when to use a zipper in Haskell who are actively looking for employment.

Anecdotal but I casually attend Boston Haskell and I can't remember the last time someone was out of work other than 'funemployment' (e.g. a startup goes bust and they have accrued more than enough money to just sit around, stretch and work on pet projects). The second they 'need' a job, they'll casually mention it and I think ~3 out of the ~7 times this has happened, someone in the crowd went like "oh Bill, yeah come in to Monday and meet our CTO". No recruiters, no wait. The CTO trusts Joe has heard Todd ask enough insightful questions consistently enough that he's going to be a good hire. Tuesday 9AM HR, 10AM pull the repo down, setup stack, start poking around Haddock and start closing the easy tickets. Good talent (10 of the 15 applicants are quality) might respond to Minsky but those other 9 guys will be picked up almost invariably in well under two weeks

Re: Advanced programming languages (2009)

#28
post #12

This post is very fortuitous for me. I've been looking to learn a functional language and I had more or less narrowed my options to Haskell, OCaml and Scala. I liked the breakdown between these languages and the resources. Can anyone who programs in Haskell or OCaml regularly tell me the current state of standard and third party library support? I'm very attracted to Scala because it has JVM support, which sounds fan…

There's a very good summary of the Haskell ecosystem here: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md

Re: Advanced programming languages (2009)

#29
post #7

Earlier quoted context omitted.

> you'll be more productive in the short-term I'm not so sure. One of the advantages of these more mainstream languages is the combination of an incredibly large selection of libraries and many people having already made the mistake you will make. This means when you run into an issue, there are already several posts on stack overflow about it, and you move on without issue.

The really interesting problems have the property that there is no library written for them yet. Granted, you need some kind of interaction with the outside world, but this is easy to handle in another language layer. The "existing libraries" are only going to be efficient if your entrepreneurship is based around the idea of rehashing or recombining existing tooling, which is already there. But far from all projects…

> The really interesting problems have the property that there is no library written for them yet.

But it's the reverse of that that's precisely the point though. If all the uninteresting problems already do have nicely packaged solutions, you get to focus on the interesting problem instead. The question then becomes: are you better off solving the interesting problems in better language at he cost of having to solve more of the uninteresting ones?

Post reply on HN