ayberkt

Exactly. Even though I thought the author was bringing up an important point, I couldn't take them seriously due to the repeated finger-pointing and the conspiracy-theorist attitude.

I was living in Sweden at the beginning of the pandemic. I suspected that I had COVID multiple times and tried to get a test. The response I got from the Swedish healthcare system was: “it doesn't matter what you are infected with, just stay home”.

Even though the author does have a point, they overlook the fact that it's been much harder to get COVID tests in Sweden than the countries it is compared to in the blog post. Are these numbers normalised with respect to the number of tests performed? What about the number of tests on symptomatic vs. asymptomatic people?

Sweden's lack of action against the pandemic was not limited to just the lack of closure and mask mandates and so on. As far as I know, they never set up a proper test and trace system (please correct me if I'm wrong, I'm not sure about this) as they did in Israel or the UK. Of course their case numbers will be smaller.

No, not really. The wikipedia page of Maude has a good explanation of what it is like: https://en.wikipedia.org/wiki/Maude_system. You can also see the Maude book if you're interested [1].

[1]: http://maude.cs.illinois.edu/w/images/0/0d/Maude-book.pdf

FRP is awesome and is an example of how something previously thought of as an inherently imperative problem can be much easily done declaratively; we completely agree on this!

What I was talking about is: almost all lower-level abstractions are designed with the view of computer as a state machine. If we are solving a problem at an abstraction low enough to make us deal with this analogy, it is easier not to have a declarative layer in between.

machines/pipes/conduits are all very interesting and I was going to mention them too, but I still don't think they solve this problem in the way OP was referring to.

You seem to have completely misunderstood my point.

> Well, you don't get to decide what people find natural, they do.

I am not contending that functional/declarative is a more natural way to think; I am saying that there is nothing inherently more natural about imperative programming. Since the latter comes from imitating the machine architecture up in the abstraction hierarchy, we should consider for a moment if this is really desirable.

> And deep below, computers work under a model that's anything but functional (assembly language is basically a big mutable state machine).

This is entirely irrelevant. Computers are highly stateful but the languages we design don't have to be stateful because of this. They have to meet the criterion of easily expressing the mental constructions we designate which I would definitely say is much better handled with statically typed functional programming languages.

> There is value in understanding both imperative and functional programming and applying each of them wherever they are the best fit...

We completely agree on this! Not all problems are best solved with functional languages (e.g., things actually involving the machine).

> there are some real world situations where sticking to immutability is a terrible choice (e.g. neural networks).

I don't see why immutability is a terrible choice for neural networks? Could you elaborate on this? It might be that almost all neural network implementations have been imperative so you have come to accept that as more normal.

I don't see how either operational or denotational semantics is relevant as I was not talking about semantics of any kind.

I don't think I am confusing anything, you are reacting exactly as I would expect from someone who does not get the point I'm making: we don't have to necessarily program with steps of instructions. If we have a good solver for our language, we can very efficiently execute definitions like my example. I agree that this presents the challenge of efficiently executing such high-level definitions, but this is irrelevant to my point.

> Mathematics sits at a level of abstraction unsuited to physical hardware.

Precisely what I am talking about. Mathematics sits at a level of abstraction convenient for humans not machines.

Have you ever programmed in Prolog? I strongly suggest you try it to get a feeling of why programs are not inherently lists of instructions and how computation can be viewed as deduction.

Thanks for pointing this out!

Dijkstra, in his "on the cruelty of really teaching computing science" makes a very similar point that people should learn how to reason about programs before learning to program.

This is why dependent types are a great framework to program in. If a program is worth writing, it should at least contain everything the programmer thinks about the program, including the reasoning of why it is the program he wants to write!

That is definitely right. For things involving the machine, doing things declaratively is wrong.

Also, thanks for telling about Koka. It sounds very interesting!

That's a great point, thanks! I will look into Papert's work. Are there any specific papers/books you would recommend?

The recipe analogy is certainly very natural, but it does not extend as we get into things like assignments and references, which are a crucial part of Von Neumann languages (which is really the thing I am criticizing).

Tactic languages in theorem provers like Coq are stateful too: you have a proof state and you keep giving instructions for it to change. I wouldn't say that this is an unnatural way to think; for that subtask of the problem, we can view the proof as something with state without any problems.

"Mathematical modeling" sounds too sophisticated to be natural for humans. Let me illustrate what I meant; the kind of naturality I was talking about is this:

sorted(xs): a permutation xs' of xs such that, as we traverse xs' each element is greater than or equal to the previous one.

This is a perfectly fine sorting algorithm. It contains all the information we need to sort a list of comparable things, and it is very unlikely to contain an error; it is the _definition_ of sorting.

There are righteous performance concerns about this but ignoring all performance issues this is still more natural than listing out the steps needed to carry out the task of sorting. I don't think it is possible come up with a simpler recipe-like algorithm for this task.

There are recipe-like tasks in programming: ones that don't involve modeling the world; for those the functional paradigm would not be a good one. But these are rare if you are doing programming the right way.

It makes me sad how people think imperative programming is a "natural" way to think. I have known lots of people who resist using functional languages for serious projects, marginalizing the "functional" way of thinking as though thinking in terms of "labeled boxes with data in them" (Von Neumann architecture) is some sort of more normal way to think.

Before computers people modeled the real world using a Haskell-like pseudocode called "mathematics".

No one's mentioned OS X's "do not disturb". Just set it to be turned on after each login so you have permanent do not disturb.

> Let me emphasize: you write the test cases for your program, and then you write your program. You are writing code to test something that doesn't even exist yet. I am not rightly able to apprehend the kind of confusion of ideas that could provoke such a method.

I don't understand this. What is so absurd about specifying facts about the program you will write? When we have tools that can prove facts, we will be doing formal specifications instead of random sampling. But still, testing is a way of statistically specifying facts about your program, for which it seems sensible to be written before the program.