Pull to refresh
4
0
Негрей Сергей @snegprog

Пользователь

Send message

Описанное вами круто, фантастично, так все и должно быть и вурен что будет! Но в статье, на сколько я понял, про попытку заменить мыслительный процесс роботом (ИИ), а это сбор информации от человека, а не от датчиков. И все идет к тому, что информации (мыслей) от человека в ИИ поступать (такими темапми) скоро не будет.
*сбор информации с камер, это не мысли человека. Среди фильмов много шлака (есть и хорошие, но их данные перебьют плохие, т.к. их больше) на которых не стоит обучаться. А потом фильмы будут генериться самим ИИ и никаких новых данных не будет (как и книги будет генерить ИИ). Думаю в данной статье про это.

Вот и я всем говорю "Если так дальше и пойдет, стоимость оригинальных решений вырастет в разы!"
ИИ это прогресс (и от него не уйти), который легко может превратиться в регресс.

Цель статьи дать направление и вкратце рассказать для чего статические анализаторы вообще нужны.

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

PHPStan можно интегрировать с PHPStorm, как это сделать лучше читать документацию к данной IDE. С вс код вероятно тоже есть интеграция, но точно ничего не скажу.

Да, пет-проект это круто, но что делать если увлечен своим проектом на работе (тоже работаю в "МТС Диджитал"), бывает засиживаешься до глубокой ночи или встаешь вместе с петухами и новыми мыслями как реализовать какую-то фичу, подписан на хабр, на несколько телеграмм каналов, читаешь различные статьи по разработке, читаешь книги, НО при этом нет пет-проекта, просто не хватает времени, сил и просто не видишь необходимости т.к. все свои мысли имеешь возможность реализовать на работе. Это значит я не увлеченный человек?

Так на сколько знаю Никите просто нравится Rust и он уже давно контрибьютит и туда. Просто человеку захотелось развития как личности, Rust совсем другие принципы нежели PHP, Java, Go или NodeJS

Первое что приходит в голову, это обработка больших объемов данных, на собеседовании кажется об этом речь и шла, допустим необходимо обработать большую (по объему) таблицу БД имея маленький доступный объем оперативной памяти.
Но я даже не об этом, а о том, что кто то даже не знает что есть в пыхе и плохо понимает что на самом деле в этом языке не так, восхищаясь другими языками не зная что и там есть проблемы.
Как раз про это и говорил, что проблема в людях, а не в языке!
Многие ведь как, когда наслушаются как все круто в другом языке, особенно когда вокруг него много хайпа (Допустим в Java и C# отсутствует множественная наследовательность и сделали это намеренно т.к. с ней много проблем, но она есть в Python вокруг которого много хайпа, в итоге у Дмитрия Стогова спросили «когда будет в PHP множественная наследованность?», на что он четко ответил «Никогда» (слава богу)) столкнувшись с какой то не стандартной задачей начинают думать о другом ЯП.
Пример из жизни — был как то на собеседовании, не помню точный вопрос, но вспомнил про yield и начал рассказывать про генераторы, на что собеседующий сказал «мы сейчас говорим о PHP, а не о Python»! Как Вы думаете, какая была моя реакция и кого винить за незнание ЯП, сам ЯП или человека? Напомню, генераторы появились еще в PHP 5.
Вот и говорю, проблема не в языке, проблема в людях. И людей которые знают только то, с чем работают очень много и не только в PHP, но не надо за это винить ЯП.
Поддерживаю обоими руками!!!
Проблема не в языке, проблема в людях. Если за 10 лет так и не понял принципы работы ЭВМ, то это не проблема языка.
Возможно где то стоит упомянуть, что это перевод статьи nikic.github.io/2012/12/22/Cooperative-multitasking-using-coroutines-in-PHP.html
?
Читал как то статью на хабре, где автору не нравится во что превращается PHP.

А я скажу, что прям в точку все попадает, и «Возвращаемый тип static » и "$object::class" и "?->", да и много других вещей, так не хватало в PHP, не раз сталкивался с такой необходимостью, теперь код можно будет писать более чисто, без личшних замудренностей!
Почти каждый обсуждаемый для PHP 8 RFC несет одну и ту же проблему — нарушение ранее сложившейся системы языка. И это плохо. Это ломает мозг и тем, кто пишет на PHP давно, и тем, кто только начинает его изучать.

Мир меняется, мир уже не такой как был в 2004 году! Так в нишу PHP пришел Phyton, а пришол он как раз потому, что PHP долго стоял на месте! Сейчас, если PHP так же и останется в 2004 году, то не долго осталось ждать до его смерти, я в этом убежден!

Далее добавляем понятие «замыкания». …

Замыкание— функция первого класса, в теле которой присутствуют ссылки на переменные, объявленные вне тела этой функции в окружающем коде и не являющиеся её параметрами. Говоря другим языком, замыкание — функция, которая ссылается на свободные переменные в своей области видимости.
Т.е. это функция с доступными ей переменными из внешнего пространства. В PHP переменные из внешнего пространства в анонимную функцию мы передаем с помощью оператора use, поэтому анонимную функцию и называют замыканием.

А дальше у нас появляются стрелочные функции. И это ломает всё.

Все что сделали, так это убрали use и сделали доступными переменные из внешнего пространства по умолчанию, при этом само внешнее пространство стрелочная функция не меняет.

Где «доллар»? Нет.

Как много ругани я читал про то, что PHP плохой язык именно из за знака $, к константам без знака $ как то привыкли.

это новые match-expressions. Можете объяснить, почему в них используется символ "=>", а не привычный по switch-case ":"? И я не могу.

А разве switch-case удалили или объявили как deprecated? Это просто новая конструкция, если вы не хотите применять новые конструкции, то никто вас и не заставляет.

Ну а далее могу просто сказать — можно меняться в угоду привычкам, а можно меняться в угоду лучших решений. Изменения принимаются путем обсуждения, споров и голосования!
Да, возможно что то лишнее появляется и непонятное, но
  1. Это больше дело привычки, человеку всегда сложно отказываться от старых привычек и завести новые
  2. А может стоит сейчас попробовать как можно больше, посмотреть эффективность тех или иных инструментов, исправить ошибки, а потом вычистить все от хлама? Только ведь пока не попробуешь сложно понять что хлам, а что нет

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

Я об этом.

Ну а если глубже капнуть, то да, слабая и сильная типизация.
Это обширный вопрос, но в PHP (как уверен и в других языках с такой типизацией) достаточно много проблем как раз из за динамической типизации, поэтому type hinting и strict_types добавили (как написал выше, язык развивается, кто участвует в его разработке о таких проблемах явно знают и явно стараются их закрыть не повторяя ошибок других ЯП).

Не буду вдаваться в технические подробности почему статическая типизация лучше динамической, а логическая проблема в следующем — легче выстрелить себе в ногу, допустим когда определил переменную как int, далее переопределил её как string, а потом обратился к этой переменной как к int, теоретически это возможно и сделать такое может любой программист (особенно в больших проектах, поэтому в них как правило Java используют, а не PHP), не нарочно. Если так случайно сделаете, то в языках со статической типизацией приложение у вас просто упадет и вы будете знать об этом, а в языках с динамической типизацие приложение продолжет работать с ошибкой и вы об этом узнаете только когда компания попадет на круглую сумму.

Здесь дальше можно разговарить о компиляции и о статических анализаторах (котрые я немного упомянул в этой статье, это реально крутая вещь!), но это уже отдельная и большая тема.
Сейчас JS очень популярен, так там проблем еще больше, с ним я дружу и считаю имею право так говорить. Та же проблема с типизацией, даже больше, (TypeScript если только рассматривать как замену), классы появились только в ES6 который еще не везде поддерживается и если не ошибаюсь больше является синтаксическим сахором, т.к. JS это прототипное ООП и т.п.
Java — излишне сложен и JVM как правило ресурсоемок, опыт с данным языком так же имеется.
Phyton — популярен, та же динамическая типизация, думаю там такие же проблемы присутствуют. Не знаю как сейчас, но раньше если обновляешь ядро OS Linux, то часто phyton просто переставал работать и соответственно приложения написанные на нем просто падали.
Golang — крутой язык, но как на нем написать например CRM, которую можно написать на PHP и легко поддерживать, не представляю.
C#, Rust, Scala — если не ошибаюсь вообще другая сфера применения нежели у PHP. Конечно и на них можно что то для WEB написать, но стрелять из пушки по воробьям!? Ну а брокеры очередей, базы данных и т.п. пока у меня небыло необходимости писать.

Почему PHP:
1. Я им владею
2. Некоторые вещи реализовывать значительно проще нежели например на Java
3. Язык хорошо развивается
4. Согласно бэнчмаркам php 7.4 уже показывает хорошие результаты, а в конце года ожидается выход php 8
4. Большой выбор уже готовых библиотек и готовых решений проверенных временем.

Поэтому какой язык вы считаете более продвинутым пока непонятно. Думаю просто сказать «используй только этот язык и никогда не используй вот этот» будет не правильно! Но это очень холиварная тема и думаю не стоит продолжать ее здесь обсуждать, просто написал почему я выбираю для некоторых своих проектов PHP.
Да, просто побыстрее хотелось написать про такую возможность, от части на эмоциях была написана статья. Примеров внедрения и как это помогло нашей команде достаточно много, просто надо больше времени уделить написанию статьи и думаю получится достаточно интересно.

Еще раз спасибо, именно такую помощь на хабре и хотел увидеть! Надеюсь я Вас услышал.
PS: Скажу больше, без использования подобных инструментов php слабый язык программирования (хотя я его очень люблю, поэтому и рассказал про такие инструменты), т.к. прощает ошибки, например когда объявил переменную в одном регистре, а при обращении соучайно напутал регистр одного из символов в названии переменнтой, то тебе выдаст что то типа «PHP Notice: Undefined variable:» и код продолжит работать, хотя ты думаешь что обратился к переменной в которой уже есть какое то значение. А эти инструменты позволяют найти подобные ошибки, когда человеческий взгляд может их пропустить.
Решил поделиться инструментами которые на порядок облегчают жизнь программиста и на порядок лучше находят ошибки в коде чем человеческий взгляд (проверено на практике), НО минусов пока больше, наверное ничего не стоят эти инструменты, зачем их только разрабатывают когда есть человеческий, предвзятый и уставший, взгляд. Два человека спасибо сказали, так и их заминусовали. Более того, ведь никто не заставляет вас и никого другого их использовать, а если и захотите использовать, так в любом случае потребуется разобраться со всем этим, здесь только озвучена такая возможность.
Странно.
Спасибо, надеюсь я Вас услышал, просто очень часто слышу, что при code rewiev проверяется как раз единообразие code style, производится поиск синтасических ошибок и т.п.
Если вы настраиваете линтер/форматтер, и человеку этим заниматься не надо – значит, вы убрали этот момент из code review, и ревьюер может заниматься другими задачи, которые входят в code review. И вот как раз из этих других задач и складывается сложность code review.

Статья наверное больше об этом, об исключении из code rewiev моментов которые можно автоматизировать.

Information

Rating
9,356-th
Date of birth
Registered
Activity