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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 2362—2353 | 2352—2343 | 2342—2333 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 316


    № 2352   30-03-2007 18:05 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2350« (Geniepro)
    ___________________________

    Ответ на »сообщение 2349« (Илья Ермаков)
    ___________________________
    Ну вот Вы сами и признали, что в "жёстком" РВ языкам со сборкой мусора делать в общем-то, нечего... :о))

    Во-первых, где я это признал? :-)
    А во-вторых, в таком ключе разговора я обычно говорю не об Оберонах конкретно, а о Паскалевском семействе в целом. Есть сборщик мусора, нет сборщика мусора - в данном контексте детали.


    № 2351   30-03-2007 17:45 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2348« (Илья Ермаков)
    ___________________________
    Селяви такова, что реальный выигрыш дает в первую очередь дисциплина и отказ от излишеств.
    Правильно, но вот в достижении этого результата мы с вами расходимся.
    Вы считаете что отказаться от излишеств можно УГОВОРИТЬ. Это мягко говоря не подтверждается всей историей программирования.

    Функциональщики (те которые ратуют за чистый ФЯ) считают что добиться дисциплины программирования можно только если расхлябанность ЗАПРЕТИТЬ.
    И опять таки реальный опыт внедрения ФЯ в индустрию (те же ericson) показывает, что да, этот подход работает.
    Запретили размазывание состояния по всей программе, и пожалуйста, надежность системы подскочила в разы. Безо всяких уговоров, лекций про грамотное проектирование и прочей лабуды, которая для болтовни на форумах хороша, а как результата добиваться, так сразу выясняется что эти самые мифические программисты с "грамотным проектированием" жуткий дефицит. Ну нигде их не найдешь. :))


    По-моему, сегодня для ФП риск пойти по тупиковому пути нагромождения собственных сложностей вполне реален...


    А вы не бойтесь. Практика все расставит по местам.


    Времена изящного и стройного ЛИСПА, видать, прошли... :-)
    А по моему только начинаются.
    Лисп всегда был в загоне специфических приложений.
    Это сейчас он начинает выбираться из своей пещеры.

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

    Оберон вполне может быть и жемчужина императивного программирования, так же как и катана - жемчужина холодного оружия. Но поезд уехал :) вы господа опоздали лет на 20 с признанием оберона.



    № 2350   30-03-2007 17:45 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2349« (Илья Ермаков)
    ___________________________

    Ну вот Вы сами и признали, что в "жёстком" РВ языкам со сборкой мусора делать в общем-то, нечего... :о))


    № 2349   30-03-2007 17:12 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2347« (Geniepro)
    ___________________________

    Ответ на »сообщение 2344« (Илья Ермаков)
    ___________________________
    Вы меня, конечно, извините, но пока что в "жёстком" РВ рулит именно язык Си и ОСРВ, на нём написанные - например QNX.
    Вот у Оберонов с их сборщиком мусора, не соответствующим требованиям к РВ, в РВ делать как-раз таки нечего.

    В жестком РВ в ряде стран Це вообще законодательно запрещен к использованию :-)
    Стандарт де-факто в авиации и космосе за рубежом - Ада. В России - Модула-2 (на которой весь ГЛОНАСС, в частности).
    Оберон выбран Европейским консорциумом гражданской авиации как основной язык бортового ПО.
    На Обероне написаны 3 промышленные ОС ЖРВ - XO/2, XOberon и JBed.
    А реализации сборщика мусора, соответствующие требованиям РВ, существуют - как раз в этих ОС (как они реализованы, увы, не знаю - а хотелось бы, конечно, хоть глазком :-) ). В самых "жестких" модулях, конечно, автоуправление памятью отключается.


    № 2348   30-03-2007 17:08 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2346« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 2344« (Илья Ермаков)
    ___________________________
    которые в их задачах могли бы дать реальный выигрыш

    Селяви такова, что реальный выигрыш дает в первую очередь дисциплина и отказ от излишеств. Для рядового программиста упоминания о "жестком РВ" полезны тем, что это та область, в которой терпят мгновенный крах мейнстримовские мифы и "погремушки"...
    У ФП есть прекрасные качества, однако уж очень сильно иногда сентенции программистов от ФП начинают сходиться с аргументами цешников, что само по себе настораживает...
    По-моему, сегодня для ФП риск пойти по тупиковому пути нагромождения собственных сложностей вполне реален... Времена изящного и стройного ЛИСПА, видать, прошли... :-)

    Кстати, о жестком РВ - это весьма широкий круг управляющих задач. Это ведь не только спутники, самолеты, поезда и АЭС. Самая обычная промышленная автоматика, например. Если сейчас в России из-за практически угроханного машиностроения про эти задачи уже практически позабыли, то для развитой промышленности уже это само по себе является приличным сектором потребления разработок ПО...


    № 2347   30-03-2007 17:04 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2344« (Илья Ермаков)
    ___________________________

    Однако есть две категории реального времени - мягкое и жесткое. Телекоммуникации не относятся к последней категории. Чтобы в нее попасть, нужно к надежности (которую ФП дает) добавить предельную эффективность, да еще уложиться в ограничения оборудования - по памяти, например.
    В жесткое РВ не прорваться ни Цям, ни ФП - правда, по совершенно противоположным причинам. Нужны инженерные компромиссы, композитные решения. В центре треугольника "надежность"-"эффективность"-"динамичность" сегодня лежит только Паскаль-семейство.

    Вы меня, конечно, извините, но пока что в "жёстком" РВ рулит именно язык Си и ОСРВ, на нём написанные - например QNX.

    Вот у Оберонов с их сборщиком мусора, не соответствующим требованиям к РВ, в РВ делать как-раз таки нечего.

    Та мифическая система управления какой-то латиноамериканской АЭС (где-то то ли в Бразилии, то ли в Венесуэлле), вполне возможно, что если она и написана на языке обероновского семейства, то на урезанной Си-подобной версии Оберона, с вырезанным сборщиком мусора, и от всего Оберона в ней только фишки из Модулы-2 - модульность и сильная статическая типизация...
    Это, конечно, голословное утверждение, равно как и любое противоположное - ведь толковой и точной информации об этой системе нет ни у кого, кроме её создателей, которые всё скрывают...

    Максимально эффективные и производительные однопроходные сборщики мусора доступны только языкам с однократным присваиванием - то есть различным чистым ФЯ...


    № 2346   30-03-2007 16:36 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2344« (Илья Ермаков)
    ___________________________
    Однако есть две категории реального времени - мягкое и жесткое.
    Первый раз такое слышу. Однако если даже это и так, то получается что это ваше "жесткое РВ" - очень и очень и  очень и очень  узкий круг задач.
    Так чтоит ли для такого узкого круга задач создавать инструмент ОБЩЕГО назначения, и заставлять всех остальных программистов (99%) отказываться от более легких и надежных инструментов, которые в их задачах могли бы дать реальный выигрыш. При этом какие то там примущества в "жестком РВ" им по барабану.
    Получается что обероны - это узкоспециализированный инструмент, для широкого круга задач приспособленные гораздо хуже, нежели ФЯ.


    № 2345   30-03-2007 16:29 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2343« (Илья Ермаков)
    ___________________________
    А вот "разбавление" кода вспомогательными "опорными точками", которые не позволят программисту с замыленным от усталости взглядом в три часа ночи сделать ляп - очень даже коррелирует.
    Используя ваш же аргумент - корреляции между разбавлением кода и его надежностью - никакой.
    В конце концов именно ФЯ достигли надежности на реальных и больших и сложных проектах, которую пока ни один ИЯ (ключая и оберон) обеспечить не могут. Примеры эрланга здесь уже многократно приводились.
    Причем улучшение показателей бло по всем фронтам, а не только по одному за счет ухудшения в других.
    То есть не только надежность системы сильно повысилась, но и количество кода уменьшилось, и скорость разработки увеличилась.

    Когда нужно обеспечивать надежность критических систем, то надеяться на "разбавление" кода вспомогательными "опорными точками", это значит ставить во главу угла человека. А он всегда подведет, сколько вы там ему подпорок не ставьте, и соклько про "грамотное проектирование" не талдычьте.
    Надежность обеспечивается выведением ченловека из как можно большего клоичества задач.
    ЧЕм меньше работает человек - тем надежнее решение.
    Именно поэтому сборка мусора надежнее любых "подпорок" в виде си-шных фреймворков для управления памятью.
    Именно поэтому хаскель с его жестким разделением кода на чистый и не чистый - наежнее ИЯ.
    Именно поэтому Erlang с его ЗАПРЕТОМ на shared memory concurrency, и опять же отсутствием оператора присваивания, дает надежность, которую традиционными методами постороения многопоточных систем никогда не достичь.
    Все упирается в человека.
    Убирайте человека из процесса, а не подсовывайте ему "опроные точки", если хотите действительно добиться надежности кода.


    № 2344   30-03-2007 16:19 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2342« (Geniepro)
    ___________________________

    Ответ на »сообщение 2335« (Илья Ермаков)
    Стоит ли в который раз повторять, что телекоммуникационное ПО фирмы Ericsson - практически эталон надёжности и безопасности?

    Возможно. Даже очень вероятно.
    Однако есть две категории реального времени - мягкое и жесткое. Телекоммуникации не относятся к последней категории. Чтобы в нее попасть, нужно к надежности (которую ФП дает) добавить предельную эффективность, да еще уложиться в ограничения оборудования - по памяти, например.
    В жесткое РВ не прорваться ни Цям, ни ФП - правда, по совершенно противоположным причинам. Нужны инженерные компромиссы, композитные решения. В центре треугольника "надежность"-"эффективность"-"динамичность" сегодня лежит только Паскаль-семейство.


    № 2343   30-03-2007 16:14 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2337« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 2335« (Илья Ермаков)
    ___________________________
    Тут логика начинает мне отказывать. Чем больше код тем ЛЕГЧЕ ошибаться. Во всяком случае так было всегда.
    Код на ассемблере гораздо больше кода на обероне - одишиться в разы легче. Код на обероне гораздо больше кода на хаскеле - ошибиться гораздо легче.

    Код на Це может выглядеть гораздо лаконичней кода на высокоуровневых ИЯ. Хотя бы это одно должно бы уже заставить призадуматься о том, что количество строк в программе слабо коррелирует с тем, насколько просто в ней ошибиться... А вот "разбавление" кода вспомогательными "опорными точками", которые не позволят программисту с замыленным от усталости взглядом в три часа ночи сделать ляп - очень даже коррелирует.

    Чертеж на ватмане может занимать пространства в пять раз больше, чем карандашный набросок на огрызке бумаги. Но стоит ли запускать конвейер работать по схеме на огрызке, даже если там все верно нарисовано? :-)


    <<<... | 2362—2353 | 2352—2343 | 2342—2333 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 316


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

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

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

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

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

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