[Haskell-cafe] Wow Monads!

[Joachim Durchholz]

Am 18.04.2017 um 18:57 schrieb David McClain:
>> 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.
>
> Too powerful for whom?

Too powerful for teams that include sub-average programmers (by 
definition, you always have a sub-average one on the team).

The issue is that you don't have enough brilliant developers to staff 
all the projects in the world, so you need technology that gives 
consistent results, much more than technology that boosts productivity 
but is inconsistent.

 > Again, I’m lucky to be master of my own
> domain.

Exactly.

>> 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.
>
> Isn’t that always the case, and always will be the case?

Only in dynamic languages that do not give you any guarantees about what 
the code is *not* going to do.
That's exactly what makes Haskell interesting: There cannot be any side 
effects unless the code has IO in the type signature, which is so 
awkward that people tend to push it into a small corner of the program. 
The net effect is that it is far easier to reason about what a program 
can and cannot do.
In the Java/C++/whatever world, unit testing achieves the same, though 
the imperative nature and generally less well-delimited semantics the 
effect is far less pervasive. Java stands out a bit since the language 
semantics has always been nailed down pretty narrowly right off the 
start, which is a first in the computing world and has been having 
pervasive effects through all the language culture - Java libraries tend 
to interoperate much better than anything that I read about the C and 
C++ world.

 > Nobody can
> be certain how some library or application was written. You might
> have some pretty strong hints and hunches, but how can you be sure?
>
> Seems like the best bet is to treat everything as untrusted black
> boxes.

Whenever I see one of the Java libraries do something unexpected in what 
I code, I tend to read the sources. It's usually easy because Java is so 
dumbed-down and verbose that you can pick up enough hints.
The more advanced libraries (Spring) take longer to understand well 
enough, and some (Hibernate) are so badly coded that it's pretty 
non-fun, but I tend to get results, mostly because Java is so strict 
that I can see what's happening.
I get into trouble whenever annotations or AOP stuff is involved, or 
when too much activity is hidden away into data structures that are 
being executed at a later time. Data types help me pick up on that lead 
though; I'd fail miserably in a language without static typing because 
all the hints and hunches are gone, and I have to go by cultural hints 
and hunches which tend to diverge between projects so I'd be lost. 
(Actually I'm pretty sure, I tried to get "into" Smalltalk once and it 
never worked for me.)

 > Erlang probably offers the best security model against
> dependencies.

Erlang is good for handling failures that show up.
It does nothing for you if the problem is code that's subtly wrong.

> If you look at any major element of code in production, it was
> probably written in a hurry under near unreasonable demands because
> hardware engineering overran their budgets and took some of yours,
> and the programmer may or may not have well understood his tools and
> language, or even if he did, he might have been daydreaming of being
> on the beach with his girlfriend instead of in this meat locker with
> the rest of you guys…

Actualy it's not the hardware engineers nowadays (we all work on stock 
hardware anyway).
It's the bean counters who are trying to cut down on the budget.

> My experience has been that hardware companies produce the most
> gawd-awful code you can imagine. Software shops vary… take M$ for
> instance - the bane of my existence. Looks like code gets pushed out
> the door and they rely on the audience to test it.

They used to be that way.
Security threats endangered their business model, so they had to change; 
nowadays, they aren't that different form other large companies anymore.

 > Apple looks to me
> like a room full of really bright young minds, with no adult
> supervision.

Actually Apple is the most strictly controlled workplace in the 
industry, as far as I know.

> I guess if I could offer any advice to other younger programmers, it
> would be to push yourself to become a polyglot to expand your mental
> horizons of what is possible, and a historian to understand what went
> before you and why, so that you don’t keep repeating the same stupid
> mistakes we did.

In the modern world, the bean counters found enough tools to control the 
development process that you don't have much of a choice.
If you want to have choice, you now need to become a manager. Which 
means no programming at all.

It takes a lot out of the profession that was attractive in the past 
decades, but on the other hand it reduces project unpredictability and 
increases job security. (It's still not perfect, but I doubt it ever can 
be.)

> I could not be a production programmer. I’m definitely too much of a
> cowboy and a lone wolf. Teams are anathema to me. I need deep periods
> of isolation to think. People who manage to perform in production
> coding environments must have very different personalities from me.

That has been clear for a long while :-)