Java против C#: какой язык производительнее в реальных проектах?

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

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

В любом случае, как я уже говорил, заменять нормальную архитектуру Monkey Patch'ем - совсем совсем неправильно. То есть когда ты один в поле Д'Артаньян, то еще ничего так, а как только к тебе присоединяться мушкетеры, отстреливать им ноги совершенно не нужно.

Как я и думал, «Avoid needless metaprogramming.» в первом же нагугленном ruby style guide https://github.com/bbatsov/ruby-style-guide#metaprogramming .

потому что полностью статичные системы вряд ли смогут существовать в реальности

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

Как я и думал, с производительностью не очень http://www.ibm.com/developerworks/ru/library/j-aopwork2/

ты точно читал то, что по ссылке?

Вот еще одна, в которой говорится ровно то же самое http://eclipse.org/aspectj/doc/released/faq.php#q:effectonperformance

И вот про spring http://blog.springsource.com/2007/07/19/debunking-myths-proxies-impact-perfor...

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

@Transactional
public void foo() {
   //...do smth
}

что может быть проще?

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

Если Lift - вот,

You don't have permission to access /uploads/posts/2011-11/1321047607_azis_562206.jpg on this server.

что за самостийная незалежность что к картинкам не допускает? беспека та заборона сала вид москалiв?

Погугли azis, чо

нет уж, знаем-с

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

Дальше не читал

Да, похоже гугл перегнал

Ваши страшилки.. ни разу такого не было. Никогда у меня не было ошибок с типизацией. И да юнит тестирование помогает.

100500 проверок везде и всюду

И строк на руби станет не в 4, а в 3 раза меньше.. И проверки эти будут не про типы, а про логические ошибки, т.е. то что надо.

Это просто у вас ритуал такой, никто толком не знает зачем это нужно, просто делают.

Пойди уже почитай

http://newstar.rinet.ru/~goga/tapl/tapl.pdf

Если ты намного умнее авторов книги, тогда ладно, можешь не читать

Ограничения - это же хорошо.

Ага, свобода - это рабство)) В яве не принято так писать, в руби не принято без этого обходиться. Если ты хочешь заменить генерируемый (в каком-то случае) объект, то самый прямой и интуитивно понятный путь - переопределить метод, который этот объект создает. В яве же, ты сделаешь то же самое, но с помощью паттернов. Больша́я часть системы, при этом (а возможно бо́льшая), будет исключительно структурная. Она будет разрастаться и чем далее, тем становится все более непредсказуемой. В конце, сделать изменение в работе функционального модуля будет слишком сложно. Это система будет далеко не самодокументирована - будет миллион соглашений касаемо паттернов, она будет не производительна, и я спрошу тогда, в чем смысл?

в руби не принято без этого обходиться

а вот тот самый первый нагугленным ман говорит что лучше без этого

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

ау, инкапсуляция, наследование и полиморфизм, придите к этому человеку! Ты же переопределить его метопрограммированием собрался, а не наследованием, я правильно понял?

В конце сделать изменение в работе функционального модуля будет слишком сложно.

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

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

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

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

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

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

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

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

Ты же переопределить его метопрограммированием собрался, а не наследованием, я правильно понял?

Кстати я не знаю как это сделать в яве «без костылей». Ситуация простая, библиотека приносит новый прокси класс и переопределяет в опр. месте генерацию объекта прокси класса.

чем у костылей на руби

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

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

О, специальная олимпиада производительности.. ассемблер!</win>

Как бы это парадоксально не звучало, но ассемблеру до C++ в плане производительности - далеко ;) Есть много задач, которые в теории можно конечно сделать на асме быстрее, но в итоге это потребует набирать ассемблерную портянку на многие сотни тысяч строк кода, когда C++ компилятор сгенерирует это все из всего пары тысяч плюсовых сорцов на шаблонах.

А я разве говорил о C? Я про C++, и это две большие разницы.

Ситуация простая, библиотека приносит новый прокси класс и переопределяет в опр. месте генерацию объекта прокси класса.

В действительности, я бы для этого конфигурировал синглтон. И переопределять методы часто нет необходимости, ведь в руби есть лямбды и блоки, но ведь в яве и этого нет!

я имел ввиду с++

наследование

слабый инструмент

инкапсуляция

не расширяет функционал

полиморфизм

это скорее идеология))

http://habrahabr.ru/post/86882/ Хорошая статья про руби-блоки.

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

А JavaFX - вполне себе айс.

Лет за индусы смогли перевести его из разряда «совсем ненужно» в просто «ненужно».

А говорят что оно даже вполне на Nexus 7 работает