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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 1432—1423 | 1422—1413 | 1412—1403 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 409


    № 1422   06-11-2006 13:19 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1419« (Jack Of Shadows)
    ___________________________
    Что это означает ? Это означает что импетаривное программирование совершенно не нужно для того чтобы научить человека правильно программировать.
    ...на функциональном языке.
    Так более корректно, Вам не кажется?

    Ответ на »сообщение 1421« (Артем)
    ___________________________
    :о) Супер!!!
     hugi


    № 1421   06-11-2006 04:09 Ответить на это сообщение Ответить на это сообщение с цитированием
    Операции присваивания вас погубят! Каждая операция присваивания приближает использующих ее программистов к смерти. Удивительно, как здравомыслящие люди до сих пор не распознали смертоносности этой операции. Несмотря ни на что, использование операции присваивания неуклонно растёт. С операциями присваивания связаны все телесные недуги и вообще все людские несчастья :
    1. Практически все, страдающие хроническими заболеваниями программисты, использовали операции присваивания. Эффект явно кумулятивен.
    2. 99,9 % всех, умерших от рака программистов использовали операции присваивания.
    3. 99.7 % программистов - жертв автомобильных и авиа катастроф использовали операции присваивания как минимум за две недели до фатальной даты.
    4. 93,1 % малолетних преступников, родителями которых являются программисты, происходят из семей, где постоянно используют операции присваивания.

    Ещё более убедительным доказательством служат исследования, полученные известным коллективом учёных - медиков: у программистов, которых принудительно заставляли набирать (без использования буфера) в текстовом редакторе  notepad по 10 000 операций присваивания в в день в течение месяца, возникли серьезные проблемы со здоровьем. Некоторым даже потребовалась реанимация.
    Единственный способ избежать губительного воздействия операций присваивания – изменить стиль программирования. Используйте чистое функциональное программирование. От него, насколько нам известно, ещё никто не умирал.


    № 1420   06-11-2006 02:09 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1415« (Сергей Перовский)
    ___________________________


    Кстати, как насчет сборки мусора в системах реального времени?


    http://www.memorymanagement.org/bib/gc.html#real-time

    http://www.memorymanagement.org/bib/a.html#baker


    № 1419   06-11-2006 01:20 Ответить на это сообщение Ответить на это сообщение с цитированием
    На днях ковырялся в DrScheme. Обнаружил весьма интересную вешь.
    Для начала расскажу что такое DrScheme.

    Есть такой известный на западе проект http://www.teach-scheme.org/ спонсриуемый Американским Научным Фондом.
    Это проект создан для распространнения программирования среди студентов.
    Ближайшим аналогом в России наверное будет проет info21
    Только teach-scheme наверное на порядок помощнее по охвату, спонсированию и конечно известности.
    В качестве обучающего языка программирования используется, как понятно из  названия, диалект лиспа, scheme.
    В качестве среды - разработанная ими же DrScheme. А основным учебным материалом является книга которую я многократно здесь упоминал: htdp.org
    Одной из основных идей является то что язык программирования для обучения должен быть как можно более простым и исключать все что лишнее или мешает процессу обучения.
    Ну точно как оберон скажете вы.
    Однако достигают такой вот  простоты они совершенно другим образом.
    Не обрезают язык, выбрасывая из него "все лишнее", а создают графическую среду, в которой можно ограничивать язык по нескольким уровням.
    Самый первый уровень включает в себя только самые базовые конструкции языка. Любая попытка использовать функции или возможности языка вне этого базового набора просто выдаст ошибку.
    Далее с ростом знаний студента и по мере прохождения материала, открываются все более высокие уровни языка, давая доступ к более сложным и может даже более опасным конструкциям языка и концепциям программирования.
    Всего там 5 уровней от Beginning Student до Advanced Student.
    Так вот господа, основа основ императивного программирования, оператор присваивания, открывается только на самом последнем уровне.
    Причем если вы просмотрите материал курса то поймете что практически весь материал проходится до этого.
    То есть к моменту когда студенту становится доступным оператор присваивания, он уже курс практически прошел. А материала там немало.
    Что это означает ? Это означает что импетаривное программирование совершенно не нужно для того чтобы научить человека правильно программировать.
    Что давать его надо в самом конце, как технический прием, позволяющий работать на компьютерах с той архитектурой, которая исторически сложилась. Но ни в коем случае не во время обучения и становления программиста. Иначе частный, технический метод общения компьютера с внешним миром, в сознании ученика подменит само понятие программирования. Что мы с вами и наблюдаем в массовом порядке в учебных заведениях, где программирование ведется на базе семейства паскалей/java/си

    Это как вы видите не только мое мнение. Это мнение огромного количества людей, стоящих за проектом teach-scheme.
    Вот такоя вот пища для размышлений :))




    № 1418   06-11-2006 00:26 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1414« (al_mt)
    ___________________________
    В конце-концов, пришли к выводу (и Сишники согласились), что наличие сборщика мусора, когда не требуется всенепременно явно освобождать память, правоцирует программиста на неаккуратный код.
    Сомнительно...
    Нашли один пример, когда наличие сборщика мусора в Си привело к  возникновению очень тяжелоотлавливаемой ошибки в большом проекте.
    1. Чтой-то за зверь такой "Си со сборщиком мусора"? Или это это очередная прилепка в виде "hениальных указателей" а ля ACE, boos или Loki?
    2. Если вы такую одну ошибку строго определили - не приведёте ли её, хотя бы общее, описание. Интеренсо же!


    № 1417   05-11-2006 07:06 Ответить на это сообщение Ответить на это сообщение с цитированием
    Writing a Lisp interpreter in Haskell
    http://joel.reddit.com/goto?rss=true&id=pd54

    Пост иллюстрирует преисущества хаскеля на примере написания простенького интерпретатора лиспа.


    № 1416   05-11-2006 03:17 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1415« (Сергей Перовский)
    ___________________________

    ... это не опечатка, а ошибка проектирования, которую в системе со сборкой мусора просто не уловить.
    Еще как уловить.
    По кр. мере в Блэкбоксе: надо просто реализовать предопределенный метод FINALIZE, который вызывается в момент "сбора" данного объекта.

    "Применять сборку мусора" -- это quasi как "применять технику безопасности".
    Надеюсь, диссонанс Вам слышен в правой части -- это укажет на недопонимание в левой.
    "Pensate!" (C) Giuseppe Verdi


    № 1415   04-11-2006 16:35 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1414« (al_mt)
    ___________________________
    >>>наличие сборщика мусора правоцирует программиста на неаккуратный код.
    +1
    Когда задумывается новый объект, необходимость четко понять, когда он должен быть уничтожен, заставляет более точно осознать ЗАЧЕМ этот объект нужен.
    Количество AV из за неправильного уничтожения объектов у меня в среднем 1(один) на проект. Причем это не опечатка, а ошибка проектирования, которую в системе со сборкой мусора просто не уловить.
    Вот в NET, когда объект не является собственностью приложения, автоматическая сборка мусора необходима. Так, что у всякого средства есть область применимости.
    Кстати, как насчет сборки мусора в системах реального времени?


    № 1414   04-11-2006 01:23 Ответить на это сообщение Ответить на это сообщение с цитированием
    К слову о сборщике мусора. Мы вчера обсуждали на работе разницу между C++ и Delphi (не спорили, что лучше), на предмет что есть в одном такого, чего нет в другом, как это применить и как прикрутить к Delphi шаблоны в Сишном смысле (например).
    Говорили и о сборщике мусора. В конце-концов, пришли к выводу (и Сишники согласились), что наличие сборщика мусора, когда не требуется всенепременно явно освобождать память, правоцирует программиста на неаккуратный код. Нашли один пример, когда наличие сборщика мусора в Си привело к  возникновению очень тяжелоотлавливаемой ошибки в большом проекте. Я не Сишник, тонкости не передам, но в общих чертах, один модуль написан с кучей мусора, и при стыковке с другим под отладочной библиотекой всё нормально, а в откомпилированной конечной версии - баг :( Так что, сборщик мусора штука хорошая, но видимо не для всех стилей программирования.

    P.S. Кажется начал въезжать в принципы ЛИСПа :)))


    № 1413   03-11-2006 13:00 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1406« (Сергей Перовский)
    ___________________________
    Функциональщик: Сборка мусора это один из механизмов функционального программирования. Впрочем полезный и сам по себе. Вам императивщикам будет очень полезен.

    Императивщик: Чем полезен, пример можно ?

    Ф: Показывает пример в 4 строчки. Видишь не нужно в ручную освобождать память.

    И: И это ВСЕ ? Одна строчка ? Ради этого многократно усложнять компилятор и тащить за собой VM ?

    Ф: Это на маленьком примере одна строчка. Но на больших проектах она выливается в огого (расписывает прелести сборщика мусора)

    И: Да ты покажи, я так понять не могу. Или если не можешь показать то хотя бы приведи класс задач для которых сборка мусора может быть полезной. Позиционируй так сказать по классам задач, в процентном отношении.

    Ф: Ошалело смотрит на И пытаясь сообразить как в принципе можно в процентах по классам задач выразить пользу сборки мусора.

    Ф: Сборка мусора полезна сама по себе, вне относительности к классу задач.

    И: Так не бывает. Вот SQL он полезен для БД, а Пролог он тоже для чего то там полезен (Я правда в это не верю, поскольку сам никогда в жизни не только не пользовался Прологом но даже и задачи такой не могу представить где он мне понадобился бы. Но говорят кто то им пользуется). Универсальных инструментов не бывает. А вдруг мне сборка мусора не понадобится. Да и вообще, количество строчек, которыми я осовбождаю память в моих проектах не превышает 1% (может даже меньше). Дергаться нет смысла.

    Ф: Да но это один процент строчек ответственен за 50% всех ошибок в твоей программе. Из за этого 1% строчек рост твоей программы в какой то момент просто останавливается.

    И: Докажи, в моей практике этого никогда не было. Это все слова.

    Ф: А ты попробуй, собственный опыт лучше любых доказательств.

    И: Сначала убеди, потом попробую.

    И так по бесконечному кругу.
    ------------------------------

    Сергей, функциональный подход к решению задач, это не специфический инструмент как SQL или Пролог.
    Это универсальное средство, как сборка мусора, которая дает пользу независимо от того какую задачу вы решаете.
    Разговоры о том что какой то класс задач лучше подходит а какой то хуже - это в лучшем случае миф, в худшем вранье.

    Как в приведенном мною примере с библиотекой sftp, все просто упирается в наличие определенных библиотек и инструментов. Дельфи ничуть не лучше для задач с GUI чем лисп. Как язык. Но вот то что вместе с языком поставляется программа (Delphi IDE) для рисования окошек и бросания кнопочек и других визуальных обьектов, а вместе с лиспом такой программы не поставляется - именно это является решающим фактором при выборе языка для конкретной задачи, а не то что функицональный ли язык или императивный.
    Если функциональынй и имепративный языки оба предоставляют все небходимые для решения задачи инструменты (билиотеки, билдеры итд), то функциональный язык всегда предпочтительнее.

    Именно из за такой мелочи как отсутствие GUI билдера для лиспа, я виндовые программы пишу на делфи/сишарп.
    Плююсь но пишу. Завтра лисп перекочует на dotnet, или кто то напишет к нему нечто похожее на Delphi IDE, и этот класс задач буду делать на лиспе.

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



    Для меня ЛИСП остался в далеком прошлом вместе с ФОРТРАНом, СНОБОЛом и КОБОЛом. И особенного впечатления не произвел. Может быть это связано с моей личной убогостью, а может с теми алгоритмами, которые я тогда разрабатывал.


    :)))) Помните наналогию с машинами и самолетом которую я приводил.
    "Да ездил я на этих запорожцах, москвичах и самолете, все хреново ездют (а самолет хуже всех), мой мерседес лучше." :))


    <<<... | 1432—1423 | 1422—1413 | 1412—1403 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 409


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

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

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

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

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

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