LINUX.ORG.RU

Группа разработчиков Scala получила грант Евросоюза

 , , ,


1

4

Группа разработчиков языка Scala получила грант Евросоюза, выиграв конкурс языков для параллельного программирования. Разработчики получат в течение следующих 5 лет на развитие своего детища 2,3млн €.

Scala — язык программирования для платформы JVM, сочетающий возможности объектно-ориентированного и функционального программирования. Scala был разработан в лаборатории швейцарского ВУЗ’а EFPL.

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: Zhbert (всего исправлений: 3)

Ответ на: комментарий от r

> Я пишу

«Максимилиан Андреевич считался, и заслуженно, одним из умнейших людей в Киеве.»

anonymous
()
Ответ на: комментарий от kifer

>> все АппСервера, JPA и Hibernate живут через генерацию на ходу доп.классов по прототипу существующих

С _расширением_ интерфейсов дополнительными методами, вы, таки, уверенны?

если приложение написано правильно, то да, интерфейсов. А если криво и нет интерфейсов - то расширяют от классов. Хотя конкретный код не читал.

VoDA ★★
()
Ответ на: комментарий от VoDA

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

kifer
()
Ответ на: комментарий от r

> Я еще заметил что банальный Option - делает программы намного более надежными в плане необработанных инвариантов, при чем значительно короче чем в жабе.

Банальная спионеренная из Хаскелля монада Maybe. :) А так - всё верно.

pitekantrop ★★★
()
Ответ на: комментарий от anonymous

>>Код на Scala пишу быстрее кода на Java в 2-10 раз в зависимости от задачи.

Ну что тут скажешь - аргумент. А производительность свою вы как архимаг - по числу строк меряете?

Не, по числу строк - за то же время успеваю написать в 2-3 раза меньше. :)

Это мои субъективные впечатления, замеров я не делал.

Доказывать я тут ничего не собираюсь. Будет хорошо, если несколько программистов, прочитав это обсуждение, захотят узнать больше о Скале. А победа в споре с виртуальными остолопами меня не интересует.

pitekantrop ★★★
()
Ответ на: комментарий от pitekantrop

На sh можно написать за минуту такое, что ты будешь писать на Скале годами и не напишешь. Например, текстовый процессор очень легко пишется, а также браузеры. Я их уже много написал.

anonymous
()
Ответ на: комментарий от maxcom

> визитор в классическом виде редко когда нужен, это скорее нарушение дизайна чем полезный паттерн

Визитор редко нужен, когда язык поддерживает double dispatch. Ввиду отсутсвия такового в Java этот костыль позволяет повысить качество жизни пациента.

pitekantrop ★★★
()
Ответ на: комментарий от anonymous

На sh можно написать за минуту такое, что ты будешь писать на Скале годами и не напишешь. Например, текстовый процессор очень легко пишется, а также браузеры. Я их уже много написал.

Надеюсь, не

#!/bin/sh
firefox $*
? :)

pitekantrop ★★★
()
Ответ на: комментарий от pitekantrop

Именно так. Это я к тому, что имея библиотеки и т.п. можно сделать и на каком-нибудь пресловутом паскале столько за час, сколько нельзя сделать на супер-пупер-языке Х за год.

anonymous
()
Ответ на: комментарий от anonymous

>Это я к тому, что имея библиотеки

Библиотеки тут не при чем. У меня в проекте в процессе развития некоторых модулей - они были переписаны с жабы на скалу - то есть могу сравнивать при прочих равых условиях. На скале часто получалось так то что было большими классами в жабе - в скале было стыдно пихать в разные файлы. Объмы кода при равном функционале уменьшились в разы.

r ★★★★★
()
Ответ на: комментарий от r

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

anonymous
()
Ответ на: комментарий от anonymous

У меня в проектах такие заморочки непосредственно по прикладной области, что вопросы языков программирования находятся на тысячном месте и любые мега-навороты любых языков абсолютно бессильны чем-либо помочь.

Они позволяют выражать предметную область удобнее. Яичницу уже жарили. Или вот такие скальные мелочи: несколько списков аргументов + PartialFunction:

scala> def cool(x:Int)(f:PartialFunction[Int,Int]) = if (f.isDefinedAt(x)) f(x) else -1
cool: (x: Int)(f: PartialFunction[Int,Int])Int

scala> cool(5) { case 4 => 10; case 5 => 20 }
res0: Int = 20

scala> cool(10) { case 4 => 10; case 5 => 20 }
res1: Int = -1

добавляем parial application

scala> val cool4 = cool(4)(_)
cool4: (PartialFunction[Int,Int]) => Int = <function1>

scala> cool4 { case 4 => 10; case 5 => 20 }
res2: Int = 10

такие вот мелочи которые упрощают код и позволяют строить нужные абстракции (например в акторах).

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

r ★★★★★
()

Чуть не прочитал: Группа разведчиков «Scala» трампам-пам Евросоюза.

Ну, думаю, опять спецслужбы попалились где-то.

void_ptr ★★★★
()
Ответ на: комментарий от www_linux_org_ru

>вот попробуй передай функции *позиционно* 20 аргументов в языке без ключевых параметров; при этом еще у всех этих аргументов есть умолчания, свои для каждой функции

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

anonymous
()
Ответ на: комментарий от VoDA

>утечка возможна только там, где программист может получить память и забыть ее вернуть. в языках высокого уровня Java, C# или той же scala утечка ПАМЯТИ невозможна.

Она там не невозможна, а узаконена и естественно возникает. Достаточно сравнить потребление оной с программами на С.

anonymous
()
Ответ на: комментарий от anonymous

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

О чём и речь. И такая ситуация в большинстве дельных проектов.

anonymous
()
Ответ на: комментарий от Quasar

>NeXTStep так и не выбилась вперёд.

ага, не выбилась. особенно после того, как на нее нацепили лук-эн-фил другой системы, переименовали в Mac OS X и она заняла второе место среди десктопных операционных систем.

А Mosaic по кусочкам растащили, да проприетарные поделия понаклепали.


и ПО, основанное на ее коде до сих пор занимает немногим менее 50% на рынке броузеров.

Ingwar ★★★★★
()
Ответ на: комментарий от r

>Конкретный пример

Лесенка жуткая. Однозначно нужно использовать какой-то комбинатор. Хотя бы на уровне User-Scheme.

Кстати, есть библиотечка scalaz :)

Macil ★★★★★
()
Ответ на: комментарий от pitekantrop

>Доказывать я тут ничего не собираюсь. Будет хорошо, если несколько программистов, прочитав это обсуждение, захотят узнать больше о Скале. А победа в споре с виртуальными остолопами меня не интересует.

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

anonymous
()
Ответ на: комментарий от anonymous

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

Пишите до сих пор на ассемблере? Кстати, PDP-11 и VAX-32 вместе с альфой были очень неплохи.

dave ★★★★★
()
Ответ на: комментарий от anonymous

> И такая ситуация в большинстве дельных проектов.

На постановку задачи часто влияет то, какими средствами задача будет решена. Тут связь в двух направлениях. Одно зависит от другого.

dave ★★★★★
()
Ответ на: комментарий от Karapuz

> Мне вот интересно, откуда у троллей с топика по ссылке сложилось мнение что «Каким бы рациональным не казался вариант с *VM, пока за Scala стоит мягко говоря не идеальный JVM, все её преимущества будут рубиться на корню»?

тред не читай @ сразу отвечай

Как-то приходилось читать рассуждения Луговского на эту тему - он сокрушался, что в JVM нет ряда нужных инструкций, без которых многие динамические языки будут люто тормозить. Безболезненно добавить их, по его словам, было нельзя, т.к. очень много чего перестало бы работать.

anonymous
()
Ответ на: комментарий от Karapuz

Луговский, насколько я слышал, сейчас в Лондоне работает. А Джава, судя по статистической аналитике, уже лет 5 стабильно катится в ж.

anonymous
()
Ответ на: комментарий от Karapuz

> «Собака лает караван идет»©

Судя по всему, идут оба каравана - и Луговский, и JVM. Луговский, если не ошибаюсь, пилит свой убер-оптимизатор кода .net и неплохо с этого имеет. Но речь не о Луговском самом, а о том, что он имел реальный опыт написания компиляторов в жабовый байт-код, и утверждал, что ничего хорошего там не увидел (точнее, он подробно расписывал технические причины). В частности, он также упоминал, что Scala будет вечно тормозить из-за жабы. Конечно, Луговский не истина в последней инстанции, но объективных причин ему не верить или сомневаться в его компетентности у меня нет.

anonymous
()
Ответ на: комментарий от anonymous

> которых многие динамические языки будут люто тормозить

Пардон, тут я соврал - проблема была в отсутствии tail call optimization, и, следовательно, функциональных языках.

anonymous
()
Ответ на: комментарий от anonymous

А Джава, судя по статистической аналитике, уже лет 5 стабильно катится в ж


А ты не читай оналитеков с ЛОРа, верь своим глазам. Я вот поставил 1.7.0-ea b124 и начиная с этого билда Idea 10 CE запускается на глаз примерно за 2-3 сек. Правда, у меня SSD, но все таки JRE вылизывают жоско

Karapuz ★★★★★
() автор топика
Ответ на: комментарий от anonymous

>что Scala будет вечно тормозить из-за жабы

А я например, слышал утверждения что F# будет вечно тормозить из-за CLR. Это разве чего-то доказывает? Чтобы запилить нормальный рантайм нужны десятилетия.

Меня вот больше беспокоит, что разработчики даже и не чешутся устранять стирание типов в генериках. Да еще их заигрывание с динамическими языками.

Macil ★★★★★
()
Ответ на: комментарий от anonymous

>Евросоюз уже выбрал перспективную ОС - Minix 3.

Теперь перспективный ЯП - Scala...


Когда они выберут «калину» как перспективное авто? :)

matumba ★★★★★
()
Ответ на: комментарий от matumba

«калину» как перспективное авто?


В КАЛину как в перспективное авто вклдывают нефтедоллары в рф

Karapuz ★★★★★
() автор топика
Ответ на: комментарий от qwerky

>среда/библиотека, в которой есть все нужное, плюс отсутствие тормозов

Java не тормозит! (c) Томми.

EvgenijM86
()
Ответ на: комментарий от Karapuz

SSD на старт и работу IDEA влияет очень сильно, купил себе ноут с SSD и очень рад этому факту. На рабочем компе, несмотря на более быстрое железо, работает не так шустро

maxcom ★★★★★
()
Ответ на: комментарий от anonymous

> перспектив у Евросоюза - нет

пока миром правят некомпетентные ламеры никаких перспектив не предвидется.

trueshell ★★★★★
()
Ответ на: комментарий от anonymous

> 20 параметров в фукнции - это уже проблемы в голове разработчика API и язык, способствующий таким извращениям только усугубляет болезнь разработчика, а не лечит её.

посмотри на выхлоп wget --help и скажи, как должна выглядеть функция, предоставляющая аналогичную функциональность

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от maxcom

> В чем оптимизация то тогда заключается?

исходя из того, что процессор колбасит 2Г операций в секунду, а память меняется (в большом) не так уж сильно, можно предположить, что бОльшая часть х, выделенных на куче, окажется неопубликованной — т.е. мусором

потом весь этот мусор придется собирать — и при скорости непоследовательного прохода по памяти раз в 10 меньшей, чем последовательной, получаем не меньше в 100 раз большее время на уборку мусора, чем на его выделение

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

вполне возможно, что есть другие варианты — например, держать под х специальный счетчик ссылок, и если х не опубликован, то реюзать место под ним

однако разные х имеют право иметь разные размеры, и счетчик ссылок тормозит — т.е. работоспособную схему, возможно, придумать и реализовать не так просто

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> потом весь этот мусор придется собирать — и при скорости непоследовательного прохода по памяти раз в 10 меньшей, чем последовательной, получаем не меньше в 100 раз большее время на уборку мусора, чем на его выделение

Короткоживущие объекты находятся в early generation, который чистится довольно эффективно.

maxcom ★★★★★
()
Ответ на: комментарий от VoDA

> все АппСервера, JPA и Hibernate живут через генерацию на ходу доп.классов по прототипу существующих. Ничего технологически сложного, но довольно много геморра. есть библиотеки упрощающие byte-code manupulation.

ну да, причем все происходит под страхом MethodNotImplementedException (или как там его) — поскольку у подгружаемого нет исходника, видимого компилятору, то и гарантировать наличие метода и правильность сигнатуры нельзя

можно, то это уже черная магия - не к лицу ее применять.

лучше прямо скажи «не знаю»

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от maxcom

>SSD на старт и работу IDEA влияет очень сильно, купил себе ноут с SSD и очень рад этому факту. На рабочем компе, несмотря на более быстрое железо, работает не так шустро

Полностью согласен. На мой взгляд SSD - это самое существенное достижение компьюетростроителей за последние лет 5, что появилось на рынке. Ничего так не ускоряет работу машины, как замена HDD на SSD (имеется ввиду на нормальную со скоростями ~100-200Мб/с, а не то что во всякие ЕЕЕреси ставят).

//Пользуюсь SSD с 2008

anonymous
()
Ответ на: комментарий от www_linux_org_ru

>посмотри на выхлоп wget --help и скажи, как должна выглядеть функция, предоставляющая аналогичную функциональность

man va_list

anonymous
()
Ответ на: комментарий от www_linux_org_ru

и при скорости непоследовательного прохода по памяти раз в 10 меньшей, чем последовательной, получаем не меньше в 100 раз большее время на уборку мусора, чем на его выделение


вполне возможно, что есть другие варианты — например, держать под х специальный счетчик ссылок,


мусор не собирается и не считаются ссылки.

Karapuz ★★★★★
() автор топика
Ответ на: комментарий от Karapuz

>А ты не читай оналитеков с ЛОРа, верь своим глазам.

Я имел ввиду не здешних аналитиков, а то, что публикует tiobe и т.п. Мне как заядлому прагматику в выборе программной платформы для своего креатива в первую очередь интересуют перспективы на будущее. Если я сейчас пишу скажем на нативных (без VM) языках типа С/С++, то я почти уверен, что и через 10-20 лет можно будет собрать на широком спектре платформ. А во всяких байт-кодовых языках наблюдается жестокая конкуренция и совершенно не понятно какая платформа станет мейнстримом в будущем. Не исключаю что и все эти разработки зарулит какая-ть новая технология, ибо развиваются они довольно вяло. Тут же можно вспомнить про постоянные патентные/лицензионные войны в области этих VM. И картина становится совсем туманной, поэтому в результате можно оказаться в полной ж., которая предстоит всяким новомодным флеш-сильверлайт разработчикам, которых очевидно в скором будущем вытеснит HTML5. Так что я в некотором смысле трус и не хочу жертвовать собой и лезть на фронт этой войны со своими поделками (да и воевать тут на мой субъективный взгляд особо не за что), я выбрал позицию наблюдателя, который в стороне тихо и мирно пилит свой огород.

anonymous
()
Ответ на: комментарий от VoDA

> все АппСервера, JPA и Hibernate

подробнее: можно через рефлексию узнать методы класса Element вместе с их сигнатурами; дальше принципиально можно при класслоадинге проверить, что

1. загружаемый класс имеет все методы класса Element

2. он дополнительно имеет метод accept с правильной сигнатурой,

но дальше что? как будем вызывать этот accept? через getMethod(«accept») — т.е. ничем не лучше всякой динамической шняги типа РНР

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от anonymous

> man va_list

то есть ты (хотя кто вас анонимусов различит) уже не считаешь, что 20 параметров — это дефект АПИ?

ну и пусть va_list — тебе придется придумывать свой poor man's способ передачи ключевых параметров — например

wget( HTTP_ADDRESS, «example.com», NO_VERBOSE, 1, RECURSIVE, 1, END );

или тот изврат что в curl-е — а он действительно изврат, т.к. реально из-за был (не мной) словлен баг

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от anonymous

> Не исключаю что и все эти разработки зарулит какая-ть новая технология, ибо развиваются они довольно вяло.

Что типа NaCl, если добавить в железо сущую мелочь — бит аппаратного запрета джампов на некратное 16.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Во большинстве программ это дело парсится каким-ть gtk_init или FRAMEWORK_PROGRAM_run, корые получаюь argc/agrv и разбрасывают параметры по адресам. Разработчик уже работает с готовыми данными. Т.е. никакой проблемы тут нет и не было.

anonymous
()
Ответ на: комментарий от www_linux_org_ru

>речь идет не о парсинге agrv, а о *функции*, принимающей дохрена параметров

посмотри на выхлоп wget --help и скажи, как должна выглядеть функция, предоставляющая аналогичную функциональность


Ты уже определись, детка.

anonymous
()
Ответ на: комментарий от anonymous

> Ты уже определись, детка.

я давно определился, дедушка

повторю еще раз для тех, кто в танке — функция должна принимать не массив строк (типа char** arvg), а кучу параметров с разными типами; каких параметров и с какими типами можно *предположить*, посмотрев на выхлоп wget --help или *узнать*, взглянув на http://curl.haxx.se/libcurl/c/curl_easy_setopt.html

www_linux_org_ru ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.