Haskell, Ada, C++: An Experiment in Prototyping Productivity (1994) [pdf](haskell.cs.yale.edu)
haskell.cs.yale.edu
Haskell, Ada, C++: An Experiment in Prototyping Productivity (1994) [pdf]
http://haskell.cs.yale.edu/wp-content/uploads/2011/03/HaskellVsAda-NSWC.pdf
57 comments
C++, also, is an entirely different, and overwhelmingly more powerful, language, than in 1994.
> would anyone be interested in a blog post "Rapid Prototyping in Haskell"?
Yes. Please.
Yes. Please.
"Rapid Prototyping in Haskell"
would be fantastic.
would be fantastic.
What is a "Python blob"?
As someone who writes a lot of Python, I'd say a Python blob is a half-formed idea expressed in Python without any particular thought given to design or conceptual clarity. Just enough to get the job done if you don't encounter any surprises, but not something you'd want to maintain. You expect it not to handle all of the edge cases and when it raises an exception you jump in and code around it at the point where it's raised, rather than fixing the root cause, which is lack of design. Unfortunately, a lot of Python starts out like this and then ends up being maintained anyway.
edit: What makes it blobbly is its lack of structure. It doesn't express any clear idea of the domain and tends to devolve into spaghetti.
edit: What makes it blobbly is its lack of structure. It doesn't express any clear idea of the domain and tends to devolve into spaghetti.
I would!
Yes please!
Trying to find the most productive language for all tasks seems like a quixotic quest. Each language encodes a set of expressions that are succinct to communicate, at the expense of some others. There are some basic information theoretical and computational complexity reasons for this.
There will always be different languages that are best suited to certain tasks, and the goal should be to make it easy (tools, systems) to work with many languages equally well, or to allow switching anywhere like with human languages.
There will always be different languages that are best suited to certain tasks, and the goal should be to make it easy (tools, systems) to work with many languages equally well, or to allow switching anywhere like with human languages.
I believe it was Dr Robert Dewar of AdaCore fame who I first heard remark that ( paraphrased ) every time a bug gets missed at a stage of development ( compile-time to alpha, to beta, to production, etc ) the cost of it's resolution increases by an order of magnitude.
I'm certainly by no means dismissing the value of concise languages for expressing ideas fluently, but brevity and expressiveness are only two factors influencing the value of a programming language in a specific domain.
It's definitely an interesting paper, every time I see it I can't help but think that it's a little disingenuous to conduct an apples to oranges comparison of languages on these particular merits. It's much more difficult to weigh up the relative investment of time necessary to write code that is equally robust, maintainable and fit for purpose.
Here's the video I got the Dr Dewar quote from: https://www.youtube.com/watch?v=0yXwnk8Cr0c
Here's the video I got the Dr Dewar quote from: https://www.youtube.com/watch?v=0yXwnk8Cr0c
This sounds like the oft parroted but rarely fully sourced quote that turns out to be from some 60s IBM journal, with questionable applicability to the modern age.
see eg https://news.ycombinator.com/item?id=15216407
see eg https://news.ycombinator.com/item?id=15216407
Most evidence I've seen supports it. This is especially true when people start integrating stuff with or building on top of a deliverable. Even more if that stuff was designed with the deliverables good and bad behavior in mind. It becomes a legacy system that sticks around. Knocking out its problems ahead of time can have considerable savings. Plus, a benefit not often mentioned is that knocking problems out at design time is easier since everything is fresh in developers' minds. They just wrote it.
Now, it might not apply in an environment where everything is designed to be pluggable and easy to change without breaks. Maybe folks should run some new studies on such projects to see if there's any major benefits for up-front investments in quality. Enough to pay off that up-front investment like in the other projects.
Now, it might not apply in an environment where everything is designed to be pluggable and easy to change without breaks. Maybe folks should run some new studies on such projects to see if there's any major benefits for up-front investments in quality. Enough to pay off that up-front investment like in the other projects.
I didn't really look at the quote as being a literal, canonical truth. I have my own doubts about it being _literally_ true, but I feel that the underlying idea that "the longer a bug persists through the development process the costlier it becomes to fix" is true.
Reposting it on Lobsters, hwayne had a nice counterpoint to it:
https://lobste.rs/s/6ywivn/are_delayed_issues_harder_resolve...
Anyone that studied what TSP was supposed to do would get what he was talking about. It might be supporting that TSP's up-front and lifecycle efforts make late changes in lifecycle easier rather than that non-TSP projects can easily make late changes.
https://lobste.rs/s/6ywivn/are_delayed_issues_harder_resolve...
Anyone that studied what TSP was supposed to do would get what he was talking about. It might be supporting that TSP's up-front and lifecycle efforts make late changes in lifecycle easier rather than that non-TSP projects can easily make late changes.
As far as costs go, 90% of it is in the "maintenance" phase from and usually be other developers, something this didn't address.
Brevity certainly helps there but only up to a point, usually the most concise languages are the dynamic ones which can be much harder to maintain.
Brevity certainly helps there but only up to a point, usually the most concise languages are the dynamic ones which can be much harder to maintain.
This is a paper from 1994. C++ seems very different to me now vs the early 90s.
Every language in that list is vastly different from its 90s version.
C++ changed a lot more than Ada, though. Ada was well-designed from start.
If I remember correctly, in 1994 the STL and its associated patterns were in its utmost infancy, so compared to the old "Modern C++" or today's lambda/task/auto C++, any language will be strong & stable.
Still, there have been some changes since Ada83...
Still, there have been some changes since Ada83...
[deleted]
> C++ seems very different to me now vs the early 90s.
True, but it's still very far from optimal. For something MUCH closer to optimal, see Rust.
All that said, from a practical standpoint I think Julia is near perfect as both a prototyping and implementation language, with the ability to drop to Rust/C/assembly easily as needed.
High productivity, and C-like performance. That's a sweet spot.
True, but it's still very far from optimal. For something MUCH closer to optimal, see Rust.
All that said, from a practical standpoint I think Julia is near perfect as both a prototyping and implementation language, with the ability to drop to Rust/C/assembly easily as needed.
High productivity, and C-like performance. That's a sweet spot.
I am fully invested in Julia but I have found it's far from being productive for large scale projects. It's hard to encode interfaces and invariants (in practice this is done by documentation instead of code) and code is not very self documenting.
I expect it to get there over the next years though. And it otherwise his a perfect sweet spot for us.
I expect it to get there over the next years though. And it otherwise his a perfect sweet spot for us.
Worse than python?
Is Julia used for general purpose programming? I hear of it only in the context of Data Science.
I'm generally interested in programming languages and have taken a look at hundreds, if not thousands in the past decades. Based on that experience, I'd say that almost no language is a general purpose programming language, because that would include cross-platform GUI programming. Except for C, C++, and Python, every binding to GUI toolkits I've seen was incomplete, buggy and not fully tested, not ready for prime time, eternally promising without ever getting there, lagging behind the toolkit versions, hard to setup and compile, and so forth. There is always something about the glue code, versioning, or portability that gets in your way.
Typical example: I've decided to make a little GUI application in gtk3 for Go and encountered the first show-stopper already after two weeks. Yes, in theory this can be fixed by adding bindings yourself and submitting pull requests, but once you start with this it kind of defeats the purpose of using another language in the first place. (And there is a second issue of this kind already waiting in line...)
The same is true for Julia, which I have evaluated for this purpose, too. The GUI bindings are not yet complete, and experience has told me that if bindings are not yet complete, there is a high chance they will never be complete. Once they are completed, they are already outdated.
So if you include GUI applications into "general purpose", the answer is practically always "No". If you exclude GUI applications, on the other hand, then almost every programming language on earth is sufficiently general purpose.
Typical example: I've decided to make a little GUI application in gtk3 for Go and encountered the first show-stopper already after two weeks. Yes, in theory this can be fixed by adding bindings yourself and submitting pull requests, but once you start with this it kind of defeats the purpose of using another language in the first place. (And there is a second issue of this kind already waiting in line...)
The same is true for Julia, which I have evaluated for this purpose, too. The GUI bindings are not yet complete, and experience has told me that if bindings are not yet complete, there is a high chance they will never be complete. Once they are completed, they are already outdated.
So if you include GUI applications into "general purpose", the answer is practically always "No". If you exclude GUI applications, on the other hand, then almost every programming language on earth is sufficiently general purpose.
I used it recently to write something at work that would count as "an application", and it was so much more pleasant than writing the equivalent in Python would have been. Having a proper type system and multiple dispatch really makes a huge difference, and immutability by default and rejection of OO makes for code that's really easy to reason about.
Julia's "niche" is essentially an improved, free Matlab. At least, that certainly seems to have been its initial impetus.
Now it's grown far beyond that, and is acknowledged by its creators as a true, general-purpose language.
One example is its use in real-time robotics:
http://www.juliarobotics.org/
Now it's grown far beyond that, and is acknowledged by its creators as a true, general-purpose language.
One example is its use in real-time robotics:
http://www.juliarobotics.org/
Yes.
see this as an example: http://genieframework.com/
see this as an example: http://genieframework.com/
Julia attracts people that are interested in data science, but it's also a very capable language outside of that field.
I love awk within certain domains, but the the overlap between where awk is suitable and something big and complex enough to serve as a good example of programmer productivity is essentially nil.
There are some gems in the results section though:
> It is interesting to note that the developer originally reported only 101 lines of code, but fully admitted attempting to pack as many statements into each 80-column row as possible! The line count of 250 is based on looking at the actual code in [LBK+94] and estimating a line count based on a more “reasonable” notion of program formatting.
There are some gems in the results section though:
> It is interesting to note that the developer originally reported only 101 lines of code, but fully admitted attempting to pack as many statements into each 80-column row as possible! The line count of 250 is based on looking at the actual code in [LBK+94] and estimating a line count based on a more “reasonable” notion of program formatting.
Interesting that the lisp prototype took the least amount of time to develop, yet was considered less understable code than the haskell prototype(s).
I thought it was interesting how quickly the lisp result was dismissed. I'm not particlularly partisan one way or the other, and it's to the authors' credit to have included it at all. However, this is a paper with "foregone conclusion" written all over it.
If it used macros I bet that had some effect on the ranking. Macros and CLOS are two things that really take some time to sink in and understand for programmers that don't use lisp much.
I bet it did.
In the extreme case, using macros makes every program a slightly different DSL.
In the extreme case, using macros makes every program a slightly different DSL.
I don't think they wrote any macros.
The language they used is Common Lisp with a special library for programming with relations on top. So they used a DSL library for relational programming. Something like a Lisp with a kind of in-core database with a rich language for it.
That kind of programming is extremely rare.
The language they used is Common Lisp with a special library for programming with relations on top. So they used a DSL library for relational programming. Something like a Lisp with a kind of in-core database with a rich language for it.
That kind of programming is extremely rare.
What this tells me most of all, is that humans will only acknowledge the legitimacy of studies that support their predetermined opinions.
The arguments for and against a type system like Haskell's have been going on seemingly forever, and the commonly parroted line from e.g., Clojure or JavaScript enthusiasts (like the curly-haired San Francisco guy) is that there has never been a single study to support the idea that a type system like Haskell's is generally a cheaper way to write reasonably robust software. Point them to a study like this, and you're met with "Nuh-uh! Not valid! Nope!"
My observation is supported by section 7, "Lessons Learned".
> …The reaction from the other participants, however, in particular those not familiar with the advantages of functional programming, was somewhat surprising, and is worth some discussion.…
> …In conducting the independent design review at Intermetrics, there was a significance sense of disbelief.
> …some observers have simply discounted the results because in their minds the use of higher-order functions to capture regions was just a trick that would probably not be useful in other contexts. One observer described the solution as “cute but not extensible”
> We mention these responses because they must be anticipated in the future. If functional languages are to become more widely used, various sociological and psychological barriers must be overcome. As a community we should be aware of these barriers and realize that they will not disappear overnight.
They're right. These barriers haven't disappeared overnight. They haven't even disappeared after a quarter of a century. People still come up with stupid reasons why they don't like Haskell.
The arguments for and against a type system like Haskell's have been going on seemingly forever, and the commonly parroted line from e.g., Clojure or JavaScript enthusiasts (like the curly-haired San Francisco guy) is that there has never been a single study to support the idea that a type system like Haskell's is generally a cheaper way to write reasonably robust software. Point them to a study like this, and you're met with "Nuh-uh! Not valid! Nope!"
My observation is supported by section 7, "Lessons Learned".
> …The reaction from the other participants, however, in particular those not familiar with the advantages of functional programming, was somewhat surprising, and is worth some discussion.…
> …In conducting the independent design review at Intermetrics, there was a significance sense of disbelief.
> …some observers have simply discounted the results because in their minds the use of higher-order functions to capture regions was just a trick that would probably not be useful in other contexts. One observer described the solution as “cute but not extensible”
> We mention these responses because they must be anticipated in the future. If functional languages are to become more widely used, various sociological and psychological barriers must be overcome. As a community we should be aware of these barriers and realize that they will not disappear overnight.
They're right. These barriers haven't disappeared overnight. They haven't even disappeared after a quarter of a century. People still come up with stupid reasons why they don't like Haskell.
> Point them to a study like this, and you're met with "Nuh-uh! Not valid! Nope!"
Are they really saying that or did they point out the small sample size, age of the study, inconsistent preparation of the participants, and ask about whether it had been replicated? I mean, the authors themselves acknowledge this and it'd be interesting to know how they would view it a couple of decades later, especially since there have been huge improvements across the board in languages and things like quality of tooling, availability of documentation, etc.
Unfortunately, the way you chose to start that post sounded like you were assuming that any position which didn't support your favorite language couldn't be correct. I think that's just as unproductive as the sentiment you complained about, especially because one of the big trends over the last couple of decades has been appreciation for the exact concepts you quoted in other languages. People are writing more functional-styled code than ever before so it seems more likely that extremely complex and important decisions like choice of programming language aren't driven by a single purity test.
Are they really saying that or did they point out the small sample size, age of the study, inconsistent preparation of the participants, and ask about whether it had been replicated? I mean, the authors themselves acknowledge this and it'd be interesting to know how they would view it a couple of decades later, especially since there have been huge improvements across the board in languages and things like quality of tooling, availability of documentation, etc.
Unfortunately, the way you chose to start that post sounded like you were assuming that any position which didn't support your favorite language couldn't be correct. I think that's just as unproductive as the sentiment you complained about, especially because one of the big trends over the last couple of decades has been appreciation for the exact concepts you quoted in other languages. People are writing more functional-styled code than ever before so it seems more likely that extremely complex and important decisions like choice of programming language aren't driven by a single purity test.
>They're right. These barriers haven't disappeared overnight. They haven't even disappeared after a quarter of a century.
The barriers disappeared since functional concepts were absorbed into other languages. Almost all languages have higher order functions. Many languages have a preference for immutable data. Recursion was rightly not adopted as iterators are a better solution - keep the map/filter/fold, leave the TCO.
>People still come up with stupid reasons why they don't like Haskell
One expects that if Haskell was superior, then it would be impossible for successful Haskell projects to materialize as they've done with Python, Go, Rust, Java, C++. And yet, successful Haskell projects are rare. There must be a because there is a hidden variable that this study in 1994 didn't capture.
There's certainly not a cabal of project managers forcing C++ down peoples' throats. So instead of calling the reasons stupid, why not try to find out what this hidden variable is?
The barriers disappeared since functional concepts were absorbed into other languages. Almost all languages have higher order functions. Many languages have a preference for immutable data. Recursion was rightly not adopted as iterators are a better solution - keep the map/filter/fold, leave the TCO.
>People still come up with stupid reasons why they don't like Haskell
One expects that if Haskell was superior, then it would be impossible for successful Haskell projects to materialize as they've done with Python, Go, Rust, Java, C++. And yet, successful Haskell projects are rare. There must be a because there is a hidden variable that this study in 1994 didn't capture.
There's certainly not a cabal of project managers forcing C++ down peoples' throats. So instead of calling the reasons stupid, why not try to find out what this hidden variable is?
> There's certainly not a cabal of project managers forcing C++ down peoples' throats. So instead of calling the reasons stupid, why not try to find out what this hidden variable is?
Project managers do still matter. I've had an incredibly hard time convincing my current project manager that pure FP languages will pay off for us and that's even after showing code that abstracts over what we do in other languages in fewer lines and with more extensibility.
I've shown things that are impossible to do without higher-kinded types that solve real issues we've had that have impacted business. I've also shown a lighter version of that relying on phantom types to solve the same problem, in order to show that there are levels to this. The core of the problem lied in ensuring that logged data was anonymized. This is something you can encode in the type system with no runtime overhead so that it's impossible to log something that's not pre-sanitized.
It's very hard to convince someone who's experience extends to Java & JavaScript that there are languages that allow you to more precisely and safely encode business logic in ways that make misuse hard if not impossible. It's even harder to convince those people that the overhead of learning something like PureScript will be amortized by the ease of maintenance that you get out of it.
The main issue, as far as I see it, is that we continually solve all the issues that arise from our lack of good language choices. We've yet to end up in a situation so bad that we can't solve it within a day, which makes our choices "good enough". The "good enough" that you have right before you is better than the seemingly unknown that someone is promising you and no amount of code examples addressing your issues is going to change that.
Project managers do still matter. I've had an incredibly hard time convincing my current project manager that pure FP languages will pay off for us and that's even after showing code that abstracts over what we do in other languages in fewer lines and with more extensibility.
I've shown things that are impossible to do without higher-kinded types that solve real issues we've had that have impacted business. I've also shown a lighter version of that relying on phantom types to solve the same problem, in order to show that there are levels to this. The core of the problem lied in ensuring that logged data was anonymized. This is something you can encode in the type system with no runtime overhead so that it's impossible to log something that's not pre-sanitized.
It's very hard to convince someone who's experience extends to Java & JavaScript that there are languages that allow you to more precisely and safely encode business logic in ways that make misuse hard if not impossible. It's even harder to convince those people that the overhead of learning something like PureScript will be amortized by the ease of maintenance that you get out of it.
The main issue, as far as I see it, is that we continually solve all the issues that arise from our lack of good language choices. We've yet to end up in a situation so bad that we can't solve it within a day, which makes our choices "good enough". The "good enough" that you have right before you is better than the seemingly unknown that someone is promising you and no amount of code examples addressing your issues is going to change that.
> And yet, successful Haskell projects are rare. There must be a because there is a hidden variable that this study in 1994 didn't capture.
I'd argue that Haskell projects are just rare generally, at least partly for the reasons described in the study. It's not debatable that so much of a technology's adoption comes primarily down to network effects, and not a technology's technical merit alone.
I'd argue that Haskell projects are just rare generally, at least partly for the reasons described in the study. It's not debatable that so much of a technology's adoption comes primarily down to network effects, and not a technology's technical merit alone.
> It's not debatable that so much of a technology's adoption comes primarily down to network effects, and not a technology's technical merit alone.
Ok. I put to you that if a technology's adoption primarily comes down to network effects, then other languages will also suffer from adoption.
Since 1994:
Java was released in 1995. But this surely won't count because this was funded and shoved down our throats by Sun. Just as C# was funded by Microsoft or Swift and Objective C are funded by Apple
Ruby became a big deal in the web arena thanks to Rails.
Python became bit in sysadmin tools and moved in data analysis (competing with R and Matlab). It's also fairly big in web projects.
Golang became big in sysadmin tools and network applications. It was started by Google but it wasn't really a part of any platform that was being shoved down peoples' throats like Java or .Net.
Erlang became was fundamental to Facebook's first version of their chat, Whatsapp's first version of /their/ chat, Google's first version of //their// chat, Discord's current version of ///their/// chat[1]. RabbitMQ is/was a popular message queue implemented in Erlang.
But where are the Haskell projects?[2] The data suggests there is another variable here.
[1] Discord uses Elixir, but this is built off Erlang's VM so it's Erlang technology. Agree or disagree, I don't think that it detracts from the point.
[2] They are here: https://wiki.haskell.org/Haskell_in_industry
Ok. I put to you that if a technology's adoption primarily comes down to network effects, then other languages will also suffer from adoption.
Since 1994:
Java was released in 1995. But this surely won't count because this was funded and shoved down our throats by Sun. Just as C# was funded by Microsoft or Swift and Objective C are funded by Apple
Ruby became a big deal in the web arena thanks to Rails.
Python became bit in sysadmin tools and moved in data analysis (competing with R and Matlab). It's also fairly big in web projects.
Golang became big in sysadmin tools and network applications. It was started by Google but it wasn't really a part of any platform that was being shoved down peoples' throats like Java or .Net.
Erlang became was fundamental to Facebook's first version of their chat, Whatsapp's first version of /their/ chat, Google's first version of //their// chat, Discord's current version of ///their/// chat[1]. RabbitMQ is/was a popular message queue implemented in Erlang.
But where are the Haskell projects?[2] The data suggests there is another variable here.
[1] Discord uses Elixir, but this is built off Erlang's VM so it's Erlang technology. Agree or disagree, I don't think that it detracts from the point.
[2] They are here: https://wiki.haskell.org/Haskell_in_industry
As with all attempts at making big lists insiders don't really care about this one is perpetually out of date.
Every time someone posts a message on Facebook it goes through an anti-spam system written in Haskell by way of their `Haxl` monad which automatically batches resource requests, "figures out" what it can fetch concurrently (not really, it's a feature of `Applicative` vs. `Monad`).
People go on and on about how Haskell is niche, but I haven't made a job search in a long time where there weren't more results for Haskell than Erlang, for example. Among the rarer languages it's clearly one of the more popular ones. Yet, here we are, people talking about it as if it's somehow less used in industry than all of the other FP languages.
OCaml is an interesting example. Usually people who haven't used either language outside of a few Sundays here and there will talk about how OCaml is more practical than Haskell and is the more obvious choice for industry... But on just indeed.com as an example it currently has 63 listings with the top ones being for developers in other languages. Haskell has 479 (again it's popular to search for Scala developers by saying they ought to know Haskell).
Every time someone posts a message on Facebook it goes through an anti-spam system written in Haskell by way of their `Haxl` monad which automatically batches resource requests, "figures out" what it can fetch concurrently (not really, it's a feature of `Applicative` vs. `Monad`).
People go on and on about how Haskell is niche, but I haven't made a job search in a long time where there weren't more results for Haskell than Erlang, for example. Among the rarer languages it's clearly one of the more popular ones. Yet, here we are, people talking about it as if it's somehow less used in industry than all of the other FP languages.
OCaml is an interesting example. Usually people who haven't used either language outside of a few Sundays here and there will talk about how OCaml is more practical than Haskell and is the more obvious choice for industry... But on just indeed.com as an example it currently has 63 listings with the top ones being for developers in other languages. Haskell has 479 (again it's popular to search for Scala developers by saying they ought to know Haskell).
They're rare because attempts to actually use Haskell in the field result in disaster. When you're hiring random programmers off the street to code your shitty business logic in Haskell, the result is a horrible mess of 'Unsafes, exploding memory leaks and random crashes. It's a train wreck.
That's why you don't hire random programmers. You hire good ones, or you develop a training program and ensure they're good before you give them the responsibility for making or breaking your business.
Why would anyone trust "random programmers" to some of their most critical business efforts?
Why would anyone trust "random programmers" to some of their most critical business efforts?
Because random businesses don't know how to hire good programmers. (In fact, even good businesses struggle with it.)
While that may be true to some extent, it doesn't further the discussion because it makes the point moot.
For the purposes of discussing the technical merits between different technology alternatives, we must assume some baseline competency of programmers. Otherwise the point becomes "technology doesn't matter because programmers are all stupid", which is not a constructive discussion.
For the purposes of discussing the technical merits between different technology alternatives, we must assume some baseline competency of programmers. Otherwise the point becomes "technology doesn't matter because programmers are all stupid", which is not a constructive discussion.
otabdeveloper1 said (four parents to this post) that there aren't many successful Haskell projects because businesses can't (or at least don't) hire good programmers. Jtsummers said to hire good ones, or train them to be good.
So in context, you could read my post as saying that run-of-the-mill companies don't know how to hire good Haskell programmers.
> For the purposes of discussing the technical merits between different technology alternatives, we must assume some baseline competency of programmers.
No. If it's harder to find good Haskell programmers than it is to find good Python programmers, that absolutely has to be figured in. It's not a technical merit of Python or a technical flaw of Haskell, but it certainly has to be factored into the decision of which to use.
Perhaps the summary would be "Technical merit doesn't matter if all the good programmers for that language are unavailable."
Then there's the problem that, even though we have a good track record of hiring good C++, Java, and Objective C programmers, I am not sure that we would be competent at selecting good Haskell programmers, even if they were available.
So if I'm the CTO of RandomCo, I probably don't use Haskell for that new project, no matter how technically good the language is, because I can't identify, locate, and hire good people for the team. And bad people for the team can turn Haskell into... something less.
So in context, you could read my post as saying that run-of-the-mill companies don't know how to hire good Haskell programmers.
> For the purposes of discussing the technical merits between different technology alternatives, we must assume some baseline competency of programmers.
No. If it's harder to find good Haskell programmers than it is to find good Python programmers, that absolutely has to be figured in. It's not a technical merit of Python or a technical flaw of Haskell, but it certainly has to be factored into the decision of which to use.
Perhaps the summary would be "Technical merit doesn't matter if all the good programmers for that language are unavailable."
Then there's the problem that, even though we have a good track record of hiring good C++, Java, and Objective C programmers, I am not sure that we would be competent at selecting good Haskell programmers, even if they were available.
So if I'm the CTO of RandomCo, I probably don't use Haskell for that new project, no matter how technically good the language is, because I can't identify, locate, and hire good people for the team. And bad people for the team can turn Haskell into... something less.
Ok, I understand the concern, but I don’t think it reflects the market, at least at the scale I operate in.
It’s the same as when DHH was asked about hiring Ruby developers a little over ten years ago. The question was “why would I use Ruby when there are far fewer developers that know it? Why not just use PHP since there are thousands of PHP developers available?”
The answer being “how many developers do you need? Thousands? Probably not. You probably need two or three.”
I did a hiring round for Haskellers recently for my startup, and we were spoiled for choice. There are so many brilliant people available, and we can’t hire them all.
It’s the same as when DHH was asked about hiring Ruby developers a little over ten years ago. The question was “why would I use Ruby when there are far fewer developers that know it? Why not just use PHP since there are thousands of PHP developers available?”
The answer being “how many developers do you need? Thousands? Probably not. You probably need two or three.”
I did a hiring round for Haskellers recently for my startup, and we were spoiled for choice. There are so many brilliant people available, and we can’t hire them all.
100% of my income is from web applications written in Haskell. I hire Haskellers, and it's been a positive experience so far. None of my projects use unsafePerformIO. I track metrics across everything, and I'm not suffering memory leaks or random crashes.
Everything you have said is nonsense.
Everything you have said is nonsense.
As a Haskeller, I am extremely wary of seeing this study linked to over and over again.
Julia is also getting there the fastest, IMHO.
> Haskell and C++ from 1994
What is this, the Guild of Legacy Crap Archeology?
What is this, the Guild of Legacy Crap Archeology?
As an experiment, some months ago we prototyped a new service in Haskell at work. We timeboxed a week for it (two people, proficient in Haskell), and the result is that (1) the Product Owners were really pleased with it, and (2) even if it was really bad Haskell code, we _still_ managed to encode business logic in the types so that it would always hold some important invariants. As a result we had to fix a surprisingly small amount of things before putting it in production.
The best thing is that as it happens we couldn't properly rewrite the prototype, so today's service is still the same codebase, BUT it's not a Python blob and it was such a breeze to refactor.
EDIT: would anyone be interested in a blog post "Rapid Prototyping in Haskell"?