Lambda the Ultimate

Now, obviously, language can make code more readable and easier to maintain. But are there real differences between most mainstream languages today?

An important factor is the availability of tools. IDEs, class browsers, refactoring browsers etc. This is one area where Smalltalk excels.

By the way, my personal experience shows that well written assembler is easier to work with, than poorly written Ada/C++ etc. That's why you should be careful choosing the person whose code you going to take over

Beacuse of our cognitive abilities?

In fact, I don't think there's tension. I think that good programmers think on many levels at the same time (problem domain, system architecture, programming language, machine architecture).

Good programming languages allow you to focus on the level you need, when you need.

Abstractions often seem to bury the details of a design.

Information hiding is the goal, is it not?

I wouldn't use the word bury. I'd rephrase: (Good) abstractions let you ignore unimportant details of design.

I often see criticisms of java programs that use too much abstraction.

No such thing as too much abstraction. Choosing wrong kinds of abstractions or simply choosing wrong abstractions is, of course, entirely possible.

Notice that OOP languages tend to push you in the direction of the "abstraction=classes and inheritance" point of view. There are several other important kinds of sw abstractions...

The problem, I think, is that there's a common notion that it's always a good thing to add those abstractions, and the chosen interface is usually pretty ad-hoc. Consequently, anything forgotten in the abstaction (like how a database interface manages its connections) becomes an undefined "implementation detail", and you can't so easily find (or change) the answer by just looking at or hacking "the code."

That's how it seems from my Java hacking experience, anyway. You are right that really it's just using bad abstractions, but it comes from a drive to hide as much detail as possible that often goes much too far. Saying Java programs "use too much abstraction" definitely means something to me.

I found a Dijkstra quote recently that hits the nail on the head for me:

... it might be worth-while to point out that the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise.

This point is often missed - and I won't claim innocence myself.

This is a great quote. I think it is of great important to language designers - but at least most of them are aware of the fact that they should try an create "a new semantic level".

I know exactly what you guys mean by "too much abstraction," but I think using this phrase is dangerous. It makes people think that simply exposing details is the way to go. This is worng, and leads to bad sw design.

Good software design is about choosing appropriate abstractions, and using the appropriate language facilities for defining them (e.g., templates or macros).

I have been using the log abstraction (using several of my own designs) as a case study this last semester (my students just finished sitting on an exam, which contained one more variation on the log theme. I am pretty sure they are fed up with it by now...)

one day we might all use Web Services and easily get the information we need from various providers using SOAP or REST, but in the meantime the common way to achieve this goal is just to write code to connect to a web server, retrieve a page and extract the information from the HTML. In short, "screen-scraping."

Here is an algebraic view on abstraction in software engineering. I intersperse the text with translations of the mathematical concepts into programming terms between parentheses.

Abstracting away from a particular implementation is like taking a set (the implementation) and giving an algebraic axiomatization of it (an API with a contract). You do it by identifying certain operators on the set (names of procedures), giving you a signature (the API), and laws they satisfy (the contract). This characterization induces a class of algebraic models (possible implementations). One of these models is the "intended" one (the implementation you abstracted away from).

A pitfall that mathematicians (programmers) often fall into is that they reason about the class of models (the API plus contract) by reasoning about the intended model (the original implementation). This leads them to ascribe properties of one model to all the models (ascribe properties of the implementation to the API+contract), which leads to incorrect "theorems" or proofs (malfunctioning programs, or programs which stop functioning when the implementation of the API is changed). Falling into this pitfall means you cannot achieve goal #1 of abstraction above.

(What actually happens most commonly in software development, though, is that the contract is not documented!)

Another pitfall is making your signature and laws (API and contract) too strong. This makes the class of models (possible implementations) too small. This pitfall is very easy to fall into. By adding one law (one statement in the contract), you can collapse the whole class of models to be empty (no possible implementations) or isomorphic (implementations may differ in efficiency, but not essential behavior). If empty, you have made a mistake. If isomorphic, you cannot achieve goal #2 of abstraction.

(Again, though, what happens most commonly is that only a fragment of the contract is documented, and that fragment is actually too weak, and then you fall into the intended model trap again.)

Finally, the way in which you abstract away from a set is pretty open-ended. You could identify ten, or a hundred or an infinite number of operators (API procedures), and ten, or a hundred, or an infinite number of laws (statements in your contract), each of which may be arbitrarily complex. If the result is something which is hard to reason about, then you will not achieve goal #3.

Note, BTW, that abstraction does not always mean "forgetting details". As I mentioned above, you can pick your abstraction so all models are isomorphic, for example, and this is can be a useful thing, even if it means you don't get goal #2.

Right! Let me extend the notion of abstraction a bit, and while at it give an example.

Parameterization is a form of abstraction. When you parameterize a module that uses a stack, so that the stack (type) is a parameter, you reduce the coupling between the module and a specific stack implementation.

Notice, that you exposed details (i.e., that a stack is used). Presumably you did that because these details are important to the module's users (e.g., they want to control the memory behaviour of the stack used).

Another example is a sort routine, parameterized by the order relation for the element type.

Generic programming tends to expose these kinds of relations between components.