Visual languages: functional programming in the era of jab and smoosh

Today I gave a talk on visual programming languages at NL-FP day 2015. It was the first FP-day I visited and it felt a bit like coming home for me, I already look forward to next year when it’s held on January 8th in Utrecht!

Here you find the text of my talk:

I will skip my introduction on why in fifty years our modern day practice of
computer programming by typing may seem as old-fashioned as using keypunch
machines.

More than 50 years ago, at MIT, Ivan Sutherland developed Sketchpad:
the first program with a graphical user interface. He used the experimental
transistor-based TX-2 computer, which had a nine inch CRT screen and a light
pen. Sutherland used this light pen to allow users to draw directly on
the display, something which had not been done before. He created the necessary
software to allow you to draw primitive objects that can later be recalled,
rotated, scaled and moved. These drawings could be saved on magnetic tape, so
you could edit them at a later time. Sketchpad was truly ground breaking
because it allowed you to directly interact with the system, without having to
type, and it also allowed non-experts to use the a computers.

Sketchpad was used for computer aided design, but you could also use it to
create programs by drawing flow charts. You could draw boxes, containing the
statements, transferring the results along one way or another, allowing the
user to program the computer without first having to transcribe everything onto
punch cards or paper tape.

Ivan Sutherlands work was very important for the future of GUI’s, Computer
Aided Design and Visual Languages. In 1988 he received the Turing Award for
everything he did for computer science.

In the years after his thesis on Sketchpad the work on Visual Languages was
continued by many others. His older brother Bert, for example, wrote a
thesis on a new pictorial language. Influenced by the work on Sketchpad he
created a system on the TX-2 in which the user could draw procedures using
symbols that depict operations. It featured a system for debugging and in his
thesis he elaborately described the flow of data inside these procedures,
making his system one of the first graphical dataflow programming frameworks,
an approach using directed graphs which would be used often hereafter.

Bert Sutherland mentions in his thesis that the specification of graphical
procedures has been a neglected field, and most accomplishments have been in
the field of graphical data. More research was conducted the following years,
but the development in visual languages was hampered by the fact that there
wasn’t a widely used pointing device. This changed when the Macintosh brought
about the widespread adoption of the mouse in the mid eighties. This also
caused the first commercial VPL’s like Prograph to appear, which did
not target computer scientists, or educational purposes, but were meant to make
programming easier, by supplying the user with high level building blocks.

But still, visual languages were almost non existent in the landscape of
programming. There was, however, a certain optimism that this would soon
change. In a 1990 paper in the Journal of Visual Languages and Computing
titled “Exploring the general purpose alternative“, the authors Glinert,
Kopachet en Mcintyre said the following: “The goal is nothing less than to
expand the programmer’s workspace to a multi-modal, animated,   3-D
environment. We predict that this objective will in fact be attained before the
turn of the century.

Obviously this hasn’t happened. But what did happen in the years after this
paper? We got some great VPLs like Scratch and Alice. Truly
magnificent tools if you want to teach your child to program without pre-mature
exposure to stuff like object orientation, pointers or monads. If you
want to create your own audio effects pipeline, or a funky 80’s revival style
synthesizer, or a midi step sequencer you can save yourself a whole lot of
frustration and wire up all your needs in Pure Data or Max/MSP, which is (trust
me
) way better than rolling you rown in <fill in your favorite functional
programming language>
, even if you pull in the best available libraries from
hackage or the likes.

There are many, many visual domain specific languages. You want to
process your lab data? You want to control a robot? You
want to build a visual effect chain for your newest Youtube animation?
You want a language that keeps itself simple and stupid enough so even your
livelong <stuck in middle management, not having a clue> boss can use it?

These domain specific needs can be checked without a hitch, but when you look
at the popularity of general purpose VPLs they a far cry from even Visual
Basic? Sure there are some broad-purpose VPL’s. Microsoft has made one,
MIT has one. There’s an open source tool called “Programming without
coding
“, and there are others, but none of these are considered to be a serious
programming environments that could be used by a professional. General purpose
VPLs same to be stuck inside specific domains, research and education.

And there are a couple of good reasons for this. First of all, VPL’s, albeit
being developed early, came late to the real party after the first waves of
personal computers hit the market. It took quite a while for computers to be
outfitted with a mouse. This left little room for the graphical alternatives.
But there were also serious issues with visual languages itself.

Take for example scalability. A hello world program might look nice and dandy
, but when you want to make a complex program you will need to be able
to tidy up your act by putting everything neatly into separate parts. In
imperative and functional languages we have pretty much fixed the problem of
scalability, by putting our code in different modules, or classes, or using
namespaces and packages…etc. In visual languages this is more difficult to
achieve. The tendrils of your system are out in the open, and more in your face
than in a written language. If you don’t mitigate this then the cross-program
dependencies you have rear their ugly heads and turn your program into
spaghetti, which visualised looks pretty gruesome.

Then there is the problem of expressiveness. With program languages there often
seems to be a trade-off between ease of use and expressiveness. The more dummy
proof a language, the more pain and sweat it will take to get some serious work
done. Anybody who has done stuff in the Commodore 64 supplied Basic , or
in Java before it supported anonymous classes and generics should know what I
mean. When you look at the many available VPL’s then you will notice that most
of them have settled for ease of use, which is of course fine of you’re into
creating toy projects or sticking to one domain, but in this specific case of
wanting VPL’s to take over the world and converting all programmers in pinching
swiping gurus of the touch screen, this simply won’t suffice.

The last obvious problem has to do with culture. Programmer culture tends to
move slow. It took Java 20 years to get lambda expressions. Something
which has been a great idea ever since Alonzo Church introduced the
Lambda-calculus in the 1930’s and proven to work extremely well in practice
since the implementation of the first Lisp in the 50’s. So advancements in
programming languages propagate slowly, we tend to stick to old languages for a
long time. Sometimes there’s good reason for this, when we prefer stability
above everything else. I guess that’s the reason why there are still poor sods
out there maintaining decades old Fortran codebases.

But besides the languages there’s also a certain conservatism surrounding the
tools with which we write our code. I for example am an avid user of the
VIM-editor and when I’m working in my tiling window manager with terminals
plastering my screen, I almost never need to reach for the mouse. Geeks like me
will need a very good reason to actually pick up that cabled clicky thingy that
lies next to my keyboard when I can instead keep the fingers on the keys.

But still. I think there’s great merit in visual languages. The cultural issues
I mentioned can be solved with time, the other issues by adopting the right
constructs from computer science research and functional programming.
Scalability can be solved, and has been solved, by choosing correct ways to
create modules. Expressiveness can be added by taking cues from homoiconic
languages like lisp that transform beautifully to the graphical space, and
adding higher order functions, purity, laziness.

We, humanoids, are visual animals. To make sense of how an algorithm
works I visualize it. When I try to make sense of a large code project I use
it’s file and directory structure, modules and packages as a visual frame of
reference. If we visualize a project correctly, abstracting away the details
when we don’t need them, and providing an easy way to dive into the nitty
gritty bits when we want, we can find ourselves in a place where it can be
easier to reason about our code and more importantly explain this reasoning to
others. So the scalability issue could in fact be turned upside down and
changed into a strength if we take the right interface designing path of
modular touchy swipey goodness. Something we might need actual interface
designers for. And like they do we would need to break out of the computer
screen and look at the smelly beast sipping red bull in front of it. We would
need to find out which different mental models programmers use, and how we can
transpose those to visual elements. And we will need to figure out the
cognitive dimensions of those visual elements so we can trace out a path for
improvement.

I can list many reasons for trying to create a new VPL that rocks the world,
but one pet peeve of mine are compile-time errors and especially  syntax
errors. Aren’t these the most stupid, time wasting things ever. So I’m typing
all this code and after my IDE doesn’t show any of those curly red thingies I
can safely press Compile, only to be confronted with a load of messages about
all the obvious ways in which I suck, and my program is incorrect. And this is
a totally solved issue, I mean, compile time problems are mostly low hanging
fruit. In the case of Haskell with its nice type system, also to somewhat
higher branches, but still. Why can’t we eliminate these completely? “We can”,
you might say, because I use, Eclipse, or IntelliJ and that IDE happens to be
very smart. WRONG. They stink. Why is it even possible to write something that
is so blatantly wrong, low hanging compiler or lint-checker, fruit? It feels a
bit like driving in a car in which I will have to control the cooling system
manually and when I start the ignition make sure I don’t flood the engine by
quietly murmuring obscenities.

It seems that while the abstraction level of programming languages have
increased, the errors themselves are still stuck in the elevator.
Error-catching wastes more time than ever. Many programmers of dynamic
scripting languages see no problem in actually going through the mind
numbing process of first executing their program in order to check for errors,
and I’m not talking about highly parallel programs that can’t be easily
debugged in another way. Madness!

Anyway, I think that we can create a new visual programming language, by
combining more than fifty years of research with the lessons learned in
functional programming. I have foolishly made a start:

Here’s what we do: We start with a typical boxes and arrows, directed
graph, flowchart kind of language. We add the ability to zoom and hide details
when using a touch screen, and we support laziness, currying, higher order
functions and a module system. We make functions pure by default and add
necessary, but evil side effects by surrounding them with a visual code smell.
Something like monads, but minus the unnecessary but frequent occurring fears
of category theory.

Taking a cue from Lisp it’s a great idea to have one basic data type and using
that for both code and data. One problem in the written world is that
homoiconic languages tend to look like a too many parenthesis in a love
shack, but work pretty well when visualized as graphs.

We can switch between different list representations at will  , or draw
new ones if we like. We can also create symbolic expressions by pointing lists
to functions with arrows. We can make a bigger function with nested functions
by drawing a box around them. We can drag lists around and create
immutable copies if this helps in our evil schemes. You can choose to direct a
partial list for further processing, which helps create  a nice head or
car function.

We can add labels to our functions, or larger encompassing structures.
But since we’re working visually, we could do even better.

I will show you how we can implement a map function.

We need a function and a list for our map function. And it’s nice if the system automatically adds color to them so we can keep them apart.

We can make immutable copies and change the list representation to get the granularity we need.

We’ll also make a copy for the function that you supply to MAP.

We use recursion to call map on the provided function and the tail of the list

We apply the head of the list to the provided function

We concatenate the results

Now, what happens when we give Map an empty list? We will need to check for this, by adding an if statement.

The if statements returns an empty list when you try to apply map to an empty list, otherwise it will return the result of the concatonation.

What if we want to add a side-effect to our map function?

We are launching the missiles as a side-effect and this makes the entire function impure, so our red background propogates to the entire function.

Here you have it, we have made a higher order recursive function that doesn’t like
like complete rubbish. You can travel along the recursive steps if you like by
zooming into the nested map function, enjoying the droste effect, or strange
loop.

Alright, so what now? I’m still figuring out the best way of adding types to
this visual notation. If I want to protect the programmer from silly errors
while he’s trying to make them, I will need a strong type system, and
preferably one that is light and stays out of your way if you want to by using
type inference.

I will make an informal description of this language and follow it up by
describing everything formally in typed lambda calculus. After this I will make
a first browser based implementation, using a simple graph reduction approach.

I will post updates on the progress on on this blog.


While I show you a possible implementaton of quicksort I would like to ask you
to give visual languages a chance in the future. When you find yourself needing
a DSL, or like me you’re toying around with language design, maybe you can pick
a visual language instead of a traditional one. I know it’s a bit harder,
because you will need to make do without lexer and parser generators , but I’m
confident that slowly but surely we are moving in this direction. At first we
might see smarter IDE’s that add graphics to tackle the complexity of large
projects, but I think the touchscreen revolution isn’t stopping, and one day we
might find ourselves developing software by touching, swiping, jabbing and
smooshing.

FP-Day 2015

Tomorrow I will be giving a talk on visual programming languages at the University of Twente during FP-Day 2015. I will later post my slides and full text here, for your enjoyment.

Here’s the abstract for my talk:

Visual languages: functional programming in the era of jab and smoosh
Abstract: Why are we still typing our code? We have made the jump from keypunch machines to text terminals, but our programming hasn’t fully entered the bird slinging, candy crushing age of touchy swipy goodness. Are programmers the latest luddites or is it impossible to graphically capture the complexity of computing? In this talk we will look at visual programming and especially the way in which a pure functional approach might help create a general-purpose language that is both easy on the eyes and in touch with modern times.

Zaken doen met vrije software

Ik heb in 2013 een stuk geschreven voor Linux Magazine waarin ik beschreef hoe je geld kunt verdienen aan vrije en open source software.
De pdf kun je hier downloaden.

Zaken doen met vrije software

 Alhoewel vrije software meestal gratis verspreid wordt, kun je er prima geld mee verdienen. En in tegenstelling tot bedrijven als Red Hat hoef je ook geen miljoenenomzet te draaien om hier een levensvatbaar businessmodel van te maken.

Eerst wat geschiedenis. In 1969 koppelde IBM de verkochte hardware nadrukkelijk los van de software en gaf zo ruimte aan wat nu een miljardenindustrie is. Voor die tijd werd programmatuur bij de dure mainframes geleverd en programmeurs konden deze vrijelijk aanpassen en uitbreiden. Niet iedereen was in zijn nopjes met deze ontwikkeling. Richard Stallman starte begin jaren tachtig de vrije software beweging en zette zijn gedachtes in 1985 uiteen in het GNU Manifesto. In dit manifest beschreef hij niet alleen de ideologie achter softwarevrijheid, maar ook de mogelijkheden om hier geld mee te verdienen. Hij verwierp de gedachte dat dit programmeurs tot de bedelstaf zou veroordelen en nam nadrukkelijk de ruimte om aan te geven dat hij de ‘free’ in free software bedoelde als in ‘free speech’, niet als in: ‘free beer’.

Stallman bracht gelijk een businessmodel in de praktijk. Hij verkocht de broncode van de teksteditor GNU Emacs. Deze deed hij voor 150 dollar op de post, waarna de ontvanger een tape thuiskreeg. Maar het duurde nog even voordat de commercialisatie van vrije software een vlucht nam. Dit gebeurde in 1989 toen het Amerikaanse Cygnus Solutions opgericht werd. Michael Tiemann, John Gilmore en David Henkel-Wallace boden hiermee commerciële ondersteuning voor vrije software en wisten een succesvol bedrijf op te zetten rond de support en ontwikkeling van de GNU tools voor programmeurs.

In de jaren negentig groeide het aantal bedrijven dat hun diensten aanbood rond open source. Met name het succes van de Linux kernel, gecombineerd met de webserver Apache en het GNU besturingssysteem speelden hier een grote rol in. Het stelde mensen in staat om veel goedkoper een webserver te kunnen neerzetten dan voorheen.

In 1998 werd de term “open source” gemunt om de aandacht wat af te leiden van de meer ideologische aspecten van vrije software en meer te richten op de praktische kant ervan. Dit zette de deuren open naar brede vermarkting van vrije software. Red Hat, een bedrijf met zijn eigen GNU/Linux distributie, ging in 1999 uiterst succesvol naar de beurs, gevolgd door de recordbrekende beursgang van VA Linux Systems dat voorgeïnstalleerde Linux computers verkocht. Ondanks het barsten van de internetbel bleef het aandeel van open source en vrije software in de jaren hierna stijgen. Met deze ontwikkeling zijn er ook een overvloed aan businessmodellen ontstaan.

Voor freelancers of directeurs van softwarebedrijfjes die de open source richting in willen slaan zet ik de voordelen en valkuilen van de verschillende bussinesmodellen uiteen.

Het belangrijkste om je te realiseren is dat je – in verhouding tot de traditionele softwareverkopers – het accent van je arbeid verplaatst. In plaats van het product komt de gebruiker en haar beleving en wensen centraal te staan.

De klassieke manier om geld te verdienen met open source is door support te verkopen. Deze support kun je bieden rond producten die je niet zelf hebt ontwikkeld. Dit is een uitstekende manier om je geld te verdienen. Je kunt eenvoudig een contentbeheersysteem als WordPress, Drupal of Joomla gebruiken. Dit vormt dan de basis voor het inrichten van de websites van je klanten. De support die je dan levert is het tweaken naar de smaak van je opdrachtgever en het passend maken in de huisstijl. Deze aanpak komt erg veel voor en is vaak zo vanzelfsprekend dat gebruikers ervan niet eens doorhebben dat ze feitelijk een 100% open source bedrijfje runnen.

Het is voelt als programmeur ook vrij logisch om uit te gaan van bestaande code, hoef je minder zelf te programmeren en aan het eind van de streep ook minder door te berekenen aan je klanten. Ook zit je klant niet aan jou vast als ontwikkelaar.

Je kunt support verkopen rond een bestaand product, maar je kunt er ook een zelf ontwikkelen. Red Hat doet dit bijvoorbeeld met hun eigen Red Hat Enterprise Linux. De broncode van RHEL kun je vrijelijk downloaden en verspreiden. Deze programmatuur staat echter niet zozeer centraal. Red Hart verdient zijn geld met de handholding, support en updates. Deze kun je krijgen door een abonnement bij hen af te sluiten en een deel van de inkomsten hiervan worden vervolgens weer gestoken in het doorontwikkelen van hun portefeuille aan open source projecten die zich voornamelijk richten op de enterprisemarkt.

Red Hats aanpak is enorm succesvol en haalde als eerste opensourcebedrijf een jaaromzet van een miljard dollar. Dit neemt echter niet weg dat je dit bussinesmodel ook prima kunt gebruiken als klein softwarebedrijfje of freelancer. Het grote voordeel hiervan is dat je zelf de ontwikkeling van het product kunt sturen en gebruik kunt maken van bugfixes en code van mensen buitenaf. Als je het goed doet is het mogelijk om een gemeenschap rond jouw project te creeëren. Deze enthousiaste gebruikers leveren jou dan weer klanten op die aankloppen voor support.

Wat je je wel moet realiseren is dat het vrij veel tijd kan kosten om zo’n open source project te ontwikkelen. Als je slim bent zoek je klanten die dit mee kunnen financieren. De core developers achter het Erlang webframework Zotonic doen dit bijvoorbeeld handig. Zij maken als verschillende kleine bedrijfjes gebruik van het pakket en breiden het uit aan de hand van de wensen van hun klanten. De code die dit oplevert stroomt regelmatig weer terug in Zotonic. Je kunt er echter niet van uit gaan dat je gelijk al klanten bij je project zal hebben en niet alle open source projecten zijn levensvatbaar. Dit kan dus betekenen dat je weekenden en avonden in een project moet steken, zonder direct uitzicht op geld. Je kunt er dan maar het best een echte passie voor hebben, want anders kun je je beter richten op bestaande systemen.

Als je toch wel gehecht bent aan het traditionele beeld van de softwareverkoper dan zijn er ook mogelijkheden om direct geld te verdienen aan je programmatuur. Ik kom regelmatig thema’s en plugins voor WordPress tegen waarvoor betaald moet worden. Dit lijkt in eerste instantie wat merkwaardig, want de licentie van WordPress vereist dat de daaraan gekoppelde software ook open source is. Dit neemt echter niet weg dat je in navolging van Stallman met GNU Emacs geld kunt vragen. Je biedt je extensie dan aan via een webshop, waar de klant kan afrekenen met bijvoorbeeld PayPal en er zelf mee aan de slag kan. Dat laatste is natuurlijk een vrees van menig traditionele softwareverkoper. Ze zijn bang dat anderen met hun pakket aan de haal gaan en er over hun rug geld mee verdienen. In de praktijk blijkt dit niet zo vaak te gebeuren, want het is vrij veel werk om zo’n pakket te voorzien van het nodige onderhoud. De extensies en thema’s zijn vaak ook dusdanig klein dat het voor andere programmeurs al gauw makkelijker is om hun eigen systeem te programmeren. Deze methode van programmatuur verkopen kom je veel tegen bij onder andere WordPress, Magento, OpenCart, en Joomla.

Je kunt ook je software aanbieden onder twee verschillende licenties. Deze techniek wordt dual licensing genoemd en houdt in dat je enerzijds je pakket beschikbaar maakt onder een vrije licentie, maar anderzijds ook een commerciële gesloten licentie hanteert. Je zorgt er dan voor dat de open source zijde gebruik maakt van copyleft. Dit betekent dat als mensen wijzigingen aanbrengen in de broncode en het pakket verder distribueren, deze wijzigingen ook weer vrijelijk beschikbaar moeten komen onder dezelfde voorwaarden. Bedrijven die hier dan niet veel voor voelen kunnen verkiezen de gesloten licentie aan te schaffen en zodoende hun wijzigingen voor zich te houden. Voor MySQL en Qt wordt zo’n soort systeem gehanteerd en financieel gezien is dit interessant. Een nadeel van dual licensing is wel dat je er waarschijnlijk de wrok van menig vrije software zeloot mee op de hals haalt. Zij zien het verkopen van vrije software in een gesloten pakket als een misdaad en zodra je deze route inslaat is het handig om voorbereid zijn op een mailbox vol kritische berichten. Als je daar tegen kunt en niet zo’n ideologisch aanhanger bent van softwarevrijheid, maar het voornamelijk bekijkt vanuit het praktische nut dan is dit wel een levensvatbaar model om je bedrijf op te baseren.

Er kleeft echter ook voor de pragmatischer medemens een belangrijk nadeel aan dual licensing en dat is het feit dat je alle auteursrechten of toestemming van de programmeurs moet hebben om de software te mogen verkopen onder een andere licentie. Dit zorgt ervoor dat je niet kunt profiteren van bugfixes en code uit de gemeenschap zonder hen ook te vragen om jou het auteursrecht toe te kennen. Ook minder die-hard open source liefhebbers beschouwen dit als onkies. Dus moet je er rekening mee houden dat je voor de ontwikkeling van het project op jezelf bent aangewezen. Dit model is dan ook niet voor een freelancer weggelegd.

Een bepaald smaakje van dual licensing dat de afgelopen jaren sterk is gegroeid wordt ook wel “open core” genoemd. Dit betekent dat je niet alleen meerdere licenties hanteert, maar ook nog bepaalde features ontwikkelt die specifiek bedoeld zijn voor de betaalvariant van je pakket. Zarafa, SugarCRM en Puppet Labs gebruiken dit onder andere. Net als bij het verkopen van gesloten software kan dit financieel gunstig uitpakken, maar naast de algemene kritiek op dual licensing worden deze pakketen vaak als crippleware bestempeld. Deze term stamt nog uit de DOS-tijd waarin je goedkoop floppies kon krijgen met shareware programma’s of spelletjes die maar een klein deel van de functionaliteit hadden. Net genoeg om je naar de gehele software te doen zou verlangen. Het is de vraag of zo’n stempel altijd terecht is, maar wie voor deze route kiest moet daar wel mee kunnen leven.

Er zijn nog meer – creatievere – manieren om geld te verdienen met vrije software. Je kunt donaties vragen voor je project, maar je kunt ook geld proberen te verdienen aan de wens tot gemak van je gebruikers. Het downloaden van een pakketje met broncode, dit compilen en vervolgens aan de gang krijgen kost tijd en met name als het een groot pakket is dat weer afhankelijk is van veel andere paketten dan kan dit snel een dagdeel in beslag nemen. Daarom kun je net als Paul Davis van het digitale audiomontagesysteem Ardour de voorgecompilede pakketjes gaan verkopen. Hier vraag je dan een vriendelijk bedrag voor. Davis vraagt kopers zelf een bedrag in te vullen vanaf 1 dollar. Ook is het mogelijk een financieel evenzeer vriendelijk abonnement af te sluiten. In het geval van Ardour werkt dit vrij aardig. Het project zit in een kleine niche, maar Paul Davis kan er toch van leven. En in tegenstelling tot wat je zou verwachten kiest niet iedereen er voor om het minimumbedrag te betalen. Zijn aanpak leverde Ardour veel sympathie op bij bij de gebruikers en hij heeft nu 276 abonnementhouders die goed zijn voor een bedrag van 1777 dollar per maand.

Je kunt ook geld ophalen via een crowdfunding actie. Dit is erg handig als je een startkapitaal nodig hebt en niet naar de bank wilt. MediaGoblin haalde hiermee 42.000 dollar op. De hoofdontwikkelaar van dit mediapubliceerplatform kan er zo zonder financiële zorgen een jaar aan werken. Dit geeft hem de tijd om een bussinesmodel voor de tijd daarna uit te vogelen. Hij zou hierna de route van WordPress kunnen kiezen en net als WordPress.com een gehoste variant van het pakket kunnen aanbieden.

Zoals je ziet zijn er veel verschillende manier om zaken te doen met vrije software. Of je nu als freelancer support wil leveren voor externe systemen, met een gewaagd project geld van de eindgebruiker vraagt, of je eigen bedrijf wilt oprichten met een eigen product, de gebruiker staat binnen vrije software altijd centraal en zal uiteindelijk jouw succes bepalen. De meest geslaagde open source projecten vormen een eenheid met die gebruikers. Zij leveren bugfixes, vertalingen, suggesties voor verbeteringen en wellicht zelfs hele stukken code. Misschien willen ze het ook zakelijk gebruiken en kun je zo je krachten bundelen. In plaats van een eenzijdig verkoopkanaal ontstaat er een levendige gemeenschap van mensen die een project niet alleen downloaden en installeren, maar ook verbeteren en er zelf deel van uitmaken.

 

Carmack over functioneel programmeren

Ik ben dol op de jaarlijkse QuakeCon keynote van John Carmack. Ik volg met name zijn stappen op het gebied van functioneel programmeren met grote interesse.

Als je Carmack op Twitter volgt dan weet je dat hij afgelopen jaar veel met FP geëxperimenteerd heeft. Hij heeft Wolfenstein 3d deels nagebouwd in Haskell en ook veel geprogrammeerd in Scheme via de iOS app “Lisping”. Maar het blijft niet bij experimenten, want hij komt nu voor het eerst met concrete ideeën hoe hij functioneel programmeren in zijn dagelijkse werk bij ID Software kan toepassing in C++. Een switch naar bijvoorbeeld Haskell zullen ze daar niet snel maken, maar dit laat onverlet dat je dezelfde principes ook in een object georiënteerde of procedurele taal kunt gebruiken.

Bijzonder fascinerend, een echte aanrader om te kijken, natuurlijk ook vanwege zijn geweldige toekomstvisie op het gebied van 3D en virtual reality headsets.

Haskell buiten de universiteitsmuren

Dit is een inspirerend praatje van Bryan O’Sullivan, mede-auteur van Real World Haskell. Hij vertelt hoe hij Haskell gebruikt in zijn eigen startup.

Wie deze functionele programmeertaal de laatste jaren gevolgd heeft, zal het zijn opgevallen dat het langzaam de academische niche aan het uitklimmen is. Het succes van zowel O’Sullivans boek als Learn You A Haskell For Great Good en de relatieve hipheid van Rails/Django-achtig webframework Yesod onderstrepen dit.

Ik ben zelf een enorme fan van functioneel programmeren. Het is, sinds dat ik Miranda/Amanda kreeg op de universiteit mijn favoriete paradigma. Maar deze overtuiging heeft vreemd genoeg mijn dagelijkse werkzaamheden nooit kunnen infiltreren, waar het tot op vandaag OOP is dat de klok slaat.

O’Sullivan legt uit hoe hij Haskell gebruikt en geeft handige tips of het voor jou ook een goede optie is. Tevens beantwoordt hij de zorgen dat de Haskellprogrammeurs niet bepaald aan de boom groeien. Naar mijn tevredenheid moet ik zeggen. Ik ga serieus overwegen om Haskell in mijn werk te gaan gebruiken en anderen hierin ook aan te moedigen.

Nog een klein dingetje dat ik graag uit het filmpje wil lichten is “property based testing”. Als je programmeert dan maak je waarschijnlijk gebruik van unit-tests om te checken of je code zich naar behoren gedraagt. De toepasbaarheid van de unit-test is echter beperkt tot de fantasie van de programmeur, en eerlijk gezegd ook uithoudingsvermogen, want bijzonder inspirerend werk is het geenszins. Met property based testing wordt je code automatisch getest aan de hand van een assertion die je zelf invoert. Je code krijgen zo een heel batterij aan vreemde, ongebruikelijke input te verduren. Dit alles om je programma via deze edge-cases op de knieën te krijgen. Extreem nuttig en niet alleen beschikbaar in Haskell.

Waarom mobiele web apps traag zijn

Mobiele web apps zijn traag, dat is een feit. Nu ik zelf steeds minder native apps bouw en diezelfde apps vaker in HTML5 en Javascript ontwikkel word ik hier bijna dagelijks mee geconfronteerd.
Dit neemt niet weg dat mobiele web apps extreem handig zijn en voor eenvoudige toepassingen de beste “bang for the buck” leveren aan mijn klanten.

Zoals deze uiterst grondige analyse van Drew Crawford goed uitlegt, ligt de waargenomen snelheid van deze apps aan je invalshoek. Vergeleken met c/c++ en zelfs met Java/Python/Ruby zijn ze ranzig traag, maar als je verwachtingspatroon is afgestemd op websites dan valt het allemaal mee.

Het stuk is echt een aanrader, maar je moet er wel wat tijd voor inruimen, want het is bijzonder uitgebreid. Het deel over garbage collection en het complete gebrek aan controleerbare memory management in Javascript slaat de spijker feilloos op z’n kop.

Al met al is het niet de meest vrolijke boodschap voor de minnaars van de mobiele webtechnieken. Voor deze groep is er gelukkig ook een optimischer kijk voorhanden:
http://danbricklin.com/log/2013_06_19.htm#jsspeed

Dart en de Javascriptsoep

De afgelopen dagen heb ik even goed gekeken naar Dart. Deze taal moet als het aan Google ligt in de komende jaren Javascript gaan vervangen als dominante clienttaal voor het web.

Webdevelopers zijn veelpotige wezens. Voor een gemiddeld project maak ik al gauw gebruik van een halfdozijn talen. Html en CSS voor de clientweergave. Javascript (en tegenwoordig vaak Coffeescript) voor rijke webapplicaties. Aan de serverzijde gebruik ik veel PHP (soms Java) met regelmatig een extra taal voor templating, zoals Smarty, of (in het geval van Typo3) Typoscript. Voor de database gebruik ik daar boven op uiteraard SQL en soms PL/pgSQL voor stored procedured.

Zonder talenknobbel kom je niet ver als webprogrammeur en om eerlijk te zijn kijk ik wel eens met milde jaloezie naar collegaprogrammeurs die hun dagen in een wereldje van puur Java of C++ doorbrengen. Maar ik ben ook wel dol op de razendsnelle iteratie van technologie van het web. Bovendien maak ik tegenwoordig steeds meer mobiele apps ook met webtechnieken (dankzij Cordova/Phonegap en goede ondersteuning voor CSS3/HTML5 in webkit). Wat ik erg graag wil is een taal die client en serverside met elkaar verbindt, waardoor het mogelijk is om iets meer analoog aan de prototypische J2EE-developer binnen één taal en programmeeromgeving te leven.

Dankzij recente ontwikkelingen is het vrij onvermijdelijk dat ik over een paar jaar aan server- en clientside dezelfde taal gebruik. Node.js is extreem hip (Javascript op server), in de Haskell hoek gebeuren er allerhande interessante dingen (Yesod/Fay/Happstack) en ook talen als Opa krijgen volop aandacht.

Het probleem met de enorme wirwar aan nieuwe webtalen is dat het moeilijk in te schatten is wat uiteindelijk succesvol gaat worden. Hoe waanzinnig mooi de ontwikkeling van nieuwe talen ook altijd zijn, uiteindelijk draait het om adoptie daarvan.
Haskell is bijvoorbeeld erg academisch en in tegenstelling tot wat veel Haskellfans je zullen zeggen, tamelijk moeilijk te leren. Er is een enorme lijst van talen die gefundeerd zijn op Javascript, maar denk je serieus dat iedereen over een paar jaar Opa, of Objective-J gebruikt? De adoptie van zulke talen is moeilijk en gefragmenteerd. Coffeescript is succesvol, omdat je het razendsnel oppikt en feitelijk niet meer is dan een mooi gepolijst syntaxlaagje. Alsof je hebt besloten slagroom op je appeltaart te nemen, het blijft uiteindelijk appeltaart.
Begrijp me niet verkeerd, ik vind Coffeescript prettig, maar het neemt niet het javascript probleem weg, namelijk dat de taal een rommeltje is. Tot 10.000 regels code zit ik daar niet zo mee, maar op het moment dat het echt heel groot wordt en moet schalen, dan wordt het lastig te managen. Natuurlijk zijn hier allerhande oplossingen voor zoals AngularJS, maar liever switch ik dan naar een andere taal.

Dart is een goede kandidaat. Op het eerste gezicht lijkt het erg op Java, niet erg sexy. Het is sterk gericht op object georiënteerd programmeren, maar heeft in tegenstelling tot Java wel de mogelijkheid om top-level functies toe te voegen. Harige zaken zoals multiple inheritance zijn vermeden en het heeft optionele static typing (nu al “feeble typing” gedoopt). Google is duidelijk erg pragmatisch te werk gegaan en heeft zoveel mogelijk geprobeerd een allemansvriend te maken. Je kunt dus wel raden wat voor een pissige reviews er zijn geweest, want er zijn weinig dingen die zoveel programmeurpedanterie kunnen veroorzaken als een nieuwe taal.

Ik ben zelf niet van het “code is poëzie kamp”. Zelfs de prachtigste stukken Scheme of Erlang zijn nog geen Leo Vroman en hoe elegant je ook functiecompositie kunt toepassen in Scala, het redt het niet bij de verzen van Vasalis.

Ik drijf af. Wat ik bedoel is dat je een programmeertaal een functioneel nut heeft, als een strijkijzer, en uiteindelijk niet te veel in de weg moet zitten. Het is handig als het snel op te pikken is en lijkt op reeds bekende programmeertalen. Het is mooi als de taal probeert te voorkomen dat de programmeur zichzelf of een ander makkelijk in de voet schiet en niet als een vervelende drill sergeant je dwingt regel na regel aan vervelende boilerplate code uit te poepen.
Dart voldoet hier aan. Je kunt er met grote teams mee werken, het moedigt een pragmatische en heldere stijl aan en het heeft een paar features die het leven van een webdev een stuk aangenamer maken.

Die belangrijkste features die mij zo in het oog springen zijn isolates en futures. Isolates zijn een Erlang-achtige elementen om concurrency te regelen aan de hand van afgezonderde beestjes die communiceren aan de hand van boodschappen. Isolates zijn zoals de naam al zegt geïsoleerd en delen dus geen thread. Als je Dart naar Javascript compiled dan worden ze geïmplementeerd aan de hand van web workers.
Futures zijn een handige manier om de enorme callbackkluwen een beetje te handelen.

Al met al ziet Dart er gewoon vrij goed uit. Het is een beetje de “Gilmore Girls” van de nieuwe webtalen, maar dat is expres en zou wel eens goed kunnen zijn voor de populairiteit. Ik zou er weinig bezwaar tegen hebben als ik over een paar jaar voornamelijk programmeer in deze taal, maar mijn milde mening is niet bepaald het ontvangst dat Google heeft gekregen.

Veel programmeurs zijn bang voor een ActiveX-achtig scenario. Dart zal vanwege de VM die Google in Chrome zal stoppen daar een eersteklas burger zijn en voorlopig op de andere browsers omgezet worden naar Javascript. Het lijkt me onrealistisch om te verwachten dat andere browserbakkers, hoe prettig de open source licentie van de VM dan ook is, dit zullen overnemen. Bovendien was de manier waarop Google destijds Dart (toen nog Dash genoemd) aankondigde niet de meest subtiele. Het zou een nieuwe standaard moeten worden en Javascript gaan vervangen.

Ik zie zelf weinig problemen in Javascript an sich. Het is geen mooie taal, maar het heeft nu de status bereikt van de bytecode van het web. Ik denk dat de push voor Dart als nieuwe taal een stuk eenvoudiger zou zijn als Google dat volledig had gerespecteerd. Maar goed, als ze maar voldoende programmeurs achter zich krijgen dan kunnen ze Dart natuurlijk tot nieuwe standaard máken. Dit is echter wel een staaltje powerplay dat de reus uit Redmond ondertussen niet meer aandurft. We zullen zien of deze hoogmoed Dart ten val brengt, of juist als nieuwe top dog boven op de webstack parkeert.

Moddergooien met Bush

Bush was een scriptingtaal gebaseerd op Ada 95, maar Bush is niet meer. Deze BUsiness SHell heeft de sprankelijke naam SparForte gekregen (let op de CamelCase).

Erg jammer, want een opstootje met een politiek bijsmaakje is altijd amusant in het vaak zo correcte codewereldje. Meestal blijft de politiek echter beperkt tot digitaal vuistvechten over licenties (gaap).

Maar laten we wel wezen, in verhouding tot het moddergooien zoals dat in de Amerikaanse presidentsverkiezingen gebruikelijk is, lijken veel conflicten tussen programmeerbaarden (m/v) erg veel op peuterspeelzaalonvrede over speelgoed.

Bush, zoals de taal op de site meestal nog genoemd wordt, maakt dit echter meer dan goed in hun vergelijking met andere talen. Dit stukje is overduidelijk getypt zonder handschoenen aan, want de minachting voor elke taal anders dan de eigen en lingua mater Ada wordt niet verhuld.

Python wordt weggezet als lullig scriptingtaaltje. Perl wordt hard aangepakt vanwege zijn acroniem (die overigens niet bestaat, maar laten we de pret niet bederven). Ruby maakt gebruik van “the principle of least surprise” en dat is uiteraard fout. Bush is namelijk het programmeerequivalent van de extreem spontane party favorite. Java heeft een “awkward syntax” en last but not least is QBasic heus niet beter, want kijk: Bush heeft ook een crappy textgebaseerde programmeeromgeving met een blauwe achtergrond.

Heerlijk. Ik mag dat moddergooien wel, hoe onzinnig het ook is. De makers van Bush/SparForte kunnen echter nog wel wat leren. Allereerst zou ik een voorbeeld nemen aan de trots waarmee de “brutally optimizing Scheme compiler” Stalin haar politiek niet bepaald kleurloze naam draagt en voor de verbale vuigheden goed luisteren naar David Heinemeier Hansson.

Leer Lua in 15 minuten

Via deze tutorial krijg je in 15 minuten een vogelvlucht beeld van Lua.

Lua is een schattige dynamische scriptingtaal die perfect is om te embedden in een groter project. Geliefd onder game-makers, tref je dit beestje aan in menig computerspel. Denk hierbij aan niet mis te verstane namen als World of Warcraft, Civilization V en Painkiller.

Lua is makkelijk te porten (20k regels ansi C), werkt lekker vlot en is ook snel op te pikken. Boeken en tutorials die beloven dat je X in Y minuten kunt leren doorstaan meestal niet een keiharde stopwatchtest, maar deze tutorial geef ik een goeie kans. Het is feitelijk één groot Lua-bestand dat je zo door de interpreter kunt halen. De schrijver laat je alle highlights van de taal zien.

Mijn persoonlijke favorieten: Modula-achtige syntax, functies als eerste klas burgers en de tabel als standaard datastructuur. Ongeacht de syntax doet Lua denken aan Scheme en dat blijkt niet toevallig.

Er is ook een soortgelijke tutorial voor Clojure.