Дополнительный вопрос. Почему не любят java?)

Не учи Python, ему не долго осталось. Язык умирает. Все уже переходят на golang.

А разве python - это не фортран нашего времени?

За что не любят дерьмо? Аргументы!

ТС, ты почему на завтрак, обед и ужин не ешь навоз?

А кто - нибудь может конкретней аргументировать?

Зачем тебе аргументы от наркоманов? Язык как язык.

много говносайтов

Это проблема не языка.

низкий порог вхождения

Приводить подобное в качестве аргумента «почему язык плохой» — это вообще смешно. С такими вообще лучше никогда не разговаривать, а то они и это делать жопой будут, потому что ртом — слишком просто.

Конкретно про $ — для поклонников тех языков, где переменные вообще никак не выделяются, ставить перед ними значок непривычно, баттхёрт. Относительно перла, откуда PHP и пошёл — там $scalar, @array и %hash, что хотя бы логично. Но так сложилось и хрен бы с ним, тупые холивары типа кэмелкейс vs. снейккейс.
Остальные аргументы можно свести к двум: а) «этот язык не похож на $мойлюбимыйязык, поэтому говно» и б) «я видел древний говнокод на древнем PHP, поэтому PHP говно».
Короче, нормально всё с языком, ещё заколебутся закапывать. Работает, развивается, живёт.
Про достоинства питона не могу рассказать, не пользуюсь.

интересует только сфера веба

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

Не любят похапе только те, кто _вынужден_ с ним работать. Все остальные к нему равнодушны, проходят мимо (иногда сочувственно поглядывая).

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

На нём очень удобно делать костыли, чем все с удовольствием пользуются.

Вот на лурке статья есть: http://lurkmore.to/PHP

Экосистема php ущербна. Например нормальной пакетной системы не было, а composer еще не допилен

Идея парсить и выполнять php код заново при каждом запросе не лучшая идея

Шаблонизатор php это треш

Сам же язык был бы нормален если б не тянул мусор с прошлых версий в виде мультибайтовых функций со строками

https://habrahabr.ru/post/142140/ - вот тут все аргументы против PHP.

Классика: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ — немного устарело, но в целом правда.

Также интересно насчет Python, за что его так любят

За то, что приучает писать код согласно Code-Style, т.е. написать на нем чудо, которое другому человеку или тебе спустя месяц будет трудночитабельным не так то просто, это тебе не C++ и не Perl. А на PHP говнокод писать несколько проще.

У них разная ниша.

php - язык не общего назначения.

См. недавнюю *уязвимость* от FSF, когда оказались доступны бэкапы: php единственный язык с моделью *что вижу, то и пою*

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

А в остальном - никакой разницы с другими языками.

Также интересно насчет Python, за что его так любят(интересует только сфера веба)?

Кто любит? Кто пользуется, тот пользуется. А кто не пользуется, тот истерит *бейсик*, *скобычки*, *зачемдвеветки* и т.д. и т.п.

для меня основная проблема php - читаемость. то что, в php выглядит как f4(f3(f2(f1($a)))), в ruby (а иногда и в python) выглядит как a.f1.f2.f3.f4

php умирает лет 15, и всё никак не умрёт. и, скорее всего, проживёт еще столько же

Идея парсить и выполнять php код заново при каждом запросе не лучшая идея

XCache, APC, OPCache. Последний доступен прямо из коробки

Шаблонизатор php это треш

вроде тоже самое, что и erb или jsp

оба - общего назначения, и всё что можно сделать на питоне, можно сделать и на go.

не так быстро (в плане скорости разработки), не так читаемо (привет С-style), но можно. И полученный результат не будет жесточайше сливать тому же PHP по производительности.

сервер забыл handler и думает, что *.php - plain text. и как я понимаю, речь про апач.

расскажи же нам что тебя спасёт, если сервер будет думать, что *.py - тоже plain text

расскажи же нам что тебя спасёт, если сервер будет думать, что *.py - тоже plain text

сервер вообще не знает, что такое .py, ему хидеры даёт сервер приложений. так работают все, кроме php, только в php сервер разбирает на исполнение файлы, которые могут быть набросаны там и сям: например, разрешил юзер аплоад файлов, и директория /upload/ в зоне видимости сервера - ты заливаешь php файл, и сервер его исполняет. нигде ещё я такого не видел, даже в cgi-bin правила исполнения горазо суровее :)

сервер вообще не знает, что такое .py

но знает, что такое .php? серьёзно? для тебя «сервер» - это LAMP в собранном виде?

ты заливаешь php файл, и сервер его исполняет

надо ли говорить, что одной строкой в .htaccess можно отключить исполнение файлов не проходящих критерий?

надо ли говорить, что вообще-то обычно составляют white-list разрешённых типов файлов для загрузки, куда входит только мультимедиа?

ощем, RTFM

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

но знает, что такое .php? серьёзно?

да, потому что это реальный пример использования

надо ли говорить, что одной строкой в .htaccess можно отключить исполнение файлов не проходящих критерий?

.htaccess может тоже не обрабатываться. по причине от смены сервера, до неподхватившегося конфига

надо ли говорить, что вообще-то обычно составляют white-list разрешённых типов файлов, куда входит только мультимедиа?

причём здесь это? речь о том, что ошибиться (тем более, через несколько лет) в таком деле вполне реально (что и показывает проблема с FSF), а в других средах - даже теоретически невозможно

причём здесь white-list? вася сделал себе сервер, а петя через 5 лет сделал заливку по ftp, где каталог обрабатывается васиным сервером. и всё, заливай-не-хочу. :) речь не об идеальных условиях в вакууме а о том, как можно допустить серьёзную ошибку, даже не подозревая об этом

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

Apache-проблема, при чём тут PHP?

да, потому что это реальный пример использования

какой-то странный пример. расскажи нам подробнее, нам и правда интересно

.htaccess может тоже не обрабатываться. по причине от смены сервера, до неподхватившегося конфига

плохо себе представляю такую ситуацию, но если у тебя не работает htaccess или не подхватился конфиг - .py будет вываливаться текстом или выполняться где попало

петя через 5 лет сделал заливку по ftp

опять-таки очень странный и надуманный use-case, но ок.

ты не поверишь, но у FTP-серверов (как минимум vsftpd) тоже есть white-list для upload'a

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

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

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

У тебя каша в голове. Какой нафиг PHP, когда он у тебя не подхватился? Исходники тебе не PHP покажет, а веб-сервер.

Почему не любят java?

Очень многословная. Слишком много писать. Отсюда и неудобно читать и неудобно писать.

Все уже переходят на golang.

Два чая этому господину.

.py будет вываливаться текстом или выполняться где попало

не будет :)

У тебя каша в голове. Какой нафиг PHP, когда он у тебя не подхватился? Исходники тебе не PHP покажет, а веб-сервер.

для ещё раз - модель *что вижу, то и пою* применяется только в php

Фанатики, насколько я знаю ни на каком другом яп нельзя за такое короткое время развернуть цельный онлайн магазин (см. функционал битрикса). Обычно после этого фанатики начинаю говорить что медленно и т.д. и он не выдержит нагрузку в #@улеард пользователей в секунду, что собственно вообще не требуется т.к. в большинстве случаев она не большая.

Яп это ведь только инструмент и говорить что пхп плохой, это тоже самое что шуруповёрт хуже перфоратора.

пхп уже давно живёт и очень хорошо развивается.

.py будет вываливаться текстом или выполняться где попало

не будет :)

https://test.valkeru.ru/
Кукарекай дальше, болезный.

ты вообще сам понял, что сделал? ты просто выложил исходник .py файла. но его не выкладывают, его ЗАПУСКАЮТ. все python-приложения так работают.

php приложения же, наоборот, все выполняются *на месте*, их сваливаешь на веб-сервер и тот их исполняет.

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

За что не любят PHP? Аргументы

собственно, за это php и не любят :)

если бы я написал, что php начинается с буквы p, мне бы начали доказывать, что это не так :) я вообще не понимаю, о чём они спорят и зачем, но людям главное поспорить :)

ты вообще сам понял, что сделал?

Да, я не запустил сервер приложений. Нет исполнителя — тебе выдаётся исходник. Ровно та же самая ситуация с отвалившимся mod-php, о чём ты кукарекал выше по треду. Только у тебя почему-то в отсутствии интерпретатора виноват неподхватывающийся сервером интерпретатор, а не сервер. Я же говорю, в голове у тебя каша.

их сваливаешь на веб-сервер и тот их исполняет

Ух ты, прямо как какой-нибудь сервер приложений!

С ним бессмысленно спорить, у него всё «сваливается в папку на сервере», а дальше происходит магия. Сервер «не подцепит обработчик php», но из последних сил, неведомым образом, «php покажет исходники».

В питоновебе (и вообще в любом не-php вебе) если нет исполнителя — тебе не выдаётся НИЧЕГО потому, что сервер не имеет понятия, где питонофайлы вообще находятся (и не имеет туда доступ, как правило). Только в пхп-средах в уйме дефолтных сетапов код находится там же, где и статика + медиа-файлы.

в результате неудачного обновления оно не подцепит обработчик php (я такое наблюдал лично)

вася сделал себе сервер, а петя через 5 лет сделал заливку по ftp

что это вообще за детский сад

php покажет исходники

исходники могут и чаще всего должны лежать на жидхабе

Да, я не запустил сервер приложений. Нет исполнителя — тебе выдаётся исходник. Ровно та же самая ситуация с отвалившимся mod-php, о чём ты кукарекал выше по треду.

всё понятно

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

что это вообще за детский сад

читайте главную страницу, там написано :)

Только в пхп-средах в уйме дефолтных сетапов код находится там же

это случалось потому что на шаред хостингах давали только доступ к публичному каталогу. Если использовал эти настройки то ССЗБ. всегда есть возможность настроить нормально и вынести сорцы выше рута апача

Еще один

Это не «пхп-среда», это апач-среда. Если у тебя не завёлся handler, apache будет показывать все файлы в document root. В том числе питонячьи

Если у тебя nginx+php-fpm и php-fpm сдох, то ты тоже ничего не увидишь

Никто не может, расслабься.

модель *как в php*

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

в openbsd, скажем, нельзя даже теоретически всем основным серверам что-то за пределами /var/www

при этом, четыре проверенных мною пакета, nextcloud, owncloud, piwik, dokuwiki - все ставятся в /var/www, для всех идёт инструкция для нескольких серверов, которая в итоге даёт ровно такой же результат.

при этом для python-приложений, которые тут есть, будь то trac или django, я вообще не могу сказать, из какой директории оно запускается - такое понятие тут просто неприменимо. но все основные данные и модули лежат, понятное дело, в /usr/local/lib и /usr/local/share

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

что значит *виноват* и причём здесь *виноват*? php использует такую модель, а все остальные - другую. это медицинский факт. возьмите любой тарбол или любой пакет с php-приложением и прочитайте его README, там будет буржуйским-по-чёрному написано именно это.

для самых маленьких

его ЗАПУСКАЮТ

кто его запускает? что происходит, когда

.htaccess может тоже не обрабатываться. по причине от смены сервера, до неподхватившегося конфига

php как Ленин, если вы понимаете о чём я:) Не верьте слухам. Он ещё долго будет на коне. Слишком много всего на нём понаписано. И левые сайты пилят в основном на CMS написанных на php. Но у новичков, осваивающих скриптовые ЯП он уже не так популярен как раньше, поэтому его популярность будет снижаться - тут ничего не поделаешь.

третейский_судь_мод_оно_самое:

утверждение же сиё таково: в php-культуре «так принято»(или в лучшем случае было а уже нет принято) что если сервер не обработает сервер-сайд то конченый клиент-хакир увидет глубины мамкиного-рhp-магазина и именна - а в клиническом случае и явки пароли к базам. в «других» языках/серверах увидет ошибку сервера.

утверждение же оппа таково: если вышелушит конкретные знания об серверах и прочих апачах и останется тока скелет спора то - и php и любой другой(веб) язык эквиваленты поэтому «нет разницы и не парь меня буратино»

так поня?