Sunt un programator mediocru, dar un dezvoltator excelent

[•Cosmin]

http://infoarena.ro/blog/programator-mediocru-dezvoltator-bun

[•toni2007]

Eu am inceput cu Pascal, am trecut pe C cand lucram pt olimpiade. Acum vreo 4 ani m-am apucat de php, am vazut ca nu imi place si am trecut la ruby. Dupa am inceput sa invat python, bash, javascript (atat pe client cat si pe server). Dupa am inceput sa cochetez cu coffescript si chiar sa lucrez la parserul de haml in python (ghrml).

Pot sa zic ca stiu cam aproape orice in python/ruby/javascript. In restul cam mediu....

[•rgrig]

Voi ignora subiectul principal, dar ... mmm ... evident ca moștenirea e un lucru rău.

In limbajul INTERCAL nu exista instructiunea rea GOTO; în schimb are instrucțiunea COME FROM. Ideea a fost importată în Python.

Cod: (python)

from goto import comefrom, label
comefrom .repeat
name = raw_input('what is your name? ')
if name:
    print "Hello",name
    label .repeat
print "Goodbye!"

Binențeles că e o glumă. Problema e că citești codul de pe lângă „label .repeat” și habar n-ai unde o să meargă mai departe programul decât dacă te uiți la un context destul de mare.

Moștenirea, mai exact polimorfismul de subtip, este mai rău de atât. Dacă vezi un apel x.foo() habar n-ai unde va merge execuția decât dacă știi care este tipul dinamic al lui x. Asta nu poți face decât folosind un context mare și ținând informații dependente de pe traiectoria execuției (flow-sensitive). Există tot felul de încercări de rezolvare a problemei. Liskov a zis că trebuie să nu conteze care dintre foo-uri e apelat. Cu alte cuvinte, foo-urile trebuie scrise în așa fel încât să poți substitui un subtip fără nici o modificare observabilă pentru un utilizator care folosește ca tip static tipul de bază. Restricția asta însă este nerespectată în practică de multe ori, chiar și în APIuri considerate bune. De exemplu, metoda equals în Java. (Nerespectarea principiului lui Liskov e una din explicațiile date de oameni pentru bug-urile nenumărate legate de equals și hashCode.)

Una dintre cele mai recente și complete explicații ale moștenirii este probabil teza lui Parkinson. Înainte de asta polimorfismul de subtip a fost explicat cel mai bine de Cardelli (varianta 1984).

Polimorfismul parametric și polimorfismul ad-hoc nu au problema asta. Cel parametric a fost explicat satisfăcător de Reynolds (search keywords: „relational polymorphism”).

Înseamnă asta că nu mai trebuie folosim polimorfism de subtip? Nu: Înseamnă că trebuie să ne gândim cu atenție dacă chiar vrem să-l folosim, fiindcă e complicat și va cauza probleme neașteptate. Cu alte cuvinte, îl folosim dacă avem motive bune, nu doar din inerție.

[•rgrig]

OK, uite și un comentariu scurt legat de subiectul principal: Învățarea ultimelor procente ia mult mai mult timp în comparație cu învățarea primelor, așa că la un moment dat raportul cost/beneficiu devine așa de prost că nu mai merită.

Edit: O corectare de la Cosmin.

[•vivi]

Mai puține like-uri la articolul ăsta decât la cel anterior.

[•Cosmin]

Mai multe tweeturi in schimb.

Cred ca nu poti combate prea mult concluzia ca vrei sa fi pragmatic si sa get things done.

[•vivi]

Mă așteptam ca măcar oamenii să se revolte că mă consider world-class developer, adică cine mă cred eu? Dar probabil m-am obișnuit așa de la mine de pe blog și audiența de aici este ceva mai... modernă.

[•Cosmin]

) sigur mai susoteste lumea la colturi, uite ma la vivi asta .

[•vivi]

Data viitoare o să încerc să scriu mai incendiar.

[•MciprianM]

Data viitoare o să încerc să scriu mai incendiar.

Poti sa scrii ca romanii nu sunt programatori buni si o sa se revolte multa lume

[•darkseeker]

Nu ar fi frumos din partea lui sa minta .

[•xtreme]

De ce toti scrieti articole 90% despre software developing cand software developing e o ramura asa mica in CS ?

There's no money. There's no possessions,
only obsession. I don't need that ****.
Take my money, take my obsession.

[•vivi]

O ramură mică din punct de vedere al informației, al numărului de oameni care lucrează în ea, sau al banilor pe care îi poți câștiga lucrând în această ramură, comparat cu restul ramurilor CS-ului?

[•xtreme]

  Desi nu sunt sigur 100% , consider ca software developing e cea mai bine platita ramura a CS-ului si de aceea atrage un numar mare de oamenii din orice tara. Din punctul acela de vedere, e intradevar mare. Dar in acelasi timp consider ca software developing are foarte mare pubicitate ( "media" face sa fie asa ) si celalalte ramuri sunt lasate in intuneric.
  Din punctul de vedere al informatiei... nu stiu exact la ce te referi... dar daca te referi la munca/tehnicile care se poat face in software developing, eu zic ca accea cantitate e infinita, La fel ca in celalte ramuri. Nu ai cum sa compari niste chestii ce nu au sfarsit. Bineinteles poti sa compari infiniturile dar, nu in practica.
  De accea, eu zic ca ar trebui popularizate si celalte ramuri sa se limpezeasca diferenta dintre CS si software developing.

[•vivi]

Care ramuri dom'le? La ce ramuri te tot referi? Fii mai clar.

[•stefangab95]

Am învățat BrainFuck din greșeala citind pe Wikipedia, e ok  ?
Limbajul meu principal e VB.net dar lucrez și în C++, C#, PHP, Javascript, Python, ... HTML.
Am ceva cod bun, am fost la InfoEductiea 2011 și la un simpozion de informatica unde am prezentat niște software și aș vrea să particip și anul acesta, și prin acest intermediu pun și eu o întrebare: Îmi poate furniza și mie cineva o idee de software?

[•Cristy94]

In general astia care se axeaza strict doar pe un domeniu eu ii numesc roboti, eu sunt tot genul de generalist, trebuie sa stii frate cate putin din toate nu tot doar dintr-un domeniu.

Da, dar fara "roboti" nu prea ar exista evolutie in anumite domenii...