Aventura lui Linus Torvalds in C++

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++. "

Edited by WinstonMontana, 28 June 2018 - 22:44.

da, si daca imi amintesc bine un coleg de pe forum chiar a facut un tutorial cu asta

MarianG, on 28 iunie 2018 - 22:50, said:

unde, unde ?

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...

Pai daca C++ este asa si pe dincolo, de ce lumea il mai foloseste ? Care e faza ?

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.

TS030, on 29 iunie 2018 - 01:40, said:

tu cate sisteme de operare si sisteme de version management ai scris?? Ca sa stim cu cine stam de vorba...

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:

Era pe aici postat de @dani.user

Edited by neagu_laurentiu, 29 June 2018 - 03:26.

WinstonMontana, on 28 iunie 2018 - 22:55, said:

https://forum.softpe...5-de-la-c-la-c/

WinstonMontana, on 28 iunie 2018 - 23:53, said:

faza e ca nu toata lumea scrie cod pentru kernel-uri

_Smiley_, on 29 iunie 2018 - 06:13, 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

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.

Edited by OriginalCopy, 29 June 2018 - 08:07.

Nu foarte... niciunul nu e gandit serios pentru oop, C deloc, la C++ e un afterthought, ambele duc la decizii naspa de design si alte neplaceri... C++ macar are de rau de bine niste standarde si niste conventii in privinta OOP...

unbrutus, on 29 iunie 2018 - 01:59, 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.

Edited by TS030, 29 June 2018 - 08:48.

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:

Este relativ simplu sa restrictionezi utilizarea unor librarii. Orice cod de productie este supus unui review, nu? In cazul Boost il poti si automatiza.

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.

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.

Edited by OriginalCopy, 29 June 2018 - 09:52.

TS030, on 29 iunie 2018 - 08:48, said:

in anumite cazuri, da, se poate folosi si acest argument.

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.

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:

Actualmente, dezvoltarea C++ se face in directia unei utilizari mai facile. Din motive de compatibilitate (non-negociabile), asta nu se face prin simplificarea in sine limbajului.

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.