Tehnici de programare

Tehnicile de programare au fost create pentru a crește productivitatea programatorilor, măsurată ca număr de linii sursă scrise de un programator pe unitatea de timp. În timp au apărut nenumărate cărți despre tehnici de programare, unde autorii lor au inclus acele capitole pe care ei le considerau a fi tehnici de programare. Dacă prin tehnici de programare eu înțeleg niște modalități speciale de a scrie programe mai bune, mai repede și mai complexe, multe din capitolele incluse în acele cărți nu-și găsesc locul ca tehnici de programare.

În unele cărți la tehnici de programare sunt trecute metodele:

Divide et Impera

Backtracking

Greedy

Programării dinamice.

Consider că acestea sunt metode de a construi algoritmi. Că acei algoritmi permit scrierea de programe este o cu totul altă ciorbă de pește. Unele cărți se intitulează ceva cu algoritmi și tehnici de programre dar acolo nu apar:

- programarea structurată;

- programarea vizuală;

- programarea orientată obiect.

Sau apar, dar expediate rapid. Nouă ne plac denumirile de discipline misterioase, fără a le pune în corespondență corectă un un conținut adecvat, ci în ele pune fiecare ce crede sau ce vrea sau ce i se năzare pur și simplu, să se creadă că chiar acolo se fac lucruri speciale, căci sortarea nu este o tehnică de programare și nici ingineria programării.

(22 octombrie 2017)

Programarea industrială

Și la noi, ca peste tot, a existat obsesia scoaterii programării calculatoarelor de sub zodia artei, aducând-o dincolo de meșteșugărie, spre industrie. Mulți necunoscători și-au imaginat crearea de programe de calculator ca pe un proces industrial, unde programatorul asemeni strungarului se așează în fața calculatorului și dacă strungarul face șuruburi, programatorul face programe. Numai că aceștia au uitat că șuruburile strungarului sunt identice toate între ele, pe când programele scrise de programator, au ele ceva elemente comune, dar sunt otuși unicate, ceea ce este o mare diferență între strungar și programator.

Acum în condițiile robotizării se realizează unicate în cadrul fluxurilor de producție de masă, în ideia de a face personalizări radicale la încălțăminte, la cămăși, la ochelari de soare, dar repet, este vorba de robotizare unde se mențin randamente foarte ridicate și cu calculatorul se fac tot felul de combinații de materii prime și de reglaje de echipamente, încât randamentele și fluxurile nu au de suferit câtuși de puțin. În acele vremuri de început ale informaticii nu se punea problema în acest fel, căci nici tehnici de programare nu prea existau, iar tehnica programatorului șef a enervat foarte mult, fiind la noi factor de regres, știut fiind faptul că mulți dintre programatori erau solitari, fiind alergici la a lucra în echipă și cu atât mai mult să se uite altcineva în programele lor, din orgoliu, desigur.

Peste tot unde se făcea programare s-a încercat să se pună un pic de ordine prin:

- alinierea programatorilor în raport cu un stil de programare omogen;

- impunerea utilizării componentelor de bibliotecă;

- construirea părților unui program de către mai mulți programatori și apoi asamblarea părților;

- specializarea programatorilor în a scrie programe cu funcționalități relativ identice;

- obligativitatea de a respecta reguli în folosirea de variabile și de instrucțiuni.

Când am auzit de tentativa din anii '80 de a se face o fabrică de software la Timișoara m-am închinat cu amândouă mâinile, căci studiasem problema și tentativa devenea realistă numai și numai dacă:

- programatorii aveau calculatoare legate în rețea, asemeni utilajelor legate în flux;

- existau instrumente puternice care să pună bazele definirii de specificații complete și corecte;

- bibliotecile de programe conțineau suficient de multe componente care asigură reutulizare;

- colaborativitatea programatorilor este componentă a educației acestora.

Inexistența acestor condiții am crezut că nu vor încununa cu succes inițiativa timișoreană, căci studiasem destul de mult productivitatea programatorilor și fără a depăși un anumit nivel nu ai cum să vorbești de procese industriale, iar programarea se găsea în acel moment în stadiul de artă pură, în care programatorul asemeni pictorului are tuburile de culor sub forma de instrucțiuni. Un pictor bun cu aceleași tuburi face capodopere, cum și un programator din aceleași instrucțiuni scoate programe excepționale, tot așa cum un pictor slab cu tuburile de culor nu face mai nimic tot așa cum un programator slab eșuează lamentabil cu toată diversitatea instrucțiunilor din limbaj pe care le are la dispoziție și pe care le-ar folosi oricum ar vrea fără a avea costuri suplimentare de niciun fel.

Nici în ziua de azi problema industrializării producției de software nu se tratează ca pe o problemă serioasă din cauză că diversitatea de programe este așa de mare încât unicatele nu se realizaează în regim industrial căci roboții nu s-au apropiat așa de mult de programatori încât să le preia din muncă, chiar dacă generatoarele de programe sunt o realitate, dar una crudă din moment ce programele generate nu au diversitatea pe care ne-am dori-o.
Programarea industrială  este și azi un vis, căci nu au apărut instrumentele care să înmagazineze atâta informație încât să se dicteze problema și să se scrie automat programul, ca element nou, care nu are multe lucruri în comun cu alte programe scrise anterior. Concepte ca programarea automată, ingineria programării, sunt numai niște elemente de a-i mângâia pe creștet pe unii pentru a le arăta că și în programare s-au făcut progrese, dar nu atât pe cât s-ar crede că este suficient ca între terminologie și realitate să fie o suprapunere perfectă.

(16 octombrie 2017)