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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.

Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.

Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.

 Jack Of Shadows

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

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

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


Всего в теме 5502 сообщения

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

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


Смотрите также обсуждения:
Средства разработки. Языки программирования.
  • Delphi 4 or Delphi 5
  • Что приобрести в качестве средства разработки?
  • Delphi6
  • Delphi vs PowerBuilder
  • Сравнение компиляторов
  • Вот и вышла Delphi 7... Вы рады?

  • <<<... | 192—183 | 182—173 | 172—163 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 533


    № 182   15-06-2006 16:09 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 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. Но все это не делает задачу легче. Это все инструменты управления сложностью. Но сложности в задачах меньше не становится.
    Мы уперлись. Мы буксуем. Настала пора переложить на плечи машины часть этой сложности, иначе мы просто не сможем двигаться вперед.
    Сколько можно жонглировать переменными в целях экономии памяти ?
    Вы в сокобан играли ? Это такая игра где в очень ограниченном проастранстве (комнате) нужно передвигать и упорядочивать ящики, используя для этого, ТО ЖЕ САМОЕ ПРОСТРАНСТВО!
    Сама задача легкая, подумаешь, вытащил все ящики, и потом занес их обратно в комнату.
    Но то что вытаскивать их из комнаты неьзя, делает задачу сложной.

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

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

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




    № 181   15-06-2006 15:45 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 180« (Руслан Богатырев)
    ___________________________
    Некорректно сравнивать заточенный на эти возможности язык с универсальным.

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

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


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


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

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

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

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

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

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


    № 180   15-06-2006 15:19 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 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.


    № 179   15-06-2006 15:08 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 178« (Jack Of Shadows)
    ___________________________
    Кстати, в тему переписывания ОС на функциональных языках.
    Лиха беда начало, как говорится :)))

    Кстати - да. http://www.coyotos.org/
    А вот здесь, ничего не напоминает? ;) http://www.coyotos.org/docs/bitc/spec.html
    С чего бы это? ;)


    № 178   15-06-2006 14:32 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 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.

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


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


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


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

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




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

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




    № 174   15-06-2006 11:06 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 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% надежностью говорят о том что у функциональных языков есть все перспективы стать главенствующей силой в индустрии, в то время как имепративные могут противопоставить только лишь свою экономичность, т.е. возможность работать на оборудовании столетней давности :)))


    № 173   15-06-2006 09:03 Ответить на это сообщение Ответить на это сообщение с цитированием


    <<<... | 192—183 | 182—173 | 172—163 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 533


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

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

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

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

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

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