Michael Wiedekings Frust mit Scala – und der meine

Auf seinem heise developer-Blog Babel-Bulletin schreibt Michael Wiedeking den Beitrag “Runterskaliert” über die funktionale Programmiersprache Scala und seine Probleme damit. Auch wenn dieser Blog-Beitrag schon fast angestaubt ist (einen Monat alt), konnte ich mich in einigen seiner Kritikpunkte wiederfinden, und auch meine Faszination für Scala und die damit umgesetzten Konzepte aus der Welt der Funktionalen Programmierung findet sich in seinem Beitrag wieder.

Und trotzdem hinterlässt der Beitrag einen etwas schalen Nachgeschmack.

Aber erst mal schön der Reihe nach.

Wiedeking zählt zunächst einige der Eigenschaften von Scala auf, die ihm an Scala erwähnenswert erscheinen:

Bei Scala gefällt mir der Ansatz, dass wirklich ausnahmslos alles ein Objekt ist…

Diesen Umstand findet ein Smalltalk-Liebhaber natürlich auch sehr vertraut und attraktiv. Schliesslich ist neben Typecasting und viel syntaktischem Grundrauschen vor allem die seltsam anmutende Tatsache, dass es in (sagen wir mal) Java für z.B. Ganzzahlen zwei Typen existieren, denen man auch erst kurz nach der Pubertät beibrachte, dass sie sich automatisch ineinander umwandeln können (Autoboxing), immer wieder ein Kopfschütteln wert, wenn man das nicht als ein unumstössliches Faktum mit der Muttermilch aufgenommen hat.

…wie schön einige der syntaktischen Probleme gelöst werden…

da der Autor nicht weiter darauf eingeht, was er hier meint, lese ich das als “mir hat die Syntax gut gefallen”. Auch hier finde ich mich wieder, Scala liest sich weitaus angenehmer als Ruby (sic!) oder eine Sprache aus dem C-Dunstkreis. Aber das ist natürlich reine Geschmacks- und Gewöhnungssache. Smalltalk haftet ja auch eine Aura seltsamer Syntax an.

und – nicht zuletzt – dass ich die komplette Java-Bibliothek zur Verfügung habe

Das ist natürlich ein Riesen Vorteil, den es nicht zu verachten gilt. Zwar gibt es einige Beschränkungen in der Scala-Java-Interoperabilität, aber diese betreffen in erster Linie den umgekehrten Weg, also die Nutzung von Scala aus Java heraus. Die Tatsache aber, dass ein Scala-Programm auf so ziemlich jeder (aktuellen) Java-Laufzeitumgebung aufgesetzt werden kann, und dass eine riesige Auswahl an Bibliotheken aus der Java-Welt zur Verfügung stehen, ist ein sehr gewichtiges und stechendes Argument. So ist es denkbar, eine Scala-Anwendung zu schreiben, und die Oberflächen in SWT oder Swing zu implementieren. Dafür stehen dann auch bereits bewährte Werkzeuge wie SWT Designer oder WindowBuilder zur Verfügung. Auch die komplette RCP-Umgebung von Eclipse steht dem Scala-Entwickler offen, um vertraut wirkende Oberflächen bereitzustellen. Bestechend ist auch die Idee, die Persistenz der Scala-Objekte in einem Java-Framework zu implementieren, und damit auf Bewährtes und gut Dokumentiertes zurückzugreifen.

Gerade hier wird aber auch klar, dass es in Scala meist nicht ganz ohne Java gehen wird. Das muss kein Nachteil sein, kann aber.

Schliesslich wird man um ein gerüttelt Mass an Java-Kenntnissen nicht herumkommen, und letztlich in der Wartungsphase eines Projektes immer beide Technologien vorhalten müssen. Ein Mix aus zwei Sprachen, wie nahe sie auch immer beieinander sein mögen, bedeutet immer auch, dass man bei der Käferjagd über Grenzen springen muss. Steckt man mitten im Debugger und ist an einer Stelle angekommen, an der aus Scala heraus Java-Methoden aufgerufen werden (oder umgekehrt), ist erst mal ein Moment des Innehaltens und Kontextumschaltens angesagt. Selbst, wenn ein Debugger zur Verfügung stünde, der den Übergang nahtlos darstellen könnte, befände man sich auf einem neuen Planeten: hier bin ich nicht mehr in der funktionalen Welt, und die Syntax hier vor mir ist Java, nicht Scala…

Ich will das Thema nun aber nicht überstrapazieren, der geneigte Leser kann sich sicher sein Bild davon machen, was ich meine: spätestens bei der Bearbeitung von Troubletickets ist “die andere Seite” nicht mehr als Black Box akzeptabel, auch wenn sich das ganze beim Entwickeln noch so anfühlen mag. Ich bin, wenn ich an einem Java-Debugger sitze, immer wieder irritiert, wenn dieser mir Quelltext vorenthalten will, aber das ist eine andere Geschichte…

Als Smalltalker kann ich auch das Folgende sehr gut nachvollziehen:

Beispielhaft sei hier nur das Operator Overloading erwähnt. Es hatte mich schon bei C++ begeistert, da ich schon immer fand, dass

ab + c

deutlich einfacher als

a.mul(b).add(c)

zu lesen ist

Denn in Smalltalk gibt es ebenfalls keine Operatoren, sondern nur Methoden, und es ist gar kein Problem, die Methode + zu überschreiben. Natürlich gibt es Punkte, an denen man wissen sollte, was man tut, wenn man es denn tut, aber das sollte kein Argument gegen Operator Overloading sein. In diesem Kontext sei ein kleines Beispiel aus grauer Vorzeit bemüht:

Kaum war der Jahrtausendwende-Spuk vorüber, und wir waren alle knapp dem Weltuntergang entronnen, versank die IT-Welt in der nächsten Katastrophe: Die Euro-Umstellung (manch einer mag sich nun wieder an lange Nächte, Schlaflosigkeit und vor allem eine gewisse Unruhe im Management erinnern, die zu vielen unerquicklichen Reports und Status Meetings führte) . Millionenbeträge wurden investiert, um Programme fit für die neuen Umrechnungs- und Rundungsregeln sowie die Umstellung in zwei Phasen fit zu machen. In einem Smalltalk-Projekt konnten wir hier mit relativ wenig Aufwand eine Klasse für Geldbeträge einführen, die sich nach aussen hin mit dem API einer Zahl präsentierte, und intern den gesamten Verwaltungskram abhandelte (in welcher Europhase sind wir, bin ich eine Summe aus Beträgen in zweierlei Währungen etc.). Für sämtliche Stellen, die also vorher zwei Zahlen unter Verwendung der Methode + addierten, änderte sich gar nichts. Es musste lediglich dafür gesorgt werden, dass alles, was einen Betrag erzeugte, eben nicht mehr nur eine Zahl instanziierte, sondern ein Objekt der Klasse EuroBetrag. Der Rest des Systems blieb unangetastet. So war der ganze Spuk in ein paar Wochen erledigt (inklusive Tests), und wir konnten neue Features implementieren, während andere Projekte enormen Aufwand treiben mussten.

Also, kurz gefasst: Operator Overloading kann extrem mächtig sein, und enorme Produktivitätsvorteile bieten, wenn man sich sparen kann, jeden einzelnen +-Operator darauf zu untersuchen, ob er nun ein Aufruf der add-Methode der neuen EuroBetrag-Klasse sein muss oder nicht.

Jetzt aber kommt der erste Stolperstein für meine positive Grundeinstellung gegenüber Herrn Wiedekings Artikel, in dem er die aus seiner Sicht großen Vorteile des Operator-Overloadings darstellt. So sieht er es als zusätzlichen Vorteil, dass Scala es erlaubt,

beliebige Unicode-Zeichen als Operatoren zu definieren. So konnte ich beispielsweise beim Herumexperimentieren einen regulären Ausdruck der folgenden Art schaffen:

NUMBER = LPAR ∙ (SP↯) ∙ (ALPHANUM ↦ 0) ∙ (SP↯) ∙ RPAR ∙ (SUBNUM ↦ 1)

Ich muss zugeben, dass meine Kenntnisse in der Erfassung von Unicode-Zeichen über die Tastatur eines heute gebräuchlichen PCs oder Macs sicher verbesserungsfähig sind, aber irgendwie kann ich mich des Gedankens nicht erwehren, dass ich hier verloren ging. Nicht nur, weil ich mathematisch nicht mehr mithalten kann, sondern auch, weil ich hier fast glaube, dass diese Unicode-Sache für Operatoren dann doch etwas zu weit geht.
Wobei das vielleicht nicht für Anwendungen im mathematischen oder Engineering-Bereich gilt. Letztendlich liest sich der Code für einen Mathematiker dann doch sehr gut.
Ich fand das Beispiel allerdings sehr esoterisch und nicht wirklich ein gelungenes Plädoyer für Operator Overloading oder Scala.

Nun kommt Wiedeking aber zu einem sehr interessanten Punkt:

So habe ich also Scala schätzen und nutzen gelernt, habe mich aber trotzdem gegen einen professionellen Einsatz von Scala entscheiden müssen. Das ist insofern bedauerlich, weil Scala einen deutlich höheren Wiederverwendungsgrad hat als beispielsweise Java.

So ging es mir auch: Scala gefällt mir gut, und die Möglichkeiten durch die Java-Basis sind sehr bestechend, aber so recht zu Scala konvertiert bin ich auch (noch?) nicht.Während wir gleich noch auf Wiedekings Argumente gegen Scala eingehen, hier ein paar Gedanken von mir:

Ein Aspekt auf den Wiedeking in seinem Artikel nicht wirklich eingeht, sind die funktionalen Ansätze in Scala, die in vielen Problembereichen sehr mächtige Vorteile sein können. So ist es durch die Nutzung von Konstanten (also vals) anstatt Variablen, und durch die Freiheit von Seiteneffekten bei der Bearbeitung von Konstanten sehr schön möglich, sehr gut lesbaren Code zu schreiben, und vor allem, Funktionen so zu formulieren, dass sie gut in einem eigenen Thread ablaufen können. Scala hilft bei der Parallelisierung von Aufgaben und kann so einen wichtigen Beitrag zur effizienteren Nutzung von Multicore-Prozessoren leisten. Wohlgemerkt, solange man Scala als funktionale Programmiersprache nutzt. Nun sind in meiner Projektpraxis ab und an Aufgaben auszumachen, bei denen man sich eine einfach zu implementierende multithreading-Fähigkeit wünschen würde, aber die Regel ist dies nicht. So wäre es manchmal schön, mitten in einem Smalltalk- oder Java-Programm eine solche Funktion zu formulieren und sie parallel ausführen zu lassen. Aber meist lässt sich dies auch mit den Bordmitteln der Sprache auch schon lösen, wenn auch möglicherweise mit etwas mehr Aufwand. Das halte ich für Vertretbar, wenn es um wenige Tasks in einem Programm geht. Smalltalk-Blöcke sind hier sicher ein hervorragender Ersatz für Funtionen in Scala, da diese in ihrer Eigenschaft als Objekte auch herumgereicht und jederzeit mit anderen Inhalten auswerten kann. Sonderlich weit ist ein Smalltalk-Block von einer Funktion in Scala nicht entfernt. Eines jedoch ist ein Vorteil von Scala: eine Funktion kann als nativer Thread ausgeführt werden. In Smalltalks Green Threads – Modell geht dies nicht. Hier sind noch Ansätze gefragt, die auch eine Unterstützung von Multicores in Smalltalk bringt.

Nun aber zurück zu Wiedekings Argumentation:

Der Grund ist ein ganz anderer: Es ist die Entwicklungsumgebung. Ich gehöre eigentlich zu denen, die, bis es nicht mehr anders ging, mit dem “vi”, “emacs” oder vergleichbaren Editoren gearbeitet haben. Und eine Zeit lang war das auch vollkommen ausreichend. Allerdings hatte sich das schlagartig mit dem Einzug der Refactoring-Fähigkeiten moderner IDEs geändert.

Ja, hier wird es düster um Scala (wie auch um andere der aktuell sehr beliebten Sprachen, etwa Ruby, erlang o.ä.). Zwar gibt es ein Eclipse-Plugin, das einge der heute üblichen Werkzeuge, wie man sie aus Eclipse, IntelliJ oder modernen Smalltalk-Entwicklungen kennt, bietet, aber eben leider keinen guten Eindruck hinterlässt. Ich habe es bisher auf den meisten Eclipse-Installationen nicht (oder nicht vollständig) zum Laufen gebracht, auf denen ich es versucht habe. Und die Tools sind noch weit davon entfernt, den Umfang eines Eclipse-Debuggers oder Smalltalk-Inspectors zu erreichen. Geschweige denn deren Stabilität. Das ist nun irgendwo auch nicht verwunderlich, denn die Tools, mit denen ich das Scala-Plugin vergeliche, sind von einem Heer von bezahlten Programmierern erstellt worden, und nicht von einigen wenigen Enthusiasten, Diplomanden und Doktoranden. Insofern ist es ein unfairer Vergleich zwischen Äpfeln und Birnen. Und dennoch zieht es der Mensch eben vor, ein funktionierendes Werkzeug zu nutzen.

So habe auch ich vorerst das selbe Fazit gezogen wie Wiedeking:

Nichtsdestoweniger werde ich die Entwicklungsumgebungen von Scala im Auge behalten. Und sobald sie meinen Ansprüchen genügen, werde ich nie wieder in Java programmieren müssen.

Nur mit dem Unterschied, dass ich mit Smalltalk deutlich weniger unzufrieden bin, als er mit Java 😉

So stimme ich Herrn Wiedeking zu, dass Scala als Ersatz für unsere jetzige Umgebung nicht in Frage kommt, aber wir beide beurteilen die Sprache Scala in völlig unfairer Weise über die für sie verfügbaren Tools, anstatt uns mit den Fragen auseinander zu setzen, welche konkreten Vorteile die Sprachmittel von Scala uns gegenüber unserer aktuellen Lieblingssprache bietet. Ich glaube aber, wir sind da nicht die einzigen…

Smalltalk Solutions is Back. March 2011.

Georg from the Smalltalk Industry Council just announced Smalltalk Solutions 2011, which will be held in Vegas, March 13th to March 16th 2011.

This time, one of our goals is to attract strangers, i.e. non-Smalltalk[er]s to our conference.

Times for this have never been better over the last 10 years, so I hope STIC and the organizers will reach lots of Smalltalk-wannabees.

It’s good to see Smalltalk Solutions being revived. Smalltalk now has major vendor-neutral events on three continents:

If I look at what we’ve heard from people in the U.S. after our VA Smalltalk Forum Europe I guess this is great news for all the Smalltalkers abroad!

VFE2010: Video of my talk is online

Marten Feldtmann is working his way through a hole day’s material of recordings of our VA Smalltalk Forum 2010. He’s just finished editing the video of my talk that and put it online. You can view or download it from his blog.

I’m surprised by the high sound quality of the vidoes and I’d say Marten did a great job of recording and editing the sessions. I want to repeat my Thank you for that!

PragDave on Software Archeology and The Advantages of Self-Containment

I just finished listening to Episode 148: Software Archaeology with Dave Thomas (Pragmatic Dave) of Software Engineering Radio.

It’s a really interesting interview and Dave has a lot to say about our Software Engineering Jobs of today:

  • Most of the time we read code rather than write it
  • Most of the code we have to read is in less than perfect shape
  • Most of the programmers aren’t educated in how to read code
  • Far too often people change code they don’t really understand
  • Tests are a great way of proving your hypotheses about what existing code does
  • Code rots, and you have to be prepared or it
  • Only documentation tends to rot faster than code
  • Most documentation that gets written is mostly useless, because people tend to document the obvious rather than the reasoning behind their decisions
  • Reading code is not only good in software maintenance but also is an educating exercise
  • You can write bad code in any language, but also: a well-written program can be easy to understand in any language

There’s not much space for disagreement here, since you learn these lessons pretty fast when you maintain software. Also the idea of having to “get into people’s heads” about their style of programming, thinking and problem solving is absolutely right. To me, it’s often good to know who wrote a method, especially in projects where I know the initial programmers. You sometimes really know why something was done in a certain way if you know who wrote the code.

So it may sound funny, but sometimes you find your way to a bug a lot faster by knowing whose code it’s in. Every programmer leaves some DNA in their code, and since software maintenance has a lot in common with detective stories, it’s always good to have a profile of your “Mister X” in mind 😉

Some of the things Dave talks about sound weird or ridiculously obvious at first:

  • Print out an artefact in 2pt font size to learn about its structure
  • You need to make sure you’re digging in the right version of the code
  • You need to make sure you have all the necessary code
  • Use a local code repository
  • IDE’s and code generation can be dangerous
  • Tools like Emacs and grep can be of great help

But once you think about them, you’ll find them much more useful advice than they sound in the first place.

When trying to translate some of these to Smalltalk, however, I guess we can put some of these aside. There’s no point in using grep on Smalltalk code if you work in an image based environment. There are much better tools like References, Senders/Implementers and such. And there’s not much use in looking at a body of code isolated from the Smalltalk class library. In the light of these arguments, the use of a good source code control system like Envy becomes more important. Since I never tried the tiny font-size thing, I can not really judge it. But I can imagine that in a purely file based world, even this kind of thing can help (and if not, it’s been worth a try).

This, combined with the fact that software archeology is not necessarily a nondestructive task (it’s not about conserving code, but about understanding it), version control gets more important. As I mentioned in my talk at the VA Smalltalk Forum two weeks ago, Refactoring is a great way of finding your way into existing code. Sometimes just changing the name of a temporary variable or a parameter or extracting parts of e method and giving it an intention revealing name makes understanding code a whole lot easier.

Dave also mentions the importance of getting a hold on all artefacts that are needed to make a piece of code run, like database creation scripts and stuff. Since I am a strong believer in “get all your stuff into your code repository” and since my favourite language Smalltalk makes this quite easy by having the compiler available to create classes out of scripts (again, see my talk for an example), I think we have a very good environement to our disposal to make the lives of later software archeologists easier.

Since Software Maintenance is one of the most important and least appreciated tasks in Software Engineering, I guess we owe it to ourselves and to the developers who need to get along with our code to use techniques and tools that make archeology easier. We need to improve our coding style, documentation habits and we need to keep in mind our code is not only there to be executed by machines, but mostly to be understood and reworked by humans.

And I guess there aren’t many environments that make reading (into) code as easy as Smalltalk. The Smalltalk Debugger as a means of watching the innards of a program on the job and even modifying a program in the middle of a task, together with a rich set of inspection tools and well-integrated testing facilities like sUnit, combined with a whole set of Code Browsers that are written around the idea that “FINDING EXISTING CODE” is the main task in programming, not only make writing code easier in the first place, but also help later developer generations to understand our code.

In case of Smalltalk, this is not a theoretical assumption, it is a proven fact that the language allows for long product lifecycles. There are many systems around that are running for more than one and a half decade, and continue to be integrated into modern architectures like Web Services or to be transformed into Web based applications while also adding new features all the time. This would presumable be a lot harder in less maintenance-friendly environments.

As developers, it’s our responsibility to lay the grounds for later generations, and we have to make decisions that will have consequences even when they’re pushing us through the park of our elderly’s home on a wheelchair every wednesday afternoon. So using an environment that’s helpful in reading code and checking hypotheses is what we should do. Smalltalk is an environment that qualifies in this area and should seriously considered as the platform of choice.

Many people out there think that Image-based systems are a bad thing, since they feel they’re losing control over their system’s structure, but it’s quite the opposite: A Smalltalk Image is the whole world of the objects in a system and therefor gives you much more abilities to explore and search than a list of dead files. In the end, in an object world, what kind of structure does a file give you? Your running program consists of classes and instances, not of files.

Taking Dave’s Analogy a step further, there is a strong advantage in Smalltalk, because learning about existing code is not really archeology, but much more like time travel: you just jump into the bazaar of a running system, talk to the merchants and visit the temple on the hill instead of just digging some old stones out of the sands. So while software archeologists try to imagine how a system might work or have worked, we Smalltalk developers have the luxury of just starting the system up and live in there for a day or two.

Squeak on the iPad: Cool!

Bert Freudenberg has put up a short video of his port of the Squeak VM (based on John McIntosh’s port for iPhone) and Etoys onto YouTube.

It looks really cool: Multi-Finger gestures on this nice pad computer to let little race cars drive around. I am not sure I’d like to use the screen keyboard for coding in Smalltalk, but as an Etoys-based learning machine, this is really cool.

Now if only Apple’s policy on interpreted languages was a bit more reliable and transparent, we could invest in Smalltalk-based apps for the iPhone/iPad…

VFE 2010: Attendee fedback

At last week’s VA Smalltalk Forum Europe 2010, we asked ourattendees for feedback. Based on the forms that were returned, it seems we did quite well:

  • 77% of the attendees saw their expectations met, while 23% partially got what they were looking for
  • 64% found the organizations of the event very good, 33% thought it was good
  • 94% said they’d recommend the VA Smalltalk Forum Europe to their colleagues and Smalltalker friends

Since we’ve had an extremely packed and interesting agenda this year, the top most point of critique was that there was too little time for networking in the coffee breaks and at lunch time. We’ve gotten the message and will reduce our agenda for next year by at least one session / hour and plan for longer breaks. The fact that two sessions were held remotely also was a point that was criticized, because the feedback loop is too long to ask detailed questions. And, it would have been nice to discuss more details at a coffee table.

We also asked for individual feedback on all our sessions, and all I can say is that it seems we pretty much hit the nerve of our attendees topic-wise as well as with respect to the quality of the talks. The top score went to Lukas’ Seaside talk, which is no surprise to me at all.

By the way, you can download all presentations [link was updated] from various places. And, even better, Marten has recorded all sessions and is currently working on editing them. A few have already been put online.

People liked the food and the location, which was very practically situated directly at the main train station in Stuttgart. So coming to and leaving from the event was easy. I guess the location was chosen not too badly, since we had attendees from Germany, Switzerland, The Netherlands, Liechtenstein, Belgium and the UK.

I guess our feedback shows that you really missed something if you were hesitant to come this year.  But I’m quite sure there’ll be another chance. There are no specific plans for a next event yet, but I guess we’re going to organize another VA Smalltalk Forum Europe next year.

VFE 2010: Slides of My Talk: Get (Your Project) Back to Shape

If you’ve missed the VA Smalltalk Forum Europe 2010 in Stuttgart last week, there is at least a chance to take a look at the presentation slides. While we’re still working on an “official” central version location for all the material, I’ve put up some files to our company website, where you can look at them.

My talk was mainly about improving your working style in legacy Smalltalk Projects. Truth be told, there are much more Legacy Smalltalk Projects out there than greenfield projects, even though the Seaside Frameworkl has attracted quite a few Developers into the Smalltalk community.

Legacy here is not a negative term. Many Smalltalk projects are legacy projects, because they’ve been running for more than a decade, fulfilling their business needs and making their users happy. Since there has been a lot of pressure in big corporations towards a “unified platform” (the name may vary in your company), the projects had to survive under really unpleasant circumstances:

  • fluctuation of key developers to newer projects
  • shrinking budgets
  • an aura of being unwanted, old technology
  • neverending wishes for new features

In some organizations, this has lead to a very “pragmatic” (this is not the “pragmatic” of the pragmatic programmers movement!) approach to implementing new features and bug fixes:

  • touch as little code as necessary
  • forget about how it should be done
  • ignore all the new techniques like unit testing, refactoring, build automation etc.

A few years ago, this sounded like a good idea, because people would never have to touch the code again, when the system would be switched off a few months later.

Things went different (as they usually do):

  • The new projects failed completely or in part, so that they were cancelled or reduced in scope
  • The new projects were so expensive that it was decided to couple the old and new systems and keeping the core logic in the Smalltalk system
  • The new projects didn’t really stay within their timeline (surpise!) and so the old one is still the only thing the users have. The result is feature creep in both projects, which may possibly lead to one of the above-mentioned consquences in the future. The difference for the end users is very relevant: they never see the new system anyways, but they get the new features in the old one.

At the end of the day, all of this means the Smalltalk projects in this situation are faced with a few problems:

  • Bad code stuffed into a once good and clean system (Smalltalk Projects were generally well-staffed and budgeted back in the early to mid nineties)
  • Techniques that are common sense today (and, ironically, were invented in the Smalltalk world, like Refactoring and unit testing or automated builds) never got adopted in these projects
  • The once highly-skilled team has lost a lot of talent (Most organizations have shot themselves into their knees by forcing good people out of the projects and scaring everybody away from them by officially calling them a dead-end)
  • Lots of features need to be implemented and the all the ugly crimes of Software Maintenance that have been committed “for the good” need to be cleaned up now. The reason for this is that the systems have returned to an “open end of life” phase, meaning there is no question that these projects will continue to run for another 5 or ten years or “forever”. This, of course, means you need to handle existing code with a lot more respect than people have done for quite a while

My talk is a short summary of findings around all this. I’ve been helping a number of projects to cope with exactly this situation over the last few years by teaching or coaching and by introducing technigques and tools to make the developers’ lives easier. I demoed a few of the little helpers for coping with typical problems like artefacts that are not under version control and tried to motivate people to use the refactoring browser as a tool for reading into existing code (I’d say Smalltalk is one of the best environments for software archeology).

Another area in which projects have serious problems is configuration management with Envy/Developer and the build process. This is not so much a technical problem but more a problem of fear and misunderstanding as well as a question of complete lack of tools and automation in that area. I’ve shown some of the stuff I’ve implemented for customers to overcome these problems. We’ve implemented a complete set of tools and helpers for code management in Streams and automating builds for a Continuous Integration Environment.

Once the video of my talk is available, you’ll probably get an impression of how much I enjoy working with such project teams. There’s a lot you can achieve with little steps and it’s really motivating to see project teams gaining self confidence back that was lost in-between a lot of frustration and sadness about the ignorance of their own management. And, even more important, it’s a lot of fun pairing with a programmer who discovers the power of the Refactoring Browser and Unit Tests.

So if you like my talk and think your project could use some of the tools and techniques to get back to speed again and if you need someone to scratch the rust from your code and make your project shine again, don’t be shy and contact me.

VFE 2010: The first videos are online

Marten Feldtmann was kind enough to not only attend our VA Smalltalk Forum Europe 2010 in Stuttgart last week, he also recorded all the sessions and is now making them available over time (it can be lots of work to get a video ready for release):

I’ve finished the preparation of the first three videos of this event. I think, that Instantiations will publish these videos also.

The first videos are:

* VASmalltalk Business Update – Session 01
* Smalltalk State – Session 02
* WebServices – Example – Session 07

So head over to Marten’s Blog to have a look at the vidoes.

So, a big THANK YOU goes to Marten!

Meanwhile, we are working on getting all presentations slides, remote session recordings, pictures and Marten’s vidoes into one place on the web for you to download them. Stay tuned.

VFE 2010: after the show

This year’s VA Smalltalk Forum Europe 2010 went quite well. We’ve had more than 50 registrations and only a hand full of people who didn’t show up.

We’ve had no major problems, all presentations went well, without any technical problems and as far as I can tell, people thought the talks were interesting. We’re still working on the feedback froms, so I’m still waiting for all the facts 😉

My personal highlights in the talks were

  • Georg Heeg gave an interesting overview of Smalltalk’s history and showed some very interesting Smalltalk projects that have nothing to do with typical Banking or Insourance Applications.
  • Mike Taylor (CEO of Instantiations) said Instantiations is increasing their investments in VA Smalltalk, including an increase of the development team.
  • John O’Keefe gave an update on VAST 8.0.2 and upcoming versions. My highlight here was Instantiations is not only shipping GLROP, but also included documentation for it in the database guide
  • Lukas gave a really nice overview of Seaside. I like his presentation style and slides very much. I was fascinated by the way his talk inspired people to use Seaside in their existing projects. I had seen this before and also saw it when I talked about Seaside at the VFE 2008. The usage examples Lukas showed were partly new to me.
  • My talk went quite well, even the three micro demos I gave worked well. About 45 minutes before my talk, my laptop had seemingly died. I had started up Keynote with my presentations and VMWare with VAST and closed the lid. During Lukas’ talk I opened it to have a short look at some slides and found it to not wake up any more and not react to any keystroke or the power button. You probably need not much fantasy to feel my panic. Fortunately, removing the battery and inserting it again helped.
    I was impressed to see that people were discussing about my talk later and got some nice comments by email. I must have hit some nerve with the topic of working on Smalltalk legacy projects.
  • Marten Feldtman was awarded as the top poster of open source code to VASTGoodies.com. He’s really uploaded a lot of code to the site, most of which is his own work rather than just ports from other Smalltalk dialects.
  • Sebastian Heidbrink gave a more business oriented talk on transforming existing VAST applications into Web Services servers that can be put into the (enterprise) cloud and continue to deliver value for another decade. He also introduced his company (Tricept) which is not new to Smalltalk or VAST, but joined Instantiations and objektfabrik as a Business Partner this year.
  • Diane Engles gave a remote demo of how to integrate a VAST based Web Service with a client that’s implemented in VisualStudio (VisualBasic). It was a walk-through of exposing Smalltalk methods as a web service. So you could say her talk went hand in hand with Sebastian’s.
  • John’s talk on porting code from Squeak/Pharo into VAST and on using VASTGoodies (which he obviously really likes a lot) for open source Smalltalk code for VAST not only showed how to export code from Squeak/Pharo, but also what problem areas you’ll have to look into when porting.
  • Eric Clayberg joined us remotely for a Q&A session. My personal highlights here was a question on a multithreaded VM and once again a question about VAST on Mac OS X. 64 bit was also a topic. Since the Mac OS X question was not asked by any of the usual suspects (Marten or me), but by someone I haven’t met before, it seems there is some real interest in it. 64 bit is on the agenda at Instantiations while a Multithreaded VM is not. I guess that’s far less a problem than it seems, because implementing and synchronizing green threads can be hard enough without the VM running threads as OS threads. We discussed a bit about a framework for enabling object sharing and synchronizing two or more images rather than enabling the VM to use multiple cores, which I guess would be sufficient for most uses and also allow for interesting projects
  • Most people stayed for an after-show snack and were discussing a lot.
    I’ve had some interesting chats with people and also got some feedback on the event, which was very positive. Since we had a lot of talks that day, some people thought the networking aspect didn’t work out as good as in the past. So we may have to remove one slot for next time.

We’re currently collecting all slides and remote sessions and will make them available soon. I’ll keep you updated on that. Since Marten recorded the whole event on video I guess we’ll also be able to publish all talks in video form as well. So stay tuned to learn more.

There have already been more blog posts on the forum and you can also download pictures from the event from adriaan’s online gallery.