Список перспективных технологий

[Zorkus]

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

Проблема в том, что опыт еще надо где-то поиметь.

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

Эээ нет. Так можно и про груви было бы сказать, но не совсем верно. Чтобы реально сокращать простыни кода на яве в 2-3 раза, и чтобы это выглядело не совсем ужасно и при этом не было медленнее намного чем в яве - именно что надо разбираться глубоко довольно-таки.

[Zorkus]

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

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

Ну давайте признаем, что Java как язык весьма примитивен, по сравнению с другими современными языками (например, руби или питоном). Да, он простой (за исключением отдельных вещей типа generics), его знает армия индусов, под него есть вылизанные почти до предела IDE, у него есть вылизанный javac и прочее и прочее. И в этом его достоинства, но язык примитивен. Замыканий нормальных на уровне языка нет, работы удобной со строками, регексами, массивами, коллекциями, датами - нет, синтаксис громоздкий, поддержка функциональщины..гм, умолчим.

Я лично считаю, что писать сейчас (managed) general purpose языки на чем-то, кроме JVM / .NET это большая трата ресурсов, ненужная. Но я look forward на языки, которые появляются под эти платформы. Потому что они берут плюсы JVM / .NET как платформы, при этом преодолевая проблемы ее базовых языков (Java language).

[smikesh1]

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

Проблема в том, что опыт еще надо где-то поиметь.

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

Эээ нет. Так можно и про груви было бы сказать, но не совсем верно. Чтобы реально сокращать простыни кода на яве в 2-3 раза, и чтобы это выглядело не совсем ужасно и при этом не было медленнее намного чем в яве - именно что надо разбираться глубоко довольно-таки.

я боюсь что при этом не было медленнее намного чем в яве не получится совсем... ну потому что не будет анонимный класс Ф1 быстрее чем обычный фор...) т.е. любая лямбда будет медленнее... и в яве 8 если они для лямбд пойдут таким же путем, судя по всему будет тоже самое...

[Zorkus]

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

Проблема в том, что опыт еще надо где-то поиметь.

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

Эээ нет. Так можно и про груви было бы сказать, но не совсем верно. Чтобы реально сокращать простыни кода на яве в 2-3 раза, и чтобы это выглядело не совсем ужасно и при этом не было медленнее намного чем в яве - именно что надо разбираться глубоко довольно-таки.

я боюсь что при этом не было медленнее намного чем в яве не получится совсем... ну потому что не будет анонимный класс Ф1 быстрее чем обычный фор...) т.е. любая лямбда будет медленнее... и в яве 8 если они для лямбд пойдут таким же путем, судя по всему будет тоже самое...

Ну, в скале я не силен, возьму груви как пример. В груви любое замыкание - это новый класс, наследующийся от groovy.lang.Closure или его сабклассов. Т.е. на каждое новое замыкание в тексте генерится новый класс, которые занимает место в пермгене, которые надо валидировать и грузить в JVM и так далее.

Понятно, что будет медленее. Задача, чтобы не было намного медленнее. Бенчмарки кстати можно найти и сюда кинуть в тред.

[smikesh1]

я боюсь что при этом не было медленнее намного чем в яве не получится совсем... ну потому что не будет анонимный класс Ф1 быстрее чем обычный фор...) т.е. любая лямбда будет медленнее... и в яве 8 если они для лямбд пойдут таким же путем, судя по всему будет тоже самое...

Ну, в скале я не силен, возьму груви как пример. В груви любое замыкание - это новый класс, наследующийся от groovy.lang.Closure или его сабклассов. Т.е. на каждое новое замыкание в тексте генерится новый класс, которые занимает место в пермгене, которые надо валидировать и грузить в JVM и так далее.

Понятно, что будет медленее. Задача, чтобы не было намного медленнее. Бенчмарки кстати можно найти и сюда кинуть в тред.[/quote]
http://shootout.alioth.debian.org/u64q/benchmark.php
на самом деле в гугле куча ссылок, все зависит от задачи на самом деле...

[Zorkus]

Ну, в скале я не силен, возьму груви как пример. В груви любое замыкание - это новый класс, наследующийся от groovy.lang.Closure или его сабклассов. Т.е. на каждое новое замыкание в тексте генерится новый класс, которые занимает место в пермгене, которые надо валидировать и грузить в JVM и так далее.

Понятно, что будет медленее. Задача, чтобы не было намного медленнее. Бенчмарки кстати можно найти и сюда кинуть в тред.

http://shootout.alioth.debian.org/u64q/benchmark.php
на самом деле в гугле куча ссылок, все зависит от задачи на самом деле...

Бенчмарки на этом сайте, помню, Шипилев приводил как пример бенчмарков, которые меряют совсем не то, что надо Не то что я им совсем не доверяю, но надо внимательно смотреть.

[crypto5]

Я не понял аргумента. В скале есть пару фишек вроде выведения типов, лямбд, и хорошо спроектированной библиотеки колекций которые позволяют избегать кучи boilerplate кода. DSL-и тут не причем.

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

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

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

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

[crypto5]

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

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

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

[Sergunka]

Zorkus,

расскажите про Груви конспективно из каких соображений был выбран язык?
Заранее спасибо.

[crypto5]

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

Проблема в том, что опыт еще надо где-то поиметь.

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

Эээ нет. Так можно и про груви было бы сказать, но не совсем верно. Чтобы реально сокращать простыни кода на яве в 2-3 раза, и чтобы это выглядело не совсем ужасно и при этом не было медленнее намного чем в яве - именно что надо разбираться глубоко довольно-таки.

Это утверждение противоречит моему опыту. Как я уже сказал выведение типов, лямбды и правильные коллекции очень сильно сокращают boilerplate.

[crypto5]

Проблема в том, что опыт еще надо где-то поиметь.

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

Эээ нет. Так можно и про груви было бы сказать, но не совсем верно. Чтобы реально сокращать простыни кода на яве в 2-3 раза, и чтобы это выглядело не совсем ужасно и при этом не было медленнее намного чем в яве - именно что надо разбираться глубоко довольно-таки.

я боюсь что при этом не было медленнее намного чем в яве не получится совсем... ну потому что не будет анонимный класс Ф1 быстрее чем обычный фор...) т.е. любая лямбда будет медленнее... и в яве 8 если они для лямбд пойдут таким же путем, судя по всему будет тоже самое...

Ну, в скале я не силен, возьму груви как пример. В груви любое замыкание - это новый класс, наследующийся от groovy.lang.Closure или его сабклассов. Т.е. на каждое новое замыкание в тексте генерится новый класс, которые занимает место в пермгене, которые надо валидировать и грузить в JVM и так далее.

а в джава с анонимными классами такого разве не происходит?

[dotcom]

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

В 70-х годах академики сказали, что лямбды - плохо, читать невозможно. Но вам виднее в 21-м веке. Все относительно. Читаемость кода лямбды могут для кого-то улучшить читаемость. Для вас - возможно. Для программистов, которые будут писать тесты, чтобы учить Скалу, они ТОЧНО не улучшат читаемость.

[crypto5]

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

В 70-х годах академики сказали, что лямбды - плохо, читать невозможно. Но вам виднее в 21-м веке.

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

Все относительно. Читаемость кода лямбды могут для кого-то улучшить читаемость. Для вас - возможно. Для программистов, которые будут писать тесты, чтобы учить Скалу, они ТОЧНО не улучшат читаемость.

та нет, улучшат

[dotcom]

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

В чем его примитивность? Я не знаю ни одного примитивного языка. Порог вхождения в Жабу примерно такой же высоты, что и в Руби и Питон. Возможно даже выше. Дизайн языка и его имплементация - ужас нафиг. Но мульярды денег сделали свое дело. Теперь это мейнстрим. В 95-м году я был таким же оптмиистом-максималистом как crypto и был среди Жаба-энтузиастов. Мне двух лет мучений хватило, чтобы охладиться к языкам и относится к ним спокойно.

Да, он простой (за исключением отдельных вещей типа generics), его знает армия индусов, под него есть вылизанные почти до предела IDE

IDE - есть. Вылизанных - нет.

[dotcom]

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

Копать труды Хоара и Ершова еще раз у меня желания нет. Но википедия вам в помощь. Читаем про историю Алгола:
http://ru.wikipedia.org/wiki/%D0%90%D0% ... E%D0%BB_68

та нет, улучшат

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

[АццкоМото]

Порог вхождения в Жабу примерно такой же высоты, что и в Руби и Питон.

ХЗ. На джаве я просто сел и начал писать, конечно, иногда задавая вопросы кому-то кто язык знал (из всего оркестра выделялся тромбон. возможно, он даже знал ноты - жванецкий). когда я смотрю на руби с питоном и всякие перлы, я понимаю, что они, возможно, не рокет сайенс, но книжку прочитать сначала нужно. но лень, ибо баловство

[crypto5]

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

Копать труды Хоара и Ершова еще раз у меня желания нет. Но википедия вам в помощь. Читаем про историю Алгола:
http://ru.wikipedia.org/wiki/%D0%90%D0% ... E%D0%BB_68

А вы не могли бы процитировать где в той статье про лямбды, а то что то ничего не находится

та нет, улучшат

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

Привожу пример:
List<Person> males = new ArrayList<Person>();
for(Person p: getPersons()) {
if(p.isMale()) males.add(p);
}


val males = getPersons().filter(_.isMale())

Что читабельнее?

[АццкоМото]

и правильные коллекции очень сильно сокращают boilerplate.

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

[АццкоМото]

Привожу пример:
List<Person> males = new ArrayList<Person>();
for(Person p: getPersons()) {
if(p.isMale()) males.add(p);
}


val males = getPersons().filter(_.isMale())

Что читабельнее?

Читабельнее так:
doAllTheNeedfullForMePerFavore();

[dotcom]

ХЗ. На джаве я просто сел и начал писать, конечно, иногда задавая вопросы кому-то кто язык знал (из всего оркестра выделялся тромбон. возможно, он даже знал ноты - жванецкий). когда я смотрю на руби с питоном и всякие перлы, я понимаю, что они, возможно, не рокет сайенс, но книжку прочитать сначала нужно. но лень, ибо баловство

Ну Руби может в ступор ввести в начале. Это факт. Питоновская скриптовая часть проста как дуб. С ООП они намудрили конечно, но надо сделали как сделали из-за совместимости. С C/C++, конечно, проще перейти на Жабу.

[dotcom]

А вы не могли бы процитировать где в той статье про лямбды, а то что то ничего не находится

Там есть пример с анонимными функциями, которые тогда лямбдами называли только в Лиспе. Года 60-е, тогда не любили базворды лепить, как сейчас. Вам легко читать этот код? Как я сказал выше, мне лень заново перечитывать старый мусор. Я не спорю, что функции хорошо вписываются в алгоритмы и итераторы. Должны ли они для этого обязательно быть анонимными? Никогда не думали над этим? Лямбда функции в данном случае сокращают кол-во кода на объявление фукнции. Читаемость улучшается не всегда. Если использовать функцию с именем, то читаемость ничуть не ухудшится. Те, кто учится в колледже и выросли не на Паскалях и Си, а на Питонах-Окамлах (который обязателен во Франции) могут подумать по-другому.

[crypto5]

и правильные коллекции очень сильно сокращают boilerplate.

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

Тем не менее в скала колекции позволяют писать код более правильный чем Java collections + guava.

[crypto5]

А вы не могли бы процитировать где в той статье про лямбды, а то что то ничего не находится

Там есть пример с анонимными функциями, которые тогда лямбдами называли только в Лиспе. Года 60-е, тогда не любили базворды лепить, как сейчас. Вам легко читать этот код? Как я сказал выше, мне лень заново перечитывать старый мусор. Я не спорю, что функции хорошо вписываются в алгоритмы и итераторы. Должны ли они для этого обязательно быть анонимными? Никогда не думали над этим? Лямбда функции в данном случае сокращают кол-во кода на объявление фукнции. Читаемость улучшается не всегда. Если использовать функцию с именем, то читаемость ничуть не ухудшится. Те, кто учится в колледже и выросли не на Паскалях и Си, а на Питонах-Окамлах (который обязателен во Франции) могут подумать по-другому.

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

[АццкоМото]

Тем не менее в скала колекции позволяют писать код более правильный чем Java collections + guava.

и в чем заключается православность?

[M. Ridcully]

Читабельнее так:
doAllTheNeedfullForMePerFavore();

Синтаксическую ошибку выдаёт. Исправить надо:

kindlyDoAllThe... ну и т.д.