Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>А уж те, что исходники USER видели, с патчами "А вот тут затычка, потому что в PowerPoint квадратик рисуется неправильно", "а вот тут придется развести немножко грязюки, чтобы ПаэурБилдер и написанные на нем программы правильно работали", с именами функций типа zzzDesktopThread() и доведенной до маразма венгерской нотацией — эти и вовсе чудеса рассказывают.
Вот, кстати, свежая статья с несколькими примерами на эту тему. Особенно мне понравилось про SimCity
Неужели правда?
Здравствуйте, VladD2, Вы писали:
VD>Пойми если рефлекшен есть, то он есть. Сделай превую компиляцию, получи мета-информацию, прочти ее и сгенери код сериализации.
Класс.
Интересно, сколько мне ещё учиться, чтобы понять эту фразу?
Здравствуйте, Шахтер, Вы писали:
Ш>К сожалению, эффект наблюдал только один раз. Так что насчет повторить -- не знаю как. Вылетело, когда я закрывал Янус.
Ну, ты хоть опиши конфигурацию системы, расскажи как дело было...
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
MSS>Ни программы на Java, ни на C# -- по 100 разных причин -- не работают и никогда не будут работать столь быстро, как на Си. Ну язык левой ногой задизайнен, что тут сделаешь, -- разработчики компиляторов не винованы, что создатели Жабы были в языках программирования и компиляторах ни уха ни рыла, посему там грабли разложены очень ровным слоем просто везде. Жаба, господа, это просто атас, а реализация ВМ (виртуальной машины) Саном -- это песня. Смотришь, и сразу понятно, -- ребята делают первую в их жизни ВМ. Ляп тут, ляп здесь, засада за углом, обломс там... Скажем все дружное спасибо фирме Сан, которая вбахала в пропаганду и распространие этого убожества несколько миллиардов баксов и таки добилась своего.
Ню-ню.
Java — это философия, резко отличающаяся от остальных парадигм программных систем.
И она стала распространённой от серверов уровня предприятия до сотовых телефонов.
Везде. Абсолютно.
Если Вы лично её не используете — это Ваше личное дело, никто, кроме маркетинга, Вам ничего не навязывает.
Почему "Ляп тут, ляп здесь, засада за углом"? Да потому что Вы лично не привыкли к иному видению "мира" и остаётесь на том уровне, на котором Вам удобно воспринимать окружающее.
MSS>Кроме того, есть еще один очень существенный момент. Собственно написание кода -- это мелочи. Это 5-10% времени и стоимости разработки. Сотни миллиарды долларов и миллионы человеко-лет (без преувеличения), как в трубу, вылетают на поддержание (тестирование, правку багов и проч) софта. Вот это и есть настоящая проблема. Да еще программисты наповадились с места на место бегать каждые 2-4 года, -- только человек освоится и годик поработает продуктивно, -- глядишь, он уже опять в лес намыливается...
Мир всегда был изменчивым, а Вы — нет.
MSS>И вот тут возникает интересная проблема. В связи с высокой текучестью кадров и большой сложностью реальных проектов читаемость и модифицируемость кода приобретает первостепенное значение. Чтобы код был читаем и легко модифицируем, крайне желательно, чтобы он был локально понятен. Так, чтобы новый человек, посмотрев на процедуру, смог достаточно быстро понять, что она делает и как.
JavaDOC и комментарии в обычных языках ничего не дают?
MSS>И вот тут начинается веселье с конструкторами, деструкторами, виртуальными функциями, наследованием, исключительными ситуациями и проч.
Веселье начинается тогда, когда человек, приступающий к "разборкам" чужого кода, начинает чувствовать свою неспособность объять необъятное. Ему поможет лишь здравый смысл и диаграммы из разных уровней абстрагирования.
MSS>Ну скажите мне, часто ли в Си встречаются указатели на функции? -- исключительно редко, и только по делу. Поэтому, увидев вызов функции в Си, как правило сразу понятно, какая именно функция вызвалась, можно сходить и посмотреть, что она делает.
В ОО-же языках, где народ (в особенности вчерашние студенты) любят, ой как любят переоперделять функции, хрен поймешь, какой из 15 виртуальных методов будет вызван в данном контексте, и читать текст их всех дело утомительное. В результате починка бага занимает в 3-5 раз больше времени.
CodeExplorer Вам в помощь.
MSS>Перейдем к деструкторам и конструкторам. Видит программист описание локальной переменной, которая нигде не используется, и, ничтоже сумняшеся, херит его. Программа перестает работать. Что за бред? -- оказывается, конструктор этой переменной устанавливает связь с Exchange'ем (реальный пример из Аутлука). Конечно, за такие фокусы (я имею в виду создание такого конструктора) нужно увольнять, но -- что написано пером, не вырубишь топором. MSS>В результате программист (по-хорошему) вынужден прочитать описания всех конструкторов и деструкторов по всей цепочке наследования всех локальных cтруктурных переменных процедуры. Кому хочется шариться по 40 файлам, чтобы понять, что делается в процедуре? — да никому. Никто этого и не делает, в результате через 3 года в программе, лихо написанной на ОО языке, не разберется никто.
Да нельзя делать иерархическую цепочку (ветвь наследования) слишком длинной! Это нецелесообразно в любых ООП-языках.
А так, лучше использовать UML-инструментарий — понятнее будет.
MSS>Посему, как показывает мой личный опыт, надежность программ, размашисто написанных на ОО языках, оставляет желать лучшего (конечно, если менеджер следит за тем, как пишут код и за творческое использование языка программирования немедленно дает по ушам, то дело, конечно, другое. К сожалению, грязного кода на ОО языках я видел на порядок больше).
Надёжность программ оставалась и всегда будет оставаться в головах разработчиков, а не в парадигме ООП.
MSS>Я уже не говорю про перекрытие операторов, конструкторов копирования и проч. Творческое пользование темплейтами также сможет доставить потомкам немало приятных минут. А чего стоят исключительные события?
К сожалению, в ООП слишком много парадигм, например, шаблоны (template), от чег весь вой: с одной стороны это экономит силы и время, с другой стороны ведёт к двусмысленности(n-смысленности) толкований сторонними кодерами.
MSS>Почему-то получается, что код, написанный на языке программирования без скрытого поведения, поддерживать и сопровождать гораздо легче. Просто уже потому, что вероятность наступить на грабли меньше. Описана переменная -- можно быть уверенным, что ничего больше это не означает. Вышли из блока -- значит, вышли, и нечего кроме. Что написано, то и происходит. Когда же программа начинает напоминать сводку новостей времен СССР и приходится докапываться до третьего слоя истины -- это бардак. К сожалению, на ОО языках наломать дров проще простого, что мы и наблюдаем изо дня в день.
Интерфейсы и семантика использования — основные факторы, которые нужно донести до сторонних кодеров. Всё!
MSS>Как это ни удивительно, при промышленном программировании залогом хорошего здоровья является простота. Чем проще, тем лучше. Код должен быть понятен олигофрену, иначе человек, который заменит Вас через 2-4 года, не справится.
Пять баллов! (Полностью согласен)
MSS>Хотите проинициализировать переменную? -- вызовите процедуру. Надо вызвать функцию? -- зовите ее напрямую. Не надо вот этого -- посылания сообщения в Жаба-скрипт, который исполнит XML (взяв его из Registry), который запустит ActiveX контрол, который и сделает, что надо, позвав вашу процедуру через COM-интерфейс (Вы смеетесь? -- зря. Я именно такой код чинил год назад. Очень надеюсь, что создатель этого маразма больше в МС не работает).
По-хорошему сочувствую Вам.
MSS>Связная тема -- сложность языка программирования. Стардарт языка Си -- 200 страниц. Си++ -- почти 1000 (и достаточно много отдано на волю разработчика компилятора). Та отписка, которая должна подразумевать собой описание семантики Жабы, -- это просто смех.
Pascal — 50 страниц;
Modula-2 — 40 страниц;
Oberon — 16 страниц.
(c) Н. Вирт
Java — ~100 страниц (по-моему мнению, библиотеки не считаем)
MSS>Ее авторы скромно обошли молчанием самые интересные и интригующие моменты (ну, все те, где грабли лежат) -- которые и вызывают самый искренний интерес у разработчика компилятора, -- видимо, справедливо полагая, что как ни сделаешь, хуже уже не будет.
Грабли в Java? Где?
Лично я в 1998г. столкнулся с непониманием семантики организации кода (пакеты), а дальше — легко.
MSS>Очевидно, что чем проще язык программирования, тем трудней сделать на нем семантическую ошибку. Если достаточно полное и предельно краткое описание языка занимает более 1000 страниц, можно ли ожидать, что рядовой программист будет знаком хотя бы с 50% особенностей языка? -- навряд ли. Тогда откуда может быть уверенность, что достаточно навороченная конструкция представляет собой именно то, что хотел сказать программист?
"Навороченные конструкции" — это шедевры из области C/C++.
MSS>Далее. Стандартные библиотеки. Опять же, с точки зрения промышленного программирования, — чем проще, тем лучше. Если в стандартной библиотеке (к тому же динамически подгружаемоей) есть баг, то это беда. Если программисты его не нашли -- значит, найдут пользователи. Если нашли и обошли, то проблемы начнутся после того, как пользователь обновит библиотеки и в новой версии баг будет починен (а все ведь под него проточено, не так ли?). Наконец, необходимым требованием является 100% backward compatibility библиотек. Ну скажите мне, хоть одна библиотека для Жабы удовлетворяет этому требованию? А есть ли там хоть одна процедура без какого-либо ляпа? Я уже не говорю о том, что на изучение этих библиотек может уйти полжизни.
На изучение Win32 API может уйти вся жизнь. И только небольшая чать документирована в MSDN на нескольких CD.
Что Вы хотите от библиотек Java, которые занимают объём, равный Windows 95 OSR2 (если не Win98)? По-моему, тот кто занимается узкой областью, тот использует узкие аспекты библиотеки, знает, где что закопано и не фырчит, так как это отраслевой стандарт.
MSS>Опять же, смежная проблема. Возраст языка. Чем старше язык, тем лучше и глубже его знают программисты. Что касается Си, то всем известно, что можно делать, чего нельзя, а что можно, но лучше не нужно. С новомодными языками дело обстоит сложней, и опыт, равно как устав караульной службы, пишется кровью [программистов]. Наконец, не следует забывать, что разработчики компиляторов тоже не боги и могут ошибаться, посему вероятность обнаружить ошибку в компиляторе с Си гораздо ниже, чем в компиляторе с Си++ (чтобы найти баги в компиляторе с Жабы, в особенности Сановском, напрягаться не нужно, -- баги Вас сами найдут).
Первый раз слышу о багах в компиляторе Java.
MSS>Резюмирую. При создании операционных систем и большинства других серьезных проектов предъявляются очень жесткие требования к производительности и надежности.
Требования-то предъявляются, а вот исполняются ли, по-хорошему?
MSS>Первое существенно зависит от языка программирования. Второе зависит от как от тестирования, так и от дисциплины программирования и читаемости/модифицируемости кода, которые также достаточно сильно связаны с языком. MSS>Если внимательно посмотреть, то все хорошие серьезные программы на Си с примесью ассемблера. Ворд. Эксель. Ядро НТ. Ядро Линукса. Кодогенераторы (VC, GNU, etc. Гнусный кодогенератор, конечно, никуда не годится, но про удачном расположении звезд может и правильный код породить). Единственная хорошая программа, написанная на Си++, знакомая мне, -- это MS SQL сервер.
)
Насмешили. Сколькл багов и дыр нашли в MSSQL сервер, знаете? Спец.вирусы уже пишут...
MSS>Посмотрим же теперь на софт, написанный на Си++. Exchange Server. Outlook. PowerPoint. WMP. Нужны комментарии?
...Windows.
Самая небезопасная ОС в мире.
MSS>Конечно, все вышесказанное относится к большим промышленным проектам, где объем кода измеряется миллионами и десятками миллионов строк и над которым работает хотя бы человек 50. К софту класса "t.c" длиной в 100 строк это не относится -- это можно писать на любом языке программирования.
???
MSS>пи-эс. Я тут много пинал Жабу и мало -- C#. Однако, учитывая вышесказанное и тонкую связь, имеющую место быть между этими двумя языками, полагаю, что есть основания считать, что и проблемы у них будут достаточно общими. Хрен, он ведь редьки не слаще.
Проблемы будут везде!
Независимо от того, на чём можно писать "Hello World!".
Люди — вот главные баги.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Шахтер, Вы писали:
Ш>>К сожалению, эффект наблюдал только один раз. Так что насчет повторить -- не знаю как. Вылетело, когда я закрывал Янус.
VD>Ну, ты хоть опиши конфигурацию системы, расскажи как дело было...
Система -- XP Home Edition. .Net Framework 1.1 , Pentium-M 1.5 Г 256 М ОЗУ. Дело было -- закрываю Янус, винт шуршит, как обычно, вылетает окошко. Вообщем, очнулся -- гипс.
Здравствуйте, iZEN, Вы писали:
ZEN>На изучение Win32 API может уйти вся жизнь. И только небольшая чать документирована в MSDN на нескольких CD.
ну-ну, таки большая часть документирована в MSDN, а про оставшееся написаны книги а-ля "Недокументированые возможности windows nt"
ZEN>...Windows. ZEN>Самая небезопасная ОС в мире.
Здравствуйте, Шахтер, Вы писали:
Ш>Система -- XP Home Edition. .Net Framework 1.1 , Pentium-M 1.5 Г 256 М ОЗУ. Дело было -- закрываю Янус, винт шуршит, как обычно, вылетает окошко. Вообщем, очнулся -- гипс.
Очунь уж н экспишное окошко.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, iZEN, Вы писали: ZEN>К сожалению, в ООП слишком много парадигм, например, шаблоны (template), от чег весь вой: с одной стороны это экономит силы и время, с другой стороны ведёт к двусмысленности(n-смысленности) толкований сторонними кодерами.
В ООП нет никаких шаблонов. Эта парадигма никакого отношения к ООП не имеет.
... << RSDN@Home 1.1.4 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Полная фигня. Энумы никак (семантически) не соотвествуют С-шным. В С энумы ни чем от констант не отличаются. Тут же это разумный тип.
Не совсем. В IL-коде вместо енума фигурирует его underlying тип. Сам enum это честный класс (ссылочный!), наследник System.Enum — обертка для работы с метаданными.
Здравствуйте, Maxim S. Shatskih, Вы писали:
>>У МС же тогда это был натуральный комплекс неполноценности.
MSS>Факт.
MSS>Я еще когда молодой был, в 95ом году, слышал от своего тогдашего шефа (главный менеджер в одной фирме, которая Microsoft Solution Provider) — "Microsoft есть убогая персоналочная компания, у них один Ворд и Эксел, и ихний Бэкофис из пальца высосан — куда они лезут-то на рынок тяжелых систем, они там не понимают ничего..."
лично я вот назвал бы больше "комплексом неполноценности" твоего тогдашнего шефа. Типа убогая компания. А он управлял конечно не убогой компанией, которая куда круче и увереннее была, чем МС. Она просто маленькая была и никто её не замечал, а вот глупые людишки... Только МС и замечают. Только почему-то о компании твоего тогдашнего шефа я ни разу не слышал, а МС давно на рынке "тяжелых систем", хоть "они там не понимают ничего...". И МС поср*ть, что говорил твой шеф, и что говорят тыщи таких шефов по всему миру, она гнет свою линию и у нее все получается как нельзя лучше...
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, iZEN, Вы писали: ZEN>>К сожалению, в ООП слишком много парадигм, например, шаблоны (template), от чег весь вой: с одной стороны это экономит силы и время, с другой стороны ведёт к двусмысленности(n-смысленности) толкований сторонними кодерами. S>В ООП нет никаких шаблонов. Эта парадигма никакого отношения к ООП не имеет.
Да, ошибся в формулировке. Неправильно выразился.
Шаблоны — это костыли для первых псевдо-ООП-языков, таких как C++ с его STL. Чтобы было легче писать в "как-бы" ООП-стиле, экономя время себе и другим. В что это иногда (не всегда!) выливается — уже написал — требуется более продвинутый программист, чтобы понять что хотел сказать автор. Простота ООП исключает "левые" наносные сложности, там не место макроподстановкам (моё мнение, другое мнение возобладало в C++) — фактически метаязык "определений для определений" (на самом деле для препроцессора).
Обидно, что новая версия Java пошла по такому же пути.
Здравствуйте, iZEN, Вы писали: ZEN>Да, ошибся в формулировке. Неправильно выразился. ZEN>Шаблоны — это костыли для первых псевдо-ООП-языков, таких как C++ с его STL. Чтобы было легче писать в "как-бы" ООП-стиле, экономя время себе и другим.
Ничего подобного. Еще раз: никакого отношения к ООП шаблоны не имеют. Ни "как-бы", ни "вместо" ООП. Просто не все виды взаимоотношений между типами можно выразить при помощи наследования (или генерализации). Шаблоны, как и ООП, позволяют увеличить выразительность языка программирования. Совместное применение метапрограммирования и ООП на сегодня, насколько мне известно, является наиболее выразительным средством императивного программирования.
... << RSDN@Home 1.1.4 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alexkro, Вы писали:
A>>>А толмуда с названием "Coding guidelines" у вас нет? Перегнули вы тут явно. B>> Есть, только не талмуд, которому никто следовать не будет, а небольшой внутрифирменный документ, стандартизирующий написание кода. Над проектом работает 10 человек, ... A>Команда из десяти человек, а сколько бюрократии. Я видел группы побольше, и никаких формальных документов не требовалось. Разумные люди сознательно не будут бардак создавать.
"Coding guidelines" есть практически везде, где работают удалённые команды, вот пример самого краткого: Phoenix team guielines
Там же есть ссылки на другие задекларированные аспекты работы, хотя казалось бы зачем GNU разработчикам на себя такие вериги накладывать — знай себе твори. Однако история нам подсказывает — где есть толпа, там должен быть определённый закон, иначе не будет развития. Даже в Open Source движении есть координаторы проектов, своего рода князьки и рядовым разработчиком бывает порой труднее их убедить, чем коммерческого менеджера.
A>>>Самодокументированность липовая, так как проблемы в этом смысле абсолютно такие-же как и в Java, когда в одной функции спецификация меняется, и это заставляет поменять все функции, её вызывающие, а дальше и все функции их вызывающие, и т.д. В конце концов это приводит к бардаку. B>> Тоже самое с модификатором const, сделав одну из функций неконстантной, вам прийдёться модифицировать все функции исполюзующие её. Но вы ведь не будете отрицать необходимость этого модификатора. A>Это совсем не тоже самое. Во-первых, твоё утверждение о "модификации всех функций" неверно. Во-вторых, ответь мне, почему const входит в сигнатуру функции, а спецификация исключений нет? Я удивлен, что тебе вообще пришла идея такого сравнения в голову.
Можно вообще не использовать ни const ни throw, и всё будет работать. Но это IMHO снизит управляемость кода. А сравниваю эти два зарезервированных слова я потому что сторонник порядка. Если функция не изменят состояние объекта, то это должно быть описано; если функция может генерировать исключения, то это тоже должно быть указано.
B>>>> К тому же, уже по моему мнению, информация об исключениях, может быть использована компилятором для оптимизаций, A>>>Как раз таки, компилятор должен кучу кода награмаздить, чтобы проверить соответствие спецификации исключения. Тут уж ни о какой оптимизиции речи не идёт, за исключением опять-же пустого throw(). B>> На то он и компилятор, чтобы громоздить код вместо человека. Вы же не обижаетесь на автоматически код пролога и эпилога функций, и на автоматические деструкторы и операции копирования. A>Ты говорил про оптимизации или про что? А теперь перекинулся на то, как компилятор облегчает генерацию кода. Да-с.
Что дасссс?
Современный компилятор громоздит код гораздно лучше, человека. Чего стоит только вызов деструкторов для автоматических объектов при исключении. Я давно работаю с компилятором Intel C++, и наблюдаю эволюцию их рекомендаций по написанию кода, который будет наилучшим образом оптимизирован, тенденция ведёт к упрощению, к снятию ограничений с кодера.
А вообще давай послушаем что сказали отцы throw
B>> К тому же, компиляторы эволюционируют >>>> или для автоматической генерации кода обработки исключения. A>>>Автоматическая генерация обработчика? std::unexpected()? Кому такая нужна? B>>Кому не нужна, тот и не использует. Кому понадобиться, тот будет рад что такое возможно. A>Вот и объясни мне, кому такое понадобится и зачем. Иначе, в твоих словах нет аргументов.
Как минимум — выдача диагностического сообщения о классе исключения, и если доступна контесктная информация, то и её выдача. Наверняка ты видел много сообщений "IO error" или "Divide by 0 error". Как минимум компилятору доступно имя класса исключения,что он и может использовать в обработчике по умолчанию.
B>>Во всех крупных проектах, в которых я участвовал, к конце концов формировалась своя иерархия классов-исключений. A>Мы кажется говорим про спецификации исключений, а не про иерархии классов-исключений. Почему-то тебя все время в сторону тянет. A>Я не противник технологий, я противник их бездумного применения. Далее прошу оставаться в рамках спецификации исключений и не перепрыгивать на смежные вопросы.
Посмотри на тему дисскусии, там про исключения вообще ничего нет
А про иерархия я говорю, потому что, не вижу смысла говорить о строительной глине, не подразумевя что из неё делают кирпичи, а из них дом. А споры нужна ли белая глина, или достаточно для всего красной, это пустая трата времени.
Вот я и говорю, что на моей практике две разных команды пришли к одному и тому же удобному для них решению — иерархии классов-исключений.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Нижеследующий текст написан нашим соотечественником, работающим в микрософтовской команде компиляторов.
MSS>Ко мне этот текст попал в конце 91го года. Он довольно старый, и старше, чем релиз .NET.
MSS>Предлагаю обсудить.
А что обсуждать? Человек не умеет пользоваться ООП в чем долго и нудно расписывается.
Есть области где ООП оправдано, есть области где оно вредно. К примеру интерфейся куда проще и удобнее писать с применением
ООП.
Большинство чисто алгоритмических задач (как тот же самый компилятор) в ООП не сильно нуждаются.
Здравствуйте, Шахтер, Вы писали:
Ш>Какому? Это зависит от системы. Нет в С способа использовать printf системно-независимым способом. Сейчас Майкрософт вводит Win64. В этой системе size_t -- 64 разрядный. Он будет больше long. Ш>Т.е. его вообще невозможно распечатать используя стандартные коды форматирования.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, году в 1994 я наблюдал изумительный пример маразма в этой области. Одному орлу поручили написать функцию преобразоватия числа в строку прописью (русское написание числа). Так вот он вместо того, чтобы написать одну простую функцию состряпал класс. Это надо было видить. Я плякаль... После этого мы переписали его код выбросив процентов 40. Но это же не проблема ООП. Это проблема умения выделять абстракции.
По поводу этого примера вставлю свои 5 копеек.
Ошибочно мнение, что ООП можно заниматься только на языках, в которых есть поддержка ООП. Это не так.
На Си тоже прекрасно получаются абстракции, наследование, полиморфизм и пр. НО! чтобы сделать
это надо маленько подумать и написать несколько больше букв (размер кода не больше, чем генерит компилятор, поддерживающий ООП),
поэтому абстракцию используют только там, где это реально необходимо и дает преимущества.
На Си вышеозначеный "орёл" не написал бы такой маразм, т.к. это требует значительно большей умственной нагрузки.
Т.о. программист, получив возможность просто объявить класс, а не создавать всю начинку класса самому, получает мнимую легкость
применения ООП, но знания его совсем не соответствуют уровню задачи.
Как аналогия — пересадить человека с машины на вертолет с очень простым управлением. Пока погода хорошая, он сможет летать на вертолете не хуже
чем ездить, но в сложной ситуации он неминуемо разобьется. А если бы управление вертолетом было сложное и требовало бы обучения, то
в ходе обучения человек бы приобрел все необходимые навыки поведения в экстренной ситуации и не разбился.
Здравствуйте, anidal, Вы писали:
A>Ошибочно мнение, что ООП можно заниматься только на языках, в которых есть поддержка ООП. Это не так. A>На Си тоже прекрасно получаются абстракции, наследование, полиморфизм и пр. НО! чтобы сделать A>это надо маленько подумать и написать несколько больше букв (размер кода не больше, чем генерит компилятор, поддерживающий ООП),
ИМХО, прекрасно как раз и не получится. Реализовать можно и на асме — для этого надо всего лишь подумать и написать несколько больше букв. Только кому это надо?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, anidal, Вы писали:
A>>Ошибочно мнение, что ООП можно заниматься только на языках, в которых есть поддержка ООП. Это не так. A>>На Си тоже прекрасно получаются абстракции, наследование, полиморфизм и пр. НО! чтобы сделать A>>это надо маленько подумать и написать несколько больше букв (размер кода не больше, чем генерит компилятор, поддерживающий ООП),
AJD>ИМХО, прекрасно как раз и не получится. Реализовать можно и на асме — для этого надо всего лишь подумать и написать несколько больше букв. Только кому это надо?
Я не призываю писать абстакции на С и тем более ассемблере, но когда для написания абстракции надо приложить усилия, пусть и небольшие,
сто раз подумаешь, а надо ли это и программ типа Hello world с десятком классов не будет.
Если нам не помогут, то мы тоже никого не пощадим.
