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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение. 

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

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

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


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

Добавить свое сообщение

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

Обсуждение из раздела
Школа ОБЕРОНА

<<<... | 4066—4057 | 4056—4047 | 4046—4037 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 221


№ 4056   17-04-2007 15:40 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4052« (Сергей Перовский)
___________________________

Поскольку предполагалось, что при переносе UNIX на новую платформу достаточно написасать для нее транслятор с С, сам транслятор нужно было писать на ассемблере, а то и в кодах. И все правила языка выбирались исходя из принципа "все для разработчика транслятора".

Это не так. К облегчению транслятора концепции Си отношения не имели. Ритчи в 1993 г. довольно подробно изложил историю создания своего языка. Оригинал можно посмотреть здесь: http://www.europrog.ru/book/cddr1993e.pdf

Я понимаю Ваше предубеждение в отношении работ Вирта по Оберону, якобы он шел по пути облегчения работы/структуры компилятора. Боюсь, это серьезное заблуждение. Он в ряде случаев шел навстречу компилятору (с тем же DEFINITION). Но на общем балансе концепций языка это отразилось в незначительном объеме.


№ 4055   17-04-2007 15:17 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4052« (Сергей Перовский)
___________________________

Но ветка называется не "язык Оберон", а "Оберон-технология". Т.е. мы обсуждаем положенные в основу языка принципы и подходы к программированию. Почему же некорректно сравнивать их с другими методологиями?

Некорректно сравнивать язык с методологией и упрекать его в том, что он не удовлетворяет ее требованиям. Давайте сравнивать методологии с методологиями, парадигмы с парадигмами, языки с языками.

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

Если есть желание обсуждать методологию ASU в сопоставлении с модульным или расширяющим программированием в исполнении Оберона или КП -- давайте будем обсуждать. Нет возражений. Но тогда давайте уже по полной программе -- на каких парадигмах она реализована, на каких языках. Карты на стол.

К чему были эти странные полунамеки в отношении квалифицирующего импорта? Он-то каким сюда боком? Модульное программирование что с ним, что без него как было самим собой, так и остается. Если Вы сами поняли -- к чему, так поясните. Попробуем разобраться.


№ 4054   17-04-2007 15:03 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4050« (Сергей Перовский)
___________________________

Может быть Вам жалко времени, объяснять нам, бестолковым, простые с Вашей точки зрения вещи, но тогда как Вы убедите различных чиновников от образования? С ними явно проще не будет :)

Я слишком плохо объясняю? Возможно. Но мне непонятно, когда по нескольку раз в одно предложение формулируется мысль, а потом постоянно всплывает недопонимание. Мысль-то несложная. Перечитываю то, что написал. Нет там двоякого толкования. Ну нет.

Что касается чиновников от образования, то у меня нет цели их в чем-то убеждать. Я не занимаюсь ни пропагандой Оберона, ни его продвижением в какой бы то ни было среде. Нет у меня такой цели. По крайней мере, в настоящее время. За что видимо и получаю тычки со стороны представителей Оберон-общественности. Продвигать Оберон здесь по меньшей мере неразумно. Здесь можно что-то обсуждать. По крайней мере, пытаться обсуждать.


№ 4053   17-04-2007 14:54 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4049« (Сергей Перовский)
___________________________

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

Давайте тогда уточним в отношении A и B -- что совпадает, что отличается (интерфейсы, реализации)? Два одинаковых интерфейса с одинаковой реализацией (различие только на уровне имен) или два разных интерфейса с одинаковой реализацией?


№ 4052   17-04-2007 13:05 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4044« (Руслан Богатырев)
___________________________
>>>Сопоставление языка программирования Оберон с методологиями некорректно.
Но ветка называется не "язык Оберон", а "Оберон-технология". Т.е. мы обсуждаем положенные в основу языка принципы и подходы к программированию. Почему же некорректно сравнивать их с другими методологиями?
Кстати, провел со студентами занятие по выбору языка программирования для конкретной разработки (в курсе "теория принятия решений"). Полный кошмар: вся группа смогла перечислить десяток языков программирования. Про Lisp вспомнили двое после напоминаний. Про Prolog никто не слышал. Понятие декларативных языков оказалось абсолютно новым. Впрочем Оберон тоже никто не назвал. Вот и выбирай язык :)
Когда объяснял, почему С получился таким простым, но так плохо подходящим для программирования, сформулировал очевидный принцип: С это язык с максимально упрощенным транслятором. Поскольку предполагалось, что при переносе UNIX на новую платформу достаточно написасать для нее транслятор с С, сам транслятор нужно было писать на ассемблере, а то и в кодах. И все правила языка выбирались исходя из принципа "все для разработчика транслятора".
Я это к чему? К тому, что синтаксический минимализм - мечта разработчика транслятора :)
С точки зрения пользователя это хорошо до определенного предела.


№ 4051   17-04-2007 12:44 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4048« (AVC)
___________________________
>>>Вместе с тем, критика квалифицирующего импорта совершенно неубедительна.
>>>ASU так и не указал альтернативный способ разрешения конфликта имен.
А я указал :)
Нужно отделить имя интерфейса от имени модуля.
И явно описать импорт переменных и функций из заданного интерфейса.
Писать каждый раз, что функция синус должна быть взята из модуля математика, а ни в коем случае не из модуля тригонометрия, все таки большое занудство.


№ 4050   17-04-2007 12:39 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4046« (Руслан Богатырев)
___________________________
>>>Почему в форум, где не идет торговля Оберонами, где обкатываются идеи до их воплощения (орг.деятельности, программных реализаций, публикаций), где разные элементы Оберонов и Оберон-технологий подвергаются критическому разбору специалистов в этой сфере, постоянно появляются желающие походя пнуть ногой язык, а заодно и тех, кто его изучает и использует.
Надеюсь это не на мой счет...
Я конечно не могу себя причислить к "специалистам в этой сфере", но кое-что в этом жанре умею.
Стараюсь никого лично не задевать и на эмоции не переходить.
Чего и Вам желаю :)
Может быть Вам жалко времени, объяснять нам, бестолковым, простые с Вашей точки зрения вещи, но тогда как Вы убедите различных чиновников от образования? С ними явно проще не будет :)


№ 4049   17-04-2007 12:21 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4040« (Руслан Богатырев)
___________________________
>>>какие проблемы дать "подмене" имя, соответствующее интерфейсу?
Которому из интерфейсов? Я не могу дать модулю имя "А и В". Мне придется создать три модуля А, В и С из которых первые два будут в качестве реализации иметь обращение к С с разными параметрами. Можно и так. Но не слишком удобно.


№ 4048   17-04-2007 09:49 Ответить на это сообщение Ответить на это сообщение с цитированием
IMHO, Слишком много эмоций с обеих сторон.
Уверен, что ASU не проводит по отношению к Оберону "враждебную политику". :)
Вместе с тем, критика квалифицирующего импорта совершенно неубедительна.
ASU так и не указал альтернативный способ разрешения конфликта имен.
А главная мысль (что квалифицирующий импорт несовместим со "слабыми" связями) просто ошибочна (IMHO). Механизм совмещения был изложен в этой ветке многократно.
Вообще, создается впечатление, что ASU критикует не такую частность, как квалифицирующий импорт, а модульный подход как таковой.
Если это предположение верно, то тогда так и надо говорить.
 AVC


№ 4047   17-04-2007 09:35 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4044« (Руслан Богатырев)
___________________________

Подходы к "системостроительству" не зависят от языка программирования.

Из этого тезиса непосредственно вытекает другой: если подходы к строительству программных систем не зависят от языка программирования, то при прочих равных условиях инструментарий (соответствующих методологий) целесообразнее выполнять на максимально компактном языке, который обеспечивает дополнительное важное свойство отображения идей на реализацию: контроль сложности проекта.


<<<... | 4066—4057 | 4056—4047 | 4046—4037 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 221


Добавить свое сообщение

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

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

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

Перейти на конкретную страницу по номеру
  
Время на сайте: 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» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

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