[1] https://www.haskell.org/communities/05-2017/html/report.html
On to the topic of this submission itself, Elm turned out to be a gateway drug to Haskell for me. Similar to Paul Chiusano[1] I decided to switch from Elm to GHCJS (Haskell). I started with https://haskell-miso.org/ (based on the Elm architecture) but I'm currently developing using http://docs.reflex-frp.org/
[1] https://pchiusano.github.io/2015-04-23/unison-update7.html
Haskell is also astoundingly terse. In Java and C my data type declarations were too long to fit on a page, full of redundancies and boilerplate. In Haskell if you want to make, say, a data type that is either an X or an O (suppose you're writing tic-tac-toe), you could do it in four words: 'data XO = X | O'. (Notice that there's not even a natural way to do that in Java or C, because they don't have sum types; you'd have to make a type that has a flag to indicate whether it is an X or an O. That gets really complicated if they're supposed to have different data associated with it -- but in Haskell, if the X is supposed to carry a float and the O is supposed to carry a string, you just add two more words.)
Pattern matching also helps with terseness. I don't have time even to write the last paragraph so I'll skip this one.
Purity keeps you from tripping up on IO-related errors. It lets you be much more certain that things are working. It also forces you to keep the IO in a thin top-level layer of your program, which might sound like a pain but once it feels natural you'll find yourself moving faster than you could before.
To be sure, Haskell has features that I don't use. But purity, sum types, pattern matching, and the unusually rigorous (it's complete!) type system are all critical to its value to me.
I'm currently dealing with it in a large swift project, and I would much rather go back to the extra verbosity of objective-c than have type inference at this point.
But that was insightful, thank you!
I remember vaguely reading about how at a haskell conference people were basically cornering compiler maintainers about compile speed, but that was several years ago.
My codebase is only a few thousand lines, though.
In the case of rust, I suspect one of the biggest issues is the way parametric polymorphism is implemented. Basically, if in your program you end up using e.g. Box<usize>, Box<MyType> and Box<Result<String>>, you're compiling Box 3 times.
I don't know enough about swift to hazard a guess as to where the build is spending its time.
My experience with Haskell is that compile times are neither great nor terrible.
Clojure and Scala give you an alternative to Python that have the power of the Java ecosystem to take your programming out of academic and toy projects.
And Python finally has static typing, 10 years after it was announced.
If you want to approximate the cool things in Haskell with a Python-compatible* language, there's Coconut. In addition to static typing, it offers algebraic data types (how I lived without sum types, I don't know) and pattern matching.
* every valid Python program is valid Coconut
Why is this not more popular? Coconut seems like something many people, including me, would want to use for every Python project of sufficient complexity. What's the catch?
The catches:
1. You have to be OK with a compilation step that isn't part of the Python world.
2. To the best of my knowledge the language has been and still is being developed by a single person, so there's the "Evan gets hit by a bus" risk built in.
3. Tooling is virtually nonexistent. There's a Vim plugin that understands the language syntax but there's zero IDE support. Of course you can debug the generated Python with Pycharm/VS Code/etc and having done it I can say it's not terribly painful but isn't terribly fun either.
I think that over time the lack of tooling will be the biggest hindrance to the language's further adoption. OTOH I'd be curious to know if this has been a major factor in other unpopular languages remaining unpopular. I seem to remember a lot of complaints about tooling in the early days of Scala but the language still managed to become fairly successful once that situation improved.
Edit: formatting, final thoughts
- Types are checked before run time
- Type errors are reported
If that's not static typing, what is?
Just because mypy is optional doesn't mean it's not static typing.
- Most Python expressions and standard library functions would have (nontrivial) types
- It would be unusual for a Python library to come without (nontrivial) types
- It would be unusual for Python code containing type errors to be distributed
- Many classes of runtime errors (e.g. no such method) would be unusual in Python code that does not contain type errors
> Python 3 supports type annotations natively
And:
> the mypy tool is an external typechecker that you can run just like any other static analysis tool
I think I was pretty clear that Python is not statically typed.
In this way, both your statement and the parent's statement can be simultaneously true.