Ответ на »сообщение 2216« (Jack Of Shadows)
___________________________
>>>Понятно что есть места где присваивания убрать нельзя. И ОО с ФП расходятся не в том что это надо делать, а в том ГДЕ это надо делать.
ГДЕ? ГДЕ?
Особенно интересно ГДЕ НЕЛЬЗЯ?

Ответ на »сообщение 2248« (Снегурочка)
___________________________

Еще немного об Erlang. Ключевая особенность Erlang, как языка, разработанного телекоммуникационной компанией именно для задач телекоммуникации, - multi-tasking, поддержка процессов.

Как верно здесь было подмечено, ноги Erlang растут из EriPascal - он вышел из экспериментов над средой PLEX (Programming Language for EXchange Switches) в компании Ericsson. Создавался как альтерантива языку CHILL (CCITT High Level Language). На EriPascal была написана ОС EriOS, которую потом для переносимости переписали на Си.

Автор языка Бьерн Декер (Bjarne Dacker) писал, что идеи Erland и EriPascal вышли из виртовских языков: Pascal, Modula и PL360. Да и личность самого Вирта сыграла здесь не последнюю роль. On my wall I have a framed photograph of myself presenting PASTEL for Niklaus Wirth. That was some experimental language that we were working on at the same time as he was working on Modula. I actually listened to his first lecture presenting Modula for his students in Zurich in hoch deutsch! Instead of PASTEL there came EriPascal but just imagine how beautiful manuals we could have printed!
http://www.erlang.org/pipermail/erlang-questions/2003-February/007354.html

Еще из его воспоминаний: I went to a Pascal conference in Southampton in 1977 and Brinch-Hansen described Concurrent Pascal. When asked what he thought of Modula (that Wirth just had brought out), he replied that you might do something clever but then "Claus" would come with the worked-through elegant version of it!

По мнению же Джо Армстронга, другим источником идей были работы Дейкстры: One other work which influenced Erlang was Dijkstra's idea of guarded commands - Dijkstra liked *every* alternative in a multi-way branch to have a guard.
http://www.erlang.org/pipermail/erlang-questions/2003-February/007325.html

В статье Бьерна Декера "Concurrent Functional Programming for Telecommunications: A Case Study of Technology Introduction" (Stockholm, Royal Institute of Technology, 2000) читаем: In 1979 I was responsible for the creation of the in-house programming language
EriPascal for a new processor APN 167. EriPascal was similar to a subset of Chill but with a Pascal like syntax. Like Modula it contained modules and processes. In EriPascal only messages were used. There were also plans to create an EriChill by using a different compiler front-end which accepted a Chill like syntax, but there were no user requests for it.
<...>
In 1984 the Computer Science Laboratory (CSLab) at Ericsson was formally established by myself and three colleagues, Goran Bage, Seved Torstendahl, and Mike Williams. Further colleagues joined. CSLab has had a low personnel turnover and has averaged between 12 and 15 people.
<...>
Based on this environment a series of experiments were carried out with different programming languages and paradigms which involved at least five persons in the laboratory. The following techniques were tried :
* Imperative programming languages: Concurrent Euclid and Ada.
* Declarative programming languages: PFL and Prolog.
* Rule based programming: OPS4.
* Object oriented languages: Frames and CLU.

В отношении же начала работ и источников идей для Erlang Декер пишет:
Joe Armstrong led the next round of experiments and started with Prolog, because of its terse and clear style, and added concurrency. However, the language began to change in the direction of a functional style. For example, one of the key characteristics of Prolog is backtracking and this could not be used because it is not possible to backtrack over hardware. (A tone signal once sent out cannot be taken back.)
<...>
Erlang is aptly described as a concurrent functional programming language combining two main traditions:
* Concurrent programming languages: Modula, Chill, Ada, etc. from which Erlang inherits modules, processes, and process communication.
* Functional and logic programming languages: Haskell, ML, Miranda, Lisp, etc. from which Erlang inherits atoms, lists, guards, pattern matching, catch and throw, etc.

Ответ на »сообщение 2250« (Alexey Veselovsky)
___________________________

на Обероне либо не появились бы вообще, либо решаются достаточно просто. Да, арифметика указателей и сборщик мусора тут не при чем.

Любопытно, что именно там было. Если строгая типизация, то ясно.

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

Ответ на »сообщение 2242« (Geniepro)
___________________________
Есть великолепная фраза на эту тему. Создай язык для дураков, и только дураки будут им пользоваться. :))

Фраза великолепная. Может быть при желании приложена, например, ко всем, кто повелся на С++ или ФЯ...

Ответ на »сообщение 2251« (Антон Григорьев)
___________________________
Point taken :))

Оберон (имеется ввиду даже именно что Оберон, но не КП и не Оберон-2) действительно весьма мощный при своей простоте язык. Ряд проблем которые я решал в последние дни в своем проекте на С++, на Обероне либо не появились бы вообще, либо решаются достаточно просто. Да, арифметика указателей и сборщик мусора тут не при чем.

Тем не менее, у Оберона таки есть проблемы. Иногда (причем это самое иногда - довольно часто случается), возникает необходимость написать множество однотипных классов(и/или модулей) (например, как в моем случае - это коллекция технологических GUI-элементов). При этом весьма большая часть кодов практически неизменна и зачастую зависит только от имени. Ручная писанина этих кодов провоцирует ошибки, особенно когда цейтнот. В С++ есть два механизма позволяющие автоматизировать процесс генерации таковых кодов - это шаблоны, а если не шаблонизируется, то макросы. В Обероне же ничего кроме как копирования текста с последующей ручной её правкой, не остается...

Ответ на »сообщение 2248« (Снегурочка)
___________________________
ФЯ могут использовать и чайники.
Сегодня - практически исключено. Видите ли в подавляющем большинстве учебных заведений ФП не преподают.
На коммерческих курсах ТЕМ БОЛЕЕ. Там затребованы java и сишарп. На ФП быстро бабла не срубишь.
Таким образом если увидите функциональщика то это либо программист прошедший через годы работы с ИЯ и пришедший сам к ФП. Явно не чайник. Чайники будут сидеть на своем любимом VB/delphi/java/csharp всю жизнь, пока их под зад не ткнут.
Ну или редчайший случай если повстречаетесь с выпускником МИТ, Berkley и еще нескольких универов где ФП  преподают.
Надеюсь ситуация с преподаванием ФП в дальнейшем сильно улучшится. Но насчет чайников особенно не надейтесь.
Порог слишком высок. Они раньше отсеиваются. :))

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

Ну почему оберонщики всё время твердят, что ФЯ могут использовать только профессионалы экстракласса, тогда как Оберон идеален для полных чайников, вчера севших за комп?

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

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

Нас хотят уверить, что по надежности Erlang обставил все императивные языки. Один конкретный проект, качество которого оценивали сами разработчики, и при этом, разумеется, не проводили параллельных реализаций на языках-конкурентах - очевидно, не более чем просто success story, рекламная шумиха, которая для специалистов говорит, что в этой сфере язык может использоваться и может добиваться хороших результатов (под чутким руководством такой фирмы как Ericsson, ведь язык был разработан в Ericsson Computer Science Lab). Только и всего.

Немного истории. Начинали они (лидер - Джо Армстронг) в 1986 г. с интерпретатора Пролога, добавив туда понятие процесса. К 1988 г. декларативные вещи были взяты из Пролога, а multi-tasking - из EriPascal и Ada. Вещь была жутко неповоротливая. Пытались решить эту проблему путем привлечения средств компиляции в расширенную WAM (Warren Abstract Machine, виртуальная Пролог-машина) с добавлением примитивов поддержки процессов. В 1992 г. начались работы над BEAM (компилятор с Erlang в Си с добавлением генерации шитого кода). Полезла наружу проблема роста объема кода (требовал больше места, чем шитый код). Полностью на BEAM перешли в 1997 г. В 1995 г. Фил Уодлер (Phil Wadler) пришел к мысли, что языку Erlang нужна своя система типов (пользовательских типов). Type Checker сначала писали на Haskell, затем переписали на Erlang. Информация взята из статьи Joe Armstrong "The Development of Erlang". В ее заключении автор говорит следующее: Typical systems are written in several different languages. Erlang is not good at everything. Large parts of a system might use purchased software packages written in C. Efficient integration with C is essential.

Относительно run-time. Давайте не будем забывать, что run-time пишется на низкоуровневых языках (том же Си). Для Erlang объем Си-кода под run-time (именно run-time, а не интерфейса, как там в случае с исходниками на Java) составляет после повторного подсчета около 6 Мбайт. Если посчитать, что средний размер строки в этих исходниках - 30 байт, то получается около 200 тыс. строк Си-кода (комментариев там минимум). Но женская логика, как тут уже замечали, вещь особенная. Возможно, влияет и на арифметические способности. Так что милости просим пересчитать. Там есть куски под разные платформы, но экспресс-анализ показывает, что эта часть не столь велика (хотя влияет на конечный объем Си-кода под одну платформу).

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

Ответ на »сообщение 2242« (Geniepro)
___________________________
тогда как Оберон идеален для полных чайников, вчера севших за комп?
Есть великолепная фраза на эту тему. Создай язык для дураков, и только дураки будут им пользоваться. :))