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?