The year was 1997 and my uni professor was contributing to Hugs (do you remember it?). But, while I was working my way through Monads and stuff other people were running circles around me in C or C++. The basics were "simple" (even for basic C++) and they concentrated in getting things done.
Years later I launched my first start-up idea on Common Lisp. In both situation I learnt two hard truths:
a) libraries and support are very important
b) Architecture + basics >>>>> any particular technology
Now we are in 2015 (nearly 20 years later) and Haskell has advanced as much as Common Lisp on regards of usefulness for the general business. People still consider them elite (or 1337!) languages for showing off, meanwhile the rest of the world (with its mediocre programmers and tools) are running circles again. Programs now are distributed around dozens, hundreds or thousands of machines. Latency, networks, deployments, services, data communication,...
In the end I selected Python as my main programming language, following Norvig's advice that Python made for a good replacement for Lisp. I don't regret my decision not even a bit. Python paid/pays my bills. Yet, from time to time I read this posts and presentations and I feel a bit of envy for not being in a position where I could say «I reject your reality and substitute my own» and use Haskell or Common Lisp for main infrastructure to have the 1337 feeling again... like when I use obscure operative systems and end up in fruitless battles over how they are better even taking into account the lack of mainstream adoption (I'm staring at you Haiku-os!).
I really could not have said it better. Programmers seem much more likely to feel the need to prove they are smarter than their peers than the average population and functional languages seem to be a very popular I'm-smarter-than-you badge to bandy about.
I think the penetration of functional programming speaks for itself. If a tool is clearly superior, you'd expect it to do great things, and to do it often. I hear tons of excuses but not one that has made any sense.
To be clear, I'm not say functional languages are worthless, I am succinctly saying that they are not measurably more productive than the usual suspects and I say this after having a rather pleasant experience with erlang working on a rather huge ejabberd plugin.
Going philosophical (and I do this a lot), it's really about exploration of the solutions space. I think the whole profession has moved a step forward and we need metaphors, tools and architectures for systems where one computer (regardless of the number of CPUs or architecture) is just a component in our systems. Functional programming (not Functional design, think Map/Reduce) is a late attempt to improve on a "semi-solved" problem: to produce high quality systems that run inside a unique computer. Late attempts always can contribute, but they only offer some negligible benefits that doesn't balance properly with the added complexity (in technology or training... the famous learning curve). These attempts will always be welcome and will improve some layers on the systems we design, it's just that as move forward the benefits will go into a diminished returns dynamic.
Hm, I'm not sure about the parallels between Lisp and Haskell, and the conclusion that they are primarily valued for showing off. Yes, they are appealing to programmers with that mentality because they are powerful languages that are difficult to learn and use effectively. However beyond that they diverge dramatically.
Lisp is a language with no syntax, it is like an unshaped lump of clay. It gives you total freedom to implement any computational construct you can imagine. This does allow greater productivity for very small teams, and maybe it's the most powerful tool for the smartest programmer, however it doesn't offer anything to improve the practice of maintenance and reuse. This is why no viable ecosystem ever coalesced around Lisp, and in fact why there are so bloody many Lisps to begin with: because it is attractive primarily to individuals who want to build their own special flower.
Haskell gains its power in an almost opposite way by its type system, it's an extremely rigid structure which contributes tremendously to code reuse and maintainability. It works because great effort was put into the type inference so that it is strong yet lightweight.
IMHO as a seasoned programmer who has spent 5+ years and 7+ years on individual projects, I can definitely see that Haskell is addressing real world problems in a way that Lisp can not. I use ruby day to day, and frankly it's good enough in its meta-programming ability to solve most of the pain that Lisp solves compared to say Java or C++. However when I look at the problems which creep in over a period of years, the code rot, these are things which Haskell trivially prevents while half-hearted type systems like Java don't really put a dent in.
I think the reason Haskell hasn't seen more adoption is simply because of the current value of shipping fast. However we are in the midst of a Cambrian Explosion of software, and I believe that as the maintenance costs become apparent (as well as parallelization increasing), that the scales will tip towards many functional programming ideas. Maybe it won't be Haskell that sees mainstream adoption, but at the moment it has the most powerful embodiment of these ideas. I wouldn't bet against it based on the parable of Lisp.
Lisp was a language that precisely gained great adoption due to the power it allowed to the individual programmer. The lack of syntax was it's biggest advantage.
Viable ecosystems coalesced around Lisp! Emacs? Lisp Machines? Tons of scientific software? Big AI projects? The whole open source revolution started due to the appeal of the commercial world for Lisp and it's success.
Lisp was a academic and commercial success. The reasons for its decline are multiple, and yet it even was able to come back as Clojure.
And then you have Haskell. A programming language created exclusively by and for the academia. I don't know if you realise that Paul Graham launched his startup using Common Lisp... at a time when Haskell was available as open source too. I'm just using Paul's name as an example of the large community of people who thought (and think) that Lisp languages gave them a productivity and power that couldn't be compared. You even have some commercial video games programmed in Lisp languages! (the famous and repeated example of Naughty Dog). Lisp in finances? Yeap, there are still system using it after many years. Remote probes in deep space? Check. So there must be something to Lisp that helped people to create reusable and maintainable code. And in all these cases it was individual geniouses who pushed for the use of Lisp.
I think that the problem with Haskell is the single promise of its type system. Every single language that boasts to have the silver bullet that will allow people to tame programming (what is nothing more than hard complicated work) has failed to gain adoption by some reason. Diminished returns, maybe. The world is complicated and single techniques that promise to solve everything tend to fall short to the promised benefits. So, how is Haskell going to help me with network protocols? To build better generic software? To interface with the IoT? To create better AI or explore data with Machine Learning? If the answer to these and other questions is "through a hard fully capable type system", then I cannot but laugh.
Then you have languages like R, that are gaining wild adoption in the academia (even if it's a "specific" language) because people feel powerful with them. They can achieve so much more with the same effort that it's a no brainer to use it. Code reuse? Yeah!!!! Thousands of libraries available that work like a charm. Ugly? As hell! but who cares? Oh yes, dogmatic showing-off aestetically/academic inclined posh programmers that represent a small part of the industry, they seem to care a lot (I include myself in this group). And yet smart people is using R every day to the point of forcing people like me (yes I programmed in Haskell in the past) to recognise that there must be something to it. A programming language that transfer a unseen amount of power to the normal user (even if it's an opensource copy of previous software).
As I said, I would like to be able to use the «I reject your reality and substitute my own» card... but after that many years I think that doing so would be just plain naîve.
PD: I would never put maintainability above power (power being defined as "now I can do X easily in half the time"), it seems to never work when it's achieved through "training" and "complexity" (as in for instance "large learning curve").
You're right, I was downplaying Lisp's successes. In fact I wouldn't disagree with most of what you say here, Lisp is definitely more powerful than Haskell.
The part where I disagree is that Lisp holds future promise as a general-purpose language replacement to tame the mess of COBOL / C++ / Java / PHP. I see in Haskell a way to raise the bar for the masses, whether it's Haskell per se or some trickle down effect. Yes, you could build a powerful type system in Lisp, but it is not a widespread goal because it is somewhat conflicting with the raw power argument.
> I would never put maintainability above power
Here is another place I disagree. All else being equal of course I prefer power, but these things are on a continuum. If I can sacrifice a bit of power to greatly increase maintainability or robustness then I believe that is a compromise worth looking at.
I'm curious if you really see no truth in my comment or you really do see programming world in purely blub-theory terms.
Balance, c/c++ (and even to some extend Java), are not appropriated for what I normally build: web systems. The balance that Python offers me, where performance is achieved by other means than the programming language (systems), with an access to libraries (data analytics, web frameworks, devops...) that cannot be easily matched by C/C++/Java. And about Haskell... well, I suppose it offers amazing performance and technical advantages over other languages (if I remember...), but always as far as you can afford little geniuses working in specific problems in a megacorp where all the other things (from having access to cash, to sending them to Hawaii with all the family every year, to SRE, to Devops, to... well everything) has been covered and what you really need is that 0.00001% of advantage that can keep you in the competition with other megacorps (Google vs Facebook?).
Sorry for my "you geniuses are important but not that much" approach, but I'm in the start-up business, not in a PhD ridden competition to check who can move more chess movements in their head while listening to trash metal :)
If you want to know my thinking framework for this kind of stuff, I apply Dawkins/Evolutionary Biology technique of counting how many times certain traits have evolved independently to measure its usefulness. Take any Haskell project in Google and measure it vs their total code vs the revenue that it brings to the table. Same for Facebook. And then we can talk.
And yes, I realise that Facebook is mostly PHP and Google is mostly C++/Java. But I remember, the first engine in Google was implemented (at least in part) in Python ;) Later they had the cash/resources to afford rewrites in C++/Java.
But that was the point, that not all programming languages are created equal. I only have anecdotal and personal experience to back this up, but I believe that a vast majority of people familiar with both Python and C would much prefer the former for Web development (as you do).
Looking at the big picture, computers are so ubiquitous now because they provide significantly better tools for all kinds of businesses. It's fairly obvious that programmers themselves can also benefit from improved tools. And our main tools are programming languages - although there are obviously also other parts to the puzzle (IDEs, compilers, build + deployment + CI systems). I think we are already better in that some of our mainstream languages today are nicer to use than most of those 30 years ago. However, the difference is not huge, and my impression is that the language development was largely done from personal experience of individual language creators, and has largely ignored the research advances made in the area of programming languages. Notable exceptions are garbage collection, and Clojure and Haskell (if we can consider them mainstream).
Now of course, there are other, both non-technical considerations that are also affected by language choice. Availability of libraries or programmers are obvious examples. But the real question is of course whether incorporating these advancements offers a real, measurable benefit, and I think that's what you're hinting at. The problem is that the benefits are hard to measure in a sensible way. Frankly, I don't think that the metric you propose (which, if I understand correctly, is "measure the cost/revenue ratio of projects in language X at company Y against the average ratio for all projects at company Y) can give reliable answers. How do you measure the revenue of something like Haxl? I think the language choice is going to remain a personal decision in the end.
At the risk of sounding inflammatory... I would be willing to believe that purely functional languages are the "one true way" if there were even the slightest bit of empirical evidence to support it. But where are all the successful large scale projects built with Haskell (or Clojure or whatever)?
The biggest FP project I was aware of was Twitter using Scala and they ended up completely backing away from it. Yikes.
The only other popular site that springs to mind is Hacker News, and frankly, it sucks. It's practically the Hello World of discussion forums.
The truth is, at the end of the day almost everything is being built with Java, Python, Ruby, or JavaScript. Can you really blame the product owners for being wary of writing their whole product in a functional language?
> But where are all the successful large scale projects built with Haskell (or Clojure or whatever)?
How about Erlang. Let's try it, just from the top of my head:
* AXD 301 Switch -- Classic. Powers and control phone switch networks of whole countries. Claims 99.9999999% reliability.
* Basho Riak -- popular NoSQL database, highly scalable nodes are peers
* RabbitMQ -- popular message queue used by enterprises
* WhatsApp -- messaging application, processes billions of messages a day. Built and maintained by only a few engineers. Sold for billions of dollars.
* Klarna -- European payment processing
* Bet365 -- Sports bets
* Stock trading -- Allegedly Goldman Sachs uses it.
* Erlyvideo.org -- Video streaming service
* eNodeB -- Ericsson cell to internet gateway. There is a 50% if you want to look at cat pictures from your smartphone and Erlang breaks, you won't see your cat pictures.
* Wings3D -- A subdivision 3D modeler. I guess you can build your 3D cat and then send it over WhatsApp via a eNodeB to your friend.
Those are just I know of. So there you go. Maybe you should learn Erlang ;-)
Well OP asked about Clojure so Erlang fits the profile.
But you make an interesting point in a way. One can ask, ok here are two non-strictly functional languages that seem to be fairly practical. Used for large distributed mission critical systems.
Would they be better off written in Haskell?
Would they have been written at all if creators only knew about Haskell?
How large is the relationship between fault tolerant and safe systems as a product vs strong compiler type safety in the language it was written.
>But you make an interesting point in a way. One can ask, ok here are two non-strictly functional languages that seem to be fairly practical. Used for large distributed mission critical systems.
I think there're at least these problems with Haskell:
* The language is badly designed. See the number of extensions which aren't standardized but widely used. See also obvious problems such as requirement to use renames when importing code, and problem with record names conflicts which isn't solved for years.
* The focus of the language isn't correct. Lazy evaluations creates a lot of problems both in program performance and complexity of the compiler. The most important parts are pureness and side effect control.
* The language is already obsolete. Many its constructions and related complexities are redundant if we unify type and expression level, and get as a result dependently typed system.
I hope some language in the future will implement these ideas, and we will have a widely used pure functional dependently typed language with explicit control of effects.
I see two candidates for such a language:
* Pure script - it's Haskell done right, compiledd to JS. Unfortunately, it doesn't support dependent types.
* Idris - it's the language which I describe, but I fear that it's impossible to create a widely used commercial language without major industry players' support.
> the number of extensions which aren't standardized but widely used.
Actually, I think this is something that Haskell did right. It allows experimentation with new language ideas in a way that allows them to be tested safely with existing codebases. Edward Kmett recently had this to say about it:
> I appreciate Haskell's willingness to take a very very long view, and explore the design options, before committing to a path. In many ways, it is this feature of our community and our language that keeps other programming languages looking to us for features and designs to steal.
> The language is already obsolete.
By that argument so are C, C++, Java, etc. But it's about the existence of a mature ecosystem, not about what is theoretically known.
> Pure script
PureScript is great, but its compile to JS basis makes it inappropriate as a general purpose language.
> Idris
Idris looks promising, but it doesn't have a large enough ecosystem yet. I would certainly be willing to switch from Haskell to Idris in the future, but Haskell already is at least a little bit dependently typed [1] and as hinted at above I wouldn't be surprised if Haskell is able to continue improving its dependent typing capability as research advances.
> PureScript is great, but its compile to JS basis makes it inappropriate as a general purpose language.
Except that Javascript is rapidly making inroads on everything except systems programming. If Java is a general purpose language (can't be used for systems without translation due to the JVM), then so is anything-which-compiles-to-JS.
I think the really important thing is that, while I've been enthusiastic and interested in Haskell for a long time now (~8 years?), the vast majority of people will never understand even a comparatively simple concept like monads, let alone anything higher level than that.
Until you can 'get work done' without the equivalent of graduate-level math classes, there's simply no way to develop that 'mature ecosystem' that everyone is hoping for. People have been using 'better if you understand the complication' languages for a long time now, and there's a good reason they're still niche, unfortunately.
Erlang is a great language, but it's very definitely not of the same scale of difficulty to understand as Haskell. You can noodle around with Erlang and end up with something that works reasonably well - in my experience with Haskell, if you can't mathematically formalize what you're talking about, you're going to have a bad time, unless you do go the 'embedded scheme interpreter' route, which is a fun project, but why not just use Racket to begin with?
> If Java is a general purpose language (can't be used for systems without translation due to the JVM), then so is anything-which-compiles-to-JS.
Fair point. I guess my thinking here is that PureScript is unlikely to replace Haskell. It is possible, but I think there are a few reasons that probably won't happen. The first is that it's mission statement "PureScript is a small strongly typed programming language that compiles to JavaScript" points it in the wrong direction. Maybe Javascript is the counter to this, but that feels like an anomaly. Second is that it is way behind Haskell in terms of infrastructure, ecosystem, and a lot of core language/compiler features that enable general purpose programming. Could swarms of people come in and change this? Sure. But if they did, it seems to me that PureScript is similar enough to Haskell that people could just switch to Haskell and avoid that work.
> Until you can 'get work done' without the equivalent of graduate-level math classes
This is a big misconception that is demonstrably untrue. I know many people who have developed a solid working grasp of monads without doing graduate-level math.
> Second is that it is way behind Haskell in terms of infrastructure, ecosystem, and a lot of core language/compiler features that enable general purpose programming.
No, it's way ahead because it's based on Javascript, and javascript is having umpty-billion libraries developed for it right now. Of course that's not actually a good thing at the moment but they'll settle down at some peoint.
> This is a big misconception that is demonstrably untrue. I know many people who have developed a solid working grasp of monads without doing graduate-level math.
Ref my reply to Mr. Church, but it's not just monads - you never stop running into category theory if you're using Haskell, it's baked in.
If someone without any knowledge of category theory rewrote the language, that statement might become true (though I'd be skeptical they'd get it right), but as of right now, you need to know category theory to understand the language and it's base libraries.
I know, I've struggled with it for a long time - every time I have a problem, I have to go back and reteach myself category theory to understand it.
Until you can 'get work done' without the equivalent of graduate-level math classes
The problem is the name "monad", not the concept itself. You don't actually need to know anything about category theory to do I/O. You just need enough exposure to the concepts to know why the Monad type class is so repeatedly relevant as to be given a named abstraction.
People have a hard time getting past the name. You don't need to be a category theorist to use monads in Haskell.
> You don't need to be a category theorist to use monads in Haskell.
I find that demonstrably false. Every time I run into problems and ask for help, the answer is "there is this other mathematical concept that solves that problem".
It's not just monads, it's comonads, monad transformers, GADTs, Functors, phantom types, arrows, arrow transformers, the list keeps going. In addition, they're only described in terms of other mathematical terms - the same problem that plagues monads: nomenclature.
And these aren't just 'things you can use', if you want to understand the libraries you're using, you need to be able to keep up with all of those and more.
It's not like lisp, where you can mostly rearrange cons cells to make nearly any data type you like - there's no way to bootstrap your brain into understanding arrows from a standing start, at least in my experience as an autodidact trying to learn.
GADTs, phantom types, and arrows (not to mention monad transformers) aren't "mathematical terms" in that the names aren't borrowed from mathematical terminology.
They're just _terms_. But to you they are new terms. So you call them "mathematical terms" because obviously if you haven't heard of it, then it must be complicated math.
It isn't.
If you stop thinking that every new concept you meet in the world (or at least in Haskell) is a "mathematical concept" and start thinking it is "just a thing that is new and I can learn" then maybe you will stop feeling this way.
For that matter, none of the things you list except for Functors and Monad Transformers (which are just "ways to build monads") are idiomatic for "basic" haskell programming, and the next step up, GADTs is a straightforward feature to learn when you need.
If you read something like RWH or LYAH, you'll notice they don't cover arrows or GADTs that much. That's because they're not considered core concepts. If you set out to learn "all the things" and then discover that there are a lot of things, perhaps the problem is just that you set out to learn "all the things" under the false impression that you need to in some immediate way.
I should amend this. I have never noticed something to be an arrow transformer in the wild, neither because it was called out in documentation or naming, nor independently. I have much less confidence nothing I have encountered has ever been an arrow transformer...
Sometimes you have to find the tutorials and blog posts first. The lens type signatures aren't the easiest to understand, and sometimes its easier to just use things "empirically" without fully understanding them, and then get a sense of the type signatures when you really want to know what the compiler's actually doing. Being able to use lenses is not as hard as understanding why its intimidating rank-2 type signature is the right one.
Finally, sometimes it helps to de-generalize. To replace (Monad m) with IO, for example, and think about what that special case might mean.
For example, the type signature for Control.Arrow.first is:
first :: Arrow a => a b c -> a (b, d) (c, d)
If you're a beginning Haskeller, your reaction is going to be "WTF"? Well "Arrow" is a type class more general than function. (It could be the "effectful function" type or Kleisli arrow, a -> IO b.) If you specialize with a = (->), you get the more concrete type signature:
first :: (b -> c) -> (b, d) -> (c, d)
... and it's much more clear what it does.
As for nomenclature, I don't disagree. I had this discussion with Brian Hurt (and owe him for the insights): we'd be more marketable if we called Monoid "Appendable" and Functor "Mappable". Monad is one where it's hard to come up with a more accessible name for it: it abstracts over computational context (i.e. what do we actually mean when we talk about computational effects) but that would be a mouthful of words and not any more clear.
I know all these things now - my point is that it took me years to get them to a level where I understand what they mean well enough to implement them anew. You can't say that about other languages.
Nobody is going to 'build a community' around a language that is so effectively obtuse, and when called on it, says 'here are tutorials' - tutorials are not the point. RTFM isn't a decent response to 'your language is difficult to learn and use'.
Given that not even basic functional programming has become popular yet, I can't see dependent types being widely adopted for decades. The learning curve for using dependent types is incredibly steep and capturing interesting properties in types inevitably requires you to understand and write tricky maths proofs.
I wouldn't say that was the case until there is wide support for algebraic data types, type inference, pattern matching and immutable data. I see more languages allowing functions as parameters, basic type inference and encouraging immutable data, but they're still missing out on a lot of benefits offered by functional languages like Haskell and OCaml by ignoring these features.
I do see functional programming features making their way in to imperative languages but most people are still coding in an imperative way. Mutable data is still the default rather than immutable data for example.
This is a terrible and also hilarious argument. Instead of saying Haskell has too many newfangled ideas, you're instead arguing that it has an insufficient amount of them.
So Haskell has newfangled innovations compared to the big players, and it _also_ has a mature ecosystem in widespread use.
This puts it ahead of Purescript and Idris for adoption in large scale projects (although I would readily agree that both those languages are pretty great too).
I maintain that lazy evaluation works great, it just requires optimizing along different paths than devs are used to -- but it doesn't incur more "overhead" to optimize code than is the case in typical strict languages, which _also_ have to pay that cost, just in different sorts of optimization and reasoning.
There is what I like to call The IRC Problem, which is that it takes a bit of work to really make IRC into an awesome, persistent chat environment.
First, you need to be persistently connected so that you don't miss messages when you're not actually at your computer.
Second, you need a decent interface to use when you are actively reading or chatting.
Third, it would be great to have the same across all devices (phone, tablet, laptop/desktop), with everything syncing correctly. If you read some scrollback on your phone, you want your laptop to also know that you already read those messages, and vice versa.
It's certainly possible to achieve all this with irssi and a combination of other techniques. However, you can also use something like IRCCloud and get every problem solved at a very high level of competence immediately, plus a bunch of other stuff (like push notifications and embedded social media, images, videos, tweets, pastebins, etc.).
It's up to you. For me, I really just want everything to work and I don't care at all about doing it myself. It's a means to an end. The $5/month fee is not important to me given the product quality. I sort of liken it to Dropbox -- it's not about doing something that couldn't be done before, it's about just making it streamlined for those who don't care to do it themselves.
> First, you need to be persistently connected so that you don't miss messages when you're not actually at your computer.
I consider that a feature of IRC myself. I don't need to be wired in at all times and read eveerything everyone says. If I'm not there, I'm not there, and if there's something important I really need to hear, I'll hear it when I'm there. If I don't hear it, it never was important.
There is memoserv in many IRC networks that does relay messages when you come back online. I have seldom had important messages relayed that way either. Most conversations are not that important.
I don't see IRC as something that should follow me everywhere across all devices. It's like radio or TV. Turn it on, turn it off. Not on all the time.
Lisp, Haskell and other FP are currently killing it in the quiet world of DSLs, especially Mining, Oil & Gas industries which need to parse petaflops of seismic data and reservoir simulations, need rapid prototyping, need formally verified drilling platform components that field engineers can interact with easily, and HPC algorithms for financial trading.
As for Hacker News UX I wish every site was this simple instead of popups everywhere to get me to download their phone app, piles of slow loading fonts, trackers, generic stock images of business suits pointing at a screen, information buried underneath annoying popup FAQ screens, ect.
> The truth is, at the end of the day almost everything is being built with Java, Python, Ruby, or JavaScript.
You need to normalize against the number of programmers writing in Java/Python/... compared to the number of programmers writing Haskell for this assertion to be meaningful. And when you do that, the picture starts to look a lot better.
In the past few years I have seen more and more people start writing real projects in Haskell and be successful. There was a presentation a couple years ago at CUFP [1] discussing one company's experience porting a 43k line Groovy app to 8200 lines of Haskell. You don't need someone to build a highly visible multi-million line piece of software in Haskell to be confident that it can benefit your project. I think there's enough evidence out there today to make a very compelling case.
That may be survivor's bias, though. How many software products end up not making it, at all? If you look at all software projects, everywhere, combined, and split them up: functional vs non-functional. The latter group would several orders of magnitude larger than the former.
Now what percentage of the non-functional ones ends up becoming successful enough for you to hear about them and know what they were built with? Apply that percentage to the functional projects, you might just be left with naught.
I have a feeling that if there's one thing more rare than functional programs, it's highly successful ones.
I would use strongly typed functional programming languages for everything if I could.
However, to be productive, you're usually constrained by what the dominant language is for your domain. For example, Android apps are usually written in Java and web apps are usually written in JavaScript. Each has a huge ecosystem of tools and libraries based around these languages.
I'm sure there's some way I could use Haskell or OCaml to write Android and web apps. However, by going against the grain, it's likely to be very time consuming and frustrating to integrate with existing libraries and tools. I'm therefore going to lose any advantage I was hoping to gain from using a functional language.
> I'm sure there's some way I could use Haskell or OCaml to write Android and web apps.
I don't know about Android, but for Javascript apps the balance tipped for me just last month. I'm probably enough of an insider that it's not quite true yet for the average Haskell developer, but I believe that will change soon.
What framework are you using? I've investigated Dart, Flow and TypeScript to improve static checking but I'm still having pain points: they work fine when dealing with your own self-contained code but integrating with third party libraries isn't always straightforward.
I'm using GHCJS and Reflex. Reflex is a recently released FRP library that makes a huge difference in one's ability to abstract GUI code. I personally feel that this combination of GHCJS + Reflex is the first thing I've used that makes web front end programming tolerable. A week ago there was a presentation about it at the NY Haskell Meetup. Look for videos of it to be posted early next week.
It's new, so not right now. But docs are coming. The NYHUG presentation will probably be the first thing along those lines. My company just rewrote a significant front-end app in it, so we clearly are invested in its future. In the meantime there's a #reflex-frp IRC channel on Freenode that you could use to talk to some of the people currently working with it.
It depends on if your server side code is heavily reliant on third party libraries written in non-functional languages and which languages your team are experienced with.
I'd like to think that the Erlang has proven its value at building reliable, distributed applications. It's a go to language for distributed key value stores (Riak, Couch, et al), and it's in wide use in Motorola and Ericsson to build critical infrastructure. I call that successful.
That said, you do have a valid point: The presentation provides justifications for those that want to switch in the first place, but to be compelling, it needs evidence.
I work in Erlang and love it, but I would make the friendly argument that Erlang is really distinct (and special) even among the FP languages for a number of reasons. I always had the impression that Erlang was functional to support the guarantees made by the runtime rather than for ideological reasons. Some of the Functionistas I've run into seem to reject it out of hand for not being Haskell, but as a C guy I find it freaking amazing for writing stuff that has to stay running all the time. I guess I use in spite of it being functional rather than because of it, but it feels like I'm getting good value even when I run into things that are a pain in the ass to do functionally (which is not super often).
> The biggest FP project I was aware of was Twitter using Scala and they ended up completely backing away from it. Yikes.
You must be joking, Twitter is far and away the largest Scala shop in the world.
Presumably you're mixing up LinkedIn's recent move from Scala to Java. An important caveat is that they're still using the Play framework (Typesafe product), just now in Java instead of Scala.
It's unfortunate that Play serves two masters (i.e. Scala and Java), but industry demands it -- the argument that FP is the one true way goes out the window in face of current reality: enterprise by and large will go with mature tooling and cheap developers in a large-team-friendly language like Java over a paradigm shifting FP language like Scala, Clojure, or Haskell.
Be careful what you mean by 'mostly'. Though there may be many small outfits that use it for this particular features, there are others that use it very differently (and at completely different scales). Examples such as Facebook, Jane Street and Esper come to mind. There are likely many other companies who have less of a web-presence too (cf defence industries, as mentioned in the slide deck).
Well, Twitter didn't backed away from Scala, but it doesn't qualify as purely functional.
Turing completeness ensures there's no "true way", but some languages offer better abstractions than others. In my experience, once you learn the abstractions, the functional paradigm has an edge about the ability to reason about the code.
Of course, the adoption of new ideas and technologies takes time, they need to be explored and fully developed. But even right now, you see many mainstream languages adopting functional flavors.
I believe that eventually, there will be enough successful large scale projects build with pure functional languages to convince skeptics, there's nothing wrong with "playing it safe" and wait.
If Scala is good enough as an example, I see an increasing adoption.
As an anecdote, one of the biggest and Very Serious(tm) investment bank, is using Scala for most of their new initiatives, with a big team spread across the world.
And the language itself was selected by a committee. You can't get more serious than that...
Sure maybe it's not good for FP if you're Edward Kmett.
> The reason, I'm hesitant to give it a fifth star is ultimately that I don't believe that Scala is a good language in which to actually do functional programming.
Literally the only other mainstream language that he would be able to say is capable of "fp" better than Scala would be Haskell.
At least people use it, which is more than what could ever be said about Haskell, so it had a larger impact overall ... while getting things done at the same time.
You only need to have one look at it's module system/Cabal/Hackage to see that it was never intended for larger code bases than people's PhD thesis.
Yes, it can scale: In the same way PHP and JavaScript does.
But where are all the successful large scale projects built with Haskell (or Clojure or whatever)?
Standard Chartered has a huge amount of infrastructure in Haskell. Clojure's too young to have the types of stories you're looking for, but it's had plenty of moderate-sized successes (as has Haskell).
The biggest FP project I was aware of was Twitter using Scala and they ended up completely backing away from it. Yikes.
Scala is different from Haskell. Scala has a lot of features that don't play well together, it has stability issues, and it has inherited some of the Java culture which means that there's a lot of terrible Scala code out there.
I've been working with Spark over the past month and I'm shocked by how bad the JVM/Hadoop legacy is. Spark itself is a neat idea. Getting it to work on an actual production cluster is a huge PITA. I'm tempted to just use Cloud Haskell.
I know people who've moved away from Scala (either to Java or Clojure or Haskell). No one who's moved to Haskell has ever regretted it. I know of about 15 companies that use it (not all on million-line projects) and they're all happy with it. I'm only aware of one case, in the past 7 years, where a company moved away from using Haskell: they moved to F# because they picked Microsoft up as a client and MSFT wanted to be able to say that $COMPANY_X was using their products.
The only other popular site that springs to mind is Hacker News, and frankly, it sucks. It's practically the Hello World of discussion forums.
It's written in Arc, which lost to Clojure. Also, HN is as good as it needs to be. It's successful on its own terms. It doesn't need to be a wonder of software engineering.
It will be once it gets a decent mobile view akin to viewing reddit on /.compact.
Anyway, good point--I've heard people complain that Haskell is hard to learn/understand, but I've never heard of anyone actually using it in production and regretting that decision.
* There's no widely used successful system written in Haskell. Yes, there's GHC, Agda, Idris and other research tools but they are marginal.
* It's untrue that mutable state is the main reason of problems with code. You can manage state in Java and C# in any other language.
* Haskell programmers are usually smarter than Java programmers, but they often don't want to work on tasks which they aren't very interested in, which are almost non existent, or have little business meaning.
* Haskell, actually has a lot of design flaws. The worst of them is the scope of record fields.
> There's no widely used successful system written in Haskell. Yes, there's GHC, Agda, Idris and other research tools but they are marginal.
Google's Ganeti?
Microsoft's Bond?
> It's untrue that mutable state is the main reason of problems with code.
Its certainly one of the biggest, if not the single biggest (the only thing I can think of that gets cited nearly as much is multithreading/parallelism, and the main source of problems in that domain is also managing mutable state in that context.)
> You can manage state in Java and C# in any other language.
Sure, Turing equivalence means there is very little difference in what languages can do, just in how suitable the abstractions they present are to enabling humans to do it effectively.
> Haskell programmers are usually smarter than Java programmers, but they often don't want to work on tasks which they aren't very interested in, which are almost non existent, or have little business meaning.
So, take Java programmers (particularly smart ones) and teach them Haskell. Bang, you've got Haskell programmers without worrying about the interest distribution among pre-existing Haskell programmers. Learning PLs, for skilled programmers, isn't a huge deal -- the good Java programmers won't have much problem becoming good Haskell programmers.
Those aren't the only two known projects, those are just two examples of open source projects that are, in addition, used in key infrastructure by the major solutions provider that is the original source of the project, and so widely, if indirectly, used.
Compare this list to Java/C#/C++ used in the industry. Or even to Scala/Clojure/Erlang used in industry. There will be several orders of magnitude difference.
And, so what? Sure, Haskell is less popular in industry many other languages. That was true of all the currently popular industrial languages before they became popular. But its certainly not the case that there are no succesfull uses of Haskell in significant systems.
> The most popular language, namely C#, Java and C++ became popular quite quickly.
But those languages had corporate backing. Haskell doesn't have corporate backing, so shouldn't you compare it to languages that became popular and didn't have corporate backing?
Site integrity service is minor compared to such things used at facebook as, Cassandra (Java), React (JS). Haskell might be used efficiently in some cases, but we don't see any killer applications created with it.
> You can manage state in Java and C# in any other language.
Yes but I think that the "value prop" with Haskell is that it forces everyone to abide to a certain discipline with respect to type safety and immutability.
> they are marginal.
Relative to what/whom? All the projects you have quoted are really successful and directly or indirectly pushed mainstream software engineering forward (i.e safer style).
>Yes but I think that the "value prop" with Haskell is that it forces everyone to abide to a certain discipline with respect to type safety and immutability.
Thanks, to a large number of extensions with questionable utility, it's very easy to write not only unmaintainable code, but just unreadable code.
>Relative to what/whom? All the projects you have quoted are really successful and directly or indirectly pushed mainstream software engineering forward (i.e safer style).
They aren't safer style. They are more related to math than to programming. I believe, they could have benefitted from being implemented in more mainstream language than Haskell.
I've been using Haskell at work for the past two years, but despite the fact that it's been a great investment, I don't really like articles like this.
I find evangelism gross, and in particular, developer technology evangelism especially distasteful.
That said, I take issue with the objectiveness of your points. For the first one, there are indeed quite a few successful systems written in Haskell (I suppose I might be quibbling with your definition of "successful"). Facebook is using Haskell for a few things internally (including their rule engine for fraud/spam processing), Standard Charter is using Haskell. In fact, here's a whole site of people using Haskell in industry (https://wiki.haskell.org/Haskell_in_industry)
I do think that it's only recently that you're starting to see projects/products built with Haskell that aren't libraries. Just this week there's been a bunch of web frameworks released (Airship and Spock, with Silk releasing a REST API framework a couple of months ago).
I'd like to see more projects that people can use that don't have to care about the fact that the software is written in Haskell (databases and data analytics systems are a particular area I'd like to see become less Java-focused).
Your second point on mutable state seems counter to a lot of the current conventional wisdom of the past five years, which is that immutability is vastly preferred to mutability. This is becoming true in Javascript (with React and Underscore), has always been true in Clojure, and is becoming more and more important in any system that deals with concurrency.
You can certainly disagree that mutable state is the root of all evil, or even the most important problem with modern development; but I don't think it's accurate to paint Haskell as being the weirdo fringe language that's advocating immutability is the way to go. They have a lot of company on that front, they've just been making the point for a lot longer than most.
Your third point seems like you just completely made it up. Do you have evidence that Haskell programmers are "usually smarter than Java programmers"?, or that they are somehow inordinately picky about what projects they work on? Do you know many professional developers who work in Haskell?
It's true that the population of Java programmers is probably an order of magnitude larger than Haskell programmers (the number of universities who still teach Java for their introductory CS classes would probably guarantee that's the case), but contrary to what message board lore would have you believe, Haskell isn't some magical "smart person" language.
I'm an idiot and I haven't had any trouble using it full-time. I don't use it for crazy math stuff, or advanced computer-science research. I use it to process events, interact with databases, and display CRUD operations (like probably 80% of most enterprise-y software development).
Haskell's design flaws, while certainly existent, don't seem appreciably above or below any other language (I'm trying not to be smug, I actually think Haskell is much better designed than most any other language). I can happily attest that the record field scoping has not actually been an issue (although maybe I've just been lucky, and there's actually a bunch of other idioms for dealing with the scoping issue like lenses).
Personally I find selling excellence easiest without sweeping negative generalizations like they claim in their summary slides[1]. Presentation feels more like a blame game about how people have done things wrong in the past than highlighting success and features of Haskell.
[1] From slide 152:
- Old East Coast tech culture valued quality and
correctness, weak on practicality and communication.
- The new California-centric one emphasizes commercial practicality and communication
but doesn’t give a damn about software quality or excellence.
Reading the "How to Sell to Business" section convinced me as an engineer that I should not focus on Haskell. If Haskell programmers are a better deal for businesses because better programmers can be hired for less money, I should logically choose to be a Java programmer for the same reason.
The Java expert will be hired to maintain a million LOC legacy shitstorm, whereas in Haskell you'd have at least a few engineering guarantees you won't get a headache on your first day.
The paradox is that if you are focused on how to make the most money to the point that you are choosing your programming language based on estimated market value, you are likely not the caliber of developer that the top-tier tech companies are looking for. In other words, you can probably make $150k under an insufferable pointy-hair at any Fortune 500 company, but you won't get to work on cool stuff at Google or Facebook for $250k.
It doesn't necessarily work that way. Java programmers at the high end can push their compensation into the 250k+ range by starting bidding wars. It's hard to do that in a small community. In Java, there are so many jobs that it's really easy for a good engineer to set up a bidding war.
You have to be somewhat of a game-player to pull off the Java-engineer-bidding-war game. You have to be the sort of person who will work on the most horrible projects just to move up the salary scale. You also have to live in the Bay Area or New York, and use competing offers to drive up your pay every 2 years or so.
At some point, though, these $300-500k Java engineers at tech giants (who, by the way, are mostly paid in stock with vesting, so if you're bearish on the markets, their comp is more modest than it appears) are going to dry out and have to go into big-company executive roles. Playing that game rots your brain, because you're spending more time looking like a great engineer than learning new things.
Some people who are just as smart as me have better boredom-proofing and can work on enterprise Java. Good for them. I can't do it. I'd leave the industry before I'd maintain someone else's Java mudball.
That chart on slides 29-35 which claims you will be 600% more productive with Haskell than C#/Java after 5 years...
Its just made up isn't it? This is part of the problem. If you try to convince someone smart, experienced but skeptical by making things up, you hurt your own case.
Does the name "Brand X" on slide 29 refer to any specific language? Why add a mysterious third line to the graph when the presentation's primary focus is comparing the other two lines, Haskell and Java?
(a) there are good business people out there,
(b) the fact that they trust idiots on tech is our fault as much as theirs
(we get too arrogant or too submissive and fail to convince them),
(c) we need to recognize that we and they have orthogonal skill sets
and aren't *prima facie* smarter,
(d) and this requires understanding certain cultural differences.
It's a long road, though. We're not a socially skilled tribe, for one. Secondly, there are a lot of terrible managers and business people in tech (more than in other industries) due to the Damaso Effect.
IMO, good business people are people who are doing good for their business not using technology which their developers want them to use. They should consider things such as: ability to find developers, availability of training and books, availability well supported libraries, maturity of tools, code maintainability, etc.
>(b) the fact that they trust idiots on tech is our fault as much as theirs (we get too arrogant or too submissive and fail to convince them)
So, you are calling people who recommend to use technologies different from Haskell idiots, right? Or at least you pointing at them in your presentation. IMO, it's not the things which a professional should do. We have a lot of opinions, and it should be ok to have a different opinion. We shouldn't bash people who don't agree with us, otherwise, we will have (and I feel we already have) haskell cult.
"IMO, good business people are people who are doing good for their business not using technology which their developers want them to use. They should consider things such as: ability to find developers, availability of training and books, availability well supported libraries, maturity of tools, code maintainability, etc."
Business people should not be making tech decisions. Most good business people don't know a damn thing about code maintainability etc and they shouldn't have to.
IMO, good business people are people who are doing good for their business not using technology which their developers want them to use.
I agree. The ethical problem I have is with the short-termism. The next-quarter culture is absolutely horrible and that's what I hate. It's not directly related to choice of language, but often it gets tied up in that. The fact that Haskell requires some investment (and not a lot of it) is a deal-breaker, because so many business leaders are short-sighted.
They should consider things such as: ability to find developers
Java wins on quantity. It's probably easier to find good developers in Haskell. Even though there are probably more good Java engineers than good Haskell engineers, Java has a much lower percentage so your interviewing costs are a lot higher.
availability of training and books
Both Haskell and Java have enough.
availability well supported libraries, maturity of tools
Haskell is getting there, and Java has a lot of "enterprise standard" libraries (e.g. Spring and Hibernate) that will take you in the wrong direction.
code maintainability
Haskell wins.
So, you are calling people who recommend to use technologies different from Haskell idiots, right?
No. If, for example, you're doing low-latency trading, you're not going to use Haskell. Sometimes you want to use C or assembly. And while I prefer static typing, I think highly of Clojure and its community.
I think that there are a lot of idiotic reasons for using Java that get a lot of play. That doesn't mean that everyone who uses Java is an idiot.
When I point out that businesspeople trust idiots when it comes to technology, that's not to single them out. Realistically, I can't always tell a good car mechanic or lawyer from a bad one. You find that out over years, because there are plenty of people who can talk a good game but don't deliver the goods.
It seems like Python works for him, so he should continue using it. I'm not a purist who thinks that absolutely everyone should use one language (although I dislike Java).
There's nothing (major) wrong with Python. It has some quirks, and I don't like the lack of tail recursion, but it also has a large community and mature frameworks. If you need to build something quick and will rely heavily on existing libraries, it's a great choice. If your project will have to scale and is guaranteed to go multi-developer, then you probably want Haskell's static typing.
The year was 1997 and my uni professor was contributing to Hugs (do you remember it?). But, while I was working my way through Monads and stuff other people were running circles around me in C or C++. The basics were "simple" (even for basic C++) and they concentrated in getting things done.
Years later I launched my first start-up idea on Common Lisp. In both situation I learnt two hard truths:
a) libraries and support are very important
b) Architecture + basics >>>>> any particular technology
Now we are in 2015 (nearly 20 years later) and Haskell has advanced as much as Common Lisp on regards of usefulness for the general business. People still consider them elite (or 1337!) languages for showing off, meanwhile the rest of the world (with its mediocre programmers and tools) are running circles again. Programs now are distributed around dozens, hundreds or thousands of machines. Latency, networks, deployments, services, data communication,...
In the end I selected Python as my main programming language, following Norvig's advice that Python made for a good replacement for Lisp. I don't regret my decision not even a bit. Python paid/pays my bills. Yet, from time to time I read this posts and presentations and I feel a bit of envy for not being in a position where I could say «I reject your reality and substitute my own» and use Haskell or Common Lisp for main infrastructure to have the 1337 feeling again... like when I use obscure operative systems and end up in fruitless battles over how they are better even taking into account the lack of mainstream adoption (I'm staring at you Haiku-os!).