[4b11b4]

I really enjoyed the this one:

Some meditations on Advanced Programming

https://www.cs.utexas.edu/~EWD/transcriptions/EWD00xx/EWD32....

As I'm currently in a Functional Programming course in Haskell... This resonated.

I know that we'll always need to write programs which directly interface with memory.

However, when we don't need to do that... Maybe we shouldn't write programs in this style (i.e. imperative). Maybe we shouldn't even use an imperative language (I know, that's a stretch, many languages have incorporated functional aspects and we can utilize them instead of trying to avoid the language entirely).

---

Dijkstra ends EWB 32 with:

"Smoothly we have arrived at the third component of our tool, viz. the language: also the language should be a reliable one. In other words it should assist the programmer as much as possible in the most difficult aspect of his task, viz. to convince himself —and those others who are really interested— that the program he has written down defines indeed the process he wanted to define."

"As my very last remark I should like to stress that the tool as a whole should have still another quality. It is a much more subtle one; whether we appreciate it or not depends much more on our personal taste and education and I shall not even try to define it. The tool should be charming, it should be elegant, it should be worthy of our love. This is no joke, I am terribly serious about this. In this respect the programmer does not differ from any other craftsman: unless he loves his tools it is highly improbable that he will ever create something of superior quality."

At the same time these considerations tell us the greatest virtues a program can show: Elegance and Beauty."

---

Functional languages... help us achieve these aims.

[commandersaki]

You should read the correspondence between Dijkstra and John Backus and contrast that with your view of Functional Programming.

https://medium.com/@acidflask/this-guys-arrogance-takes-your...

[bdamm]

Alas, I live an a world where efficiency does actually matter, and elegance to me includes efficiency. I live in a world of embedded software, portability, and reliability. In this regard, almost every single functional language is an utter failure, because they require runtimes and big fat common libraries. Even golang is borderline. Haskell has little chance.

Generally I think this does answer the question about why functional languages don't dominate more than they do - although you could make an argument that JavaScript is a functional language, and it certainly is enjoying a lot of dominance these days. JS environments aren't known for being particularly efficient, though. To me, efficient use of resources is elegant, and a language needs to be able to do that.

[linguae]

You brought up something interesting. I believe academic computer science originated from at least three cultures: pure mathematics (Church, Turing, Kleene, Dijkstra), electrical engineering, and psychology (Licklieder). I say “at least” since there may be other cultures I’ve overlooked. These three cultures have different views on programming: the EE-based culture emphasizes taking full advantage of the underlying hardware, the math-based culture emphasizes proof, and the psychology-based culture emphasizes human factors.

The challenge is reconciling these three views of programming: the holy grail is a programming language that is ergonomic and expressive, yet is also amenable to mathematical reasoning and can be implemented efficiently. I wonder if there is a programming language theory version of the CAP theory in distributed systems, where one compares performance, ease of mathematical reasoning about code, and human factors?

[mrkeen]

Your environment is probably not more constrained than this: https://github.com/Copilot-Language/copilot

[bdamm]

That is really quite cool, and unlike any functional language I've seen.