Haskell, Ada, C++: An Experiment in Prototyping Productivity (1994) [pdf]
haskell.cs.yale.edu
haskell.cs.yale.edu
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"?
would be fantastic.
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.
Yes. Please.
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.
Here's the video I got the Dr Dewar quote from: https://www.youtube.com/watch?v=0yXwnk8Cr0c
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.
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.
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.
Still, there have been some changes since Ada83...
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.
see this as an example: http://genieframework.com/
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.
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:
I expect it to get there over the next years though. And it otherwise his a perfect sweet spot for us.
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.
In the extreme case, using macros makes every program a slightly different DSL.
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 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 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?
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.
Everything you have said is nonsense.
Why would anyone trust "random programmers" to some of their most critical business efforts?
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.
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.
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.
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
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).
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.
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.
What is this, the Guild of Legacy Crap Archeology?