Беседка для программистов, или «Бутерброд с кодом»

Конечно. Это разные пути. Например, на пути "обрезать все лишнее" очень часто наблюдаешь, что очень полезная и красиво написанная библиотека оказывается не нужна просто потому, что не нужен кусок, который к ней обращался. И наоборот.

Брукс. Мифический человекомесяц. конкретный кусок

При этом они должны были бы лишиться свойств отношений, чего не происходит. Так что видим обратное: соединение под надстройкой как базиса, так и псевдо-базиса - целиком паразитной части "отношений", притворяющихся "силами".

Пардон. http://www.gudleifr.h1.ru/c84.html

 

Ну дык и переходный процесс же ж ещё не закончен.
К тому же у слова "постиндустриал" есть и "западный" смысл - когда на заводе зарплата у бухгалтеров на два порядка больше чем у цеховых инженеров и сидят они на другом конце планеты... :-( Это тоже нехило морочит голову.

А-аа, так это ж классика - стахановская бригада. Радикально растёт производительность труда, факт. Но углубляется его разделение - а тут и до райкинского "радуйтесь что вам гульфик не пришили" недалеко. :-(

 

Дык, бухгалтера никогда и не входили в производительные силы. Еще в 1500-лохматые годы Лука Пачоли признавался, что сию науку придумали того, чтобы дурить проверяющих.

Когда американцы продували космическую гонку, они много чего у нас потянули: и плановое ведение хозяйство, и социалистическое соревнование. Есть по этому поводу интересный сборник переводных статей "Наука - техника - управления" 1966 года.

Это уже модный перегиб, когда бывший строй ругают за действия его врагов.

 

Во! И переход от капитализма к социализму в начале 60-х в NASA оказался вполне себе обратимым в начале 70-х: МТБ-то одна и та же - индустриал, радикальному скачку производительности труда (как было при переходе от кустарного способа производства к индустриалу) взяться неоткуда. :-( А МТБ коммунизма - собственно постиндустриал - все государства давили с более-менее постоянными усилиями с конца 20-х (из наиболее известных "наших" - макаренковские коммуны, Болшевская; из менее - общество радиолюбителей: в ЕМНИП 1927-м "поворот все вдруг" от пропаганды полноценной радиосвязи до установки рогаток на пути желающих заняться радио) до аж 80-х (НПО "Факел", Новосибирск; из "ихних" - Джонстаун) и таки задавили. :-(
Про это хорошо пишет Павел Кучер с Самиздата (рекомендую его последний роман "Деревянный хлеб"). И, кстати, есть такой Александр Лазаревич aka Selenit57, тоже рекомендую.

Я в курсе. Но вся эта фигня с "хозрасчётом" же ж подавалась как чуть ли не переход к коммунизму! Хотя на самом деле тешила только древние обезьяньи инстинкты участников. :-(

 

Рыжий Тигра, еще порекомендую: Бир "Мозг фирмы". Там хорошо расписано, как задавили кибернетический эксперимент в Чили. Понимание того, что "хорошая машина вполне заменяет среднего управленца" американцам была страшнее коммунистов.

 

Для этого есть Java. Есть пустить эту рабсилу в C++, получается тотальный кирдык. Потому что будь ты хоть тыщу раз дебил - чужую память в Java не испоритишь, и даже полноценный memory leak создать труднее. А в C++ - запросто.

---------- Сообщение добавлено в 17:54 ---------- Предыдущее сообщение размещено в 17:42 ----------

А вот нет. Предупреждения в C говорят то же самое, и если их не игнорировать, результат получается надежнее. В C++ ошибки могут быть запрятаны раз так в 10 глубже, чем в C, ввиду наличия шаблонов, наследования (множественного и виртуального), исключений, конструкторов-деструкторов, перегрузки функций и операторов. В C++ банально крайне трудно проследить последовательность исполнения ошибочного кода, потому что благодаря всем этим конструкциям он превращается в многомерные макароны. Ты смотришь на код и не можешь понять, что происходит. В строчке из нескольких идентификаторов и операторов может происходить множество выделений памяти, вызовов конструкторов и деструкторов, скрытых преобразований типов, выбор между перегруженными функциями на основе результатов этих преобразований итд. Чтобы достигнуть хоть немного близкой запутанности в С нужно очень долго и цинично злоупотреблять макросами разве что.
Многие убежденные сишники все равно пишут на плюсах, и даже неплохо их знают, но, тем не менее, пользуются его возможностями как сапер ходит по минному полю.

 

Thnx, гляну.

Ну. :-( Cледующая ступень деградации после C++. (Ещё более глубокой собирался стать Delphi (австралийцы в конце 90-х уже носились с идеей переучить всех токарей на дельфинистов), но к счастью не срослось - только надолго ли? )

Ха. Вспомни анекдот про нового русского - про "жми ОК, но не сразу". И ткни пальцем в ламера, "не игнорирующего" warning'и именно с т.з. собственной крутизны. :-(

Гы. Вылитый я. :-))))))))

 

Это не деградация, а просто шаг в сторону.

 

В сторону дальнейшей деградации. И С++, и Java, и, тем более Visual-объектные модели (Win API, Qt) - это быдлопонимание ООП.

Имеются ОО библиотеки. В смысле: не "написанные объектно-ориентированно", а "подогнанные под ОО внешний интерфейс". И есть быдлокодерская обвязка этих библиотек в приложениях, которую, и то с натяжкой, можно назвать объектно-ориентированной только в случае строго-ОО-языков (Java, Python). На C++, например, все ООП сводится к использованию class вместо struct. В некоторых ОО-системах даже запрещено самому плодить ОО-сущности - Visual Basic (старые), 1C.

Классическая парадигма ОО - это творение программы сверху вниз (за 7 дней), от общих абстракций к частной реализации (см. Страуструп, Парнас, Элджер). На этом пути, вроде бы, даже ожидаемы какие-то бонусы, которые признавал даже Брукс.

Но, ведь, так никто не пишет - все быдлокодеры быстренько лепят свои (не ОО!) программулины из готового набора ОО-кубиков - снизу вверх. Но, при этом, оправдываются мнением авторитетов, которые, как раз, требовали идти сверху вниз...
Более того, "правильно" строить ОО-приложения сверху вниз в реальной жизни невозможно: никакой рефакторинг не позволяет подправить однажды кем-то созданное дерево классов. Можно только выкинуть и начать заново.

Аналогично выглядит и современное "визуальное программирование". Вместо полезной концепции создания удобного интерфейса для что-то делающей программы, мы имеем концепцию красивого интерфейса, скрывающего неумение программы хоть что-то делать.
Вместо освобождения программиста от заботы о реализации интерфейсов - "программистов", умеющих только рисовать интерфейсы.

Опять все задом-наперед: не интерфейс для программы, а программа для интерфейса.
И опять - идеями, которые не имеют отношения к процессу, оправдывают явную дурость...

Т.е. есть (в теории) идеальные ООП и визуальное программирование и есть их быдлокодерское понимание, ничего общего с ними не имеющее (но позволяющее хоть какую-то практику).

P.S. Когда я в последний раз разводился, мне стало жалко бедную работницу ЗАГС. Ей пришлось пройти через десяток экранов, заполненных жутким количеством органов управления. И на каждом она долго сверяла буквы-цифры, ставила, максимум, одну галочку-циферку и жала "Ок". После чего внесла руками записи в два журнала и паспорта, а я проверил все написанное-напечатанное и раз пять расписался. Вы хотите сказать, что без компьютера было бы сложнее-дольше?

 

Alex Kagansky, Ага, это язык где реально можно с пользой использовать не очень квалифицированных разработчиков и эффективно вести совместную разработку без серьезной боязни, что кто-то обрушит всё нафиг От С++ там унаследованы только фишки, не позволяющие случайно отстрелить себе ногу, то есть довольно мало от общего их количества Простые вещи на Джаве пишутся почти автоматом, с выключенным мозгом, хоть и оказываются по сравнению с Си (а с C++ и подавно) чресчур многословными. Чего стоит только отсутствие unsigned типов и автоматической конверсии enum в int.

---------- Сообщение добавлено в 20:02 ---------- Предыдущее сообщение размещено в 19:57 ----------

Это проблема дизайна UI а не языка программирования. К сожалению, почти каждый программист считает, что он и швец и жнец и на дуде игрец, хотя в каждой области на самом деле нужен специфический опыт и знания. А еще причина банально в том, что такой софт делается для попила денег, а не для повышения эффективности работы итд.
Я когда то в юности кодил софт (С/WinApi) для забивания формочек - у меня плавно автоскроллилось всё на одном экране с автоматическим переходом между полями после ввода информации в каждое. Да и у тетки наверное была возможность использовать Tab/Shift-Tab, если бы ее кто научил.

 

Эта проблема постановки телеги (визуальный редактор) впереди лошади (смысл программы). А C++ это поощряет.
Почему поощряет? Потому, что делать на нем "нормальное ООП" (См. главу " ПРОЕКТИРОВАНИЕ И РАЗВИТИЕ" у Страуструпа) невозможно.

 

gudleifr, C++ мог там рядом не валяться. Визуальные редакторы тут уж тем более не причем. И без них многое делается намного сложнее. Кроме того даже Qt- это уже немного "не тот" C++. Там есть новые возможности, добавляемые препроцессором.
А с основным тезисом - "C++ - не лучший язык для разработки UI" вряд ли кто не согласится. Это звучит примерно так же как "танк - не лучшая машина для поездок на дачу"

 

Почему же? Как раз быдлообвязка симпатичных ОО-библиотек (в т.ч. визуальных) - это его конек. Для чего-то другого этот этот язык непригоден (т.к. хочет идти к наращиванию сложности сразу двумя взаимоисключающими путями - и путем структуризации, и путем проблемно-ориентированного языка).
А в силу его капитуляции перед сложностью, остается только сборка из визуальных кубиков (когда программист практически не пересекает границ обработчиков сообщений).

 

gudleifr, А для меня и для многих других это просто более мощный С для решения тех же задач меньшим количеством кода. А для создания формочек давно уже в фаворе Java, С#. А у Apple Objective C и Swift. Тоже намного лучше плюсов справляются.

 

А ничего, что он менее мощный? И программы на нем намного длиннее C-шных?

 

Я бы не сказал, что Страуструп имеет отношение к классической парадигме ООП, которая возникла за 20 лет до него. Классическая парадигма - это Smalltalk и принцип "все есть объект" (про классы тогда речи не было). Есть объекты, и они могут обмениваться сообщениями. И это все. Остальное все уже потом надумали.

Ну так это и хорошо, что простые вещи делаются просто. Вместо бега по минному полю, усыпанному граблями. unsigned типы это неплохо, но в основном для манипуляций с битами, что не является предназначением жабы. А вот все автоматические конверсии - это однозначно в топку.

---------- Сообщение добавлено в 21:17 ---------- Предыдущее сообщение размещено в 21:17 ----------

Он более мощный.

 

gudleifr, Вы его неправильно готовите По скорости - там компиляторный бэкэнд одинаковый, поэтому если не плодить лишних сущностей (и запретить всякие RTTI с exception-ами), разницы никакой.

---------- Сообщение добавлено в 21:27 ---------- Предыдущее сообщение размещено в 21:20 ----------

Alex Kagansky, Я сюда не наезжать на Джаву пришел. Это - язык для решения своей, довольно широкой, группы задач, Хотя не мог не заметить, что совершенно простые и короткие для C задачи (сформировать сетевое сообщение на основе int-ов и enum-ов своей объектной модели) на джаве вырастают в разы (например, каждый enum надо учить конвертироваться в int итд). А траблы с конверсией типов там тем не менее есть, сам находил чужие баги, где char конвертироался в int, хотя вызывавший думал, что есть перегруженная функция берущая char итд. А сколько палок в колеса производительности вставляет Garbage Collector - вообще грустная тема.
Низкая выразительная способность Джавы (например, отсутствие полноценной альтернативы макросам + темплейтам) - это не только плюс (код меньше похож на паззл, проще разобраться), но и минус (чрезмерная многословность, некоторые проблемы решаемы только копипастой, а копипаста - это бич сопровождаемости)

 

Ну так и обратное заявление тоже верно - простые и короткие для жабы задачи на Ц вырастают в разы - ну там, создание иерархии объектов с виртуальными методами.

 

Не надо ставить с ног на голову. Из того, что Страуструп не изобретал ООП, не следует, что он не пытался следовать его парадигме (создавая C++).

Не-а.
nop, смотрите проще. Чем C++ отличается от C? Усилением средств типизации и средствами построения проблемно-ориентированных языков. Причем одно идеально нейтрализует пользу от другого. Т.е. С++ может тоже, что и C, только имеет эти два неработающих "довесочка". Следовательно, он сложнее в использовании. А т.к. сложность определяет границы наших возможностей, то у него они ниже.

 

А часто бывают задачи, поставленные именно так: "создать иерархию объектов с виртуальными методами"?
Кстати, повторить это дело сишными указателями на функции в принципе несложно, и наследовать даже, только, конечно, язык не будет скрывать реализацию и будут видны неприглядные потроха.
Но я считаю - если уж приперло все это устраивать - бери плюсы, только осторожно