Advanced programming languages (2009)

If you're really interested in learning a language for itself, rather than using it for some practical goal, libraries that are "just" bindings to some other language with radically different semantics don't really count as a positive. They generally end up non-native and a real pain to try to write "language-A in language-B", unless someone has taken the time to write a native-idiom wrapper around them, which is pretty uncommon. So for educational purposes, I'd only look at the pure-Scala libraries rather than "the JVM ecosystem". Or, similarly for Haskell, Haskell still AFAIK does't have a great binding to native QT or GTK or any other really good desktop toolkit. There are bindings, but you're writing C in Haskell at that point, which is definitely a pain, and not a great way to learn the language.

If you want to do practical things with the language, by all means count the bindings as an asset. It's still better to have a foreign-library binding to some capability than no capability at all, and it's not hard to imagine that using another language for some reason, even with the cost of the foreign-idiom binding, is still net cost/benefit positive.

Answering your second question:

Since you have experience with a statically typed language, you'll be fine with little no to Java knowledge.

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.

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.

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

I didn't have large problems with Haskell library availability until lately. I was attempting to see what some code from work would look like from work. It used:

Mssql, Cassandra, CSV, and MySQL

MySQL and CSV were no problem. The Cassandra bindings were bitrotted and I had to do a good amount of work fixing the Cassandra dependency and the thrift dependency it has. Mssql bindings through hs-odbc have an allocation error I haven't had the time or energy to figure out.

If I were using Haskell in production and not having mssql was a showstopper, I'd need to take the time to fix this library to with fix my immediate case and then continue maintaining it.

I found that Haskell Library support seems to be stronger in the technically Superior Technologies Department. For instance postgres support is quite a bit better than MySQL support.

It makes total sense that the Haskell Community would put more work into supporting technically Superior Solutions using their technically Superior language, but I fear that's biting off more than you can chew.

At home for instance I've been struggling with Linux issues rather than putting time into my side project. It would probably be a better economic choice to buy something with more seamless Hardware support like a Mac, and then be bleeding edge with my side project using Haskell.

Point being, if every part of your life is bleeding edge you'll just end up bloody and never going anywhere.

The huge difference between Haskell and the other two (that isn't in libraries) is that Haskell has controlled side effects, whereas side effects are uncontrolled in the other two (and virtually all other languages...)

That, at least to me, is way more interesting/important than libraries, which can always be ported or otherwise interfaced with.

Scala's JVM support can get rough. Many a developer had gone down the road of finding a library like a db driver and using it in Scala. This works fine until you deadlock your production system because your execution context ran out of threads because your db driver blocks.

So yes, while you can use Java libraries you often have to jump through a lot of hoops.

I can recommend Scala:

- It is mature and rock-solid, but still manages to evolve, fix issues and simplify/remove features. Most other languages are purely additive, meaning you will have to carry on all the baggage since the languages' inception.

- It is a language which is interested in identifying the best way to solve common programming issues and spares you with all this ideological "OOP/FP is bad" bullshit.

- It has the largest ecosystem (plus it can use all of Java's, too).

- It has the best tooling.

- It has the largest community.

- It has some great learning resources, like the three (or four?) Coursera courses starting in a few weeks.

- Its JavaScript backend is stable and production-ready, Scala-Native is being worked on.

> That said, I come from a C++ and Python background, so do I need to know Java well before learning Scala?

Java knowledge might reduce the amount of learning (as many Java things like the JVM also apply to Scala), but isn't really necessary. You will be fine.

Some would argue that not knowing Java would be a benefit to learning scala. It depends though, some scala codebases are very java-y and others are very un-java-y

I had zero background in Java, and I'm a very happy Scala developer for about two years now (still at the beginner level, though).

I'd say not knowing Java the language isn't a big deal. Also not a big deal, but certainly a point to consider, is Java the ecosystem. I can imagine Java pros bringing their knowledge regarding the JVM, threads, and other stuff, that's certainly a plus.

I've been writing Haskell professionally full-time since 2010. Before I started pursuing Haskell I looked into Scala, but it seems to be trying to embrace too many paradigms, which has resulted in a gigantic unwieldy language. In the 6 years that I've been using it professionally the Haskell ecosystem has matured tremendously. Obviously the third party library support can't be as good as popular languages like Ruby, Python, etc simply because of manpower, but I find that these days there is an open source package for just about everything I need. Furthermore, due to Haskell's purity and strong type system it is MUCH more likely that these libraries will work. It is also usually quite easy to make improvements when needed.

Knowing Java won't help you much in learning Scala. It's the functional programming parts that will trip you up if you haven't done that before, and this is the most valuable part to learn. I use Scala every day, and it was easy to learn; but I suspect that was because I did a lot of functional programming before that.

We write OCaml professionally. In case you find it useful to browse real world, battle-tested code, here's our main repo (there are others, but this is the largest): https://github.com/libguestfs/libguestfs There is an introduction/overview of the source here: http://libguestfs.org/guestfs-hacking.1.html

I would recommend Elixir or Clojure over Scala. In my opinion, Scala and F# suffer from supporting multiple programming paradigms, which means that people tend to fall back on the procedural or object-oriented programming they know, rather than learning how to do things the right way, functionally speaking. That has been my experience with them, anyway.

Reasonability. In an age where billion dollar companies are gutted by 16yo hackers on a monthly basis, it's worth the effort to build strong, secure systems that can be formally reasoned about.

2 things IMO

- There's a long running pendulum that swings back and forth from FP. We're currently in an FP cycle.

- Current mainstream computing puts a heavier emphasis on concurrency and distributed computing. FP's focus on immutability and referential transparency makes it easier to reason about these.

The usual explanation is that they're good for safe parallelism on multicores. Which are everywhere now - even phones.

A quick idea, as systems have become more complex, needing more threading and such to perform at scale, I think many developers are reaching for functional programming techniques to make the code easier to reason about.

I'm not a pure functionalist, but I recognize some nice things: immutable by default, composition instead of inheritance, chained operations/monads.

I've personally become a huge fan of Rust, while this isn't a pure functional language, it definitely inherits a lot from them, but it also doesn't force FP on you.

My guess is that it is a result of processors getting faster, memory bigger and compilers better (and GUIs more complex). Functional languages do have some performance penalty over highly optimised code directly manipulating memory but for most usages such performance is not needed. Thus programmers tend to trade some of it for clarity of code and safety.

They're not, really.

A couple of concepts have become trendy: composition and immutability.

The former is certainly a staple of FP but the latter, not as much (a lot of languages considered functional support both mutability and immutability).

> since the dawn of humanity

Since near the dawn of computing is more like it :), but I get what you mean. There was this early language by John Backus (yes, of BNF fame) called FP (sic), though Lisp may have been the first one.

It's been a trend for some years now (not just recently), due to reasons others here have said, such as multi-core, immutability, easier to reason about, etc. E.g. a friend of mine was in a startup that was using Clojure in production over 5-6 years ago.

Pure FP languages are still pretty niche, but what has happened is the big mainstream languages like C# and Java has adopted more functional features like higher order functions, lambda syntax, increased focus on immutability and so on. So functional languages are clearly trendy among the language designers, from where the inspiration trickle down to the mainstream.

Concepts that originated in functional languages have been slowly percolating to everyday use via dynamic languages, things like first class functions, map/reduce, closures, lambda etc. Bouncing these buildings blocks in your head for 10 years or so makes the rest of the FP concepts look pretty natural and a logical next step even if you're just joe programmer in the trenches.

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

"I personally would really hesitate before picking a language that will be hard to hire for to build a business around"

Unfortunately, this is HN so we know you're wrong:

http://www.paulgraham.com/avg.html

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, but it makes sense in theory. PHP is an easy language to find developers for, but it's incredibly annoying to figure out how competent the developers you're interviewing in that ecosystem will be. But languages like Haskell and Scala have a (perceived or real) barrier to entry, so you typically have a higher median ability among developers in those languages.

There's theorem provers like Coq. I'm pretty comfortable with Haskell, but concepts like the difference between Propositions and Booleans are enlightening to my Haskell the same way Haskell can be enlightening to use of other languages.

The language itself is not, but I would argue that the Wolfram Language has an advanced, advanced standard library.

Have you explored languages with dependent type systems such as Agda, Idris, Coq, or Twelf?

You could also explore languages from an academic perspective. Benjamin Pierce has written several high quality texts about topics in programming languages.

Well, there's:

- Dependently typed languages (ATS, Agda, Idris)¹ should be fairly familiar if you're a Haskell veteran.

- Array languages (APL, J, K, and more obscure ones like Nial) are pretty enlightening if you're a functional programmer (at least they are for me). Most of these trace to Ken Iverson and his Notation as a Tool of Thought. They are a bit brain-bending at first, largely because of the density, but they're fun to use and the density makes comprehension easier after a while.

- Function-level languages (FL, FPr, J) – a somewhat obscure and very advanced sister to functional programming. If you're familiar with Haskell Arrows, there are many parallels. They are, essentially, a more convenient point-free style. Most (all?) of these trace to John Backus (of Fortran and Backus-Naur Form fame) and his 1977 Turing Award lecture Can Programming Be Liberated From the von Neumann Style?

J (http://jsoftware.com/) combines array and function-level programming, and IMO is a very good language to learn to expand your horizons if you're a veteran functional programmer.

--

¹ Coq kinda, but it's more of a theorem prover than a programming language. Agda sort of fits that too.

Agreed with siblings: Agda, Idris and the like are one option.

You can try Curry or Mercury for Logic/Functional cross.

Shen for something with Turing-complete type-system (by design, as opposed to C++ templates).

Do you know any array language? Like J or K (or APL, though personally I never dared). I can recommend J as a better documented and easier to get into language.

Have you seen Avail (http://availlang.org)? It looks very funny at first, but it is incredibly expressive.

What about Factor and Cat/Kitten? Stack-based languages, the latter additionally statically typed.

Haskell and ML at least have advanced type systems. Since types are erased during compilation, you can't reason about type systems in terms of their impact on the generated code. An example of a simple type system is C with its structs.

Haskell also has lazy evaluation, which is very difficult to do in C. Obviously you could encode your own trampolines, but at that point you might as well be coding in a Turing tar pit language "where anything is possible but nothing of interest is practical".

Pattern-matching and ADTs are also usually difficult to do in other languages.

Most of the benefits of something like Haskell only show up on larger projects, so it's not meaningful to point to specific language features as a point against it. I can do just about anything in C. The type systems you probably can't do; you'd have to embed a language and that doesn't count.

* A lot of mainstream languages are syntactic skins on top of substantially the same semantics and skill in one is easily transferrable. A person skilled in C should be able to understand a Java program, but may find similarly high-quality, idiomatic Haskell totally inscrutable.

* The number and complexity of concepts with which you should be familiar are much higher. To tread water in most imperative languages, you need to find if/else, while, for, assignment, function call, and function definition. To tread water in these languages, you will generally need more.

* The idioms provided by these languages provide for and encourage code that is more expressive (says more with fewer characters) but may be more difficult to think about and write.

* All languages are equivalent in the sense that you can simulate them all by each other, i.e. by writing a compiler from X programs to lambda calculus expressions, and a lambda calculus interpreter in Y. This result does not imply that you can always express the same concepts in a reasonable, space-efficient manner.

I do have some nits to pick with the list, though. I would consider C++ advanced, in that there is a lot you need to know and think about to work with it.

Scheme itself is very simple: the entirety of its syntax and semantics can be learned by a laymen in an hour, and by the end of a semester first-year computer science students can write their own Scheme interpreters in Scheme. Its complexity is an emergent property of the kinds of abstractions it supports, not inherent to the size and complexity of its design like Haskell or Scala.

I've seen people recommending this book more recently: http://haskellbook.com/

I'm not sure I like LYAH as a practical resource: It's silly and might put people at ease, but I wouldn't feel comfortable writing a database or parsing tool or compiler after reading it.

Real World Haskell is better for these, but is a little dated by now.

Not to knock LYAH, but I personally think it stops at a place that would leave newcomers a little ill-equipped to work on haskell projects, considering there are concepts (like monad transformers) that nearly every modern haskell project is going to make some use of that aren't covered. Pedagogically, I think its great that it takes some of the intimidation out of learning something that could otherwise seem very alien and academic.

These days, I recommend the book "Haskell Programming From First Principles" [1]. It's still a work in progress, but its already probably the best haskell book available right now. Just be aware that its a bit lengthy (1000+ pages) and that many of the chapters aren't necessary for learning haskell, but may make the going easier.

I also highly recommend using Stephen Diehl's "What I Wish I Knew When Learning Haskell"[2] which covers a huge amount of pragmatic advice on style, library use, GHC extension use, etc.

[1] http://haskellbook.com

[2] http://dev.stephendiehl.com/hask/

Writing/deploying F# on a non-Windows machine is a huge pain. Been there, won't do that again.

Help us break away : nothing is inevitable, the future is unwritten!

And of course, it is not "untyped". It is dynamically typed.

Web based is because JSON is always easier with dynamic types.

Rapid prototyping is because it requires less explicit up front design due to dynamic types.

Artificial Intelligence is because metaprogramming is easier in homoiconic languages.

> web-based programming and rapid prototyping

Any dynamically-typed scripting language is good for that sort of thing. Scheme in particular is very productive because of its meta-programming capabilities and REPL-based development.

> artificial intelligence

"Scheme was created during the 1970s at the MIT AI Lab [...]"

https://en.wikipedia.org/wiki/Scheme_(programming_language)

Since Strong A.I hasn't been invented yet, I don't think anyone knows which language is best for A.I. Maybe it'll just be something boring like Java.

The article's 7 years old. Clojure's first stable release (1.0) was released the same year.

Scala has a very well-regarded implementation of Erlang's actor system. I have personally seen it handle hundreds of thousands of requests spun off as lightweight threads.

multiplayer tetris?

> Imagine English itself was a programming language

That's a terrible idea.

https://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffal...

Haha here was my personal intro to the world of haskell: https://www.youtube.com/watch?v=RqvCNb7fKsg . Was instantly hooked.

Yes, its first stable release (1.0) was around the same year this article was written.

Yes, that's exactly what I practice. My "breadwinner" language is C/Java/C++ at the moment because that is what others in the project know and that is what makes sense in the ecosystem the project is in, my sideproject language is Haskell.

I had a small server written in Haskell but since the other contributor familiar with Java/C/C++ was not able to pick at it effectively, we switched to Rust and we all were happy, and transitioning was fine.

At work I deal with Java code, but we have a framework we wanted to use that's written in Scala, and since Scala can interop with Java, we were all productively able to transition over for the better.

For a hobby project we use Objective-C, but we are starting to write some bits in Swift. Apple is especially effective at trying to convince the developers to change over to this shiny language.

I think "advanced" languages can be used in real world applications, and the transition experience from other well known languages can certainly matter.

Has anyone experience with "Curry" (functional logic programming)? If it has all the advantages of Haskell plus some possibilities of logical languages, it should be really interesting for experimental approaches.

http://www-ps.informatik.uni-kiel.de/currywiki/

idk if you are serious or not but part of me feels like the fact that those languages haven't gained much attention in the last 30 years means that they won't get much attention in the future.

You're lucky you didn't get voted down -5, with the Type Police out and about.

I like ES5 (would be ES6, but for IE support...) Javascript, but it is a bit light on the immutability aspect, given the environment and problem set it usually runs in.

Check out the "Ramda.js" library for JS (http://ramdajs.com/0.21.0/index.html). There's some good concepts put to use there. (although I have my own version of "currying" implemented at work, as I like to sometimes have "0 arity" functions for event handlers -- but those types of "functions" aren't particularly "pure")

Unlikely you'll be cranking out a Rails style MVP in Scala + Play, but you will produce a robust, blazing fast, scalable application that's a dream to maintain and build upon.

In short, Play is a really, really good MVC framework. For SPAs you can go lightweight with just Play's router and WS api, or try something like http4s for a more FP-based REST api.

Throw Scala.js into the mix and you've a got a fully typed stack across the board.

and then Scala Native on the horizon...things are looking good in Scala land ;-)

Scala can be a fine Java replacement, if you drop 20% of its features on the floor. As long as you never see a higher-kinded type, I think you are ahead of Kotlin, and the learning curve is not really any different.

The problem with this approach is that 90% of Scala libraries are built by people that live in higher-kinded land, and believe that since they have reached that level of expertise, so should everyone else, the second they start learning the language. For instance, look at SummingBird: The hello world example includes F bounded polymorphism, and path dependent types! Anyone new to the language would run away screaming, and I'd not blame them.

> Also I would argue that Scala is much better suited for writing compilers than Haskel.

Any examples of how it can help out?

Well said!

OP reeks of subjectivity.

"Scala is a rugged, expressive, strictly superior replacement for Java."

I have nothing for or against Scala, and Java is a popular target. But "strictly superior"? There are critiques of the language and its toolset that contradict the strictness of its superiority. (https://www.quora.com/What-are-some-criticisms-of-Scala)