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

Господин info21 однако не погнушается даже такой клюквой :)))


Милый Джек, уж что Вы не погнушаетесь помечтать, мы тут все давно знаем 8)))

Ответ на »сообщение 2221« (Сергей Перовский)
___________________________

Ответ на »сообщение 2210« (info21)
___________________________
>>>И позвольте напомнить простой критерий близости к ЧЕЛОВЕКУ:
урок программирования в 8-м классе средней школы.
Ой, сейчас мы породим еще одну жаркую дискуссию.
Потому, что в конкуренты получим Васек :)

Нет, не получим (если обсуждать серьезно) по ряду причин:
1) у Вас же указана ниже.
2) невозможно сделать "единое пространство", "систему" и т.п.

Какому программированию надо учить в школе (и в какой школе) - вопрос тяжелый.
Ну, не надо преувеличивать тяжесть.
Жизнь сама экспериментально показывает.
Вот очевидные глупые препятствия нужно устранять, некое усилие прилагать.

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

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

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

Аналогия с математикой доказывает, что все-таки надо учить. И что нужно "единое пространство" (иначе все равно одна хрення будет получаться, как сейчас это имеет место с программированием).
И, кстати, тогда будет легко показать, что программирование -- вовсе не просто: открыл исходник какого-нить Kernel, и ничего больше объяснять не надо.

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

2. Если я буду писать на лиспе/хаскеле/ерланге - то меня быстро заменить не получится.
...
Ну как ? Ниша понятная вырисовывается ?

Раскрылся ларчик 8))

Во всяком случае отсюда следовает (независимо от прочего функцинального счастья), что ФЯ, как и С++, может быть использован "профессионалом" как инструмент обеспечения себя, милого работой... за счет плебеев вроде info21...

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

И вопрос Сергея Антоновича превращается в такой: где ФЯ невозможно заменить Обероном?

Ответ на »сообщение 2232« (info21)
___________________________
Дак чо... раз ввели присваивание -- получите весь букет проблем. 
Не весь, меньший букет, меньший :)) У вас больше присваивания - больше букет проблем.
У нас меньше присваивания - меньше букет проблем.
Как результат там где вы будете завалены своим букетом проблем, у нас на руках будет букет вполне контролируемого размера, что позволит нам идти дальше в увеличении размера и сложности системы.

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

Ответ на »сообщение 2213« (info21)
___________________________
присваивания удаляются не отовсюду, а ВЕЗДЕ ГДЕ МОЖНО. Понятно что есть места где присваивания убрать нельзя. И ОО с ФП расходятся не в том что это надо делать, а в том ГДЕ это надо делать.


Дак чо... раз ввели присваивание -- получите весь букет проблем.
Q.E.D.

Ответ на »сообщение 2220« (Сергей Перовский)
___________________________

Ответ на »сообщение 2209« (info21)
___________________________
>>>И остается ли ниша (не считая голов и компов сугубых любителей и т.п.) для ФЯ, когда наш ИЯ уже имеет герметичную систему типов включая сбор мусора, еще открытый вопрос.
Давайте без фанатизьму...
В то же время функциональное представление многих алгоритмов не просто компактнее, а по сути надежнее.

Дак я и говорю: вопрос открытый.
Дайте клиенту, грубо говоря, Lisp.CAR и Lisp.CDR etc., и пусть представляет себе алгоритмы...

Функциональное представление, взгляд, стиль -- полезное дело, последний буду спорить...

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

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

простой критерий близости к ЧЕЛОВЕКУ:
урок программирования в 8-м классе средней школы.


Я помню об этом.

Дак я не Вам, про Вас не сомневаюсь :))) Народу...
Хороший критерий.

Ответ на »сообщение 2228« (AVC)
___________________________
ИМХО, достаточно ясно, что механизм многопоточности в Эрланге
не привязан к ФП и для него не специфичен.
Господи, да при чем тут механизм многопоточности ?
Для решения задачи многопоточности выбран этот механиз.
Для решения проблем присущих этому механизму многопоточности выбран ФП.
Соединения ФП с shared nothing mesaging дает вам Erlang.
Без ФП на базе скажем оо (например оберон) будет вам активный оберон.
БЕЗ тех преимуществ которые дает Ерланг однако с теми преимуществами которые дает Actor model.

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

ИМХО, достаточно ясно, что механизм многопоточности в Эрланге
(т.н. Actor: model http://en.wikipedia.org/wiki/Actor_model )
не привязан к ФП и для него не специфичен.
В свое время я применял в чем-то сходный (не зная об этом :) ) подход асинхронного обмена сообщениями в программах на Си++.
В подтверждение стертых Вами из русской Википедии слов, существуют ОО-языки с Actor model:
http://en.wikipedia.org/wiki/E_programming_language

Ответ на »сообщение 2226« (AVC)
___________________________
Английская страница ясно различает ФП и параллелизм в Эрланге:
Было бы трудно их спутать :)))
Параллелизм это задача, которую требуется выполнить. Для решения этой задачи выбран механизм shared nothing messaging. А вот для избавления от проблем deadlocks и race conditions ПРИСУЩИХ ПАРАЛЛЕЛИЗМУ и выбрана ФП
Еще раз повторяю. Было бы трудно спутать ФП и параллелизм, парадигму и задачу :))