срач java vs php из теории

[fixxxer]

Krishna
Кстати, Scala и Groovy решают почти все перечисленные тобой недостатки джавы

 

[Krishna]

fixxxer
Я в одной конторе немного поработал с Grails 2.0.0M3 и, соответственно, Groovy 1.8
В начале мне тоже показалось, что вот он, идеал, золотая середина.

Но, потом, в ходе очень энергичной работы (начальник все соки выжимал по срокам) я за 1.5 месяца наткнулся аж на несколько багов, каждый из которых убил у меня заметное время. Конечно, скорее всего это были баги именно Grails, нокак минимум 1 грувовский. Мне кажется, это уж слишком критичная концентрация.
Кроме того, мне как-то сильно не понравилась сама концепция closures, мне она показалась отличным способом выстрелить себе в ногу в плане создания нечитаемого Perl-style говнокода. Для pure Java, есть кстати интересная попытка улучшения работы с коллекциями - Guava (оно же Google Commons).

Про scala не знаю, но в целом, у меня сложился большой скепсис к скриптовым языкам на JVM.

 

[fixxxer]

scala (в отличие от groovy) совершенно не скриптовая, динамика там достигается засчет вывода типов, примерно как auto в c++11, только замороченнее

 

[Krishna]

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

То есть, подход, ставящий функции во главу угла мне кажется менее подходящим, чем ООП.
Хотя, писать не пробовал, повторюсь. Но что-то мне сдаётся, что я прав.

То есть, даже если какие-то минусы явы, из мною перечисленных в скале, устранены, то вряд ли это повод переходить на неподходящую парадигму?

 

[Gas]

эта тема выделена из http://phpclub.ru/talk/threads/Нагруженные-приложения.74997/
сравнивать php и java без конкретной задачи, смысла наверное мало, разные весовые категории.

 

[keltanas]

Модератор, видимо что-то попутав, решил новую тему назвать не верно. Ибо началось все с другого вопроса, который он сам же и выделил, т.е.:

скриптовые языки vs java

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

Кстати, grigori, не ты ли тут облажался, а потом троллил остальных участников конференции? Очень напоминает твой стиль.

 

[grigori]

> в месяц мы тратим на железо и хостинг 1 гбит/с - около $20 000 (всего). За год выходит $240 000. Умножить на 3 - $720 000. Экономия 10% - $72 000 в год. 72 штуки едва на 2 годовых зарплаты программеров хватит. Где-то ошибка в расчетах? .-)

1. при создании собственной качественной инфраструктуры 1000 серверов * $5000 за сервер * 10% = $500 000 инвестиций в железо
следовательно,
2. Аренда ДЦ на 100 серверов и обслуживание
+ транспорт и сбои

да, таких проектов мало, в рунете - вообще единицы, но вопрос же теоретический

Резюмируя:

Java хороша для бизнес-приложений, работы с финансами, тяжелых вычислений.
PHP хорош для быстрой и безгеморойной разработки сайтов с богатыми веб-интерфейсами, но без тяжелой логики.

вопрос: что делать с сайтами с богатым веб-интерфейсом и тяжелой логикой, как в играх?

 

[grigori]

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

 

[Krishna]

вопрос: что делать с сайтами с богатым веб-интерфейсом и тяжелой логикой, как в играх?

Java + PHP вполне вариант, имхо. Ну это надо смотреть уже конкретно. Я думаю, тут не в последнюю очередь будут влиять доступные кадры, например. И размер проекта, разумеется. Да мало ли ещё что.

 

[Adelf]

Ну по мне, Такие языки как Java и С# просто гораздо приятнее для разработки. Они статические. Они гораздо проще анализируются различными тулзами. Автоматические рефакторинги(IDEA или VS+Resharper - вообще делают процесс разработки мегаприятным). А в PHP до сих пор никак не введут нормальный способ отметить, что этот массив содержит элементы такого-то класса. Так что если сравнивать только языки - ответ очевиден.

Но под веб я пишу все равно на PHP. Все гораздо проще. Проще развертывается. Более гибок. Куча готового. Да и банально не участвовал в проектах, где бутылочным горлышком были операции языка(как и 99% веб-разработчиков).

 

[keltanas]

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

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

 

[keltanas]

вопрос: что делать с сайтами с богатым веб-интерфейсом и тяжелой логикой, как в играх?

А как на счет BigWorld?

The developer can customize all aspects of a world by adding new tools and low-level behaviors without modifying the server code. BigWorld game objects are written in Python, a standard object-oriented scripting language that has demonstrated threefold improvement to programmer productivity. Scripts can utilize C++ when required for optimization of regularly used functions. The BigWorld Server also allows cross-platform functionality allowing PC and next-gen console users to interact within the same world space.

 

[keltanas]

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

Ну в целом PhpStorm вполне себе не плохо анализирует php-код, хотя случается и не как хотелось бы. Например, если в индекс попадет файл кэша с классами (как yiilite или bootstrap.php.cache в symfony), то могут быть проблемы с подсказками.
А в целом PhpStorm (как наследник IDEA) поддерживает рефакторинг, сборку (через phing), отладку (через xdebug или zend debug), запуск тестов в отладчике с расчетом покрытия (PHPUnit + xdebug).

Чтобы решить проблему, объектов в массиве, к примеру здесь предлагают использовать классы тира Collection, представляющий список объектов определенного типа. Т.о. на каждый вид объектов надо делать новый вид Collection, что не всегда удобно, конечно (особенно если приложение не большое), но является выходом из ситуации. В той же книге предлагается не инициализировать объекты в коллекции до того момента, пока они не понадобятся, а до этого хранить в коллекции "сырые" данные в виде массива, которые необходимы для инициализации объектов (и за счет такого lazyload экономить память).

 

[AmdY]

keltanas
чтобы не было проблем из-за кеша, нужно эксклудить директории из проекта. делается это в два клика.
другое дело что из-за повсеместного DI теперь иде не понимает что делать и задалбёшься с автокомплитом, пока не поделают нормальные плагины для фреймворков. типа как для ROR.

 

[AmdY]

По поводу срача - детский сад, силиконовые тесты не говорят ровным счётом ниочём. У меня есть опыт переписывание с увеличением функционала 3-х проектов на java и 1 на питоне, проекты обычные вебморды для бизнес тулз, формочки, списки. фильтры, во всех скорость увеличилась. Я понимаю кривые руки, толстые фреймворки, старые версии, но это хотя бы не силиконовые тесты или hello world. Другое дело, когда консольная тулза с поиском лиц на питоне работает в тысячи раз менее функционального скрипта на php, здесь особо думать не стоит что применять. Тем более нормальный программист способен как минимум заточить под себя готовое решение на другом языке, даже без знание оного. Сейчас время мультиязычных решений, а не холиваров о серебрянной пуле.

 

[keltanas]

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

Я так и делаю. Но согласись, что IDE, которая официально поддерживает Yii и Symfony, могла бы сама понимать, что ей нужно анализировать, а что нет.

keltanasдругое дело что из-за повсеместного DI теперь иде не понимает что делать и задалбёшься с автокомплитом, пока не поделают нормальные плагины для фреймворков. типа как для ROR.

Сейчас приходится делать подобным образом:

use Acme\SomeBundle\Repository\FooRepository;

/** @var $fooRepository FooRepository */
$fooRepository = $this->getDoctrine()->getRepository('AcmeSomeBundle:Foo');

Что в целом устраивает, хотя может и показаться по началу муторным. Хотя в яп со статической типизацией тоже приходится прописывать тип переменной, только явно, а не в качестве аннотации для IDE.
Но согласен, что и этот момент IDE могла как-то отслеживать, хотя бы для тех фреймворков, которые она официально поддерживает

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

 

[WMix]

силиконовые тесты не говорят ровным счётом ниочём.

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

смысл этих тестов == ява быстрее, кушает меньше памяти, но занимает больше места...

 

[fixxxer]

Krishna
scala не навязывает функциональную парадигму. Можно писать ООП код и юзать ФП только для сахарка (в тех случаях, когда в java придется делать анонимный класс с одном методом)

 

[Absinthe]

- В нестрогой динамической типизации (когда нужно быстро разобрать пользовательский HTTP-ввод, без лишних телодвижений).

Это не плюс, а особенность. Лично для меня это большой минус.

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

ArrayList<NameValuePair>?

- Возможность мешать код с выдачей.

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

Еще плюсом PHP являются зачатки ФП. Если богомерзкий use выпилят - то можно говорить уже о поддержке ФП.

 

[Krishna]

Это не плюс, а особенность. Лично для меня это большой минус.

Ну, если не заметил я каждую типизацию включил в плюсы, т.к. в каких-то (в частности указанных) случаях она плюс, в каких-то минус.

ArrayList<NameValuePair>?

Тогда уж HashMap<String, Object>, но в нём не получится хранить переменные разного типа (если только заранее не знаем что там будет и не будем кастить), как раз таки из-за отсутствия динамической типизации, которая в PHP в данном как раз таки случае во благо

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

Опять же зависит с какой позиции смотреть.