На базарной площади довольно часто можно слышать высказывания об
Обероне. Мне кажется, что на базарной площади пора появиться ветке об
этой системе и языке, что-то вроде "Мысли об Обероне". Что это такое, перспективы
этой системы, что
полезного можно извлечь из него для программирования на Дельфи
(например) и др.
Ivan
Всего в теме 4531 сообщение
Ссылки по теме "Оберон" и "Компонентный паскаль"
Отслеживать это обсуждение 
- Free Pascal, Oberon, BlackBox
- Разработка препроцессора gpre для delphi\freepascal.
- Component Pascal и среда разработки BlackBox
- FreePascal: реальная альтернатива или OpenSource — блажь?
| № 4421 07-02-2006 07:49 |   |
Ответ на »сообщение 4419« (Ev_genus)
___________________________
Ответ на »сообщение 4417« (Андрей Хохлов)
___________________________
x+++y действительно допустимо, x+++(++y) тоже, но как понимать x+++++y?
Если вас сбивают с толку сиволы - обратитесь к лексемам.
[x] [++] [++] [+] [y]
Следовательно
(([x] [++]) [++]) [+] [y]
Результат - ошибка. ++ нельзя применить к выражению (x++)
Воспроизвожу цитату еще раз:
На языке C программист МОЖЕТ написать конструкцию x+++++y, загадку, а не выражение, представляющую проблему даже для сложного синтаксического анализатора
Разбиение на лексемы правилиьно (берется самая длинная допустимая подстрока, в данном случае ++), а вот аргумент притив Си непонятен. Я его (Си) нисколько не оправдываю, но все же...
| № 4420 07-02-2006 07:07 | |
Ответ на »сообщение 4418« (Владимир Лось)
___________________________
Расширяемость можно понимать, как безболезненное и минимальное, в смысле перепроектирования, изменение подсистемы, обеспечивающее удовлетворение большинства поступающих требований, не заложенных в первоначальной их совокупности.
Безболезненное и минимальное изменение. Подумаем. Безболезненное для кого/чего? Для автора, новоявленного соавтора ("расширятеля"), модуля, всей системы? Как насчет авторского надзора? Всяк, кто тронет, посягнет на задумку. Берем оловянного солдатика. А теперь начнем безболезненно пластилином лепить к нему наши овеществленные фантазии. Что получится? Значит, могут быть модули подконтрольные автору и неподконтрольные ему.
Минимальное изменение - это вроде как для детишек переводные картинки? Раскрасить можно, но просто водой (никаких там красок). А самому что подрисовать - ни-ни. Значит, модули могут быть "макияжные"
(переводные картинки) и трансформируемые (LEGO).
| № 4419 07-02-2006 07:02 | |
Ответ на »сообщение 4417« (Андрей Хохлов)
___________________________
x+++y действительно допустимо, x+++(++y) тоже, но как понимать x+++++y?
Если вас сбивают с толку сиволы - обратитесь к лексемам.
[x] [++] [++] [+] [y]
Следовательно
(([x] [++]) [++]) [+] [y]
Результат - ошибка. ++ нельзя применить к выражению (x++)
| № 4418 07-02-2006 06:45 | |
Ответ на »сообщение 4416« (Старик Оберон)
___________________________
Очень рад, что вы согласны.
И много таких разработчиков, "способных мыслить на уровне создания расширяемых модульных систем"?
Нет.
Модульность понимает каждый по-своему. Расширяемость - тоже.
Да.
Расширяемость можно понимать, как безболезненное и минимальное, в смысле перепроектирования, изменение подсистемы, обеспечивающее удовлетворение большинства поступающих требований, не заложенных в первоначальной их совокупности.
Беда, коль сапоги начнет тачать пирожник...
Именно!
Просто когда-то прочитал, про "бешенные бабки" , получаемые программистами, а про то, что здесь, как и везде надо РАБОТАТЬ (А, ГЛАВНОЕ - ДУМАТЬ и УЧИТЬСЯ, при этом - ПОСТОЯННО!!!!) индивиду забыли сказать...
Cначала надо думать, а потом делать.
И снова рад полностью согласиться с вашими золотыми словами!
Именно тогда и было бы меньше "куч" кодов в монолитных приложениях... :о)
Беда в том, что большинство менеджеров именно требуют как можно более скорейшей "выдачи на гора" первоначальных результатов.
Беда в том, что большинство менеджеров НИКОГДА НЕ ПРОГРАММИРОВАЛИ!(хотя, может быть и "писали код")...
| № 4417 07-02-2006 06:06 | |
Ответ на »сообщение 4373« (Сергей Губанов)
___________________________
Еще раз о статье Н.Вирта
Хорошие идеи: взгляд из Зазеркалья
Никлаус Вирт
Оригинал: Good Ideas, through the Looking Glass by Niklaus Wirth, Computer, V. 39, No 1, January 2006
http://www.citforum.ru/programming/digest/wirth/
Как понимать следующее:
На языке C программист может написать конструкцию x+++++y, загадку, а не выражение, представляющую проблему даже для сложного синтаксического анализатора
x+++y действительно допустимо, x+++(++y) тоже, но как понимать x+++++y?
| № 4416 07-02-2006 05:58 | |
Ответ на »сообщение 4415« (Владимир Лось)
___________________________
В отсеве разработчиков, не способных мыслить на уровне создания расширяемых модульных систем. Или вообще - проектировать системы... :о(
И много таких разработчиков, "способных мыслить на уровне создания расширяемых модульных систем"? Модульность понимает каждый по-своему. Расширяемость - тоже.
Написание монолитной кучи кода - только показатель высокой производительности, как кодера. О способностях к ПРОЕКТИРОВАНИЮ это ни коем образом не говорит. Или, в подавляющем большинтсве случаев, говорит о "никаком" проектировщике.
Беда, коль сапоги начнет тачать пирожник...
Вся "фишка" заключается в том, что не модульность сама по себе мешает писать хорошие программы, а именно недостаток знаний и навыков.
Cначала надо думать, а потом делать.
| № 4415 07-02-2006 05:38 | |
Ответ на »сообщение 4412« (Сергей Перовский)
___________________________
Пока перечислены только минусы модульного подхода.
В чыем же плюсы?
В отсеве разработчиков, не способных мыслить на уровне создания расширяемых модульных систем. Или вообще - проектировать системы... :о(
Написание монолитной кучи кода - только показатель высокой производительности, как кодера. О способностях к ПРОЕКТИРОВАНИЮ это ни коем образом не говорит. Или, в подавляющем большинтсве случаев, говорит о "никаком" проектировщике.
Когда я пришёл на эту работу, человечек, работавший здесь до меня, "напрудил" туеву хучу кода, вроде как работающего (вообще-то у меня волосы дыбом вставали, когда я его код разбирал), но АБСОЛЮТНО не расширяемого! Или лучше сказать так: если вы вздумали бы его расширять, то выполнение каждого нового требования потребовало бы усложнения существующего кода и его объёмов в геометрической прогрессии. Код был АБСОЛЮТНО не структурирован ни по типам, ни по "зонам ответственности" (я про ООП молчу - это для этой конторы - вещь "из запредельно-параллельного мира").
Сейчас объём кода раза в полтора-два меньше, переписано с С на С++, пределы расширения функциональности (для своего класса подсистемы) практически не ограничены. И плюс к этому - уровни надёжности вообще не сравнимы.
Но самое главное ДЛЯ МЕНЯ - прежний код был НЕПЕРЕНОСИМО ПРОСТО ТЯЖЕЛ ДЛЯ ПОНИМАНИЯ в силу абсолютного пренебрежения элементарными средствами (хотя бы и в Си) поддержки модульности, - как на уровне исходного текста, так и на уровне средств компоновки и выполнения программы.
Вся "фишка" заключается в том, что не модульность сама по себе мешает писать хорошие программы, а именно недостаток знаний и навыков. И здесь не важно то, в принципе, в каком языке ты работаешь. Хорошее проектирование видно в любом проекте. Конечно, если язык (средство) поддерживает модульность - это ОГРОМНЫЙ дополнительный плюс. Но если ты не можешь элементарно проектировать системы, то даже и наличие таких средств не спасёт... Впрочем, как и в любой отрасли знаний и труда...
Хотя бы с этого начать: Как писали мальчики и девочки в нашей конторе на Си #include "a_file.c" (!!!!!!!!), так они и под С++ пишут: #include "a_fale.cpp"... И хоть ты третий плюс добавь в язык, мозги-то не переделаешь, там уже на подкорке всё это выграверовано...
| № 4414 07-02-2006 05:19 | |
| № 4413 07-02-2006 05:18 | |
Ответ на »сообщение 4408« (Святослав Ушаков)
___________________________
Сильно жалко, что стандартный грид недоступен для расширения. Приходится делать свой. Как вы думаете это правильно? Надёжность за счёт расширяемости?
Надежность в BlackBox мнимая. Кто работал, знает. Страусиная политика, направленная на "зачернение" всего на свете. Для реальной расширяемости нужен даже не GrayBox, а TransparentBox.
| № 4412 07-02-2006 04:26 | |
Ответ на »сообщение 4409« (Сергей Губанов)
___________________________
>>>Проектировать модульные системы сложнее чем монолитные программы.
Значит в методологии что-то недоработано :(
>>>Рекомендуется между модулями, особенно от различных поставщиков, наследоваться только от абстрактных классов.
Это резко увеличивает объем кода и создает проблемы с отладкой.
>>>Как ни парадоксально, позволить бесконтрольно расширять систему - значит вскоре свести ее расширяемость вообще на нет, т.к. разработчик не сможет сделать ни шага в сторону без того, чтобы не вызвать проблемы у множества клиентов.
Если Вы создаете нечто, чем будут пользоваться тысячи людей, то сначала нужно думать: шаг в сторону точно будет сделать нельзя.
Пока перечислены только минусы модульного подхода.
В чыем же плюсы?
Отслеживать это обсуждение
| Дополнительная навигация: |
|
