The Story of Haskell at IMVU

https://chadaustin.me/2016/06/the-story-of-haskell-at-imvu/

by adamnemecek • 10 years ago

210 165 10 years ago

chadaustin4• 10 years ago

Hi! Author here. Let me know if you have any questions.

Andy, the same Andy mentioned in the article, wrote a blog post in 2014 with his perspective of what it's like to use Haskell in production, if you're interested. https://engineering.imvu.com/2014/03/24/what-its-like-to-use...

rakpol6• 10 years ago

Hoping for a little advice: I'm trying to push for some development culture changes at work, one of which is doing more local, incremental refactors rather than large, all-at-once changes (i.e. the sort of thing for which one books 'architecture meetings'). Since we'll hopefully be massaging large parts of the codebase, there's an opportunity to jump into something new with both feet.

Question: what do you think of the thesis of pure4j [1] vis. frege [2]? Namely, are the advantages gained by switching to a haskell-like language far above those attained by simply forcing effects into a small part of the codebase?

[1] https://github.com/pure4j/pure4j

[2] https://github.com/Frege/frege

codygman4• 10 years ago

I can't speak for pure4j, but I would be very wary about suggesting Frege at my workplace to (what I'm assuming are) Java programmers.

I feel like some Java programmers would have almost as much culture shock with something like Haskell as some of the php programmers at IMVU apparently did.

pron24• 10 years ago

You may want to consider http://www.ocamljava.org/ instead of Frege.

chadaustin4• 10 years ago

Personally, I think you'll have more success with something more gradual than a complete syntactic overhaul. I've never used pure4j or frege but it sounds like pure4j is something you could try out incrementally, which could be quite immediately useful for your team.

Best of luck!

Buttons840• 10 years ago

Scala is an obvious option as well. I haven't used Scala but it's surely more palatable to Haskellers than plain Java.

Also. There is work underway to enable GHC to compile for the JVM.

rjtobin2• 10 years ago

Not relevant to this particular blog post, but I just wanted to say thank you: one of your old projects, Sphere, had a big influence on me as a young programmer (in my early teens), and is a big part of why I got into programming. SCons is also awesome. I'm glad to see you are still doing cool stuff :)

chadaustin4• 10 years ago

Super cool! Glad I could help! Isn't it hilarious how almost everything you could do in Sphere is actually quite easy directly in browsers these days?

Bromskloss• 10 years ago

I'd love to take your course on Haskell. :-)

majewsky2• 10 years ago

I'm just learning Haskell through a university course. It's quite traditional in the author's nomenclature, with extensive discussion of laziness, currying and point-free notation.

But it introduces monads very similarly to how he did it: starting with Arrays, drawing parallels to Maybes, then introducing Control.Monad.State through an assignment before moving on to IO. This has helped me a lot in grasping the concept behind monads.

cmrx64• 10 years ago

Great read. I love it when oral history in our field gets recorded. One of my great fears is that more interesting stories than not will be lost to time.

wyager• 10 years ago

Good read! We've had a few good "haskell in production" articles recently. Hopefully this encourages some folks to try it.

mmbaghdad• 10 years ago

Nice read, you encouraged me to give haskell another round.

douche5• 10 years ago

Interesting, especially about the cultural division and politics.

Something to think about, since I'm thinking of swapping out some problematic C# code for F#. Pattern matching and a stronger, more expressive type system would be very nice. F# isn't as far off the reservation as Haskell, but I'm not sure how well throwing a monkey wrench, at the team will go.

louthy5• 10 years ago

Moving from C# to F# is much less politically difficult than moving to Haskell. For a start the framework they're on is the same, and actually, you can write object oriented F# that looks almost the same as C# (not that I would advise that, I prefer to use the OO side of F# as a last resort).

I'm the CTO at my place of work, and our primary app is C#. I wanted to tame some of the excesses of the language, and started looking at Haskell - I knocked up a few small projects with it; got it talking to the C# app through RabbitMQ, all happy days. But a few months later I came back to the projects to find they had rotted because of cabal. Some projects I found it next to impossible to recover. That left a pretty sour taste, which was gutting because I loved the language.

Then I took a look at F#. It's not as impressive as Haskell as a language, but it really does sit in that sweet spot for 'fitting in' to a big project environment. I've found that creating satellite projects to our core app in F# has been the perfect way to go. It's moved the team into that mindset slowly without having to force the issue.

douche5• 10 years ago

I've found that creating satellite projects to our core app in F# has been the perfect way to go

Can you elaborate on how that is laid out? I've identified some existing C# code in various of our current projects that could benefit from conversion to F#, but I'm not sure how the resulting projects should be structured.

elcapitan3• 10 years ago

To have the equivalent outside the .net world, there could be a Ocaml for JVM, that would allow to fall back to a ecosystem of libraries and toolchains. I think there have been some experiments to do that, but not a finished one to my knowledge.

ayberkt8• 10 years ago

It makes me sad how people think imperative programming is a "natural" way to think. I have known lots of people who resist using functional languages for serious projects, marginalizing the "functional" way of thinking as though thinking in terms of "labeled boxes with data in them" (Von Neumann architecture) is some sort of more normal way to think.

Before computers people modeled the real world using a Haskell-like pseudocode called "mathematics".

douche5• 10 years ago

Or a imperative-esque pseudocode called "instructions" or "recipes". Claiming primacy for mathematical modeling is not a priori the answer.

ayberkt8• 10 years ago

The recipe analogy is certainly very natural, but it does not extend as we get into things like assignments and references, which are a crucial part of Von Neumann languages (which is really the thing I am criticizing).

Tactic languages in theorem provers like Coq are stateful too: you have a proof state and you keep giving instructions for it to change. I wouldn't say that this is an unnatural way to think; for that subtask of the problem, we can view the proof as something with state without any problems.

"Mathematical modeling" sounds too sophisticated to be natural for humans. Let me illustrate what I meant; the kind of naturality I was talking about is this:

sorted(xs): a permutation xs' of xs such that, as we traverse xs' each element is greater than or equal to the previous one.

This is a perfectly fine sorting algorithm. It contains all the information we need to sort a list of comparable things, and it is very unlikely to contain an error; it is the _definition_ of sorting.

There are righteous performance concerns about this but ignoring all performance issues this is still more natural than listing out the steps needed to carry out the task of sorting. I don't think it is possible come up with a simpler recipe-like algorithm for this task.

There are recipe-like tasks in programming: ones that don't involve modeling the world; for those the functional paradigm would not be a good one. But these are rare if you are doing programming the right way.

pron24• 10 years ago

But in a way, imperative is more natural, because it captures the notion of computation more precisely. Haskell -- like other pure FP languages -- is built around the approximation of denotational semantics, which does have a bit of a mismatch with computation (not to say it isn't extremely useful much of the time). Anyway, mathematical thinking about programs didn't start with PFP, nor is PFP the most common way of formalizing programs. See:

http://research.microsoft.com/en-us/um/people/lamport/pubs/s...

I believe that the best way to get better programs is to teach programmers how to think better. Thinking is not the ability to manipulate language; it’s the ability to manipulate concepts. Computer science should be about concepts, not languages. But how does one teach concepts without getting distracted by the language in which those concepts are expressed? My answer is to use the same language as every other branch of science and engineering—namely, mathematics.

It makes me sad that some PFP enthusiasts enjoy the mathematical aspects of it -- as they should -- yet are unfamiliar with the more "classical" mathematical thinking. I think it's important to grasp the more precise mathematics first, and only then choose which approximations you'd make in the language of your choice. Otherwise you get what Lamport calls "Whorfian syndrome — the confusion of language with reality".

ayberkt8• 10 years ago

Thanks for pointing this out!

Dijkstra, in his "on the cruelty of really teaching computing science" makes a very similar point that people should learn how to reason about programs before learning to program.

This is why dependent types are a great framework to program in. If a program is worth writing, it should at least contain everything the programmer thinks about the program, including the reasoning of why it is the program he wants to write!

oggy• 10 years ago

Haskell -- like other pure FP languages -- is built around the approximation of denotational semantics,

Interesting, do you have any references for this? I thought that the primary reason for purity was to enable equational reasoning, but I have no sources for this. Also, AFAIK, there are no formal semantics for Haskell?

technomancy2• 10 years ago

If you view it in terms of psychological development, understanding concrete imperative steps happens before children are capable of understanding abstract concepts like mathematics. The works of Seymour Papert describe how these findings relate to education.

That said, people who connect this to software in a professional context are doing a disservice since hopefully software professionals have progressed in their intellectual development beyond their teens and are capable of abstract mathematical thought.

pron24• 10 years ago

Concrete imperative steps are extremely mathematical -- even elegantly so -- and most of software verification is predicated on this idea. Just like you can describe physics pretty precisely with simple math, you can do it with computation. The math of PFP is one particular approximation, chosen for its supposed utility as the basis for a language. It is more linguistic math than descriptive math. I also hope people adopt abstract mathematical thought when reasoning about their programs, but that has little to do with the kind of math they choose to model their programs' source code with.

ayberkt8• 10 years ago

That's a great point, thanks! I will look into Papert's work. Are there any specific papers/books you would recommend?

chadaustin4• 10 years ago

I find both mental models useful. For example, "accumulate all of the monoids in this collection" (https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-F...) makes total sense as a functional operation. You have a collection and some pure operations you want to apply to combine it all into one thing.

But then, sometimes you just want to iterate across a list of directories, read some files, and put some results in lists. Tail-recursion here feels dumb. Like, dammit, I'm the human and you're the computer, I know you can turn a sequence of instructions into a tail recursive loop for me, so don't make me think.

Haskell, due to its effectful / monadic vs. pure syntax distinction isn't terribly great here. Ideally I'd write all of my code in an "imperative style" all the time, but a row-typed effect inference system would determine which functions were pure, or in IO, or async, or in ST, or threw exceptions, etc. Koka [1] is an interesting language that explores some of these ideas.

[1] http://research.microsoft.com/en-us/projects/koka/

johncolanduoni4• 10 years ago

Some other projects that are doing cool things in this space are Idris[1] and F-Star[2] (the latter is also a Microsoft Research project). I am particularly impressed by Idris's algebraic effect approach, since it gives you a general effect system that combines the ability to easily extend that monad transformer approaches provide with the ease of use and inference of F*'s effect system.

I think the theory behind algebraic effects is a key step in making it easy to develop code with more stringent and customized safety properties than is available in languages like Rust.

[1] http://www.idris-lang.org/ [2]: https://www.fstar-lang.org/

ayberkt8• 10 years ago

That is definitely right. For things involving the machine, doing things declaratively is wrong.

Also, thanks for telling about Koka. It sounds very interesting!

tome13• 10 years ago

Ideally I'd write all of my code in an "imperative style" all the time, but a row-typed effect inference system would determine which functions were pure, or in IO, or async, or in ST, or threw exceptions

Yes, this would be a really nice approach (and it's not one that Haskell lovers would be upset by, BTW).

daxfohl3• 10 years ago

Agreed, I just recently took some recursive F# code from a photobooth (display countdown, async sleep, take photo, download from camera, recur with new byte[] list)->reverse list, and rewrote it it an imperative loop appending to a normal List<byte[]> and the code is much more intuitive.

Some things are more intuitive as a list of things to do and changes to make.

Zpalmtree• 10 years ago

I find writing recursive code is often very short and easier to read and show intent than the same code written non recursively.

joe_the_user2• 10 years ago

Before computers, far more people did bookkeeping or followed recipes or read sheet music than did abstract mathematics. I think one can reasonably say that lists of instructions that change mutable variables/objects is one of the most natural ways people can operate. Anyone learning a task essentially does this in the real world. It may indeed be terrible when done at a large scale. But there are a lot of people who can naturally understand these.

Immutable data may be a great idea. But is it the first that occurs to anyone? I have an MA in mathematics and the idea of mutable variables never seemed strange in the process of learning to program.

But even more, for a lot of people, even algebra isn't a natural way of thinking. What's natural is a series of instruction about how perform arithmetic. Learning what an abstract variable means is a hurdle for a lot of students.

The thing is that "natural", in this context, just means "what occurs to you first, all things being equal".

You may have a good and correct argument that learning Haskell is the right way to do things, that the costs of learning are more than exceed by the benefits.

But I don't think you can argue people into having functional approaches be the first thing that occurs to them.

dasil003• 10 years ago

I think it's impossible to disentangle the reality of common programming languages and how they work from what is inherently more "natural". The bottom line is programming is not natural, not in any way shape or form. It's hard to learn imperative programming, it's hard to learn functional programming, and it's really hard to learn object-oriented programming (well). If all languages were functional I don't think that would really be harder than learning BASIC, people would just accept that is what programming is and get on with their lives.

I acknowledge that imperative programming is more analogous to real world tasks, but then as soon as you try to write your first program you run headlong into the fact that programming is nothing like other tasks you have done before. The tricks you have to learn to make imperative programming work are not really any easier than the tricks for other paradigms, and in fact you can mix and match from various paradigms to great effect (see: ruby).

plafl2• 10 years ago

I have a cup of coffee, if I drink a little I don't think a new cup of coffee with less coffee has been created, just that the old one is different. There are some times where imperative thinking seems more natural.

elcapitan3• 10 years ago

I guess that applies to most programming paradigms. Their metaphors rapidly break down if you want them too.

I also don't send a message to the cup of coffee to reduce the amount of liquid that is in it and pass it a PourIntoMouthStrategy object to act on.

lmm7• 10 years ago

I think in a block-time model of the world. The coffee cup now and the coffee cup a minute ago are different things; my memory of the coffee cup a minute ago doesn't suddenly have less coffee in it.

greydius2• 10 years ago

There are some times where imperative thinking seems more natural

This is certainly true. But there are also times when there is nothing natural about it at all. Consider this scenario:

I give you a cup of coffee. You set it on your desk to cool. Then when you go to take a sip, the cup is empty! You see, I gave you the same cup I was drinking from.

pyrale• 10 years ago

Cue philosopher riot !

http://existentialcomics.com/comic/64

kmiroslav5• 10 years ago

Well, you don't get to decide what people find natural, they do.

And deep below, computers work under a model that's anything but functional (assembly language is basically a big mutable state machine).

There is value in understanding both imperative and functional programming and applying each of them wherever they are the best fit and there are some real world situations where sticking to immutability is a terrible choice (e.g. neural networks).

Koromix• 10 years ago

Programming is about making a piece of hardware do what you want to do. Many people seem to forget that, or treat it as an afterthought. "Oh yeah, it's slow. Hopefully the compiler will do its magic!". Except it does not, because it cannot rewrite your code to match what the hardware wants.

This is why we now live in a world where many programmers don't think there is a problem with running web servers on programming languages that slow down computation by orders of magnitude, in addition to being very cache and memory inefficient. We can scale! Yeah sure, use 50 servers where one could have done it. We would also use Saturn V to launch small individual LEO satellites, you know. Why not? It works!

Taking a functional approach is fine for a lot of tasks, and when you can do it without cryptic or inefficient code, you should do it. But when imperative is easier, use that instead.

tome13• 10 years ago

And deep below, computers work under a model that's anything but functional (assembly language is basically a big mutable state machine).

Acutally, deep below a computer is a massive asynchronous electronic circuit. Your "big mutable state machine" is an abstraction, just like any other.

ayberkt8• 10 years ago

You seem to have completely misunderstood my point.

Well, you don't get to decide what people find natural, they do.

I am not contending that functional/declarative is a more natural way to think; I am saying that there is nothing inherently more natural about imperative programming. Since the latter comes from imitating the machine architecture up in the abstraction hierarchy, we should consider for a moment if this is really desirable.

And deep below, computers work under a model that's anything but functional (assembly language is basically a big mutable state machine).

This is entirely irrelevant. Computers are highly stateful but the languages we design don't have to be stateful because of this. They have to meet the criterion of easily expressing the mental constructions we designate which I would definitely say is much better handled with statically typed functional programming languages.

There is value in understanding both imperative and functional programming and applying each of them wherever they are the best fit...

We completely agree on this! Not all problems are best solved with functional languages (e.g., things actually involving the machine).

there are some real world situations where sticking to immutability is a terrible choice (e.g. neural networks).

I don't see why immutability is a terrible choice for neural networks? Could you elaborate on this? It might be that almost all neural network implementations have been imperative so you have come to accept that as more normal.

kmiroslav5• 10 years ago

It's refreshing and uncommon to see someone who sees value in PHP, Java and Haskell at the same time.

Nice to see open mindedness about languages for a change.

MustardTiger11• 10 years ago

Where are you seeing that? "PHP was not usable" doesn't sound like seeing value in it.

yawaramin4• 10 years ago

The value was it came with less drama among his colleagues.

todd8• 10 years ago

I like Haskell, perhaps because of my strong mathematics background. My dilemma is should I spend more time developing my Haskell skills or should I spend some time with the new C++ features, or learning Rust, or just programming in the languages that I am already productive in?

When I assess a programming language, one of the questions I ask myself is "How will this programming language help me write correct programs?" In more detail I want a language that helps with four goals related to the ability to produce programs that achieve their specifications:

(1) Partial correctness: the program doesn't give wrong answers

(2) Total correctness: the program does (1) and doesn't deadlock or get stuck in an infinite loop. It eventually produces a correct answer.

(3) The program does (2) within the desired performance bounds specified.

(4) The program does (3) while making efficient use of hardware.

Haskell definitely helps with (1). Reasoning about the partial correctness of Haskell programs is easier than it is with imperative programming languages. Total correctness is very hard, especially with multi-thread, multi-process, or multi processor programs, but I think that Haskell is helpful here as well.

The real problem is that Haskell makes (3) and (4) very difficult to understand. Some of this is that compilers for functional programming languages are magic, making it hard to reason about what they are doing. This is further aggravated by Haskell's non-strictness.

A discouraging look at Haskell: "Why Is Haskell Used So Little In The Industry"[1] and "Disadvantages of Purely Functional Programming"[2]

[1] http://flyingfrogblog.blogspot.co.uk/2010/05/why-is-haskell-...

[2] http://flyingfrogblog.blogspot.co.uk/2016/05/disadvantages-o...

seagreen2• 10 years ago

  Citing Credit Suisse and Standard Chartered is just 
  name-dropping big banks in the hope that it will deceive 
  people into thinking that these institutes are seriously 
  invested in Haskell. They are not.

Lol, Standard Chartered is hiring like 30 haskellers _this year_, and I'm pretty sure they were heavily invested in Haskell in 2010. That writer of that article has an axe to grind, and is twisting facts to suit it.

seagreen2• 10 years ago

Update: sorry you're getting downvoted, that's not me. I think worrying about the predictability of performance is perfectly reasonable, especially in the presence of lazy evaluation.

tome13• 10 years ago

Jon Harrop has some ... "interesting" views on Haskell.

MustardTiger11• 10 years ago

Jon is a professional troll. He's done the same nonsense with lisp, ocaml, F# and haskell. And just as with all his other trolling, very little in those posts is accurate.

dhab• 10 years ago

I have programmed in Java for some time now, and I have only recently dabbled in the functional world (Haskell, and still ways to go before getting any better in it). My observations about it is that functional programming in typed and immutable world, provide better composability, reusability, terseness and maintainability. It does have it's drawbacks - Haskell is known to be difficult for estimating complexity, and i think it lags in many benchmarks.

I think OO can be thought of as an extension of functional programming, except it has some fancy names and idioms (single responsibility principle, polymorphism, abstractions ... ), but in the end are incarnations of functions. For example, int String.length(){..} could be thought of as length(char[]):int function, and List.size() as length(List):int. Node Tree.next(DepthFirstStrategy) could be thought of as traverse(Tree, traversalFunction):Node. But because OO languages tend to be mutable, they lose the benefits of the FP world. However, because they are mutable, they tend to perform better in benchmarks. I think OOP implemented in an immutable language would be over-engineered FP, whereas OOP implemented in mutable language is just glorified imperative programming.

With my experience so far learning functional programming, I think it is a better tool: All the things you can do in OO world, you can also do in FP world, mostly better. When performance is of real concern, then those bits could be factored out into some imperative code - whether it's done in OOP or assembly, C is a matter of choice.

In other words, I think in the order of technology preferences, FP should be prioritized higher than others although there seems to be a steeper learning curve. I think FP is not getting the attention it deserves as a better tool.

SkyMarshal• 10 years ago

So Haskell got you all of the following:

* GHC’s support for safe concurrent programming is world-class

* Sound type safety led to refactoring being a breeze

* Fun, stretches the mind (for some people)

* Perfectly reliable unit tests.

* Concurrent batched IO.

* Abstractions for things like timeouts and running tasks on other threads while correctly bubbling failures.

* Fantastic support for safely encoding and decoding JSON.

* One of the best benchmarking tools I’ve ever used.

And the complaints amounted to:

* Devs have to think more about which String representation to use

* Devs have to think more about syntactical differences from the more familiar C-derived languages

* The team has to support more backend platforms, duplicate infrastructure

* Not a mainstream language (harder to learn, hire for, bus factor)

* “at this stage in my career I don’t want another programming language”

75% were for and 25% were against. Frankly the only complaints worthy of serious response were infrastructure duplication and hiring/skill development/bus factor. The rest are people just being close-minded and lazy.

The Story of Haskell at IMVU

Related Stories