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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 2522—2513 | 2512—2503 | 2502—2493 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 300


    № 2512   02-04-2007 13:33 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2507« (Руслан Богатырев)
    ___________________________
    что, на Ваш взгляд, в решении на КП выглядит тяжеловатым, излишне изобилующим деталями, вызывающим желание переделать (спрятать детали реализации). Я весь внимание...
    Странно что вы не заметили. Наш взгляд уже был показан...размером в 63 строчки. :))
    И решение на КП на наш взгляд излишне изобилует жонглированием локальным состоянием чуть ли не в каждой строчке программы.
    Я уже об этом говорил. Илья сказал что многокоратное присваивание перемеых там используется только в процедурах ввода/вывода но никак не в логике программы. Однако я привел пример 2 центральных процедур именно логики где эти переменные так и мелькают. Опровержения (может пока) не получил.


    № 2511   02-04-2007 13:27 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2508« (AVC)
    ___________________________
    Если уж, Jack, Вы на самом деле хотите увидеть разницу, то обратите внимание, что Java не поддерживает "старое доброе процедурное программирование".


    Поддерживает, поддерживает. Все в одном файле "классе". Все процедуры видят все данные, которые задекларированны как поля одного класса "Программа"
    К неудобству того что в начале программы обязательно надо писать class main - легко привыкается.


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


    Вы меня не поняли AVC. Я о том и говорю. Не нужны ни ООП, ни модульность, ни компонентность.

    <...>

    ФЯ именно в обучении дают преимущество. В том плане что прививают грамотный подход НЕЗАВИСИМО от размера задачи. Прививают ПРИВЫЧКУ к декомпозиции, модуляризации, упрятыванию всего лишнего внутрь, взаимодействия через жесткие и скупые интерфейсы функций (входные параметры, выходные значения)


    Это совсем другое дело. :)
    Эта мысль действительно заслуживает обдумывания и обсуждения.
    Если ФЯ на самом деле дают преимущество в обучении (хотелось бы получше разобраться в этом вопросе), то, конечно, постановка вопроса о ФЯ как первом (или хотя бы втором) языке программирования абсолютно обоснована.
     AVC


    № 2509   02-04-2007 12:49 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2508« (AVC)
    ___________________________
    Естественно, что для игрушечных задач, для которых достаточно процедурного программирования, используется именно процедурное программирование.

    Вы меня не поняли AVC. Я о том и говорю. Не нужны ни ООП, ни модульность, ни компонентность.
    То есть решение Илья принял ВЕРНОЕ.
    В этом и проблема. Для того чтобы понять пользу и необходимость всех этих механизмов нужно столкнуться с задачей довольно большого масштаба. Где ? Где столкнуться ? В школьном курсе ? Несерьезно. В реальной жизни ?
    Кому ? Студентам у который программирование всего лишь факультативный предмет ?
    Получается что вы меняете VB или java на оберон из самых лучших побуждений, а результат нулевой. Разницы никакой. Получается что все эти правильные и нужные механизмы не имеют никакой возможности развернуться и показать свою правильность и нужность ... в школьной среде.
    Да ладно черт с ним с возможностью показать (и доказать) свою нужность и полезность.
    Что хуже всего, что практика которую получают студенты, вот эти вот маленькие задачи в которых им приходится принимать ВЕРНОЕ решение НЕ использовать ничего из того чему их учили, доказывает им ()пусть и ложно) что МОЖНО обойтись без всего этого. Что это будет даже ЛЕГЧЕ и БЫСТРЕЕ и УДОБНЕЕ.
    Таких ведь потом переделать гораздо труднее.

    ФЯ именно в обучении дают преимущество. В том плане что прививают грамотный подход НЕЗАВИСИМО от размера задачи. Прививают ПРИВЫЧКУ к декомпозиции, модуляризации, упрятыванию всего лишнего внутрь, взаимодействия через жесткие и скупые интерфейсы функций (входные параметры, выходные значения)

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



    № 2508   02-04-2007 12:19 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2506« (Jack Of Shadows)
    ___________________________

    Ни одного типа класса не описано. Никакой модульностью и не пахнет. Старое доброе процедурное программирование. А ведь это не новичек писал :))
    Это писал человек продвигающий здесь "идеи оберона" которые вроде бы должны давать какую то разницу с дельфми или java. К сожалению в коде этой задачи разницы этой так и не обнаружилось.


    Неужели этот "критический" пассаж написан всерьез?
    Естественно, что для игрушечных задач, для которых достаточно процедурного программирования, используется именно процедурное программирование.
    И надо было бы поставить Илье "двойку", если бы он умудрился засадить в эту программку дюжину классов или разбить ее на десяток модулей.
    В том-то и достоинство Оберона, что кроме прочего он поддерживает "обычное" процедурное программирование.
    В отличие, кстати, от Java.
    Если уж, Jack, Вы на самом деле хотите увидеть разницу, то обратите внимание, что Java не поддерживает "старое доброе процедурное программирование".
     AVC


    № 2507   02-04-2007 12:06 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2506« (Jack Of Shadows)
    ___________________________

    А Руслан на радостях не разглядел :))

    С какой лупой Вы у меня радость-то разглядели? Я тут все сокрушаюсь, горюю, можно сказать, а некоторые это воспринимают как радость. Странно, однако...

    Но вот что интерено так это то что Руслан даже не подозревает что в устах этих профессоров "java" означает не конкретный язык а целое семейство языков, подход.
    К этому семейству относятя и паскаль и оберон.


    Да-да, а также Алгол-68, ПЛ/1, C++ и т.д. и т.п. Это надо еще умудриться всех поставить на одну доску. Что имели в виду американские профессора -- ведомо им одним. Я же привел их слова с целью привлечь внимание к тому факту, что наконец-то американцы прилюдно (опубликовано в центральном американском издании) начинают беспокоиться о том, что преподавание ИТ в сфере их высшего образования, мягко говоря, ущербно. Что не преподают они фундаментальные вещи, не дают  препарирование исполнения программы (ассемблер). А то, что они восстали против "Java", так это потому IMHO, что оскомину она уже в американских университетах всем набила. Любят они из одной крайности в другую бросаться. Но язык-то по сути ни при чем (Java или что другое). Надо просто владеть предметом программирования и уметь это владение донести до студенческой аудитории, а не учить языку (видимо, кто-то был не очень внимателен, читая мои сегодняшние сообщения, а жаль, я-то думал, что-то дойдет).

    Ни одного типа класса не описано. Никакой модульностью и не пахнет. Старое доброе процедурное программирование. А ведь это не новичек писал :))
    Это писал человек продвигающий здесь "идеи оберона" которые вроде бы должны давать какую то разницу с дельфми или java. К сожалению в коде этой задачи разницы этой так и не обнаружилось.


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


    № 2506   02-04-2007 11:24 Ответить на это сообщение Ответить на это сообщение с цитированием
    Руслан вот тут приводил слова некоторых американских преподов, по поводу того что преподавать студентам java это преступление. Полностью согласен с этим утверждением, сам не раз заявлял подобное.
    Но вот что интерено так это то что Руслан даже не подозревает что в устах этих профессоров "java" означает не конкретный язык а целое семейство языков, подход.
    К этому семейству относятя и паскаль и оберон.
    Для того чтобы это осознать достаточно посмотреть на задачи, которые решают школьники и студенты. Задачи эти маленькие (может за исключением курсового проекта). И в задачах этих школьники, даже те кто 5-ки по программированию получил не используют ни ООП, ни модульность. По существу разницу между кодом одной и той же задачи написанной студентами на java, паскаль или оберон - под лупой не разглядишь.
    Не верите мне ? Посмотрите на код олимпиадной задачи на обероне, приведенный здесь совсем недавно:
    http://forum.oberoncore.ru/viewtopic.php?t=409

    Ни одного типа класса не описано. Никакой модульностью и не пахнет. Старое доброе процедурное программирование. А ведь это не новичек писал :))
    Это писал человек продвигающий здесь "идеи оберона" которые вроде бы должны давать какую то разницу с дельфми или java. К сожалению в коде этой задачи разницы этой так и не обнаружилось.

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

    Так будет ли разница если перейти от java к оберону в обучении студентов ? Даже если и будет то только на словах, чтобы оценку получить. А на практике... ну вы видели :))

    Будет ли разница если преподавать программирование на лиспе (схеме) или даже хаскеле ?
    Несомненно. Причем даже на самых маленьких программах.

    Именно это и имели в виду те американские преподы. Они показывали пальцем на MIT с его курсом SICP.
    А Руслан на радостях не разглядел :))


    № 2505   02-04-2007 10:25 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2503« (Geniepro)
    ___________________________

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


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

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

    Мое глубокое убеждение, которое я вынес еще со времени проекта интеграции Модулы-2, Лиспа и Пролога 20-летней давности -- не надо все впихивать в один язык. Равно как и пытаться создавать межъязыковое взаимодействие вообще -- на все случаи и времена. Лучше выбрать базис языков в "ортогональных" парадигмах и наладить их взаимодействие через делегирование управления и обмен сущностями (не всеми, а пригодными для "экспорта-импорта"). Взаимодействие может быть достаточно глубокое -- вплоть до возможности автоматического расширения ран-тайма другими языками (как я делал в случае введения в Пролог-машину новых встроенных предикатов, реализованных на Модуле-2). В этой схеме централизация работы (выбор головного и вспомогательных языков) диктуется задачей/проектом и предпочтениями команды исполнителей.


    № 2504   02-04-2007 10:25 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2503« (Geniepro)
    ___________________________

    Хорошо, если с ООП всё ясно, то какие же возможности ФП, не пересекающиеся в то же время с возможностями ИП и ООП (т.е. традиционно характерные именно для ФП), есть в Оберонах?

    Уточняющий вопрос.
    Насколько я понял, из крупных идей к ФП относятся:
    1) отсутствие побочных эффектов и все возможные следствия этого факта;
    2) принадлежность функций к числу объектов первого рода (лямбды и т.д.).
    Не забыл ли я о чем-нибудь столь же существенном, как и эти два пункта?

    >>>И насколько удобно и естественно для типичного оберонщика они реализованы?

    Вы нам льстите.
    Где Вы видели типичного оберонщика? ?)
     AVC


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

    ИП в одеждах  МП (в контексте Оберонов) -- это объединение возможностей ФП и ООП (не всех, а существенных) без "жесткости" ограничений ФП и ООП.

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


    <<<... | 2522—2513 | 2512—2503 | 2502—2493 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 300


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

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

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

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

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

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