[Haskell-cafe] Wow Monads!

[Joachim Durchholz]

Am 18.04.2017 um 17:39 schrieb David McClain:
> Well, as I stated, I think failures come in several categories:
>
> 1. Machine Fault failures on successfully compiled code. That’s the
> big nasty one. Provably correct code can’t fail, right? But it
> sometimes does. And I think you can trace that to the need to
> interface with the real world. The underlying OS isn’t written in
> OCaml. Neither are many of the C-libs on which OCaml depends.

I think that any language will depend on C libs, and so all languages 
are afflicted by that.
Of course some languages have their own software stack and need less 
external libs, so this depends.

> 2. Experimental languages are constantly moving tools with ever
> changing syntax and semantics. It becomes a huge chore to keep your
> code base up to date, and sooner or later you will stop trying. I
> have been through that cycle so many times before. Not just in OCaml.
> There is also RSI/IDL, C++ compilers ever since 1985, even C
> compilers.
>
> The one constant, believe it or not, has been my Common Lisp. I’m
> still running code today, as part of my system environment, that I
> wrote back in 1990 and have never touched since then. It just
> continues to work. I don’t have one other example in another language
> where I can state that.

Java :-)
Breakage does happen, but it's rare, though the incident rate can go up 
if you don't know what you're doing (some people routinely use APIs 
wrongly, read Internet recipes rather than the docs that come with the 
Java libs, and are caught flat-footed when internals change - I guess 
you don't have that problem because you know your system well enough to 
avoid this kind of pitfall).

> 3. Even if the underlying language were fixed, the OS never changing,
> all libraries fully debugged and cast in concrete, the language that
> you use will likely have soft edges somewhere. For Pattern-based
> languages with full type decorations (e.g., row-type fields),
> attempting to match composite patterns over several tree layers
> becomes an exercise in write-only coding.
>
> The lack of a good macro facility in current FPL is hindering. Yes,
> you can do some of it functionally, but that implies a performance
> hit. Sometimes the FPL compilers will allow you to see the initial
> AST parse trees and you might be able to implement a macro facility /
> syntax bending at that point. But then some wise guy back at language
> HQ decides that the AST tool is not really needed by anyone, and then
> you get stung for having depended on it. The manual effort to recode
> what had been machine generated becomes too much to bear.

I think Lisp-style macros are too powerful.
You can get excellent results as long as everybody involved knows all 
the relevant macros and their semantics perfectly well, and for one-man 
teams like yourself this can work very well.
If you need to work with average programmers, this fails. In such an 
environment, you need to be able to read other peoples' code, and if 
they can define macros, you don't really know anymore what's happening.

> 4. I will fault any language system for programming that doesn’t give
> you an ecosystem to live inside of, to allow for incremental
> extensions, test, recoding, etc. Edit / compile / debug cycles are
> awful. FPL allows you to generally minimize the debug cycle, by
> having you live longer at the edit / compile stage.
>
> But see some of the more recent work of Alan Kay and is now defunct
> project. They had entire GUI systems programmed in meta-language that
> compiles on the fly using JIT upon JIT. They make the claim that
> compilers were tools from another era, which they are, and that we
> should not be dealing with such things today.

Well... the Java compiler doesn't really "exist" in a modern IDE, stuff 
is being compiled on-the-fly in the background, even with live reload 
inside a running program (with some restrictions, so this isn't perfect 
- but then Java is anything but perfect).

So I do not think that compilers per se are a problem, though they way 
they often need to be used can be.

> For me, Lisp offers a
> full toolbox and allows me to decide its shape in the moment. It
> doesn’t treat me like an idiot, and it doesn’t hold me to rigid world
> views.

Problem with that is that empowering the programmer makes it harder to 
be 100% sure what a given piece of code does. There might be macros 
involved, there might be metaprogramming involved, or some kind of 
multiple dispatch with nonobvious defaulting rules, or a gazillion of 
other things that you have to be aware of.
It's not a problem if you know your system from the inside out, but it 
doesn't scale well to tasks that need to be done by a team.