If you are able to master all the language changes between minor releases, master every language feature across objects, metaprogramming, functional, old style classes, multiple inheritance, slots,...., the complete standard library, and all major third party libraries, I bow to thee.
Yeah, that's stretching it to absurdity.
Python is easy to get started, and easy to adopt any of the extra features (e.g. slots, metaprogramming, async, etc) piecemeal. And easy to read most codebases.
Haskell is not easy to get started, not easy to adopt the extra features piecemeal, and not easy to read most codebases.
Easy to be a Python black belt certainly not.
While it looks like piecemeal to adopt metaprogramming, decorators, multiple inheritance, slots, operator overloading, extension of built in types, generators, async/await, their use combined in the hands of clever programmers, is anything but easy.
Doing Python since version 1.6.
Perhaps, but that's a different goalpost...
Plus it's still easier to be a Python black belt than a Haskell one...
>Doing Python since version 1.6.
Doing Python since 1.5 (at university) and 1.6 professionally. A remember when it didn't have half of its current constructs...
Agreed
> and not easy to read most codebases.
Hmm ... debatable. I have to dig in to the implementation of Python libraries and Haskell libraries regularly. I'm much more confident that I'll come away understanding the latter than the former!
> not easy to adopt the extra features piecemeal
I can't see any evidence of this. Can you name a few Haskell features that can't be adopted in the absence of other features?
How about the common task of CSV file manipulation? Database access? (Simplest of FFI.) Not reopening nor reparsing the file every time you want to do something? At the same time, with known upper bound on memory use?
Note how almost none of standard CRUD and web stuff is easy to write in Haskell from scratch and libraries do not help a lot.
You always end up in some variant of IO monad, typically multiple incompatible ones at the same time, making the pure functional nature of the language moot. You get to glue the various kinds of IO explicitly.
Haskell feels like writing a CPU (high level state machines everywhere), except with less readability and more verbiage than Verilog. The propensity of Haskell programmers to abbreviate everything and add redundant "helper" functions under different names does not help.
Programming is stateful because world has a state, and Haskell's handling of state is annoying at every step even for someone versed in it.
Secondly, are you really saying you believe that Haskell doesn't have all these features? That there aren't good ways of mutating arrays, writing CRUD apps, combining effects, etc.? Presumably then, your jaw would hit the floor if I could demonstrate that everything you believe is false.
There's plenty of shade you can throw at the good old snake, be it package management, performance / speed, formatting peculiarity but this one is the most unlikely I can think of.
What does it make it not easy in your mind?
Python is a language where, by default, a typo is a potential runtime error. That's far from easy in my book.
These bugs enter your system and manifest in such weird ways that it always will be the job of unit and integration testing, not static typing, to catch them. Not with modeling states in the type system. Not with phantom types. Just nope. Frankly to me this is what distinguishes a senior engineer from junior engineers in statically typed languages. Do they understand the language design faculties don’t actually protect them, abandon the misguided idea of encoding protection into the language’s special faculties, and instead put that effort towards making the testing infrastructure easy to understand and update and very fast to run.
This is fascinating. You are basically the only person I know who has used Haskell extensively who claims this. Have you considered writing up your experience as a blog post (or even more formally as a technical report)? I think it would be extremely helpful to the programming community and particularly the Haskell sub-community for you to share your point of view.
But in terms of me ever wanting to write this up with rigorous technical examples, I mean, just look at the level of discourse and tribal downvoting in a thread like this.
Even setting aside that this experience was spread across a quantitative trading company and in a large public financial technology company, meaning I definitely can’t publicly share a lot of details of those systems (which adds tons of required effort to convert examples into totally isolated tutorial-like standalone samples), why would anyone with a valuable technical dissenting opinion about Haskell want to open themselves up to that kind of religious backlash?
It’s demoralizing and discouraging for me even just in a thread like this one, where I’m just some mostly anonymous commenter talking subjectively about my experience in small comments.
There’s no way I’m sticking my neck out on a big technical blog post or technical paper about why leveraging a static type system doesn’t meaningfully reduce defects in real systems.
Also to be clear, I think static typing is fine. Some people enjoy it a lot or have clever ideas about using it for expressiveness. Some people also write amazingly concise dynamically typed code that covers a huge variety of use cases in a safe way with pretty much no overhead code to register anything at all about those use cases. People are free to choose their tools and whatever gets a job done is totally fine.
The part I find disingenuous is that it seems like only the static typing zealots are trying to come up with a reason to think a certain way of doing things strictly dominates or supersedes a different way of doing things, and it’s totally disingenuous to act like the benefits of static typing on defect rates would be such an argument for “universal” applicability of one certain paradigm.
It similarly turns me off into trying to discuss this constructively, even though my experience of Haskell is almost a complete opposite of what you're saying here. I guess that leaves space for only low-effort discussion and people happy to hear that Haskell turns out to not be worth it after all.
I will say, however, that just as I mentioned in my comment, I’m willing to say static typing is fine. There are lots of tools in a toolbox. It is one of them.
I don’t believe a lot of commenters who seek out this discussion would give a similarly charitable view of dynamic typing, and in my real life experience, these are people who superficially dismiss projects written in dynamic languages, especially Python, on parochial grounds not rooted in reality.
In other words, I see a lot of people in the Python community in real life saying, “Haskell is cool, you can do expressive things in it, but it makes certain other things hard and so for a wide range of tradeoffs I wouldn’t pick it.” But I see people in Scala, Haskell, Clojure, F# etc., communities saying, “Python is crap, so unsafe, so many bugs, it’s just a categorically wrong way to design and write programs.”
So the discussion is (in my experience) extremely asymmetrical along these programming religion lines.
Fine, but that's a criticism of the people not the language. I'm interested in the latter and not really in the former, unless you're trying to say that they are somehow linked.
I totally agree, and my dissenting opinion of Haskell is not based on anything about people or communities, just on ergonomics of using it and working on a big legacy codebase of it in production.
I mentioned the asymmetry of people who can be zealots about only one paradigm being The One True Way only in response to the parent comment I was responding to.
Let's hope there's another alternative: that those of us with seemingly opposite experience and opinion to mlthoughts2018 can encourage him/her to share more so that we can all learn something beneficial to our lives.
I am unqualified to assess the benefits of an advanced type system, after all, I've only worked through examples in a few Haskell books. I've never used Haskell professionally. Haskell is a lovely language. Its compiler is a remarkable achievement of computer science, mathematics, and engineering. Simon Payton Jones deserves the notable accolades and awards that he as received.
In my opinion, Haskell's most important contribution is in pushing the state of the art of programming languages forward. Is it practical? Yes, that too, but after all these years, it hasn't really become popular because being "practical" wasn't the main goal for Haskell. Haskell was designed to explore the non-strict functional landscape. Haskell's designers made good choices and were able to expand our understanding of non-strict functional programming (e.g. see Miranda [1]).
In the past I did years of research in program verification, so I'm naturally skeptical of the widely repeated claim that "Once your code compiles it usually works" (it's even on the haskell.org site). In what universe is this true? Verification that a program meets its specifications is quite difficult. In general, no compiler for Haskell can even verify that a program will terminate (the Halting Problem). I don't believe that real programmers are using Haskell's type system to formally verify total correctness (which includes freedom from deadlock, etc.) or even partial correctness (the weaker condition that if a program produces an answer that it is the correct answer).
I frequently write Python programs that work the first time; of course they are little scripts. It isn't dynamic typing that is keeping my programs from working more often. Consider the errors that I do make, syntax errors are caught by my IDE, I don't count those kinds of errors as real bugs. Next there are "type" errors, these aren't really troublesome even when I'm not using Haskell. I can find these almost immediately by testing or even using the REPL. (Every so often, I've heard of, say, a ruby program crashing once deployed because there is an untested path through the code that has a type mismatch between an argument and a function parameter. Haskell would catch this type of defect at compile time. That's good.) However, the really troublesome bugs are more subtle. Do the distributed parts have some kind of race condition? Am I handling the various spans of data within some vector correctly? Can an index touch memory outside of my memory segment? Is the floating point arithmetic doing what I think it should be doing? Have I translated the mathematics of wavelet compression correctly? Do I understand the Vandermonde matrix used in fast decoding of Reed-Solomon error correction codes--I don't! Haskell might be able to help with some of these harder bugs if the concepts can be properly represented in the type systems, but I believe that what mlthoughts2018 is saying is that this is often too hard to be worth it.
Haskell is a pioneering approach to programming, and the next frontier could be dependent types (see [2]). My own feeling is that someday programming will involve a dialog with a proof checker while coding. Writing proofs is hard, it seems harder to me than writing the program, so having an AI assistant that aids with the proof checking might make it more useful than simply struggling to encode a proof in the program's (dependent) types (see the Curry–Howard correspondence[3]).
[2] https://serokell.io/blog/why-dependent-haskell
[3] https://en.wikipedia.org/wiki/Curry–Howard_correspondence
In my experience, dynamic typing has not caused unforseen bugs at run time.
What it does do, is it causes large codebases to become extremely difficult to reason about, as you could get very little information about what types are needed or received where, and program flow, from the code.
Where I work, the managers decided that everything shall be python or ruby. So we have some 10,000+ line codebases, which are very hard to reason about. Including industrial control programs. "garbage collection pauses? What are those?"
Big codebases becoming ugly messes is sociological and pressured by bureaucracy. It is not something that stricter language designs can seriously mitigate, even a little. Meanwhile, very disciplined and experienced teams can avoid it in virtually any programming language.
Some of the cleanest and safest huge software systems I’ve ever worked with were written in C, C++ or Python. Also some of the worst huge systems I’ve seen were written in C, C++ or Python.
I'd love to read more about this experience (good and the bad).
You don't see "Python is easy" examples with full test suite attached to them, explaining that, well, you are in for a ride without those.
As for your comment: I can believe that production breaking typos may have been at a similar level. I don't believe that the effort to reach that level was the same, though.