japgyrus....что Scala приложение компилируется в байт код, который исполняется Java Virtual Machine - той-же самой,которая исполняет байт код скомпилированного java приложения...
так это зависит от реализации только, разве нет?
если какой-то умник сделает (такие подделки уже есть) это под тот-же самый CLR, то возможности расширятся ;)

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

japфантазируя дальше: тот же IBM может (при желании) сделать нативе поддержку для мэйнфрэймов , если кому-то надо будет...
Фантазируя дальше: И придет великий Саурон и настанет царствие божие на земле...

Кстати... Знаете как именуются люди, которые воспринимают свои фантазии как часть реального мира?

VoDABasil A. SidorovНу ладно двусвязный список - можно идти двумя потоками с разных концов и встретиться "где-то на Эльбе", но в классическом односвязном ...

P.S. Нет, не надо мне рассказывать, как "поделить" список на сегменты или "превратить" в массив.Если результат обработки элемента списка не зависит от предыдущего потока обработки, то можно легко разделить список на Н-частей, обсчитать отдельно, а затем сложить вместе результаты вычислений.

ForkJoin как раз для таких мат.задач и сделали. Причем теоретически ForkJoin может работать и между нодами. Получаем классический MapReduce, только без фазы Map ;)

PS да, на списке в 10-1000 элементов выгоды не будет. Думаю, что это готовятся выйти на рубеж Терабайтных модулей памяти и обработки всего-и-вся прямо в памяти.

Скажу больше - упомянутая паралельная обработка списков в скале реализована именно посредством Fork-Join Framework (и java версия озняенной функциональности будет реализована точно так-же)

schwagyrusпропущено...

Давайте лучше вы про них почитаете а? В частности о том, как они, параллельные коллекции реализованы... Потом попробуйте ответить на такой вопрос - являются ли означенные параллельные коллекции семантическим свойством Scala? Потом почитайте про fork-join framework в java и - чисто для саморазвития про ParallelArray (только будьте внимательны - последнее это jsr166z)

И вот ПОСЛЕ того как вы про все это почитаете, попробуйте сделать утверждение, что параллельные коллекции есть уникальное свойство Scala, которое в принципе невозможно реализовать в java... А мы прожем...
А вы только попробуйте их использовать без лямбд. А мы прожем (c) :))

Как это МОЖНО сделать без "лямбд" вы можете посмотреть на примере библиотеки Guava
Кроме того, вы можете взять на себя труд ознакомиться с примером упомянутого ранее мною ParallelArray

Наконец, как новообращенный адепт лямбда исчисления вы могли бы поинтересоваться запланированными на ближайшее будущее изменениями java платформы

И в порядке вашего личного просвещения - те самые параллельные коллекции в скала сеализованы самыми что ни на есть штатными средствами java...


Вот теперь пора ржать... Когда проржетесь Вы можете написать ответ на данное сообщение в котором в частности упомянете, что Скала предоставляет гораздо более элегантный способ обработки коллекций... О чем я и писал изначально - ВСЕ преимущества Scala заключаются в предоставлении более продвинутого синтаксиса, позволяющего реализовывать функционал намного более кратким и выразительным образом, чем Java. Все что можно сделать в Scala можно сделать, причем без особых затруднений в Java (Конечно код будет более многословным, но результирующий байт-код принципиально будет таким-же) Это ЕДИНСТВЕННОЕ преимущество является преимуществом только в глазах разработчиков. Тем кто платит разработчикам деньги глубоко по барабану насколько разработчикам УДОБНО писать код... Они конечно в принципе не простив, но при условии, что это как минимум не увеличит риски и, в меньшей степени - расходы.


schwaК вам вопрос. Когда вы последний раз писали код, использующий классы из j.u,c? И как часто вы это делаете?
Никогда - я даже не знаю, что такое "j.u,c" - мы ведь академиев не кончали

Alexey KuznetsovКоллеги, как вы считаете, с учетом выхода java 8 насколько актуально выглядит scala?

Вполне актуально... Точнее вполне может быть актуально... В будущем.. Причем вне зависимости от java 8
Но деньги за нее пока не платят

Alexey KuznetsovP.S. java 8 еще долго ждать, но все же?
Почему долго? несколько месяцев... 4-6 наверное...

grasoff.netLeonidvпропущено...

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

вощето вы оба сказали одно и то же.

Это потому, что вы видимо тоже "слабо понимаете в программировании" :)

grasoff.netя исправил ошибки в цитате, чтобы было понятнее.
такшто както не ясно причем тут "вопрос" да ещё и глупый.
Как при чем?!!!! Надо же как-то выявлять тех, кто "слабо понимаете в программировании"??!!!

Kenny Fartmangyrus Но вы несомненно можете найти эту тему сами... Это совсем просто... Если у вас не получится с первого раза, а также со второго и еще нескольких последующих, я вас научу... Это я только в программировании слабо понимаю.... Ав поиске я огого!!!Это Функциональное программирование чтоли?

Не уверен на 100% но очень на то похоже... я конечно не про ссылку на конкретный пост, а про всю ветку

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

LeonidvЕсли я все правильно понимаю, Одерски пытается решить задачу на уровне языка + компилятора. Если у него получится, Scala станет классным средством. Понятно, что реализация распределенных вычислений будет следующий задачей, причем практически решенной.
Я конечно слабо понимаею в программировании, но русским и английским языками я владею в достаточной степени, чтобы сообщить вам, что вы все понимаете неправильно - Одерски НЕ пытается решить задачу на уровне языка + компилятора. Одерски разрабатывает прикладную библиотеку, которая позволит создавать DSL для конкретного класса задач. Созданный DSL может содержать реализацию конкретных алгоритмов распаралеливания для данного класса задач. В качестве примера я уже приводил реализацию паралеллной обработки коллекций в Скала - это БИБЛИОТЕКА (т.е. реализация не на уровне языка), которая реализует алгоритмы распаралеливания для выделенного класса задач - не более того... Допустим вам приперло реализовать распаралеливание некотороых алгоритмов на графах - вы вполне можете реализовать свою собственную библиотеку на Scala или на java в той=же самой манере как это сделано для параллельных коллекций в Scala (приперло на самом деле мне и я в общем практически реализовал - на java - это просто пример...) - иными словами вы фактически можете реализовать алгоритм распаралеливания для узкого круга задач, засунуть его в библиотеку или реализовать DSL (что в общем-то тоже самое) и пользоваться в свое удовольствие "автоматическим распараллеливанием"

Так вот, собственно пан Одерски и собирается предоставить библиотеку, которая позволит делать вышеописаное посредством неким особо элегантным способом (Синтаксис Scala вообще очень хорошо подходит для определения DSL) - по крайней мере он обещал это сделать... в течении 5 лет...

LeonidvgyrusСинтаксис Scala вообще очень хорошо подходит для определения DSL
Не догадываетесь, почему синтаксис Scala очень хорошо подходит для определения DSL?

НУ КАНЭШНА НЕТ!!! Я вообще вообще слабо понимаю в программировании - куда мне... Но вы пишите-пишите... Мне так не хватает ваших откровений!

Kenny FartmangyrusТак вот, собственно пан Одерски и собирается предоставить библиотеку, которая позволит делать вышеописаное посредством неким особо элегантным способом тогда почему в жабе без и даже в скале нельзя сделать LINQ без добавления в язык пресловутых макросов? И вообще, что дает программистам С# этот LINQ если жаба программисты обходятся без него, с помощью резалтсетов и ORM?

Простите сударыня, не могли бы вы уточнить ваш вопрос? Правильно ли я понимаю, что полностью ваш вопрос звучит так:

авторпочему в жабе без и даже в скале нельзя сделать LINQ без добавления в язык пресловутых макросов, если пан Одерски собирается разработать некую библиотеку, которая позволит создавать проблемно ориентированные языки неким особо элегантным способом?