Better than Thou

Återigen en engelsk titel, det bor uppenbarligen en liten Dolph i mig.

Ni har kanske råkat ut för den det här inlägget handlar om: idealisten, evangelisten. Då talar jag inte om alla de corporate evangelists det vimlar av från Sun och Microsoft främst, utan den verklige idealisten som har sett ljuset och sen inte kan låta bli att försöka sprida det till alla som vill (och efter ett tag inte vill) lyssna.

I mitt fall rörde det sig om Smalltalk. Alltså, det var Smalltalk som företeelse som var 'ljuset'. Och i min närhet fanns idealisten som höll Smalltalks fana högst i alla lägen.

Inget ont om Smalltalk och dess olika dialekter - mer OO-purism än så är svårt att tänka sig - allt är objekt - även klasser och integers (1+2 innebär att man skickar meddelandet '+' till objektet 1 med parameter objektet '2'). Para det med grymma utvecklingsmiljöer och en varm och cosy feeling som bara Smalltalk kan ge och man har en vinnande kombination. Eller?

Problemet kommer när man skall jobba kommersiellt tillsammans med idealisten. Kommersiellt innebär att man skall jobba för pengar som nån känner sig villig att hosta upp.

Det innebär ofta också att man ska jobba i ett team tillsammans med folk som har kompetens på den valda plattformen (och den valda plattformen är en kommersiellt gångbar plattform = inte Smalltalk).

Smalltalk hade kunnat vara vad Java och C# är idag - preferred choice of språk och utvecklingsmiljö för bulken av alla nystartade utvecklingsprojekt.

Det är som sagt squeaky (förlåt vitsen) clean vad gäller objektorientering. Det saknar också den ofta (enligt min mening) onödiga statiska typningen i Java/C++/C#.

Helt enkelt en produktiv miljö second to none.

Men, marknadens vägar äro outgrundliga, eller snarare beroende av smarta marknadsförare med stora pengasäckar i bakfickan (läs Sun, Microsoft).

Hade det funnits en dylik pengasäck bakom marknadsföring av Smalltalk på den tiden då Javas showcase var vinkande tomte-appleten, så hade Sun kunnat lägga ner den satsningen.

Då var Smalltalk sedan länge redan moget och hade bevisat vad det gick för (det var under en period ganska stort i USA som plattform för t ex banksystem och administrativa system).

Resultatet av den frånvarande marknadsföringspengapåsen är att det inte finns nån marknad (i alla fall inte i Sverige) för Smalltalk.

Då återkommer vi till problemet med idealisten. Att sitta i projekt med honom (i en kommersiellt gångbar miljö) blir en evig whine-fest.
"Aaargh. I Smalltalk hade det varit mycket enklare".
"Varför tycker alla Java/C#/C++-människor att det är så j-a bra. Det suger ju jämfört med Smalltalk".

Kort sagt ingen rolig person att dela skyttegrav med.

Och omöjlig (eftersom han är en idealist) att få att inse att det handlar om stålar. Den bästa teknologin vinner inte - det är den med mest buzz som vinner och på den fronten står sig Smalltalk slätt.

Jag älskar idealister - må de sprida sina tankar och visioner till massorna i evig tid - bara jag slipper sitta i samma projekt som dem...

Följa John

Jag har varit så pass länge i systemutvecklingsbranschen att jag insett ett par saker.

• There is no silver bullet
• Om något pushas som det bästa sen sliced bread så är det nåt grundläggande fel nånstans
• Det är (faktiskt) inte alltid fel att uppfinna hjulet igen (eller kanske inte hjulet, men kanske chassit, karossen och inredningen för att fortsätta på den något krystade bil-liknelsen)
  

Låt mig ta några exempel. Jag tillhör, måste jag erkänna, dem som svalde krok, lina och fiskespö när J2EE-tåget lanserades med buller och bång på senare delen av 90-talet.
Här kom en spec, en standard som skulle lösa alla mina problem - persistens, distribuerade lösningar, messaging och en hel massa annat. Sun, i sin oändliga vishet, publicerade en "show case"-app i form av "pet store" full av
J2EE-patterns att använda för intet ont anande utvecklare världen över.
Inte nog med det - "Enterprise" i namnet gjorde att management i tusentals företag också svalde betet. Att använda J2EE blev ett slags kvalitetsstämpel; en garant för att lösningen var byggd på solid grund, lätt att underhålla och skala upp.

Hej vad vi alla bedrog oss. Om man bara hade använt sin (iofs på den tiden betydligt kortare) erfarenhet och utbildning och verkligen läst specen istället för att kasta sig över ett kodexempel och med ett fånigt flin på läpparna sjösätta sin första Entity Bean i nån mer än lovligt buggig och seg 'container'.

Vad som framgår som pinsamt tydligt nu i ett förklarat ljus är att J2EE-specen var ett typiskt 'Design by Commitee' piece of crap. En kopp komplexitet tillsammans med fyra liter configuration i form av XML och sex matskedar magi - vad containern har för sig under huven visste man inte riktigt (och det var ju inte meningen att man skulle behöva veta det heller). Lycka till förresten med att sätta en debug-stopp långt inne i JBoss mitt i nån ConfigurationFactoryManagerFactory eller nåt som är i full färd med att instansiera sig själv utifrån nån vidrig XML-blobba.

Applikationerna blev precis det motsatta mot vad som utlovades:

• Skalbarhet - my ass. Nåt segare än en J2EE-applikation med Entity Beans går inte att uppbringa. Det är datavärldens motsvarighet till en bil med prestanda från en Trabant och komplexitet hos en Ferrari F1
• Maintainability - tanken var att eftersom allt var byggt efter en enhetlig spec skulle man kunna byta utvecklare i ett projekt lika ofta som man byter kalsonger. Vem som helst skulle kunna kliva in och vara produktiv på en gång. Detta föll genast eftersom alla var tvungna att kringgå den vidriga specen med hembyggda lösningar (som ofta blev mer eller mindre de facto patterns för J2EE-utveckling) som t ex "fast lane" (dvs gå direkt med JDBC mot databasen för att göra saker som inte gick att göra med J2EE (som att läsa upp fler än 10 objekt t ex (hmm, ett persistensramverk som inte fixar att läsa upp ett tjog objekt eller så från databasen borde ju fått folk att tänka efter)))
• En tredjeparts-marknad med färdiga komponenter färdiga att bara drag-and-droppa in i din container och vips så funkar allt! Att bygga ett system skulle bara kräva en systemdesigner (gärna i kostym) som i samråd med beställaren grafiskt drar-och-släpper komponenter i en grafisk högnivå-utvecklingsmiljö. En luttrad utvecklare inser kanske att det är omöjligt att t ex komma fram till en generell definition av ett så basalt begrepp som 'användare'. Vissa system behöver user name och mail address, medan andra behöver längd i cm och hårfärg. Marknaden för tredjepartskomponenter blir snabbt begränsad till komponenter för typisk generell funktionalitet - mail-skickning, och messaging t ex

De enda som drar nytta av eländet är företag som säljer J2EE-containers och de som konsultar i ämnet. Mest de som gör bådadera, t ex säljer en vidrigt komplex container (läs WebLogic) och sen säljer vidrigt dyra konsulttimmar för att röja upp i de katastrofprojekt som (naturligt nog) inte kan leverera utifrån en galen spec (läs J2EE) implementerad i en överkomplex container (läs WebLogic). Där har ni en bra affärsidé. Synd att det inte var jag som kom på det.

J2EE är en typisk 80-20 deal. Det går bra att utveckla 80 procent av din applikation (om du kan stå ut med att den är seeeeg), medans resterande 20 procent är omöjlig att utveckla eller måste byggas i strid med vett och sunt förnuft för att kringgå alla hinder som J2EE lägger i vägen.