16 / 16 / 1
Регистрация: 13.10.2012
Сообщений: 454
|
|
1 | |
Недостатки ООП16.05.2014, 16:35. Показов 17173. Ответов 318
Метки нет (Все метки)
Задали написать небольшую статью о недостатках этой замечательной парадигмы. В нашей группе прикладной информатики я один более-менее знаком с разработкой, поэтому на придирчивость аудитории можно не рассчитывать, и я решил спросить мнение опытных людей здесь. Я самоучка-теоретик, так и не написавший более-менее достой программы за свою жизнь, поэтому часть этой статьи навеяна из сети, а вот про усложнения - уже исключительной мой загон - не могу просто взять и написать программу. Пишу, думая, что это будет целый Фреймворк. Ну в общем предлагаю вашему вниманию эту коротенькую статью и рассчитываю на объективную критику. Всего полторы страницы - больше просто не знаю к чему придраться.
https://www.dropbox.com/s/m6u9... D0%9F.docx дропбокс глючит и не дает нормальную ссылку. вот статья под спойлером. Кликните здесь для просмотра всего текста
Недостатки ООП
Парадима ООП не нова. ООП приобрело популярность во второй половине 80-х вместе с такими языками, как Smalltalk, С++, Objective C (другое расширение C) и некоторыми другими. 25 лет назад никто не ожидал, что “новый” феномен ООП проживет столь долго и сегодня большинство современных языков поддерживают эту парадигму. ООП стоит на трёх китах: 1.Первый — инкапсуляция — это определение классов — пользовательских типов данных, объединяющих своё содержимое в единый тип и реализующих некоторые операции или методы над ним. Классы обычно являются основой модульности, инкапсуляции и абстракции данных в языках ООП. 2.Второй — наследование — способ определения нового типа, когда новый тип наследует элементы (свойства и методы) существующего, модифицируя или расширяя их. Это способствует выражению специализации и генерализации. 3.Третий, известный как полиморфизм, позволяет единообразно ссылаться на объекты различных классов (обычно внутри некоторой иерархии). Это делает классы ещё удобнее и облегчает расширение и поддержку программ, основанных на них. Инкапсуляция, наследование и полиморфизм — фундаментальные свойства, которыми должен обладать язык, претендующий называться объектно-ориентированным (языки, не имеющие наследования и полиморфизма, но имеющие только классы, обычно называются основанными на классах). Различные ОО языки используют совершенно разные подходы. Мы можем различать ОО языки, сравнивая механизм контроля типов, способность поддерживать различные программные модели и то, какие объектные модели они поддерживают. Преимущества этих языков всем известны: повторное использование кода, упрощение разработки больших программ, более логичная структура программы и многие другие. Разберём некоторые недостатки. Недостатки есть абсолютно у всего – с этим нужно просто смириться. Важно адекватно их оценивать и стараться минимизировать их влияние. То же самое касается и объектно-ориентированной парадигмы программирования. Есть несколько причин, почему узкие места ООП часто вылазят наружу. Я считаю, что это прежде всего непонимание самой сути объектно-ориентированной техники программирования - восприятие этой парадигмы как серебряной пули. Часто программисты стараются решать абсолютно все задачи, где даже не предвидится конкретных сущностей с их свойствами с помощью объектов, наследования и с помощью объектов. Это очень усложняет процесс. То есть вместо написания парочки функций в процедурной манере и передачи аргументов туда-обратно, программист часто пытается нагромоздить целую иерархию классов и после разгребает проблемы с видимостью классов, доступа к скрытым инкапсуляцией данным. Таким образом, можно выделить один недостаток объектно-ориентированных языков программирования – избыточность их средств при решении большинства простых задач. Нужно помнить, что применение ООП это прежде всего моделирование. Для построения хорошей, легко читаемой и сопровождаемой программы необходимо в самом начале разработки предусмотреть сценарии её использования и, что очень важно, изменения – заказчик легко в корне может поменять задачу. Это нетривиальный процесс, в котором часто задействуются даже отдельные языки моделирования. Не каждый способен выделить отдельные сущности и сделать их классами. Ещё меньше людей способны адекватно распределить функции, работающие с данными программы в методы и упаковать их в классы. Для этого нужно уметь мыслить объектно-ориентированными категориями. На всё это уходит драгоценное время. Оно обязательно окупится, если программист имеет дело с большим и сложным проектом, но вряд ли в других случаях, когда требуется просто решить задачу и перейти к другой. Для меня вывод один, всем известный и общепринятый – не стоит воспринимать парадигмы и языки, их поддерживающие, как божество. Это всего лишь инструмент для решения определенного круга задач. Я думаю, что для объектно-ориентированных языков такие задачи начинаются, когда их решение укладывается более чем в тысячу строк и задачи, которые требуют масштабирования. “Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп
0
|
16.05.2014, 16:35 | |
Ответы с готовыми решениями:
318
Архитектура с толстым клиентом: какие есть недостатки? ООП ради ООП Изучаю Python, сейчас учу основы ООП, где можно найти задачи по ООП Недостатки React |
1195 / 588 / 88
Регистрация: 20.09.2012
Сообщений: 1,881
|
|
12.06.2014, 07:43 | 61 |
Картина Репина "приплыли". ML внезапно стал DSL'ом, LISP на котором Amazon's и Yahoo'и и еще туча приложений написаны перестал быть ЯОН.
Мы говорим что на ООП невозможно создать внутренний вменяемый и читаемый DSL легкий в разработке и поддержке, который существенно упрощает жизнь при проектировании сложных систем. Второе ML гарантирует корректность программы, это львиная доля багов при разработке. Т.о. скорость разработки и надежность на порядок (десятичный) выше чем у всяких там ООП. А что гарантирует ООП кроме тонны кода? Добавлено через 1 минуту Смутные сомнения меня терзают. Вы о ML и Lisp'е знаете только то что в вики написано?
0
|
1824 / 732 / 99
Регистрация: 01.10.2012
Сообщений: 3,744
|
|
12.06.2014, 11:06 | 62 |
Мне кажется Вы в плену красивых идей. Ну покрутитесь Вы годик на хаскелле, обнаружите что работы/проектов "не так уж много", вначале будете вздыхать о "стене непонимания", инерции (и даже тупости), потом перестанете. И перейдете на что-нибудь ходовое, типа плюсы, жаба. Это нормально, через это все проходят. Конечно приятно думать что "я работаю на самом крутом языке!!!" но..
0
|
1195 / 588 / 88
Регистрация: 20.09.2012
Сообщений: 1,881
|
|
12.06.2014, 11:56 | 63 |
Igor3D, у вас все проекты состоят только из одного языка? Мало-мальски крупный проект в среднем использует на менее 5 языков и технологий. Почему весь проект по вашему должен быть только например на хаскеле?
Но в целом показательно, когда предоставить нечего люди обычно с темы съезжают. Т.к. показать, чем ООП круто, не получается, то переключимся на обсуждение проблемы идиотизма HR'ов и MBA'ев. Ну, что вам сказать, некоторые конечно вздыхают, а некоторые берут и делают. Берут erlang и делают WhatApp, Echo, Yandex.Disk и еще кучу полезного софта, до качества которого C++ даже в смелых мечтах не дорастет. А еще берут Scala и Closure вместо жабы, и их популярность только растет. Угадайте почему. А то, что о используемых внутри компаний разработках на незнакомых для вас языках не вопят на каждом углу - это не значит что этого нет в природе. Это нормальная практика. Люди и там просто берут правильный инструмент и делают, а не вздыхают и не жалуются. ЗЫ А вы так и не удосужились хоть что-то прочитать о "моей" "вещи". Ваши "утверждения" как бы наглядно это показывают. Ну что вам сказать в этом случае. В таком случае я думаю вам не стоит жаловаться что вам "ничего взамен не предлагают" и вопрошать где там ошибка "архитектурная ошибка или недостаток/ограничение ООП". Вам похоже новые знания все равно не нужны.
0
|
1824 / 732 / 99
Регистрация: 01.10.2012
Сообщений: 3,744
|
|
12.06.2014, 12:54 | 64 |
Да, почему только не на нем - если он так хорош? Смею предположить что не все он умеет и слабые стороны у него тоже есть. Что нормально для любого языка - достоинства есть продолжение недостатков и наоборот. А Вы взяли сильную сторону и тыкаете ее всем в нос - вот мол, глядите! Это довольно наивная попытка жульничества
Так вот и покажите как с помощью новых прогрессивных технологий разрулить мою проблему наследования. Бегать с учебным примерчиком каждый может, а вот конкретный житейский вопрос - и ответа не видать.
0
|
1195 / 588 / 88
Регистрация: 20.09.2012
Сообщений: 1,881
|
|
12.06.2014, 13:42 | 65 |
От каждого языка (а их несколько) в проекте должны браться сильные стороны. Со своей стороны я сильные показал. Со стороны ООП ничего не увидел - значит ему в проектах места нет.
0
|
4486 / 2721 / 485
Регистрация: 28.04.2012
Сообщений: 8,590
|
||||||
12.06.2014, 20:35 | 66 | |||||
Вот это статистика проекта одной игры под Android/iOS:
1
|
1195 / 588 / 88
Регистрация: 20.09.2012
Сообщений: 1,881
|
|
12.06.2014, 21:44 | 67 |
Как по мне, это несколько перебор, видимо связанный с дикой кросслатформеностью проекта и его богатой историей. Насколько понял из признаний разработчиков в самом проекте используется всего 6 языков. Остальное мишура и тулзы, которые, разумеется, в таком крупном проекте просто обязаны быть. Но в целом впечатляет .
0
|
1824 / 732 / 99
Регистрация: 01.10.2012
Сообщений: 3,744
|
|
13.06.2014, 06:49 | 68 |
Довольно смутно представляю как реализовать такой адаптер(ы) Ну да ладно, главное я услышал - штатных средств/механизмов у Вас нет.
Мое решение: отказался от использования QDialog и реализовал этот ф-ционал сам. Что будет если понадобятся классы унаследованные от QDialog? Таких не нашлось (из более чем 200 окон). Подобным же образом я бы решал Вашу задачу с этажами. Создал бы контейнер "айтемов", определил бы "правила" и включил перебор. Да, будет длинновато и коряво, но будет работать. А ООП это или нет - меня не волнует. Вероятно это вызовет Ваше недоумение (проще говоря "фыркание" ), поэтому я объясню смысл. Решение всегда найдется - практически на любом языке. Оно может быть далеко от совершенства (как в примерах выше), но в проекте оно будет рабочим. И нет никакого смысла привлекать тот же хаскел если задача - всего лишь небольшой эпизод и вес ее в проекте невелик. Может он и лучше, но проще перетерпеть. Др словами то что Вы знаете "нечто крутое" - само по себе ничего не значит. Вы еще найдите проект где Ваша крутизна будет хотя бы "не хуже" - и это совсем непросто, лично я не уверен что задачи "где кто живет" прут мутным потоком До крупного проекта еще надо дожить
0
|
1195 / 588 / 88
Регистрация: 20.09.2012
Сообщений: 1,881
|
|
13.06.2014, 07:28 | 69 |
Если вы не представляете себе такой адаптер, то никогда не сможете построить нормальную архзитектуры проекта (с ООП или без без разницы), ибо это основы.
Штатных средств чего? Исправления маразма проектировщиков либ? Адаптер и есть штатное средство (даже если вам кажется то это не так). А то что для каждого отклонения нужен свой адаптер, так и болезни не лечат одними и теже ми лекарствами. К каждому свой подход. Я даже не знаю. Вы точно из ООПшной пещеры лет десять как не вылазили, поэтому и не уверены. Даже для вас сочетания JVM и Net ничего не значат (где это можно использовать в любом проектеб а многи кто не зациклен на ООП используют), то даже за их пределами кроссплатформеность всяких ML'ов и Erlang'ов в разы выше чем у Цепепей. Добавлено через 37 секунд Я это не понял. Вы в таких не участвовали?
0
|
Заблокирован
|
|
27.08.2016, 15:39 | 70 |
Вот что думает по поводу ООП и С++ создатель языка С++ Бьярн Страусструп
HACKNET REVIEW 01/98
Интервью Bjarne Stroustrup, данное 1 января 1998 года для журнала Computer. © 1998, Computer перевод: Mike Bluesman Первого Января 1998 года Bjarne Stroustrup давал интервью журналу 'Computer'. Вообще-то редакторы предполагали, что он расскажет о семи годах объектно-ориентированного программирования с применением языка, который он и разработал. К окончанию беседы выяснилось, что интервьюер извлек больше информации, чем предполагал, и, естественно, редакторы решили урезать содержание 'для пользы индустрии', но, как обычно получается в таких случаях, произошла утечка информации. Вот полный и нередактированный протокол интервью - это не похоже на обычные запланированные вопросы/ответы. Вам наверняка покажется это интересным. Интервьюер - далее И., Stroustrup - далее C.. И. Прошло несколько лет с тех пор, как Вы изменили мир разработки программного обеспечения. Что Вы теперь чувствуете, оглядываясь назад? C. Вообще-то я думал об этих днях как раз перед тем как Вы приехали. Помните - все писали свои версии 'C', и проблема была в том, что все это делали чертовски замечательно. Университеты тоже чертовски замечательно преподавали этот язык. Это привело к понижению компетенции. Под 'компетенцией' в данном случае я подразумеваю феноменальность. Вот что породило проблему. И. Проблему? C. Да, проблему. Помните когда все писали на Cobol? И. Конечно, я тоже это делал. C. Ну вот, в начале эти ребята были как боги. Им платили кучу денег и относились как к королям. И. Да уж, вот это были времена... С. Именно. Ну и что же случилось? IBM прямо заболела этим и вложила миллионы в подготовку программистов, пока их не стало до ужаса много. И. Вот так и я вылетел из этой сферы. Втечение года зарплата упала настолько, что даже журналистом можно было зарабатывать больше... С. Точно. То же самое случилось и с программистами, писавшими на 'C'. И. Понятно, ну и что же Вы все-таки хотите этим всем сказать? C. Однажды я сидел у себя в оффисе, и мне пришла в голову небольшая идейка, как хоть немного восстановить баланс. Я подумал: интересно, что произойдет, если будет язык программирования такой запутанный и такой сложный для изучения, что никто бы уже не сможет заполнить рынок толпой программистов, пишуших на этом нем? У меня уже были тогда кое-какие мысли по этому поводу. Вот, знаете наверно, X10 и X windows. Это тогда была такая графическая система, которая работала на Sun 3/60. У нее были все ингредиенты, которые мне были нужны - комплексный синтаксис, сложные для понимания мрачные функции, псевдо объектно-ориентированная структура. Даже сейчас никто не пишет напрямую под X-windows. Motif - единственный путь, если вы хотите сохранить рассудок. И. Шутите? C. Ничуть. Есть еще одна проблема. Unix был написан на 'C' - это значило то, что любой программист, пишущий на 'C', мог очень легко стать системным программистом. Помните сколько обычно зарабатывали большинство системных программистов? И. Да, я же ведь тоже этим занимался. С. Так вот, этот новый язык должен был отделять себя от Unix путем скрывания всех системных вызовов, которые так здорово связывают 'C' и Unix. Тогда ребята, знающие только DOS, тоже смогли бы прилично зарабатывать. И. Не верится в то, что Вы это сказали... С. Это уже происходит достаточно долго, но вроде сейчас большинство людей уже уяснили для себя, что C++ - это пустая трата времени, но должен сказать, что осознание этого происходило дольше чем я ожидал. И. Ну расскажите поточнее, как же Вы все-таки сделали это? C. Это была просто шутка, я никогда не думал, что люди воспримут эту книгу всерьез. Любой человек, даже с половиной мозга, может понять что объектно-ориентированное программирование интуитивно, нелогично и неэффективно. И. Что? С. И относительно 'повторно-используемого кода' - Вы когда-нибудь слышали, чтобы хоть одна компания 'повторно-использовала' что-либо? И. Ну, вообще-то не слышал, но... С. Вот так-то. Некоторые, кстати, пытались. Была такая компания из Орегона - Mentor Graphics, в которой просто заболели тем, что пытались переписать все что можно на C++ в '90 или '91 году. Я на самом деле им сочувствовал, но думаю, что люди по крайней мере, научились чему-то на их ошибках. И. Очевидно у них ничего не вышло? С. Вообще ничего. Но было бы сложно объяснить держателям акций компании ущерб в 30 миллионов долларов и вот, надо отдать им должное , они все-таки заставили это работать в итоге. И. Так все-таки у них получилось? Это доказывает что 'объектное-ориентирование' работает. C. Почти. Запускаемый файл получился такой огромный, что загружался 5 минут на рабочей станции HP со 128Mb оперативной памяти. Я думал, что это станет камнем преткновения, но это никого особенно не заботило. Sun и HP были очень рады продавать до ненормальности мощные ящики с огромными ресурсами для выполнения на них тривиальных программ. Знаете, когда мы в AT&T откомпилировали нашим первым компилятором C++ программку 'Hello World', я не мог поверить своим глазам: запускаемый файл получился размером 2.1Mb. И. Да уж... Но компиляторы с тех пор прошли долгий путь. C. Вы так думаете? Попробуйте тот же пример 'Hello World' с последней версией g++ - вы получите примерно пол-мегабайта. А кроме этого есть еще множество примеров со всего мира. У British Telecom чуть было не возникли большие проблемы, но к своему счастью они вовремя догадались свернуть проект и начать все заново. И им больше повезло, чем Australian Telecom. А теперь я слышал, что Siemens cоздает какого-то динозавра и все больше и больше волнуется по поводу размера того, что у них получается. Не правда ли забавно смотреть на это всеобщее заблуждение? И. Да, но C++ -то, в общем, вполне нормальный язык. С. Вы в это так верите? Попробовали ли вы когда-нибудь сесть и поработать над проектом на C++ ? Во первых, я расставил достаточно ловушек, чтобы просто так работали только тривиальные проекты. Под конец проекта получается что одни и те же операторы в разных модулях означают совершенно разные вещи. А теперь попробуйте соединить все эти модули в единое целое, особенно если у вас их штук 100. Боже, я иногда не могу удержаться от смеха, когда слышу о проблемах разных компаний, которые не могут сделать так, чтобы их модули общались между собой. И. Я должен сказать, что совершенно сбит с толку всем что Вы сказали. Вы сказали что сделали это для того, чтоб повысилась оплата труда программистов. Но это же бессмыслица. С. Не совсем так. У каждого есть его выбор. Я не предполагал, что все это так выйдет из-под контроля. Но все-равно, практически все у меня получилось. C++ cейчас уже умирает, а труд програмистов продолжает нормально оплачиваться - особенно тех, кто имеет дело со всей этой чепухой - вы же понимаете, что невозможно использовать эффективно большой программный модуль на C++ , если не вы сами его написали. И. Как это? С. Не понятно что-ли? Помните typedef ? И. Конечно. С. А теперь вспомните сколько времени приходится копаться в заголовках для того, например, чтобы просто найти, что какое-нибудь там 'RoofRaised' - число с двойной точностью. Представьте теперь сколько времени уйдет на нахождение всех определений типов в большом проекте. И. Значит, Вы утверждаете, что Вам все, что Вы хотели удалось... C. Ну, вспомните сколько занимает реализация проекта среднего размера на 'C'. Это около 6 месяцев. Не достаточно долго чтобы парень с женой и детьми мог заработать себе на нормальное существование. Попробуйте тот же проект реализовать на C++ , и что получится? Вам понадобится 1-2 года. Не правда ли, это замечательно? Кроме этого: в университетах уже так давно не преподают 'C', что теперь стало мало людей программирующих на 'C', особенно таких, которые знают все о программировании под Unix. Как вы думаете : сколько парней смогут сообразить что делать с 'malloc' , после того как втечение многих лет они пользовались 'new' и никогда не заботились о проверке кода возврата? Большинство программистов на C++ вообще не выбрасывают этот код возврата. Что произошло со старой доброй '-1' ? По крайней мере было сразу понятно, что у тебя где-то ошибка без всяких там 'throw', 'try' и 'catch'... И. И все же, наследование экономит кучу времени? С. Нет, я же говорил... Замечали, в чем разница между стадиями планирования проектов на 'C' и C++ ? Для проекта на C++ эта стадия в три раза дольше. Время уходит на то, чтоб убедиться что все что надо наследуется, а все что не надо - нет. И все-равно без ошибок не обходится. Кто слышал когда-нибудь об утечке памяти в программе на 'C' ? Теперь нахождение этих утечек - целый труд. Большинство компаний сдаются, так и выпускают продукт, зная что утечка памяти существует. И. Но есть различные программные инструменты... С. Большинство из которых написаны на C++. И. Если мы опубликуем все это, то Вас просто могут линчевать, понимаете ? C. Сомневаюсь. Как я сказал C++ уже уходит в прошлое. Ни одна компания без предварительного тестирования теперь не начнет проект на C++, а если будет тестирование, то они поймут, что это путь к неудаче. Если не поймут - то так им и надо. Знаете, я пытался убедить Dennis'a Ritchie переписать Unix на C++. И. О Боже. И что же он сказал? C. К счастью у него присутствует хорошее чувство юмора. Я думаю и он, и Brian понимали что я тогда делал. Он ответил, что может мне помочь написать версию DOS на C++, если я захочу. И. Ну и как? Вы захотели? С. Я написал DOS на C++. Могу дать вам demo. Она у меня работает на Sparc 20 в другой комнате. Просто летает на четырех процессорах и занимает всего то 70 мегабайт на диске. И. На что же это похоже на PC ? С. Вы, очевидно, шутите. Видели же вы Windows'95 ? Я о них думаю как о своем величайшем успехе. И. Знаете, эта идея насчет Unix++ заставила меня задуматься. Ведь где-то может сидеть парень, которому придет в голову сделать это... С. Но не после того, как он прочитает это интервью. И. Я сожалею, но врядли мы сможем опубликовать даже часть этого интервью. С. Но это же история века. Я просто хотел чтоб мои приятели-программисты помнили меня за то, что я для них сделал. Знаете как сейчас оплачивается программирование на C++ ? И. Последнее, что я слышал - настоящие профессионалы зарабатывают $70-80 в час. С. Понимаете теперь? И я уверен, что он заслуживает этих денег. Отслеживание всех этих ловушек, которые я встроил в C++ - не легкая работа. И, как я говорил раньше, каждый программист на C++ чувствует себя связанным тем обстоятельством что он должен использовать каждый элемент языка в каждом проекте. Вообще это и меня часто раздражает, даже тогда, когда это служит моим целям. Но сейчас, когда прошло столько времени, мне уже начинает нравиться этот язык... И. Имеете ввиду, что раньше Вам C++ не нравился? С. Ненавидел его. Он даже выглядит неуклюже, вы не согласны? Но когда стали там выходить разные книги... вот, тогда-то я и увидел полную картину. И. Погодите, а как насчет ссылок? Вы подтверждаете что улучшили указатели 'C' ? С. Хмм. Я и сам не знаю. Вообще я думал, что да. Потом я как-то говорил с парнем, который писал на C++ с самого начала. Он говорил, что не мог запомнить были ли ссылки на его переменные или нет, поэтому он всегда использовал указатели. И. Обычно на этой стадии я говорю 'большое спасибо за интервью', но сейчас это как-то не к месту. С. Пообещайте мне, что опубликуете это. И. Я извещу Вас, но мне кажется, что я знаю, что скажет мой редактор по этому поводу. С. А все-равно, кто этому поверит? Кстати, не могли бы вы мне прислать копию этой записи? И. Это я могу. Примечание переводчика : Я не программирую на C++. Я не являюсь знатоком русской словестности. Посему прошу извинения за возможные ошибки в переводе. специальный перевод для Hacknet Review выполнил Mike Bluesman, март 1998 ©
1
|
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
|
|
27.08.2016, 18:53 | 71 |
Да, тот, кто это писал, действительно не является
А к чему вы это здесь процитировали, сегодня вроде бы не первое апреля?
0
|
Заблокирован
|
|
27.08.2016, 22:51 | 72 |
0
|
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
|
|
28.08.2016, 00:59 | 73 |
Ну так то, что вы процитировали, это хоть и веселая, но брехня. А тема же не про юмор.
0
|
Модератор
3051 / 2193 / 459
Регистрация: 26.03.2015
Сообщений: 8,469
|
|
28.08.2016, 02:37 | 74 |
Я уже не раз это писал в этом форуме... С++ - это один плохих языков программирования. Его популярность связана исключительно с совместимостью с Си... и это же является одним из главных недостатков С++.
Добавлено через 6 минут На всякий случай... В институте нам преподавали только Фортран. Я изучил С++ самостоятельно и просто тащился от того, насколько этот язык круче. Но позже я узнал, что есть много других языков... По работе мне приходилось решать самые разные задачи и, оглядываясь назад, я могу с уверенностью сказать, что ни для одной из этих задач С++ не был наиболее подходящим языком программирования. Если кто-нибудь мне скажет, для решения каких задач С++ лучше других языков (без учёта легаси кода), я буду очень благодарен. Но пока я считаю, что таких задач просто нет. Даже если взять простую пару Си и Джава - один из этих языков всегда! будет лучше, чем С++ для любой задачи.
0
|
Заблокирован
|
|
28.08.2016, 02:45 | 75 |
Я бы не сказал.
Там многое по делу. Например из первого что пришло в голову про typedef
0
|
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
|
|
28.08.2016, 02:51 | 76 |
0
|
2063 / 1542 / 168
Регистрация: 14.12.2014
Сообщений: 13,402
|
|
28.08.2016, 09:17 | 77 |
Потому что для всяких WhatApp Echo Yandex.Disk большого ума и знаний не надо. Все это системы из серии погоняй "туда- сюда массив и чтобы кнопочки были красивые". По большому счету хеллоуверды массового пользования. И делают их обычно выпускники всяких курсов а то и просто школ которые ни как комп работает особо не представляют ни матан не знают ни даже не задумываются с какой стороны у них rvalue. Для таких людей JS или басик или нечто наподобие фактически пропуск в сферу кодинга и называются они кодеры. И С++ их затопчет сразу и насмерть. Это язык профессиональных программистов. А ООП парадигма профессиональных аналитиков. И этих программистов-аналитиков со знаниями кучи математики физики и т.д. слишком сильно нехватает в делах разработки систем промышленной автоматики, ракетно-космической и авиацинной отрасли, робототехники, разработки промышленных CAD и прочего математически нагруженного софта чтобы они еще и web-хелоувердами занимались. При этом потребности индустрии растут быстрее чем успевают готовить специалистов. К примеру квота на прием программистов из стран xUSSR в США в два раза превосходит количество дипломов выдаваемых в год в этих странах.
Добавлено через 2 часа 22 минуты Несколько месяцев назад софт на C++ вывел в космос двухступенчатую ракету Falcon-9. После чего свел ее с орбиты и успешно посадил обе ступени на необитаемый плавучий космодром. после чего самостоятельно привел космодром в порт. Scala и Closure и жабе со всеми ерлангами вместе взятыми о таком точно не мечтать.
0
|
Модератор
3051 / 2193 / 459
Регистрация: 26.03.2015
Сообщений: 8,469
|
||||||
28.08.2016, 20:50 | 78 | |||||
Абстрактные Типы Данных (АТД) есть во многих языках программирования, включая функциональные. В объектно-ориентированных языках добавлена возможность описывать новые АТД путём добавления полей/методов в ранее описанные АТД (то есть, добавлено Наследование).
Если не злоупотреблять этой новой возможностью, то программа, написанная на объектно-ориентированном языке, будет, как минимум не хуже. С С++ отдельная песня. Этот язык просто перегружен возможностями. Многие из этих возможностей реально не нужны, а некоторые даже мешают. Многие программисты не могут удержаться от использования этих возможностей или не знают, как это делать. Из-за этого программы могут получаться плохо читаемыми. Кликните здесь для просмотра всего текста
Например, мне сложно понять (не запуская), что делает эта программа:
0
|
2063 / 1542 / 168
Регистрация: 14.12.2014
Сообщений: 13,402
|
|
29.08.2016, 06:11 | 79 |
Задача простая. Есть древовидная структура объектов с паритетными связями (Ну к примеру чертеж). в ней есть объект на который есть куча ссылок (например точка). Пользователь нажал кнопку оную точку удалить. Как будете на джаве задачу решать?
Добавлено через 1 минуту К примеру задач имитационного моделирования. У Си для этого нет классов (в ручную их городить прийдете в конечном итоге к С++) у Джавы автоматический мусоросборник во многом мешать будет
0
|
Модератор
3051 / 2193 / 459
Регистрация: 26.03.2015
Сообщений: 8,469
|
|
29.08.2016, 17:06 | 80 |
Не хватает информации, чтобы ответить точнее, но, вероятно, решение в том, чтобы использовать более подходящую структуру данных.
Чем будет мешать мусоросборник? Не будет ли отсутствие автоматической сборки мусора в С++ мешать ещё больше, чем его наличие в Джава?
0
|
29.08.2016, 17:06 | |
29.08.2016, 17:06 | |
Помогаю со студенческими работами здесь
80
Укажите на недостатки Недостатки AnyLogic Какие недостатки недостатки системы Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |