C– for cross compiler

In late 1994, when I need to write a programming language it was a pain. You must start with flex, lex and so on, and the way will be very long.

Then I found GCC was able to compile in a pseudo-machine language, already optimized. Then a set of backend was able to emit mc68000, 80×86, power pc code…

I am glad to see now there is a “stripped down” version of the C language to simplify this hard work….
By the way, Fortran has been the first compiled language, appeared near 1957.

“A new perspective on programming-language infrastructure”

Welcome to C–

Suppose you are writing a compiler; how will you get quality machine code? You might write your own code generator—but that’s a lot of work. You might use somebody else’s: perhaps VPO, MLRISC, or the gcc back end. But each of these impressive systems has a rich, complex, and ill-documented interface, and furthermore, to use MLRISC you must write your front end in ML, to use gcc you must write it in C, and so on. You might generate C, if you can live without multiple results in registers, proper tail calls, computed gotos, accurate garbage collection, and efficient exceptions.

You would be much happier with one portable assembly language that could be generated by a front end and implemented by any of several code generators. Such a language should serve as the interface between high-level compilers and retargetable, optimizing code generators. Authors of front ends and authors of code generators could cooperate easily. C– is that language.

What distinguishes C–

The following aspects of C– distinguish it from other compiler infrastructures:

* Other infrastructures focus on adding new optimizations; C– focuses on supporting multiple front ends for multiple languages.

* C– has a machine-level type system, so you don’t have to shoehorn your favorite high-level language into a high-level data model that doesn’t fit.

* C– provides a run-time interface, so you can implement garbage collection and exception handling using the techniques that are best suited to your language.

The run-time interface is the most novel and most distinguishing feature of C–.

via C– Home.

Designing Interfaces with Balsamiq

In the last seven months I have the need of sketching a bunch of interfaces, but I cannot find a valid tool. I was a Software Architect of a big huge project, busy also on other smaller projects as project manager.

I need a rapid way to sketch use cases, to pass them to a very young team.

Web interfaces are not easy to design, and we was in a very weird situation: the team was forced to use DAOs, with no O/R mapping tool. So I need also to map some interfaces to a database model, to help them building the model and the view classes

After some search, I ended up with MS Visio.

MS Visio is great, but too difficult to use, doing training is hard and so I must discourage its use.
Worst, Visio costs a lot, and it is not included with the standard MS-Office Tools.

Visio offers only WinXP look&Feel, which is not the best for designing agnostic web interfaces.

Thank you to a friend of mine, I have the discovered the BalsamIQ Mockup project.
Let’s see why it is a so good solution.

Continue reading “Designing Interfaces with Balsamiq”

iPhone programming

iPhone is the brand-new Apple product which has changed the way Apple thinks. Because of iPhone, Apple strip the word "Computers" from its brand name. And because of iPods and iPhone products, Lepoard developmenet slip a bit, blurring the focus on pure technology.
To be true, I do not beat on  the iPhone success, but the product success is at least  bright this year. And the iPod touch has also added value to the iPods product catalog. But I am an IT-man, damn you boy! So I want to buy it to play with it, to program with it!

The iPhone Open Application Development, is a fresh book on iPhone Developement, edited by O'Reilly which come into play. The book has less then 280 pages, and is well organized. First of all, the bad news: the book lacks figures and tables (only one, and not so useful) and no Photo on it. Then breaking the iPod firmware is not a thing Apple likes a lot. As far as I know, it is NOT illegal, because Apple is opening the device too.
Anyway, breaking the iPhone firmware can prevent you to get the upgrades so, you must know what you are going forward to do.

And now the good news: the book is well written, and guide the user from the beggining to the end.  There are a lot of way to free the iPhone from the jail.

After that, you can also use Linux to program on the iPhone, where the Apple SDK seems only "PC Mac"-enabled.

The book is composed of 7 chapters. After unlocking the iPhone (first chapter), the author explain us how to write code for it, and what is Objective-C. Objective-C is a very nice idea developed by Brad Cox, in the 1980. It is a C++ language "ante litteram". I like the ideas of Objective-Ch because you get the power of C for fast tasks (like  you know, coding your quicksort or your perfect B-trees :) and you get a true dynamic O.O. language, like SmallTalk is. Objective-C was not so lucky, and there are only two major implementation: the GNU one and the Apple one, used to build the entire MacOSX.
I have no time to study it a lot, but I suggest you to code the iPhone in Objective-C.
Then the books start to explore iPhone features like:

  • Basic user interface building blocks
  • Graphic Services and animation effects. You get also a Coreflow-like animation in the Appendix
  • Sound Control
  • Deep integration. A nice thing is the way to make calls: you simply ask the emmeded Safari to open a "tel://" url

The code presented is always very compact, and the style is nice.
The Appendix give us a lot of code samples.

Programming a so riche device is not easy, but the good news is you have a full O.S. to work with.
Java midlets and J2ME are much more difficult to use, if you will find your way with Objective-C.
A very good book, for very nice techno-guys, and not (only) for nerds!

 

 

 

The Valueteam PDFGenerator

 

Per un importante cliente di ValueTeam, ho sviluppato per un'applicazione chiamata PDFGenerator, che è stata pacchettizzata come un vero e proprio prodotto.
PDFGenerator nasce in una situazione caratterizzata da un alta variabilità dei requisiti utente.

Le specifiche del progetto hanno subito variazioni significative nell'arco di quattro anni, ed alla fine i requisiti utente erano parecchio mutati.  L'applicazione, già fatturata, non era ancora stata validata dal Cliente finale, ed era passata di mano moltissime volte.
Da un lato c'era la necessità di fornire uno strumento semplice da utilizzare, dall'altro la possibilità di espanderlo nel momento in cui le esigenze di Business del Cliente fossero cambiate, contenendo i costi di sviluppo.
Questi due aspetti erano acuiti in questo contesto, poiché i dati potevano provenire da fonti assai eterogenee per tipologia (database o personale del marketing) e l'utente finale doveva elaborarle in modo uniforme e rapido.
Per queste ragioni la specifica era cambiata spesso nel tempo, e la sfida era notevole.
PDFGenerator è semplice dal punto di vista software, e la sua forza sta nell'idea, e nella capacità di capire l'utente finale.

Si tratta di una applicazione che è in grado di caricare dati da un backend, e di generare poi a partire da esso una serie di documenti Word parametrici, da cui l'utente genera documenti pdf.
Tali documenti sono una serie di informative sui prodotti erogati dal Cliente verso i loro partner commerciali.

Si tratta di gestire agevolmente oltre 500 documenti, simili tra loro ma divisi in moltissime tipologie.

L'applicazione consente all'ufficio marketing di creare informative personalizzate, ed è integrata con Microsoft Office.
Il back end può essere esteso in diversi linguaggi (Java, .NET ecc) purché generi in uscita un file Excel.
Un modello MS-Word poi si occupa di integrare, con una serie di macro, i dati provenienti dall'Excel e di consentire, in modo guidato, la generazione di un vasto numero di documenti MS-Word.
E' quindi possibile estendere l'applicazione nelle due direzioni:
+ dal lato backend, arricchendo i moduli che forniscono i dati.
+ dal lato del front end, personalizzando l'interfaccia utente
L'estrema attenzione al Cliente si è concretizzata nello sforzo di fornire una interfaccia di amministrazione semplice e gradevole, seguendo i più moderni dettami dello Human Interface Design.

Inoltre, l'aspetto più importante è stato comprendere le esigenze del cliente attraverso lo sviluppo incrementale di una serie di prototipi operativi. Lo sviluppo di prototipi operativi in tecnologia WebJ2EE risulta difficoltoso,  mentre appoggiandosi agli widget grafici di MS-Office è stato possibile ridurre di quasi tre volte lo sforzo operativo.

Per maggiori informazioni, mandate un email

Javascript and Smalltalk

There is a future for SmallTalk? I was a very strong fan of the SmallTalk language, but in the last five years I have seen more and more contraction of its usage in the IT field.

The OLPC project, which uses also Squeak Smalltalk and its done by the core team fo Squeak, is not going very well.

Anyway, Dan Ingalls, one of the father of Smalltalk, is working on a new project called Lively. It is a rewrite of Morphic in Javascript, especially target  for building a Squeak-like interface.

 The interesting part of this work is a paper outlining the limitation of javascript as programming language. I have tried in the past years to look for ajax and or web 2.0 javascript libraries, but I feel very difficult to develop with them.

From the Paper we underline these parts:

Loading multiple JavaScript applications into the same virtual machine is problematic.[…] For instance, if two programs
happen to use the same names for global variables or functions, the overlapping variables or functions of
the first program will be replaced with the corresponding features of the second program, resulting in
unexpected behavior in the subsequent execution of the first program. Since JavaScript will not typically
give any warning messages or errors in such situations, the resulting behavior can sometimes be a total
surprise; in many cases the errors resulting from such situations may not be discovered until much later.

 

Evolutionary development approach is a necessity. Due to the highly permissive, error-tolerant nature of
JavaScript, JavaScript programming requires an incremental, evolutionary software development
approach. Since errors are reported much later than usual, by the time an error is reported it is often
surprisingly difficult to pinpoint the original location of the error. Error detection is made harder by the
dynamic nature of JavaScript, for instance, by the possibility to change some of the system features on
the fly.

 

A lot of room is left in optimizing JavaScript performance. Current JavaScript virtual machines are
unnecessarily slow. Even though JavaScript is a significantly more dynamic language than, for instance,
the Java programming language, there is no fundamental reason for JavaScript VMs to run two orders of
magnitude slower than Java virtual machines.

 

Memory management capabilities of the current JavaScript VMs are poorly suited to large, long-running
applications. Current JavaScript virtual machines have simple, 1970's style garbage collectors

 The reason of these issue are simple:JavaScript was intially a language for web developers, small and easy to use, and very compact.
Absence of errors or warning is a nightmare, if you care of your digitating time.
And Javascript is slow because no one will write  long script with it.

A very compact and clean discussion can be found in http://javascript.crockford.com/javascript.html 

Fixing these problems is hard. Until the current  implementation will not provide a better way of error detection, writing javascript code will be a very long and time-consuming task.

And using a so old garbage collector, give a chance to a c/64 BasicV2 to beat your code:  you are awared, guys :)

Anyway, there is a good set of javascript libraries out of there (prototype and jquery, for instance but not only), so you should be quite happy