Lambda the Ultimate

It's arguably a noble thing to assume that no one is too stupid to teach a given trade, but it is simply foolish to assume that no one is too ignorant to practice that trade. Yet that is precisely what industry seems to desire: a magic wand that will enable poorly educated people to do meaningful work in what Dijkstra called the most difficult branch of applied mathematics. I can only say, "Good luck with that."

Isn't that what employers and managers would like most ? To have tools so that anyone can program, making programmers abundant and cheap ?

I'm not suggesting that actual employers and managers think like that, only that it would be an ideal situation for them. And there seems to be no shortage of tools to promise to make programming easy...

I have come to the conclusion that languages should scale.

You can't exclude the basic user, the hobbyist, if you will. The guy who does HTML and on the side is learning a little bit of PHP so that he can do more. He's probably not interested in Haskell or Scheme.

Or the entrepreneur who has an idea for a product. He's got a marketing background, but he's got a good head on his shoulders and knows enough Python to get the job done. It's not beautiful code, but it works well enough to get things rolling. At that point, he hired me to clean things up - he knows he's not a gifted coder. (Yes, true story).

You have to aim for people like that, or at least provide something they can get started with, or else you consign yourself to yacking back and forth about whether common lisp or scheme is better and being largely ignored by "the average guy".

And be careful before you cop an attitude. Maybe the 'hobbyist programmer' is also a medical doctor who sees a way that software could automate what he's doing. Lots of commercially successful code is that way - written by someone who knows a problem domain inside out and has enough programming skills to accomplish what he has in mind.

On the other hand, my ideal language wouldn't be something that a professional would turn their nose up at, and would feel trapped with. It should be a sharp enough tool that the right person can still express themselves with it and not have problems.

Ideally it would also scale in the sense that quick programs are very quick, and complex programs are possible.

Exactly,

The point of arguments that say that a particular programming model is "closer" to the way people think is as follows. If a programmer has a certain way of thinking about how you solve a problem, then a language that allows them to express their thoughts in a manner close to the way that they think about it in their head will allow them to devote more mental effort towards other aspects of the programming task. For example, ensuring that the algorithm is correct, thinking about how their code relates to the project as a whole, etc.

Now obviously there are other things that need to be considered in the choice of programming language, for example:

• Can a programmer change the way they think about approaching a problem? In my own case, I started off with GWBASIC on an MS-DOS computer, something that left a lot to be desired compared to just about any language that gets discussed on this list. But when I learnt Modula-2 and C I was able to adapt my way of thinking to that required by a more block and function strucured imperative langauge. Later as I learnt various object oriented languages, lispy languages, functional languages, these all influenced the way that I thought about programming. If I was to go back and approach some of the programs I wrote 10 years ago, even using the same language as 10 years ago, I would approach them differently given my exposure to other programming styles.
• Does the way of approaching a problem that is encouraged by a language make algorithms easier to write? The classic example for me is tree algorithms and recursion (very basic, I know). By using languages that encourage recursion, it changes your way of thinking and allows you to express algorithms that traverse trees in a much more natural way.

So I guess what it boils down to for me is that the closeness of a languages approach to computation to a programmers mental model is a consideration in language choice, but it is still only one consideration.

Given a substiantially large codebase no single programmer really "understands" the code anymore, in the sense of having a mental overview of all possible interactions and dependencies. This contrary to other fields, we basically assume right from the start that even an expert has a partial picture of what goes on at best.

Nonsense. There is no scientific field where any expert has comprehensive knowledge either of the field or of the specific instances of any application. No physician is privy to every medical result, much less all the particular (even medically relevant) circumstances of a patient. No engineer knows the entire body of physics, much less the exact composition of building materials, precisely what stresses a structure will encounter, or what economic fluctuations will do to the cost of a project. No mathematician can know every theorem, or even understand except perhaps in merest outline every sub-field which may impinge on his interests. On the contrary, if they did, it would spell the end of science.

What workers in all these fields do share is exceptional problem-solving, research and information-gathering skills. If they see a problem which is close to but not exactly the same as one they understand, they can develop variations on an existing solution. If they see a problem they don't understand at all, they know where to look in the literature and are ready to educate themselves better about it. If they don't have enough information about a problem, they do experiments and tests, or work through examples.

This is all the same as what is demanded of a programmer. A programmer needs to be able to solve new problems (develop new algorithms, ways of structuring a program modularly, etc.), to be cognizant of what problems can be and have been solved and how to find out about it (via trade magazines, or journals or technical articles or even the Internet Oracle), and to know how to make progress when he lacks sufficient information about a problem (gather requirements, assemble test and use cases, prove correctness, profile, debug, etc.).

You may object that, on top of all this, the programmer must familiarize himself with the domain-specific details of an application. That is true, but he need not become an expert in such a field, and it is also true in other fields. A doctor who treats athletes will need to familiarize himself with the particular injuries which are likely to occur in that sport. An engineer who builds a hospital will need to know something about what the requirements of a hospital are. A mathematician whose interest is Hamiltonian dynamics will familiarize himself with applications in mechanical physics and celestial mechanics.

Psychology has played no role in shaping the structure of any of these fields, and yet, not only are they are far better developed and understood than is the science of programming, they are also populated by professionals who, on the average, are better educated, more responsible, more resistant to fads and pseudoscience, and, frankly, more capable and valuable than Joe Q. Programmer.

One should hope that the difference between today's programmer and tomorrow's programming professional will be the same as the difference between an electrician and an electrical engineer. Right now all we have, for the most part, is electricians.

(Where does psychology play an important role? Marketing and consumer development. If you want to sell a drug, say Viagra, ask sex or social psychologist. Want to sell a market a new handicam model? Consult a usability expert.

But in a technical field, where the practitioners are highly-trained experts, there is far too much important esoterica for a psychologist to have an impact. You would not ask a psychologist to refactor or reorganize theorems or results. An enginer might ask one to give ergonomic requirements for a house he intends to build, but not to find a better way to solve differential equations, or even to devise a better notation for integrals. Similarly, you might ask a psychologist for advice on a user interface, but not on a programming language's semantics or even syntax.)

(Having said that, here is an interesting application of psychology in, well, something like science. (And note that, in this instance, the psychologist also played the role of a scientist who had to familiarize himself with domain-specific details.))

Psychology has played no role in shaping the structure of any of these fields

If you insist on a narrow reading of "psychology" (i.e. the particular field so-named), I might agree, but if we mean usability in general, I think you are off the mark.

What is "elegance" of a proof if not usability? Why do mathematicians continue to "refactor" proofs in search of greater elegance, if not for the sake of some psychological quality of simplicity or clarity that makes the essence of the proof more evident?

All of these fields have been around for so long that usability has evolved in them naturally. All those tricks for solving differential equations, all those lemmas lying around in math are the natural expression of usability. They answer the question "How could I do the same thing a bit easier, a bit more clearly?"

I would agree with you that formally-trained psychologists are not necessarily going to add a lot to any of these fields, or to the field of programming, but I will argue (as I have before) that one way or another PL design has to come up with some princpled vocubulary of elegance/usability/human factors to deal with the real issues that are there, and that have been subsumed already into other mathematical endeavors.

So we agree whole-heartedly that someone serious about being a programming professional should have a solid foundation in theory; I don't think this is an unreasonable requirement.

But a PL can have an excellent theoretical basis and still be poorly designed for use, even if you limit that use to the theoretically savvy.

What is "elegance" of a proof if not usability? Why do mathematicians continue to "refactor" proofs in search of greater elegance, if not for the sake of some psychological quality of simplicity or clarity that makes the essence of the proof more evident?

I don't dispute that at all. When I wrote "psychology" I meant the scientific field of formal psychology.

But a PL can have an excellent theoretical basis and still be poorly designed for use, even if you limit that use to the theoretically savvy.

Sure, but my point is that no one halfway proficient develops such languages because avoiding surface features which might make a language unusable (say, 50-character long keywords) requires little more than common sense and some experience.

Difficult semantic constructions (one might argue, for example, against first-class continuations) are another matter and require much more thought. But in those cases you would even more assuredly not consult a psychologist.

Sure, but my point is that no one halfway proficient develops such languages because avoiding surface features which might make a language unusable (say, 50-character long keywords) requires little more than common sense and some experience.

I would buy this if it weren't for so many counter examples: zero-based indexes mixed with 1-based indexes, "there is more than one way to do it" where each way is slightly different semantically, programmers who think "hjkl" are intuitive keys for navigating the cursor, etc.

And that is just the petty stuff.

Do we just have to accept an eternal battle between "delimited with pretty printing" vs. "significant whitespace", or might there be a principled way to choose between them (perhaps each having it's appropriate, but different, use)?

one might argue, for example, against first-class continuations

An interesting choice. From my point of view continuations are wonderfully simple once you let go of preconceptions. The only thing that is hard about them is that they fall in the crack between two well-established paradigms: they are too functional from a procedural point of view and too stateful from a functional point of view.

I suppose in the end their biggest failing is that you don't really NEED them.

But in those cases you would even more assuredly not consult a psychologist.

Unless of course you were feeling despondent about it. ;-)

I suppose in the end their biggest failing is that you don't really NEED them.

I only hope by NEED was not meant some cognitive factor...

What has first-class status in Turing machine?

How about this Andris? Why don't you take a vow to only program on a Turing machine from now on, and let us all know how that works out for you. ;-)

I only hope by NEED was not meant some cognitive factor...

Let me spell that out. In this instance, "not needed" means that there are other common PL structures that can accomplish the same ends most of the time, and these do not sacrifice simplicity to any great extent.

Are difficulty, tractability, complexity and so on psychological concepts?

If we are using psychological in place of the dread "human factors", I think that they often are.

Partly this is ambiguity of usage. We can always hedge and say that "difficulty" in mathematics is based on something objective, say the number of known techniques that can be used on a problem of configuration X, or the presence of certain features which have known pitfalls.

But I think this is sweeping dust under the rug. Generally what we mean by a problem being difficult is that, given some norm of mental tools at someone's disposal (whether "common sense" tools or the result of training), we assess the problem has a good chance of not being solved, or at least of taking a long time.

So let me propose as a first approach to the HF problem that when we discuss such an issue, we define the norm of mental tools we are assuming, then show how it interacts with the given problem.

I suspect that just defining the mental tools we think "any programmer" should have will illuminate a number of PL design issues and disagreements.