Aventura lui Linus Torvalds in C++
Ultima postare: iun 29 2018 21:39, Inițiat de
WinstonMontana
, iun 28 2018 22:41
·
0
#1
Publicat: 28 iunie 2018 - 22:41
http://harmful.cat-v...tware/c /linus
Pareri ? Sunteti de acord cu el ? Sunt doua mailuri , insa mai intersant este al doilea mail , unde spune : "you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++. " Editat de WinstonMontana, 28 iunie 2018 - 22:44. |
#4
Publicat: 28 iunie 2018 - 23:22
Ar fi culmea sa nu fim de acord... omul si-a exprimat parerea despre C++ si chiar si programatorii care il utilizeaza, in mod public, de mai multe ori.
Desigur se referea la cei care vor sa contribuie la proiectul lui, nu la toti. A putut fi combatut pe zeci de forumuri, nu prea mai e mult de adaugat. Realitatea e ca stie ce zice... |
#6
Publicat: 29 iunie 2018 - 01:40
Nu e deloc aiurea sa nu fii de acord cu aberatiile crunte pe care le-a varsat Linus. Un singur punct valid are, si p-ala il expune prost: daca nu poti controla cum diversii programatori se folosesc de facilitatile limbajului, este mai usor sa iasa un haos total decat la C.
Iar ca sa spui ca programatorii C++ sunt prosti in general, se numeste ca mananci cu polonicul. Nu in ultimul rand, despre ce limbaj vorbim? C++ nu mai este cel din 2007. |
#8
Publicat: 29 iunie 2018 - 03:29
Nu e o noutate asta cu "C & OOP", avem printre altele o implementare in GObject/GTK+/Gnome, sunt si carti pe tema asta.
Nu avem nici o egalitate intre Linus si altii, fiecare cu proiectele sale, in alt context, toti au dreptatea lor. La fel cum C++ nu te forteaza sa folosesti doar o anumita paradigma (nici nu trebuie dusa la extrem), sau anumite biblioteci. De fapt aici e marea "arta", ca tu iti alegi calea. WinstonMontana, on 28 iunie 2018 - 22:55, said:
unde, unde ? Editat de neagu_laurentiu, 29 iunie 2018 - 03:26. |
#9
Publicat: 29 iunie 2018 - 05:26
#11
Publicat: 29 iunie 2018 - 06:47
_Smiley_, on 29 iunie 2018 - 06:13, said:
faza e ca nu toata lumea scrie cod pentru kernel-uri the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes: - infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny) - inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app." Se refera strict la C++ si nu despre domeniul kernelului |
#12
Publicat: 29 iunie 2018 - 07:59
Nu am lucrat eu chiar atat de mult cu C++, dar proiectele pe care le-am vazut se pretau pentru C++. Si in toate existau problemele ridicate de Torvalds.
C++ e un limbaj atat de imbuibat cu tot felul de artifacte, noile standarde doar adauga noi si noi lucruri care fac limbajul si mai complicat si incoerent, dezvoltarea e foarte greoaie si trebuie sa treaca printr-un comitet foarte colorat, si multe alte probleme. Cred ca in C++ se va lucra peste 10-20 de ani doar de nevoie, in proiecte legacy, in 99% din cazuri. Proiectele greenfield in C++ vor fi la companii mari care ofera SaaS, vor fi restul de 1%, si serviciile vor fi oferite prin internet. De exemplu ceva inovatii in AI si web API-uri pentru interactiunea cu acel AI de la google. In rest, limbaje ca Rust sau similare vor prelua locul, mult mai curate, mai consistente si coerente, generand cod binar la fel de eficient, dar cu compilatoare mult mai puternice. Rust editia 2015 (1.0) a aparut in 2015 dupa 9 ani de 0.x in care a fost intors pe toate partile. Editia urmatoare, Rust 2018, deja se anunta a fi foarte ergonomica, cu lucruri precum non-lexical lifetimes. Iar dezvoltarea e permanenta, iterativa, include comunitatea. Au un sistem de RFC robust care nu face compromisuri. In fata unei decizii complexe, se merge pe varianta sigura, chiar daca nu acopera toata problema mare, si apoi se continua mai tarziu cu un alt RFC, cand mai multe idei noi au fost implementate. Se re-evalueaza in pasi foarte granulari. Editat de OriginalCopy, 29 iunie 2018 - 08:07. |
#14
Publicat: 29 iunie 2018 - 08:48
unbrutus, on 29 iunie 2018 - 01:59, said:
tu cate sisteme de operare si sisteme de version management ai scris?? Ca sa stim cu cine stam de vorba... Editat de TS030, 29 iunie 2018 - 08:48. |
#15
Publicat: 29 iunie 2018 - 09:08
Uite, aici gasim lucruri care, daca ar fi fost facute in 2018, ar fi exemple de gandire retrograda (dar si atunci erau suspecte):
WinstonMontana, on 29 iunie 2018 - 06:47, said:
"C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes: - infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny) - inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app." Se refera strict la C++ si nu despre domeniul kernelului Pe de alta parte, libraria standard este matura, stabila si te scuteste de multe probleme (cum ar fi clasicul "fiecare proiect cu propriile implementari de liste" din C ). Iar implementarea e mai eficienta decat sunt in stare - si au timp la dispozitie - majoritatea programatorilor. Ies din contextul unui kernel... un mare cauzator de bug-uri si probleme de securitate din C-ul este buffer overflow-ul. C++ are o solutie. Sa fie rau? Sa fie mai bine sa lucram in continuare cu array-uri si management manual de dimensiuni? Problemele de design nu sunt probleme de limbaj. C++ nu te obliga in vreun fel sa folosesti "inefficient abstracted programming models". C++ iti ofera posibilitatea de abstractizare la cost zero (comparativ cu o implementare similara in C). Nu comparam aici cod C++ scris cu picioarele cu cod C scris ingrijit. Ori una, ori alta. |
|
#16
Publicat: 29 iunie 2018 - 09:39
Multe lucruri pot fi facute in orice limbaj, cu programatori excelenti. Se aplica si lui C++.
Problema e ca C++ e greu de invatat si insusit corect, si restul lucrurilor care pot fi facute cu limbaje ca Rust, nu sunt facute de compilatorul C++. In Rust, daca e o problema de consistenta, codul nici macar nu compileaza. Nu rareori mi s-a intamplat ca, atunci cand scriam cod Rust, compilatorul sa ma forteze sa iau deciziile corecte din start - pentru ca efectiv nu compila. Chiar daca eram constient de problema si voiam sa o las pe mai tarziu: e imposibil. Da, si in Rust poti face greseli, dar cand limbajul insusi in mod direct reduce numarul de teste necesare cu 50-90% fata de un cod echivalent in C++, atunci factual vorbind, ceva e extrem de bine in Rust si extrem de nasol in C++. De exemplu, suntem de acord cu "prefer composition over inheritance". In C++, te bazezi pe disciplina ca sa respecti asta. In rust, e deja integrat direct in limbaj. In rust 2015 erau probleme destul de mari cu ergonomia codului, dar in rust 2018 acestea vor fi foarte mult reduse. Stim ce crede Torvalds despre Rust: https://www.quora.co...s-think-of-Rust si admite ca C are probleme lui, si ca Rust are avantaje. Comentariul lui e mai vechi, despre rust 2015, rust 2018 va avea chiar si mai multe avantaje. Editat de OriginalCopy, 29 iunie 2018 - 09:52. |
#17
Publicat: 29 iunie 2018 - 10:59
TS030, on 29 iunie 2018 - 08:48, said:
Asta se numeste apel la autoritate - pentru tine conteaza nu afirmatiile facute si argumentele prezentate, ci ca Linus a scris un kernel de OS si ca-i celebru. Avem cateva cazuri in istoria lumii cu persoane care au facut atat de multe comparat cu ceilalti. Sa scrii de la zero git, dupa ce deja lucrai la proiectul cu linux, pe care il duci in spate practic singur, da, apelul la autoritate in fata unui oarecare pe net care isi da si el cu parerea ca ala nu are dreptate cand zice ce zice e absolut normal. Trebuie sa ai in spate ceva ca sa poti intelege ce vorbeste omul. Practic, daca nu ai scris si tu un kernel ceva in C si sa il treci in C++, mai bine nu te bagi, parerea mea. |
#18
Publicat: 29 iunie 2018 - 15:45
Apelul la autoritate nu este un argument. Poate doar servi la intarirea unui argument, nu si sa-l suplineasca.
Pe de alta parte, iti pot intoarce foarte usor rationamentul: daca nu ai scris si tu un kernel ceva in C si sa il treci in C++, nu ai de unde sa stii cine are dreptate. OriginalCopy, on 29 iunie 2018 - 09:39, said:
Multe lucruri pot fi facute in orice limbaj, cu programatori excelenti. Se aplica si lui C++. Problema e ca C++ e greu de invatat si insusit corect, si restul lucrurilor care pot fi facute cu limbaje ca Rust, nu sunt facute de compilatorul C++. In Rust, daca e o problema de consistenta, codul nici macar nu compileaza. Nu rareori mi s-a intamplat ca, atunci cand scriam cod Rust, compilatorul sa ma forteze sa iau deciziile corecte din start - pentru ca efectiv nu compila. Chiar daca eram constient de problema si voiam sa o las pe mai tarziu: e imposibil. Da, si in Rust poti face greseli, dar cand limbajul insusi in mod direct reduce numarul de teste necesare cu 50-90% fata de un cod echivalent in C++, atunci factual vorbind, ceva e extrem de bine in Rust si extrem de nasol in C++. De exemplu, suntem de acord cu "prefer composition over inheritance". In C++, te bazezi pe disciplina ca sa respecti asta. In rust, e deja integrat direct in limbaj. In rust 2015 erau probleme destul de mari cu ergonomia codului, dar in rust 2018 acestea vor fi foarte mult reduse. Stim ce crede Torvalds despre Rust: https://www.quora.co...s-think-of-Rust si admite ca C are probleme lui, si ca Rust are avantaje. Comentariul lui e mai vechi, despre rust 2015, rust 2018 va avea chiar si mai multe avantaje. Rust e inca o jucarie. Sa-l vedem cum trece testul timpului, cum evolueaza... Solutia pentru C++ o reprezinta uneltele de dezvoltare, un prim pas fiind C++ Core Guidelines - aplicate automat. Nu e obligatoriu sa fie integrate in compilator. |
Anunturi
Bun venit pe Forumul Softpedia!
▶ Utilizatori activi: 1
0 membri, 1 vizitatori, 0 utilizatori anonimi