Beauty and the beast (on elegance versus performance)

When you are programming you have to choose between code elegance, clean code, versus code performance.

It starts with the programming language itself which you choose. Pick a low abstraction programming language, like C, and you'll have a lot of performance. You could go even further and write in assembler, for even more performance. But consequently the code will be large and hard to read. The program will tend to focus on the specifics of the machine or language, how to do it, instead on the specifics of the problem to be resolved, what to do. In other words, it will be low in abstractions. Otherwise, if you pick a higher abstraction programming language, an OOP or FP language, your program will be more succinct and readable, but you may get performance penalties. This time your program will be rich in abstraction, but it may also suffer on performance.

Even in one programming language you still have options for elegance versus performance. If you choose to use the simplest and cleanest solution you come up with, you may have poorer performance than if you would have used a more complex algorithm, but also harder to understand. Also if you choose to generalize the solution to include a family of problems, in the eventually of program growth, you would get into performance problems.

I faced this issue recently. I tried to write a program as simple and readable as possible. I used Groovy. I used a lot of reflection; the language itself is also heavily based on reflection. I tried to generalize each aspect to include as many cases I could think at the time. I used a lot of dynamic attributes and collections instead of static ones. The program was very domain centric, easy to read and understand (I think).
Note: I don't want to seem to be bragging; there were also plenty of hacks, shortcuts, to resolve a problem in minutes, instead of spending hours to do the wright way.

It all went fine until I tried to use large input data. It took forever to process the data. All the reflection, dynamics and generalities came back on me, and had dramatic effects on performance. I tried to improve some critical points of the program, hot-spots, but the overall performance was still poor.

So in the end you always have to pick: code elegance versus performance. Sometimes the domain will force you to choose one, because of its restrictions. But you will always have to balance these two aspects. If you favor performance you will have hard time maintaining the code on the long-run, If you favor code elegance you will have performance issues, like I had. It's a fine balance, you have to get it right.

What's your opinion: Code elegance or performance? Beauty or the beast?

Programmer profitability

How profitable are you as a programmer? Have you ever asked yourself that question? This is a tricky question, so let me give you a hint: it would be more profitable for you as a programmer to be better at what you do? I don't say if it would be good for you to be better programmer, but it would be more profitable? OK, enough with the questions.

It is accepted by everyone that programmer productivity varies by a large margin (by 10 times or more, but the numbers are debatable). So let's say you are twice as productive as the average programmer. Are you paid twice as much? Probably not. So a programmer's pay is not directly proportional with the value he is providing. Probably if you're twice as productive as the average programmer you'll be paid with let's say x% more, where surely x is smaller than 100. This sounds wrong, but it's true. And it's true because the work a programmer is doing is extremely hard to quantify. A programmers work cannot be quantified like a manufacturing task for example, where you could be paid by the number of items produced. But a programmer doesn't produce items by the number, even if there is an old practice to measure programmer’s productivity by the line of code they've written. But this is the worst measure of a programmer. A programmer could solve a problem in half the code and twice as elegant than another one, and that doesn't mean he is less productive, quite the opposite. But this is another story.
Not to mention another tricky aspect, a good programmer can come up with solutions to problems that the let's say the average programmer couldn't crack at all. And that's invaluable.
So from an economical point of view you're less profitable if you are a better programmer. So how can a programmer be motivated to be better at his job? We could blame this aspect for the ever decreasing level of competency in our industry, yet another story.

If being a better programmer isn't profitable for you, this means it is more profitable for the employer. And it is, because you get twice the value at less than twice the price. So it's a bargain for the employer to get the best programmers out there. But unfortunately usually most of the companies hire on number of programmers, not on value. You usually hear 'we need x more programmers', not 'we need y programmers with that level of skills or z with another level of skills'.

In the end I have a small advice for you: be a better programmer for yourself, because it feels good to be one of the best, and not because it gets you more money, because it doesn't scale up.

On Java EE complexity

Reading an article I remembered the words of one of my friends (Doru Girba) about the increasing complexity of Java, the language and technologies. And I must agree with him: EJB it's a nightmare (at least version 2), Java enterprise application start to add more and more complicated technologies, which add more complexity rather than to simplify things. I start to feel all this complexity myself, being involved in a massive enterprise project.
But there is also hope for better. Spring (a JEE application framework) simplified a lot the JEE landscape; it heavily influenced EJB version 3 with it's innovative ideas.
Another good sign is the development of more and more dynamic languages that run on JVM. The most promising (from my point of view) is Groovy: a dynamic version of Java (dynamic typing, closures, MOP, and others). Groovy also provides and web framework, inspired by the famous RoR, called Grails. Groovy's advantage over other dynamic languages is that it is compiled into Java bytecode, so it looks live ordinary Java classes.
Coming back to the article I mentioned in the beginning, it's about the recent acquisition of the company that develops Groovy and Grails by SpringSource (the company that develops Spring framework) - "More Weapons for the War on Complexity: SpringSource Acquires Groovy/Grails Leader". A combination of Spring and Groovy and Grails, running on a light-weight application server, based on OSGI, looks like a very promising idea. And the most interesting is the new SpringSource motto: "Weapons for the War on Java Complexity."

Conclusion: Keep it simple! Do not complicated things more than it has to be.
"Everything should be made as simple as possible, but not simpler." - Albert Einstein
"Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away." - Antoine de Saint-Exupery

The perfect definition for "Meta"

Defining the word "meta" is always hard, this includes programming.
Following is the Wikipedia definitions for "meta":

Meta is a prefix used in English in order to indicate a concept which is an abstraction from another concept, used to complete or add to the latter.

This way too abstract and hard to understand. A better definition for the word "meta" is given by Guy Steele in his OOPSLA'98 talk "Growing a Language" (video and paper), for the meaning used in programming but also for a more general meaning.

Meta means that you step back from your own place. What you used to do is now what you see. What you were is now what you act on. Verbs turn to nouns. What you used to think of as a pattern is now treated as a thing to put in the slot of an other pattern. A meta foo is a foo in whose slots you can put foos.

If you carefully analyze this definition you'll find a very deep meaning and you'll probably realize what "meta" means. And also if you truly understand this definition than you probably understand the whole meta-programming stuff. So just read that definition very carefully.

Software Visualization

Software visualization is defined as “the use of the crafts of typography, graphic design, animation, and cinematography with modern human-computer interaction and computer graphics technology to facilitate both the human understanding and effective use of computer software.”(John T. Stasko et. al.). It is a specialization of information visualization, whose goal is to visualize any kind of abstract data, while in software visualization the sole focus lies on visualizing software.


Software visualization and reverse engineering: Software visualization has been widely used by the reverse engineering research community during the past two decades. Many of the approaches provide ways to uncover and navigate information about software systems. The graphical representations of software used in the field of software visualization, a sub-area of information visualization, have long been accepted as comprehension aids to support reverse engineering. Software visualization has become one of the major approaches in reverse engineering, Koschke reporting that 80% of interviewed researchers consider visualizations as being important or absolutely necessary in software reverse engineering.

The enormous interest in visualization as an aid for reverse engineering and problem detection can also be inferred from the large number of tools that have been developed for this purpose: Rigi, SHriMP, CodeCrawler, Mondrian, etc.

My interest in this domain appeared during my visit to SCG, during my diploma thesis, when I created a set of new visualization for Lisp systems, developed to underline the differences of the language and to help understand and browse complex Lisp systems. For more information see my diploma thesis.

Going META!

Recently i am interested metaobject protocols.
Reading "The Art of the Metaobject Protocol" by Gregor Kiczales, Jim Des Rivieres, Daniel G. Bobrow (MIT Press) was a wonderful experience for me.
Like Alan Kay said: "The Art of the Metaobject Protocol is the best book written in computing in ten years" (Keynote OOPSLA 1997).

In a language based upon metaobject protocols, the language implementation itself is structured as an object-oriented program. This allows the power of object-oriented programming techniques to be exploited to make the language implementation adjustable and flexible. In effect, the resulting implementation does not represent a single point in the overall space of language designs, but rather an entire region within that space.

A metaobject protocol (MOP) is an interpreter of the semantics of a program that is open and extensible. Therefore, a MOP determines what a program means and what its behavior is, and it is extensible in that a programmer (or metaprogrammer) can alter program behavior by extending parts of the MOP. The MOP exposes some or all internal structure of the interpreter to the programmer. The MOP may manifest as a set of classes and methods that allow a program to inspect the state of the supporting system and alter its behaviour. MOPs are implemented as object-oriented programs where all objects are metaobjects.

The the best-known runtime MOP and the most powerful is the one described in the book "The Art of the Metaobject Protocol"; it applies to the Common Lisp Object System (CLOS) and allows full reflection (introspection and intercession) on every entity in CLOS (object, classes, methods, slots) and even on the mechanisms of inheritance, method dispatch, class instantiation and so on.

Even if your not interested in this meta-stuff, you should read this book because you will think differently after that, and you'll look at OO programming from another angle.
So my advice is: go META!

Stratified design

This is an idea from the book "Structure and Interpretation of Computer Programs" by Hal Abelson, Jerry Sussman and Julie Sussman (an excellent computer science text used in introductory courses at MIT - a must read book).
They come with the idea of Stratified design (programming in a sequence of levels, one level based on another), giving the example of The picture language.

"We have obtained a glimpse of another crucial idea about languages and program design. This is the approach of stratified design, the notion that a complex system should be structured as a sequence of levels that are described using a sequence of languages. Each level is constructed by combining parts that are regarded as primitive at that level, and the parts constructed at each level are used as primitives at the next level. The language used at each level of a stratified design has primitives, means of combination, and means of abstraction appropriate to that level of detail. ... Stratified design helps make programs robust, that is, it makes it likely that small changes in a specification will require correspondingly small changes in the program."

There is also a paper by the authors of the book on this topic: "Lisp: A Language for Stratified Design" by Abelson and Sussman.

This idea is put to work in some of the newer trends in programming, like Language Oriented Programming (Sergey Dmitriev), Intentional Programming (Charles Simonyi), Language workbenches (Martin Fowler), Little Languages (Matthias Felleisen), Grammarware (Ralf Lammel), etc.

Static vs. Dynamic Languages

In static typing all expressions have their types determined prior to the program being run (typically at compile-time).
Dynamic typing, also called latent typing, determines the type-safety of operations at runtime; in other words, types are associated with runtime values rather than textual expressions.

There's a lot of debate around dynamic vs. static typing.
The advantage to static typing is said to be increased safety, because types are checked before running the program and so many bugs are thought to be revealed.
The advantage to dynamic typing is that you do not waste all your time thinking at type problems and you can focus more on the programming itself. And about safety, even if you do not have compile time type checking, experience showed that dynamic languages (Lisp and Python) are surprisingly bug-free. Another good think with dynamic languages is that they do not restrain you from expressing naturally your thoughts directly. Dynamic languages are very good at prototyping and experiencing new ideas, because the delay between idea and runnable program is much more shorter. And even so it is showed that dynamic languages can scale; there are a lot of big projects using dynamic languages.

Even Bruce Eckel, author of "Thinking in C++" and "Thinking in Java", admitted that he prefers Python for expressing more naturally his thoughts in his article Static vs Dynamic: "I think that statically typed languages give the illusion of program correctness... In my own experience, it's very helpful to create models in a dynamic language, because there is a very low barrier to redesigning as you learn. Possibly more important, you're able to quickly try out your ideas to see how they work with actual data, to get some real feedback about the veracity of the model, and change the model rapidly to conform to your new understanding... By developing the model in a language that encourages change, my experience is that you end up with a better model, and this produces a distinct benefit when that model is translated to your implementation language... This last point is a major puzzle – we believe that static type checking prevents bugs, and yet a dynamically-typed language produces very good results anyway... My guess is that Python allows me to think more clearly about the concepts of the problem that I'm trying to solve. It is less distracting because it doesn't force me to think so much about the rules imposed by the language – rules that are basically arbitrary when I'm trying to produce an effective model of my problem space. By getting out of the way, Python and similar dynamic languages allow me to spend more of my brain's "seven plus or minus two" items on the problem itself, and less on the details of the language implementation... These are a couple of examples where too much static type checking, no matter how well-intentioned, gets in the way of both the creation and the examination of code."

So the conclusion: static typed languages are thought to be safer but dynamic ones turned to be more bug-free; static typed languages "stay in your way" of expressing your thoughts in programming while dynamic ones are more naturally at expressing ideas and experimenting. So why everybody insists on static typed languages?

Languages are software too!

Most people focus their attention on the software engineering, and always neglect the language. They think that languages are something static, with no evolution.

This idea is pointed out by Jean-Marie Favre in "Languages evolve too! Changing the Software Time Scale":
"However, most academics still consider languages as immutable artefacts. Language/software coevolution issues are still neglected. Migration issues are however commonplace in software industry... It is therefore time to recognize that languages evolve too. Languages are integral parts of software products. Languages are software too. This paper surveys a few models of evolution taking decades and centuries as time-scales."
"Misconception: languages are immutable. While everybody agree that software architecture evolves, most academics still consider computer languages as if they were immutable artefacts. For instance most people consider “grammar evolution” and “grammar reverse engineering” as strange combination of words. They often argue that a grammar can be seen as a mathematical entity, and as such it is eternal."

So if we study software engineering, why not study "language engineering". This term was coined by Ralf Rammel: "Who needs a language engineer? Language engineers are into grammars, types and declarative programs; they seek to facilitate these concepts for the purpose of improving the practice of software development; they push forward language-engineering foundations inspired by practical needs."

Languages are pieces of software: they are designed, implemented, maintained, and they also evolve. So to think languages are "immutable artefacts" it's only naive.

Patterns... what they really are?

There's a lot of talking around patterns in the last years. What patterns really are?

wikipedia.com says: "In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations."

Christopher Alexander says: "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"

GoF says: "A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context."

Alexander is the "father" of the idea, but GoF are accredited with the idea to apply patterns to programming. But don't let the GoF patterns mislead you. Those are only instances (Radu Marinescu) of the more general idea of pattern, the one intended by Alexander. The GoF patterns apply only to OOP and especially to static typed languages (C++/C#, Java, etc.). But these patterns don't apply for example to dynamic languages (like Lisp). Peter Norvig pointed this out in his paper "Design Patterns in Dynamic Programming": "16 of 23 patterns have qualitatively simpler implementation in Lisp or Dylan than in C++.", "16 of 23 patterns are either invisible or simpler." This lead people to say that "Patterns are signs of weakness in programming languages."(Mark Dominus - "Design patterns of 1972") and "When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough." (Paul Graham - "Revenge of the Nerds"). I think this is true, every pattern (or almost every) shows a missing feature in the language. Take for example the visitor pattern in C++/Java; it shows the missing of double-dispatch in the language. The same way in C we have the "Object-oriented class pattern" which shows the lack of OOP. So i must agree with Paul Graham that a pattern is a sign that were missing an higher abstraction.
If you want to know more about what Alexander's idea of patterns is then you better read his books, not GoF! Another book that speaks about Alexanders patterns in programming, not instances, is "Patterns of Languages" by Richard P. Gabriel.
So when you think at patterns, don't think at instances, but at a meta-level (Radu Marinescu), at the real idea of pattern.

Why Lisp?

I am big fan of the Lisp programming language. And everybody when hears this asks me "Why Lisp?". This is why, or better said, this is where you can find out why.

The best description of Lisp lies in the following quotes:

"Lisp has jokingly been called "the most intelligent way to misuse a computer". I think that description is a great compliment because it transmits the full flavor of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts."
- Edsger Dijkstra, CACM, 15:10

"Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot."
- Eric Raymond, "How to Become a Hacker"

If you really want to know what Lisp is about, you could read the following articles:

• "Why Lisp?" by Peter Seibel
• "Why Lisp?" by Peter Norvig
• Articles from Paul Graham
• "The Roots of Lisp"
• "Beating the Averages"
• "Revenge of the Nerds"

Now if you want to learn Lisp, you could start with this books:

• Ansi Common Lisp by Paul Graham (not free)
• Practical Common Lisp by Peter Seibel
  
• On Lisp by Paul Graham
• Common Lisp: An Interactive Approach by Stuart Shapiro
  

The place to start: The Association of Lisp User

And if you need a Lisp implementation (software) i recommend:

• GNU Lisp (Open Source)
• CMUCL (Carnegie Mellon University Common Lisp)
• SBCL (Steel Bank Common Lisp)
  
• LispWorks Personal Edition (free - IDE)
• Allegro Common Lisp Express Edition (free - IDE)

Generative programming

In the present i am interested in a way new of doing programming. This is widely known as Generative Programming but there are a lot of similar ideas. Here is a list of those similar ideas:

• Domain Specific Languages
• Model-Driven Engineering
• Generative Programming
  
• Language Oriented Programming (Sergey Dmitriev)
• Intentional Programming (Charles Simonyi)
• Language workbenches (Martin Fowler)
• Little Languages (Matthias Felleisen)
• Software Factories (Microsoft)
  
• Family-Oriented Abstraction, Specification, and Translation (The FAST Process) (David Weiss - Lucent)
• Grammarware (Ralf Lammel)

Maxwell’s equations of programming

Alan Kay – „How Simply and Understandably Could The "Personal Computing Experience" Be Programmed?” at The Intel Research Berkeley Programming Systems Seminar Series (November 27th 2006)


This are „Maxwell’s equations of programming”:

from John McCarthy – „LISP 1.5 Programmer's Manual”


Now we have to discover „The theory of relativity of programming” ...

Who's more important: the programmer or the machine?

This is a very important question you have to put to yourself before doing anything, because this will have a great influence on the way we program and think. Most of today's people are focusing on the machine: run faster, optimize, performance. This was a good idea back in the 60's-70's when machines were slow and the price of hardware was bigger than the price of programmers, but today (and from a long time ago) the proportion was reversed, people are way more expensive than hardware. So way always think at the machine, think at the programmers: what is better for them, how is more convenient for them. Thinking at the machine makes us lower the way we think and think like the machines, and this is by no means a good thing.

Donald Knuth: "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do."

Yukihiro "Matz" Matsumoro: "Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something." They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves."

John Backus: "While it is perhaps natural and inevitable that languages like Fortran and its successors should have developed out of the concept of the von Neumann computer as they did, the fact that such languages have dominated our thinking for twenty years is unfortunate. It is unfortunate because their long-standing familiarity will make it hard for us to understand and adopt new programming styles which one day will offer far greater intellectual and computational power."

Allen Newell: "Millions for compilers but hardly a penny for understanding human programming language use. Now, programming languages are obviously symmetrical, the computer on one side, the programmer on the other. In an appropriate science of computer languages, one would expect that half the effort would be on the computer side, understanding how to translate the languages into executable form, and half on the human side, understanding how to design languages that are easy or productive to use.... The human and computer parts of programming languages have developed in radical asymmetry."

The Feyerabend Project

The Feyerabend Project is Richard P. Gabriel's attempt to repair the arena of software development and practice.
"Fifty years into the First Computing Era some of us in the computing arena have come to realize we’ve made a false start that can’t be fixed, and for us to finally be able to produce lasting, correct, beautiful, usable, scalable, enjoyable software that stands the tests of time and moral human endeavor, we need to start over. Perhaps we’ll be able to salvage some of what we’ve learned from the First Era, but I expect almost everything except the most mathematical fundamentals to be brushed aside."
To begin thinking about how such a reinvention can take place, Richard P. Gabriel have put together some small workshops: at ChiliPLoP, at EuroPLoP, at OOPSLA.

What's next?

Were is the programming world of today? To a new paradigm shift (personal opinion). The current programming paradigm (object-oriented) is fading. Programmers need something more (you'll see this need more in the research area, not in the commercial area). But which will be the new paradigm? AOP, MDA? There's a lot attention to models this days; a lot of people would bet on that. The problem is not to focus all our attention in only one place. And maybe incremental evolution is not the answer. All great discoveries were revolutionary and not incremental evolutions. What would it be if Einstein didn't dare contradict all physics of his days to say that things are not as they seem? As Alan Kay says in a presentation at "The Intel Research Berkeley Programming Systems Seminar Series", we have the equivalent of Maxwell's equations (i'll let you discover what they are), but we still need the Theory of Relativity... This is kind of a radical way to think but this is the only way to get new and great things.

In 1975, Berkeley philosopher Paul Feyerabend wrote a book called "Against Method," in which he said: "...one of the most striking features of recent discussions in the history and philosophy of science is the realization that events and developments ... occurred only because some thinkers either decided not to be bound by certain ‘obvious’ methodological rules, or because they unwittingly broke them."
In "The Invisible Computer," Donald Norman wrote, "...the current paradigm is so thoroughly established that the only way to change is to start over again."

State of purpose

This blog will be a way of expressing my thoughts on programming. This will be something different, you will not see mainstream ideas here, but instead you will get new ideas, new way of looking at programming. As the subtitle says this is about the programming world of tomorrow. I will try to gather here some ideas from a lots of people i consider appealing and off course some of my ideas. I hope this will lead to something good, and helpful. So lets start...