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 :-)