Discutie despre minimalizarea toolurilor si frameworkurilor si toolurilor, cu paralela la cooking, si motive pro-contra.
Related to this topic.
compara mere cu pere si ceapa. cutitul e o unealta, nu limbaj de programare. limbajul de programare e gatitul.
ca sa nu mai zic… nu incarci o librarie pentru ca creezi dependinte. mai bine te apuci sa faci tu una, ca aia nu creeaza dependinte.
@Sapioit why would you unearth this unholy thread? (ma refer la cel de unde ai sters post-ul) mai ales ca ai facut unul nou cu same bloody content …
Desi l-ai sters iar e in the top.
Cutitul e o unealta. Blenderul este o alta unealta, care de foloseste de cutite (unelte).
Ideea era urmatoarea:
Xulescu invata bazele unui limbaj, apoi incepe sa invete frameworkuri.
Zetulescu invta bazele aceluias limbaj, apoi se concentreaza pe limbaj, in loc de frameworuri.
Funfunfunction, vrea sa spuna ca, in timp, va fi un triping point, in care Zetulescu va putea intelege cod nativ (adica non-framework) mult mai rapid decat va putea Xulescu sa inteleaga codul scris pentru un framework.
Ce nu se mentioneaza este durata pana al acel tripping point.
Nu l-am sters eu. Si nu stiam ca discourse (inca) mai face legaturi intre threaduri. Credeam ca au scos funtionalitatea respectiva cand au adaugat sidebar-ul cu drag-to-#X-comment. Cat despre de ce, fiindca este on-topic si ofera context.
si Zetulscu si Xulescu trebuie sa invete logica din spatele codului. Indiferent ca-i un framework sau cod nativ (n-am nici cea mai mica idee ce-i ala cod nativ. frameworkurile sunt scrise in alt limbaj?)
diferenta e ca un framework are o documentatie destul de bine scrisa si este mai usor de inteles decat o aplicatie scrisa de la 0.
Nu, diferenta este ca frameworkurile sunt un cod pe care este foarte probabil ca Xulescu sa nu il inteleaga. (Cod nativ = cod scris fara un framework disctinct.)
Da, documentatia exista, dar in momentul de fata nu sunt suficiente studii care sa concluzioneze dupa cat timp acel tripping point ar avea loc. Ideea nu este sa nu folosim framework-uri si tooluri, ci sa le limitam numarul. Spre exemplu, daca este sa comparam Java si Ruby cu Javascript si PHP, observam ca numarul frameworkurilor si toolurilor pentru ultimele doua este mult mai mare decat pentru primele doua.
Unul din efectele economice este faptul ca, nefiind o persoana care sa stie toate acele frameworkuri si tooluri, salariul minim pentru o persoana care stie frameworkul X creste, din cauza a induced demand (hype, trends, fooling the fools, etc.), care, desi creste cantitatea de utilizatori a limbajului de baza, impiedica sau incetineste avansul a mult mai multe persoane decat in lipsa acestui induced demand.
Extra: Videos, example, links
Deasemenea, merita sa va informati si despre Braess’ Paradox. Video mai jos.
https://www.youtube.com/watch?v=DqqjT3Xq620
https://www.youtube.com/watch?v=q16dmckC_QU
https://www.youtube.com/watch?v=8mlH9bnvWVE
https://www.youtube.com/watch?v=ZiauQXIKs3U
https://www.youtube.com/watch?v=sTQAu9TW4jM
Spre exemplu, pentru a inlocui comute-ul cu masini cu cel cu biciclete, trebuie sa ai cate o banda cu sens unic care sa asigure accesul in orce locatie (ca sa poata lumea sa se mute in&out, precum si pentru a nu folosi banda pentru biciclisti), iar restul benzilor sa fie benzi pentru biciclisti sa aiba delimitatoare fizice care sa nu permita masinilor sa intre pe benzile respective, precum si locuri de parcat bicicletele (spre exemplu, parcarea de masini se va face paralel cu sensul de mers pentru masini, aproape de trotuar, iar parcarea de biciclete se va face intre trotuar si benzile pentru biciclisti, dar perpendicular cu sensul de mers, deoarece ocupa tot cat o masina).
Astfel, early adaptors vor folosi bicicletele si vor vedea ca le ia mai putin sa ajunga unde vor, mai multe persoane vor folosi biciclete, companiile vor incepe sa inlocuiasca (initial intr-un numar mic, care va continua sa creasca) locurile de parcare pentru masini cu cele pentru biciclete (un loc de parcare pentru masini poate fi folosit de intre 2 si 6 biciclete si ar necesita jumatate din latimea sensului de mers, pentru acces si tranzit).
Chestia cu framework-ul este un fallacy de tipul it’s turtles all the way down:
- framework
- Shiny Language + standard library
- the language the Shiny Language is written in
- LLVM and friends if the base language is also written using other abstractions
- assembler care si el a devenit a abstractie in modern times
De sus pana jos vbim de un set de abstractii iar fiecare isi au sensul in contexte diferite si evident their leaky coefficient gets lower as we go down
tl;dr: stop splitting hairs ffs it’s not rocket science ™
De acord, dar, cred eu, in video-ul respectiv se recomanda micsorarea numarului de framework, dar nu suficient incat sa incetineasca prea mult dezvoltarea.
Cu alte cuvinte, sa micsoram numarul de abstractii, si sa ne concentram pe adaptarea lor pentru a fi cat mai usor de folosit si eficiente pentru use-case-urile dorite, in loc de fragmentarea pietei.
Cu alte cuvinte, adaptarea frameworkurilor, in loc sa facem/viralizam cate un framework pentru fiecare usercase posibil.
tl;dr: it’s not rocket science ™ …yet, it’s the foundation of our society, and with a weak foundation, I guess you know the rest. And to make it rocket science, we only need one step: going from drones to satellites. And SpaceX is making that easier.
iarasi ceva trivial: NIH syndrome - care nu are legatura cu frameworks ci cu cei care activeaza in comunitatea respectiva si their values - si la fel este ierarhic e.g. poti aplica NIH cand iti scrii propria functie de bubble sort in your Shiny Language cand de fapt ea este implementata in C in std. library.
daca incerci to be a smart-ass macar do it on subject.
@Sapioit ți-a atras atenția și @tekkie acum câteva zile, ți-am mai zis și eu de câteva ori (și probabil și alții): nu este nevoie să ai opinii despre orice. Serios, nu câștigi nici un premiu dacă o faci, nu dai pe nimeni pe spate cu „uau, câte știe ăsta!”, nu nimic.
Faptul că vii și ne citezi din cărți și/sau articole scrise de alții fără ca tu să ai experiență practică în domeniul respectiv nu ajută. Pur și simplu, fără experiență nu poți face diferența dintre un articol/subiect bun și unul prost. Cel mult, poți recomanda dacă un articol e scris bine, nu dacă are informație bună.
Apoi, adaugi câte cinci filme/comentariu. Realist vorbind, ce șanse sunt ca cineva să se uite la ele în condițiile în care sunt complet fără legătură cu development?
Te-am rugat de câteva ori: nu mai da 
la fiecare comentariu, face această funcționalitate inutilă. Este imposibil să îți placă fiecare comentariu de pe forum. Chiar îți plac toate comentariile? Dacă da, chestia asta ar trebui să ne spună ceva despre capacitatea ta de a discerne între un material bun și unul… mai puțin bun, recte ar trebui să luăm orice contribuție de-a ta cu un bob pumn de sare.
Nu vreau să îți blochez accesul, dar îmi lași impresia că ne testezi răbdarea.
Nu te obosi să-mi răspunzi, cel mai probabil vei face cherry picking pe o virgulă.
8 Likes
@iamntz puteai sa-i zici asta si in privat 
nu stiu ce sens are public witch hunting.
1 Like
Puteam. Și i-am zis. De mai multe ori.
1 Like
Nu, dar dau like daca imi place cel putin o parte din comentariu. Daca o fraza de 2-3 cuvinte imi place cum suna (in contextul respectiv), dau like.
Poate nu au legatura directa cu programarea, dar au legatura cu developmentul, doar ca nu neaparat developmentul de programe informatice. Mergeam pe asumptia ca dev-ul din devforum se refera la development in general. De aceea ofeream informatii (aparent) extra, care au legatura directa cu dezvoltarea in general.
Imi cer scuze pentru problemele cauzate de interpretarea gresita a informatiilor, de catre mine. Voi incerca sa nu mai repet aceleasi greseli.
Daca tot discutam de asta si suntem deja in off-topic, desi not sure ce topic era, desi (#2) incepuse sa mi se para int. discutia - ma rog, cateva sugestii pt @Sapioit:
- incearca sa postezi videos ca links in subsol
- evita walls of texts, o idee exprimata concis uneori face cat pagini intregi de bla bla
- imi place ca atingi foarte multe subiecte si faci legatura intre ele insa uneori cand argumentezi ceva keep focus altfel ajungi in straw-men si alte logical fallacies (daca este ceva legat si nice to read, la fel, pune un link in subsol)
3 Likes