Изненада

Вижте тук

Наистина изненада. Ама то човек като остарее...
Най ме учуди твърдението "object-oriented programming is counter-intuitive, illogical and inefficient"

:))))))))

Напълно съм убеден, че C++ и OOP е чиста глупост.

Радвам се, че и самия Stroustrup си го казва.

:)))))))

какво пък му е изненадващото?
поздравления обаче за шегаджията който е сътворил това "интервю"...
това за 4 процесорния Sparc си беше направо класика! :))

хубавото е, че интервюто изглежда правдоподобно, някои неща не са съвсем далеч от истината (IMHO)...

Kak niama da si ubeden, kato si samo edna tochka ('.').
I nistho poweche!

Ето ти и две точки, нямаш проблем :)

По същество:
(1) C++ наистина повече усложнява софтуера и е илюзия, че програмите стават reusable. За мен на чисто C софтуера може да се организира много по-семпло и по-разбрано. А простотата значи удобство за работа.
Преимущество за C.
(2) Самото OOP е само една от много възможните парадигми чрез които програмиста може да моделира външния свят. Наистина понякога е удачно. Но много често проблеми нямащи никаква OO структура изкуствено се напъхват в модела на OO. И кой има полза от това?
Все пак и на C можеш да си организираш софтуера OO ако много ти трябва.
Никакво преимущество за C++.
(3) Да се работи и поддържа голям софтуер на C++ изисква времето и енергията на добри и знаещи програмисти. Чисто прахосничество! Добрите програмисти могат да се заемат с нещо по-полезно от доизкусоряването на синтаксиса и наместването на йерархии.
Недостатък на C++.

Много хора (и аз) пишат на C++, заради VC++, MFC,... плюс всички автоматики които дава Microsoft. И заради по-лесна съвместимост с Windows.
Но доста хора (и аз) ще ти кажат, че не се радват много на двата ++.

Ще ти отговарям по-нататък, само ако спориш по същество.

както навсякъде е необходимостта от добър дизайн. И преимуществото на C++ пред C е, че в много случаи самия ОО подход води до добра абстракция, а ОО абстракция се реализира по-лесно с ОО език, защото самия език ти дава удобни средства.

Добър дизайн, от друга страна, се прави трудно. И точно затова за немалко проекти няма смисъл от ОО подход - хората по-трудно се учат да мислят ОО, следователно подходът само им пречи. В такива случаи C е по-добър избор, като се абстрахираме от синтактичните удобства на C++, разбира се (имам предвид например възможността да дефинираш променливи където ти трябват, а не в началото на функцията/отворената скоба. И други подобни).

В две неща, обаче, играещия ролята на Stroustroup тип е прав - езикът е доста сложен и програмистите си умират да използват всяка възможност в него. Естествено, това рядко води до добри резултати.

Според мен, C++ е просто най-малко лошия избор на език за ООП. И то само, защото вече има доста добри компилатори, които генерират много добър код. Като лекота на използване и изучаване, от езика има още много да се иска. Java, например, е къде-къде по-напред. Да не говорим, че C++ вече е стар език. Съвременните технологии за създаване на софтуер изискват, как да го кажа, по-различен подход.

По-различен подход?

Ето ти няколко неща, които не ми харесват в C++:

- статични оптимизации. Оптимизацията се прави по време на компилиране. Тоест, моя грижа като програмист е да си направя profiling на кода, за да разбера къде се бави най-много и да приложа там максимални оптимизации. Не че това е нещо лошо, обаче освен алгоритмични оптимизации (моята работа), не е лошо на съответното място да се прави нещо и от самия компилатор. Тоест, във въпросните фрагменти код да се използват дори най-скъпите оптимизации, защото си струва. Добре, ама как по време на компилиране компилаторът да разбере къде ще ми се мотае кода? Няма как. Значи, трябва runtime някой да ми следи програмата и като види къде се бави най-много, да приложи необходимата оптимизация. Може би проблемът се решава, ако имам възможност да укажа фрагменти, в които да се правят оптимизации на max, обаче а) не знам за такава възможност и б) програмистите са мързеливи и няма да я използват.

- ако искам функциите в класовете ми да са inline, трябва да ги дефинирам в header-те. Е не искам. Искам моя header да съдържа само интерфейса, даже без private нещата. Очевидно, много искам. И докато предишната точка може да се разглежда като проблем на по-общ клас езици, тук виновен е точно C++.

- ако нямам header-и на C++ библиотека/обектен файл, ползата от нея е никаква. Това, разбира се, важи и за C. И не смятам, че import във VC++ решава проблема - това вече не е C++, не е стандарт и трябва специално да се грижа да използвам IDL. Аз, например, пиша много на C++, но не мога да използвам VC++ и не искам да описвам всичко с IDL. Освен това, ако без да искам съсипя някакъв си текстов (header) файл, ела да видиш. Примерно, като променя стойност на някой define. Да, знам, че .h файловете трябва да са read-only, ама това е work-around, а не решение на проблема.

- разглеждането на масивите просто като указатели към паметта. Липсва какъвто и да е контрол върху използването им. А бих искал. Няма лошо, ако в крайната версия на кода тази проверка се изключи. Докато пиша обаче, искам да ме спират, преди да омажа паметта. А и не мога просто да връча на функция масив - трябва задължително да казвам и колко е голям. Досада.

-template - само статични. Не мога runtime да накарам някакъв клас да работи с еди-какви си данни. Проблеми: не мога да напиша код, който взима някакъв темплетизиран клас, без значение какъв точно template използва в момента, и да правя нещо с него. Всъщност май мога, ама е грозно и никак не ми харесва.

- препроцесора. Ебаси дивотията. Направо не ми се говори за него.

Мога да напиша още сума неща, но същината е следната: C++ не дава добра абстракция от компютъра. Практически C/C++ са машинно-независими макроасемблери. От една страна, това е хубаво - дава ти пълен контрол върху машината. От друга - никак не се грижи да те улеснява. Всичко си е твой проблем. Ако пишеш код с ниска степен на абстракция (например операционна система), друго не ти и трябва. Обаче ако пишеш потребителско приложение (Word), трябва непрекъснато да мислиш за дреболии, което е досадно. Да, знам, че могат да се напишат библиотеки, които донякъде да те разтоварят от подобни грижи, ама това е заобикаляне на проблема. Който в същината си е следния: C++ не е подходящ за mainstream език. C++ е специализиран език, който трябва да се използва по предназначение - да се пише бърз код, който работи на ниско ниво. И понеже този код е сравнително малко, с него могат да се заемат истински професионалисти, които имат достатъчно време и желание да се учат и да изчистят бъговете, за откриване на които C++ не прави кой-знае колко.

За масовия програмист, обаче, трябва език с по-голяма степен на абстракция. Език, който се учи лесно, налага дисциплина, поради която не бъркаш толкова много, помага ти да пишеш бързо и т.н. Тоест, език за не-маниаци, а хора, които просто ходят на работа като програмисти. От такива хора не можеш да очакваш да влагат безкрайни усилия в програмирането, затова и толкова много продукти имат плачевно качество. И това е, пак повтарям, заради факта, че за тези проекти се използва C++.

Много се изкушавам да кажа, че Java е този език. За съжаление, поне в момента не е така. И причината е проста - все още Java не е узрял достатъчно за такива цели. Подходът обаче е правилен и това може да ти каже всеки, който е правил по-голям проект на Java.

[линк] horata i ofis paket sa napisali na java.... zastho da ne stava za seriozni prilojeniq.. :))

a da ne zabraviame i JBuilder koito si e dosta seriozno prilojenie i e 100% java...

taka ili inache niakoi shte otgovori sys "java prilojeniqta sa bavni" ili nestho takova.. e da no pone niakoia greshka na programist-indiec niama da ti srine cialata OS zashtoto e obyrkal adresa na neshto si.. :))

a i osven tova ne e neobhodimo da izpolzvash OS na M$ za da rabotish s prilojeniqta... :))

na gleite tuka kwa e istinata:

[линк]

Всички тези "недостатъци" на C++ за които говориш ти излизат когато решиш да го използваш като език от "по-високо" ниво. А той си е едно C със съмнителни (и неудачно избрани от Stroustrup) добавки, които са уж за да можем да пишем OO.

Не зная защо не ти харесва, че пойнтер и масив е едно и също. За мен това е най-удобната абстракция; има памет която може да се адресира, а в нея си слагаш квото ти е кеф. Не ми трябва нищо повече от if-then-while, свободно да пипам паметта и малко макроси с #define. Всичко по-нататък се гради с абстракции, но собствени и както ми е угодно, а не по съмнителни правила на OOP и C++. Това не е избягване на проблема, а решението му.
От езиците от по-високо ниво работа ми вършат инструменти като MathCad или Euler за да проверя и моделирам някои алгоритми, преди да си ги напиша на C.

Но изглежда различни програмисти имат различно ниво и разбиране и различни вкусове.

Ясно е, че самия Stroustrup няма да плюе върху своя език.

Ние пък можем!
Понеже C++ е голема боза с която Microsoft, ATT и компания заблуждават и унищожават кункоренцията :))))

qko pich...microsoft unishtozhawat linux sys c++...kak li ne sym se setil sam dosega...

Ами това C++ е сложено в GNU за да не кажат такива майстори като теб, че GNU не могат да им изкомпилират гениалните бози :)))

ako trqbwa da sme tochni pichowete ot FSF/GNU mi zwynnaha i pitaha "abe mnogo iskame twoite genialni bozi da se kompilirat s gcc, ta razreshawash li da slozhim c++ support, a?", na koeto az estestweno dadoh ljubezno syglasie...

a ako sluchaino ne si zabelqzal ot 1999 nasam GCC oficialno znachi ne "GNU C Compiler", a "GNU Compiler Collection" i oswen c++ ima front-end i za java i fortran i razni drugi neshta...

всеки от нас има различно разбиране/подход към нещата.

Ще ти кажа защо не ми харесва pointer и масив да са едно и също. За мен указателя е инструмент, с който мога да стигна до произволно място, където има записани данни от някакъв тип. И толкова; нищо не ме кара да смятам, че точно преди или след тези данни има още такива. Наистина, ако знам че има, няма лошо да ги използвам и адресната аритметика е супер за такива ситуации.

Масивът, обаче е по-скоро обект, или структура от еди-колко си неща от даден тип, ако предпочиташ. Тоест, той е нещо цялостно, което върви заедно с размера си, освен мястото в паметта, от което започва и типа на данните, които съдържа. И, забележи, нищо не кара елементите да бъдат последователно разположни в паметта; това е просто едно възможно решение. Ключовото е, че масива съдържа еди-колко си елемента, които се адресират с индексите си.

Бе всеки път стигаме до някакви подобни спорове. Моето скромно мнение е следното - всеки влак си има пътници. От тук по темата мога да направя два извода:
1. Ако някой ми предложи някаква абстракция и тя ми трябва - използвам я. Лошо е ако ти предложат половинчата абстракция. Като ще е гарга да е рошава, като ще е масив да е масив, а не нещо дето е почти масив ама не съвсем. Във втория случай съвсем естествено идва другата идея - ами като не са го донаправили вместо да се мъча с половинчати решения, по-добре да си направя нещо мое дето ще ми върши работа. От тук до извода "ами то аз мога и на С/асемблер/машинен код мога да си направя същото, що ми трябват тези нови идиотщини" е съвсем близко. Така си е, но това за мен не е правилния път. Не е проблем да си направиш собствена абстракция, но доста по-добре си е да я има като естествена част от езика.
2. Не знам защо толкова често се повдига въпроса за най-добрия език за програмиране. Ами може ли да се каже кое е най-доброто превозно средство с колела, а кой кораб е най-добър или кой самолет? Защо иската да има един единствен език, който да е супер и най-добрия. Практиката е показала, че такова животно нема. В момента се сещам за три такива езици Algol, PL/1 и Ada. Супер са и всичко си имат, но кой знае защо не се използват. Навремето ми беше писнало като ида на някой конкурс и някой мастит преподавател да ме изпитва за PL/1, въпреки че никой в съответния институт не го използва. Честна дума, виждал съм компилатори и за трите, но за толкова години вече не съм видял да се използва програма написана на някой от тези езици. Хората си пишеха на ограничените Fortran, Cobol, Paskal, C и кой знае защо не искаха да използват тези езици, в които има "всичко". Може би защото са прости

- статични оптимизации. Оптимизацията се прави по време на компилиране. Тоест, моя грижа като програмист е да си направя profiling на кода, за да разбера къде се бави най-много и да приложа там максимални оптимизации. Не че това е нещо лошо, обаче освен алгоритмични оптимизации (моята работа), не е лошо на съответното място да се прави нещо и от самия компилатор. Тоест, във въпросните фрагменти код да се използват дори най-скъпите оптимизации, защото си струва. Добре, ама как по време на компилиране компилаторът да разбере къде ще ми се мотае кода? Няма как.
Някъде бях чел, че оптимизацията на алгоритмите е дело на програмиста. Защото е абсурдно да искаш машината да осмисля и да разбира това, което пишеш. А статичните оптимизации са достатъчни в повечето случаи - компилаторите в последно време доста са се осъвършенствали. Не заместват тъпо дадена продукция с поредица машинни инструкции, а си имат експертни системи, които добре преценяват какъв точно код да се генерира за да се изпълнява максимално бързо на зададена платформа.

Значи, трябва runtime някой да ми следи програмата и като види къде се бави най-много, да приложи необходимата оптимизация.
Разбираш ли, това означава непрекъснато да следи. Което, естествено, намалява общото бързодействие. На места наистина може да се направи нещо, но като цяло всичко ще върви по-бавно, просто не си струва. Ако си струваше, щеше да бъде направено вече.

- ако искам функциите в класовете ми да са inline, трябва да ги дефинирам в header-те. Е не искам. Искам моя header да съдържа само интерфейса, даже без private нещата. Очевидно, много искам. И докато предишната точка може да се разглежда като проблем на по-общ клас езици, тук виновен е точно C++.

Съжелявам, аз съм фен на M$. Хората са си решили проблема:

inline

function_declarator; // C++ Specific

__inline

function_declarator;// Microsoft Specific

__forceinline

function_declarator;// Microsoft Specific

The inline and __inline keywords allow the compiler to insert a copy of the function body into each place the function is called. The insertion occurs only if the compiler's cost/benefit analysis show it to be profitable. The __forceinline keyword overrides the cost/benefit analysis and relies on the judgement of the programmer instead. Exercise caution when using __forceinline. Indiscriminate use of __forceinline can result in larger code with only marginal performance gains or, in some cases, even performance losses (due to increased paging of a larger executable, for example).

С горното, мисля, че се изчерпва този въпрос.


- ако нямам header-и на C++ библиотека/обектен файл, ползата от нея е никаква. Това, разбира се, важи и за C. И не смятам, че import във VC++ решава проблема - това вече не е C++, не е стандарт и трябва специално да се грижа да използвам IDL. Аз, например, пиша много на C++, но не мога да използвам VC++ и не искам да описвам всичко с IDL. Освен това, ако без да искам съсипя някакъв си текстов (header) файл, ела да видиш. Примерно, като променя стойност на някой define. Да, знам, че .h файловете трябва да са read-only, ама това е work-around, а не решение на проблема.
IDL е един вид стандартизиран мултиезичен начин за описание на header file. Разбираш ли, съвременните програми/изпълними модули имат един регион вътре в себе си, наречен "ресурси", в който може да се съхранява всякаква информация. Та пъхаш си header-a в ресурсите и всички ще могат да ти ползват модула. import във VC единствено транслира мултиезичния хедър от IDL във C++ хедър.

- разглеждането на масивите просто като указатели към паметта. Липсва какъвто и да е контрол върху използването им. А бих искал. Няма лошо, ако в крайната версия на кода тази проверка се изключи. Докато пиша обаче, искам да ме спират, преди да омажа паметта. А и не мога просто да връча на функция масив - трябва задължително да казвам и колко е голям. Досада.

Ами аз не мога да си представя паметта по друг начин освен като масив. Указателите са просто индекси от масива. А за контрола - не си прав. Виж функциите:

IsBadCodePtr
Determines whether the calling process has read access to the memory at the specified address.

IsBadReadPtr
Verifies that the calling process has read access to the specified range of memory.

IsBadStringPtr
Verifies that the calling process has read access to a range of memory pointed to by a string pointer.

IsBadWritePtr
Verifies that the calling process has write access to the specified range of memory.

Ако си фен на M$. Ако не си - сори, добре е да станеш.


-template - само статични. Не мога runtime да накарам някакъв клас да работи с еди-какви си данни. Проблеми: не мога да напиша код, който взима някакъв темплетизиран клас, без значение какъв точно template използва в момента, и да правя нещо с него. Всъщност май мога, ама е грозно и никак не ми харесва.

- препроцесора. Ебаси дивотията. Направо не ми се говори за него.
На шаблоните и аз не съм фен. А препроцесора е много ценно нещо. Зависи от гледната точка, нали знаеш

Мога да напиша още сума неща, но същината е следната: C++ не дава добра абстракция от компютъра. Практически C/C++ са машинно-независими макроасемблери. От една страна, това е хубаво - дава ти пълен контрол върху машината. От друга - никак не се грижи да те улеснява. Всичко си е твой проблем. Ако пишеш код с ниска степен на абстракция (например операционна система), друго не ти и трябва. Обаче ако пишеш потребителско приложение (Word), трябва непрекъснато да мислиш за дреболии, което е досадно. Да, знам, че могат да се напишат библиотеки, които донякъде да те разтоварят от подобни грижи, ама това е заобикаляне на проблема. Който в същината си е следния: C++ не е подходящ за mainstream език. C++ е специализиран език, който трябва да се използва по предназначение - да се пише бърз код, който работи на ниско ниво. И понеже този код е сравнително малко, с него могат да се заемат истински професионалисти, които имат достатъчно време и желание да се учат и да изчистят бъговете, за откриване на които C++ не прави кой-знае колко.
Ти пък Всички компютри имат НОК, което е превъзходно описано с езика Си. А Си-то няма нищо общо с асемблера - то си е ЕВН.

За масовия програмист, обаче, трябва език с по-голяма степен на абстракция. Език, който се учи лесно, налага дисциплина, поради която не бъркаш толкова много, помага ти да пишеш бързо и т.н. Тоест, език за не-маниаци, а хора, които просто ходят на работа като програмисти. От такива хора не можеш да очакваш да влагат безкрайни усилия в програмирането, затова и толкова много продукти имат плачевно качество. И това е, пак повтарям, заради факта, че за тези проекти се използва C++.
Няма нужда да ти казвам, че има _твърде_ много такива езици. Според мен това е свързано с _твърде_ големия срив на ИТ пазара напоследък. А по-абстрактен език от C++ наистина не съм виждал. Няколко оператора и НИЩО повече. Никакви вградени I/O ф-ии, просто нищо. И въпреки това с него може да се описва ВСИЧКО.
В един филм бях чул една прекрасна сентенция: "Всички велики неща на този свят са създадени от фанатици".

Много се изкушавам да кажа, че Java е този език. За съжаление, поне в момента не е така. И причината е проста - все още Java не е узрял достатъчно за такива цели. Подходът обаче е правилен и това може да ти каже всеки, който е правил по-голям проект на Java.
Съжелявам, аз съм върл противник на всеки pcode. Дри да направят компилатор за native code, Java-та е за мен език от "небостъргачно" ниво и не може да се разчита, че ще бъде конкуренция на Си.



Si Vis Pacem, Para Bellum

oburkal si thread-a pich - vig v "C++ e gnusna rabota" tam tezi neshta biaha lubezno preduvkani ot massa narod...