Пойми наконец то одну вещь. Всё, что ты здесь написал относительно моих мотивов — твои домыслы. Спрашивая, почему в Немерле есть такое ограничение я не имел в виду хорошо-плохо — это ты так воспринял. Мне были интересны причины такого выбора.
И вообще, может хватит рассматривать меня при ответе на вопрос, ко мне не относящийся? Это и называется между прочим переходом на личности. Не смог ответить — не надо, ответит другой. WolfHound же ответил, я получил интересующую меня информацию. Сказал "спасибо" в оценках. С тобой же получился бестолковый флейм, в котором меня же и обвиняют в неконструктивности.
Здравствуйте, ambel-vlad, Вы писали:
AV>Там не только сервер приложений, там еще и своя реализация аналога COM/DCOM. Об этом я уже писал в самом начале. Вот для этого и надо поддержка разных языков. Чтобы можно было писать компоненты на разных языках.
Здравствуйте, VladD2, Вы писали:
VD>А многопоточность в Яве вообще не продумана. Ввели какие-то примитивы (да еще и через зад), но толку от этого == 0. Писать многопоточный софт так же трудно как на С++. Тут нужны другие решения: 1) автоматическое распараллеливание, 2) аналог системы сообщений Эрлэнга. Вот это дало бы толк. А ручная синхнонизация крути, не крути все равно приведет к ошибкам которые будет трудно найти.
Несмотря на то, что некоторые механизмы в Java эффективнее
обеспечивают решение отдельных задач программирования параллельных
вычислений, в целом Ада предлагает более доступные и надёжные
механизмы поддержки программирования для параллельных
вычислительных систем.
System.Threading library
General lock objects
Wait/Pulse for threads self-management
Zonnon approach ...
Activities built into objects, none or more
Syntax based dialogs governing interaction
Object level monitor locks via blocks Thread management by the system via
await on pre-condition for continuation
(transparently on single or multiple processors)
Statement level concurency also available
OCTAGRAM wrote: > * /Thread management by the system via > await on pre-condition for continuation > (transparently on single or multiple processors)/
Та же самая Ява с немного большим числом примитивов. Ничего это не
решает, нужно что-то типа Эрланга.
Hi OCTAGRAM
AV>>Там не только сервер приложений, там еще и своя реализация аналога COM/DCOM. Об этом я уже писал в самом начале. Вот для этого и надо поддержка разных языков. Чтобы можно было писать компоненты на разных языках.
O>Есть же XPCOM. Не подходит?
Здравствуйте, Cyberax, Вы писали:
C>OCTAGRAM wrote: >> * /Thread management by the system via >> await on pre-condition for continuation >> (transparently on single or multiple processors)/ C>Та же самая Ява с немного большим числом примитивов. Ничего это не C>решает, нужно что-то типа Эрланга.
Ну тогда Ада — проверенный временем язык, что касается многозадачного программирования.
Активные и пассивные мониторы, механизм рандеву, оператор select...
OCTAGRAM wrote: > C>Та же самая Ява с немного большим числом примитивов. Ничего это не > C>решает, нужно что-то типа Эрланга. > Ну тогда Ада — проверенный временем язык, что касается многозадачного > программирования. > Активные и пассивные мониторы, механизм рандеву, оператор select...
Та же самая Ява, вид в профиль. Изменяя набор примитивов синхронизации
добиться чего-то революционного не получится. В конце концов, они все
сводятся к мьютексу.
Если требуется использовать операции синхронизации — это УЖЕ источник
для трудноуловимых ошибок.
Несмотря на то, что некоторые механизмы в Java эффективнее
OCT>обеспечивают решение отдельных задач программирования параллельных
OCT>вычислений, в целом Ада предлагает более доступные и надёжные
OCT>механизмы поддержки программирования для параллельных
OCT>вычислительных систем.
Несмотря на то, что некоторые механизмы в Java эффективнее
OCT>обеспечивают решение отдельных задач программирования параллельных
OCT>вычислений, в целом Ада предлагает более доступные и надёжные
OCT>механизмы поддержки программирования для параллельных
OCT>вычислительных систем.
Нда... Я бы постеснялся такие статьи цитировать.
Хотя бы потому, что в Java кроме мониторов+volatile есть и:
Короче говоря, автор "сравнения" не знает нормально Java (хотя бы потому, что метод destroy() для потоков не реализован). Про возможность создавать в Java потоки с помощью внутренних анонимных классов — он тоже не подозревает.
Здравствуйте, Cyberax, Вы писали:
C>OCTAGRAM wrote: >> C>Та же самая Ява с немного большим числом примитивов. Ничего это не >> C>решает, нужно что-то типа Эрланга. >> Ну тогда Ада — проверенный временем язык, что касается многозадачного >> программирования. >> Активные и пассивные мониторы, механизм рандеву, оператор select... C>Та же самая Ява, вид в профиль. Изменяя набор примитивов синхронизации C>добиться чего-то революционного не получится. В конце концов, они все C>сводятся к мьютексу.
C>Если требуется использовать операции синхронизации — это УЖЕ источник C>для трудноуловимых ошибок.
Да нет, Яве до Ады далековато будет Да Ява и не преследовала удобство параллельного программирования. Впрочем, удобство родового программирования она тоже не преследовала до поры до времени. Кто знает, быть может, однажды придёт мода и на параллельное программирование.
В Аде нет мьютексов. И вообще нет примитивов. Ни мьютексов, ни сигналов.
Синхронизация встроена в объекты.
Метолы protected объектов могут выполняться одновременно максимум в одном потоке. Разве не это требуется? Только это синхронизация с человеческим лицом.
Про задачи долго объяснять, там механизм рандеву используется, гляньте в Интернете. Если Вы не ещё знали, что это такое, я уверен, Вам понравится.
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Да нет, Яве до Ады далековато будет Да Ява и не преследовала удобство параллельного программирования. Впрочем, удобство родового программирования она тоже не преследовала до поры до времени. Кто знает, быть может, однажды придёт мода и на параллельное программирование. OCT>В Аде нет мьютексов. И вообще нет примитивов. Ни мьютексов, ни сигналов.
Есть. В мониторах. Разница с мьютексами ничтожная.
OCT>Синхронизация встроена в объекты.
И чем оно отличается от явовского synchronized?
OCT>Метолы protected объектов могут выполняться одновременно максимум в одном потоке. Разве не это требуется? Только это синхронизация с человеческим лицом.
Это _сериализация_ "с человеческим лицом". Только очень ограниченная. Синхронизация не сводится к сериализации, это значительно более обширная и разнообразная тема.
OCT>Про задачи долго объяснять, там механизм рандеву используется, гляньте в Интернете. Если Вы не ещё знали, что это такое, я уверен, Вам понравится.
Редкое уродство, jIMHO. Народ попытался заменить схему очередей. Только одно в их идее непонятно — на кой вообще там обслуживающая задача, если можно обойтись одной? Потому что монитор не позволяет сделать удобную для этого случая сериализацию?
Обнаружен новый язык — конкурент Nemerle! Называется Lexico, далее следует пример кода:
/*Fibonacci source*/
tarea:
{
los objetos i, n, primero, segundo, tercero son cantidades
muestre: "Entre el numero de terminos deseados: "
entre: n
copie 0 en i, primero
copie 1 en segundo
mientras i<n haga:
{
copie i + 1 en i
muestre primero
copie primero + segundo en tercero
copie segundo en primero
copie tercero en segundo
}
}
Единственный недостаток — требует .NET:
incluya "System.Windows.Forms"
clase ventana derivada_de "System.Windows.Forms.Form"
{
publicos:
mensajes:
ventana copie "Este es el título de mi primera ventana" en ventana.text
}
Здравствуйте, Aquila, Вы писали:
A>Обнаружен новый язык — конкурент Nemerle!
И чем он конкурировать будет?
A>Называется Lexico, далее следует пример кода:
Кошмар (на Испанском?) поскипан.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, OCTAGRAM, Вы писали:
OCT>А если имена протаскивать как параметризаторы? Каким-нибудь чудесным образом.
По идее конечно можено было бы приделывать имена как атрибуты к методам, но что делать если тип используется только локально? К чему этот атрибут приделывать? Ведь к выражениям атрибуты не прикрепишь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>"Что позволено быку, то не позволено Юпитеру".
Про быков не понял.
AVK> Выпустят .NET Framework 3.5 и всего делов.
Кстати, в Рефлекторе уже есть такой пунктик. Только тогда не ясно почему бы не исправить недоделку и не ввести анонимные типы на уровне этогт самого .NET Framework 3.5.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Пойми наконец то одну вещь. Всё, что ты здесь написал относительно моих мотивов — твои домыслы.
Агащазблин. (с)
L>Спрашивая, почему в Немерле есть такое ограничение я не имел в виду хорошо-плохо — это ты так воспринял. Мне были интересны причины такого выбора.
Дык что же ты тогда выясняешь "зачем сделно такое ограничение?" и кричишь, что это плохо?
Причины выбора тебе объяснили, но ты даже слушать не захотел о них. Ты же умудрился сказать, что тебе так о них и не скзали и попер снова выяснять "зачем вели ограничение?".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
OCTAGRAM wrote: > C>Если требуется использовать операции синхронизации — это УЖЕ источник > C>для трудноуловимых ошибок. > Да нет, Яве до Ады далековато будет Да Ява и не преследовала удобство > параллельного программирования. Впрочем, удобство родового > программирования она тоже не преследовала до поры до времени. Кто знает, > быть может, однажды придёт мода и на параллельное программирование.
Да ничуть Ада не удобнее. Отличается только синтаксическим сахарком и
мелкими деталями.
> В Аде нет мьютексов. И вообще нет примитивов. Ни мьютексов, ни сигналов. > Синхронизация встроена в объекты.
И? Мьютексы никуда не исчезают, если даже встраиваются в объекты. И все
те же проблемы с порядком блокировки и priority inversion никуда не
исчезают.
> Метолы protected объектов могут выполняться одновременно максимум в > одном потоке. Разве не это требуется? Только это синхронизация с > человеческим лицом.
Нет. Остаются все те же проблемы мьютексов.
> Про задачи долго объяснять, там механизм рандеву используется, гляньте в > Интернете. Если Вы не ещё знали, что это такое, я уверен, Вам понравится.
Я использую паттерн "рандеву" уже много лет, в том числе и в Java. В
JDK1.5 он даже в стандартную библиотеку вошел.
Еще раз — рекомендую посмотреть на Erlang. Вот там действительно
уникальный подход к решению проблемы.
Да Ява и не преследовала удобство параллельного программирования. Впрочем, удобство родового программирования она тоже не преследовала до поры до времени. Кто знает, быть может, однажды придёт мода и на параллельное программирование.
