Hacker News Reader

Comment by Gyonka | Hacker News Reader

I agree with him in the sense that these are CS courses, and in in such a way Haskell ties together well with the math that one learns in a CS program. Keeping that in mind it makes sense to only have taught Java in courses specifically designed for developing software.

View on HN

I am looking forward to the day the notion that functional languages are not suitable for developing software will die.

It is not only that functional languages are more succinct, easier to reason about and are more readable, they also often come with significantly better type systems. Some have type systems sophisticated enough to specify nearly all the legal states and guarantee these are the only states the program can stay in at compile time. One can look at languages with dependent types for that.

On the more practical front, Erlang proved itself over three decades to be one of the best choices when it comes to fault-tolerant, highly concurrent systems. Jane Street is using OCaml for all of their trading software, Morgan Stanley has moved to Scala, and so on and so forth.

I suppose you are correct, although all the training I received for software engineering was in straight OOP Java. I really dislike java in general.

Now I write mostly in python and go, learning a bit of haskell.

That day will come, for many of us, when a large AAA game, web browser, or usable OS is written in a FP language.

And I realise that is an unfair target, but there is very little user facing FP software. The only one I can think of I have used is xmonad, which is both hard to use and fairly buggy

You mean like Crash Bandicoot, Abuse, Jak and Daxter?

Or maybe Genera.

Or maybe Remote Agent software used by Nasa Deep Space 1?

Or eventually the train control systems running on software from Siscog?

> You mean like Crash Bandicoot, Abuse, Jak and Daxter?

Huh, TIL:

http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

You can do functional programming in Lisp, but even the wiki page for GOAL says "GOAL encourages an imperative programming style". Not to mention most Lisp data structures being mutable if we're talking purely functional.

I have a problem with modern notions of purely functional.

My first functional programming language was Caml Light, back in 1996. Followed by Prolog and eventually Lisp.

All alongside traditional lambda calculus and logic proofs, with ocasional references to a programming language called Mirada.

So for me, Lisp is functional programming and I don't buy into this modern notion that only Haskell is the poster child of FP.

I looks like alayne is using 'purely functional' to mean Pure + Functional, but you are using it to mean Everything is an Expression / First-class functions, etc.. The functional paradigm.

Lisp is definitely a functional language. It's just not as pure as Haskell, which is the poster child for Maximally Pure FP, if not for the functional style.

Hence why I made the reference to Miranda.

We were already doing functional programming while Haskell was still using diapers.

Well, yes. Haskell is heavily inspired by Miranda. Haskell was just managed in a way that allowed it to become very popular.

Probably more like when Mozilla ships a browser written in Rust. Even though Rust handles low-level so well, it heavily uses FP concepts.

Meanwhile, this is good news for people creating startups or otherwise being competitive. Having advanced programming languages where your competition is mired down having to churn out 10x more code, is certainly a benefit. Although not every (many?) business really comes down to technical ability.

> Probably more like when Mozilla ships a browser written in Rust.

Actually I would rather see this happening, than the continuous effort on Firefox OS.

While Crash Bandicoot used LISP (which I wouldn't call FP, although definitions vary), it was only for a small part of the code (the AI), nowhere near all the game was written in lisp.

Not there at all (slower than the Pascal equivalent, limited to fairly simple games, and uses some C), but nevertheless interesting is http://cleangl.sourceforge.net/thesis/CGL.pdf, which describes a game library in Concurrent Clean.

(reading http://clean.cs.ru.nl and looking at the archives of the mailing list may give the impression the project died at the end of 2011, but http://clean.cs.ru.nl/Download_Clean has binaries from November 2014)

Xmonad is buggy? I've been using it for 4 years and never had a problem. I actually also use it on multiple displays.

Since I use Xmonad as my window manager, I'm rather invested in you elaborating on Xmonad being "fairly buggy". Should I worry about my data?

I found that several applications would cause it to go crazy (lock up), including many Java applications and open office. Further, if you started adding many extensions, they would cause crashes (I'm sure it's because they were badly written, but I thought the whole point of haskell was no crashes).

So, if you find nowadays Java apps and openoffice work fine (or, you don't use them), and you are careful about which extensions you add, then you will probably be fine.

Oh! I know what you are talking about and remember the issue. You had/have to add `setWMName "LG3D"' to the configuration since versions older than Java 7 don't include Xmonad on their hardcoded list of suppported window managers. Correct me if I'm wrong, but it doesn't seem like that one was Xmonad's fault.

Interesting, to be honest I don't really use any extensions. I do use Java apps and openoffice these days and they work fine.

Thanks for your response! I'll have to try adding some extensions and see what happens.

Neither Erlang nor OCaml bring with themselves the burdens of purely functional programming and the sophisticated type systems that you talk about. You also mentioned Scala and that one too is extremely pragmatic and lets you mix and match both OOP and functional concepts instead of sticking to purely one paradigm. Erlang is dynamically typed and OCaml does not mark side-effects with types and force you into the monadic context for all such side-effecting computations.

Purely functional programming still remains a purely academic exercise because it fetishizes type systems to the detriment of all other concerns in software engineering. Although I do enjoy some of the things that come out of that kind of work, e.g. parser combinators.

> Purely functional programming still remains a purely academic exercise

This is false.

Also, as far as I can see, only you mentioned pure functional programming. Sophisticated type systems do not mandate purity; see Scala for example.

There's nothing unfunctional about OOP. The two are not at odds. It's just frustrating when people confuse OOP with imperative programming and concludes that for sophisticated type systems to exist, all the lessons from OOP has to be thrown out. Imperative programming needs, to some degree, to be thrown out if you want programs that are easy for the compiler to reason about, but OOP doesn't.

Well there is something unfunctional about OOP, encapsulation of state and some implicit assumptions about mutability. Although I do agree that neither paradigm is at odds with the other. Scala demonstrates that there can be a fruitful interplay between both.

As for the existence of sophisticated type systems I again don't disagree with you. I'm having a lot of fun playing with TypeScript and mixing and matching dynamically and statically typed portions of my code. I'm looking forward to see where that line of work leads because it is an extremely pragmatic approach to type systems and helps me program instead of adding unnecessary cognitive overhead.

Yes, how statically-typed languages deal with dynamic data is one of the interesting features of type systems. In C for dynamic types you resort to void *, in Go it's Interface{}, but in OCaml you can construct a type that identifies exactly what you need.

Reply on news.ycombinator.com