M>>Помнится, в Германии надо было гос. портал по поиску работы переделать. Сделать его более удобным в использовании и быстрым. 2 или 3 года, 40 миллионов долларов. Портал так и не сделали.
M>Почему-то напомнило эту историю

В Германии все похуже: http://europa.eu.int/idabc/en/document/2210/353

Я цифры подзабыл однако. Оценка стоимости была 65 миллионов евро. В итоге оценка показала, что он будет стоить около 165 миллионов к 2008 году. Портал в итоге так и не запустили.

M> Состояние этот модуль тоже может хранить

Эмм... процессы Эрланга — они конечно являются тяжеловесными объектами — но все же сколько может быть реально таких процессов вработающей программе? три тысячи? тридцать тысяч? Объектов в C++ или Java программе наверное побольше будет

Здравствуйте, Аноним, Вы писали:

А>Эмм... процессы Эрланга — они конечно являются тяжеловесными объектами — но все же сколько может быть реально таких процессов вработающей программе? три тысячи? тридцать тысяч? Объектов в C++ или Java программе наверное побольше будет

С чего ты взял тяжеловесность? В том и смысл что они "лёгкие" (хотя и тут есть пределы ), по сравнению с потоками обычными.
Вроде как десятки тысяч процессов — это обычная ситуация. А в плюсах и жаве порой есть объекты которые практически только инкапсулируют данные (т.е. struct по сути), реализовывать их в виде процессов довольно странное занятие (хотя тоже может быть нужным )

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Аноним, Вы писали:

А>>Эмм... процессы Эрланга — они конечно являются тяжеловесными объектами — но все же сколько может быть реально таких процессов вработающей программе? три тысячи? тридцать тысяч? Объектов в C++ или Java программе наверное побольше будет

К>С чего ты взял тяжеловесность? В том и смысл что они "лёгкие" (хотя и тут есть пределы ), по сравнению с потоками обычными.

Не читаешь.
Прочитай сначала — процессы Эрланга легковесны по сравнению с нитями ОС — и *тяжеловесны* по сравнению с объектами C++/Java/etc

К>Вроде как десятки тысяч процессов — это обычная ситуация. А в плюсах и жаве порой есть объекты которые практически только инкапсулируют данные (т.е. struct по сути), реализовывать их в виде процессов довольно странное занятие (хотя тоже может быть нужным )

Однако тогда не говори что процессы — замена объектам. Иногда, но только не полностью.

Здравствуйте, Аноним, Вы писали:

А>Прочитай сначала — процессы Эрланга легковесны по сравнению с нитями ОС — и *тяжеловесны* по сравнению с объектами C++/Java/etc

Поясни "тяжеловесность", фактически там есть мессаджбокс и словарь процесса.
Фактически это аналог переменных класса + таблицы методов.

К>>Вроде как десятки тысяч процессов — это обычная ситуация. А в плюсах и жаве порой есть объекты которые практически только инкапсулируют данные (т.е. struct по сути), реализовывать их в виде процессов довольно странное занятие (хотя тоже может быть нужным )

А>Однако тогда не говори что процессы — замена объектам. Иногда, но только не полностью.

Я говорил? Покажи.
Мамут говорил, что процессы могут участвовать в декомпозиции системы также как объекты, как раз на "макроуровне", а таких объектов много быть не может по определению.

К>Поясни "тяжеловесность", фактически там есть мессаджбокс и словарь процесса.
К>Фактически это аналог переменных класса + таблицы методов.

Не знаю как реализован мессаджбокс в Эрланге — но скорее всего он не фиксированной длины и (кажется, но неуверен)из него иногда можно доставать сообщения нужного образца, а не только последний. По сложности это то, что в обычных ООП-языках делается как ещё один объект-контейнер.

VMT состоит из пар integer — ID+указатель. Тоже структура заметно попроще, чем словарь. И она одна на класс, а не одна на объект. Наконец используется она заметно менее гибко — т.е. реализация опять таки проще и ресурсов требуется меньше.


А>>Однако тогда не говори что процессы — замена объектам. Иногда, но только не полностью.

К>Я говорил? Покажи.

ДЕйствительно, Мамут. Но не суть, если ты с ним согласен.

К>Мамут говорил, что процессы могут участвовать в декомпозиции системы также как объекты, как раз на "макроуровне", а таких объектов много быть не может по определению.

Если только объекты макроуровня — то да.

Здравствуйте, konsoletyper, Вы писали:

K>Хотя, лучше я переименуюсь в "shzzxckujzopicnn", чтобы неповадно было!

Заведи себе лучше GUID, как все нормальные люди.

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Здравствуйте, konsoletyper, Вы писали:

K>>Хотя, лучше я переименуюсь в "shzzxckujzopicnn", чтобы неповадно было!

ДГ>Заведи себе лучше GUID, как все нормальные люди.

Их уникальность гарантированна вроде всего на 700 лет вперёд. Может он собирается прожить дольше?

Здравствуйте, Аноним, Вы писали:

[]

По-моему, чистый фп подход продьюсит спагетти-код

Здравствуйте, граммофон, Вы писали:

Г>Проблема с ОО подходом (к проектированию) в том, что никто не знает что это такое и как должно работать. Сколько человек соберется это обсуждать, столько и мнений будет. Потому что не формализировано ничего, никто не знает что такое объект, не говоря уже о проектировании. Отсюда всякая неразбериха с паттернами типами этих объектов — объект-сообщение, объект-прокси, объект-фабрика. На ровном месте.

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

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

Нутром чую, что про выделенное тоже басня была, и не одна, да вот вспомнить не могу... Ну так предложи более эффективную методологию, чем ООП. Чтобы решать сложные задачи, да по щучьему велению. Джин-мартини "Фаулер" в бутылке.

Г>модулями, неймспейсами, пакетами и тп. То есть чисто функционально.

Гы. Модули, неймспейсы и пакеты — ЭТО ДААААА, это без базару, это главные атрибуты функционального программирования. Можно сказать, характеристические. Не удивительно, что тебе никто даже ответить не удосужился. (Я не в счёт, я развлекаюсь.)

Здравствуйте, Константин Л., Вы писали:

КЛ>По-моему, чистый фп подход продьюсит спагетти-код

Эээ, залезем в Вики

Спагетти-код — (1)плохо спроектированная, (2)слабо структурированная, (3)запутанная и (4)трудная для понимания программа, особенно (5)содержащая много операторов GOTO, (6)исключений и (7)других конструкций, ухудшающих структурированность.

И? Причём тут чистый ФП?

Здравствуйте, deniok, Вы писали:

D>Здравствуйте, Константин Л., Вы писали:

КЛ>>По-моему, чистый фп подход продьюсит спагетти-код

D>Эээ, залезем в Вики

D>

D>Спагетти-код — (1)плохо спроектированная, (2)слабо структурированная, (3)запутанная и (4)трудная для понимания программа, особенно (5)содержащая много операторов GOTO, (6)исключений и (7)других конструкций, ухудшающих структурированность.

1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.
2. слабо структурированная. Туда же.
3. запутанная. Как следствие присутствия 1 и 2, плюс спагетти из лямбд и функций высшего порядка. ИМХО сильно ухудшает читабельность и саппорт лиджаси
4. трудная для понимания программа. см. пункт 3.
5. особенно содержащая много операторов GOTO. Ну тут не в тему. Однако что может быть хуже для читабельности, чем "функций высшего порядка"?

Кроме того, спагетти-код был в рифму к "подход"

D>И? Причём тут чистый ФП?

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, deniok, Вы писали:

D>>Здравствуйте, Константин Л., Вы писали:

КЛ>>>По-моему, чистый фп подход продьюсит спагетти-код


КЛ>1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.
КЛ>2. слабо структурированная. Туда же.

Извини, но это уже неприкрытый флейм. Реч шла про код.

КЛ>3. запутанная. Как следствие присутствия 1 и 2, плюс спагетти из лямбд и функций высшего порядка. ИМХО сильно ухудшает читабельность и саппорт лиджаси

Лямбды не порождают спагетти — они замкнуты на себя и никуда не ссылаются.

КЛ>4. трудная для понимания программа. см. пункт 3.
КЛ>5. особенно содержащая много операторов GOTO. Ну тут не в тему. Однако что может быть хуже для читабельности, чем "функций высшего порядка"?

А с ними то что не так? Лаконичнейшее средство абстрагирования

map унарная_функция список

fold бинарная_функция инициализатор список

Где тут спагетти?

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

Здравствуйте, Константин Л., Вы писали:

D>>

D>>Спагетти-код — (1)плохо спроектированная, (2)слабо структурированная, (3)запутанная и (4)трудная для понимания программа, особенно (5)содержащая много операторов GOTO, (6)исключений и (7)других конструкций, ухудшающих структурированность.

КЛ>1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.

Кто сказал такую глупость. Это утверждение неверно в первую очередь из-за того, что ФП сам по себе никак не пересекается с макроархитектурой. Тот же Common Lisp поддерживает как ОО, так и ФП. То же самое можно сказать про Nemerle (правда, это гибридный язык, но, как выяснилось, ФП и ОО в одном флаконе вполне ужились). Есть и несколько другой подход — система типов Хаскеля. Она гораздо мощнее, чем в том же .NET. Единственный минус — если в ОО можно делать "методы-омонимы", т.е. методы у совершенно несвязанных классов, обладающие различной функциональностью, но имеющие одинаковые названия, то в Хаскеле такого провернуть не удастся, потому приходится придумывать кучу префиксов для методов. Но и эта проблема разрешима, т.к. при правильном проектировании такие вещи сводятся к минимуму. Кроме того, никто не запрещает некому Васе придумать систему типов Хиндли-Милнера-Пупкина, где это будет учтено.

КЛ>2. слабо структурированная. Туда же.

Обоснуй.

КЛ>3. запутанная. Как следствие присутствия 1 и 2, плюс спагетти из лямбд и функций высшего порядка. ИМХО сильно ухудшает читабельность и саппорт лиджаси

Это лямбды-то спагетти? Вот когда мне нужно в C# 1.0 что-то отсортировать по сложному критерию, приходится объявлять доп. приватный метод. Так вот и начинает в глазах рябить от нагромождения мелких приватных методов. А если нужно ещё смоделировать замыкания, то приходится делать приватный класс, так что проще "выпитьйаду" и убить себя "апстену". Хорошо хоть, что в C# 2.0 проблема была решена. А в ФЯ эта проблема решена красивее и лаконичнее.

КЛ>4. трудная для понимания программа. см. пункт 3.

Конечно же. Программа на языке, содержащем крутые фичи по объёму меньше, чем на менее мощном языке. Потому средняя скорость восприятия (в строках) такой программы на мощном языке меньше. Надо заметить, что крутой язык — не обязательно ФЯ. Но вот если язык смог правильно позаимствовать из ФЯ хорошие концепции, то это только увеличивает его мощь.

Здравствуйте, deniok, Вы писали:

D>Здравствуйте, Константин Л., Вы писали:

КЛ>>Здравствуйте, deniok, Вы писали:

D>>>Здравствуйте, Константин Л., Вы писали:

КЛ>>>>По-моему, чистый фп подход продьюсит спагетти-код


КЛ>>1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.
КЛ>>2. слабо структурированная. Туда же.

D>Извини, но это уже неприкрытый флейм. Реч шла про код.

я не про код?

КЛ>>3. запутанная. Как следствие присутствия 1 и 2, плюс спагетти из лямбд и функций высшего порядка. ИМХО сильно ухудшает читабельность и саппорт лиджаси

D>Лямбды не порождают спагетти — они замкнуты на себя и никуда не ссылаются.

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

КЛ>>4. трудная для понимания программа. см. пункт 3.
КЛ>>5. особенно содержащая много операторов GOTO. Ну тут не в тему. Однако что может быть хуже для читабельности, чем "функций высшего порядка"?

D>А с ними то что не так? Лаконичнейшее средство абстрагирования
D>

D>map унарная_функция список
D>

D>

D>fold бинарная_функция инициализатор список
D>

D>Где тут спагетти?

а где тут функции высшего порядка? это fold что-ли, который принимает функцию?

D>Что касается претензий к читабельности, то, извини, любой язык надо сначало изучить, пописать на нём какое-то время, а уж потом рассуждать об этой самой читабельности. А то вот я по-финнски ничего не понимаю, нечитабельный, блин, язык.

Да ну как бы никто не возражает. На любом языке можно писать нечитабельно, просто фичеры ФЯ чуть-чуть способствуют этому.

Ладно, мой поинт в том, что оо+фя гораздо привлекательнее и "живучее" чем чистые фя.

PS: просто высказал своё мнение. Вроде форумы именно для этого. Не тратьте силы, чтобы разубедить меня , я либо изменю своё мнение сам, либо не изменю

Здравствуйте, konsoletyper, Вы писали:

K>Здравствуйте, Константин Л., Вы писали:

D>>>

D>>>Спагетти-код — (1)плохо спроектированная, (2)слабо структурированная, (3)запутанная и (4)трудная для понимания программа, особенно (5)содержащая много операторов GOTO, (6)исключений и (7)других конструкций, ухудшающих структурированность.

КЛ>>1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.

K>Кто сказал такую глупость. Это утверждение неверно в первую очередь из-за того, что ФП сам по себе никак не пересекается с макроархитектурой. Тот же Common Lisp поддерживает как ОО, так и ФП. То же самое можно сказать про Nemerle (правда, это гибридный язык, но, как выяснилось, ФП и ОО в одном флаконе вполне ужились). Есть и несколько другой подход — система типов Хаскеля. Она гораздо мощнее, чем в том же .NET. Единственный минус — если в ОО можно делать "методы-омонимы", т.е. методы у совершенно несвязанных классов, обладающие различной функциональностью, но имеющие одинаковые названия, то в Хаскеле такого провернуть не удастся, потому приходится придумывать кучу префиксов для методов. Но и эта проблема разрешима, т.к. при правильном проектировании такие вещи сводятся к минимуму. Кроме того, никто не запрещает некому Васе придумать систему типов Хиндли-Милнера-Пупкина, где это будет учтено.

здесь сказали такую глупость и я с ней согласен

Автор: VladD2
Дата: 23.04.07

КЛ>>2. слабо структурированная. Туда же.

K>Обоснуй.

КЛ>>3. запутанная. Как следствие присутствия 1 и 2, плюс спагетти из лямбд и функций высшего порядка. ИМХО сильно ухудшает читабельность и саппорт лиджаси

K>Это лямбды-то спагетти? Вот когда мне нужно в C# 1.0 что-то отсортировать по сложному критерию, приходится объявлять доп. приватный метод. Так вот и начинает в глазах рябить от нагромождения мелких приватных методов. А если нужно ещё смоделировать замыкания, то приходится делать приватный класс, так что проще "выпитьйаду" и убить себя "апстену". Хорошо хоть, что в C# 2.0 проблема была решена. А в ФЯ эта проблема решена красивее и лаконичнее.

чувствуешь разницу м/у лямбдами и спагетти из лямбд? Ну ладно, тут почти можно отступить.

КЛ>>4. трудная для понимания программа. см. пункт 3.

K>Конечно же. Программа на языке, содержащем крутые фичи по объёму меньше, чем на менее мощном языке. Потому средняя скорость восприятия (в строках) такой программы на мощном языке меньше. Надо заметить, что крутой язык — не обязательно ФЯ. Но вот если язык смог правильно позаимствовать из ФЯ хорошие концепции, то это только увеличивает его мощь.

Проблема — структурированность. Сам писал на clisp, поэтому есть представление.

Здравствуйте, Константин Л., Вы писали:

КЛ>PS: просто высказал своё мнение. Вроде форумы именно для этого. Не тратьте силы, чтобы разубедить меня , я либо изменю своё мнение сам, либо не изменю

Ты есть замкнутая система, которая не разумеет чужих мыслей?

Здравствуйте, Константин Л., Вы писали:

D>>

D>>map унарная_функция список
D>>

D>>

D>>fold бинарная_функция инициализатор список
D>>

D>>Где тут спагетти?

КЛ>а где тут функции высшего порядка? это fold что-ли, который принимает функцию?

Конечно. Это, собственно, и есть канонические ФВП.

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Константин Л., Вы писали:

КЛ>>PS: просто высказал своё мнение. Вроде форумы именно для этого. Не тратьте силы, чтобы разубедить меня , я либо изменю своё мнение сам, либо не изменю

К>Ты есть замкнутая система, которая не разумеет чужих мыслей?

с каких это пор (разумеет мысли) == (разделяет мнение)?

Здравствуйте, deniok, Вы писали:

D>Здравствуйте, Константин Л., Вы писали:

D>>>

D>>>map унарная_функция список
D>>>

D>>>

D>>>fold бинарная_функция инициализатор список
D>>>

D>>>Где тут спагетти?

КЛ>>а где тут функции высшего порядка? это fold что-ли, который принимает функцию?

D>Конечно. Это, собственно, и есть канонические ФВП.

ладно, я имелл ввиду, что мог привести пример понавороченее.