Ответ на »сообщение 4330« (Geniepro)
___________________________
F# - мертворожденное создание. Безумно сложный синтаксис (который авторы постоянно дорабатывают и перерабатывают), куча подводных неявных фич, вытекающих из взаимодействия с базовыми классами CLR.
F#, в принципе, занимает ту же нишу, что и C# 3.0 (строго типизированный статический, аппликативный и т.д.), а C# 3.0 - тоже достаточно сложный язык, со всеми свойствами которого многие программисты до сих пор не знакомы (а знакомиться надо, т.к. это основной язык .Net).
Если хочется свежего и необычного в .Net - обратите внимание на http://www.codeplex.com/IronScheme. Правда, автор сего творения все ленится написать help, о чем ему уже прямо сказали на форуме. Будем надеятся, что к концу года он все-таки удосужится написать нормальную документацию.

Scheme - язык очень гибкий, динамический, с потрясными гигиеничными макросами. Для Scheme можно найти сферы применения, в которых он даст фору вышеуказанным C# и F#. Хочу уточнить, что в эти сферы однозначно не должно входить, например, визуальное проектирование форм. Лисп(и Scheme, естественно) не для этого, это все равно, что микроскопом гвозди забивать. Формы проектируйте в C#-части проекта, а некотрую бизнес-логику можно сделать на IronScheme. dotNet как раз для того и создан, чтобы можно было легко использоватьв одном проекте разные языки. Причем в случае с IronScheme это не обязательно подключение к сборке, написанной на C#, другой сборки, написанной на IronScheme. Вы можете вызывать прямо из текста C# итерпретатор Scheme-скриптов.

В общем, IronScheme - проект интересный, правда, чувствуется, что автору довольно тяжело приходится. Если бы у меня было время, я бы тоже подключился к его разработке, а так меня хватает только на то, чтобы послать автору найденные мною глюки. Кстати, уважаемые господа функциональщики, если у вас есть время и соответствующие знания - попробуйте помочь Leppie (ник автора IronScheme).
dotNet - весьма мощная и перспективная платформа. Если в ней появится нормальная реализация Scheme - то это будет, вообще, СУПЕР!

Ответ на »сообщение 4329« (Сергей Перовский)
___________________________

Может отдельную тему создать про теорию систем?
Или в многострадальную тему о информационных полях податься - там филосовские споры вроде к месту?

Только не в информационные поля, там последние тысячи сообщений всё одна религия обсуждается... :о)
Лучше новую тему, давно пора...

Ответ на »сообщение 4328« (Lisp Hobbyist)
___________________________

>>> Упоминание ML без указания конкретного диалекта я воспринял как ссылку на все семейство ML-подобных языков.

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

>>> Соответственно, с этой точки зрения утверждение о вымирании ML показалось мне излишне радикальным, с намеком на то, что появление Haskell'а делает остальные ФЯ ненужными.

Зх, хотел бы я, что бы с Хаскеллем было так всё замечательно, но увы... И вроде бы даже есть многие библиотеки для использования Хаскелла в промышленных приложениях, и транслятор GHC вполне себе промышленный, но всё что-то вот мелочи накапливаются. В основном от нехватки времени на разбирательства, как всё это совместить -- DLL'ки, ActiveX-компоненты, какой-нибуть qtHaskell для родного для винды GUI... Очень нехватает дельфиподобной среды, какого-нибудь Turbo Haskell Professional... :о(

Поэтому я сейчас стал присматриваться к F#. Из плюсов -- какая-никакая, но интеграция с Visual Studio с проверкой правильности программы прямо в процессе её написания, набор библиотек для .NET (хотя их и не так много, как для той же Дельфы), энергичный язык (не нужно выделять время на ловлю space leak'ов, как в ленивом Хаскелле).
Недостатки, впрочем, тоже есть -- пока всё ещё нет поддержки дизайнера форм (хотя вручную делать формочки для .NET на порядок проще, чем на WinAPI), ну и недостаток самого .NET'а -- громоздкий фреймворк. Сомневаюсь, что .NET-программа будет приемлемо работать на терминале со 120 мегабайтами ОЗУ и WinXP... Прям хоть на Оберон переходи (чур меня...) :о)

Ответ на »сообщение 4325« (Илья Ермаков)
___________________________
Из теории систем известно, что формальные-абстрактные языки/модели не подходят для описания сложных систем. Они могут описать максимум мгновенный снимок - а так потребуется бесконечное их множество... Требуется формально-семантический подход..
Может кому и известно...
В этом утверждении как минимум четыре термина, вокруг определения которых не утихают споры. Начиная с самой "теории систем" и заканчивая "формально-семантический подходом".
Тут это злостный офтопик, и первой реакцией было предложить "пойдем выйдем" :)
Вот только не могу предложить куда.
Может отдельную тему создать про теорию систем?
Или в многострадальную тему о информационных полях податься - там филосовские споры вроде к месту?

Ответ на »сообщение 4324« (Geniepro)
___________________________



>>> >>> таких давно вымерших языков, как ML и Miranda

>>> Грустное зрелище. Перспективы функционального подхода все еще остаются крайне неопределенными, а в ФП-сообществе уже идут свои "священные войны".

Это Вы в каком смысле? Ведь это -- исторический факт, с появлением Хаскелла популярность Миранды резко упала, и уже давно Мирандой никто в мире не пользуется.
Аналогично и ML давно уже уступил место под Солнцем своим потомкам -- SML, OCaml и F#...


Похоже, в очередной раз играет свою негативную роль разница в терминах. :-) Упоминание ML без указания конкретного диалекта я воспринял как ссылку на все семейство ML-подобных языков. Соответственно, с этой точки зрения утверждение о вымирании ML показалось мне излишне радикальным, с намеком на то, что появление Haskell'а делает остальные ФЯ ненужными. Если я понял неверно --- извините.

Ответ на »сообщение 4323« (Lisp Hobbyist)
___________________________

Ответ на »сообщение 4321« (Geniepro)
В целом же соглашусь с тем, что ранее написал Jack of Shadows: слишком расплывчатая формулировка претензий и подозрительные с точки зрения компетентности авторов утверждения о близости Lisp'а и ML. Кроме того, я очень скептически отношусь к возможности проделать в общем случае достаточно серьезный анализ программы полностью автоматически. Например, есть работы по автоматическому обнаружению зацикливания, но это по сути своей эвристики --- halting problem не одолеешь. Другое дело --- анализ с помощью человека, который формулирует логические утверждения о свойствах программ и помогает при их машинном доказательстве, но здесь ИМХО применимость ФЯ ничем не хуже.

Да нет, там точно претензии не в смысле сравнения с императивом...
Видимо, что-то типа возможности задать вопрос "why" Пролог-интерпретатору касательно сделанного им вывода...

Ответ на »сообщение 4324« (Geniepro)
___________________________

Ответ на »сообщение 4323« (Lisp Hobbyist)
_______________________
В этой связи можно ещё раз припомнить работы по Total FP, правда, там что-то особых подвижек по созданию удобоваримого языка для реального использования пока нет.
А было бы хорошо, часть проблем исчезла бы как класс -- невозможно было бы написать зациклившиеся программы, например. Но и ограничения по возможностям при этом тоже серьёзные, увы...

Тут, по-моему, никак не умирающая вера в "вечный двигатель" - "волшебную формальную модель", которая всё-всё-всё сразу решит... Хотя математики давно осознали ограничения абстрактного аппарата (например, Клайна, Ю. Манина можно почитать... Т.е. вся формальная система не несёт в себе содержания, знания больше, чем исходный её набор аксиом, абстракций от реального мира...)

А мне кажется перспективным принять следующий тезис: верификация = преобразование проверяемой системы в такой вид, в котором её правильность очевидна (хотя бы, очевидна более, чем изначально). В этом смысле интересен, конечно, подход Паронджанова с когнитивной эргономикой. (Кстати, у нас в Вике свежие материалы по Дракону (документы по самой технологии): http://wiki.oberoncore.ru/index.php/%D0%94%D1%80%D0%B0%D0%BA%D0%BE%D0%BD , а на форуме активные обсуждения...)

Ответ на »сообщение 4321« (Geniepro)
___________________________

Ответ на »сообщение 4318« (Илья Ермаков)
___________________________
Проблемно-ориентированные языки -- это DSL, как я понял?
Функциональные языки, хоть Лисп, хоть Хаскелл, прекрасно зарекомендовали себя в области реализации DSL'ей...

Да нет, под проблемно-ориентированными языками понимается некоторое жёсткое ограничение на естественный (точнее, на "разобранный на части" естественный). (Из теории систем известно, что формальные-абстрактные языки/модели не подходят для описания сложных систем. Они могут описать максимум мгновенный снимок - а так потребуется бесконечное их множество... Требуется формально-семантический подход...)

В остальном ясно, спасибо за пояснения. Просто стало любопытно...

Ответ на »сообщение 4323« (Lisp Hobbyist)
___________________________

Например, есть работы по автоматическому обнаружению зацикливания, но это по сути своей эвристики --- halting problem не одолеешь. Другое дело --- анализ с помощью человека, который формулирует логические утверждения о свойствах программ и помогает при их машинном доказательстве, но здесь ИМХО применимость ФЯ ничем не хуже.

В этой связи можно ещё раз припомнить работы по Total FP, правда, там что-то особых подвижек по созданию удобоваримого языка для реального использования пока нет.
А было бы хорошо, часть проблем исчезла бы как класс -- невозможно было бы написать зациклившиеся программы, например. Но и ограничения по возможностям при этом тоже серьёзные, увы...


>>> таких давно вымерших языков, как ML и Miranda

Грустное зрелище. Перспективы функционального подхода все еще остаются крайне неопределенными, а в ФП-сообществе уже идут свои "священные войны".

Это Вы в каком смысле? Ведь это -- исторический факт, с появлением Хаскелла популярность Миранды резко упала, и уже давно Мирандой никто в мире не пользуется.
Аналогично и ML давно уже уступил место под Солнцем своим потомкам -- SML, OCaml и F#...

Ответ на »сообщение 4321« (Geniepro)
___________________________

Опыта диагностики ошибок в программах на Лиспе я сам не имею (хотя дебаггер в DrScheme очень прост в использовании, как мне показалось). Ещё надо дождаться второго местного лиспера -- Lisp Hobbyist'а... ;о)


Мой любительский опыт тоже не может служить показателем. :-) Мне хватало, в основном, отладочной печати и просмотра состояния стека в отладчике LWW. Несколько раз пользовался в нем же Object Inspector'ом, но скорее из интереса, чем по необходимости. Очень полезная вещь --- возможность видеть результаты раскрытия макросов, но это к отладке программ скорее не относится.

В целом же соглашусь с тем, что ранее написал Jack of Shadows: слишком расплывчатая формулировка претензий и подозрительные с точки зрения компетентности авторов утверждения о близости Lisp'а и ML. Кроме того, я очень скептически отношусь к возможности проделать в общем случае достаточно серьезный анализ программы полностью автоматически. Например, есть работы по автоматическому обнаружению зацикливания, но это по сути своей эвристики --- halting problem не одолеешь. Другое дело --- анализ с помощью человека, который формулирует логические утверждения о свойствах программ и помогает при их машинном доказательстве, но здесь ИМХО применимость ФЯ ничем не хуже.


таких давно вымерших языков, как ML и Miranda

Грустное зрелище. Перспективы функционального подхода все еще остаются крайне неопределенными, а в ФП-сообществе уже идут свои "священные войны".