Ответ на »сообщение 180« (Руслан Богатырев)
___________________________
Для информации: в системе Oberon, точнее, в Oberon System 3 для описания визуальных гаджетов произвольной сложности (GUI-компонентов с persistent-хранением) используется специально разработанный в ETH функциональный язык LayLa.

Кстати тоже самое в Adobe!
http://opensource.adobe.com/group__asl__overview.html#asl_overview_intro_to_adam_and_eve

Индустрия ищет выхода из тупика сложности, в который нас загнали императивные языки.

Начиная с какого то момента мы уткнулись в невидимую стену. Железо с каждым годом удваивает мощности, а вот программы перестали брать новые высоты. Где распознавание образов ? Почему мы до сих пор не говорим с машиной ? Почему машины не переводят с языка на язык на достаточно качественном уровне ?
Где новые элементы управления, интерфейса с машиной ? Долго мы будем елозить мышку по столу, и разговаривать с машиной при помощи ОДНОГО ПАЛЬЦА ?

Сотни и сотни проектов неподьемны, поскольку слишком сложны.
Человек не в состоянии охватить такой обьем, не в состоянии осилить такую сложность.
Да мы можем обвеситься всякими инструментами, UML, IDE, кодогенерация, графики, диаграммы, ALM. Но все это не делает задачу легче. Это все инструменты управления сложностью. Но сложности в задачах меньше не становится.
Мы уперлись. Мы буксуем. Настала пора переложить на плечи машины часть этой сложности, иначе мы просто не сможем двигаться вперед.
Сколько можно жонглировать переменными в целях экономии памяти ?
Вы в сокобан играли ? Это такая игра где в очень ограниченном проастранстве (комнате) нужно передвигать и упорядочивать ящики, используя для этого, ТО ЖЕ САМОЕ ПРОСТРАНСТВО!
Сама задача легкая, подумаешь, вытащил все ящики, и потом занес их обратно в комнату.
Но то что вытаскивать их из комнаты неьзя, делает задачу сложной.

Так вот именно таким вот сокобанством мы все занимаемся! Только с компьютерной памятью.
В результате любая, даже самая простенькая задача превращается в головоломку (коей сокобан и является)
Нам уже давно не нужно это. Мы уже давно можем выходить из комнаты и выносить хоть все ящики (памяти стало немерянно просто). Но мы по прежнему делаем вид, что это так важно!, лишний байтик скономить.

Вот эта вот задача экономии памяти, красной нитью проходящая через ВСЕ императивные языки, через ВСЕ задачи, решаемые программистами на них, поднимает их сложность до идиотически высокого уровня.

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

Ответ на »сообщение 180« (Руслан Богатырев)
___________________________
Некорректно сравнивать заточенный на эти возможности язык с универсальным.

Я о том что чистый функциональный язык позволяет добиться таких результатов, позволяет такую заточку. Позволяет работу в этом направлении. Императивные языки такой возможности не дают. Иначе давно бы сделали. Лишняя производительность карман не жмет.

Т.е. того же самого можно добитсья и с хаскелем. Просто хаскель это opеnsource проект, растущий из университетской среды. Поэтому там акцент научный а не прикладной, как в случае с Эриксоном.
Но потенциал!!! Потенциал, как показывают те же практические работы Ериксона по заточке ФЯ для достижения столь нужного индустрии результата - потенциал доказан!
Т.е. когда (не если а когда!!) начнется гонка гигантов индустрии за производительностью многопроцессорных систем, это гонка будет вестись на территории ФЯ, поскольку с ИЯ брать уже нечего. Выдохся.


Сам язык тут практически ни при чем. Специфика ФП влияет,


Совершенно верно! И я о том же. Неважно какой конкретно язык. Важно что ФП.

Так например Erlang язык динамический, а хаскель статически-типизированный. Очень разные языки. И вместе с тем - оба чистые ФЯ. Что ставит их в отдельную лигу от таких всеядных языков как лисп или ocaml, несмотря на полную поддержку последними ФП.

Тут Остапа понесло...

Если я в чем то ошибся или перегнул палку - укажите. Возможности есть ? да, факты я привел.
Перспективы использования есть ? Да, Ericson это доказал.
Интерес индустрии есть ? Вне всякого сомнения.
Альтернатива у индустрии есть ? Никакой! Мощности уже производятся, а средств их загрузить НЕТ!
Направление развития железа какое - multi-processor, multi-core.
Перспективы у ФЯ есть ? по моему, учитывая все вышеперечисленное, есть и еще какие!

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

Так что не беспокойтесь Руслан. Агитрпроп агитпропу рознь. Займитесь проблемами агитпропа оберона, а мы уж здесь как нибудь сами управимся :))

Ответ на »сообщение 174« (Jack Of Shadows)
___________________________

Еще о мощи: В Ерланг на создание процесса цходит меньше миллисекунды. В java и сишарп - 250 миллисекунд !! И это кстати только до тех пор пока не созданы 2000 процессов. После чего java и сишарп сдыхают.

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

Erricson продает ATM AXD 301 в котором 1.7 миллионов строк кода на Ерланге. Эта ATM обеспечивает 99.9999999% надежности (семь девяток после точки!!) то есть в переводе на человеческий язык 31 МИЛЛИсекунда простоя в год.

Пардон, Erlang -- это язык, который специально создавался для поддержки concurrency, distribution и fault tolerance. Некорректно сравнивать заточенный на эти возможности язык с универсальным. Давайте будем более аккуратными в оценках. При этом в Erlang FAQ признается, что Erlang плохо подходит для таких задач, как image processing, signal processing, sorting large volumes of data и low-level protocol termination. См. http://www.erlang.org/faq/t1.html#AEN43


Короче говоря те факты о мощности, производительности и возможностям написания огромных просто систем практически со 100% надежностью говорят о том что у функциональных языков есть все перспективы стать главенствующей силой в индустрии

Тут Остапа понесло... Пошел чистой воды агитпроп. Не повторяйте ошибок обероновского форума прошлого пошиба. Функциональные языки и без такой агитации заслуживают серьезного внимания и изучения.

Для информации: в системе Oberon, точнее, в Oberon System 3 для описания визуальных гаджетов произвольной сложности (GUI-компонентов с persistent-хранением) используется специально разработанный в ETH функциональный язык LayLa.

Ответ на »сообщение 178« (Jack Of Shadows)
___________________________
Кстати, в тему переписывания ОС на функциональных языках.
Лиха беда начало, как говорится :)))
Кстати - да. http://www.coyotos.org/
А вот здесь, ничего не напоминает? ;) http://www.coyotos.org/docs/bitc/spec.html
С чего бы это? ;)

Ответ на »сообщение 177« (Комбриг)
___________________________
Остается только гадать, почему все производители операционок не кинулись переписывать их на Ерланге

Мешает инерция.
Вот скажем мы все до сих пор уже сколько веков пользуемся юлианским календарем. Хотя он жутко неудобный и стоит нам миллиарды долларов ежегодно. У нас в феврале 28 дней, а в августе 31, потому что черт знает когда какой то римский император Aвгуст обиделся что в его месяце (август) меньше дней (30) чем в месяце Юлия Цезаря (июль - 31 дней). И велел отобрать от февраля (в которм тогда было 30 дней) один день и добавить к своему.
При этом возникла ситуация с 3 месяцами в 31 день подряд (сентябрь тогда имел 31 дней) Поэтому их тоже перемешали. Короче такое вот жонглирование получилось из за прихоти одного самовлюбленного придурка.
Куда делся из февраля еще один день уже не помню. Но тоже не по вселенским причинам было дело.

Короче говоря, почему же мы до сих пор живем покалендарю в котором здравого смысла кот наплакал ?
Ну некоторые скажут что мол люди быдло тупое и умных мало. Этим у нас грешит время от времени info21 на своем модерируемом форуме.
На самом деле конечно люди не дураки. Просто цена такого вот переходя на лучший календарь непомерно высока.
Высока из за инерции. Надо всю жизнь менять. У 6 миллиардов народа! У миллионов компаний у сотен государств.

С ОС та же проблема. Огромная инерция сотен миллионов строк кода, написанных за полстолетия.
Конечно, рано или поздно, якоря на ногах станут обходиться непомерно дорого, а преимущества станут невыносимо привлекательными, и тогда процесс пойдет. Вернее он уже пошел. Но расчитывать на то что сегодня windows, linux, OSX, solaris, as/400 и вместе с ними горы кода написаны на императивных языках, а завтра по мановению волшебной палочки вам за один день все это перепишут на функциональных, может только наивный человек. Вы хоть себе представляете сколько времени требуется это все написать заново ?

Процесс займет как минимум еще полстолетия. Причем начнется (начался уже) он с верхушки, то есть с приложений, и только через долгие годы (скорее десятилетия) затронет ОС.

Кстати, в тему переписывания ОС на функциональных языках.

The OS team at Linspire, Inc. would like to announce that we are standardizing on Haskell as our preferred language for core OS development.

Лиха беда начало, как говорится :)))

В Ерланг на создание процесса цходит меньше миллисекунды. В java и сишарп - 250 миллисекунд !! И это кстати только до тех пор пока не созданы 2000 процессов. После чего java и сишарп сдыхают.
Далее передача сообщений между процессами (message-passing) У Ерланга - меньше миллисекунды, У сишарпа 15 миллисекунд, java вообще сдохла, начав с 15 миллисекунд, и быстро увеличив время до 100,000 миллисекунд при всего лишь ста (!!!) открытых процессах.

Остается только гадать, почему все производители операционок не кинулись переписывать их на Ерланге... Не иначе как всемирный масонский заговор мешает :)))

Ответ на »сообщение 175« (Q. Werty)
___________________________
И в этом смысле результат работы любого функционального языка не может отличаться от результата работы любого другого 

Ну это все равно что скзать, какая разница каким способом сортировать. Почему же некоторые алгоритмы сортировки на порядок быстрее других ?
Видите ли дело еще в том КАК делается а не в том ЧТО делается.
Так например та невиданная скорость работы распараллеленного кода, которую дает Эрланг не может дать лисп.
Дело в чистоте функционального кода. Только чистые функциональные языки могут дать такую производительность. И дело вот в чем. Immutability !!!
Т.е. отсутствие чортового оператора присваивания. Поскольку в императивных языках всегда есть возможность изменить содержимое ячейки памяти, то при создании и обслуживании процесса приходится это учитывать. Отсюда все служебные накладные расходы (синхронизация, race conditions, deadlock etc.) Поэтому в императивных языках процессы такие тяжелые. Поскольку о многом должны заботиться.
В чистых ФЯ. нужда во всей этой машинерии отпадает. Т.е. там процессы работают принципиально по другому.
Поскольку нет shared memory.
Конечно память жрет немерянно. Но зато какая скорость !!! А памямть нынче дешевая.

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

Впечатляет.
Но только я не могу понять одну простую вещь.
Программы, написанные на функциональных языках и программы, написанные на императивных языках, выполняются на одном и том же "железе" - на процессорах с фон-неймановской архитектурой. И в том, и в другом случае процесс выполнения программы - это последовательность инструкций процессора, т.е. выполнение некоторого алгоритма. И как бы наша программа не выглядела на бумаге - в "недрах" самого компьютера и 50 лет назад и сегодня выполняется одна и та же простая вещь - выбери команду-выполни команду-выбери следующую и т.п. И в этом смысле результат работы любого функционального языка не может отличаться от результата работы любого другого - просто процессор не умеет ничего делать, кроме последовательного выполнения своих собственных команд.
А теперь вопрос. Откуда же берется такая невиданная МОЩЬ и ЭФФЕКТИВНОСТЬ программ, написанных на ФЯ? Ведь когда дело доходит до стадии ВЫПОЛНЕНИЯ КОДА никакой разницы между программой, написанной на языке Мумба-Юмба и на языке Юмба-Тумба быть не может - работают же одни и те же команды процессора Х.

Ответ на »сообщение 170« (info21)
___________________________
Поэтому самые по факту мощные языки берут императивную парадигму за основу,

1. Это не факт. Это ваше желание.
Огромное количество народу считает самым мощным языком лисп. Доверять вам больше чем им у меня нет никакого резона.

2. То же самое можно сказать про всех пользователей хаскеля или ерланга или ocaml.
Каждый из них считает самым мощным языком свой.

3. Дело не в том как видите ли машина работает.
В наше время совсем не обязательно писать на ассемблере или на родном API ОС.
Программисты работают в виртуальной машине (java, dotnet, oberon OS, lisp)
А потому могут совершенно спокойно применять функциональный подход.

4. Про то что в хаскеле уже есть автоматическое распараллеливание я уже говорил и ссылки приводил.
Это вам материал для размышлений на тему какой язык самый мощный. :))

5. Erricson продает ATM AXD 301 в котором 1.7 миллионов строк кода на Ерланге. Эта ATM обеспечивает 99.9999999% надежности (семь девяток после точки!!) то есть в переводе на человеческий язык 31 МИЛЛИсекунда простоя в год. Попробуйте добиться такой надежности в таком большом (1.7 миллиона строк) multithread проекте на "мощных" императивных языках вашего выбора. Хоть си, хоть оберон. Потом будем говорить о мощности, да и кстати и о легкости написания распределенных систем такой вот сложности и обьема.

Еще о надежности и МОЩНОСТИ распределенных систем. http://www.sics.se/~joe/apachevsyaws.html
Это сравнение самого популярного, СТАБИЛЬНОГО, и МОЩНОГО web сервера apache? написанного как вы знаете на си, с web сервером YAWS? написанном на Erlang. Так вот апач сдыхает на 4000 процессов. В то время как YAWS спокойно держит 80,000 !!

Еще о мощи: В Ерланг на создание процесса цходит меньше миллисекунды. В java и сишарп - 250 миллисекунд !! И это кстати только до тех пор пока не созданы 2000 процессов. После чего java и сишарп сдыхают.
Далее передача сообщений между процессами (message-passing) У Ерланга - меньше миллисекунды, У сишарпа 15 миллисекунд, java вообще сдохла, начав с 15 миллисекунд, и быстро увеличив время до 100,000 миллисекунд при всего лишь ста (!!!) открытых процессах.
Приведите данные об обероне - сравним.

А пока что приходится констатировать, ваши "мощные" императивные языки годны только для ожидания пока человек кнопку на клавиатуре нажимает :)))


Обучение. Адаптация чужих программ.
Не вы единственный обчались лиспу. Не вы единственый смотрели и правили чужой лисп код. Мой опыт не сходится с вашим. Обучение лиспу ничуть не труднее обучения паскалю, java, сишарпу. А уж читать чужой код я предпочитаю лисповый. Легче просто.

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

Тут про пользу immutable:

http://wesnerm.blogs.com/net_undocumented/2006/06/software_reliab.html