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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 2692—2683 | 2682—2673 | 2672—2663 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 283


    № 2682   05-04-2007 08:50 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2681« (Руслан Богатырев)
    ___________________________

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

    Явное объявление типа переменной, разумеется. Возможно, Илья прав: пока не поймешь, что можно жить лучше, будешь считать, что и так нормально.


    № 2681   05-04-2007 08:38 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2676« (panda)
    ___________________________

    За несколько лет у более чем десятка человек никогда не возникало потребности постоянно видеть, из какого модуля взят тип или функция. Ни при чтении, ни при отладке.

    И Вы считаете такой аргумент убедительным? Т.е. если где-то когда-то кому-то не понадобилось -- то и не нужно? Мне известно немало проектов, реализованных на Бейсике. Людям тан не было нужды указывать типы переменных. Скажите, из этого следует, что явное объявление типа в языках со статической типизацией -- это ненужная, второстепенная вещь?


    № 2680   05-04-2007 08:36 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2676« (panda)
    ___________________________

    Ответ на »сообщение 2674« (Руслан Богатырев)
    ___________________________
    В данном случае я говорил о коллективно разрабатываемом проекте довольно крупного размера. За несколько лет у более чем десятка человек никогда не возникало потребности постоянно видеть, из какого модуля взят тип или функция. Ни при чтении, ни при отладке.

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


    № 2679   05-04-2007 08:30 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2675« (Сергей Перовский)
    ___________________________

    Если происхождение какого либо идентификатора вызывает сомнения, достаточно навести на него мышку и вместо ТABCClass можно увидеть uABC.TABCClass.

    Замечательно, когда для программиста разницы между языком программирования и "костылями" инструментальной среды (IDE) практически нет. Она за него давно доделывает (додумывает) то, что должен делать он. Хорошо, я понял, сколь силен стереотип такого мышления в среде Delphi-программистов. Попробуем порассуждать.

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

    Кто-то написал некий модуль и переслал его коллеге (наш случай с Geniepro). Коллега может не иметь всех тех настроек среды (и той же среды), ему нужен аккуратно отчужденный исходник (со всеми буковками) в текстовом виде (особенно, ежели в дороге, что может быть и равносильно случаю, когда кто-то обращается к исходнику спустя, скажем, лет 5).

    Скажите, зачем Бейсик-программисту заморачиваться с типами данных, когда компилятор/интерпретатор додумает за него? Ведь и так работает, чего напрягаться-то? Зачем явно преобразовывать/приводить типы? Присвоил и ладно. Компилятор поймет, не осудит.

    Додумывание и разрешение конфликтов среде и компилятору не надо никогда оставлять, если сам исполнитель может сказать -- так и никак иначе. Возможно, это будет несколько сильным сравнением, но неквалифицирующий импорт сродни include-директивам (со спасательным кругом в лице IDE). Непонимание идет от простого -- синтез превалирует над анализом, работа в качестве программиста-хозяина (по Ершову) над работой как программиста-слуги. Работа одиночки над работой в распределенном коллективе, когда постоянно из-за сроков надо смотреть/править чужие исходники "подмастерьев".

    Отчуждение модуля (даже во времени) выглядит для многих дикостью. Видимо, отсюда и непонимание.


    № 2678   05-04-2007 08:28 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2668« (panda)
    ___________________________

    Ответ на »сообщение 2655« (AVC)
    ___________________________
    Вопрос стоит именно в том, что лично мне абсолютно все равно, где размещается TThread: в Classes, SysUtils или еще где-то. Он все равно будет очень быстро найден и скопирован.
    Мне же утверждали, что легко я его смогу скопировать только если в моем модуле будет явно написано Classes.TThread. А если просто TThread - то мне будет намного сложнее найти реализацию.

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


    № 2677   05-04-2007 08:26 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2644« (Geniepro)
    ___________________________
    Ну в хаскеле это небольшая проблема.
    А вот на турбо-паскале я когда-то написал процедуру move, а потом долго не мог понять почему компьютер перезагружается. ;-)


    № 2676   05-04-2007 08:17 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2674« (Руслан Богатырев)
    ___________________________

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


    № 2675   05-04-2007 07:56 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2674« (Руслан Богатырев)
    ___________________________
    >>>Это не просто наглядность документации, а гарантия многих ошибок
    Гарантировать ошибки это конечно здорово :)
    Меня чтение таких конструкций, как Classes.class сильно утомляет. Простие за албанский "ниасилил, слишком много буквов".
    Если происхождение какого либо идентификатора вызывает сомнения, достаточно навести на него мышку и вместо ТABCClass можно увидеть uABC.TABCClass.
    Когда выражения перестают помещаться на строчку из за слишком длинных имен, ясности это не добавляет.
    Скорее всего речь опять идет о разнице парадигм. При возможности динамически обратится в любой момент к любому модулю, могут возникать проблемы с однозначностью квалификации при редактировании кода. Вопрос упирается в отчуждение модулей. И понятно, что для программистов на Дельфи обязательность квалификации выглядит дико. 




    № 2674   05-04-2007 07:03 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2673« (panda)
    ___________________________

    Видите ли в чем дело... У меня просто нет проблемы локализации. "Find Declaration" работает, отладка всех модулей (при необходимости и VCL) - тоже. Мне не надо видеть в моем модуле, откуда я импортировал тип или функцию.

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

    Для меня принудительно квалифицирующий импорт вещь давно очевидная (отказался в Модуле-2 от неквалифицирующего импорта еще до выхода Оберона в публичное плавание), поэтому даже никогда и не поднимал этот мелкий (в моем понимании вопрос). Но когда стал читать исходники Geniepro, понял, что локализовать что откуда -- не могу. Думаю, несложно эту ситуацию спроецировать и на Delphi. Случай, когда писатель#читатель. Это не просто наглядность документации, а гарантия многих ошибок (не только конфликта имен -- это мелочь).

    Пример со словарем, похоже, Вас мало убедил. Странно, да ладно. Просто по долгу службы вынужден ковыряться в таком объеме недостоверной информации, что по привычке для меня является само собой разумеющимся то, что есть в программировании понятие достоверности (надежности) модулей. Мы как-то этот вопрос уже детально обсуждали в ветке по Оберону в плане маркировки проверенных и одобренных модулей (trusted), а также иерархического импорта SYSTEM-зависящих модулей. Для Вас, как я понимаю, любой модуль вне зависимости от сырости (текущего состояния проекта) и подготовки внешними, территориально удаленными участниками команды, является надежным (достоверным). Для меня -- нет.


    № 2673   05-04-2007 06:41 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2669« (Руслан Богатырев)
    ___________________________

    Это во многом решает задачу локализации. В этом плане проблемы, связанные с локализацией/достоверностью (при работе сторонних подрядчиков, непроверенных, системно-зависимых и т.д. и т.п. модулей), в Обероне решаются проще.
    Видите ли в чем дело... У меня просто нет проблемы локализации. "Find Declaration" работает, отладка всех модулей (при необходимости и VCL) - тоже. Мне не надо видеть в моем модуле, откуда я импортировал тип или функцию.


    <<<... | 2692—2683 | 2682—2673 | 2672—2663 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 283


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

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

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

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

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

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