Friday, September 23, 2016

MaterialDesignLite for Seaside

The project MaterialDesignLite to provide MDL for Seaside reached first milestone 1.0.0. A demo can be seen here.

Railway modeling in Smalltalk

Railway modeling in MetaEdit - a tool written in Smalltalk. Reminds me of RUT-K from german railway, a large Smalltalk project for train schedule planning that I helped shaping

Monday, September 19, 2016

Smalltalk is dead, long live Smalltalk

Robert C. Martin (from Object Mentor, Inc, also known as "Uncle Bob") once did a presentation in 2009 on RailsConf with the provocative topic "What Killed Smalltalk Could Kill Ruby, Too".

The way this talk was presented was nice and funny - but by declaring Smalltalk dead he showed me that he never really followed this technology and all its offsprings close enough.

If Smalltalk would be dead how would I have been able to fill my blog with news about it over so many years? If it would be dead why do new things like Agile VisualizationsSoftware Analysis platforms or cloud platforms like www.pharocloud.com pop up? Why is it used to lively program robots or help solving scientific computations when it is dead? How could it help fighting Ebola or disaster and climate change when Uncle Bob says it is dead? How could a dead technology coordinate so many containers shipping around in this world, or how could it be used in one of the largest financial projects? How could it be given to so many people around the world as a visual programming tool? Looks like nobody cared that Mr. Martin declared it as dead already in 2009 ...

For sure Smalltalk is not as widespread as Java, C++ or C# and it will never be on top of the TIOBE index (since this is the most stupid metric to rank programming languages ever invented). But it is in use, a productive and efficient environment to solve daily problems that would be hard to solve in other technologies.

And all this in times where people (without having a deeper understanding) quickly decide for new technologies as the better ones "automagically" - because they think "newer means better". But often we see that new technologies just reinvent the wheel or provide an improvement only in a single aspect.

Smalltalk is around now since 1972, lifted and commercialized in 1980, stable and mature, used in big and small projects and processes. Because of this age it is not the first time it was declared legacy or dead. But due its virtual machine and its dynamic nature it was and still is adopted to new platforms, new requirements or new hardware. Some Smalltalks can even run 1:1 in the webbrowser or on the Pi.

So in the tradition of "The king is dead, long live the king!" Smalltalk is still alive and kicking. Primarily in the open source scene with PharoSqueak, Cuis, Amber there are many new success stories or books.

Now in 2016 even "Uncle Bob" - based on the old Type wars discussions (static vs. dynamic typing) - needs to admit in a blog post that:

"The Smalltalkers will, eventually, win. So says this old C++ programmer."

But there is no competition, so there is no need to have a winner.

Smalltalk is alive and still about new ideas - about new ways of computing and modeling our world to form something better.

Wednesday, September 07, 2016

Next Pharo Sprint dates

There is already a planning going on for the next sprint meetings at INRIA in Lille (France).

Next dates are

  • 30 September 2016 
  • 04 November 2016 
  • 25 November 2016 
  • 16 December 2016

Pharo on Pi

Made some progress on my pet project on the Raspberry Pi. Now using the new Pi model which is running much faster. Nice!

 Hope to find some time to update my medium article with the latest specs soon.

ESUG 2016 material

Slides from this years ESUG meeting in Prague are now online.

Thursday, September 01, 2016

RProjectConnector 2.1

Binding between Pharo and R was updated to use UFFI.

Toolchains ... any progress

While playing with PhoneGap, Android, Node and friends I noticed that in 2016 in the IT industry we still fight with path settings, environment variables, correct dependencies and command lines when setting up our toolchains. Always time consuming...

I hate it when to much time is required to setup things correctly to be able to code. Time is better invested in coding itself.

We know there are quicker ways where one can just install/extract and go.