At home I use a dragonfly red DAC paired with some open back sennheisers. But even when I'm out and about I benefit from FLAC. I use some noise cancelling Sony headphones which use the lossy LDAC codec over Bluetooth. My FLACs sounded noticeable better over LDAC, I guess because the music is only compressed once.
> Products built in haskell don't seem to have dramatically lower maintenance costs. They don't tend to have features that other products don't have.
That is your anecdote, mine is the opposite. Using Haskell at my place of work we have lower maintenance costs than other competitors that use Python. We also have features they don't have, such as checked purity (a guarantee that a financial calculation is reproducible) and transparent batching/caching/provenance (made possible by Haskell's expressiveness). None of this would be possible in Python or Java.
Language/notation, is IMHO critical for the ability to think using the right abstractions. To take your argument to the extreme, we should all be still using machine code, because tools don't matter.
There is unfortunately a large learning curve for production Haskell. It's a very different language to most imperative object-oriented ones, that are all broadly very similar. However, the concepts that folks will learn (Monads, Monoids, Functors, Profunctors etc etc) are taken from math and will likely be around for another 100 years. This is not disposable knowledge, and for me at least, it made a refreshing change from learning ad-hoc concepts from each successive OO fad framework I had to deal with.
There was a hackernews post yesterday where the top voted comment asserted that computer science and maths is (in practice) only useful for data structures and algorithms; everything else needed either physics or social science. This is why Haskell is important. Haskell will help teach people the mathematics behind program construction: how to write composable code, how to reason about effects, how to write consistent, general, less ad-hoc APIs.
Not true at all. We live in a world were marketing determines the standards used. The current trend is actually to give programmers less guidance on writing correct, composable code ("Dynamic" scripting languages).
Computer science and math is useful beyond just algorithms and data structures. Understanding the mathematics behind program construction would allow more programmers to write composable code and more general, re-usable, less ad-hoc APIs; and do a better job of gluing existing components together.
The Emacs bindings were designed for ease of learning, not ergonomics. For example C-n and C-p for next/previous, stretches the hand and uses the weak pinky for the very commonly used cursor keys (Vim uses the home row). I do use these bindings myself, but I strongly disagree that they are ergonomic or "excellent" (!)
XML and especially XML schema are hugely complex and almost laughably difficult to bind to any mainstream programming language. It took Java over a decade to produce a binding that could (perhaps) handle an arbitrary schema. Types boil down to sums and products, I'm not convinced the designers of XML/XSD understood this. XML has so many overlapping concepts: elements, attributes, enumerations, choices, unions, sequences, lists, element/attribute groups, substitution groups, facets, simple types, complex types etc etc
IMHO it's ad-hoc and ugly; we deserve better.
I actually still use the (admittedly awful) Emacs bindings. I have both ctrl and alt available as thumb keys on both sides (using a Kinesis Advantage). I also activate these modifiers using an opposite hand to avoid "chording". This was enough to fix my RSI and keep using the bindings I am familiar with.
The Kinesis Advantage completely cured my RSI. It's also much more pleasant to type on than any other keyboard I've tried. Worth every penny. I also use a Kensington Slimblade trackball for when I can't avoid moving a pointer.
With regard to the details sure, but the fundamentals should be studied and understood. That's why this blog is not attempting to recreate the entire of Microsoft Excel.
> It's a little known fact but the kind of FP programming we do in Scala tends to be more pure than what happens in OCaml, F#, Erlang, Clojure and others.
I have only dabbled in Scala, but IMHO it's more suited as an OCaml with first-class modules. Why not use Haskell, if you don't need the JVM?
It's a pure function because it doesn't do any IO. It returns an action that, when run, performs the IO. Because it's a pure function, we have referential transparency, we can safely replace the function call with its computed value (the action) anywhere in the program.
Lambda calculus is a lot simpler than Python. It bares a striking similarity to Gentzens natural deduction rules and is essentially isomorphic to it. It is also very well studied and its properties are well known. Hence it makes an excellent basis for a programming language. The idea that Lambda calculus was discovered and not invented was recently entertained by Phil Wadler. Given his academic credentials, I think we can assume he knows what he is talking about.
That programmers are becoming more interested in maths and the mathematics of program construction can only be a good thing. As someone clearly interested in maths, I am surprised you seek to attack them as "cults". I just see enthusiasm, no different to how folks have enthused about object-oriented programming for decades.
As Brian Goetz (Java Chief Architect) has said, Java will never become Haskell, but it will continue to take ideas from it. So even Oracle is drumming up interest in functional programming. About time I say, industry has been neglecting ideas from functional programming for too long.
At my UK state school in the 80s, they had a similar policy for musical instruments. They only gave music lessons to those that already were having private lessons (!)
My point is that your marketing is misleading. Use "strong dynamic types" if you must, but for Python, it would be more accurate to say "strongly tagged".
I believe that marketing Python as "strongly typed" has the potential to confuse rather than educate. Python still crashes at runtime with these errors. It has nice error messages, but it still crashes, potentially in production. If you want to create your own "types", you'll have to add your own runtime checks. It's much more sane than JavaScript, but it's not strongly typed like Haskell. Python does not automatically coerce some built-in runtime values, that's it.
In my industry, the companies that have standardised on Python and consequently now have large Python codebases are not very productive environments anymore. Perhaps they were once, for the first few people, in the first few months.
It's no surprise that the Python community has now started to try and retrofit types.
To understand the hate, you have to realise that no one likes being forced into using a particular technology. Especially one that is more of a lowest common denominator and ignores much of the progress in programming language research over the last 40-50 years (e.g. expressive static type systems, and Python still markets itself as "strongly typed").