Maurizio De Cecco professional site

Nothing new under the sun ?

admin — Wed, 29 Oct 2008 10:49:07 +0000

I was terrified a while ago in reading a comment qualifing the interpreted dynamically typed
languages as an example of "modern programming", against the old compiled, static typed dinosaurs.

Nothing against dynamic interpreted languages, but a lot against ignoring the programming languages
history. The first widely used example of both categories (dynamically typed and statically typed
languages) are LISP and Fortran. Lisp born in 1958, and Fortran in 1957 (first compiler available).

When i started my career as professional LISP programmer, in 1984, the debate between dynamically
typed and statically typed languages was already twenty years old; there is no way one of the two
can be called modern, they are two side of the same coins, born together, will die together.

Today we live with the false impression that the computer world move very fast. A hip technology
today will obsolete in three years. If you take the time to study the computer world history, you
will discover that this is not true. While a technology can come up in fashion for a short period,
and then apparently fade away, the evolution of technologies, especially software technology, is
very slow, and their application take a long, some time very long, time. They disappear because for
a while they are not anymore in the economical sweet spot, but the acquire more sense later, and
reappear with new names and new syntactic sugar.

This is not to say that it is always the same stuff: the technologies evolve and improve at each
iteration, but radical revolutions or disrupting changes are very rare, and a lot more connected
with economics than with the technology taken by itself (as the Internet story shows).

Let's take some example in the software field, a few buff words.

Virtualisation: what a new concept; the first commercial system providing full virtualisation
on the server side was available in 1968, and it is still in production (it is called today Z/VM);
the advantages of using virtualisation are knew since that time, and the basic principles too.

Object Oriented Programming Languages: the first language with OO extensions was Simula, in 1967.
In the 70s we had already large scale OO systems, for example full OS and window systems completely
written in an OO language (thing that we still don't have today). Java have little or no innovation
in the language department: it is a very nice piece of engineering work, defining an OO language
simple enough to be widely adopted, still elegant and complete. But essentially, Java borrowed concepts
from existing languages, cleaning them up and providing (later an industrial grade implementation.

Graphic IDEs: actually came with OO systems, around 75. Industrially available at the beginning of
the 80s. You would be surprised to see how many similarities you could find between the Symbolics
Genera environment and Eclispe. But you still cannot recompile a single C function or Java method
and reload it on a running system, you could at the time (for C and OO Lisp).

Aspect Oriented Programming: changed name, but the MIT Lisp machine supported aspect oriented
programming (using technologies called multiple inheritance and method combination at the time)
and largely used it in its software architecture (colors where added to the window system
essentially by adding a color aspect to basic graphic objects, for example).

And so on ... these are just examples.

So, what all this summ up to ? Just wild rantings from an old developer ? No, all this is actually
about you, and what history (computer science history) can teach you.

Remember: almost no idea is as new as it seems. Even Html and the web. If are looking for something
innovative on a particular field, take a took back in time: you surely find ideas and inspiration
for you innovation. If somebody is trying to sell you the better innovation after toasters, check
it twice: you'll find that the innovation is very close to something already done.

My bet on the short term future is that we will see the development of a lot a new, innovating,
revolutionary programming languages dramatically simplifying concurrent programming (after all, we
*have* to use all these cores). Most of them will be re-editions of the studies done in the
beginning of the 80s, where the first hype wave around parallel architectures exploded.
Be ready to new renamed versions of CSP, Occam, Erlan, Actor languages and the others. And soon we
will talk about "modern" parallel programming, and how it make obsolete old languages as Java.

jMax Phoenix platforms and portability

admin — Sat, 16 Aug 2008 20:17:19 +0000

As of today, we don’t know if jMax Phoenix will succeed in having a reasonable developer community. For this reason, the objectives in term of platform and portability are reduced, they may be revised later if resources are availables.

The target platform is Linux. Development is currently done on Xubuntu on amd64, and personally plan to shif to Studio 64. The strategic objectives are to cover all the main Linux distributions, 32 and 64 bits.

Today jMax is pretty open in terms of I/O systems, but future evolutions will tie it more to jack and to callback audio systems. The basic compilation environment will be gcc, and no effort will be done to be compatible with other compilers. Future versions will be heavily based on Posix Threads.

For what regard other operating systems, only environments based on gcc/jack will be supported, if we find developers willing to help. So, MacOSX yes, Windows with some limitation.

Remember anyway that the graphic UI of jMax is written in Java, and portable to all environments supporting Java 6. The UI is even able to connect thru the network to the computational server, so you may image in the future the UI running on a Windows laptop with the computation done in a back end 8 cores Linux server.

We do not plan integration with Windows or MacOSX specific I/O subsystems or plugin standards, like ASIO or VST.

We do not plan directly supporting non-jack audio or Midi I/O on Linux. We do plan to integrate support to host LADSPA plugins as jMax objects.

Producing LADSPA plugin from jMax patch is an interesting strategic direction, under the condition that we are able to compile a patch and produce an atomic object (to really use the plugin as an independent object that do not need the jMax UI, and for performance reasons).

jMax friends

admin — Fri, 15 Aug 2008 19:39:44 +0000

Just a small note to let you know that a couple of old friends, Enzo Maggi and François Dechelle, joined the jMax Phoenix project. They were both in the Ircam jMax equipe, and François was the project leader.

jMax Phoenix development principles

admin — Fri, 15 Aug 2008 19:35:03 +0000

I will follows a small number of basic principles in the future development of jMax, technical and strategical. I will ask all the contributor (if any ) to follow these principles too. The following are the first four.

If it isn’t broken, don’t fix it.

There are thousands of ways of doing things, and most of the time there is a least one that is better of the solution adopted in jMax. This is not a good reason to change the architecture, re-engineer the system, or change a part of it. Unless the fulfillment of an actual, real, requirement cannot be achieved as a consequence of a technical choice, this choice will not be changed.

Good enough is enough.

Same story. If a choice satisfy the requirement, we will not change it for the fun of it.

The intelligence is in the UI

The computational server (fts) must do what is it role to do, I.e. compute, and be the simplest and lighter possible. Configuration, higher level abstraction like packages and projects, aggregation and all high level functionalities must be implemented in Java in the UI, within the architectural limits of the system.

The UI is scripted

jMax is a system for power users. I assume that users that spent an year in developing a composition, a package, objects and so on can write also a few line in a scripting language.

More over, power users want the freedom to customize the system and change its behavior.

The jMax 2.45 UI already offer a set of scripting primitives that are not documented; in jMax Phoenix these primitives will be document and the role of scripting will be extended to allows customization of most or all of the user interface aspects.

The scripting language is jacl

Jacl (tcl for java) is a fine language. It actually had a nice success and it is currently used in mission critical environments to manage the WebSphere application servers. Yes, there are nicer languages.

See points 1 and 2.

jMax Phoenix

admin — Fri, 15 Aug 2008 19:31:44 +0000

Rumors of the jMax demise have been greately exaggerated. Free software never die, just sleep for some time. For jMax, it has been a long sleep, but I decided to wake it up.

As I describe elsewhere on this site, I was on of the original designer of jMax, and it was one of the project where I had the most fun. When I left Ircam, for various reasons, I left the project knowing that I did not not had the time to bring it to the technically excellency I was looking for, and to develop all the ideas I originally put in the design.

Have never though of going back in the past and fix some fundamental problem in your life ? Well, with free software, you can. OK, you cannot fix your life, but you can fix the code. I don’t write code anymore in my daily job, it was time to have some serious fun in a personal project.

The time is also correct: jMax was written for an high end high performance system; at least two processors were required to run it correctly, and a high computing power; it happens today that most of the PCs have at least two core, and plenty of computing power. Now jMax can easily run and be developed on any machine. The project was also very in advance of his time in its use of Java as a portable UI environment; at the time the performance of Java was not exactly optimal, and the swing UI toolkit just a first approximation of what we have today; also, no free implementation of Java were available, thing that reduced the interest of the free software community in jMax.

What were at that time the limits of jMax, are today his strength.It can use multiple processors, it use a very reach and powerful graphic environment, and have a architecture defined for the future.

Please not that the jMax Phoenix project is a fork of the original code base and cvs, taken around the time I left Ircam. For those who know the jMax history, jMax Phoenix will start from jMax 2.4.5. Later developments will be backported if judged interesting.

I’ll use this post to trace design and coding decisions for future reference.

If you are interested, take a look to the source forge project called jMax Phoenix; you can subscribe to one or both of the mailing lists there (users, developers), and get an idea of technical work going on from the archives. If you want to know more about all this, you can also contact me directly at maurio at dececco dot name.