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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 2012—2003 | 2002—1993 | 1992—1983 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 351


    № 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 одного типа.

    В лиспе с этим было бы гораздо проще. Там в список можно че угодно пихать.


    <<<... | 2012—2003 | 2002—1993 | 1992—1983 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 351


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

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

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

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

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

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