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

[keltanas]

скриптовые языки не лучший выбор.

А чем java лучше?

 

[Gas]

тролишь?
jit (performance), multithreading, больше квалифицированных разработчиков

 

[keltanas]

тролишь?
jit (performance), multithreading, больше квалифицированных разработчиков

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

В php есть APC. Обрабатывать данные асинхронно в несколько потоков тоже никто не мешает. Если у джавы даже будет выигрыш по скорости, то не значительный, в чем я сомневаюсь.
А если пойдем дальше, и посмотрим в сторону python, erlang, node.js etc, то тут java точно не конкурент. Т.к. скорость разработки точно компенсирует затраты на лишний сервер (опять же, если у java все так шоколадно, как вы говорите - сам с ней не работал, тестов не проводил; обычно она как раз славится своей прожорливостью).

Ах да. Для nginx есть модуль, читающий информацию напрямую из redis. Так что кроны в сколько хотите потоков могут готовить ее, а клиент забирать.

 

[WMix]

http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=java&lang2=php

 

[keltanas]

http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=java&lang2=php

Извините за троллинг, но там PHP 3 использовали видимо?

 

[Gas]

но там PHP 3 использовали видимо?

http://benchmarksgame.alioth.debian.org/u32/program.php?test=binarytrees&lang=php&id=1
>PHP 5.4.11 (cli) (built: Jan 27 2013 11:58:31)

Понимаешь, твои представления о работе программ в целом, слишком упрощены.
Модель работы php (получить запрос, проверить не поменялись ли файлы проекта, загрузить/перегенерить опкод приложения, загрузить состояние из persistent storage, потом наконец выполнить полезные действия и умереть, чтоб следующий запрос начал всё с начала) не является оптимальной.
Да это работает и во многих случаях скорости хватает. Но есть и другие способы работы программ - когда они запущенны и работают постоянно, в случае запроса от клиента им не нужно заново инициализировать себя, поднимать состояние из внешних источников, они сразу же могут выполнить полезное действие и вернуть результат.

p.s. про php, конечно, я однобоко написал, его тоже можно запустить в виде демона, организовать сокет-сервер, всё держать в памяти, но от этого сферическая задача на нём не станет быстрее работать чем на сферическом компилируемом языке.

 

[keltanas]

http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=binarytrees&lang=hipe
Тут идет проигрыш джаве по процессору, зато выигрыш по памяти.

А здесь идет выигрышь над джавой по всем статьям http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=binarytrees&lang=gcc

ИМХО, эрланг выучить проще, чем джаву. Код на нем пишется быстрее. Сам код понятнее, выразительнее. Поэтому не считаю, что джава - это самоцель.
Хотя доводы, конечно, весомые.

 

[WMix]

keltanas
за чтож ты так ненавидишь яву?... я понимаю ненависть к апплетам или к флэшу,.. но сама идея явы очень даже хороша!... и изучается ява с лету, нужно понимать что такое ооп и как читать явадок...

 

[keltanas]

keltanas
за чтож ты так ненавидишь яву?... я понимаю ненависть к апплетам или к флэшу,.. но сама идея явы очень даже хороша!... и изучается ява с лету, нужно понимать что такое ооп и как читать явадок...

Да я уважаю ее. Даже, начитавшись Фаулера, порывался ее учить.
Но со временем стал больше склонятся к pythonic way стилю.

 

[grigori]

"скорость разработки точно компенсирует затраты" - особенно хорошо опровергает *****, активно переписывая код с php на c,
и facebook, разрабатывая для своего php-кода сначала hiphop, а теперь и виртуальную машину a-la java

"тестов не проводил; обычно она как раз славится" - числа в студию, пустозвон ты наш

 

[keltanas]

числа в студию, пустозвон ты наш

Ты же сам общаешься одними тезисами, и кого-то еще пустозвоном называешь.
Про какую такую виртуальную машину фэйсбука вообще речь?
И может предложишь теперь вообще забить на все яп кроме C и писать сайты на нем? Или вообще не асме. Что нам кабанам?

grigori
Твой комментарий выше мутирует с каждой минутой.

 

[grigori]

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

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

 

[keltanas]

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

 

[grigori]

может, и я не проверял
>Ссылки никак не объясняют твой точки зрения
моя точка зрения: я инженер, мы занимаемся техникой, точными науками, следовательно, аргументы должны следовать научному методу, и быть объективны, иначе это пустой звон

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

для сохранения объективности и профессионализма на этом форуме твои сообщения надо или опровергнуть, что я и сделал, или удалить

 

[keltanas]

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

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

а значит, твои сообщения можно удалить без ущерба для кого-либо

Можешь удалять. Главное, что я получил ответы на свои вопросы и опровержение некоторым заблуждениям от толковых людей. Считаю, что это было для меня полезно. Думаю, что форумы для этого и существуют.
На сколько это полезно для разных троллей, мне без разницы.

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

И кстати этот срач начал не я.

 

[grigori]

я оспариваю не вопросы, а ложные безосновательные утверждения

продолжая троллинг, уточню, что

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

увеличение производительности на 10% на 1000 серверов дает экономию до $1 000 000 инвестиций в железо, датацентры и обслуживание, можно и заняться

Обрабатывать данные в несколько потоков тоже никто не мешает.

у PHP нет поддержки многопоточности. Вообще.

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

В первую очередь речь идет о потреблении памяти. В Java массив int занимает порядка 4 байт на элемент, а не 50, как в php.
Скорость вычислений различается не так сильно, но в разы.

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

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

 

[DiMA]

> увеличение производительности на 10% на 1000 серверов дает экономию до $1 000 000 инвестиций в железо, датацентры и обслуживание, можно и заняться

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

 

[Absinthe]

А чем java лучше?

Целостностью и логичностью библиотек.

 

[fixxxer]

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

У меня еще много медалей специальной олимпиады, хватит на всех =)

И, кстати, Дима прав, без профита хотя бы процентов в 40-50 производительности - вообще нефиг метаться, железок доставить дешевле

 

[Krishna]

А чем java лучше?

Я, смотрю, сегодня тема популярная
Давайте я вам расскажу, по мере сил, как чувак кодивший на том и на том

Как нетрудно догадаться, вопрос нужна правильно формулировать так "А для чего Java лучше?". И, аналогично, "для чего лучше PHP?".

В принципе, преимущества PHP сложнее объяснить на словах, так как они менее очевидны, и тем не менее значительны в своей области.

PHP рулит для быстрого создания веб-приложений малой и средней сложности.

Преимущества PHP:

- В отстутствии явной компиляции (на яве она отнимает значительное время отладки)

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

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

- В мощной стандартной библиотеке языка, реализованной на Си. В яве, чтобы например получить строку MD5 от другой строки, приходится вставлять с десяток строк кода.
Функции реализованные на Си сами по себе обладают высокой производительностью, сопоставимой с Java. Кроме того, в отличие от различных фреймворков, расширяющими возможности стандартных либ, которыми приходится пользоваться в Java, эти функции известны всем PHP-программистам, а это повышает читабельность кода проекта.

- Возможность мешать код с выдачей. В яве для этого нужно юзать сервлет-контейнер с поддержкой JSP.

- Банально поддержка multiline strings (строк с переносом строк ) В яве приходится делать так, что бесит:

String x = "bla-" +
+ "bla";

- Высокая интегрированность с HTTP. В Java, к примеру, невозможно передать тот же ассоциативный массив как параметр POST. Так же, невозможно передать двойной (тройной) вложенный массив ($_POST['arr_A']['arr_B'])) Для этого нужно как минимум пользовать один из веб-фреймворков. Каждый из которых делает это по-разному.

Возможно, я что-то упустил и вспомню позже.

Преимущества Java:

- Строгая типизация. Если мы считаем, например денежные суммы (как правило целочисленно, в копейках), то мы не должны внезапно для себя получать дробный результат. Для приложений с глубоким стеком вызова (когда сложные алгоритмы для одного, например, HTTP-запроса, когда в значительном вызывают различные методы, один вызывает другой и так далее), нестрогая типизация резко повышает вероятность того, что false полученный в результате ошибки будет воспринят как 0, или там где будет ожидаться для сравнения 1 мы получим 0.9999999... , которое не пройдет проверку на равенство. Это вызывает необходимость регулярной ручной проверки типа, что не страхует от ошибок невнимательности.

- Java требует в разы (даже на порядок) меньше памяти, чем PHP для хранения сложных объектных структур. В PHP на 64ех-битной платформе, по моим замерам, простое присвоение $x = 0; жрёт порядка 136 байт (!!). При этом память явно выделяется с запасом, т.к. присвоение $y = "test string" сожрёт дополнительно ещё тех же 136 байт.
В Java 1 ссылка на объект ест 16 байт, а примитивные типы столько, сколько нужно минимально для хранения информации, например integer - 4 байта, long - 8 байт.
Соответственно, создать в Java 100.000 объектов много дешевле, чем в PHP.

- Многопоточность. В Java другая модель взаимодействия с HTTP. Если PHP работает через вариции CGI или являясь модулем Cи-шного вебсервера, то веб-приложения на Java являются модулем веб-серверов (так называемых сервлет-контейнеров) на Java же. (Tomcat, Jetty, Glassfish и иже с ними). В Java для обработки запроса создаются так назваемые сервлеты - объекты классов специального формата, которые инициируются веб-сервером (точнее сервлет-контейнером) и далее для обработки каждого отдельного HTTP-запроса создается лишь отдельный поток, вызывающий метод этого сервлета. Поток это thread, не отдельный процесс, как в PHP, а возможность запускать параллельную выполнение методов в рамках одного процесса.
На практике это означает, что мы можем один раз инициализировать какую-нибудь тяжелую структуру, навроде огромного массива или объектного графа, а потом получать к нему доступ при каждом новом HTTP-запросе, без необходимости каждый раз проводить его инициализацию. Правда, такой подход приводит к проблемам горизонтального масштабирования (на разные машины).

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

- Кроссплатформенность. Java более кроссплатформенна, чем PHP, как ни странно. Например, размер int здесь не зависит от платформы.

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

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


Резюмируя:

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