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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

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


    № 2632   04-04-2007 16:15 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2631« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 2630« (Илья Ермаков)
    ___________________________
    Ну вот опять. За что ни возьмешся - все примеры примитивны.
    Как в церкви, бога показать не могут, требуют верить.
    Стоит ли после жтого удивляться что люди в толк не возьмут на кой ляд все эти навороты в оберонах нужны.

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

    А в плане дискуссий в этой ветке - такое замечание касается, видимо, и нас, и вас.
    У меня назревает некоторое резюме своих мыслей, чуть позже выложу.


    № 2631   04-04-2007 15:32 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2630« (Илья Ермаков)
    ___________________________
    важно сразу видеть, какой из модулей отвечает за ту или иную функциональность.
    Почему важно ?
    За функциональность отвечает вызываемая функция или метод. Модуль отвечает за упаковку. И знать где и как все это упаковано, читая код мне на черта не нужно.
    Вполне возможно что это для чего то там нужно в обероне. Но зачем тогда со своим уставом в чужой монастырь лезть ?

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

    Да нам уже и не нужно :))


    № 2630   04-04-2007 15:17 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2629« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 2628« (Илья Ермаков)
    ___________________________
    Обясните мне чем sqrt(4) отличается от Math.sqrt(4)
    В плане понимания кода, ничем.

    Для примитивного примера с мат. функциями - ничем. Для серьезных случаев, с использованием типов данных из сторонних модулей и т.п. - важно сразу видеть, какой из модулей отвечает за ту или иную функциональность. Не при написании. При изучении, а особенно - изменении. Я уже приводил пример - разобраться в одном из крупных модулей VCL - иcщелкаетесь мышкой :-)


    № 2629   04-04-2007 14:36 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2628« (Илья Ермаков)
    ___________________________
    Не понял, водить и щелкать мышкой по КАЖДОМУ из десятков имен внешних функций для того только, чтобы понять, к камому из внешних модулей идет связь -

    Ну во первых зачем к каждому. Только те которые интересуют.
    Во вторых я за все свои годы в программировании ни разу не сталкивался с необходимостью знать откуда конкретно та или иная функция. Меня интересует что функция делает, и что переменная хранит, а не то где они описаны.
    В контексте задачи это irrelevant. В контексте нахождения тела функции, если у вас нет средств автоматической навигации, то да, ГДЕ описана функция знать важно. Если есть средства автоматической навигации, то я просто кликну и попаду в нее.

    Обясните мне чем sqrt(4) отличается от Math.sqrt(4)
    В плане понимания кода, ничем.


    № 2628   04-04-2007 14:24 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2625« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 2623« (Илья Ермаков)
    То же не понял. Используя нормальный IDE вы типа НЕ имеете полную принципиальную схему системы, с наглядным выделением взаимных связей ?

    Не понял, водить и щелкать мышкой по КАЖДОМУ из десятков имен внешних функций для того только, чтобы понять, к камому из внешних модулей идет связь - и это вместо того, чтобы просто смотреть на код и видеть это?


    № 2627   04-04-2007 13:34 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2624« (Илья Ермаков)
    ___________________________
    Правильно. Нужно оценивать масштабы задачи и соразмерять инструментарий.
    Гениальная фраза. Осталось теперь только чтобы она наконец дошла до императивщиков, которые на сайте дельфи, предназначенного для созания виндовых морд к базам данных, все время говорят о жестком РВ.

    Оцените масштаб задачи, стоящий перед посетителями и основным контингентом delphikingdom и соизмеряйте инструментарий :))


    № 2626   04-04-2007 13:31 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2624« (Илья Ермаков)
    ___________________________

    Гугли и Амазоны могут себе позволить "смасштабировать" железо.
    Средний российский разработчик (например, тот же исследователь с вычислительными задачами) - нет.


    Нехилый у вас "исследователь с вычислительными задачами". С запросами к web покруче Гугла с Амазонами :)))
    Илья, для того чтобы web сайт на питоне например довести до ручки нагрузкой, надо вообще то нехилую нагрузку сначала поиметь.
    Исследователю с вычислительными задачами такая нагрузка не грозит, не беспокойтесь.

    Далее, здесь уже приводился пример Эрланговского web сервера YAWS который преспокойненько держит нагрузку в сотни раз превосходящюю ту которую может себе позволить написанный на сях apache.
    Так что вы о нас не беспокойтесь. На наши задачи возможностей и эффективности ФЯ с головой хватает.



    № 2625   04-04-2007 13:24 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2623« (Илья Ермаков)
    ___________________________
    Я хочу писать код и быть уверенным в отсутствии конфликтов имен.
    Непонятный запрос. Уверенность в отсутствии конфликтов имен дает компилятор вообще то :))
    Если код на хаскеле скомпилировался без ошибок то я УВЕРЕН что в нем отсутствует конфликт имен.

    Я хочу иметь самодостаточный программный код, который представляет собой полную принципиальную схему системы, с наглядным выделением взаимных связей.


    То же не понял. Используя нормальный IDE вы типа НЕ имеете полную принципиальную схему системы, с наглядным выделением взаимных связей ?

    But anyway, о вкусах не спорят. А то о чем мы с вами говорим именно вкусами является.
    Меня устраивает необходимость работы с кодом в специализированной среде, берущей на себя задачу облегчения чтения и навигации по коду.
    Вас как апологета оберона тоже вроде необходимость работы в среде должна устраивать (ведь оберон это именно среда а не просто компилятор текстовых файлов) Однако почему то вы ведете себя так как будто не в среде работаете а в notepad. Почему вы это желаете меня не интересует. Мучайтесь дальше :))



    № 2624   04-04-2007 13:23 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2621« (Jack Of Shadows)
    ___________________________

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

    Правильно. Нужно оценивать масштабы задачи и соразмерять инструментарий.
    Иначе для той же веб-системы при достаточно сильном росте нагрузки может настать момент, когда будет достигнут предел по быстродействию. И придется выкидывать весь ранее написанный код на помойку, и писать с нуля на универсальном языке программирования двоичные модули для веб-сервера (ISAPI или модули Apache). О том и речь - если предполагается серьезный рост масштаба задачи со временем, к выбору инструмента надо ответственно подходить изначально. Выбрав нечто с "автоматической коробкой передач", можно подойти к "потолку" по быстродейтствию, а ресурса для оптимизации-то у инструмента нет! И придется все с нуля делать...

    Гугли и Амазоны могут себе позволить "смасштабировать" железо.
    Средний российский разработчик (например, тот же исследователь с вычислительными задачами) - нет.



    № 2623   04-04-2007 13:15 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2619« (Jack Of Shadows)
    ___________________________

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

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

    По поводу "мышки и прыжков" - я хочу свободно читать код и видеть все связи с другими модулями. После работы с большим числом чужих исходников на Обероне понимаешь прелесть явно квалифицированного импорта. Пришлось однажды полезть в исходники VCL, где таковой не применяется - знаем, плавали :-)
    Я хочу писать код и быть уверенным в отсутствии конфликтов имен.
    Я хочу иметь самодостаточный программный код, который представляет собой полную принципиальную схему системы, с наглядным выделением взаимных связей.



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


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

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

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

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

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

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