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

Ну и в чём проблемато? Не нравится вызывать N раз функцию? Можно предавать указатель на структуру в формате param_id -> указатель на значение. Или парный массив. Так что никаких потребностей в 20и аргументах по прежнему нет.

>> Ну не смогла Scala за семь лет существования найти широкое применение.

http://www.scala-lang.org/node/1658

>> А оно умеет нормально интегрироваться с мэйвеном? Веб-проекты поддерживает?

Да.

>http://www.scala-lang.org/node/1658

Настолько жалкий список, что хочется дать им субсидии. Особенно Twitter понравился с аж 1500 строками скалакода. Несомненный успех.

>> Настолько жалкий список, что хочется дать им субсидии.

Ну дай, не стесняйся. А на твиттере эти 1500 строк - вся имплементация обработки очереди сообщений. Кто же виноват, что скала такая лаконичная.

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

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

Что самое смешное — это то, что когда у сектантов заканчиваются аргументы, они всегда начинают обзываться и брызжать поносом.

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

Тамошний неудавшийся суицидал сильно в большом восторге от юникода. А я не в восторге от его восторга от юникода, хотя тип весьма грамотные статьи пишет и делает.

>Но речь не о Луговском самом, а о том, что он имел реальный опыт написания компиляторов в жабовый байт-код, и утверждал, что ничего хорошего там не увидел (точнее, он подробно расписывал технические причины).

Никто не против тезнических причин которые приводил луговский. Но - покажите мне существующую VM без этих технических причин - это было раз. Два - плюсы разработки проекта типа скала для JVM - я думаю очевидны - елси бы не JVM - это бы не был язык со стойким трендом роста популярности и грантов из евросоюза бы не было а был бы еще один язык вот здесь http://en.wikipedia.org/wiki/Category:Functional_languages и без платформы он был бы нафиг кому нужен. То есть даже несмотря на грамотность команды и прогрессивность идей - он бы жил с состоянии в котором живет Цомега, уж не говоря что разработка самой подходящей VM отожрала бы огромные ресурсы.

>Да еще их заигрывание с динамическими языками.

Заигрывание даст плюсы и скале - например структурным типам.

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

Ну так последние 3 проекта у меня - именно написание библиотек.

>Однозначно нужно использовать какой-то комбинатор.

Думал об этом. Разные респонсы. Короче не получится.

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

По-твоему я верю, что Скала - лучший на свете язык? Я всего лишь считаю, что она лучше, чем Java, и заслуживает внимания Java-программистов. Точка.

Haskell как функциональный язык куда более прост и понятен, и для изучения ФП я бы рекомендовал именно его.

Ну и не забыть побрызжать поносом на сомневающихся.

Сомневающихся в чем? В полезности Скалы? Откуда появится аргументированные сомнения, если знание предмета спора, т.е. Скалы, отсутствует?

Так что секта - это у вас. Секта умственной лени с девизом: «Я этого не знаю и знать не хочу, а значит это никому не нужно». И даже не замечаете, как «ненужные» концепции работают внутри библиотек и фреймверков, благодаря которым ваших скудных знаний хватает на создание чего-либо полезного.

> Думал об этом. Разные респонсы. Короче не получится.

Угумс. Если разные None не имеют разный смысл, то все эти жуткие каскады проверок очень красиво переписывается в функциональном стиле с помощью map/flatMap/filter.

>Откуда появится аргументированные сомнения, если знание предмета спора, т.е. Скалы, отсутствует?

По-твоему чтобы понять что перед тобой лежит кусок гумна не достаточно на него посмотреть и насладить ароматом, а обязательно нужно распробовать во всех аспектах? Адекватный человек отвернётся и пройдёт мимо, а вы (сектанты) собираетесь вокруг в противогазах и начинаете убеждать других, что оно в общем-то вполне годное, если не принюхиваться.

Так что секта - это у вас.

Ога, типичное поведение сектантов - безосновательное обзывательство.

>Ога, типичное поведение

Ты мне напоминаешь завзятого католика с оторванной крышей времен инквизиции, который думает что все что он не понимает - происки сатаны.

>Ты мне напоминаешь завзятого католика с оторванной крышей времен инквизиции, который думает что все что он не понимает - происки сатаны.

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

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

Чесаться то чешутся, да только type erasure убрать не сломав обратной совместимости довольно геморрно. решения для дженериков рассматривают уже несколько лет. Санки отложили эту фичу до 8-й Джа, а Оракля сделав из 7-к две версии перенес дженерики в 9-ю Джа.

Динамические языки - это модно. Если сделают динамический язык со статический типизацией, то может быть совсем интересно =)))

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

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

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

Вообще Джава может грузить байт-код или исходный код откуда угодно - локальный диск, сеть или СУБД. исходники компилить и подключить к приложению. Обычно это не нужно, но если очень хочется ... ;)

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

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

пару раз пробовал, но дальше прототипа дело не пошло. проще привинтить JavaScript для «динамического» кода. Так что «Не знаю» ;)

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

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

Хороший вопрос. Сам задавался )))

Делаешь интерфейс с методом accept. Важно чтобы этот интерфейс был прописан в новом классе и этот же интерфейс был загружен класс-лоадером.

Дальше получаешь объект и кастишь к интерфейсу. После этого приложение пишется классически - вызов методов безо всякой динамики и рефлекшена ))) Красота ;)))

>Думал об этом. Разные респонсы. Короче не получится.

Так они и должны быть разными. Они только должны комбинироваться единообразно.

>да только type erasure убрать не сломав обратной совместимости довольно геморрно

Конечно, лучше объявить темноту индустриальным стандартом. И уж Оракл тут впереди планеты всей.

Динамические языки - это модно.

Да-да, лет 30 как.

Если сделают динамический язык со статический типизацией

8) Как это?

Настолько жалкий список, что хочется дать им субсидии.

А у тебя баттхерт от того что все делфоклепатели не побросали свои морды к ораклу на делфи и не написали резко миллион приложений на скале? Ну да, там, где можно обойтись гридом к датасету на делфе ею родимой и обходятся и продолжают лепить миллионы Form1.dcu

уж не говоря что разработка самой подходящей VM отожрала бы огромные ресурсы

Мы все с надеждой ждем когда gnu коммьюнити допили свою Vala, чтобы та запускалась везде от zSeries до андроеда

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

>динамический язык со статический типизацией
Чего?

> А вы мне напоминаете сектантов, которые на всех мирян с высока как на быдло. И не суть, что миряне усердно трудятся и работают над насущными проблемами. Вы всё равно их будете безразборно называть лентяями и тёмными, они же не хотят погружаться в детали вашей религии.

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

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

Делаешь интерфейс с методом accept.

__как__ делаешь?

дело в том, что он должен быть разный для каждого Element:

<R,P> R accept(ElementVisitor<R,P> v, P p)

если бы он был например Оbject accept(Object, Object) то его и правда можно было бы один раз «сделать» (т.е. написать)

допустим параметризованный интерфейс:

interface Accept<ElementVisitor> {
  <R,P> R accept(ElementVisitor<R,P> v, P p);
};

и как дальше сказать, что ElementVisitor — это тот класс (вероятно без имени), что мы только что загрузили?

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

Быдло это формально не те, кто малограмотен, а кто позволяет властям управлять собой вопреки личной и общественной выгоде (подобно скоту, которого ведут на бойню).

Впрочем, малограмотность с этим все-таки коррелирует.

interface Accept<ElementVisitor> {
  <R,P> R accept(ElementVisitor<R,P> v, P p);
};

в яве, насколько мне известно, нет аналога template template parameter (а в скале есть) — так что вроде бы на яве такое написать нельзя

да даже если и можно сделать воркараунд для аналога template template parameter, все равно количество телодвижений для реализации простого паттерна «визитор» просто кошмарно

> да даже если и можно сделать воркараунд для аналога template template parameter, все равно количество телодвижений для реализации простого паттерна «визитор» просто кошмарно

возможно =))) вероятно java не лучший язык для реализации визиторов и для конкретной ситуации проще использовать другой язык.

за много лет разработки JavaEE приложений визитор делал только один раз кода пытался написать свой псевдо-«компилятор». В реальных задачах мне визиторы не встречались.

> interface Accept<ElementVisitor> {

<R,P> R accept(ElementVisitor<R,P> v, P p);

type erasure сделает из него

Object accept(Object v, Object p);

в смысле что для компилятора методы <R,P> R accept(ElementVisitor<R,P> v, P p); и Object accept(Object v, Object p); имеют одинаковую сигнатуру. Вероятно каст пройдет и все будет работать на ура.

>Вы всё равно их будете безразборно называть лентяями и тёмными, они же не хотят погружаться в детали вашей религии.

Ты наверное проспал в вузе все лекции по этой религии, потому и думаешь что это происки сатаны.

> Так они и должны быть разными. Они только должны комбинироваться единообразно.

Скомбинировать то можно - короче не получится.

> В частности, он также упоминал, что Scala будет вечно тормозить из-за жабы

А Одерский упоминал, что типичному пользователю Scala на типичное для нее несущественное замедление по сравнению с Java глубочайшим образом начхать. И Одерский таки прав.

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

А теперь смотрим, сколько динамических языков есть под JVM, и сколько есть под доднед (точнее, сколько из них соблаговолили под доднед портировать и забыть). Смотрим на ту же Clojure, которая рулит на JVM и никак не взлетит под доднедом.

Откуда вывод, что все бредни теоретиков про «неправильные инструкции», про «хвостатую рекурсию» и подобную пургу не имеют никакого касательства к реальной практике.

> отказом от тьюринга

Хмм. От Неймана? У тьюринга всё-таки модель и теоремы, от них сложно отказаться v_v.

Еще оно несколько тормозит на amd64 (нетривиальных сегментов в реализации интеля нету ведь!).

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

Никакая не чушь. Ты несколькими постами выше назвал человека лентяем совершенно не зная объёмов его плодотворной работы. Т.е. для тебя критерий один - не знаешь того, что интересует меня и не хочешь по каким-то (возможно вполно объективным и уважительным причинам) этим заниматься - лентяй.

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

Да как ты не понимаешь, что зачастую порой достаточно самого базового обзора объекта, чтобы составить о нём непоколебимую оценку. Так например базирование на всё теряющей позиции Java-платформе - уже достаточный для многих фактор, чтобы компетентно отказаться от использования всего на ней основанного. И детали тут совершенно не играют роли.

> Да как ты не понимаешь, что зачастую порой достаточно самого базового обзора объекта, чтобы составить о нём непоколебимую оценку.

Непокобелимость такой оценки может даже поспорить с твердостью мнения бабок возле подъезда об экономическом блоке правительства.

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

else AccountsStorage.find(login) match {
                        case None => ...
                        case Some(user) if user.inactive => ...
                        case Some(user) if user.authScheme == "PETRIVKA" => ...
                        case Some(user) => ...
                        case _ => ...

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

Может объясните, что не позволило вам вынести обработку результата AccountsStorage.find в отдельный метод, а обработку Some(user) в еще один? И еще не понятно, зачем в данном match нужен 'case _'? И почему обработка разных схем аутентификации выполняется не только в разных логических ветвях, но еще и на разном уровне вложенности?

К чему я это... Вы тут вроде умные вещи пытаетесь писать, анонимусам нотации читаете. Все было бы ничего, если бы вы нормальный код продемострировали бы.

Странные придирки. Код вполне идиоматичен для Ф.П. Паттерн-матчинг и Ф.В.П. избавляют от необходимости городить новую функцию на каждый чих.

>Странные придирки.

Ничего странного, я уверен, что любому С-кодеру, привыкшему писать в Linux-стиле или GCS этот код покажется нечитабельным. Чтобы понять, например, что делает та ахтунговая строка на 148 симоволов нужно въедаться глазами через весь монитор. Складывается впечатление, что в этом стиле суть свернуть всё как можно компактнее по числу строк и назвать это «лаконичностью».

PS. Это притом не характерно для функционального кода вообще (коды в Emacs тому пример).

Код вполне идиоматичен для Ф.П.

Для ФП он вообще не идиоматичен, т.к. весь построен на использовании сайд-эффектов.

А вот нормальную процедурную декомпозицию автор элементарно поленился сделать.

Мне показалось, что тебе не понравился именно паттерн-матчинг, и ты захотел его разбить на части?

Мне показалось, что тебе не понравился именно паттерн-матчинг, и ты захотел его разбить на части?

Да паттерн-матчинг там вообще постольку поскольку (равно как и ФВП). И все равно автор умудрился им злоупотребить. По мне, так нужно было опцию Some(user) выносить в отдельный метод и там уже разруливать inactive, authScheme и пр. А так автор создал один большой паттерн-матчинг с guard-ами. Наверное, для провоцирования спагетти-эффекта.

Впрочем, если не лень читать, то вот.

а по-моему ты сильно перебрал с количеством функций

я бы максимум согласился на дополнительные функции doAncientLogin (альтернативное название doPetrivkaLogin) и doModernLogin; опять же вполне нормальным были бы не эти функции, а просто строки комментариев перед их началом

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

у меня весь текст функции (даже при переразбивке условных операторов на большее число строк) влезает на экран 1024х768 (хотя и со шрифтом вариабельной длинны) — так что смыла бить дальше нет

хотя комментарии обязательны, если функций не будет

и *гораздо* более важное — интересно, а компилятор скалы жалуется на недостижимой код в последнем «case _» ?

* хотя и со шрифтом вариабельной ширины

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

Очень понравилось как вы уделали scala при реализации поиска схемы аутентификации:

AccessStorage.access.auth_configs.find(_.key == user.authScheme)

private AuthScheme findAuthScheme()
{
   // bla-bla-bla
}