| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 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« (Илья Ермаков)
___________________________
Тут логика начинает мне отказывать. Чем больше код тем ЛЕГЧЕ ошибаться. Во всяком случае так было всегда.
Код на ассемблере гораздо больше кода на обероне - одишиться в разы легче. Код на обероне гораздо больше кода на хаскеле - ошибиться гораздо легче.
Код на Це может выглядеть гораздо лаконичней кода на высокоуровневых ИЯ. Хотя бы это одно должно бы уже заставить призадуматься о том, что количество строк в программе слабо коррелирует с тем, насколько просто в ней ошибиться... А вот "разбавление" кода вспомогательными "опорными точками", которые не позволят программисту с замыленным от усталости взглядом в три часа ночи сделать ляп - очень даже коррелирует.
Чертеж на ватмане может занимать пространства в пять раз больше, чем карандашный набросок на огрызке бумаги. Но стоит ли запускать конвейер работать по схеме на огрызке, даже если там все верно нарисовано? :-)
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
