Comments 75
UFO just landed and posted this here
Да, но фактически я встречал оочень мало фреймворков/проектов в которых эти структуры применялись бы активно.
Но это не мешает применять их Вам. Хотя для меня, человека который начинал с PHP, а сейчас работающего с C#, довольно странный путь PHP->C#. Иногда, когда я касаюсь разработки на PHP, мне очень не хватает той мощности C# (особенно встроенного linq и генериков). Ну и «магичность» PHP…
Да, потому что 99% функционала можно покрыть обычными массивами. А учитывая, что PHP «создан чтобы умирать», то какие-то микро-оптимизации SPL довольно бессмысленны.
Хотя, у меня есть демон который использует SplObjectStorage и это довольно удобно. Правда не замерял скорость/память по сранению с обычными массивами, но не думаю, что что-то сильно бы поменялось.
Хотя, у меня есть демон который использует SplObjectStorage и это довольно удобно. Правда не замерял скорость/память по сранению с обычными массивами, но не думаю, что что-то сильно бы поменялось.
Тут немного тестов есть: habrahabr.ru/post/337298
Автор ещё видимо не открыл для себя DS из 7-км. Очень надеюсь, что, как когда-то и fpm, перетащат в «из коробки»
К сожалению, PHP имеет ряд недостатков, которые упрощают жизнь на простых проектах, но приводят к тому, что обычное сравнение очень часто вызывает недоумение.
Никто не запрещает использовать строгое сравнение "===", жонглирование тут будет исключено.
Передача по ссылке работает не так как в .net!
На самом деле передача по ссылке работает точно так же как в .net.
В C# 7 можно написать:
var foo = "Петя";
ref var bar = ref foo;
bar = $"Меня зовут {bar}";
Console.WriteLine(foo);
Console.WriteLine(bar);В более ранних версиях языка так писать нельзя — но не потому что передача по ссылке работает как-то по-другому, а потому что она работала только для формальных и фактических параметров, а пример выше вызывал синтаксическую ошибку.
Книги. Меня конечно сейчас закидают, но мне кажется что книги по PHP устаревают еще до печати. Так же как в JS, например.
Про путь C# в сторону opensource. Сейчас есть две ветки .net «старый» и .net core, так вот открыт только второй, классический dot.net остался закрытым. И для совместимости придумали net standart.
«Старый» не развивается как opensource, но код всё-таки доступен на sourceof.net
Говоря про пивот к опенсорсу, я имел ввиду кучу всего на гитхабе.
Язык программирования (C#) и фреймворк (.NET Framework или .NET Core) это разные вещи. В любом случае, всё уже открыто: C#, .NET Core, .NET Framework (частично).
Хочется крикнуть БЕГИТЕ ГОЛУБЦЫ ГЛУПЦЫ!!! Я сам сишарпер, но сейчас волей судьбы приходится кодить на пыхе. Я уже волосы на голове готов рвать. Это жуткий язык. Просто чудовищный. Функциональность никакая. Синтаксис ужасен (например мне просто катастрофически не хватает коротких лямбд). Говнокода в старых проектах просто океаны, причем его нечитабельность поражает (в C# так специально не напишешь). Слава богу начальник обещал следующий проект на чем-нибудь другом делать. Может даже уболтаю на C# .NET Core (сервак все-же на линуксе).
Вы не написали о своём опыте работы на .NET, это сильно меняет контекст статьи.
И почему вы решили сменить стек.
Разница в языках мне кажется совершенно не важна — важно что вы перешли на стек где большое open-source комьюнити. В сравнении с .NET это огромный плюс, т.к. для .NET попробуй нади хороший сторонний компонент (пусть платный), который решит твою задачу.
Потоков дейстивтельно нехватает после C#, но всё решаемо если с головой подходить.
Я правда говорю с точки зрения перехода .NET C# (9 лет) -> Python (3 года).
И почему вы решили сменить стек.
Разница в языках мне кажется совершенно не важна — важно что вы перешли на стек где большое open-source комьюнити. В сравнении с .NET это огромный плюс, т.к. для .NET попробуй нади хороший сторонний компонент (пусть платный), который решит твою задачу.
Потоков дейстивтельно нехватает после C#, но всё решаемо если с головой подходить.
Я правда говорю с точки зрения перехода .NET C# (9 лет) -> Python (3 года).
Спорно, очень спорно. Интересно чего такого вы не нашли в C# что есть в пхп. В VS я просто открываю нугет, удобно интегрированный с поиском и быстрой установкой пакетов в один клик. Причем ни разу не было чтобы я не нашел там что надо. А в пыхе приходится гуглить, причем желательно что-то сразу интегрированное во фреймворк (например для Yii какой-нибудь виджет). Потом вручную копировать/вставлять в композер.жсон, запускать с консоли `composer update` (в IDE почему-то у меня не подцепляется это) и долго ждать пока он установит (хз почему, но ставит и обновляет он очень долго, по несколько минут).
Ну я конечно про Python говорю в большей степени, неужени в PHP так всё плохо?
Одних только готовых компонент к Django целый вагон, комплексное решение можно сделать много быстрее.
Просто есть готовые, качественные, open-source решения, которые ты можешь взять и использовать.
Одних только готовых компонент к Django целый вагон, комплексное решение можно сделать много быстрее.
Просто есть готовые, качественные, open-source решения, которые ты можешь взять и использовать.
UFO just landed and posted this here
Порты и адаптеры уместны, если вы используете laravel, yii или другой фреймворк, который не реализует psr стандарты. Yii это вообще отдельная, холиварная тема, в него что либо впилить без костылей нельзя, они лишь относительно недавно избавились от classmap вручную сгенеренный вместо autoload.
Если же используете symfony, то большую часть решений включаются без особых проблем, более того, все, абсолютно все фреймворки используют компоненты и symfony, и Zend framework. другое дело, что иногда автора пакетов не соблюдают стандарты psr, и создают проблемы впоследствии с портированием. Это есть, но не настолько критично, как может показаться, больше всего проблемы создают фреймворки, которые в своем движке не оставляют вариантов, кроме как от стандартов либо отречься, либо мучиться с портированием, либо мучиться с зависимостями. конфликты тоже случаются, но это везде, NuGet не исключение)
Phpstorm вполне нормально поддерживает composer из коробки
blog.jetbrains.com/phpstorm/2017/07/configuring-with-composer-in-phpstorm-2017-2
В остальном да, у Php порог входа ниже, соответственно мягко говоря некачественного кода больше, но это еще не говорит о том, что в нем нет инструментов для организации лучших практик проектирования и программирования.
Странно, но очень немного Php разработчиков, обычно уровня middle+, вообще пользуются psr интерфейсами для стандартизации кода.
Если же используете symfony, то большую часть решений включаются без особых проблем, более того, все, абсолютно все фреймворки используют компоненты и symfony, и Zend framework. другое дело, что иногда автора пакетов не соблюдают стандарты psr, и создают проблемы впоследствии с портированием. Это есть, но не настолько критично, как может показаться, больше всего проблемы создают фреймворки, которые в своем движке не оставляют вариантов, кроме как от стандартов либо отречься, либо мучиться с портированием, либо мучиться с зависимостями. конфликты тоже случаются, но это везде, NuGet не исключение)
Phpstorm вполне нормально поддерживает composer из коробки
blog.jetbrains.com/phpstorm/2017/07/configuring-with-composer-in-phpstorm-2017-2
В остальном да, у Php порог входа ниже, соответственно мягко говоря некачественного кода больше, но это еще не говорит о том, что в нем нет инструментов для организации лучших практик проектирования и программирования.
Странно, но очень немного Php разработчиков, обычно уровня middle+, вообще пользуются psr интерфейсами для стандартизации кода.
Знать бы почему разработчики в опытом 5+ лет на .net С# переходят на PHP.
Имеется один популярный Российский интернет-магазин одежды, реализованный на .net С#.
Там множество разработчиков и они довольно часто меняются.
За пару лет, человек 10-15, перешли на PHP, другие на питона, гофер и т.д.
Интересуют вопросы:
1) Почему программисты покидают C#
2) Почему многие выбирают PHP
P.S.
Сам работаю на 3х языках Go, JS, PHP
Имеется один популярный Российский интернет-магазин одежды, реализованный на .net С#.
Там множество разработчиков и они довольно часто меняются.
За пару лет, человек 10-15, перешли на PHP, другие на питона, гофер и т.д.
Интересуют вопросы:
1) Почему программисты покидают C#
2) Почему многие выбирают PHP
P.S.
Сам работаю на 3х языках Go, JS, PHP
Иной раз выбирают не язык, а проект.
Но не так же массово! Самому крайне любопытно.
Нет, они именно выбрали PHP или Python (в большем проценте).
Хотя как мне кажется, C# уровнем выше.
Т.е. они пошли работать где проект скажем на C#, и в роли тимлидов, решили переписать на один из указаных мной языков. То ли PHP становится популярным в России, за счет улучшения ключа ООП, то ли у людей явно что то происходит в голове интересное.
Я конечно за PHP, ко людей обычно отговаривакаю, меньше конкуренции, это плюс =)
Хотя как мне кажется, C# уровнем выше.
Т.е. они пошли работать где проект скажем на C#, и в роли тимлидов, решили переписать на один из указаных мной языков. То ли PHP становится популярным в России, за счет улучшения ключа ООП, то ли у людей явно что то происходит в голове интересное.
Я конечно за PHP, ко людей обычно отговаривакаю, меньше конкуренции, это плюс =)
1) язык C# энтепрайзный, что подразумевает основательный, вдумчивый и серьёзный подход к разработке, творчество сильно урезано. уходят потому что «художники» и хотят больше творческой свободы
2) знаю только одного человека, который ушёл на PHP, причина: писать очень быстрые скрипты и на лету размещать их в интернете, проекты: реклама на сайтах, банерные сети, порно, генерация саттелитов ботнетами и подобное.
П.С. ещё по 2) если сравнить охват и распространённость PHP с C#, и свести к пропорциям, то уже никаких «многих» не будет :)
ну и для энтепрайза PHP практически совсем не подходит. поэтому надо смотреть по области задач, а не вообще.
2) знаю только одного человека, который ушёл на PHP, причина: писать очень быстрые скрипты и на лету размещать их в интернете, проекты: реклама на сайтах, банерные сети, порно, генерация саттелитов ботнетами и подобное.
П.С. ещё по 2) если сравнить охват и распространённость PHP с C#, и свести к пропорциям, то уже никаких «многих» не будет :)
ну и для энтепрайза PHP практически совсем не подходит. поэтому надо смотреть по области задач, а не вообще.
1)… творчество сильно урезано
А можно пример проявления такого творчества?
$var_name = 'my_var';
$$var_name = 'hello';
Вот такое, например, делать в C# невозможно, соответственно не приходится контролировать и бить по рукам. Очень мало «утиной» типизации, неочевидного поведения, которое можно «творчески» эксплуатировать, с приведением типов практически нет никаких сюрпризов. В большой командной разработке строгость и сухость языка, местами многословность — то, что в динамике, типа PHP можно сделать парой строчек, в C# порой надо решать вообще отдельными структурами и классами, расширяющими методами, это огромный плюс. Для некоторых это минус.
Вот такое, например, делать в C# невозможноСильное заявление. Как же рефлекшн? Другое дело, что кейсы для таких вещей обычно покрывают с помощью полиморфизма.
Очень мало «утиной» типизацииА как же анонимные типы?
dynamic? Кортежи?Многословно — да, но если все равно потом придется писать тесты, то здесь типобезопасность гарантируется компилятором.
Выходит, творчество — это быстрые неочевидные хаки? Но, блин, в PHP по сей день перед каждой переменной "$" (=
Сильное заявление. Как же рефлекшн? Другое дело, что кейсы для таких вещей обычно покрывают с помощью полиморфизма.
Рефлекшн не является рядовым инструментом для решения задач, и при его применении видно явно: это рефлекшен, т.е. такой код дополнительно требуется протестировать и зачастую можно выпилить и заменить на код без рефлекии или на Extpression-tree. Ну и полиформизм в C# это не «полиформизм», основанный на подстановке имени переменной в рантайме, компилятор может проконтролировать приведение типов в рамках иерархии наследования.
А как же анонимные типы? dynamic? Кортежи?
Я бы не назвал это утиной типизацией :)
Выходит, творчество — это хаки? Но, блин, в PHP по сей день перед каждой переменной "$" (=
Творчество, это эксплуатирование неочевидного поведения и всяких WAT для получения профита, душевного и практического :)
Рефлекшн не является рядовым инструментом для решения задачНу это уже как минимум не «невозможно», правда?
такой код дополнительно требуется протестироватьТакой код и в php нужно тестировать. Вообще, всю такую рантаймовую магию нужно тестировать, ибо компилятор тут не всегда сможет спасти.
Я бы не назвал это утиной типизациейСути дела это не меняет (=
Творчество, это эксплуатирование неочевидного поведения и всяких WAT для получения профита, душевного и практическогоНеочевидный код доставляет php-юзеру удовольствие?)
Ну это уже как минимум не «невозможно», правда?
Рефлексия — это одна из сильных сторон платформы, но в прикладном коде она встречается редко, и очень легко детектится.
Неочевидный код доставляет php-юзеру удовольствие?)
Не исключено ))
Ну, как сказать… например, для использования кастомных атрибутов рефлекшн необходим. А это достаточно популярная функциональность.
Возможные ошибки там — поганы, как и любые другие рантаймовые.
Возможные ошибки там — поганы, как и любые другие рантаймовые.
UFO just landed and posted this here
Не-не, я абсолютно не приветствую в любых формах доступ к приватным полям, это косяк в архитектуре. А в рефлексии удобно собирать динамические вызовы хендлеров для команд, запросов, событий. Сейчас пилим CQRS, без рефлексии никуда :)
UFO just landed and posted this here
ОРМ-ки могут прекрасно работать с POCO, это наиболее правильный путь, я считаю. Сущности в понятиях DDD, всё равно отвратительно ложатся на ORM, и все попытки это сделать, которые я наблюдал за много лет, это просто курам на смех :) Поэтому ORM надо оставить то, для чего оно было придумано.
Мы пилим на C#, за основу ничего взять не получилось, пилим с нуля. В пыхе проще, там типизация утиная, поэтому можно вызвать handle с одним аргументом у любого класса. В C# тотальный контроль типов, и класс хендлера должен реализовывать интерфейс хендлера с типом-командой, чтобы найти хендлер, надо в рефлексии сформировать тип хендлера, затем получать его через DI. Т.е. какой-то особенный конфиг-мап не нужен, просто регистрируем свои хендлеры в DI и всё.
Мы пилим на C#, за основу ничего взять не получилось, пилим с нуля. В пыхе проще, там типизация утиная, поэтому можно вызвать handle с одним аргументом у любого класса. В C# тотальный контроль типов, и класс хендлера должен реализовывать интерфейс хендлера с типом-командой, чтобы найти хендлер, надо в рефлексии сформировать тип хендлера, затем получать его через DI. Т.е. какой-то особенный конфиг-мап не нужен, просто регистрируем свои хендлеры в DI и всё.
Утиная типизация — это как работают операторы foreach и await. В анонимных типах и кортежах нет никакой утиной типизации, анонимный тип или кортеж — это строго определенный тип данных.
dynamic может использоваться для утиной типизации.
ну и для энтепрайза PHP практически совсем не подходит
Что вы имеете в виду? Чем не подходит?
Не подходит тем, что одна и та же задача в PHP может быть решена 100 разработчиками совершенно разными 100 способами. В C# профессионалы одного уровня решат её примерно одинаково, соответственно большой команде не надо долго и упорно договариваться, код получается единообразным, понятным, контролируемым, практически полностью очевидным и предсказуемым. Но такой код пишется большими усилиями и с гораздо более высокими требованиями к профессионализму, зато сопровождается дешевле. Ну и не видел я серьёзного присутствия PHP в энтерпрайзе, только на периферии.
решена 100 разработчиками совершенно разными 100 способами
Очень спорно. Как тут PHP замешан? Откуда такая инфа?
Ну давайте не придираться к словам, естественно никто не брал 100 разработчиков и не изучал их 100 решений, это небольшое вольное утрирование. Честно говоря, не вижу смысла холиворить, я высказал свои соображения, основанные на опыте и наблюдениях, не в целях кому-то что-то доказать. Тем более я уверен, что на любом языке можно писать как плохо, так и хорошо. Но PHP предоставляет очень много вольностей, и мне видится не эффективным обустраивать разработку на большом количестве гайдов и договорённостей, в то время как в C# имеется единый для всех гайд, прививаемый с самых пелёнок и компилятор не даёт наделать большое количество ошибок, которые можно легко наделать в PHP.
А что за единый гайд, прививаемый с пелёнок? Я помнится году в так в 2000-м использовал немного Visual C# на одном проекте и году так в 2009-м Mono на другом и что-то единого гайда не помню.
Единый гайд описан на страницах MSDN, описан один к одному во всех книгах и упоминается в статьях, прослеживается в 90% существующей кодовой базы. Его и помнить не надо, так как если вы разрабатываете на C#, то уже скорее всего придерживаетесь этого гайда, если только вы не перешли с другого языка и тащите свои привычки в чужое поле.
100 способов сильно ограничиваются решениями использовать тот или иной фреймворк, ту или иную инфраструктуру. Как, скажем, в мире .NET принимают решение использовать ASP.NET WebForms, а не ASP.NET MVC и некоторые способы становятся если не недоступными, то нерациональными, а профессионалі садятся за гайды, потому что никогда не сталкивались, но всё равно по факту протаскивают "неправильные" способы. А решение использовать MySQL, а не MS SQL может привести к тому, что C# разработчики отказываются с ним работать из-за того, что что-то там не поддерживается на уровне то ли .NET библиотек, то ли Windows, а SQL код писать они не привычные. Вернее не знают как сделать из SQL-запроса граф обычных объектов и потому просят DBA на стороне MS SQL написать шлюз к MySQL.
Но вообще речь не о C#, а о PHP. Как я понял, основные причина вывода "для энтепрайза PHP практически совсем не подходит" у вас это отсутствие единого гайда и отстутствие статической типизации? Я бы прежде всего назвал отсуствие явного лидера среди фреймворков, даже если брать чисто ентерпрайз сегмент — как минимум нужно будет делать выбор между Symfony и Zend.
Основная причина, как мне видится, — это слабый контроль за качеством кода со стороны компилятора и инструментов разработки, безопасность полностью ложится на плечи разработчика, нет единых интерфейсов и базы, на которую бы ложились существующие решения. Очень много возможностей прострелить себе ногу у PHP. Честно говоря, не хочу повторяться, об этом уже миллион раз говорилось, и языком гораздо богаче и литературнее, чем у меня :)
Symphony и Zend — прекрасные фреймворки, я не буду спорить. Но факт остаётся фактом, я практически не видел присутствия PHP в энтерпрайзе. Какие-нибудь корпоративные порталы не в счёт.
Symphony и Zend — прекрасные фреймворки, я не буду спорить. Но факт остаётся фактом, я практически не видел присутствия PHP в энтерпрайзе. Какие-нибудь корпоративные порталы не в счёт.
инструментов разработки
Вы просто о них не знаете. Они есть и используются повсеместно. Например: github.com/squizlabs/PHP_CodeSniffer
github.com/phan/phan
практически не видел
Опять же, это не означает что их нет. А они есть, поверьте.
Всё зависит от желания использовать средства контроля качества кода, как встроенные в референсную реализацию языка (например type hinting и strict режим), так и сторонние.
Решение использовать MySQL, а не MS SQL, вообще играет ничтожную роль. Если решение написано и ложится в рамки Entity Framework, то оно будет работать одинаково и на MS SQL, и на MySQL, и на Postgres, и на Oracle. Поэтому «C# разработчики отказываются» — это какая-то ересь если честно. Сегодня C# разработчики очень активно пользуются докер-контейнерами и активно дружат с кроссплатформенной разработкой.
Конкатенация точкой точно не то, что стоит обсуждать. Кажется в статических языках нет возможности (без рефлексии) собирать имена классов, методов, свойств из строк, включая пользовательский ввод и использовать их как обычные.
В PHP нет модулей, увы.
В PHP нет модулей, увы.
А откуда сразу условие — без рефлексии? :-)
А чем рефлексия не угодила? В C# есть dynamic, которые разрешают кастомные свойства и "использовать их как обычные".
<комментарий удалён>
Буки:
* PHP: объекты, шаблоны и методики программирования. Мэтт Зандстра
* Josh Lockhart Modern PHP. New Features and Good Practices
* ну и phptherightway.com (с кучей ссылок)
* PHP: объекты, шаблоны и методики программирования. Мэтт Зандстра
* Josh Lockhart Modern PHP. New Features and Good Practices
* ну и phptherightway.com (с кучей ссылок)
UFO just landed and posted this here
Sign up to leave a comment.
Путь разработчика ASP.NET → PHP