Программирование на Scala

не ворочайте труп

// smaser

Тут мысль пробелага, что Java-е уже не куда развиваться, любые навороты будут встречены в штыки, ибо всё приходится делать backward compatible, и, как следствие, кривым (см. generics). А Scala подобной ерундой не страдает, и будет Java-ой будущего. Кто что думает на эту тему?

>Тут мысль пробелага, что Java-е уже не куда развиваться, любые навороты будут встречены в штыки, ибо всё приходится делать backward compatible, и, как следствие, кривым (см. generics). А Scala подобной ерундой не страдает, и будет Java-ой будущего. Кто что думает на эту тему?

Java будущего - это Fortress, который много заимствует от Scala, но гораздо круче.

SUN уже породил первую версию этого языка - пока это только интерпретатор, запускаемый под Java.

Scala потеряла простоту Java. Даже по сравнению с Java5. А это было очень выжной особенносью Java. А то достали всяки с++ы. =). Уже по этому ей не стоит быть джавой будущего. Как альтернативо - неплохо. Для желающих. Но не более того.

> Scala потеряла простоту Java.

Бред. Scala намного проще жабы.

>Scala потеряла простоту Java. Даже по сравнению с Java5. А это было очень выжной особенносью Java. А то достали всяки с++ы. =). Уже по этому ей не стоит быть джавой будущего. Как альтернативо - неплохо. Для желающих. Но не более того.

А разве Java это не C++ из которого вычли C, а ++ оставили :)

А в принципе-то все более продвинутые ЯП обычно не лишают людей возможности использовать средства своих прародителей.

Не любите классы - берите C++ и живите в нем как в обычном С.

То же и для Scala верно - не хочешь ихних наворотов пиши как на обычной Java.

ну хсинтаксических конструкций хотябы в ней больше. а этого уже не мало. =)

нет, Java - это С из которого вычли ассемблер =). А так как в С сосбно болше ничего особо нет, то остался один синтаксис =). А пользуясь "а эту фичу можно и нне использовать" и рождаются такие монстры как с++... Грань слищком тонкая, по этому по мне так лучше меньше чем мало. Да код на джаве многословен - но всё таки проецесс печатания - далеко не самая времяотнимающая часть программирования.=)

> Scala потеряла простоту Java. Даже по сравнению с Java5. А это было очень выжной особенносью Java.

О да! И поэтому, чтобы что-то написать на Java, надо взять кучу библиотек и фрэймворков, кучу кодогенераторов, аннотаций и т.п. И потом описывать простейшие действия кодом в несколько экранов. И это они называют "простота Java".

> Для желающих. Но не более того.

Быдлокодерам предлагается остаться на ныне отмирающей "Java5".

Скала в лучшем случае нсократит колличество кода. Но никакие библиотеки и фреймворки она не заменит. Не троллите.

>Быдлокодерам предлагается остаться на ныне отмирающей "Java5".

4.2

Ну шо, замочим анонимуса?

>О да! И поэтому, чтобы что-то написать на Java, надо взять кучу библиотек и фрэймворков, кучу кодогенераторов, аннотаций и т.п. И потом описывать простейшие действия кодом в несколько экранов. И это они называют "простота Java".

А скажите мне великий анонимус, сколько библиотек и фреймворков столь любимых анонимусами пыхпыхов, питонов и C++, вам потребуется чтобы написать каркас распределенного приложения (с взаимодействием аля RPC и передачей в сколь угодно сложных данных в сериализованном виде) передающее данные по защищенному каналу (SSL на уровне приложения), со встроенным шедулером, работающее с БД и вытягивающее 300 транзакций в секунду (под траназакцей здесь понимается полноценный удаленный вызов (скажем, от двухсот клиентов одновременно в бесконечном цикле)+парочка запросов к БД+возврат результатов). При этом чтобы оно не падало под этой нагрузкой хотя бы ночь. Использовать стандартные серверы приложений нельзя (в виду их объема), работать должно одинаково под вин и лин. Да и последний штрих - на все про все у вас 4 дня....

Мой ответ прост: spring (со встроенными RMI сервисами) + common-dbcp + commons-ssl + quartz + JDBC драйвер + мелкие собственные наработки - итого меньше 20 метров. И никаких кодогенераторов и аннотаций (конфиги спринга - в старом добром файлике spring.xml)

>Быдлокодерам предлагается остаться на ныне отмирающей "Java5".

Пойду писать свои программки на быдложабке.... С уважением, ваш быдлокодер.

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

>А скажите мне великий анонимус, сколько библиотек и фреймворков столь любимых анонимусами пыхпыхов, питонов и C++, вам потребуется чтобы написать каркас распределенного приложения (с взаимодействием аля RPC и передачей в сколь угодно сложных данных в сериализованном виде) передающее данные по защищенному каналу (SSL на уровне приложения), со встроенным шедулером, работающее с БД и вытягивающее 300 транзакций в секунду

Вообще-то нисколько не потребуется - берешь скажем Ruby - набираешь там "requre 'drb'" (это встроенный Распределенный Руби) - подцепляешь БД доступ (желательно Berkeley ДБ - тогда скорость будет раз в 100 выше) и собственно ВСЕ

>Вообще-то нисколько не потребуется - берешь скажем Ruby

А оно, разве, потянет указанную нагрузку? :) Что-то я сомневаюсь сильно, примеры можно?

>подцепляешь БД доступ (желательно Berkeley ДБ - тогда скорость будет раз в 100 выше) и собственно ВСЕ

а что так мелочится - давай уже hsql в in-memory режиме... медицина тут бессильна

Понабежали блин столько, троль и испугался. Такой флейм убили.. :)

>Понабежали блин столько, троль и испугался. Такой флейм убили.. :)

может это мое призвание мочить форумных троллей?

P.S. Должен остаться только один.... (c)Горе... то есть анонимус

>P.S. Должен остаться только один.... (c)Горе... то есть анонимус

а потом я буду вас учить любить жабу.... так шо бойтесь

P.S. Ща флейм разгорится с новой силой :)

> А оно, разве, потянет указанную нагрузку? :) Что-то я сомневаюсь сильно, примеры можно?

А что, там на долю приложения по условию какие-то вычисления полагаются?

> Мой ответ прост: spring (со встроенными RMI сервисами) + common-dbcp + commons-ssl + quartz + JDBC драйвер + мелкие собственные наработки - итого меньше 20 метров. И никаких кодогенераторов и аннотаций (конфиги спринга - в старом добром файлике spring.xml)

Офигенно простой ответ, я оболдеваю. Если я правильно понимаю условие, то достаточно взять Erlang.

> а потом я буду вас учить любить жабу.... так шо бойтесь

Не дождетесь. По обоим пунктам.

>А скажите мне великий анонимус, сколько библиотек и фреймворков столь любимых анонимусами пыхпыхов, питонов и C++, вам потребуется чтобы написать каркас распределенного приложения (с взаимодействием аля RPC и передачей в сколь угодно сложных данных в сериализованном виде) передающее данные по защищенному каналу (SSL на уровне приложения), со встроенным шедулером, работающее с БД и вытягивающее 300 транзакций в секунду (под траназакцей здесь понимается полноценный удаленный вызов (скажем, от двухсот клиентов одновременно в бесконечном цикле)+парочка запросов к БД+возврат результатов). При этом чтобы оно не падало под этой нагрузкой хотя бы ночь. Использовать стандартные серверы приложений нельзя (в виду их объема), работать должно одинаково под вин и лин. Да и последний штрих - на все про все у вас 4 дня....

40-50 строк на python'e ))

Верной дорогой идешь товарищ (С) Томми.

>А что, там на долю приложения по условию какие-то вычисления полагаются?

А здравый смысл против сферических коней?

>>Вообще-то нисколько не потребуется - берешь скажем Ruby

>А оно, разве, потянет указанную нагрузку? :) Что-то я сомневаюсь сильно, примеры можно?

Ну это как напишешь - а смысл в DRB очень простой - имеешь удаленный объект некоего твоего класса и удаленно вызываешь его методы.

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

На С разумеется шустрее будет - но на Руби я такой клиент-сервер для удаленного сбора данных породил за пару дней. Причем клиент в итоге под Руби под Виндой существует. А сервер - конечно под Линукс.

>40-50 строк на python'e ))

а как там в питоне с RPC? а с SSL(средствами самого питона, чтобы обеспечить переносимость)? а есть ли общий API для доступа разным БД (типа JDBC)?а что есть из IoC контейнеров (чтобы удобнее было собирать систему из готовых блоков)?

P.S. На жабе получилось около 500 строк (значительная часть - это конфиги спринга), зато есть уверенность в результате...

>40-50 строк на python'e ))

А мне вот интересно почему рынок не завален поделками в 40-50 строк на питоне если там все так просто? Почему вообще за 50 лет развитися ЯП высокого уровня все вокруг еще не пишется в 40-50 строчек? А как было бы хорошо - программы для внутренних систем какого-нибудь боинга? Без проблем - 40 строчек и на питоне и полетели....

Систему любой сложности можно уложить в 40 строчек, если внутри этих сорока строчек оперировать только вызовами библиотек, которые за тебя написал кто-то другой. Что вас собственно шокирует? 20 метров? Ну так это уже готовые библиотеки, а собственно кода там скорее всего написано очень мало. Кроме того я не верю что вы упакуете все систему в 40 строчек - удаленный вызов чего-нибудь, может быть, но в там ведь еще должна быть куча всяких вспомогательных элементов (обработка ошибок, журналирование (причем возможно в БД), и пр.).

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

Проблемы с готовыми библиотеками начинаются тогда когда они всем устраивают, кроме одной мааааааленькой возможности. Особенность спринга заключается в том что он позволяет комбинировать совершенно разные вещи, при условии совпадения интерфейса, а там где интерфейсы не совпадают всегда можно написать свой класс адаптер, плюс некоторые очень интерсные фичи, например AOP, автоматическое управление транзакциями или возможность подменить какой-либо метод у класса (даже если он объявлен как final - иногда можеть быть очень удобно).

В результате комоненты программы и их взаимотношения описываются не в коде, а отдельном файле. А в все что нужно сделать в коде - это выдернуть из BeanFactory, готовый экземпляр, уже настроенный, инициализрованный и готовый к работе. Так что 20 метров это вполне приемлемая цена за такой функционал и такой срок.

а когда ты свою жабу целуешь, она уже отвечает? (:

>>40-50 строк на python'e ))

> А мне вот интересно почему рынок не завален поделками в 40-50 строк на питоне если там все так просто? Почему вообще за 50 лет развитися ЯП высокого уровня все вокруг еще не пишется в 40-50 строчек?

Ну клиент-сервер на Руби это я разумеется для собственных нужд породил не для продажи.

А для серьезных подобных вещей я возьму ACE фреймворк и напишу на С++ поскольку привык и скорость в итоге повыше будет.

>Мой ответ прост: spring (со встроенными RMI сервисами) + common-dbcp + commons-ssl + quartz + JDBC драйвер + мелкие собственные наработки - итого меньше 20 метров. И никаких кодогенераторов и аннотаций (конфиги спринга - в старом добром файлике spring.xml)

>>Быдлокодерам предлагается остаться на ныне отмирающей "Java5".

>Пойду писать свои программки на быдложабке.... С уважением, ваш быдлокодер.

Aceler в теме про Monodevelop писал, что "сейчас программы тормозят из-за 'тормозов IO, много проходной обработки коллекций, создания коллекций на пустом месте, вместо создания динамического окна по оным' и т.п" Потом модеры потерли то сообщение как "ответ на Flood" а я хотел, чтобы он развил тему и дал умные советы о том как избегать таких граблей и повысить свой скилл и ману. Сейчас он в ветке по Apple vs Linux, попробую его там спросить

Ты чо, это был не я. Я на C#-то программировать не умею :)

с RPC - все замечательно. вот, например, http://docs.python.org/lib/module-xmlrpclib.html

общий АПИ для БД - конечно имеется, DB API 2, под который написана туева хуча модулей к разным субд.

SSL встроенными (библиотечными) средствами реализуется для клиента. для сервера надо использовать 3rd-party модуль, что, имхо, немногим хуже.

в википедии, в статье про IoC примеры даны на питоне :)) http://en.wikipedia.org/wiki/Inversion_of_control

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

>Aceler в теме про Monodevelop писал, что "сейчас программы тормозят из-за 'тормозов IO, много проходной обработки коллекций, создания коллекций на пустом месте, вместо создания динамического окна по оным' и т.п" Потом модеры потерли то сообщение как "ответ на Flood" а я хотел, чтобы он развил тему и дал умные советы о том как избегать таких граблей и повысить свой скилл и ману. Сейчас он в ветке по Apple vs Linux, попробую его там спросить

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

А по-моему вроде ты. При чем тут C#? Ты зато судя по домстранице на Java сечешь нормально. По-моему ты там отвечал, я еще ник запомнил, не спроста. А потом когда дошел до компа и собрался спросить в той ветке, уже поздно было, и во всех своих кэшах я тоже ничего не нашел. Как на зло, млин, одно путнее сообщение на LOR, и то потерял!

Смысл как раз был, что Ruby, Nemerle, Java, C или C# практически ни хрена не решают, а тормоза в прогах совсем по другим причинам, потому что люди не умеют работать с данными, с массивами, с коллекциями, со списками и т.п.

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

> а как там в питоне с RPC? а с SSL(средствами самого питона, чтобы обеспечить переносимость)?

PyRo + SSL, XML-RPC + SSL

> а есть ли общий API для доступа разным БД (типа JDBC)?

Storm ORM пойдет?

> а что есть из IoC контейнеров (чтобы удобнее было собирать систему из готовых блоков)?

См. флейм про IoC

> Что вас собственно шокирует?

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

> А что, там на долю приложения по условию какие-то вычисления полагаются?

> А здравый смысл против сферических коней?

Здравый смысл подсказывает мне, что заметной разницы в скорости не будет.

А меня - способность некторых решать за всех. Никто не говорил что Java - лучшее и единственное. Только способ решения на нём. И долю скепсиса что на остальных языках всё мега-круто и решается всё на свете в 50 строк.

>Единственный недостаток - мало документации - эта книга как раз и исправит.

Одна книга, для часто и сильно меняющегося ЯП, только на английском и только за большие деньги, даже PDF-ка...

Думаю, ситуацию нужно исправлять как-то поактивнее :)

> И долю скепсиса что на остальных языках всё мега-круто и решается всё на свете в 50 строк.

"Не нужно ждать, не нужно срать, а нужно брать и проверять."

Брал и прверял. Мне лично питон нравится, хотя я вёб-программированием не занимаюсь. Именно после этого и пишу.

> Никто не говорил что Java - лучшее и единственное.

Как никто? Bioreactor, например, говорит.

> Только способ решения на нём. И долю скепсиса что на остальных языках всё мега-круто и решается всё на свете в 50 строк.

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

>Как никто? Bioreactor, например, говорит.

Ну Bioreactor это всё-таки не все =)

На счёт 10 ты несколько загнул (если сравнивать с питоном). Я не отрицаю - на питоне наверняка если захотеть можно писать компактнее чем на джаве. Только не 10 и не 5 раз, если мерять на рельных праграммах. А с учётом мощности ИДЕ вроде eclipse - набирать такой код очень быстро - всё таки я надеюсь мы говорим про тот код где думать надо больше чем печатать =)

> На счёт 10 ты несколько загнул (если сравнивать с питоном).

Я сказал до 10. Возьмем класс с сорока геттерами и сеттерами. На питоне напишем: class A: pass ;)

Только ни один геттер и сеттер я не пишу Alt+Shift+S r и вуаля! Так что...

> Только ни один геттер и сеттер я не пишу Alt+Shift+S r и вуаля! Так что...

Так что посчитай нажатия на клавиши, нужные для генерации 40 геттеров/сеттеров. Можешь еще посчитать количество нагенеренного кода, который в лучшем случае является просто шумом, мусором.

Ява крута библиотеками, язык она в лучшем случае весьма средний (кто сказал почти провальный? :D).

И будешь писать 80 юниттестов либо иметь секс из за путаницы с типами. Динамическая типизация, это штука такая, у неё всегда больше одного конца.

> Только ни один геттер и сеттер я не пишу Alt+Shift+S r и вуаля! Так что...

Мы размер кода обсуджаем или время его написания? Про время никто пока не говорил.

> Ява крута библиотеками, язык она в лучшем случае весьма средний (кто сказал почти провальный? :D).

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

> И будешь писать 80 юниттестов либо иметь секс из за путаницы с типами.

Думаю, число юнит-тестов будет одинаково с явой.

> Динамическая типизация, это штука такая, у неё всегда больше одного конца.

Я в курсе.