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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 2632—2623 | 2622—2613 | 2612—2603 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 289


    № 2622   04-04-2007 13:08 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2617« (Geniepro)
    ___________________________

    Ответ на »сообщение 2613« (Илья Ермаков)
    ___________________________

    Известно также, что качество кода, генерируемого компилятором Оберона, находится на уровне С, а в некоторых реализациях навроде XDS в то время, когда они развивались, превосходило все известные реализации С (да и сейчас обходит VC 7.0)...
    Отсюда делайте сами вывод...

    Извините, но с этим тоже можно поспорить.
    ...но превзойти программы на том же C# (компилятор которого не так уж и хорош) они так и не смогли... Думаю, компилятор VC 8.0 получше будет, чем С#, так что тут XDS скорее сего пролетел бы...

    С чем поспорить? Что за привычка вообще спорить совсем не с тем, что утверждалось :-)
    При чем тут C# и VC 8.0 - о том, что они превосходят XDS, много лет не развивающийся, я и сам знаю. Речь шла о современннике XDS. Даже не современнике - т.к. современник VC 6.0.


    № 2621   04-04-2007 11:27 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2612« (Руслан Богатырев)
    ___________________________
    Понимаю, что можно заниматься дизассемблированием и анализировать схему работы транслятора, но сомневаюсь, что этим озадачиваются даже грамотные ФП-программисты.
    Грамотные программисты вообще себе голову этим забивать не будут.
    Миллионы программистов используют Python, Ruby, ASP, PHP, Perl, JavaScript, VBScript. Каждый из этих языков НА ПОРЯДОК медленнее хаскеля, не говоря уже об Ocaml. И никому из этих программистов не приходит в голову заниматься дизассемблированием и анализировать схему работы транслятора.

    Ваш вопрос из серии "жеского РВ" и бразильской АЭС. То есть вы выносите на сайт прикладников весьма узкоспецифичные проблемы, и требуете чтобы мы этими проблемами озадачились.
    Да нам плевать на эти проблемы.
    Лисп и Python достаточно быстры и вполне умещаются в рамки оперативки, чтобы я использовал их в решении своих повседневных задач. Так буду ли я мучаться вопросами эффективности хаскеля ?


    № 2620   04-04-2007 11:17 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2605« (Geniepro)
    ___________________________

    Ответ на »сообщение 2588« (RBV)
    ___________________________
    Большое спасибо за интересную идею. Только ответьте, пожалуйста, на один вопрос.

    Не за что. :) Хотите попробовать? :):):)


    Вот Руслан Богатырёв уже несколько лет предлагает российскому сообществу блэкбоксёров...

    Стратегический смысл?

    Так вот, вопрос: Почему Вы думаете, что создание транслятора Оберона или хотя бы загрузчика его модулей может заинтересовать необеронщиков, если это неинтересно даже оберонщикам?

    Евгений... Причем тут заинтересовать?! Была предложена чисто системная задача. Динамическая загрузка модулей. Всё.


    № 2619   04-04-2007 11:16 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2604« (Руслан Богатырев)
    ___________________________
    В отношении части B: на примере Хаскеля хорошо видно, что импорт IO не показывает точки использования импортируемых сущностей внутри исходного текста (типичная ситуация в случае т.н. неквалифицирующего импорта).


    Как раз таки в отношении IO там все в порядке. IO четко показан ТИПОМ нечистых функций, да оператором do.

    Далее, оберонисты почему то все время предполагают что программисты работают в notepad. Хотя последние 10 лет (может больше) я не помню ни одного случая написания мною хоть одной строчки кода в редакторе, для программирования не предназначенном.

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

    Позиция оберонистов в данном случае - это зарывание головы в песок и игнорирование изменений в окружающей среде. Пожмем плечами и пойдем дальше.


    Если говорить не о языке, а о сопоставлении подходов в рамках конкретных языков реализации, то следует обратить внимание, что в Хаскеле использовались императивные вещи (do и монады).


    Тут уже не знаешь смеяться или плакать. :)) Мама, смотри - присваивание !!!
    Руслан, ну уже сколько раз говорилось. Есть в ФЯ изменение состояния (императивные вещи), не делось оно никуда.


    По словам Р.В.Душкина, "монада является наиболее сложным концептом для понимания, который только есть в языке Haskell". Они в ФП служат окном в императивный мир.


    А вот это недопонимание. Монады и IO это не одно и тоже. List например тоже монада, хотя к IO не имеет никакого отношения.
    Для того чтобы пользоваться List не нужно знать ни того факта что это монада, ни вообще того что такое монады.
    То же самое и с IO. Монада конечно вешь сложная. Но IO такое же легкое как и в императивных языках.


    № 2618   04-04-2007 10:35 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2612« (Руслан Богатырев)
    ___________________________

    Вопрос: какие подходы мировое ФП-сообщество выработало в отношении оценки потребности ресурсов/"просадки" с перспективой возможностей последующего масштабирования (быстро) полученного решения? Это не укол, а желание разобраться. Плюсы ФП (сокрытие деталей) здесь превращаются в минусы. Их, видимо, можно нивелировать. Осталось выяснить как.

    Боюсь, такие вопросы нужно задавать в других форумах, там, где тусуется действительно мировое ФП-сообщество, а не несколько человек... :о))

    Насколько мне известно, в случае с энергичными ФЯ всё довольно прозрачно, что позволяет, например, утверждать, что программы на том же Эрланге можно использовать в мягком РВ.
    Хотя оценить время работы параллельных программ можно разве что на глазок...

    В случае же с ленивыми языками всё гораздо сложнее и менее предсказуемо. Если транслятор не использует анализ строгости, то поведение программы по оси времени вообще малопредсказуемо. С анализатором строгости тоже непросто - мало ли что он соптимизируе, а что - нет?
    Хвостовая рекурсия иногда может дать выгоду, а иногда (с ленивыми, да ещё и бесконечными, списками) - наоборот, всё испортить...
    Иногда явное указание строгого исполнения тех или иных функций может дать ускорение на порядки...

    Пока остаётся лишь традиционное средство - профилирование программ.


    № 2617   04-04-2007 10:25 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2613« (Илья Ермаков)
    ___________________________

    Известно также, что качество кода, генерируемого компилятором Оберона, находится на уровне С, а в некоторых реализациях навроде XDS в то время, когда они развивались, превосходило все известные реализации С (да и сейчас обходит VC 7.0)...
    Отсюда делайте сами вывод...

    Извините, но с этим тоже можно поспорить.
    Я как-то баловался с простенькими тестами - не нашёл подтверждений этому.
    Те мои программки на XDS работали действительно чуть быстрее, чем на Дельфях и C++Builder'е и заметно (в несколько раз) быстрее, чем на BlackBox Component Pascal, но превзойти программы на том же C# (компилятор которого не так уж и хорош) они так и не смогли... Думаю, компилятор VC 8.0 получше будет, чем С#, так что тут XDS скорее сего пролетел бы...

    Да вообще, как тут часто замечалось, все эти тесты - такая фикция... :о)


    № 2616   04-04-2007 10:15 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2611« (Руслан Богатырев)
    ___________________________

    И Вы, разумеется, выбрали худший, поскольку руководствовались "Бейсик-критерием" вместо надежности и сопровождаемости. Экономия на использовании лишних "буковок" -- IMHO, Бейсик-мания.

    Вообще, интересное противостояние взглядов у оберонщиков и большинства остальных программистов на средства разработки.

    Оберонщикам подсветка синтаксиса не важна - её роль играет языковое соглашение по прописным идентификаторам.

    Явная квалификация модуля, из которого импортируется тот или иной объект, вместо возложения этого на редактор, подсказывающий место описания этого объекта с документирующим комментарием.

    Явное специфицирование типов объектов вместо автовывода типов и опять же подсказки редактора кода.

    Всё это - всё-таки, на мой взгляд, дело вкуса и привычки... Не так уж и часто люди соглашаются на добровольный аскетизм в средствах разработки...


    № 2615   04-04-2007 09:58 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2611« (Руслан Богатырев)
    ___________________________

    Без qualified-импорта нельзя локализовать точки импорта сущностей (надо знать, что было в импортируемом модуле -- иметь к нему доступ или документацию, которая имеет тенденцию рассинхронизироваться с действительностью).

    Для хаскелла есть вполне стандартный и общепринятый инструмент генерации документации Haddock (вроде Javadoc) и некоторые принятые соглашения по коментариям, документирующим код на Хаскелле, которые используются Haddock'ом.


    Хочу обратить Ваше внимание, что неквалифицирующий импорт в Хаскеле сделан не как в Модуле-2 -- в Модуле-2 явно прямо в списке импорта (т.е. у нас перед глазами) перечисляются импортируемые идентификаторы, а в Хаскеле -- только имя импортируемого модуля. Это худший вариант.

    Вообще-то можно и так тоже (очень часто встречается):

    module ACM_2007_A where

    import IO (openFile, hClose, ReadMode, hGetContents)
    import List (nub)

    или даже так (с последующей квалификацией импортированных объектов):

    module ACM_2007_A where

    import qualified IO (openFile, hClose, IOMode(ReadMode), hGetContents)
    import qualified List (nub)



    то, что средством qualified не воспользовался Geniepro, лишний раз говорит о недооценке такой возможности (ложный стереотип относительно того, что это всего лишь косметическое средство борьбы с конфликтом имен). Уроки и опыт Оберона стоит извлекать.

    Ну, вряд ли стоит обобщать мой случай на всех хаскеллеров. Иногда квалифицированный экспорт всё-таки используется, вот только я видел не так много больших хаскеллевских программ, а в маленьких это не очень оправдано...

    Сейчас вот полистал исходники компилятора GHC (а это, по-моему, до сих пор ещё самый большой проект на Хаскелле), обратил внимание, что квалифицированный импорт встречается крайне редко...

    Уж если сами разработчики Хаскелла и его основной реализации так редко используют эту возможность - что уж ожидать от рядовых и тем более начинающих хаскеллеров?

    А может быть, для чистых ФЯ это не так уж и важно?
    Хаскелл не является языком компонентного программирования, так что не все обероновские взгляды на код программ актуальны и беспорны для Хаскелла...


    Не уверен, что строгость программирования -- дело вкуса. Это больше напоминает принцип "и так сойдет".

    В серьёзных проектах руководители проектов выставляют свои требования к кодированию с административным воздействием - так стоит ли перекладывать это ещё и на язык программирования, делая его использование неудобным? Оберон не имеет гибкости в этом вопросе - так ли уж это хорошо?


    Это худший вариант. То, что он в этом языке сосуществует с лучшим вариантом -- квалифицирующим импортом -- дает возможность выбора (чего давать нельзя).  И Вы, разумеется, выбрали худший, поскольку руководствовались "Бейсик-критерием" вместо надежности и сопровождаемости. Экономия на использовании лишних "буковок" -- IMHO, Бейсик-мания. Об уроках Оберона я не зря говорил. Делайте выводы, учитесь на чужом опыте тех, кто на этом не одну собаку съел, а не отмахивайтесь, как от назойливой мухи. Уж слава Богу, в сфере нюансов модульного программирования Вирт и его коллеги дадут 100 очков вперед Хаскель-сообществу.

    Вы меня извините, но всё это довольно спорно.

    С другой стороны, Хаскелл до сих пор ещё не используется в промышленных масштабах, а в основном только для экспериментальных работ и быстрого макетирования программ. Может быть, если Хаскелл войдёт в промышленность, то хаскеллеры и выработают стандарт кодирования и инструменты поддержки этого стандарта...
    А пока же. как говорят отцы-основатели Хаскелла, Хаскелл - язык для экспериментальных разработок...


    № 2614   04-04-2007 09:58 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2608« (Руслан Богатырев)
    ___________________________

    P.S. На мой взгляд, задача достаточно хорошо ложится на конечные автоматы (со всеми вытекающими последствиями по компактности, в ущерб определенной наглядности). Но это детали.

    Мне как-то пришло в голову, что эта программа на Хаскелле не сильно отличается от конечного автомата...


    Простите за нескромный вопрос, а Вы в этом плане себя причисляете к большинству или к меньшинству?

    Ну, будь я фанатом машшиного кода, вряд ли бы я интересовался Хаскеллом...


    Вынужден трактовать это либо как Вашу невнимательность к словам оппонента, либо как работу на публику

    Извиняюсь, что не дочитал тот абзац до конца (уж больно большой он), а сразу начал отвечать на него. Потом отвлёкся, и только сейчас таки дочитал...


    № 2613   04-04-2007 09:54 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2606« (Geniepro)
    ___________________________
    ЗЫ. А если сделать Оберон-систему целиком в машинных кодах, то она будет гораздо эффективнее, чем на Обероне. И почему большинству людей такая идея кажется бредом?
    Не будет. Известно, что для программ начиная от среднего размера компилятор с языка С дает в среднем по коду лучшее качество, чем ассемблерист руками...
    Известно также, что качество кода, генерируемого компилятором Оберона, находится на уровне С, а в некоторых реализациях навроде XDS в то время, когда они развивались, превосходило все известные реализации С (да и сейчас обходит VC 7.0)...
    Отсюда делайте сами вывод...

    А вообще, одним из важных критериев надежности среды для системного программирования и бы считал "раскрученность" на самой себе... При наличии слоев на разных язык, инородного рантайма и т.п. гарантия надежности платформы и развиваемости платформы на порядок падает...
    Это не касается, естественно, прикладного программирования - есть рантайм на Си - и пусть себе, зато вся прикладная инфраструктура "сверху" раскручена на самой себе - и отлично...


    <<<... | 2632—2623 | 2622—2613 | 2612—2603 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 289


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

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

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

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

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

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