На базарной площади довольно часто можно слышать высказывания об
Обероне. Мне кажется, что на базарной площади пора появиться ветке об
этой системе и языке, что-то вроде "Мысли об Обероне". Что это такое, перспективы
этой системы, что
полезного можно извлечь из него для программирования на Дельфи
(например) и др.
Ivan
Всего в теме 4531 сообщение
Ссылки по теме "Оберон" и "Компонентный паскаль"
Отслеживать это обсуждение
- Free Pascal, Oberon, BlackBox
- Разработка препроцессора gpre для delphi\freepascal.
- Component Pascal и среда разработки BlackBox
- FreePascal: реальная альтернатива или OpenSource — блажь?
№ 3711 13-12-2005 04:51 | |
Ответ на »сообщение 3706« (al_mt)
___________________________
Разрабатывать чего-то безусловно можно и без ООП, с этим ни кто не спорит. Но может вспомните кризис программизма 70-х? Причина - порог сложности, который удалось преодолеть именно с помощью идей ООП.
Опаньки, я чего-то пропустил... Таки порог преодолён уже?!!! :о) И в каких же отраслях программирования, подскажите! А я пока загадаю, а потом сравним... :о))))))))))
Здесь часто приводятся примеры, как можно сделать то или иное и думаю Вы сами легко придумаете пример задачи, когда ООП, скажем так - оптимально. Но не надо забывать и о другой стороне ООП - эта технология даёт коллосальные преимущества именно в индустриальной разработке ПО. "Чистые" программисты это не всегда могут понимать, а кто по-моложе еще и серной кислотой плеваться начинають :) Ничего-ничего, вот назначат начальниками, вы все еще попрыгаете ;)))))))))))
Поясняю на счёт разделения. Вы не можете начать "параллельную разработку", пока у вас не будет нормально проработанной проанализированной предметной области и плана системы. Параллельно можно разрабатывать и подсистемы (там критичность к определениям дисциплины связей ниже, чем на микроуровне, опятьтаки из-за степени абстрактности характера этих связей). Термин "индустриальная разработка" очень часто применяется не к месту. В наших, постсоветских условиях, его чаще всего применяют молодые, да ранние мальчики-миньеджеры и тим-лидеры в конторах, штампующих ПО для западных заказчиков "в области веб-программирования и информационных систем". Обычно эти "управленцы", "проскочившие" через очень кратковременный период своего "девелоперства" на Дельфи, ВижуалБэйсике или HTML+скриптования... Именно у них с понятием ООП связан прежде всего "конкретно-разработческий" аспект с уклоном на "сопровождение". Когда начинаешь разговаривать с такими товарищами, в конце приходишь к выводу, что, как раз знание нанимаемыми программистами ООП, как средства проектирования и на фиг не нужно в таких конторах, а нужно, что бы человек "умел программировать на ... или в ...", то есть был взаимозаменяемым винтиком в условиях постоянной текучки кадров в таких проектах. Естественно, что, по характеру задач, каких-то запредельных проблем они не решают, они – потребители и юзеры тулзовин и библиотек, в изобилии имеющихся на рынке для решения установившегося, "устаканившегося" набора задач. Эти наборы давно формализованы и вылиты в системы классов или настраиваемые компоненты. Ни овладение ими, ни, как я уже сказал, сложность задач, решаемых с помощью них, ни в коей мере не заставят этих "миньеджеров" усомниться, что "кризис уже преодалён"... Отработанность подходов и наличие (полу)готовых решений, естественным образом выдвигает на первый план организационный аспект. А пересади этого "товарища" в кресло управленца проектом для встраиваемых систем, космоса, аэронавтики, систем управления реакторами или ещё какой АСУТП, вот тогда я на него и посмотрю. И на его уверенность в "уже преодолении кризиса"... :о)
Кстати, а откуда взялся термин "кошачий пастух"?
Дополнение насчёт "скрытости".
Жил был такой Древний Египет.
Уже интересно! Так вы в сказки верите?! :о) Учтите, эта – из разряда той "о преодалении"... :о)
И был у них, как и положено ДревнеЕгипетский письменный.
Это при расшифровке которого, в некоторых пирамидах, тексты НОВОГО Завета получаются? ;о))))
В котором, ну Вы помните. Гласные были "скрыты". И что? Ни кто же от гласных не отказался из-за этого :)
А там они и не нужны были. Почти все они (по реконструкции) были неопределённо звучащими. А смысл как раз из окружающего текста был понятен (контест сформирован!) ... :о)
То что Вы называете "скрытостью" - это не проблема ООП, а недостаток средств разработки (редакторов в конце-концов), каковой впрочем постепенно правится, хотя и медленне чем хотелось бы.
Средства разработки следуют некоторой парадигме в конкретном языке. Сколько сами тулзовины не улучшай, язык от этого лучше не станет...
№ 3710 13-12-2005 04:32 | |
Ответ на »сообщение 3707« (al_mt)
___________________________
То что Вы называете "скрытостью" - это не проблема ООП, а недостаток средств разработки (редакторов в конце-концов), каковой впрочем постепенно правится, хотя и медленне чем хотелось бы.
Ну конечно, какая проблема может быть в ООП-парадигме? Никакой. Она хорошая! Замечательная! Самая-самая!
Занятно, однако... Элементарные, казалось бы вещи. "Плоские" модули на уровне "тупых" разъемов (да еще без наследования и полиморфизма) супротив "объемных" классов со всеми мыслимыми и немыслимыми средствами самого что ни на есть передового программирования.
Нет, говорят, не докажете, что в модульном разобраться проще. Ну не докажете и все тут.
Наши знающие люди так плохо об ООП не говорят. У нас в ООП все в порядке. Просто у людей руки кривые, инструменты надо подправить, и надо "учиться, учиться и учиться".
Потрясающе!
№ 3709 13-12-2005 04:27 | |
Ответ на »сообщение 3708« (Владимир Лось)
___________________________
Если Вы работаете с готовой библиотекой классов, то у Вас УЖЕ скомпонован глобальный контекст, в котором Вы УЖЕ можете работать со всеми включенными типами, и разумеется видимости УЖЕ на месте.
Вы же не будете утверждать, что предпочли бы для каждого проекта начинать разработку с проектирования процессора?
№ 3708 13-12-2005 04:13 | |
Ответ на »сообщение 3705« (al_mt)
___________________________
y:=sin(x);Ву компре?
Звычайно, а як же?!
Просто у вас УЖЕ компилятором скомпонован глобальный контекст в котором вы можете УЖЕ работать с переменными численных типов. Классы этих переменных УЖЕ видимы. Вы как бы УЖЕ находитесь в областях видимости, в которых можете вызывать нужные функции.
Или в области видимости класса CPU... :о)
А что, вполне могу допустить, что (отвлекаясь от библиотеки Си), можно представить данную функцию, как метод класса TCPU,
double TCPU::sin(double);
от которого унаследован Tx86CPU, от которого - T286CPU, от которого - T386CPU, от которого - T486CPU, от которого - T586CPU, от которого - T586ProCPU, от которого - T586MMXCPU... :o)
Это, канечна, маразм, но в рамках парадигмы... :о)
№ 3707 13-12-2005 04:11 | |
Ответ на »сообщение 3703« (Руслан Богатырев)
___________________________
Дополнение насчёт "скрытости".
Жил был такой Древний Египет. И был у них, как и положено ДревнеЕгипетский письменный. В котором, ну Вы помните. Гласные были "скрыты". И что? Ни кто же от гласных не отказался из-за этого :)
То что Вы называете "скрытостью" - это не проблема ООП, а недостаток средств разработки (редакторов в конце-концов), каковой впрочем постепенно правится, хотя и медленне чем хотелось бы.
№ 3706 13-12-2005 04:05 | |
Ответ на »сообщение 3704« (Владимир Лось)
___________________________
Разрабатывать чего-то безусловно можно и без ООП, с этим ни кто не спорит. Но может вспомните кризис программизма 70-х? Причина - порог сложности, который удалось преодолеть именно с помощью идей ООП.
Вашей реплики о разделении "рабочего процесса и предметной области" я не понял. А что они когда-то бывают слиты воедино? В прикладном программировании я такого вообще не представляю. Но поскольку это ответ на мое упоминание "кошачьего пастуха", то разверну:
Здесь часто приводятся примеры, как можно сделать то или иное и думаю Вы сами легко придумаете пример задачи, когда ООП, скажем так - оптимально. Но не надо забывать и о другой стороне ООП - эта технология даёт коллосальные преимущества именно в индустриальной разработке ПО. "Чистые" программисты это не всегда могут понимать, а кто по-моложе еще и серной кислотой плеваться начинають :) Ничего-ничего, вот назначат начальниками, вы все еще попрыгаете ;)))))))))))
№ 3705 13-12-2005 03:56 | |
Ответ на »сообщение 3703« (Руслан Богатырев)
___________________________
y:=sin(x);
Ву компре?
№ 3704 13-12-2005 03:42 | |
Ответ на »сообщение 3702« (al_mt)
___________________________
Откровенно говоря, я еще не видел квалифицированного ООП программиста, который бы оное ООП охаивал в пользу "модульного" или "функционального" программирования. Может просто разобраться надо?
Ой-надо!...
Надо разобраться прежде всего в том ДЛЯ ЧЕГО люди учатся ООП. Именно, для проектирования ПО или просто потому, что большинство инструментальных средств и библиотек спроектированы с его помощью? Понимаете, о чём я? Для использования STL, вы может и не ДОЛЖНЫ знать все нюансы шаблонизации в Си++, но минимальный уровень знаний необходим. То же касается и VCL...
То что называют "скрытыми" реализациями (методами, функциями, структурами) не фига не скрыто, всё элементарно открывается по <Ctrl+Left_Mouse_Buton> :))))
Во-во-во... :о))))
Возможности же разделения процесса создания ПО на параллельно разрабатываемые(!) классы - это просто манна небесная для любого "кошачьего пастуха". Попробовали бы Вы чего-нить такое разработать командой из двух десятков програмеров без ООП...
Мнэ-э-э... Скажем, полуэкт... А как в ДО (официальную) ООП-эру народ комплексы разрабатывал? :о) И не плохие, кстати...
Но вот ваш термин разделения процесса создания ПО на параллельно разрабатываемые(!) классы мне не нравится... Вы разделяете РАБОЧИЙ ПРОЦЕСС или проводите анализ предметной области?
№ 3703 13-12-2005 03:42 | |
Ответ на »сообщение 3702« (al_mt)
___________________________
То что называют "скрытыми" реализациями (методами, функциями, структурами) не фига не скрыто
Скажите, вам понятно, что в ООП исполнение кода ведется в рамках контекста иерархии классов? Что делегируются действия (обработка сообщений)? Что глядя в конкретное место исходного текста нельзя сразу понять, что же делается, пока не выявишь взаимосвязь между классами и привнесенное в ОО-слои доопределение/переопределение функций обработки?
Вам понятно, что это исполнение происходит в контексте, который надо знать? Это и имеется в виду под словами "скрытый"/"неявный".
Сколько? -- Полтора. -- Чего полтора? -- А чего сколько?
№ 3702 13-12-2005 03:31 | |
Ммм...
Откровенно говоря, я еще не видел квалифицированного ООП программиста, который бы оное ООП охаивал в пользу "модульного" или "функционального" программирования. Может просто разобраться надо?
То что называют "скрытыми" реализациями (методами, функциями, структурами) не фига не скрыто, всё элементарно открывается по <Ctrl+Left_Mouse_Buton> :))))
Возможности же разделения процесса создания ПО на параллельно разрабатываемые(!) классы - это просто манна небесная для любого "кошачьего пастуха". Попробовали бы Вы чего-нить такое разработать командой из двух десятков програмеров без ООП...
Отслеживать это обсуждение
Дополнительная навигация: |
|