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

> Я пишу

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Надеюсь, не

#!/bin/sh
firefox $*

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

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

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

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

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

Они позволяют выражать предметную область удобнее. Яичницу уже жарили. Или вот такие скальные мелочи: несколько списков аргументов + 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 визитор легко превращается в мапу с частичными функциями которые вызываются только если определены на аргументе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И где Лугофски и где JVM? «Собака лает караван идет»©

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

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

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

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

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

Спасибо за ссылку

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

man va_list

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

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

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

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

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

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

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

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

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

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

> man va_list

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

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

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

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

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

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

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

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

если неясно, посмотри на libcurl

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

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

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

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

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

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

при этом wget --help был первоначально выбран из-за большей компактности по сравнению с http://curl.haxx.se/libcurl/c/curl_easy_setopt.html, хотя последний может окажется более понятен дедушке-анонимусу