Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 1412 03-11-2006 12:56 | |
>>> мне просто приятнее работать на лиспе
Того же эффекта можно добиться, скажем, втерев стакан водки.
Без изучения 27 Mb текста и вживания в образ паука с Юпитера.
Так что тут дело не в "математических аппаратах" и объективных
преимуществах. Поэтому, Сергей, ждать анализа ФЯ неадекватно.
Вы же можете проанализировать решаемость задачи, прежде чем
приступать к её решению? Вы же не кодер.
Но энтузиазм Jackа меня заряжает.
Программисты современной системой софтостроения вытеснены
в кодирование. Поэтому тут они и плодят мифы, строят свой мирок.
Кому Оберон, кому Ада, кому Лисп, кому семантическое моделирование.
№ 1411 03-11-2006 10:38 | |
Ответ на »сообщение 1409« (Сергей Перовский)
___________________________
Потому, что за разными языками стоят разные математические аппараты.
Утверждение, что один язык ВООБЩЕ лучше другого напоминает утверждение, что комбинаторика лучше, чем математический анализ.
С зыками программирования не попадает!
Если бы сравнивали системы имитационнго моделирования и Excell - тогда можно было бы так аргументировать... Но ЯПОН - "нескольо другая опера". Сначала вы ограничиваете основания своей алгебры вохможностями технологии и архитектуры, потом пидумываете язык "подтягивающий" к тому с чего начали, а потом пытаетесь сравнивать ЭТО с Лиспом, который такими ограничениями не был "обработан"...
Всю математику можно построить на основе теории множеств, но это не означает, что нужно использовать только теорию множеств.
Низьзя. :о)
При исследовании сложных систем свободное переключение между различными математическими аппаратами становится сначала тяжелой необходимостью, потом привычкой.
Правильно. Только зачем при реализации частей, которые позволяют оперировать с этими мат аппаратами, переходить с одного средства реализации (языка) на другое, когда есть достаточно мощное и универсальное?
В основе ЛИСПа лежит лямбда-исчисление, которое очень хорошо подходит для некоторых задач. Но лямбда-исчисление не лучше и не хуже реляционной алгебры или математической логики.
Затраты на "эмуляцию" Пролога Лиспом на порядки меньше, чем наоборот.
Любой язык можно построить на основе ЛИСПа, но это не значит что так ВСЕГДА нужно делать. На ассемблере тоже можно реализовать любой язык с любым ситаксисом и что из этого следует?
Опять сызнова будет "барабан крутить"? Затраты сравните. Умственные и временные.
Так что, давате без фанатизьму.
Да - ни разу.
№ 1410 03-11-2006 10:13 | |
Ответ на »сообщение 1408« (panda)
___________________________
Вы о чем вообще? Неужели так трудно привести несколько простых примеров? Скажем, "функциональный подход дает серьезные преимущества при написании трансляторов, web-серверов, ..."
"Наша песня хороша - начинай с начала..."
Вам приводят простые примеры, вы из них (естественно!) ничего узреть не можете (просто в силу величины и специфики самих примеров) и начинаете возмущаться, что вам кота в мешке подсовывают и на фиг вам вообще оно сдалось, если у вас уже дельфи есть... :о)
Ваши и Джека рассуждения мне напоминают нападки крютых линуксоидов на тех, кто только пробует перейти на Linux из Windows.
Мимо.
№ 1409 03-11-2006 06:54 | |
Ответ на »сообщение 1407« (Владимир Лось)
___________________________
>>>Теперь осталось уразуметь ПОЧЕМУ такое разделение и различия произошли, почему в том или ином случае возникли "предпочтения" для решения тех или иных задач.
Потому, что за разными языками стоят разные математические аппараты.
Утверждение, что один язык ВООБЩЕ лучше другого напоминает утверждение, что комбинаторика лучше, чем математический анализ.
Всю математику можно построить на основе теории множеств, но это не означает, что нужно использовать только теорию множеств.
При исследовании сложных систем свободное переключение между различными математическими аппаратами становится сначала тяжелой необходимостью, потом привычкой. В основе ЛИСПа лежит лямбда-исчисление, которое очень хорошо подходит для некоторых задач. Но лямбда-исчисление не лучше и не хуже реляционной алгебры или математической логики.
Любой язык можно построить на основе ЛИСПа, но это не значит что так ВСЕГДА нужно делать. На ассемблере тоже можно реализовать любой язык с любым ситаксисом и что из этого следует?
Посмотрите ветку по OR/M - тот же JOS пропагандирует специальный язык, для описания отображения объектов в реляционную базу. Хотя можно, конечно, включить в описание объекта методы работы с базой.
У меня код взаимодействия объектов с БД не превышает 1% и учить специальный язык не имеет смысла. Но я легко могу представить ситуацию, в которой такой инструмент весьма полезен.
Так что, давате без фанатизьму.
№ 1408 03-11-2006 06:32 | |
Ответ на »сообщение 1407« (Владимир Лось)
___________________________
>> Все, что публика просит, это более менее строгое позиционирование функционального подхода по классам задач.
А публика понять критерии и причины классификации задач всегда "улавливает"? И почему они исторически именно так сложились? Может критерии сформировались под влиянием применённых когда-то инструментов и их "удобств"?
Вы о чем вообще? Неужели так трудно привести несколько простых примеров? Скажем, "функциональный подход дает серьезные преимущества при написании трансляторов, web-серверов, ..."
Ваши и Джека рассуждения мне напоминают нападки крютых линуксоидов на тех, кто только пробует перейти на Linux из Windows.
№ 1407 03-11-2006 05:57 | |
Ответ на »сообщение 1406« (Сергей Перовский)
___________________________
Все, что публика просит, это более менее строгое позиционирование функционального подхода по классам задач.
А публика понять критерии и причины классификации задач всегда "улавливает"? И почему они исторически именно так сложились? Может критерии сформировались под влиянием применённых когда-то инструментов и их "удобств"?
Когда (и почему) удобнее применять SQL, чем Паскаль тут все понимают.
Когда полезно использовать Пролог тоже некоторые догадываются.
И про ассемблер.
Теперь осталось уразуметь ПОЧЕМУ такое разделение и различия произошли, почему в том или ином случае возникли "предпочтения" для решения тех или иных задач, как они могут быть снивелированы и какие средства для этого наиболее подходящи. Подсказать ответ? :о)
Вот и хочется очертить круг задач, для которых функциональные языки полезны, потому, что соответствуют сути задачи, а не потому, что доставляют эстетическое удовольствие JOS.
Вы предлагаете разбираться с этим на собственном опыте.
А не получается. Для меня ЛИСП остался в далеком прошлом вместе с ФОРТРАНом, СНОБОЛом и КОБОЛом. И особенного впечатления не произвел. Может быть это связано с моей личной убогостью, а может с теми алгоритмами, которые я тогда разрабатывал. Ну, неудобно было его использовать. Мне для тех задач.
Как-то подозрительно лихо вы Лисп в один ряд с фортраном и Коболом поставили...
Как я понимаю, "праверка на адекватность", у вас именно так и происходила: взяли свою задачу и попытались её решить везде одинаково... А потом сделали выводы... :о) Есть и ещё причина. Я с ней тоже столкнулся. Заниматься с Лиспом в ТЕХ условиях (середина 80-х - первая треть 90-х) на ТОЙ технике особого удовольствия не представляло... Это - да. Однако же, исходя из собственного опыта и общения с лисперами, я понимаю, что причины тех неудачных опытов лежали именно в подходе к решению задач на Лиспе а ля Фортран... Опять же причина - в не смене мышления.
№ 1406 03-11-2006 05:37 | |
Ответ на »сообщение 1405« (Владимир Лось)
___________________________
>>>Вы же не можете объяснить в детском саду "пальцами" ОТО!
Ну тут все-таки не детский сад ;)
Все, что публика просит, это более менее строгое позиционирование функционального подхода по классам задач.
Когда (и почему) удобнее применять SQL, чем Паскаль тут все понимают.
Когда полезно использовать Пролог тоже некоторые догадываются.
И про ассемблер.
Вот и хочется очертить круг задач, для которых функциональные языки полезны, потому, что соответствуют сути задачи, а не потому, что доставляют эстетическое удовольствие JOS.
Вы предлагаете разбираться с этим на собственном опыте.
А не получается. Для меня ЛИСП остался в далеком прошлом вместе с ФОРТРАНом, СНОБОЛом и КОБОЛом. И особенного впечатления не произвел. Может быть это связано с моей личной убогостью, а может с теми алгоритмами, которые я тогда разрабатывал. Ну, неудобно было его использовать. Мне для тех задач.
№ 1405 03-11-2006 04:55 | |
Ответ (Всем)
___________________________
Ребята, ну сколько можно?!
Вы просите на "паре примерчиков", показать, то применение чего изучается годами...
Тем более, что по характеру производимых проектных мыслительных манипуляций это кардинально отличается от привычных сред и средств реализаций. Поймите, что подходя даже с шикарными знаниями делфи или си++, вы не поймёте фп, если заново не начнёте учиться программрованию. Овладение этим предметов сторицей воздастся. Даже если и писать проекты непосредственно на Лиспе не придётся, всё равно изучение окажет влияние на мышление и потом всё равно где-то "выстрелит". "С пользой и к обоюдному удовольствию строн". :о)
Хватит уже задавать тупой вопрос "Нет, вы покажите, чем мне это будет лучше?". Как это объяснить, если плоскости даже только в малой степени имеют области взаимного отображения? Или по другому: двумерникам очень трудно представить трёх-мерный мир. Для адекватного восприятия и налаживания контактов вам нужно сначала овладеть алфавитом того, в чём JOSh работает.
Вы же не можете объяснить в детском саду "пальцами" ОТО!
№ 1404 03-11-2006 02:48 | |
Ответ на »сообщение 1403« (Max Belugin)
___________________________
Вы думаете при наличии библиотеки программа получилась бы короче или понятней чем на питоне или рубях?
В данном случае нет. Програмка действительно мелкая. Для получения настоящего выигрыша нужен обьем "помясистее" :))
А преимущество было бы в том что мне просто приятнее работать на лиспе. Согласитесь тоже немаловажный фактор в работе. :))
№ 1403 03-11-2006 00:25 | |
Ответ на »сообщение 1402« (Jack Of Shadows)
___________________________
А чем для таких-то задач личп лучше?
Вы думаете при наличии библиотеки программа получилась бы короче или понятней чем на питоне или рубях?
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|