Hacker News Reader

Comment by minimax | Hacker News Reader

I was thinking about this the other day and I think it generalizes beyond any specific language. I'm pretty sure every time I have learned a new programming language I came away a better programmer. Different programming languages (and their standard libraries) suggest that you approach problems in different ways, and that has real cognitive benefits.

I was actually trying to think if there was ever a case where I had spent time learning a language (or library) that didn't pay some sort of dividend in terms of increasing my skill as a programmer.

View on HN

There's not much value in learning programming languages that are similar. If you learn Ruby, you already know pretty much everything there is to know about Python. If you learn Java, you already know much about C#. The only real value you can get out of learning new mainstream languages is from learning the architecture of popular libraries. Like when I was inspired a few years ago to do database migrations after I played around with Rails.

So you end up learning from the libraries written in those languages, not the languages themselves. It isn't a bad outcome, especially since learning a new language that's similar to something you already know becomes second nature and doesn't take too long. It takes me something like 2 weeks to learn a new language.

Haskell is on a whole new level though. I don't know Haskell, but in the last couple of months I've been building stuff with Scala and lots of functional programming related idioms, both for personal stuff and for our startup and I've learned more than I learned in the last 5 years. There's lots of good stuff to learn in the Scala ecosystem, like how to build rock solid pieces of functionality with referential transparency, how to work with Futures/Promise, how to do concurrency with shared-transactional memory, how to do non-blocking and safe I/O using Iteratees, how functional data-structures are designed and so on.

Of course, Scala is tainted by its hybrid and JVM-related nature. It's much too easy to cheat if it's easier than alternatives that are referentially transparent and even if your interface is pure, that interface is probably wrapping something which isn't pure. In practice it works great for building stuff, but unfortunately I'll have to take the plunge and learn Haskell to be able to take my knowledge to the next level.

One example where Scala falls short is in its implementation of lazy data structures. You see, even though Scala does have really good lazy data structures, it cheats here and there because it makes sense to do so ... like for instance a Stream is a lazy list and it does behave lazily, except when it doesn't. sort() on a lazy stream is actually implemented eagerly, which means algorithms using sort() will not have the complexity characteristics of lazy algorithms. There's nothing stopping one from implementing a lazy sort() in Scala, but it's probably not going to have any benefits so people don't do that. That's actually the reason why I want to learn Haskell, because the best implementations for lazy data-structures and algorithms are written in Haskell.

Many idioms that people use now in Scala or in other languages have been used in Haskell since years ago. Like Iteratees or type-classes.

I agree that there is pedagogical value in forcing yourself to write programs using only immutable data structures, but I don't think it's a restraint we should impose on ourselves for real world day-to-day programming. You aren't "cheating" if you've evaluated several ways of writing a program and you really think mutable local state is the best way to do it.

Also lazy data structures are built into many mainstream programming languages. Python generators are the first example that comes to mind. I think you are probably excited about Haskell because it incorporates lazy evaluation which is a separate concept.

Not only is that not cheating, it's actually completely reasonable in Haskell too! You can use ST to have as much mutable state as you like; the awesome thing is that the state is guaranteed not to leak--from the outside, the function is just as deterministic as one that doesn't use mutable references and data structures.

The big idea about Haskell isn't to avoid all state. Not at all. The big idea is to control state. Haskell expects you to use state if it makes the logic clearer or the code much faster.

What you do not do in Haskell is use state for program organization. You avoid global state as much as possible. This means that communication between disparate parts of your program are explicit--you don't have implicit dependencies everywhere. This is definitely a good thing.

I think one of the problems is that people without much experience in Haskell interpreter "purely functional" too strictly. It just means you do not have state by default; you can still use it where it makes sense.

The good thing about not having it by default is that it forces your program to be simpler and more decoupled and it lets the compiler and libraries make many more assumptions about your code. All sorts of awesome features like STM and data parallel Haskell depend on having this sort of control over side-effects. But that's all it is--control. You can still have state and side effects; however, unlike most other languages, you can also not have them.

On immutable data structures, a language like Scala makes it really practical to use only immutable data structures in daily programming. My own code is full of immutable data-structures, except in instances in which I have to process stuff returned by Java libraries and even in those cases I wrap them in Scala's immutable interfaces (note, I'm talking about Scala and not Haskell only because it's the language I know).

The only problem is that many times you need mutable references to immutable data-structures, with no easy way out and this is where you can still have problems with side-effects and multi-threading. But dealing with such references is easier, because (a) you tend to do it less and less often and (b) you can use STM or just plain atomic references or @volatiles, as in many instances you need to just ensure the visibility of updates and you only really need locks only on writes. Also, I tend to encapsulate and hide really well pieces of code that deal with mutability.

A good standard library of immutable data-structures is very practical for day to day use. I wasn't talking about immutable data-structures though, as the data-structures themselves are only a small part of the puzzle. Much more difficult is to deal with inter-modules communications, processing streams of data, I/O and stuff like that. And that's also where things break and where I feel the urge to look for better techniques.

On lazy data structures, Python is an awful example.

The point about learning Haskell in particular is that it's a way different different language. It's a single language that gives you exposure to a lot of new ideas: purity, laziness, modern type systems, functors, monads, monoids, etc.

The massive difference though gives people like me, who've never done anything like Haskell before and do not properly comprehend it some real trouble though. It's similar to assembler. At first, you don't understand how the code works, how the logic is implemented, and everything just seems strange. Then you start looking at it as seperate commands to the processor and suddenly you understand. Sudenlly MOV r1,0x90 start: MOV A,#0x04 INC A DJNZ r1,start makes sense to you.

Sorry, I started fantasizing about Assembly again, my actual question was: "If you could find a metaphor that describes how Haskell works with Data, what'd be that metaphor?"

All of these exist or can be implemented in other major functional languages.

> I'm pretty sure every time I have learned a new programming language I came away a better programmer.

You might want to think a little bit about the fact that you are predisposed to believing that your efforts are not wasted.

If you spend the time to learn a new programming language, you're then predisposed to believing that it wasn't a waste of time, and are thus susceptible to confirmation bias, which causes you to ignore all evidence to the contrary.

Reply on news.ycombinator.com