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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

<<<... | 3716—3707 | 3706—3697 | 3696—3687 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 256


№ 3706   07-04-2007 11:24 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3703« (Руслан Богатырев)
___________________________
Думаю, самое время начинать называть вещи своими именами и перестать щадить чье-то самолюбие. Ваша фраза -- элементарная ложь.
Talk about hypocrites. Для некоторых "более равных" функций значит можно исключения делать ?


№ 3705   07-04-2007 11:23 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3704« (Trurl)
___________________________
Кстати, зря. Вполне естественно смотрелись бы List.map, Set.map, Array.map..
Полиморфизм вещь удобная.
А то ведь и арифметические операторы можно явно квалифицировать как в OCAML. Отдельно "+" для целых чисел и "+." для real.
Только ведь большинство взвоют от такой "естественности".


№ 3704   07-04-2007 11:17 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3699« (Geniepro)
___________________________
Ну и кто тут говорил о лукавстве? ;-) Всякие там primPlusInt не учитываем?
И зачем формально включать в Prelude такие вещи, как [a], если они намертво зашиты в язык?

>>> в Хаскелле никому в голову не приходит квалифицировать циклические функции map, foldr...
Кстати, зря. Вполне естественно смотрелись бы List.map, Set.map, Array.map..
В частности, Set.map ничуть не хуже чем mapSet.


№ 3703   07-04-2007 11:17 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3702« (Jack Of Shadows)
___________________________

А map foldl, filter, которые и есть адекватная замена тем же операторам цикла в хаскеле, требуете квалифицировать.

Думаю, самое время начинать называть вещи своими именами и перестать щадить чье-то самолюбие. Ваша фраза -- элементарная ложь. См. »сообщение 3656«.


№ 3702   07-04-2007 10:52 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3700« (AVC)
___________________________
2) Линковщик выбирает нужный вариант "эвристически", например, как в Турбо Паскале (и Delphi?) -- из модуля-кандидата, упомянутого в списке последним.
А где гарантия, что это правильный выбор?

Гарантия проста - квалифицируйте. Вот только зачем ОБЯЗАТЕЛЬНО ВСЕ квалифицировать ?
Или у вас в системе у каждой функции свой двойник с одинаковым именем, списком и типами параметров и возвращаемым значением ?
Квалифицировать приходится всем. И в дельфях и в том же хаскеле. Вот только экстремизм в подходе непрактичен.
Квалифицировать всегда только потому что в одном из ста случаев может случиться неявная подмена, это экстремизм, то есть доведение до крайнего случая. Любителей экстремизма всегда хватает, но большинство вас не поймут.
GeniePro тут уже приводил пример с встроенными операторами оберона. Вы же их не квалифицируете.
А map foldl, filter, которые и есть адекватная замена тем же операторам цикла в хаскеле, требуете квалифицировать.
Почему ? Ах это не операторы а функции.
Потом опять же - костылями вы не пользуетесь. Печатаете код на бумагу или с сайта DelphiKingdom код читаете.
Потом, глядя на название функции
myFile := OpenFile("test.txt", ReadWrite)
вы не можете понять что же она делает.
Не можете понять ни из названия функции, ни из передаваемых ей параметров, ни из возвращаемого значения, ни из контекста применения. Вам обязательно надо видеть ИМЯ МОДУЛЯ.

myFile := Files.OpenFile("test.txt", ReadWrite);

Так наверное лучше, да ? Сразу понятно теперь что делает функция OpenFile, что означают параметры "test.txt", ReadWrite, и почему в контексте кода строчкой дальше написано myFile.Read;

Я удивляюсь как вы без имени модуля понимаете что означают for, while, repeat !!
Ведь понять что означает map, foldl, filter без имени модуля вы кажется не в состоянии.

Вам нужны костыли в виде обязательных имен модулей перед КАЖДОЙ (!!!) функцией, перед КАЖДЫМ обьектом.
Послушайте, а локальные для модуля обьекты и функции вы тоже квалифицируете ?
типа ThisModule.myLocalFunction
А то ведь не ровен час, кто нибудь в одном из импортируемых вами модулей ДИНАМИЧЕСКИ возьмет и введет функцию с точно таким же названием. Вот конфуз выйдет.


№ 3701   07-04-2007 10:41 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3700« (AVC)
___________________________

>>>А где гарантия, что это правильный выбор?

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

Пусть мы импортируем 2 модуля: M1 и M2, в каждом из них определены процедуры A() и B().
И надо же такому случиться, что нам потребовалась процедура A() из модуля M1, а процедура B() из модуля M2.
Здесь, как ни крути, без квалифицирующего импорта не обойтись.
Конечно, этот последний пример довольно искусственный (хотя кто знает?).
Главное же в квалифицирующем импорте -- уберечь нас от неприятных неожиданностей.
Не слишком логично, IMHO, использовать строгий язык (Паскаль), а в местах межмодульных соединений от этой строгости вдруг отказываться и полагаться на "авось". :)
 AVC


№ 3700   07-04-2007 10:27 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3698« (AVC)
___________________________


Линковка происходит динамически при загрузке модуля.
И к какой FindClose (если взять пример Антона Григорьева) прикажете на ходу линковаться?


Возможно, даже это не вполне понятно.
Попробую объяснить подробнее.
В Обероне клиент не требует перекомпиляции, если изменения в модуле оставили интерфейс в неизменности или даже расширили его.
Представим себе, что Вы пользовались процедурой FindClose, и все было замечательно. :)
Но случилось так, что разработчики одного из импортируемых Вами модулей решили расширить его функциональность и тоже завели себе процедуру FindClose.
Тогда у линкующего загрузчика два варианта.
1) При загрузке модуля подать сигнал тревоги и отказаться загружать "двусмысленную ерунду". :)
Проблема в том, что у измененного модуля могло быть огромное число клиентов, исходный код может отсутствовать и т.д.
2) Линковщик выбирает нужный вариант "эвристически", например, как в Турбо Паскале (и Delphi?) -- из модуля-кандидата, упомянутого в списке последним.
А где гарантия, что это правильный выбор?

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


№ 3699   07-04-2007 08:46 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3695« (Илья Ермаков)
___________________________

Да именно тем, что это не "стандартные процедуры", а именно часть языка. Операции, записываемые в префиксной форме со скобками - И ВСЕ. И их использование - это не вызов функции, а просто монолитная часть выражения.

Хм, ну тогда в таких языках, как Хаскелл, вообще нет никаких стандартных функций и операций. +, -, *, / и пр., циклические операции над списками (map, foldr, foldl, take, drop и пр.) - всего этого нет в виде языковых конструкций. Всё это определено как методы стандартных классов и стандартные функции.

А языковые конструкции - это всего лишь межмодульное взаимодействие (импорт/экспорт), выражение сопоставления по образцу (case of), условное выражение (if then else), конструкция монадического программирования (do), конструкции разграничения пространств имён (let in и where)... И всё!

Интересно, пришло бы в голову оберонщикам квалифицировать имена арифметических операций?
В Хаскелле такое вполне возможно, только хаскеллерам в голову даже не приходит.
Точно так же как в Обероне никто не квалифицирует операторы циклов, в Хаскелле никому в голову не приходит квалифицировать циклические функции map, foldr... Хотя в F# такие функции таки выделены в модуль List и выглядят типа List.map... :о))

Обероновский синтаксический сахар в Хаскелле вынесен в стандартную библиотеку Prelude.


№ 3698   07-04-2007 08:26 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3697« (Сергей Перовский)
___________________________

Хотите чертеж - любая современная CAD система может представить сложнейшие объекты в 3D и позволяет поворачивать, рассекать, делать невидимыми части и т.д.; попробуйте доказать конструктору, что это костыли и независимый от компьютера бумажный чертеж гораздо прогрессивнее. Сейчас уже прораб на стройке предпочитает работать с ноутбуком, а не с бумажной простыней. А Вы отказываете в этом программисту.

Еще бы придумали, что я предлагаю программировать на счетах. :)
Я уже говорил, что IDE (в определенном контексте беседы, а не вообще!) был назван костылем не потому, что в нем есть удобства, а потому, что в языке (и следовательно в СП в целом) остались нерешенные важные проблемы, которые IDE как бы "прикрывает".
Приводились примеры проблем, не только на далеком от нас C#, но и на Турбо Паскале (Trurl) и на Delphi (Антон Григорьев).
Т.е. то, что проблемы есть, это факт.
И потому Ваши замечательные метафоры, IMHO, не по делу.
А чтобы наше отношение к этой проблеме стало нагляднее, рассмотрим ту же ситуацию, как она выглядела бы для Оберона, если бы не было квалификации импорта.
Оберон-система (в т.ч. многие Оберон-программы, работающие под виндами) в процессе работы может менять свой состав, добавлять новые модули и, иногда, удалять старые, "ненужные". :)
Линковка происходит динамически при загрузке модуля.
И к какой FindClose (если взять пример Антона Григорьева) прикажете на ходу линковаться?
Вы действительно полагаете, что программная система (особенно, конечно, динамическая) в условиях такой неопределенности может быть надежной?
 AVC


№ 3697   07-04-2007 08:03 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3691« (AVC)
___________________________
>>>Вообразите себе чертеж, в котором надо было бы все время щелкать мышкой, чтобы узнать необходимые технические сведения.
Например, Google Earth - гораздо удобнее атласа, но без компьютера, интернете и софта не работает.
Хотите чертеж - любая современная CAD система может представить сложнейшие объекты в 3D и позволяет поворачивать, рассекать, делать невидимыми части и т.д.; попробуйте доказать конструктору, что это костыли и независимый от компьютера бумажный чертеж гораздо прогрессивнее. Сейчас уже прораб на стройке предпочитает работать с ноутбуком, а не с бумажной простыней. А Вы отказываете в этом программисту.
Современная система программирования состоит из языка с его синтаксисом и стандартными библиотеками, среды исполнения и IDE. Считать одну систему лучше другой на основании того, что функции этих подсистем распределены по другому, вплоть до полного поглащения нестоит.
"Мы можем обойтись без IDE!" Ну и что?
Я могу обойтись много без чего, включая интернет. Но не хочу.
Ручной инструмент много лучше электрического, если электричество недоступно :)
И много хуже, если электричество есть.


<<<... | 3716—3707 | 3706—3697 | 3696—3687 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 256


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

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

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

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

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

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