willtim

> But they had to dislike it in a productive, nuanced manner.

No, they fundamentally rejected JavaScript, enough to build a whole new language and set of tools. This was not a subtle dislike of a few aspects of it.

Personally JavaScript absolutely terrifies me, it's a semantic mess, the equality table is one such example: https://dorey.github.io/JavaScript-Equality-Table/

> It has an incredibly powerful Hindley Milner system under the hood.

Scala does not use Hindley-Milner, which is why it has much poorer type inference compared to Haskell or OCaml. It uses subtyping to encode sum types and under many circumstances will infer "Any" for a type.

All high-level languages with optimising compilers have "non-compositional performance" as you say. The big issue with laziness is reasoning about space usage. A strict language is not immune to this however. If one builds lazy abstractions (e.g. Streams, collection views) in Scala, then one has the same problems.

You have a very valid point. As someone who uses Haskell professionally in a large organisation, I can honestly say that past changes such as FTP and AMP have added very little but caused significant issues for both academic and industrial users. GHC is no longer a Haskell 2010 compiler and unfortunately there seems little interest in the community for creating a new Haskell standard.

Monads are a pattern for sequential composition of effectful computations (i.e. statements). Some expessive languages, such as F#, Haskell and Scala support a special overloadable syntax for any arbitrary monad, therefore giving a fully programmable notion of statements.

For background reading in this area, perhaps start with "A poor man's concurrency Monad" by Claessen, it's a very easy read and shows how green threads can be written as a user library allowing pluggable schedulers. F# also implements its asynchronous workflows using essentially this technique, see "The F# Asynchronous Programming Model". LINQ and the reactive library Rx from C# are also great examples of Monads.

In a language that supports Monads (e.g. Haskell or Scala), the above could be implemented as a library.

> the fact that no single language or paradigm completely overtakes all others is evidence in favor of there not being a very big bottom-line impact.

Or perhaps because no paradigm is universally applicable to all cases. There will be a bottom line impact if the wrong tool is picked for the job.

A Crematorium Management System built in Microsoft Access is still a Crematorium Management System.

Beowulf had no shared memory abstraction, programs had to be written using message passing, e.g. MPI.

I'm not convinced a shared memory abstraction is a good thing for distribution across machines. Some Beowulf clusters actually had much lower latency interconnects than ethernet, e.g. Quadrics, but we still needed to carefully optimise the traffic. With a shared memory abstraction, such optimisation is out of our hands.

Why specify aluminium? For example, Magnesium alloy is 30% lighter and less prone to warps and dents. For Linux, I would consider a ThinkPad (T or X series) or a Dell XPS developer edition.

Is AMD now a better choice for Linux, especially given the ongoing stability problems with Intel's Linux graphics drivers?

I tried it recently and went back to i3. For me, Gnome didn't work well for multi-monitor setups and seems surprisingly lacking in customisations. It did seem very polished though.

I would add NixOS to that list. Especially if you value rolling back upgrades or pinning package versions.

Broadcom unfortunately has never been well supported on Linux. I've always used ThinkPads for running Linux and have never had these sorts of hardware issues (and I keep laptops for at least 8 years). You need to buy a machine with running Linux in mind (or more specifically, Debian, which has even less out-of-the-box hardware support for laptops).

Debugging declarative code is always hard, whatever the language. Haskell does allow you to use trace expressions which will output values to standard out, see Debug.Trace.

This is no reason to avoid arguably the most popular (and state-of-the-art) function language and implementation out there.

The Sony's have +5db of exaggerated bass that cannot be EQ'd out on the headphones when using LDAC. Without EQ, I find them completely unlistenable for jazz or classical music. I kept them as I only use them with one device (so EQ is practical) and the NC is very good.

I remember buying "Linux - unleashing the workstation in your PC" circa '94 which had the tag line "friends don't let friends use DOS !". I was quite stunned at how much better it was than DOS/Windows at the time. I've been a Linux user ever since!

Python seems to be the new "beginners" programming language (the "B" in Basic), it's taught in schools now and makes Basic look rather archaic in comparison. So I would say the writing is on the wall. What was good about Visual Basic was the IDE and GUI builder. Sadly this has no real modern competitor in terms of ease of use.

There are many good points about KDB/Q the product (most of all simplicity) and it certainly was well-engineered. But K is not a modern language and its performance is only impressive as an interpreted language; and these gains come at a significant cost (various limits on expression sizes / variable counts / branch sizes, no closures, poor error messages). It's only really "fast" on bulk operations, much like Python.

If you want to see what a modern K or Q might look like (with static types and an embedded JIT compiler!), checkout the excellent Hobbes project from Morgan Stanley: https://github.com/Morgan-Stanley/hobbes

> Java didn't have generics until version 5 in 2004; the ML family had it in 1990.

I thought Standard ML had it in the 70's (!)

The Kubernetes codebase would probably be a lot less complicated, if Go the language itself were not so simple: https://medium.com/@arschles/go-experience-report-generics-i...

> Imperative programs can have isolated, pure subsections of functionality which are based on composition and immutability.

And functional programming languages can support imperative programming and mutation, even Haskell. It's a question of what should be the default, which depends on the domain you are working in.

> Any real banking system has much more than a ledger to deal with.

Most banking systems are cobbled together from third-party components and libraries. Low-level languages aren't really needed. Many banks use Python, which is orders of magnitude slower than Haskell.

> This comment strikes me as if it comes from someone who never dealt with significant amount of data.

Actually I have a background in distributed computing, where functional programming abstractions have made processing large amounts of data much easier (MapReduce, Spark).

> FP can be extremely wasteful; take head-tail lists for example, which are the default container in many FPs.

This is a strawman. I can write inefficient code in any language. C++ code can be littered with pointer indirection and memory barriers.

> Sometimes, arguing with FP purists feels like debating socialists.

I am a socialist.

50 years ago 99.9% of computer programs were written in completely imperative assembly language programs, such that even arithmetic involved statements and temporary mutable variables. Fortran was a more mathematical higher-level language with boolean and arithmetic expressions. Functional programming just continues this trend, resulting in more mathematical, higher-level declarative languages, which as far as I am concerned, makes them more suitable for modelling real world business problems.

All the more reason to explicitly model time and not conflate it with the system runtime. As an example, banks have always added entries to a ledger such that the time history of events is explicit and preserved. Functional programming models this very well. An imperative programmer would probably write the final balance on a post-it note in pencil so that it could be destructively updated. Some OOP programmers have actually tried to model banking like this, because their language encourages it.

Another example might be a text editor buffer. Immutable persistent data structures allow one to get many features for free such as versioning, undo, lockless autosave. Memory is cheap now, there's less of a need to throw away some my edits with destructive updates. Even filesystems and databases have realised this is good idea. Destructive updates are bad for valuable data.

Imperative programming is only better for writing low-level system code, which is full of state that ultimately no one in the real world cares about.

My 6 year old does the grip first described in the post. Her school teacher has shown much apathy in correcting it and even suggested it was "too late" (UK state school). I'm going to try and help her myself. Tips include shorter pencils and "pinch and flip": http://mamaot.com/3-tricks-to-help-kids-learn-to-hold-their-...

Purity applies to the process of program construction. This is still very valuable, as I can better reason about program correctness.

Why? Monads [from category theory] were [applied in comp sci] as a way to give imperative programs formal semantics. Making use of them to retain referential transparency in the presence of effects is probably Haskell's greatest success. [Edited for clarity].

> But solving problems with type systems is not a business goal. Increasing correctness is.

I gave an example of increasing correctness in the context of record data types, something almost every business app does.

> The same ones that formal methods research focuses on (for deep properties): model checking and concolic testing, which have shown much better scalability than deductive methods.

And these are good alternatives for some classes of problem, but how would I use them to type check a SQL query?

> There are easier ways, like Java's permission system, that I mentioned elsewhere.

Hmmm I have my doubts that this is really fit for such a purpose, otherwise why are there various efforts to build a deterministic JVM?

I'm not arguing for languages like Go. I'm saying that Go code will be forever difficult to reason about, no matter what future features they decide to add to it. Using Haskell as another example, it has grown immensely, but never compromised on purity.

It's not what you add to a language that's important, it's what you take away.