Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 1182 07-09-2006 08:47 | |
Ответ на »сообщение 1181« (Trurl)
___________________________
Нет, это некоторые называют расширение наследованием, а записи объектами. ;-) Сразу говорю, чтобы никто не обижался - дальше будет идти полушутливый стеб. У меня при созерцании оберонистов возникает ассоциация со старообрядцами и я вспоминаю картину Сурикова с разгневанной боряней Морозовой. :) Я даже немного побаиваюсь их трогать - еще заклюют :)
№ 1181 07-09-2006 08:37 | |
Ответ на »сообщение 1158« (Артем)
___________________________
Если под чистотой понимать то, что вместо классов мы употребляем записи, а наследование называем расширением, то не есть ли это очередной экзотический зоопарк, идущий вразрез с общепринятой терминологией? :)
Нет, это некоторые называют расширение наследованием, а записи объектами. ;-)
№ 1180 07-09-2006 08:32 | |
Ответ на »сообщение 1177« (Владимир Лось)
___________________________
То, что я сейчас скажу не к вам конкретно обращено и не ставит целью как-то вас обидеть:
А КНИЖКИ ПРО СТРУКТУРЫ ДАННЫХ И АЛГОРИТМЫ И ПРОЕКТИРОВАНИЕ ЧИТАТЬ НЕ ПЫТАЛИСЬ?
У меня была программа на дельфи для пострения границ цветовых областей (векторизации). Так вот на ней не было и строчки даже на встроенном ассемблере. Но оня на порядок обгоняла "конгломерат" из Си и ассемблера...
А вы думаете, чтобы в .net избавиться от unmanaged-кода надо книжки по структурам данным и алгоритмам читать? :) А как же вызов специфического API или взаимодействие с унаследованным кодом (написанным, например, на C)?
№ 1179 07-09-2006 08:23 | |
Ответ на »сообщение 1165« (Владимир Лось)
___________________________
Скажите, в процентном отношении, сколько таких "надстройщиков" языка существует?
Отвечу честно --- в процентах не знаю. :-) Те или иные макросы в своих проектах используют, я думаю, большинство лисперов, но где проходит грань между парой макросов "для себя" и действительно серьезным DSL?
И есть ли в конторах средства и время заниматься подобными вещами. Уверяю вас, что в тех местах, где на подобные занятия есть и время, и деньги (и программисты только этим и занимаются, получая при этом ДАЛЕКО не 100 доллярив), скорее всего, потребностей "остального мира", занимающегося той же тематикой, не знают. Действительно универсальных решений даже для "той же ниши" не существует.
ИМХО, никто в таких корпорациях за универсальностью и не гонится. Просто DSL служит средством построения моделей предметной области, только чуть более удобным и гибким, чем библиотека классов или подпрограмм. А по нынешним временам --- кто быстрее реагирует на внешние раздражители, тот и выиграл. По этой же причине лично мне очень мало известно о внутрикорпоративных разработках в области DSL --- их не афишируют, считая (вполне справедливо) конкурентным преимуществом.
№ 1178 07-09-2006 08:14 | |
Ответ на »сообщение 1173« (Lisp Hobbyist)
___________________________
Кстати, интересно, а Ваше решение было продиктовано конкретным практическим опытом макрописательства на Nemerle/Lisp или оно априорно?
Как говорится, не читам-с, но осуждам-с? Нет. "Наше" решение было продиктовано ознакомлением с e-литературой по языкам. Если при выборе того или иного средства будет требоваться практический опыт на нем в течении n-го количества лет, то поле выбора значительно сужается :)
Кроме того, у меня есть определенное доверие к (кто-то будет сейчас смеяться) разработчикам того же Microsoft. Если бы в microsoft research вместо F# разрабатывали бы LISP for Visual Studio, я бы более задумался над этим. Можно делать бла-бла-бла, о том как доверять таким буржуинам, но в ответ я могу спросить, а почему я должен больше доверять кому-то в форуме, чем специалистам Microsoft? :)
№ 1177 07-09-2006 08:00 | |
Ответ на »сообщение 1168« (Артем)
___________________________
Ответ на »сообщение 1166« (Владимир Лось)
___________________________
Ну назвать запалом от водородной бомбы функциональные языки трудно. Если бибизяна будет будет в них творить, то программа или просто не будет работать, или будет работать очень медленно.
Это вы ещё Вы не видели "некоторых решений" на Си++... К тому же над QNX, которая, типа "система реального времени". После этого, "с отчаянья" и в винде можно начать РВ-системы писать. Такое убожество иногда встречается - просто ума не приложишь "в каком лесу оно росло"?
Не зависит от языка, в каком из них делаются не то, что не эффективные, а просто глкпые решения. ОНО и на ассемблере тот же результат будет получать...
Вот C++ можно назвать таковым запалом. Поэтому одной из целей создания следующей генерации ООП языков, вроде Java и .Net-семейства, была минимизация негативных последствий неквалифицированного программирования. Я и сам стону, когда в C# приходится писать unmanaged code, но понимаю, для чего это все эти танцы с бубном были сделаны - для защиты от бибизян.
То, что я сейчас скажу не к вам конкретно обращено и не ставит целью как-то вас обидеть:
А КНИЖКИ ПРО СТРУКТУРЫ ДАННЫХ И АЛГОРИТМЫ И ПРОЕКТИРОВАНИЕ ЧИТАТЬ НЕ ПЫТАЛИСЬ?
У меня была программа на дельфи для пострения границ цветовых областей (векторизации). Так вот на ней не было и строчки даже на встроенном ассемблере. Но оня на порядок обгоняла "конгломерат" из Си и ассемблера...
Тут тоже все далеко не так однозначно. Ведь даже квалифицированные программисты когда-то были, как вы говорите, "животными". Зачем же отказывать кому-то в праве творить? :) Другое дело, что чье-то творчество со временем улучшается, а чье-то - нет. Но тут ничего не поделаешь - закон природы. :)
А я и не спорю, но когда "квалифицированному программисту" уже под 50 (или даже чуть "за"), а он оправдывает применение "Copy-Paste", причем в непрерывном участке, причём настолько смрадного кода, тут уже надо подумать...
ЗЫ Господи, а есть ли вообще в природе конторы, где (хотя бы!) грамотно пишут программы?
ЗЗЫ В прошлом году, когда я менял место работы, в одной конторе дали мне на собеседовании "тест". Я, когда его получил, не поверил, думал, что шутят, а человек, что меня тестировал, сказал, что я - второй за два года, кто прямо тут за столом эту задачу решил. До сих пор не могу понять, может это он так прикалывался?...
№ 1176 07-09-2006 07:53 | |
Ответ на »сообщение 1163« (Lisp Hobbyist)
___________________________
Идея языка-ядра, которое расширяется таким образом, что формирует вокруг себя другие языки, вполне понятна. Достаточно поверхносто знаю Рефал, но думаю, он вполне может справиться с такой ролью расширяемого языка. Но если подумать, то какие расширения языку требуются? В синтаксисе, семантике, прагматике?
Если только в прагматике и требуется минимальное языковое ядро ("микроядерная" архитектура), то чем не нравятся те же Occam или Oberon?
№ 1175 07-09-2006 07:47 | |
Ответ на »сообщение 1170« (Max Belugin)
___________________________
"Удивительный язык" на задворках отрасли скорее всего из-за своей низкоуровневости, чем из-за отсутствия стандарта.
А Форт ни низко-, ни высокоуровневый. В рассуждизмы здесь впадать не хочу, поговорим о другом.
Прошло какое-то время и ООП стало давлеющей "идеологией". Расцвет Форта пришёлся на время "чуть раньше" ООП. Теперьб посмотрите, практически, сейчас наибольшую популярность, развитие и распространение получили языки, в которых была "привита" ООП (а отсюда и поддержка средами, наборы многокртнопользуемых библиотек и проч. последствия). Но в этих языках введение ОО базировалась на ограничениях самого языка. Вспомните синтаксис Паскаля или Си. По сути дела, кроме введения нескольких новых служебных слов и небольшого изменения синтаксиса, ничего кардинально нового не произошло. Переучиваться можно было с меньшей затратой сил. Это, кстати, послужило причиной возникновения другого "феномена" эпохи ООП: имея языки с поддержкой ООП, люди, в массе своей, так и не стали ПРОЕКТИРОВАТЬ в духе ООП. В большинстве своём, они использовали, например Си++, просто как "улучшенный Си". В том же дельфи основная масса так бы и следовала процедурному стилю (она так и делает обычно), если бы использование VCL не принуждало их "вспоминать" об ООП.
В моей нынешней фирме ситуация вообще катастрофична. Я не просто не могу заставить людей поверить, что переход на ОО-парадигму лучше, я не могу просто объяснить им, что я имею в виду: разрыв в понятиях, смысловой и понятийной основе становится катастрофическим. Сейчас, действительно, уже происходит расслоение (преимущественно культурно-возрастное), когда "старики" просто уже не могут понять что же это им пытаются втолковать и почему это надо в своих программах отходить от единого цикла длиной в 20 000 строчек в пользу каких-то "разрозненных", "спорадических" "вспышек"-активностей в каких-то там классах-шмассах и объектах-шмобъектах... Одним из "отчаявшихся" на решительный шаг "старичков" была переписана его часть в которых весь код и данные он умудрился упрятать в ОДИН объект с кучей полей и ОДНИМ методом... А потом искренне недоумевал, что жэ это мне от него, в конце концов, надо... :о)
№ 1174 07-09-2006 07:44 | |
Ответ на »сообщение 1170« (Max Belugin)
___________________________
"Удивительный язык" на задворках отрасли скорее всего из-за своей низкоуровневости, чем из-за отсутствия стандарта.
Вообще-то для Форта в 1994 г. был принят американский ANSI-стандарт, а в 1997 г. и международный ISO-стандарт. Что до низкоуровневости, то отсутствие стандартов и низкоуровневость никак не помешали разным ассемблерам получить достаточно большую популярность. Да и по уровню абстракций Forth не сильно отличается от C.
№ 1173 07-09-2006 07:42 | |
Ответ на »сообщение 1164« (Артем)
___________________________
Я бы, все-таки, предпочел более высокоуровневый и удобоваримый язык с макросами, такой как Nemerle, или систему подсоединения внешних DSL к тому же C# :) А в Лиспе те же DSL выглядят настолько же ужасно, как и сам язык :)
Никто на Ваше право выбирать язык не покушается. Кстати, интересно, а Ваше решение было продиктовано конкретным практическим опытом макрописательства на Nemerle/Lisp или оно априорно?
Впрочем, это тоже дело вкуса. Есть ведь люди, кому нравится такой синтаксис. :)
ИМХО, вопрос "нравится/не нравится" уместен когда обсуждается применение фигурных скобок против BEGIN...END --- это субъективно. В случае же с Лиспом у S-выражений имеются кое-какие объективные преимущества, в силу которых их необычность (она, кстати, быстро проходит) совершенно не играет роли. Другое дело, что эти объективные преимущества могут быть оценены по достоинству лишь после достижения определенного барьера сложности (и скорее всего, не во всех предметных областях), подобно тому, как бухгалтер скорее всего не знает, зачем нужна бесскобочная нотация Лукашевича.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|