Ответ на »сообщение 2374« (Илья Ермаков)
___________________________
Область систем промышленной автоматики - это отнюдь не узенькая, а очень широкая область, актуальная для любого современного промышленного предприятия.
Yeah, right! Особенно актуальная на сайте delphikingdom.com, cайте прикладников компонентокидателей, основная задача которых - виндовые морды к базам данных клепать. For crying out loud...

Ответ на »сообщение 2380« (Jack Of Shadows)
___________________________

Однако Россияне как обычно легких путей не ищут. :))

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

Ответ на »сообщение 2374« (Илья Ермаков)
___________________________
Киньте ссылочку, плиз. Это что-то из ряда вон, даже интересно стало :-) Если учитывать известное качество мат. подготовки в американской школе, то я просто не представляю, как им удалось втиснуть туда ФП...


Ссылка на известный проект http://www.teach-scheme.org/ для школьных учреждений здесь уже не раз приводилась
Материалом является тоже не раз упоминавшаяся книга http://www.htdp.org/
Средой является тоже не раз упоминавшаяся http://drscheme.org/

Все уже сделано, придумано и успешно используется.
Однако Россияне как обычно легких путей не ищут. :))

Ответ на »сообщение 2357« (Jack Of Shadows)
___________________________

Казалось бы практика должна определять. Она расставит все по своим местам.

Она уже нарасставляла. За такой практикой разгребать авгиевы конюшни предстоит еще не одному поколению программистов.

Ответ на »сообщение 2376« (Geniepro)
___________________________

(Кстати, а куда Руслан Богатырёв пропал? Читал ли он ту мою мессагу?)

Он, наконец, появился :) Но тут столько всего уже успели наобсуждать, что дай Бог понять, что к чему.

Ответ на »сообщение 2357« (Jack Of Shadows)
___________________________

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

У кого-то еще остались вопросы относительно технологического совершенства в отношении ФП? Типичный экстенсивный путь развития. ФЯ как пожиратель ресурсов выгоден мировым производителям железа и монополии Microsoft, чтобы удерживать свои завоеванные высоты и грести деньги.

Позабавил подсчет строк. Честное слово. В Обероне формально говоря любой модуль записывается в одну строку (с разделителем операторов). Остальное -- на усмотрение программиста. Уж тогда бы операторы считали и пришли бы к выводу, что в Обероне мелкозернистые операторы, а в ФЯ -- крупнозернистые. А это было кому-то неочевидно раньше? И какой из этого вывод?

Ответ на »сообщение 2370« (AVC)
___________________________

Я-то полагал, что специфика ФП -- в отсутствии переменных, как они понимаются в ИЯ.
...
Спрашивается: это уже ФП?

Нет. Требование к отсутствие изменения состояния переменных - это следствие ФП, но никак не его сущность.

Сущность же функционального программирования - в манипулировании функциями, это-то и отражено в названии этой парадигмы.
Те самые "навороты" (по мнению Ильи Ермакова) - это и есть сущность ФП. Ну а что бы ФП работало без сбоев, приходится ограничивать изменения состояния, локализовать их в карантинных зонах...
(Кстати, а куда Руслан Богатырёв пропал? Читал ли он ту мою мессагу?)


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

Абсолютно непонятно, где Вы видите противоречие с инкапсуляцией - она-то тут причём? С инкапсуляцией (абстрактизацией типов данных: данные + операции над ними) тут всё в порядке.
Вы имеете в виду сокрытие (hiding) данных? А какие именно замечательные свойства у этого сокрытия есть с точки зрения ФП? ООП и ФП - всё-таки разные вещи. Что для ФП - хорошо, то для ООП - смерть! :о))

Нет, ну скажите, что такого хорошего в сокрытии данных, не укладывающегося в сокрытие лишних деталей внутри модуля?

С точки зрения ООП - безопасность, меньше вероятность ошибок от бесконтрольного изменения этих данных.

Для чистого ФП эта проблема неактуальна - это просто запрещено. Всё изменение состояния проводится под жёстким контролем. И этот контроль и скрывает изменяющиеся данные, это и есть тот самый hiding.
А зачем скрывать гарантированно неизменяемые данные?

Та проблема с датчиком случайных чисел актуальна для Scheme, но это не значит, что она актуальна для чистого ФП. В Хаскелле этот датчик помещается внутрь монады ввода-вывода, и тем самым скрывается от остальной части программы...

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

Недавно вышедшая книга Романа Душкина на такой учебник тянет?
Читал, разбирался - после этого, кстати, разочаровался в Хацкеле. Не нравится. Язык с чисто математическим стилем...

К сожалению, мне эта книга в руки пока ещё не попала...
На РСДНе была %url[тема об этой книге] http://www.rsdn.ru/Forum/Message.aspx?mid=2235031&all=1 - противоречивые мнения там были. Кто-то жаловался, что она не для средних умов, кто-то был ею вполне доволен. Однако общее мнение было таким - книга для профессиональных функциональщиков, решивших узнать, что такое Хаскелл.
Возможно поэтому она Вам и не подощла...

Поищите другие учебники по Хаскеллу (правда они все на инглише), например,
"Write Yourself a Scheme in 48 Hours. A Haskell Tutorial" By Jonathan Tang
"Haskell Tutorial for C Programmers" by Eric Etheridge
Там другой подход - как раз для императивщиков...

Роман сейчас пишет вторую книгу, которая должна по идее как раз быть в таком духе - с ориентацией на С++-программеров. Обещает описать, в частности, создание GUI-приложений на Хаскелле.
К сожалению, это больная мозоль у Хаскелла по Виндовсом. Нет дизайнеров форм, вручную приходится делать. Хотя, если пользоваться библиотеками GTK+ и Gtk2hs, то можно использовать дизайнер Glade, правда потом все связи между контроллами и функциями на Хаскелле всй равно вручную прописывать придётся..
Ну так это же и к лучшему - разделение бизнес-логики и GUI-части!


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

Что за такие средства, которых почему-то нет в Хаскелле?
Пресловутая динамическая загрузка-выгрузка модулей с экспортом задом-наперёд, к которым Вы привыкли?
Другая парадигма, другие решения...

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

Ответ на »сообщение 2371« (Geniepro)
___________________________

Ответ на »сообщение 2366« (Илья Ермаков)
___________________________
Ну что ж, тут уже вопрос привычек и приоритетов.
Вы, похоже, предпочитаете размазывать состояние программы и затем мучиться с багами из-за его бесконтрольного изменения вместо того, что бы мучиться с изменением своего мышления на пути ограничения состояния программы... Если Вас устраивает текущее положение дел - тем лучше для Вас...
Вы не поверите: :-)
а) в паскалевских языках (как и в других современных ИЯ) есть свои методы "ограничения состояния программы", путем декомпозиции, инкапсуляции и взаимодействия через интерфейсы - "узкие горла", на которые накладываются жесткие пред/пост-условия;
б) с тех пор, как перешел на Оберон, я забыл, что это такое - "мучиться с багами". Так же, как ни разу (без преувеличения) не видел чтобы среда ББ "упала". Отладка как особый этап практически исчезает, немногочисленные ошибки мгновенно вылавливаются на ассертах-предусловиях в контрольных точках и на входах процедур. А бета-версии даже любительских подсистем для ББ, по сравнению с тем, что принято в сегодняшнем массовом ПО, тянут на полуторный-второй релиз как минимум :-)
И чем больше работаю, тем больше "душа поет".


Зачем школьникам все эти низкоуровневые сложности профессионального программирования?

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


У меня лично такого опыта нет, но тут уже неоднократно приводился успешный пример американских учебных заведений, в которых первыми языками были Хаскелл и Scheme.
Их опыт секретом не является - наоборот, эти преподаватели с восторгом делятся своим опытом... Лично я вполне склонен доверять им.

Киньте ссылочку, плиз. Это что-то из ряда вон, даже интересно стало :-) Если учитывать известное качество мат. подготовки в американской школе, то я просто не представляю, как им удалось втиснуть туда ФП...



Стремиться-то надо не к тому, что бы было не хуже, а к тому, что бы было гораздо лучше.

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


Жёсткое РВ - это лишь мизерная доля всего ПО.
Причём, как Вы сами же и признаёте, даже в Оберонах приходится отказываться от сборщика мусора - а значит и терять преимущества Оберонов перед теми же Адой и Модулой-2.

Уважаемые, что хоть за манера в этой ветке гиперболизировать? Где конкретно я это говорил?
Перечитайте внимательно - было сказано о трех промышленных ОС ЖРВ на Обероне, в КАЖДОЙ из которых реализован удовлетворяющий требованиям сборщик мусора. Однако я все же заметил, что для некоторых особенно критичных модулей системы можно использовать ручное управление.
Аду с Модулой противопоставлять Оберонам не надо. Это языки одного семейства и одной идеологии, с немного разным "прицелом", но прекрасно работающие в связке.


Повторю вопрос, который задал тут на днях Jack Of Shadows, - стоит ли ориентировать язык общего назначения на узенькую облась систем реального времени, в которых даже Оберон не слишком пригоден?

Читайте выше... Невозможно по десять раз повторять одно и то же. Область систем промышленной автоматики - это отнюдь не узенькая, а очень широкая область, актуальная для любого современного промышленного предприятия. Если у нас в России сегодня промышленность пока еще в коме, это еще не значит, что завтра все не изменится...
Не говоря уже об обычном системном ПО (разработка которого сегодня в среднем случае ведется на дремучих технологиях аля Це...)


Да ещё заставлять бедных школьников перенапрягать свой бедный моск всеми хитростями и премудростями "грамотного проектирования фабрик объектов на Обероне"?

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

Ответ на »сообщение 2372« (Geniepro)
___________________________

Эх, пожалуй, скажу всё, что я об этой книге думаю! :о))

Это отличная книга - классика! НО! Эта книга не есть истина в последней инстанции!
Время не стоит на месте, технологии развиваются, меняются и представления об ограничения на применимость ФП...

Хм... и это... все? ;)