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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

<<<... | 2536—2527 | 2526—2517 | 2516—2507 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 374


№ 2526   04-02-2007 14:22 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2519« (Geniepro)
___________________________

Ответ на »сообщение 2518« (Илья Ермаков)
___________________________
Однако Ваша фраза подразумевает, что программы на Хаскелле обязаны быть ненадёжными, глючными...
Это противоречит общепринятому мнению о Хаскелле...
У Вас есть какие-нибудь серьёзные основания считать, что Вы правы на этот счёт, или это просто боязнь новизны?
Чем плохо позволить программисту описать задачу в наиболее наглядном для него виде?

Нет, речь не о том, что "обязаны". Просто моему глазу показалось, что в языке есть темные закоулки и подводные камни, вызванные тем, что разработчики таки погнались за некоторыми "фичами". И реализации могут содержать скрытые ошибки, в частности, при оптимизации и т.п. Имеется ли набор тестов, который используется для проверки реализаций Хаскеля на корректность? Этот язык не столь прост, чтобы об этом не задуматься.
По поводу второго вопроса: по мне, к примеру, либо if, либо сопоставление с образцом, либо | - но что-то одно... Когда равноценных путей слишком много, возникает известная проблема буриданова осла.
В Обероне разработчик вместе с синтаксисом сразу "всасывает" единый стиль, общую идеологию, поэтому, кстати, легко разбираться в чужик исходниках. То же самое можно сказать про Ada, где единообразие было обеспечено не только языком, но и политикой стандартизации как военного языка.
А есть другой подход - "чтоб никого не обидеть, включим в язык все варианты". По мне лучше первый :-)


№ 2525   04-02-2007 14:22 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2523« (Илья Ермаков)
___________________________
Now we are talking :)) Значит вы лукавили когда про ключи хаскелевского компилятора говорили.
в ББ тоже есть сложный отладчик. Только он не в компиляторе а в среде.



В дампе в ББ все состояние программы как на ладони, весь срез - щелкай мышкой по ссылкам-указателям, анализируй и думай, в чем ошибка.


Абсолютно тоже самое в java и в сишарп. Что вобщем то и немудрено - языки то одного уровня с обероном (как бы вам и не хотелось в этом признаться :)) )


№ 2524   04-02-2007 14:21 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2522« (Jack Of Shadows)
___________________________

Нищета-с :)) Разработка таких сложных и громоздких программ стоит не один лимон долларов.

Несколько примеров.

Возможно, Вы знаете, что был в свое время очень солидный отладчик Logitech Multiscope Debugger (OS/2, Windows, MS-DOS) для Modula-2 (написан на Modula-2). То был отладчик для языка Modula-2 - более сложного, чем Oberon. Мало кто знает, что написал его иранец Mansour Safai - автор известного инструментария Visual Cafe (Java) компании Symantec. Сафаи был ведущим разработчиком в Logitech, а потом вице-президентом в Symantec (заодно там же - генеральным менеджером департамента инструментария для языков программирования и Интернета). К сожалению, он умер 9 февраля прошлого года в возрасте 43 лет.

Вот мнение одного весьма уважаемого эксперта: Pierluigi Zappacosta, one of the original founders of Logitech and friend of Safai for more than 15 years: “In areas such as interactive debugging of applications, Mansour and his teams have delivered the most innovative systems of the past decades.” Кстати, Сафаи был иранцем, но стал программистом экстра-класса и получил отличное европейское образование в Швейцарии (Ecole Poly-technique Federal de Lausanne).

Другой отладчик VID для языков TopSpeed-семейства (C, C++, Pascal, Modula-2, Clarion) написан на Modula-2 (как и все компиляторы, и IDE).

Стоимость разработки отладчика - не миллион долларов, несколько меньше :) Но и не 5 тысяч.

Поэтому языкам обласканным финансовым вниманием толстосумов (дельфи, vb, java) повезло.

Не совсем верный тезис. Отладчики Оберонам, разумеется, не помешали бы. Но в любом деле надо понимать, зачем оно (это дело) делается, и какова цена вопроса. Для Оберона отладчик нужен еще в меньшей степени, чем для Modula-2, а для нее - много меньше, чем для C++. Уж такие это языки, что отладчик здесь сильно вторичен. Новосибирцы для XDS отладчик не делали, а свели к решенной задаче - генерировали код под внешние распространенные отладчики (CodeView). Вполне разумный подход.


№ 2523   04-02-2007 14:12 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2522« (Jack Of Shadows)
___________________________
По поводу отладки в Обероне...
Джек, я по "долгу службы" сейчас работаю как с проектами на BlackBox, так и с проектом на С++ (Visual Studio). После ББ я плююсь на отладчик студии.
В дампе в ББ все состояние программы как на ладони, весь срез - щелкай мышкой по ссылкам-указателям, анализируй и думай, в чем ошибка. В Цешных/Дельфовых/etc средах без метаинформации такое удобство не обеспечишь - вот и приходится, высунув язык, гонять пошагово... А если приходится работать в Studio 6.0, где даже std::string по-человечески не раскрываются... В плане легкости отладки Студия с Обероном и рядом не стояла.


№ 2522   04-02-2007 13:15 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2510« (Илья Ермаков)
___________________________
Не надо утрировать,
Правильно, утрировать не надо, ни мне ни вам. :))
Вы начали с укола в сторону хаскеля, мол де полсотни отладочных ключей в компиляторе означает что программы на хаскеле ужасно глючны, раз требуют такого компилятора. Это утрирование. Это выдирание из контекста.
Прежде все процесс отладки - работа необходимая и сложная. Работа требующая мощных и сложных инструментов.
И как следствие такие вот мощные и сложные инструменты существуют и для императивного подхода и для функционального. Но они разные.

ИП:
Сложные инструменты отладки существуют в виде программ поверх компилятора, то есть в виде сред. Дельфи, MS VS, Eclipse - все это мощные и очень сложные инструменты отладки, с возможностью остановки программ в выбранных точках, пошаговым исполнением, десятками окон для обзора значений переменных, стека вызова функций, дизассемблера, модулями удаленной отладки, профилировщиками.
Потому компилятор особенно отладно не нагружен.

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

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


№ 2521   04-02-2007 12:23 Ответить на это сообщение Ответить на это сообщение с цитированием
Вечный вопрос - есть ли в программировании место искусству?

Можно ли позволить программам быть произведениями искусства, писать стихи на языке программирования?
Или программы должны быть написаны по нескольким шаблонам бульварной прессы?

Программы на Хаскелле подобны хайку - несколько строк, а сколько в них глубинного, потаённого смысла, который может обсуждаться веками...
Этим он (Хаскелл) и отличается от тяжеловесного, грубоватого Оберона, и от корявого С++...

____________________

Если сравнивать программистов с солдатами, то мне в голову приходят такие аналогии:

Программист на Обероне - простой пехотнинец, тяжёлой поступью своих кирзачей наводящий ужас на врагов: женщин и детей, а иногда и рушащий под собой мосты; эдакий бравый солдат Швейк...

Программист на С++ - морской котик, который либо разоберётся в премудростях своей профессии, либо погибнет...

Программист на Хаскелле - снайпер, ворошиловский (или альпийский) стрелок, выстрел которого не имеет права на ошибку...


№ 2520   04-02-2007 10:41 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2518« (Илья Ермаков)
___________________________

И вновь вместо языка - компактного и безотказного инструмента имеем сундук с abilities, possibilities & features...

Самый компактный язык (из промышленно используемых, брейнфаки не в счёт) - это, пожалуй, Лисп/Scheme. Несмотря на обширность их библиотек (к языку они не относятся - это окружение языка), сами эти языки - очень просты и компактны...


№ 2519   04-02-2007 10:27 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2518« (Илья Ермаков)
___________________________

И вновь вместо языка - компактного и безотказного инструмента имеем сундук с abilities, possibilities & features...

Да, мы уже убедились, что правоверные оберонщики должны быть аскетами и пуританами... :о)
Хоть и находятся даже среди них люди, грешащие Зонноном, но они не в счёт, верно? ;о)

Видимо, это уже зависит от типа людей, что им больше нравится - сковать свои крылья оковами или легко парить в облаках... :о) Вопрос филосовский...

Однако Ваша фраза подразумевает, что программы на Хаскелле обязаны быть ненадёжными, глючными...
Это противоречит общепринятому мнению о Хаскелле...
У Вас есть какие-нибудь серьёзные основания считать, что Вы правы на этот счёт, или это просто боязнь новизны?


"Haskell's choise: provide multiple ways, and let the programmer decide".

Чем плохо позволить программисту описать задачу в наиболее наглядном для него виде?


№ 2518   04-02-2007 08:10 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2514« (Geniepro)
___________________________

Ответ на »сообщение 2510« (Илья Ермаков)
___________________________

Выдержка из Simon Peyton Jones. "Wearing the hair shirt. A retrospective on Haskell" (стр.15) :

Tony Hoare’s comment “I fear that Haskell is doomed to succeed” ("Боюсь, Хаскелл обречён на успех")

"Haskell's choise: provide multiple ways, and let the programmer decide".
И вновь вместо языка - компактного и безотказного инструмента имеем сундук с abilities, possibilities & features...


№ 2517   04-02-2007 07:54 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2516« (AVC)
___________________________
Хоар вроде бы сейчас занимается как раз-таки ортогональным к ФП подходом - развитием методов автоверификации и доказательства императивного кода. На мой взгляд - для практики самый перспективный подход. И оберонщики здесь тоже на месте не стоят, хе-хе ;)


<<<... | 2536—2527 | 2526—2517 | 2516—2507 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 374


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

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

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

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

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

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