Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 2002 23-02-2007 16:42 | |
Ответ на »сообщение 2000« (Илья Ермаков)
___________________________
А если какой-нибудь дурак на Хаскеле напишет модуль, в который введет неприятные побочные эффекты через Closures?
А вы попробуйте :))
Во первых хаскель ЗАСТАВИТ вас все ваши экспортируемые типы пометить как IO.
Во вторых ни одна функция из вашего модуля не будет работать с другими (несовместимость обычных и IO типов)
Вы что, не понимаете разницы между решением, которое принимается один раз, разработчиком библиотечного модуля - где ошибку по случайности сделать невозможно, и написанием кода клиентом, где он может забыть про инициализацию или захотеть пошустрить?
Я понимаю. Это вы не понимаете разницу между НЕЛЬЗЯ и НЕ РЕКОМЕНДУЕТСЯ.
В хаскеле НЕЛЬЗЯ (физически нельзя, компилятор не допустит)
В обероне НЕ РЕКОМЕНДУЕТСЯ, то есть компилятор все сьест.
Поэтому я вас прошу, не говорите о чем то "нельзя" только потому что ВЫ этого не делаете.
Можно, физически можно, а раз можно, значит БУДУТ делать.
Это показывает вся история программирования, и еще раз повторяю, если вы работаете в лабораторных условиях за стеклянным колпаком, то мы нет, Мы работаем с огромным количеством кода, написанного другими людьми, и нам приходится от этого кода ожидать все что только можно.
Что же касается вашей отмазки, типа дурак все что хош поломает, то вот что интересно.
Почему то вас эта отмазка не устраивает когда речь идет о java или о сишарп.
Там ведь тоже можно правильно писать. Там ведь тоже можно уповать на "грамотное проектирование".
Там ведь тоже можно весь плохой код списать на дураков. Мол не язык виноват а дураки, а вот мы мол, о нет, мы не дураки, мы типа "грамотно проектируем", а следовательно если мы чего то не делаем, то этого делать НЕЛЬЗЯ :)))
Это наивный подход Илья.
№ 2001 23-02-2007 16:20 | |
Ответ на »сообщение 2000« (Илья Ермаков)
___________________________
А если какой-нибудь дурак на Хаскеле напишет модуль, в который введет неприятные побочные эффекты через Closures? Что же, язык плохой, "не позволяет запретить писать дурь"?
Илья, от дураков в ФП есть постулат о невозможности "введения побочных эффектов"...
№ 2000 23-02-2007 16:06 | |
Ответ на »сообщение 1997« (Jack Of Shadows)
___________________________
Ответ на »сообщение 1996« (Илья Ермаков)
___________________________
А я вам говорю можно.
И вы сами это подтверждаете:
Если конкретный тип объекта не экспортирован,
А конкретные типы скрываются всегда.
Если бы да кабы, говорю же "грамотное проектирование решает все проблемы" :))
Джек, ну елки-палки, вы придуриваетесь что ли?
Вы что, не понимаете разницы между решением, которое принимается один раз, разработчиком библиотечного модуля - где ошибку по случайности сделать невозможно, и написанием кода клиентом, где он может забыть про инициализацию или захотеть пошустрить?
Для клиентских модулей нет возможности нарушить инкапсуляцию, забыть про инициализацию и т.п. - хоть головой об стену бейся, не получится...
А если какой-нибудь дурак на Хаскеле напишет модуль, в который введет неприятные побочные эффекты через Closures? Что же, язык плохой, "не позволяет запретить писать дурь"?
Проблема-то в том, чтобы запретить окружению нарушать инварианты модуля. А ежли разработчик дурак, то кто ж его модуль от саморазрушения защитит? И кому такой модуль нужен, чтобы им пользоваться?
№ 1999 23-02-2007 15:57 | |
Ответ на »сообщение 1992« (Geniepro)
___________________________
Ответ на »сообщение 1988« (Илья Ермаков)
___________________________
Ежели уж на то пошло, то объект должен порождаться родительским объектом, а не какими-то там конструкторами, фабриками...
Уважаемый, так речь-то о чем...
А фабрика - это что, как не родительский объект? Фабричные процедуры в Обероне используются редко, это не гибкий подход. Но и с ними тоже все выглядит естественно - объект порождается конкретной сущностью - модулем.
Взгляните на программу как на осязаемую в "железных" понятиях схему - и поймете сущность Оберона.
№ 1998 23-02-2007 15:53 | |
Ответ на »сообщение 1992« (Geniepro)
___________________________
Ответ на »сообщение 1988« (Илья Ермаков)
___________________________
ЗЫ. Рассуждения о понижении уровня абстракции и повышения эффективности программ логично приводят нас к идее программирования в машинных кодах или ассемблере. Вот только эффективность программистов при этом сильно страдает... Так же сильно, как и при переходе от высокоуровневых ФЯ к низкоуровневому Оберону...
Не приводят... Потому что есть понятие оптимума при прочих равных. Для системных задач есть оптимум - паскалевские языки. Уходя на уровень ниже, мы не получаем ничего, а теряем и надежность, и быстроту разработки. Уходить на уровень выше - все равно, что описывать инженерные конструкции вместо чертежей функциями.
№ 1997 23-02-2007 15:50 | |
Ответ на »сообщение 1996« (Илья Ермаков)
___________________________
А я вам говорю можно.
И вы сами это подтверждаете:
Если конкретный тип объекта не экспортирован,
А конкретные типы скрываются всегда.
Если бы да кабы, говорю же "грамотное проектирование решает все проблемы" :))
№ 1996 23-02-2007 15:47 | |
Ответ на »сообщение 1990« (Jack Of Shadows)
___________________________
Ответ на »сообщение 1988« (Илья Ермаков)
___________________________
Объект не может инициализаировать сам себя, объект всегда кем-то порождается, конкретным истоичником-фабрикой - просто и логично.
Илья, вы опять выдаете желаемое за действительное :))
В обероне можно ЗАПРОСТО создать обьект в обход всяких фабрик.
Джек, вам сто рах объясняли, что нельзя! Ну, нельзя!
Если конкретный тип объекта не экспортирован, а создается скрыто, то создать его экземпляр вам не поможет ничего - кроме низкоуровневых хаков....
А конкретные типы скрываются всегда. Естественно, такое должен сделать разработчик класса. Ну так извините, конструктор тоже кто-то должен написать. А клиенты нарушить инкапсуляцию не могут никак.
Или Вас волнует то, что внутри одного модуля нет защиты? Так ее там и не должно быть - внутри модуля no paranoia, все свои. И внутри своего модуля объект часто создается иным путем, не через фабрику.
№ 1995 23-02-2007 15:08 | |
Ответ на »сообщение 1992« (Geniepro)
___________________________
позабытому, увы, ОО-языку Self,
Почему позабытому ? Наоборот один из самых популярных и широко распространенных языков...только под именем javascript :))
№ 1994 23-02-2007 15:08 | |
Ответ на »сообщение 1992« (Geniepro)
___________________________
Нужен нам кульман? Берём дерево, рубим его, пилим на доски, соединяем их в одну широкую_доску, приделываем ножки и линейку - и получаем требуемый кульман! Вот она, фабрика по производству объектов! И никаких классов вообще! Никакого наследования... :о))
Хм, а ведь это функциональный стиль получается... 8-о Если принять, что каждый раз мы изменяем имя этому объекту и делаем недоступными старые имена. Ну типа сборщик мусора прибрался... :о))
№ 1993 23-02-2007 15:06 | |
Ответ на »сообщение 1991« (Geniepro)
___________________________
ups! На сей раз я выдал желаемое за действительное :(
Урок мне, проверять код.
В хаскеле можно помещать actions в списки, но конечно однородные списки, то есть actions одного типа.
В лиспе с этим было бы гораздо проще. Там в список можно че угодно пихать.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|