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

[crypto5]

Можно выработать стандарты форматирования кода правильные.

Не спорю. Можно. Хотя в функции писать, все эти pattern matching с кучей параметров, фиг отформатируешь.

Да ладно, вроде нормально форматируется.

[Интеррапт]

Ссылочку можно на то, что класс с данными, но без логики - это anti-pattern?

Ссылка на что вас устроит? Если какой-нить Знаменитый Гуру Вася Пупкин скажет, что это anto-pattern - то это лично для вас что-то изменит?

Мне логики хватает.

Ну когда вы говорите про anti-pattern, то как бы наверняка подразумевается, что это какой-то общеизвестный факт. Anti-patterns в ООП давно уже и хорошо описаны. Потому что моей логики не хватает понять, почему вот такой класс, как вы его описали "Тупая инкапсуляция данных как responsibility не канает" (т.е. фактически вы описали обычный model class) - это anti-pattern? Вот я и попросил ссылочку, чтобы просветиться. Если же вы anti-pattern в данном случае использовали просто, чтобы звучать убедительней, то позвольте с вашим мнением не согласиться.

[Интеррапт]

Вот если бы было такое чудо, я бы двумя руками его пожал (условный псевдойызык, сам с него ржу)

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

Это тебе так кажется. Было бы в разы удобнее - потому что символ "=" в стопицот раз более читаем для гетов и сетов, чем дебильное getVariable()
На слове "virtual" не настаиваю. На самом деле все, что нужно - некое обозначение, могут ли подклассы переопределить методы доступа к переменной или нет. Все. Существование геттеров и сеттеров в явном виде это какой-то атавизм, как и присутствие названия переменной в в имени методов - ДВАЖДЫ

Хе-хе. Вот ты и сам обьявил то, о чем я говорил последние пару страниц, утверждаю, что Джаве нужны нормальные properties В том же ObjectiveC или C# ты спокойно себе используешь "=" без всяких setXXX()/getXXX

а именно

x.color = 0xff00ff00;

и при этом color - это собственно property. Где в классе ты его просто декларируешь, но если нужно, можешь оверрайднуть, или добавить логику и т.п.

[Интеррапт]

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

Ох уж прямо и стандарт. В С++11 с квадратными скобками живут и не жужжат
() => someCrap()
легко можно заменить на
() { someCrap(); }
или даже на
{ someCrap(); } ()
будет в разы приличнее и привычнее

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

нуууу. как сказать
вот копи-пейст
override def toString() =
"" + re + (if (im < 0) "" else "+") + im + "i"
меня это выбешивает. где начало, где конец - поди разбери. пицот лет обсуждали, что лучше писать if (0==i), чем if (i==0), что имеет смысл лишний раз фигурные скобки поставить, когда пишешь
if (crap)
return other_crap;
а тут такие перцы решили сэкономить. я представляю, сколько хреново обнаруживаемых на глаз багов будет

Ну так кто тебе мешает ставить ";" в конце? Ставь. Синтаксисом Скалы поддерживается. Точно так же как в Джаве можно if() return; писать без { }, а можно и с ними.
В JavaScript тоже можно без ";", но я всегда ставлю ";".

[M. Ridcully]

Ну когда вы говорите про anti-pattern, то как бы наверняка подразумевается, что это какой-то общеизвестный факт. Anti-patterns в ООП давно уже и хорошо описаны. Потому что моей логики не хватает понять, почему вот такой класс, как вы его описали "Тупая инкапсуляция данных как responsibility не канает" (т.е. фактически вы описали обычный model class) - это anti-pattern? Вот я и попросил ссылочку, чтобы просветиться. Если же вы anti-pattern в данном случае использовали просто, чтобы звучать убедительней, то позвольте с вашим мнением не согласиться.

Было такое, на сам придумал, точно помню, что прочитал и нашёл логичным. Если вдруг вспомню или найду - дам ссылку.

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

[Интеррапт]

Ну когда вы говорите про anti-pattern, то как бы наверняка подразумевается, что это какой-то общеизвестный факт. Anti-patterns в ООП давно уже и хорошо описаны. Потому что моей логики не хватает понять, почему вот такой класс, как вы его описали "Тупая инкапсуляция данных как responsibility не канает" (т.е. фактически вы описали обычный model class) - это anti-pattern? Вот я и попросил ссылочку, чтобы просветиться. Если же вы anti-pattern в данном случае использовали просто, чтобы звучать убедительней, то позвольте с вашим мнением не согласиться.

Было такое, на сам придумал, точно помню, что прочитал и нашёл логичным. Если вдруг вспомню или найду - дам ссылку.

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

Ну давайте не будем строить догадки, что я там возражу. Т.к. ссылки все-равно нет. И на 200% уверен, что не будет. Просто по той причине, что обьявлять model class антипаттерном, это мягко говоря странно. А если вы это действительно где-то прочитали, то забудьте как страшный сон.

[M. Ridcully]

Ну давайте не будем строить догадки, что я там возражу. Т.к. ссылки все-равно нет. И на 200% уверен, что не будет.

Вот тут на это ссылаются как на "Data Class": http://martinfowler.com/bliki/CodeSmell.html, и называют code smell, а не anti-pattern. Но самой книжки у меня нет, так что я детальную цитату дать не могу.
Вот тут вроде человек тоже про что-то подобное спрашивает http://stackoverflow.com/questions/4723 ... data-class, правда, в каком-то специфическом контексте (чего-то из Java-мира?). Вторая ссылка не как ссылка на авторитетный источник - просто чтобы показать, что это не порождение моего воспалённого мозга.

[M. Ridcully]

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

Sir, yes sir!
(другими словами, вы очень убедительны)

[Интеррапт]

Вот тут на это ссылаются как на "Data Class": http://martinfowler.com/bliki/CodeSmell.html, и называют code smell, а не anti-pattern. Но самой книжки у меня нет, так что я детальную цитату дать не могу.

Тут вы упускаете одну очень простую вещь, а именно, что в Джаве нет понятия структур, есть только классы (а ведь мы изначально об этом беседовали?). Собственно в С++ тоже структура - это класс, где по умолчанию все декларации public. Не понимаю, в чем смысл спорить о нужности model или data классов.
И если вас уж так пугает, что в классе кроме геттеров и сеттеров нет методов, то добавьте toString() и hashCode()

[Zorkus]

Zorkus,

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

Попробую, но скажу сразу, вы выбирали слегка субъективно, и не делали полного сравнительного анализа. Ни на какую особую объективность не претендую, делюсь опытом. Описанное применимо к Groovy 1.7.5 - 1.8.* (на двойку мы так и не перешли), Java 1.6.29 или около того, JBoss 4.2.* кажется (не ржать).

Мы прежде всего искали язык, который бы нам сущестевенно облегчил написание in-container скажем так, полу-интеграционных тестов, которые работают через Cactus (у нас есть конечно юнит тесты, но много сложной логики в области планировщиков продаж можно протестировать только запуская планировщик целиком на некотором строго ограниченном наборе данных, в том числе потому что там много логики в sql / pl sql написано).

Претензии к текущему фреймворку на яве были такие:
- при изменении кода вне того, что разрешает java hotswap (т.е. изменение сигнатур, добавление мемберов в класс etc) приходилось рестартовать JBoss, что есть waste of time
- для того чтобы создать фикстуру теста приходилось писать часто десятки и сотни строк scaffolding кода (это при том, что и так уже несколько тысяч строк кода было написано в базовых классах). Для одного прогона простейшего шедулера в "реальных" условиях надо залить данные в 12-20 таблиц в БД, на каждой выставить по десятку атрибутов
- усугублялось это тем, что в яве, как я уже сказал, нет поддержки на уровне языка коллекций, дат, пропертей (когда имена переменных занимают по 15-20 символов, реально раздражает), перегрузки операторов, простых замыканий, path expressions и прочих ништяков. Т.е. реально интеграционный тест на поддержку какого-то нового режима работы планировщика, это 500-800 строк кода.

Для тестов хотелось язык, который:

- полностью работает на JVM и полно интегрируется с Java
- более-менее близок к языку Java, чтобы джавист мог быстро начать на нем писать
- имеет достаточно синтаксического сахара
- скорость в общем-то не сильно важна, так как мы тестируем код на Java + бд, т.е. testing harness overhead небольшой все равно.

Что мы хорошего получили от Groovy:

- динамическая перегрузка классов через GroovyScriptEngine, в отличие от java hotswap
- сокращенный размер кода раза примерно в 2
- особенно стоит заметить про билдеры. Я догадываюсь, что это вещь специфичная и мы просто ей удачно нашли применение, но тем не менее. В груви, как вы знаете, есть концепция билдеров (http://groovy.codehaus.org/Builders) - по сути, поддержка для построение иерархических вложенных структур данных на уровне синтаксиса, когда вложенность структуры видна визуально сразу в коде. Мы написали свой билдер для создания большинства наших тестовых фикстур, который в сочетании с разумными дефолтами везде где можно, позволил нам сетапить фикстуру так, чтобы ее стоение было видно визуально. На примерах по ссылке видны билдеры, строящие xml документ, например. У нас был билдер, который аналогичным образом строил граф наших объектов в памяти и записывал в базу, автоматически отслеживая из relationships.
- поддержку тестирования на уровне языка - power asserts (очень вкусная вещь), поддержка моков на уровне языка etc.

Свои впечатления я в блоге описал вот тут: http://mantonov.blogspot.com/2011/04/gr ... ion-1.html

[Zorkus]

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

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

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

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

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

Происходит конечно, архитектура JVM одна и та же под ними, но просто вы редко встретите в классе на Java 10-15 анонимных классов, а в груви коде - запросто.

[Zorkus]

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

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

Я в академиков не верю с тех пор как читал споры торвальдс vs таненбаум про микроядра

[Zorkus]

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

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

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

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

Нет поддержки на уровне языка для кортежей, коллекций, дат, регулярных выражений, замыканий, нет перегрузки операторов там где она не помешала бы, нет пропертей, нет поддержки функционального программирования. Если дальше копать - нет AST-трансформаций, нет мета-классов (MOP).

Порог вхождения это спорный момент, я не знаю как его оценивать. У Java как языка он имхо, низкий (если не лезть в JVM). Высокий - это лисп, хаскелл, эрланг.

[M. Ridcully]

Тут вы упускаете одну очень простую вещь, а именно, что в Джаве нет понятия структур, есть только классы (а ведь мы изначально об этом беседовали?). Собственно в С++ тоже структура - это класс, где по умолчанию все декларации public. Не понимаю, в чем смысл спорить о нужности model или data классов.
И если вас уж так пугает, что в классе кроме геттеров и сеттеров нет методов, то добавьте toString() и hashCode()

Мне кажется, вы уже немножко юлите.

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

Структура в С++ различается "стилистически" - никто не будет кричать, что вы "нарушаете инкапсуляцию" тем, что обращаетесь к полям напрямую, а не через аксессоры. С точки зрения ООП они классами не являются.

[Zorkus]

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

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

+1, метко

[Интеррапт]

Структура в С++ различается "стилистически" - никто не будет кричать, что вы "нарушаете инкапсуляцию" тем, что обращаетесь к полям напрямую, а не через аксессоры. С точки зрения ООП они классами не являются.

В Java структур нет. Если вы не заметили, то речь шла о Java. Если не заметили, то гляньте еще раз.

И вообще вы писали:

Другими словами - у класса должны быть какие-то responsibility, он должен что-то делать. Тупая инкапсуляция данных как responsibility не канает, это anti-pattern.

Ну так классу можно какую угодно функциональность добавить. Например, это может быть protobuf класс в возможностью сериализации и десерацилизации. При этом ничто не помешает вытащить эту функиональность за пределы класса, например анализировать поля при помощи reflection и генерить protobuf код. Или даже добавить оверрайднутый hashCode, вот уже что-то в классе происходит. Вообщем, о чем речь, если вы никогда не используете data classes, т.к. где-то слышали, что это плохо, то переубеждать я вас не буду.

[Интеррапт]

Претензии к текущему фреймворку на яве были такие:
- при изменении кода вне того, что разрешает java hotswap (т.е. изменение сигнатур, добавление мемберов в класс etc) приходилось рестартовать JBoss, что есть waste of time

У меня были такие же претензии, пока я не познакомился с JRebel.

[Zorkus]

Претензии к текущему фреймворку на яве были такие:
- при изменении кода вне того, что разрешает java hotswap (т.е. изменение сигнатур, добавление мемберов в класс etc) приходилось рестартовать JBoss, что есть waste of time

У меня были такие же претензии, пока я не познакомился с JRebel.

То что он платный это еще в общем не так важно, но мы его пробовали еще когда он назывался Java Rebel, году вроде в 2008, и тогда он был сырой. Т.е. после нескольких десятков перезагрузок начинались разные ошибки падать, типа метод не найден и прочее. Я точно не вспомню сейчас, что там было, но мы его попробовали и отказались. Наверное, сейчас пора еще раз попробовать. Что, стабилен он сейчас?

[Интеррапт]

Претензии к текущему фреймворку на яве были такие:
- при изменении кода вне того, что разрешает java hotswap (т.е. изменение сигнатур, добавление мемберов в класс etc) приходилось рестартовать JBoss, что есть waste of time

У меня были такие же претензии, пока я не познакомился с JRebel.

То что он платный это еще в общем не так важно, но мы его пробовали еще когда он назывался Java Rebel, году вроде в 2008, и тогда он был сырой. Т.е. после нескольких десятков перезагрузок начинались разные ошибки падать, типа метод не найден и прочее. Я точно не вспомню сейчас, что там было, но мы его попробовали и отказались. Наверное, сейчас пора еще раз попробовать. Что, стабилен он сейчас?

Ага, довольно стабильный. Я последний год его пользую корпоративно (мы купили корпоративную лицензию на пару десятков человек). До этого пользовал для личных проектов. Хорошо работает. Скажем так, экономит очень много времени и багов особо не заметно. Вообщем продукт своих денег вполне стоит.

[Zorkus]

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

[dotcom]

Я в академиков не верю с тех пор как читал споры торвальдс vs таненбаум про микроядра

Академиков тоже надо фильтровать. Я согласен. Собственно, ренесанс языков начался в 2000-х, потому что академикам гранты выбивать надо. Шлепать новые синтаксисы и поднимать старые семантики - дело веселое и не требующее большого напряжения мозгов и рук. Кстати, Линус и Тененбаум были каждый по-своему правы, что доказала практика. У них ничья.

[АццкоМото]

Хе-хе. Вот ты и сам обьявил то, о чем я говорил последние пару страниц, утверждаю, что Джаве нужны нормальные properties

Блин, получается, что так

[АццкоМото]

Ну так кто тебе мешает ставить ";" в конце? Ставь. Синтаксисом Скалы поддерживается. Точно так же как в Джаве можно if() return; писать без { }, а можно и с ними.
В JavaScript тоже можно без ";", но я всегда ставлю ";".

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

[Sergunka]

Zorkus,

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

Попробую...

Спасибо большое... даже не ожидал, что так подробно

[Alexandr]

АццкоМото
прошу прощения, любопытство раздирает меня изнутри
а это вы на аватаре?