Are today's general purpose languages at the right level of abstraction?

Question

Today Uncle Bob Martin, a genuine hero, showed this video

In this video Bob Martin claims that our programming languages are at the right level for our problems at this time. One of the reasons I get from this video as that Bob Martin sees us as detail managers and our problems are at the detail level.

This is the first time I have to disagree with Bob Martin and was wondering what the people at programmers think about this.

First there is a difference between MDA and MDE MDA in itself hasn't worked and I blame way to much formalisation at a level you can't formalize these kind of problems. MDE and MDD are still trying to prove themselves and in my mind show great promise. e.g. look at MetaEdit

The detail still needs to be management in my mind, but you do so in one place (framework or generators) instead of at multiple places.

Right for our kind of problems ? I think depends on what problems you look at. Do the current programming languages keep up with the current demands on time to market ? Are they good at bridging the business IT communication gap ?

So what do you think ?

Answer 1

As a researcher and a scientist, I've learned some simple rules, and the most important one is not to let my imagination set boundaries. What I mean is, the fact that I can't imagine a better way to abstract todays problems doesn't mean that one doesn't exist. It doesn't mean that another approach wouldn't completely alter the way we think about programming and consequently my understanding of abstraction.

In the market sense, it's really about competition. If no one else has the überlang, then of course current languages seem to solve the problems at a market appropriate level. Expectations of reasonable evolve with technology.

If you read some of Paul Graham's essays about Lisp, though, you'll see that he believed that his competitive edge was an überlang, Lisp. You'll also see some pretty strong claims about the level of abstraction provided by Lisp and how it differs from, say, Python. I hesitate to give such claims credence... but he made 48 million dollars writing Lisp code, and I didn't. That adds to his street cred, in my mind.

If we assume that Graham is correct, then we can only conclude that the Fortran family tree of languages is slowly catching up to the level of abstraction available in 1957 to the users of Lisp family languages. That's a bold claim, but if it's true than today's languages (the descendants of Fortran, I mean) aren't quite adequate for today's challenges.

But Graham doesn't have to be right in order for Uncle Bob to be wrong. Uncle Bob is wrong if Uncle Bob lacks perfect knowledge of what is possible. What we need to do is largely a function of the languages that we are using and the paradigm we work in, not the other way around.

Answer 2

I have no problem with the "level" of current languages, and I was a thorough disciple of Lisp-ism, but this whole conversation really bothers me.

It bothers me because the language we're really using is the one that we and others have built on top of whatever the compiler or interpreter provides. The nouns, verbs, syntax, and semantics consist not only of what came "out of the box" but what libraries we've included, what classes and methods we've defined, what macros we've written, what interpreters we've coded, what parsers and code generators we've written.

There is not a firm dividing line between using a language, and creating a language. It's more like a rocket taking off into outer space. At each point, it is making use of what it built up previously. Just as the rocket accelerates in a specific direction to the exclusion of others, our program/language builds more and more to the specific problem we are solving. It becomes more and more a domain-specific-language (DSL).

So the whole question "are our languages at the right level" misses the point. The point is that whenever we program, we are building a new language, and we should all know good ways to do that, and the base languages should help us. We should understand that the purpose of a language is not to "do things", "manipulate objects", "control the computer", etc. The purpose of a language is to express our mental models in an effectively computable way.

I know people are going to say "Well, wasn't that what UML was supposed to do?" The answer is it couldn't, precisely because it was pre-ordained. A domain-specific-language is just that - specific. A domain-general-language is only useful if it can be effectively transformed into a domain-specific-language.

Answer 3

I think one of the things that his says is right.

Programming languages today are at the right level of abstraction.

But, I think that although, in the future, we may use the same languages as today, because compilers are getting better and processors are getter faster (as in they can do more computations per second), we may be able to operate a higher-level, where we don't need to worry about performance details.

This has already happened with most tasks and the rise and rise of dynamic languages like python and ruby, but as compilers get better we may be able to start writing things like databases and maybe eventually kernel modules and operating systems in this style.

Answer 4

An Alan Perlis epigram comes to my mind: "A programming language is low level when its programs require attention to the irrelevant."

Also, I rather think of programming as complexity management rather than detail management.

In so many words, if we can get away with knowing about microcodes and whatnot when writing many softwares (even get away even with hardware specificities) , what else can we get away with? A possible answer: whatever computing phenomena we can create a model for (think of operating systems, pattern matching grammars, memory management, data flow, software memory transaction, etc) and make it general enough and flexible enough so we can feel comfortable with doing the mental magic called "abstracting" the set of undesired details of the complex phenomena we are dealing with.

So, I don't think general programming languages of today are in any way close to my personal expectations.

Answer 5

I've seen a real-life example of Paul Graham's Blub Paradox on usenet. Lisp programmers were trying to explain to Python programmers what macros were good for. The Python crowd responded to every example with: "You can do the same thing in Python." The point the Lisp crowd was trying to make--that Lisp allows programmers to add their own control structures--was lost on the Python group. Those who understood about the control structures took the position that adding your own was evil and led to unmaintainable code.

What this example demonstrates is that the level of abstraction of a programming language isn't the most important thing. We manage to get working code written, and don't miss the advanced features of Lisp because we never knew about them (and they're evil features anyway; they lead to unreadable code).

Answer 6

What are "today's general purpose languages"? What are "our problems at this time"? Making real-time embedded programs is quite different from making a big data mining systems, which is quite different from making web applications, and all these obviously need to work at different abstraction levels. Even general purpose desktop software is being successfully made with various languages such as C++, Python and Lisp, all of which work at different levels - or should we say dimensions - of abstraction.

It indeed seems that the level of abstraction is not that critical; somehow certain languages just seem to work better with certain problems (sometimes for obvious reasons; you can't write low-level code with languages that don't allow access to physical registers of the computer, and writing web apps with raw C is obviously impractical).

Bob Martin is an OO expert from inside out. While he can write excellent things about that, his idea of the field called "programming" seems to be somewhat shallow.

Answer 7

Bob Martin sees us as detail managers and our problems are at the detail level.

Our problems are at the detail level because we are detail managers. If we worked at a higher level of abstraction the details would take care of themselves and we would no longer have to manage them.

Answer 8

I agree with Uncle Bob that we don't need a MDA on the top of a programming language. I am a java developer and why to have my code generated automatically if the model can not handle detail management information. Saying that I disagree that UML is not the appropriate level of abstraction we need for our project as long as we don't expect UML to lead our code generation. I mean that for me UML is a fantastic language which should be used in all projects but MDA, MDD etc should not ...

Many projects only use whiteboards while a light UML would has been a lot more appropriate. You don't need to be an expert but just to use your brain and be able to talk about object at java and model level. If you don't know UML then just create class diagrams in order to create the skeleton of your application.

What I use is an advanced UML which only generate my code when I need it and which model is updated when I just code. Just marvelous technology which allows me to create my architecture and then start to code, go back to my model and again back to code without ever loosing any information and having a very well written code. The mechanism I use is the incremental model merge developped by Omondo. No MDD or MDA with Omondo but a merge between Java and UML ids.

Did you have ever noticed that UML 2.3 has the same architecture than C# and Java ? It does have packages, classes, attributes, methods and it can also handle constraints on methods which are the management details Uncle Bob is talking about. The problem is that the OMG specification job which is absolutely fantastic is dealing with the metamodel while only the UML diagrams are discussed. I mean that UML should not be just graphical or MDA, MDD. UML should be the entire project model with UML diagrams just viewer of the model and not the model itself !! The problem is that tools use transformation layers in order to create code and models and not the official specification which is the UML 2.3 metamodel !!