Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  15:28[Войти] | [Зарегистрироваться]
Обсуждение темы:
Мысли об Обероне

На базарной площади довольно часто можно слышать высказывания об Обероне. Мне кажется, что на базарной площади пора появиться ветке об этой системе и языке, что-то вроде "Мысли об Обероне". Что это такое, перспективы этой системы, что полезного можно извлечь из него для программирования на Дельфи (например) и др.

Ivan

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 4531 сообщение


Ссылки по теме "Оберон" и "Компонентный паскаль"



Отслеживать это обсуждение


Смотрите также обсуждения:
Free Pascal, Oberon, BlackBox
  • Разработка препроцессора gpre для delphi\freepascal.
  • Component Pascal и среда разработки BlackBox
  • FreePascal: реальная альтернатива или OpenSource — блажь?

  • <<<... | 3721—3712 | 3711—3702 | 3701—3692 | ...>>>
    Всего сообщений в теме: 4531; страниц: 454; текущая страница: 83


    № 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> :))))
    Возможности же разделения процесса создания ПО на параллельно разрабатываемые(!) классы - это просто манна небесная для любого "кошачьего пастуха". Попробовали бы Вы чего-нить такое разработать командой из двух десятков програмеров без ООП...


    <<<... | 3721—3712 | 3711—3702 | 3701—3692 | ...>>>
    Всего сообщений в теме: 4531; страниц: 454; текущая страница: 83




    Отслеживать это обсуждение

    Дополнительная навигация:
    Количество сообщений на странице

    Порядок сортировки сообщений
    Новое сообщение вверху списка (сетевая хронология)
    Первое сообщение вверху списка (обычная хронология)

    Перейти на конкретную страницу по номеру
      
    Время на сайте: GMT минус 5 часов

    Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
    Функция может не работать в некоторых версиях броузеров.

    Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
    Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

     
    © При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

    Яндекс цитирования