April 5th, 2008 Alex
Timp de 5 luni am fost departe de casă, apartamentul meu fiind trecut printr-un dureros proces de renovare.
Asta a presupus o separare drastică a timpului liber de comoditățile cu care eram obișnuit, printre care și accesul la Internet, iar la servici întotdeauna se găsesc lucruri mai bune de făcut. Suntem totuși fericiți, eu și soția mea iubită, că totul s-a terminat și că suntem în sfârșit acasă.
Desigur, o parte din motivul pentru care nu sunt prea activ pe blog ține de abilitatea mea de a-mi exprima sentimentele în cuvinte. De multe ori simt o anumită idee, sau o anumită concluzie ca urmare al unui șir de evenimente ce au dus la observarea unui șablon, dar în lipsa unui limbaj adecvat sunt incapabil de multe ori să pun lucrurile în perspectivă și prefer să tac din gură. Fără un limbaj bogat procesele cognitive nu funcționează la capacitate maximă. Fără un limbaj adecvat nu ai ordine în idei și o astfel de idee pe care nu o poți exprima în mod eficient nu o poți folosi în construcții mai complexe (nu scalează).
Și ca o paranteză, vă rog să-mi scuzați articolul kilometric, dar n-am reușit să-mi exprim aceste gânduri într-un mod mai succint 
Este interesantă astfel paralela care poate fi trasată între programare și comunicarea dintre oameni. Programarea propriu-zisă este procesul prin care comunici unui calculator ideile. Iar cea mai mare problemă din informatică ține de managementul complexității, și dacă exită o determinată, printre colecțiile uriașe de cunoștințe empirice pe care le avem, este eterna complexitate a proiectelor ce crește de multe ori exponențial.
Programarea este cunoaștere.
Ideile sunt într-adevăr exprimate în limbaje străine oamenilor obișnuiți, dar acele limbaje sunt necesare deoarece limbajul natural are o gramatică non-deterministă și este nevoie de inteligență umană pentru a-l înțelege. De fapt, dacă ar fi să definim inteligența umană, am putea-o defini drept capabilitatea de a înțelege și de a comunica folosind limbajul natural (iar mulți oameni de știință sunt de părere că am evoluat din maimuțe odată cu dezvoltarea acestui mijloc eficient de a comunica). Desigur, și un cățeluș este un suflet, și un cățeluș comunică, dar limbajul său este rigid, se naște cu el și nu poate defini noi cuvinte decât foarte greu (există și excepții … Bella, fetița mea rottweiler, își scurură urechile când vrea afară, și-mi citește starea de spirit de cum mă vede, dar desigur, Bella este fata mea).
Practic poți păcăli teoria evoluției deoarece nu este nevoie de mii de generații ca organismul să se adapteze mediilor noi în care trăiești. Poți pur și simplu învăța de la alți oameni experiențe, greșeli, tehnici, și chiar și sentimente. Dacă te-ai ars cu focul, copiii tăi o vor învăța de la tine (deși câteodată este inevitabil pentru copii să repete aceleași greșeli, dar nu mai se pot scuza că n-au știut).
Încet, încet am ajuns la concluzia că cea mai importantă calitate a unui inginer (excluzând ambiția, calitate cu care probabil te naști) NU este folosirea eficientă a uneltelor, și nici învățarea perpetuă de lucruri noi, deși sunt calități destul de importante. Cea mai importană este capabilitatea de exprimare cât mai eficientă a ideilor.
Și ca să pun aceste vorbe în contextul profesiei mele … cu toți simțim asta mai ales când suntem cocoșați de complexitatea unui proiect ce a avut parte de alegeri neinspirate, sau poate o auzim de la alții, dar cred că este nevoie de o oarecare maturitate să o recunoști …
Modularizarea este banală și de multe ori ineficientă, mult mai scalabilă este abstractizarea meta-lingvistică (vezi [1])
Când am început să simt acest adevăr, prima reacție a fost să caut un limbaj de programare mai eficient, mai “enterprise”, mai popular. Eram în liceu și programam mici joculețe în Pascal. Eram total nemulțumit [2] în primul rând datorită restricțiilor impuse de compilator, și prima reacție a fost să învăț C++, deși n-am văzut nici o lumină când transformarea s-a încheiat. O a doua revoltă a fost odată cu trecerea de la PHP la Java, deoarece PHP îmi dădea impresia de jucărie, sau de la Java la Python, într-o încercare de reconciliere cu limbajele dinamice, încercând să-mi regăsesc latura pragmatică.
Există din păcate programatori ce nu reușesc să vadă valoarea limbajelor de programare. Și acești programatori formează o majoritate semnificativă.
Iar din anumite perspective au dreptate să o facă …
- un editor de texte deștept poate alina durerea cauzată de folosirea unui limbaj rigid pentru un domeniu pentru care nu a fost proiectat, cazurile cele mai populare fiind C++, Java și C#, iar mulți speră ca într-o zi un IDE le va alina probleme probabil prin citirea gândurilor
(pentru o părere în acest sens vezi [3]).
- Tehnologiile informatice evoluează extrem de rapid, și ce este nou astăzi poate fi depășit peste un an
- Un limbaj nou vine cu paradigme noi (de cele mai multe ori, exceptând clonele cu mici variații), și este mai greu de învățat decât un framework nou
- Paradigmelor noi nu le observi oricum utilitatea decât după o perioadă de folosire în probleme reale
As long as our hypothetical Blub programmer is looking down the power continuum, he knows he’s looking down. Languages less powerful than Blub are obviously less powerful, because they’re missing some feature he’s used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up.
(Beating the Averages, Paul Graham [4])
Practic, un limbaj prea diferit de limbajele cu care ești obișnuit are potențialul de a te face să te simți incompetent (vezi plângerile celor ce au încercat Haskell). Și nimeni nu suportă asta.
Și din păcate toată lumea a devenit obsedată de rezultate și câștiguri rapide, de comoditizare, de ieftin și debarasabil, în timp ce adolescenții sunt orbiți de poveștile oamenilor ce au câștigat la Loto, sau de poveștile adolescentelor ce se mai cuplează cu câte un Irinel și cu prețul demnității au parte de succes fără efort (sau cel puțin așa se vede din exterior).
Și vorbind de aparențe, îmi aduc aminte de filmulețele demonstrative ale framework-ului ASP.NET [5]. Și sincer, câtă strălucire, câtă ușurință … trei click-uri, și țaca-paca ai un website complet. Și cât de naiv am fost să cred asta. Pentru că odată ce te apuci de mult subestimatele “probleme reale”, observi cât de non-standard și de problematic este mecanismul de postback, sau cât de rigide sunt componentele standard, sau cât de complex este pipeline-ul prin care se răspunde la un request (lovindu-te de problema abstracțiilor prea ambițioase [6]), sau cât de departe este ASP.NET de paradigmele și șabloanele de proiectare standard folosite în aplicațiile web uzuale, sau cât de rar este folosit ASP.NET pentru proiecte populare, deși tehnologia are deja 7 ani vechime (singura excepție semnificativă fiind MySpace). OK, știu că a mai evoluat, și că ultima versiune în sfârșit vine cu MVC (wow), poate sunt un pic rău, dar tot nu m-aș mai atinge de ASP.NET odată ce m-am fript.
În spusele lui Erik Naggum (vorbind de Haskell vs Lisp) …
If you have a language that is good at demonstrating such things, maybe it has been optimized for demonstrations? At least one really huge software company has made the bulk of its earnings on its ability to demonstrate to other people … what they could do.
From the Latin word “imponere”, base of the obsolete English “impone” and translated as “impress” in modern English, Nordic hackers have coined the terms “imponator” (a device that does nothing but impress bystanders, referred to as the “imponator effect”) and “imponade” (that “goo” that fills you as you get impressed with something — from “marmelade”, often referred as “full of imponade”, always ironic).
Erik Naggum, comp.lang.lisp
Un alt exemplu de regresie în industria IT este obsesia programarilor de a mapa modelul de reprezentare a datelor relaționale în obiecte. SGBD-urile relaționale au multe defecte, iar sistemul relațional de reprezentare a datelor (tabelar), deși cu multe defecte, ne este mai intuitiv decât programarea orientată pe obiecte (cred că și un copil de 5 ani poate pricepe un tabel). Este însă o oarecare prăpastie între obiectele din OOP și datele din sistemul relațional, agravată de necesitatea programatorilor de a învăța SQL. Oh, da. Deși SQL-ul este cea mai utilă abstractizare meta-lingvistică pe care o cunosc, mulți programatori sunt mai mult decât fericiți să folosească metode și clase Java, prost concepute aș mai adăuga, pentru interogări.
De ce ar a vrea cineva să folosească Hibernate sau DB4O, în loc de SQL, cumva îmi scapă.
Adică, dacă vrei validarea automată a tipurilor de date, nu este mai bine să folosești un limbaj mai flexibil?
Dacă vrei să treci facil la MySQL, de la Oracle, nu poți scrie un compilator? Atât teoria [7], cât și uneltele necesare [8] sunt valabile de câțiva zeci de ani, iar uneltele curente au evoluat atât de mult încât este posibilă scrierea unui parser pentru un limbaj relativ complex în câteva ore, cu tot cu teste unitare.
Și da, când vine vorba de compilatoare există un șoc inițial, cauzat de concepte nefamiliare majorității. Și nerăbdarea cu care vrei să aplici aceste tehnici este un dezavantaj.
the clumsiness of people who have to engage their brain at every step is unbearably painful to watch, at least to me, and that’s what the novice-friendly software makes people do, because there’s no elegance in them, it’s just a mass of features to be learned by rote. however, this suits people a hell of a lot better than setting out at age 6 to become a great ballet dancer and
achieving their goal 20 years later after every tendon and muscle and joint has been asked to perform just a little bit more than nature ever intended over and over and over again. to most people, this is insanity. but in reality, it’s art, and it’s the _art_ in what we do that makes us human.
once you have attained that level of effortless and carefree performance, you forget the pain.
Learning Emacs, by Erik Naggum [11]
La ce se reduce totul?
Eu am acceptat abstractizarea meta-lingvistică drept o alternativă la modularizare. Mi-a luat ceva timp, și am trecut prin durere căutând ceva timp limbajul perfect, mediul de dezvoltare perfect, etc… Voi lăsa însă la o parte mănușile și voi îmblânzi dragonul [7].
Limbajele de programare nu sunt nici zei ce trebuie idolatrizați, dar nici efecte secundare ce trebuiesc suportate în așteptarea unui IDE mai bun. Sunt doar unelte de abstractizare a complexității.
Cred că abstractizarea meta-lingvistică este explicată mai bine în cursul 6.001 de la MIT [9], acompaniat de celebra referință Structure and Interpretation of Computer Programs [1].
Deasemenea, vezi … Growing a Language, de Guy Steele [10].
Bibliografie
- SICP, chapter 4
- Pasiune de copil, si o alegere personala (lexoft.eu)
- It’s the IDE, dummy
- Beating the Averages
- ASP.NET tutorials
- Leaky Abstractions, Joel Spolsky
- Compilers, the Red Dragon book
- Antlr, Bison, Flex
- Structure and Interpretation of Computer Programs (Video Lessons)
- Growing a Language, Guy Steele
- Learning Emacs, Erik Naggum
Posted in compilers, passion, rant | 4 Comments »