Comments 263
Потому, что в php перед каждой переменной надо ставить знак доллара ))
В Perl, это нечто большее, чем просто обозначение переменной, — это обозначение скалярной переменной и часть системы типизации. На ряду с $, переменная может содержать впереди себя @ или % что означает соответственно список (массив) и хеш (ассоцированный массив). Что в частности позволяет например писать $h{@a} = @b — что означает: присвоение ключам ассоциированного массива %h списка значений заданных массивом @b причем список имён ключей соответственно задан масивом @a. И т.п.
в руби тоже вот таким путем пошли.
по своему неплохой подход — сразу видно с чем работаешь.
хотя уже когда, например, ссылка на массив — просто по имени непонятно.
к сожалению, пока нет вменяемого варианта однозначно указывать хотябы общий тип в имени спецсимволами.
в лучшем случае трешак в духе лямбд в плюсах или сложных типов в раст
мечта — красивый и краткий способ записывать ещё и генерики :)
Не единственная и уж точно не главная. Но зато самая бросающаяся в глаза. Знак доллара перед переменными не даёт никаких преимуществ, зато мешает довольно сильно.
Во-вторых, она мешает только тем, кто не пишет на PHP (или пишет редко)
Тем, кто не пишет на php, необходимость ставить доллар перед переменными в php не мешает )). А вот тем, кто пишет — логичным образом мешает.
В-третьих, придираться к синтаксису языка — это последнее, к чему в принципе стоит придираться, и стоит ли вообще?
Если синтаксис языка требует ставить один и тот же симво перед каждой переменной и это не даёт никаких плюсов, то безусловно стоит.
Аналогично можно придираться к тому, что после Питона забываешь про точки с запятыми в других языках.
Необходимость ставить доллары перед переменными мешает, когда пишешь код на php, поэтому ваша аналогия тут не применима.
после введения AST можно. но, как минимум из-за обратной совместимости такое изменение делать нецелесообразно.
Можно просто метить файлы, в которых переменные без доллара. Чем-нибудь в первой строчке. А остальное парсить как раньше.
Остальные аргументы об это убиваются. Если основной язык — другой, и периодически приходится переключаться, то безусловно это вносит неудобства, именно поэтому я и привел в пример Python с его «точкой с запятой». Лично для меня было бы удобно не использовать точку с запятой, если бы я использовал этот язык в качестве основного, НО как только я переключусь на любой Си-подобный, мне это будет доставлять дискомфорт.
Но речь о другом.
В дискуссиях ниже, Вы сами же объяснили, почему $ появился в этом языке, а теперь представьте, что разработчики языка, на котором Вы пишете несколько лет, взяли и поменяли синтаксис.
Тут речь даже не об удобстве разработчиков, которые используют этот язык, а скорее о труде разработчиков, которые разрабатывали ПО для поддержки этого языка или даже тех, кто писал статьи-книги про этот язык.
поменяли синтаксис
если удастся сделать так что бы небыло коллизий с константами — то не вижу проблемы. Отказ от $ в названии переменной не будет вызывать большого нарушения обратной совместимости.
Но это уже что-то вроде "традиции". Никто уже это не будет фиксить. Да и нужды нет.
И как Вы правильно заметили «нужды нет», потому что на самом деле — это самые последние из «проблем», которые есть у PHP, а те коллеги, которые цепляются именно к $ просто не могут объяснить реальные проблемы, которые есть у языка (а они безусловно есть, как и у любого другого).
**Update**
речь не только про обратную совместимость языка. Представьте, что команде JetBrains нужно будет переделывать PhpStorm, убирая оттуда подвязки к $, к поиску по этому символу (который, как отметили в последних комментариях может сокращать список возможных значений при автозаполнении), и так далее для остальных IDE, гайдов, книг и т.д.
Новичок в 2020 году покупает книги, читает статьи по языку, который не имеет $ в синтаксисе, хотя везде говорится об обратном.
те коллеги, которые цепляются именно к $ просто не могут объяснить реальные проблемы, которые есть у языка
Видите, какое дело. То, что проблему никто не собирается исправлять, потому что к ней все привыкли — не делает её не существующей. И тот факт, что она существует, но нередко её существование не признают, или вообще называют проблему фичей, меня изрядно удивляет.
Не мешает этот знак доллара, когда ты пишешь на PHP достаточное время.
Ко всему со временем привыкаешь, это известный феномен. Вот, например, Робу Пайку не мешает отсутствие подсветки синтаксиса, и он не один такой.
Остальные аргументы об это убиваются.
Как об это убивается аргумент, что необходимости ставить доллар перед переменной объективно нет? Что это не несёт никаких плюсов и только увеличивает вероятность поймать туннельный синдром?
В дискуссиях ниже, Вы сами же объяснили, почему $ появился в этом языке, а теперь представьте, что разработчики языка, на котором Вы пишете несколько лет, взяли и поменяли синтаксис.
Если бы речь шла о том, что значок доллара больше не нужно ставить, я бы обрадовался.
Тут речь даже не об удобстве разработчиков, которые используют этот язык, а скорее о труде разработчиков, которые разрабатывали ПО для поддержки этого языка или даже тех, кто писал статьи-книги про этот язык.
К сожалению, в ваших словах есть известная доля истины. Действительно, если человек приложил усилия, чтобы побороть какое-то неудобство, а потом неудобство убирают, то нередко он чувствует себя обманутым. Но это не повод отказываться от прогрессивных изменений и развития.
$p1 = 'Привет';
$p2 = 'Пока';
$property_name = $_GET['property'];
print($$property_name);localhost?property=p1
Привет
localhost?property=p2
Пока
Попробуйте в другом языке через значение переменной обратиться к другой переменной по имени.
Попробуйте в другом языке через значение переменной обратиться к другой переменной по имени.
Возможность интересная, но для её реализации достаточно попросить пользователя поставить один доллар перед property_name, когда хочешь через неё обратиться к другой переменной.
#!/usr/bin/perl
$v = 'first';
$first = 'second';
print $$v;основы языков программирования. У вас есть динамические языки (php, js, python, etc) и статические (C++, D, Haskell).
Статические — это значит что информация о типах доступна в компайл тайме. Динамические — только в рантайме.
В вашем примере нам неизвестно значение var. Существуют языки которые могут описать это типами что позволит проверить корректность в компайлтайме
type data = {
foo: string
bar: number
}
const locals = () => data
let v: keyof data | null = null
locals()[v] // можно проверить в компайлтаймеВ теории это можно замутить на темплейтах, но зачем вообще так делать?)
В том и суть. Это сахар. PHP не заставляет задумываться что тебе нужно (массив, список, справочник или даже объект), Ты можешь изголяться как хочешь:
- Объект в массив? Легко!
- Цикл по объекту? Без проблем!
- Извлечь массив в переменные(по ключам)? Всего 1 комманда.
- Добавление свойств классу на лету.
- Конкатинация по отдельному символу для избежания затыков уровня JS.
- Полноценное ООП
Не язык, а мечта мага.
Но ещё хотелось бы увидить пару фишек, например из питона:
- именнованая передеча переменных в функцию
- удобный выбор диапазонна в массиве
- ну и кудаже без многопоточности
Исторически сложилось. Делалось для того, чтобы было удобно вставлять переменные в строки. Тогда никто не предполагал, что php станет настолько успешным и развитым языком, что доллары перед переменными на самом деле будут мешать.
Тем, что перед тем, как применить переменную в коде, нужно набрать символ, набор которого требует зажать шифт. Это особенно неприятно потому, что никакой объективной необходимости в этом нет и никаких преимуществ это не даёт.
Вводится одной рукой — не вижу неприятностей. К тому же, никто, вроде, не мешает использовать какую-нибудь раскладку, где доллар без шифта.
Вводится одной рукой — не вижу неприятностей.
Вообще не рекомендуется набирать одной рукой комбинации, которые включают в себя 2 и более символов. Но в общем и целом гораздо лучше вообще не набирать символ, в наборе которого нет совершенно никакой объективной необходимости.
не рекомендуется набирать одной рукой комбинации
А вот тут можно подробней? alt+shift тоже к этому относятся? А заглавные бувкы?
Alt+Shit двумя руками зажать не проще, чем одной из-за неудобного расположения клавиш, увы. Кроме того, как правило, нужно зажимать Alt+Shift и ещё какую-то кнопку и тут уже совсем не возможно нажать одной рукой не больше одной кнопки.
К заглавным буквам рекомендация относится без оговорок.
я чет не очень понял… зачем двумя руками если можно одной? Это как-то связано с нагрузкой на запястье? Купите себе нормальную клавиатуру может...
Я был бы против того, чтобы его убрать.
На мой взгляд, код читается лучше. Всегда понятно, где переменные, а где что-то еще.
Если писать код в блокноте, то в ваших словах есть определённая часть правды. Но сейчас код пишут в основном в IDE, там, благодаря подсветке, таких проблем нет.
Набирать, при этом, совершенно не напрягает.
Субъективно, понятно, что не напрягает, а объективно есть необходимость набирать дополнительный символ.
Ну и плюс выделение переменной даёт всякие парсинговые вещи, вроде подстановки переменной в строку.
Нет, не даёт. Безо всяких проблем можно убрать необходимость ставить доллары перед каждой переменной в коде и, если в строке встречается знак доллара и после него переменная — вставлять эту переменную в строку.
вроде подстановки переменной в строку
"Some $var" //можно
"Some other {$this->var}" //можно
"use some {constant}" // нельзявот так появляется неконсистентность языка. И это много хуже.
Похоже, после каждого «Нам нужны значки, чтобы пояснять, о чём речь!» приходит озарение «Постойте, слова и сами справляются».
Я вот не понимаю этого шума вокруг знака $. Не припомню чтобы мне когда либо мешал этот символ.
Скажу даже больше. Некоторым не хватает $ в других языках. Довольно часто встречаю случаи когда JavaScript разработчики используют $ в имени переменных (сам так не делаю). Поначалу мне думалось, что это php программисты переносят свои привычки в js, но сейчас так пишут код даже чистые фронтендеры, которые php в глаза не видели. Возможно это просто последствия.
Хотя есть свой смысл в использовании $ в контексте js. Например, в следующем примере без контекста невозможно понять, bar это переменные с некоторым значением или название функции, а foo это название функции или ссылка на функцию.
foo(bar);Следующие примеры более очевидны
foo($bar);
$foo(bar);
$foo($bar);И не подумайте. Я не поддерживаю идею использования $ в js.
Сейчас набегут хейтеры и скажут, что это недостатки самого языка и писать надо на питоне)))
aptitude show libphp7.0-embed
…
This package provides the library /usr/lib/libphp7.0.so which can be used by application developers to embed PHP scripting functionality.
The following extensions are built in: Core date filter hash libxml openssl pcntl pcre Reflection session SPL standard zlib.
PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML.
WARNING: The embed SAPI is experimental and there's no guarantee that the API/ABI will be kept compatible even between minor releases. You have been warned.
Раз, два, и т.д.
Конечно же, есть wiki.theory.org/index.php/YourLanguageSucks, но всё же видно, что у PHP недостатков очень много.
Если вам не нравится этот язык, его экосистема и инфраструктура, ну не программируйте на нём. Делать вброс вида «php sucks», имхо, не стоит. Уж хотя бы обосновали бы мнение своим личным опытом, не опытом постороннего дяди.
Я искренне желаю вам получать удовольствие от работы с тем инструментом, который вам нравится и с которым готовы прожить остаток жизни (не сарказм) :)
Реализовывал уже году в 2006. Привинчивалось к Delphi 7 ;))))
Все бы ничего, но:
1. она написана на руби
2. её хрен запустишь на своем сервере
Если бы она была написана на PHP — лично мне было бы гораздо проще разобраться, что именно не работает. А так в этом может разобраться только 1 человек — автор.
Диковатая мысль в голове — трансляция в WebAssembly. И тогда PHP начнёт просачиваться в браузеры :)
Выглядит многообещающе (и бенчмарк, и сама статья)
хотите лайфхак как быстрее запомнить?
в array_map второй аргумент на самом деле variadic. А в reduce/filter — нет.
function zip(array ...$arrays) {
return array_map(null, ...$arrays);
}
zip([1, 2, 3], ['a', 'b', 'c']); // [[1, 'a'], [2, 'b'], [3, 'c']]
Зачем вообще запоминать, если Шторм подсказывает?
И получим мы массив объектов, который нужно так же обрабатывать. Не, можно конечно запилить коллекции, но там уже внутри коллекции будет filter/map…
А еще нужно не забывать про легаси, которое нельзя вот сразу взять и сделать идеальным, вот и приходится городить… Ну и про хайлоад не стоит забывать, где оборачивание строки в объект чтобы было удобнее слишком жирно.
признак плохого дизайна кода.
мне кажется в вашей логической цепочке пропущены важные штуки. Если объекты будут использоваться вместо массивов (коллекции например) как это избавит код от map-ов и редьюсов? Что будет внутри вместо?
Словом, поясните свою мысль.
Вот только сегодня столкнулся. Парсю URL:
$parse = parse_url($url);Далее преобразовываю параметры в массив. По аналогии написал бы так:
$query = parse_str($parse['query']);А правильно вот так:
parse_str($parse['query'], $query);Всё это нужно либо помнить, либо вникать в подсказки IDE. А это хоть на пару секунд, но выбивает из потока. Писать уже не так приятно.
С другой стороны в современных PHP-проектах всё равно гораздо больше работы с библиотекой фреймворка или с новыми возможностями языка, где всё структурировано и стандартизировано, чем со стандартной библиотекой. Поэтому считаю подобное скорее досадным легаси, чем фатальным недостатком.
ps: Я бы еще добавил в стандартную комплектацию phalcon т.к. это не затратно, быстро и очень близко к тому для чего это язык применяют.
Так оно и было, пока фракция javascript не выпустила nodeJS.
PHP и Node применяются для разных задач по сути.
Раскройте свою мысль. Где, где применяют php, применить node будет ошибкой?
И то и то можно использовать где угодно, но, согласитесь, для стандартного веба по типу «запрос-ответ» PHP подходит лучше Ноды: вы не заботитесь о памяти, вы не заботитесь что что-то зависнет, у него простая схема работы (веб сервер мы не трогаем сейчас, он отделен).
За Нодой нужно следить: а не упало ли чего, а нет ли у нас где утечек памяти и т.п. Конечно есть свои плюсы и минусы и именно поэтому это разные инструменты.
Если я вам отвечу, вы начнете спорить о том, что считать «ошибкой».
Я не хочу с вами поспорить, я хочу понять вашу точку зрения. Однако, хочу отметить, что для того, чтобы констатировать, что php и node сейчас не конкуренты, с вами должно согласиться подавляющее большинство программистов. Иначе эти программисты будут применять эти инструменты для решения одних и тех же задач.
С другой стороны, PHP уже проспали микросервисы (да и обработку Websockets без геморроя на PHP не сделать), возможно через какое-то время проспят ещё какой-нибудь юзеркейс.
А по поводу того как лучше писать,
if (number in [1,2,3]) или if (in_array($number, [1,2,3])), то первое конечно писать приятнее, но недостатки легаси — это такая мелочь по сравнению со всем остальным.Все в продакшене уже почти год и единственное, что меня не устраивает — это то, что у RabbitMQ нет возможности получить список задач очереди или включить защиту от дублей, но к PHP это отношения не имеет.
Сначала хотел использовать ноду, но как оказалось на тот момент она все равно была однопоточная (для реальной многопоточности нужен был какой-то геммор), плюс… ну нафига мне плодить разные языки в проекте? Все на PHP — и вся кодовая база едина, очень удобно.
P.S. Вообще «нормальную» асинхронность найти очень сложно, как мне кажется. Потому как сама по себе асинхронность сложна и всегда будут какие-то неудобства.
Плюс в PHP есть отличная экосистема для создания веб-бэкэнда, которая значительно масштабнее, чем в любом другом языке.
Заменить в вашей фразе на название любого другого языка и с ней согласится не меньше людей, чем согласилось с оригиналом.
Не весь мир — тонкие API и микросервисы.
www.youtube.com/watch?v=Ng3awE4dNSI
Включение популярных расширений в ядро языка — спорное решение. С одной стороны хорошо, что при выходе новой версии авторы проверяют все на совместимость. С другой — при наличии менеджера пакетов (как npm/nuget/gem/...) гораздо легче обновлять пакеты на актуальную версию, не завися от хостера.
Мне кажется они там придумывают новые слои абстракции совершенно не задумываясь нужно ли это комуто вообще.
А можете пример привести? По-моему конечного пользователя все эти абстракции не касаются
Сифмони заставляется меня безукоснительно следовать СОЛИДу.
Я так понимаю что вы не очень понимаете что такое SOLID.
Нужно создавать какието менеджеры, контейнеры, те в свою очередь хотят чтоб я им инъектил чтото и тп.
Вы можете в симфони так же как и в ларавель херачить все в контроллерах. Так собственно половина людей делают. Солиды — никто не заморачивается по этим принципам. А если кто-то заморачивается и заставляет вас классы-менеджеры делать — он просто не понимает что делает.
без которого в реальной жизни очень сложно приходится.
суть не в том что бы не писать "сомнительных решений", а в том что бы изолировать их, дабы уменьшить их влияние на проект. Как говорится — все какают но обычно делают это в определенных местах а не по всему дому.
контроллер уже имеет встроенный менеджер сущностей, который дает доступ к базе
контроллер (на тот момент, сейчас это не рекомендуется) имеет доступ к контейнеру зависимостей. в контейнере собственно все лежит. Там лежит менеджер сущностей (штука которую тоже не стоит так вот в открытую юзать но это детали), которая позволяет достать репозиторий (коллекцию сущностей) и там уже можно забрать из коллекции то что надо. Это не сильно отличается от Model::find() просто контроля больше. Ну и да, вас никто не заставляет юзать доктрину с симфони, ставите рядом любую AR библиотеку и радуетесь.
надо танцевать с бубном и инъекциями
я просто надеюсь что мне не придется сталкиваться с проектами написанными вами.
И да, к SOLID это все никакого отношения не имеет. Они про то как делать что бы было проще менять. Если вам не проще — вы что-то делаете не так. И если для вас проще бездумно собирать код из документации — сами понимаете какой будет эффект.
PHP8. Ни слова про asynс-await. Шел 2018-й год.
Ни слова про asynс-await.
А раздел "асинхронность" для кого? async/await в целом это лишь сахар, корутины есть, не хватает лишь event loop-а из коробки и промисов (что бы стандарт а не как в ноде первые 5 лет). Без этого нет смысла говорить о добавлении сахара.
Более того, посмотрите на тот же amphp:
try {
$gh = "https://github.com/";
$response = yield $http->request($gh);
} catch (HttpException $e) {
// handle error
}это код который вы можете писать уже сегодня. Проблема в том что область применения ограничена так как стандартные функции для работы с I/O все еще синхронны и людям приходится делать все с нуля.
Дайте дженерики хотя бы стандарт в док коменты. А то с промисами совсем беда.
Надо из них выбирать. Я ставлю на JS, слишком много шуток вокруг него из серии «угадай, что этот код делает в JS»…
З.ы. ну и про бесконечные фреймворки, конечно…
JS как язык конечно говно, но развивается он намного лучше php. Особенно со всеми этими бабелями и т.д. Ну и есть typescript/flow и webassembly.
честно сказать я получаю больше удовольствия от написания кода на js чем от php. Инфраструктура решает.
А какой порог вхождения в JS? Серверный JS, фронт? Ноды, редуксы, реакты, ангуляры, тайпскрипты, байбелы, йарны, прости, Господи… Не ясно за что хвататься.
Мало того, что ванильный JS постоянно развивается, так параллельно еще и куча наворотов.
З.Ы. и это при том, что я в целом люблю JS. :D
А какой порог вхождения в JS
ниже чем вы можете себе представить. Тут как с php. порог входа низкий, ограничений мало, и пошло поехало.
Не ясно за что хвататься.
каждый день люди спрашивают тупости типа "путь изучения php" и всякий раз в топе будет вопрос "поучи симфони/ларавель/yii". Я это к тому что язык тут не важен, проблема с комьюнити. У JS с этим пока все же лучше но не намного.
Ноды, редуксы, реакты, ангуляры, тайпскрипты, байбелы, йарны, прости, Господи…
Почему тогда про php не говорите, что у него есть всякие симфони, доктрины, ларавели, смарти, компоузеры и еще много аналогичных страшных слов?
Не нужно заботиться ни о диалектах языка (TypeScript или нет?), сборщиках, браузерных API и т.д. PHP развивается достаточно понятно, фреймворки тоже уже давно устоявшиеся. Плюс такое ощущение, что в JS зоопарк технологий меняется с куда большей скоростью.
Потому что этот зоопарк на PHP всё-таки меньше
ну в js тоже есть свои стандарты. И как-то в php среде не принято делать красивый пост на медиуме о новом крутом фреймворке. Хотя на рэддите раз в неделю кто-то выкидывает свои творения.
и он не так быстро меняется
я вижу в этом больше негативного нежели позитивного. При таком большом количестве php разработчиков так хреново развивать экосистему — это о много говорит. Да, в js комьюнити проблема другая — много недовелосипедов которые пиарятся неплохо, но… с этим можно смириться хотя бы.
В целом как по мне будущее не за "язык А лучше" а за возможостью более гибко их юзать совместно.
выбрать шаблонизатор из Smarty, Twig или Blade
в js комьюнити все тоже выбирают только из nunjucks/pug/mustash. Есть еще, но это не мэйнстрим. Так же как и для php есть куча разных о которых вы даже не подозреваете.
ORM привязана к фреймворку.
так только в плохих фреймворках. Ну и всеравно нормальных ORM для php нет. Разве что доктрина, и то не оч.
Не нужно заботиться ни о диалектах языка
я спокойно озабочусь диалектами если они позволят мне типы выражать без кастылей.
сборщиках, браузерных API и т.д.
вы ж под бэк писать собрались, зачем вам бандлеры?
фреймворки тоже уже давно устоявшиеся
стогнация?
такое ощущение
ощущение такое есть но… по факту этого нет. Тем более давайте будем честны, если вы возьмете именно серверную часть — там так же все давно устоялось. Есть express, koa и т.д. Не нужно просто всю экосистему JS в одну кучу смешивать и все будет куда проще.
Ноды, редуксы, реакты, ангуляры, тайпскрипты, байбелы, йарны, прости, Господи…, а это в основном про фронтэнд. Я думаю что на бэкэнде и для PHP и для Node.js ситуация устоялась не потому что болото и экосистема херово развивается, а потому что под все типовые задачи уже есть хорошие инструменты. В то время как для современного фронтэнда vanilla js совершенно недостаточно, и приходится придумывать кучу надстроек чтобы это решить.
ну если проанализировать ситуацию с фронтэндом вдруг тоже окажется что подходы устоялись. Дальше весь вопрос в мелочах — типа где делать diff стэйта, между приложением и UI или на уровне DOM и т.д.
babel и полифилы в целом позволяет не особо думать о том что умеет браузер, ну а дальше уже вкусовщина начинается.
Одно дело написать микросервис на Го, другое — крупный энтерпрайс с миллионам строк кода. Там будет столько говнокода, что легаси проекты на PHP вам позавидуют
PHP объектно-ориентированный.
классо ориентированный*
Что до Go — у него есть структурный тайпинг и в целом я бы еще с вами мог поспорить чья модель выполнения больше вписывается в концепцию ОО. Как по мне Го тут только в выйгрыше (просто концепт объекта меняется). И да, и у того и у другого нет дженериков.
Там будет столько говнокода
Увы правда в том что в любом проекте на миллион строк будет говнокод. Такова природа энтропии. И го в этом плане опять же выигрывает.
К сожалению, большинство проектов не запускается, но это никак не уменьшает количество кода на php, скорее прибавляет :)
ИМХО 3 странички с базовой логикой на java, если не постоянно с ней работаешь, будет сложней, не говоря уже о том, что "условно нормальных" рецептов nginx+tomcat не нагуглить за 5 минут (не говоря уже о случаях, когда вдруг задеплоенный war валит сервер при старте выдавая кучу ошибок)
Можно но тогда будут другие вопросы :) ведь банальной возможности скриптового php, когда можно смешать html+php и скормить интерпретатору установленному 1й командой практически в любом дистрибутиве, java, вроде, не имеет?, или я что-то пропустил?
p.s. специально "поспрашивал" яндекс с гуглом, везде jetty, tomcat и куча xml-ей в ide
github.com/reljicd/spring-boot-blog — ну вот посмотрите. Как по мне не сложнее всяких там ларавелей и симфони и при этом не php.
Ну а штуки где закинуть файлик по ftp и т.д. в коммерческой разработке должны умереть (их можно заменить другими вещами где не надо код писать вообще).
Так мы про 3 странички с базовой логикой для не владеющего java или про заказную коммерческую разработку (которая может угробить бизнес идею ещё до начала работы?), у меня есть перед глазами пример бизнес который появился только за счёт того что был php, в котором было не сложно разобраться знакомому владельца. При этом стоимость "коммерческой разработки как должно быть" никто бы оплачивать не стал :)
Мне нужно было сделать сайт по объявлениям, очень быстро. Набрал в гугл php script classifieds — получил кучу ссылок. Рабочий полностью сайт поднял за 1 час.
Набрал в гугл go script classifieds — выдает РНР решения.
Набрал golang script classifieds — нет РНР решений, но вижу набор не потребных ссылок.
Я не знаю есть ли готовое решение на GO, может оно и есть, тогда можно сказать, что гугл виноват. Но подозреваю что его все же нет.
Представьте что за эту работу я получил 5000 долларов. На РНР я заработал эти деньги за 1 час, на GO — неделя, месяц?
Профит?
Профит?
всегда было жаль клиентов которые платят кому-то $5K/h за скаченный скрипт и потом страдают с тем что бы кто-нибудь это дело потом поддерживал.
Я отвечал на конкретный вопрос — почему люди до сих пор выбирают РНР, вы куда-то не туда данную ветвь дискуссии повели.
В моем конкретном примере 5к заработано за 1 час работы, сделать нужно было быстро. Заказчик был впечатлен оперативностью. Далее был подписан контракт на поддержку и развитие проекта и никакой боли от этой поддержки и развития нет. Скрипт который был выбран вполне себе хорошо спроектирован и нормально написан на РНР.
Если проект в будущем взлетит и будет приносить 1млн в месяц, то уже можно будет нанять команду гошников или питонистов, которые радостно всё за год перепилят и на которых будет не жалко тратить заработанные деньги. А можно будет поступить по другому — потратить лишние N-к денег на дополнительные бэкенд сервера под РНР нагрузку, что опять же будет дешевле той самой команды питонистов или гошников.
Чтобы уж совсем все по полочкам разложить то расскажу еще одну историю. В предыдущей моей конторе ребята переписывали систему (кажется с питона) на GO. Делали они это 2 года! В итоге вместо 10 серверов они смогли тоже самое на 1-ом серваке развернуть. Только не помню уже точно детали, но кажется изначально дело было не в питоне, а криворукости тех питонистов, которые изначально написали систему. Можно посчитать сколько они бабла на программистов потратили за 2 года, там их около 5 человек было и когда это все добро окупится.
вы куда-то не туда данную ветвь дискуссии повели.
вы предложили поделиться своим опытом сравнения go и php. Который по сути заключается в "под go не нашел готовый солюшен, под php нашел и впарил клиенту за $5K то на что ушло час работы". На том все сравнение и заканчивается. К чему этот пример? К тому что клиенту пофигу на чем проект лишь бы работало? Так никто с этим и не спорит.
В вашем примере нет никакого анализа выбора инструмента под задачу. просто наброс. Почему изначально рассматривали go если задача настолько простая что найдется готовая система на php, которую можно не допиливая поднять за час? Какого-либо кастомного дизайна не было? Неужели клиенту было достаточно того что идет из коробки, или вы упростили рассказ?
то уже можно будет нанять команду гошников или питонистов, которые радостно всё за год перепилят
и весь этот год проект не будет развиваться? или мы закончим тем что у нас будут паралельно пилиться два проекта и один просто умрет (скорее всего тот, который еще не на продакшене). Или вам понадобится команда которая умеет и в php и в go, которая будет выстраивать пытаться делать более модульную архитектуру (присловутые микросервисы) в попытке планомерно перевести проект на go.
Обычно это "окупается" когда реально нет другого выхода. И обычно так делают не для оптимизации производительности (потому что маленький процент задач будет страдать из-за производительности php, 90% всех проблем можно решить внедрением сервера поверх php приложения, что бы то не умирало, и то для этого само приложение уже должно быть чуть получше чем среднестатистический мусор).
Мне не встречались ситуации, когда описанное вами было выгодно. А где это было чаще диктовалось не за счет рассудительного cost/benifit анализа, а скорее как крик отчаяния.
В итоге вместо 10 серверов они смогли тоже самое на 1-ом серваке развернуть.
2 года работы команды разработчиков намного дороже 9-ти лишних серваков. А потому вопрос — зачем они там что-то переписывали? Перепись была постепенная (то есть инкрементно на продакшен выкатывались новые фичи и была уже смесь python и go)? Или просто развлечение на 2 года?
У меня были ситуации когда нужно было интегрироваться с другими продуктами (например — после покупки одной компании другой компанией), где использовались какие-то кастомные решения. В этом случае были чуть другие стратегии. Но полная перепись это всегда провал (либо много лишних денег, в этом случае не мне судить).
В тут комнду на GO набирали просто хороших программистов, многие были без опыта GO, но с желанием писать на нем, кто-то вообще без опыта в нем, но в процессе все его освоили. Делали инкрементально, не переписывали с нуля, а постепенно пошагово меняли куски проекта, поддержкой Питон кода тоже занимались все это время.
Для меня анализ был простым — заработать 5к за 1 час или 5к за 3-6 месяцев работы
И причем тут php vs go? По вашим критериям побеждает тот стэк технологий, под который подберется более качественное решение. И внезапно может оказаться что побеждает в этом конкретном случае вообще python (первое что нагуглил что получше чем страшные форки вордпресса и прочий ширпотреб на php из топа выдачи).
Изначально вопрос стоял о разработке гринфилд продуктов, а не "бложик поднять". Вполне себе живой вариант делать MVP вообще на google spreadsheets + zapier, и прочие дикие комбинации призванные убрать необходимость вообще свой сервер держать.
А потому я повторюсь — к чему ваши примеры если они вообще ничего не говорят о предмете дискуссии?
многие были без опыта GO, но с желанием писать на нем
то есть причина для выбора технологии — разработчикам было скучно и они решили поучить Go? Я не осуждаю такой подход — иногда это неплохой способ мотивации людей оставаться, но с точки зрения бизнеса плюс тут только в том что можно будет проще искать людей хайповыми технологиями.
Опять же этот пример лишь говорит о том, что ничего вы не выбирали осознанно. Сильно сомневаюсь что был хоть какой-то профит от перехода с python на go. Если это позволило проще разработчиков искать — хорошо, но практика показывает что найти адекватного go разработчика не проще чем найти python разработчика. А в связи с хайповостью еще и фильтровать нужно больше.
И причем тут php vs go?
при том что вопрос изначально был почему люди выбирают это говно РНР? На него я и отвечал, приведя в пример свой случай из жизни.
я по причине хайповости хотел сделать изначально на GO и проимпрувить скилы за чужой счет, но выбрал в итоге РНР, потому что это было быстро
по-моему вы вообще далеко ушли дискуссии и вопроса, с которого она в этой ветке началась
найти адекватного go разработчика не проще чем найти python разработчика
я вообще-то написал, что там просто искали просто хороших разработчиков, у некоторых вообще не было опыта на GO, но было желание (возможно даже у всех не было этого опыта, т.к. это происходило еще тогда когда GO только набирал свою хайповость, про которую вы говорите). Выбор был сделан тим лидом команды.
Почему он выбрал GO не скажу, но тим лид в той команде, который собственно и сделал выбор именно в пользу GO пишет на всем, что шевелится. И, кстати, испытывает ненависть к РНР и давно уже его не использует. Проект был на Питоне, его нужно было переделывать, вот и переделали сразу на гоше.
это говно РНР?
в вашем случае вы выбирали не язык а готовое решение. Не важно на каком языке оно будет. "час работы" -> только конфигурация, никаких изменений в исходниках. А шаблончик подправить можно хоть на хаскеле.
и проимпрувить скилы за чужой счет
добавлю — жаль клиентов которые работают с такими исполнителями
А если бы было такое же готовое решение на go и я бы также заработал 5к за 1 час вам бы было жать клиента? Или вы бы мне рукоплескали? За вашей жалостью какое-то другое чувство скрывается.
На пайтон джанго вам нужно будет модели создавать, разрабатывать структуру базы, продумывать ее. В моем случае под каждый тип объявления формы кастомизировать. Для автомобилей есть объем движка, для недвижимости есть объем площади и т.д. и т.п. Вы это за 1 час сделаете на пайтон джанго? CMS назовите мне, которая на пайтоне все это даст мне за 1 час, я попробую.
За час у вас будет админка и авторизаци и только.
У меня за час был готов сайт с админкой, авторизацией, всеми типами объявлений, форм, кастомизациями, статистикой, спам фильтрацией, премиум объявлений, платежами и прочим. Единственное, что действительно пришлось допилить — это переделать поиск с MySQL Full text search на sphinx. Я уже выше писал, что скрипт нормально написан, я в нем легко разобрался и переделал поиск на Sphinx за 1 вечер. И это не прототип был, а готовый сайт по объявлениям, который на следующий день был вылит на хостинг.
я набрал в гугле «php classifieds scripts»
скачал скрипт, установил за 1 час, все готово
тот же самый запрос с упоминанием GO не дал результатов, т.е. задача за 1 час не решается
тот же самый запрос с Python кое-что показал мне, возможно можно брать упомянутый мной выше saleor
а отвечал я на вопрос «почему люди выбирают РНР вместо GO или ноды?» Я на него и ответил исходя из своего профессионального опыта.
С удовольствием бы сделал тоже самое на GO, если бы ставка была 5000к в час. И еще бы выбирал технологии с недельку за те же деньги.
Вообще запросы с ГО и Питон мне зачастую выдавали РНР решения. Ну может и правда гугл виноват.
Тут скорее зависит от того, кто с чего начинал. Мне как начинавшему программирование, по-сути, с PHP — его синтаксис понятен и удобен… Например я в первый раз сегодня узнал, что кому-то мешает доллар… =)
14 лет пишу на php. Пробовал питон и руби – и меня никто, ни за какие деньги не заставит писать на них)))
тут больше вопрос в том сколько пробовали писать. Мне не нравится python ровно до тех пор пока не пришлось с ним более плотно работать. Ruby — мне не нравятся рельсы а так язык очень даже ничего.
выскажу непопулярное мнение что синтаксис языка это дело привычки и не более. Не стоит судить о языке по синтаксису. А вот если отбросить вопросы синтаксиса и больше на выразительность и возможности глянуть — php будет далеко не в первой десятке. И в целом я бы никогда не стал рекомендовать в 2018-ом человеку учить php. Особенно первым языком. Вообще первый язык должен обладать рядом существенных ограничений. например — отсутствие оператора присваивания неплохое такое ограничение для последовательного обучения.
С++ никто не хоронит потому что много легаси. Вон кобал уже лет 50 хоронят и ничего, все еще живет и продолжает гнить.
Учусь по книжке С++ 11 за авторством Страструпа (по короткой книжке на 80 страниц с кратким изложением основных понятий). Вполне успешно пишу код (допиливаю Bitcoin под свои нужды).
Немного теряюсь в указателях и ссылках, вопрос привычки. Что мне действительно не нравится, так это то что интерфейсы, абстрактные классы, классы, колбеки, контейнеры — являются одной сущностью, и у меня сложилось мнение что именно из-за этого в языке есть такая ужасная вещь как «шаблоны» (молчу про перегрузку операторов и макросы — тот ещё кошмар, — специально сделали чтобы никто не знал как работает код). У меня стойкое ощущение, что нормальные интерфейсы по большей части заменили бы шаблоны и код стал бы намного яснее.
у меня сложилось мнение что именно из-за этого в языке есть такая ужасная вещь как «шаблоны»
метапрограммирование это не такая уж и страшная вещь. Опять же — вам просто непривычна эта концепция.
специально сделали чтобы никто не знал как работает код
У меня сложилось впечатление что подавляющее большинство разработчиков очень плохо понимает понятие абстракции. С чем это связано — понятия не имею.
У меня стойкое ощущение, что нормальные интерфейсы по большей части заменили бы шаблоны
Люди уже пытались — вышла java. Потом в java пришлось добавлять дженерики (только в 5-ой версии они появились). Потом отдельно лямбды, потом дефолтные методы для интерфейсов. А вот protected в С++ даже Страуступ считал ошибкой. Как и friend классы. Как он говорил — это те вещи которые стоит использовать один два раза за всю карьеру.
C++ далеко не самый лучший язык на свете. И многие вещи там непривычны и опасны. Но если вы понимаете что зачем и почему можно делать прекрасные вещи (или ужасные). Проблема именно в том как сделать обучение последовательным что бы привить понимание вещей и избавить от желания сделать очень плохо.
Взять то же ООП. Люди привыкли уже что ООП это когда у тебя код по классам разбит и т.д. А посмотреть на тот же smalltalk где даже штуки типа if или там for были просто методами объектов (что больше роднит этот язык с какими-нибудь функциональными языками, нежели с джавой той же). Или что в целом мы можем взять erlang и воспринимать один микротред, который может принимать/отправлять сообщения и иметь приватный стэйт как объект.
Словом люди всегда найдут способ сместить фокус внимания с важных вещей (концепции, идеи) на неважные (синтаксис, конкретная реализация). Так много идей погибло. ООП, SOA, TDD, микросервисы сейчас вот добивают...
у того же С++ синтаксис намного хуже, чем у PHPУ плюсов своя ниша (высокая производительность), в которой альтернатив практически нет. Возможно, ситуацию изменит Rust, но пока он все еще мало распространен. С вебом же ситуация противоположная — для написания бэкендов есть штук десять популярных языков, и можно выбирать то, что больше нравится.
его синтаксис понятен и удобенЕсли вы начинающий программист и PHP оказался вашим первым языком — возможно, вы просто не знаете, что может быть по-другому. Чисто ради интереса изучите какой-нибудь другой язык (из хорошо продуманных могу посоветовать C# и Python). Может оказаться, что вы всю жизнь ели суп вилкой.
Python — не нравится принципиально, т.к. с ним неудобно работать в блокноте из-за принудительных работ по выставлению пробелов. Под давлением силы обстоятельств имею привычку вносить мелкие правки в код удалённо с телефона, — на телефоне студию не запустишь и все возможности vim'а не применишь. Не должен язык меня заставлять ставить пробелы.
Возможно, решение лежит не в технологической плоскости, а в организационной: разделять время на рабочее (когда у вас есть все необходимое для эффективной работы) и нерабочее (когда вы отдыхаете и не возвращаетесь к рабочим делам).
В мире C# с тех пор все сильно поменялось. Рантайм .NET Core вполне нормально работает на трех основных операционках, хотя он пока поддерживает только бэкенды для сайтов.
Организационное решение проблемы хорошо, но не во всех ситуациях подходит. Как известно бывает разная работа, с разным уровнем ответственности, сроками реагирования, оплатой, штатом сотрудников. В моём случае организационно можно только сменить работу на менее оплачиваемую, с чем я не могу согласиться.
Рад за C#, только вот зачем он мне под бекэнды для сайтов, когда я гораздо быстрее решу задачу на привычном стеке? Пока на сайте нет существенной аудитории — нет нужды его оптимизировать (при условии, что изначально не писать совсем уж нарочно тормозной код), поэтому какой-то выгоды от применения C# (конкретно треды в PHP страдают, а в C# вроде работают) для бекэнда сайта — мне не видно. Будет достаточная аудитория, — будет отдельный разговор как дальше жить (скорее всего на Java дальше жить, выбирая между Java и C#, я всё же выберу Java, либо правильно применять PHP, — он тоже много всего умеет).
PS: Ещё вы так написали, что у меня сложилось ощущение будто бы я не расту. Это не так, — чуть выше я писал про свой опыт с С++. В моём случае был выбор без выбора, но даже будь выбор — он бы не пал на C# или Python, т.к. это шило на мыло с моей точки зрения.
- Отсутствие асинхронности из коробки. Распараллелить 2 исходящих HTTP-запроса — не тривиальная задача.
- Объёмный синтаксис. Например:
VS// PHP list('foo' => $foo, 'bar' => $bar) = ['foo' => 1, 'bar' => 2];// JavaScript let {foo, bar} = {foo: 1, bar: 2}; - Необходимость инициировать объекты приложения при каждом HTTP-запросе, что уменьшает производительность системы. Для решения этой проблемы есть решения, которые не назовёшь идеальными: контейнер сервисов, ReactPHP.
Радует, что разработчики PHP взяли курс на асинхронность. Хотелось бы уже в первой версии видеть все низкоуровневые операции ввода/вывода асинхронными.
Распараллелить 2 исходящих HTTP-запроса — не тривиальная задача.
[$google, $bing] = Co::wait([
get('https://google.com'),
get('https://bing.com')
]);вполне себе тривиальная задача.
Объёмный синтаксис. Например:
в целом не обязательно писать list(...). есть сокращенный вариант, но да, в JS в этом плане намного лаконичнее. А так же меня лично бесит неконсистентность фич. Очень бы хотелось видеть что-то типа такого:
$fn = ([$foo, ...$rest]) => [...$rest, 'foo' => 'new foo']
$fn(['foo' => 1, 'bar' => 2]);контейнер сервисов
они решают несколько другую проблему. Ну и помимо вариантов на reactphp/amphp есть еще spiral/roadrunner. Он как по мне выглядит намного приятнее. А то что оно на go — вас же не смущает что php-fpm на Си.
https://github.com/mpyw/co
Для PHP это скорее исключение, чем правило. Тоже самое можно сделать с помощью Guzzle. А вот параллельно с этим сделать отправку email или запрос к БД уже так просто не получится.
Очень жаль что асинхронность откладывается всё дальше, как по мне, то выбирая между JIT и асинхронностью, я бы выбрал последнее. Наличие таких проектов как ReactPHP, swoole, amphp, конечно, радует, но как мне кажется, это всё — костыли. Решение из коробки очень было бы очень кстати, особенно, когда речь идёт про Windows платформу.
Если сравнивать NodeJS и PHP (куда же без этого), то NodeJS в текущем виде мне напоминает времена PHP4, нет нормального ООП, автозагрузки, простанств имён, плюс инфраструктура NodeJS это какой-то ад, два пакетных менеджера npm/yarn, модули могут быть написаны на TypeScript/CoffeeScript что сильно снижает способность разобраться как работает модуль, для сборки какого-нибудь мелкого проекта надо вытянуть тысячи зависимостей, отсутствие универсального фреймворка типа yii/laravel (expressjs для меня всего лишь продвинутый роутер, не более), с нормальным подходом MVC, как цельное решение, без необходимости собирать всё из отдельных кусочков. Для NodeJS я не встречал проектов уровня Wordpress, Magento, Prestashop, Drupal, NextCloud и др (может кто подскажет?)
Из вашего описания понятно только одно:
- вы совершенно не знаете JS (вы автозагрузку с нэймеспейсами считаете благом а не кастылем в связи с отсутствием модулей, да и ООП у вас какое-то не такое, хотя в JS оно идеологически даже лучше, особенно с последними редакциями ecmascript).
- вы не хотите думать, то есть вот все есть из коробки и ничего делать не надо. А тот факт что на гитхабе валяются сотни разных сборок этих сотен модулей, где так же ничего особо делать не надо вас не смущает. Учитывая что даже в PHP такие монолитные фреймворки как Yii уже считаются морально устаревшими. Даже в Laravel все не так гвоздями прибито.
- вы подменяете понятия. Миру не нужен еще один вордпресс (блоговых CMS на ноде много, но большинство склоняется либо к сервисам либо к генерации статических сайтов), или еще одна магенту (это вообще тот еще адок). Да и количество CMS под ноду в целом немаленькое. Вы просто не искали.
У ноды есть проблемы, в частности это признают авторы оной. Но то что вы описали больше подчеркивает отсутствие представления как делать что-то НЕ на php.
Есть прога AutoHotkey и на клавиатуре есть очень удобно расположенная и крайне бесполезная клавиша CapsLock (кошмарная бесполезная фигня ИМХО).
Так вот — через AutoHotkey можно заменить нажатие на CapsLock на вывод знака "$" (можно даже дополнить комбинацией Ctrl+Space если у вас IDE выводит подсказки только после такой комбинации).
Также можно Shift+CapsLock заменить на вывод "$this->" или "$this".
Если же вы по каким-то мистическим причинам используете CapsLock, то можно повесить его на Alt+CapsLock.
Команды (Shift = +; Alt = !, Ctrl = ^):
Capslock:: Send $
+Capslock::Send $this->
^Capslock::Send ->
!Capslock::SendInput {Capslock}
Кстати, если вы недовольны раскладкой своей клавиатуры — с помощью AutoHotkey можно поменять почти все что угодно. Я вот на своей клавиатуре поменял кнопки на блоке «Home/Enf/Del/PgUp/PgDown» так как мне нужно и по сути исправил для себя единственный минус этой клавиатуры. Можно еще NumLock отключить или переназначить клавиши на NumPad'е.
PHP 8: чего ждать. Письмо Зеева Сураски