I mean, it seems there is somewhere a sweet spot between lack of expressiveness and overcomplication.
I mean, it seems there is somewhere a sweet spot between lack of expressiveness and overcomplication.
However if Haskell had macros (like Perl 6's or even Lisp's), I'd jump ship from Lisp quite quickly. It's a mature language with the libraries I want.
What are you wanting that's missing from Template Haskell?
Quechua (from the Andean Mountains) only has three vowels (a, i, u). I can't find a reference, but AFAIK the main hypothesis was that a 3-vowel system made it easier to communicate across longer distances (i.e. across a canyon or valley in the Andes).
Text is a compact and efficient representation, more similar to strings in other languages.
As far as learning libraries: its not mandatory and you can code as well as anywhere else without them, but the "language enhancing libraries" are undeniably useful, and can do some incredibly useful things. Monad transformers let you merge computational contexts, Conduit lets you cleanly define stream transformations, Lens lets you manipulate specific aspects of some state in a context, etc.
Most of the debates either have answers (use Text instead of String, most of the time) or don't matter to most people (MTL vs transformers or monadLib). In my mind, it's no worse than trying to pick a JavaScript framework. If you're interested, give it a shot some day.
Functor (<$>)
Applicative (<*>, <*, *>)
Monad (>>=, =<<, >=>, <=<)
Monoid (<>)
Alternative (<|>)You cannot really have too much builtin operators, they are basically functions that don't depend on context (i.e. on type of the object). The only side effect is that some of them are not going to be used often and you'll need a quick way to look them up to be able to understand the code in those cases.
However, having too few of them is a problem that leads to contextual dual meaning operators (like '+' in many languages), related cognitive overhead and bugs.