LINUX.ORG.RU
ФорумTalks

Проверка типов во время исполнения не нужна (РНР)

 


0

1

Собственно: https://stitcher.io/blog/we-dont-need-runtime-type-checks

Для Ъ: проверка типов во время исполнения в РНР достигает своего предела: дженериков нет и, вероятно, не будет в ближайшее время.

Подход 1: вынести работу с дженериками в отдельный статический анализатор (в общем: работать с дженериками не во время исполнения), но такой подход несёт одну проблема: часть кода проверяется во время исполнения, а часть статически.

Подход 2 можно попробовать проверять все типы исключительно статически, но это потребовало бы изменения самого языка (для отключения проверки типов во время исполнения):

Никита Попов:

I think that would be a good thing… but then again, lots of things would be different in PHP if we’d do a clean-slate redesign now. We have to work within the constraints we have, somehow.

Тем не мене, автор заявляет, что считает это достижимым.

Подход 3: использовать статическую проверку (но фактически другого языка) вместе с компиляцией в РНР (как делает тайпскрипт, но он компилирует в джаваскрипт). При чём опыт подобных программ уже есть.

So, this is where we are today:

* PHP's runtime type checker is reaching its limitations (generics being the most 
  obvious example)
* There are already runtime-ignored types (doc blocks), but there's no consensus 
  on syntax and usage across static analysis communities
* Runtime-ignored types require a mind-shift that many developers find difficult 
  at this point
* Transpiling PHP is possible, it's been done before, but it's a massive 
  undertaking and likely to fail again if tried without proper support
★★★

Последнее исправление: fernandos (всего исправлений: 1)

Плата за совместимость всегда высока. Зато php позволяет мигрировать проект с версии на версию с минимальными изменениями. Вероятно и rust в какой-то момент будет в той же позиции, как тот же C++ сейчас - только бы чего не сломать.

ixrws ★★★
()
Ответ на: комментарий от ixrws

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

fernandos ★★★
() автор топика
Последнее исправление: fernandos (всего исправлений: 1)
Ответ на: комментарий от ixrws

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

кмк, в языке давно пора не новые фичи релизить, а провести генеральную чистку как минимум уровня php4->php5

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

Ford_Focus ★★★★★
()
Ответ на: комментарий от Ford_Focus

проекты на пхп никуда не мигрируют, а остаются на одной и той же версии пхп

ЕМНИП, даже флюксбб поддерживает (или есть пулл-реквест) 8 версию пыха.

кмк, в языке давно пора не новые фичи релизить, а провести генеральную чистку как минимум уровня php4->php5

Я с вами соглашусь, но всё же некоторый функционал объявляют устаревшим, некоторый добавляют.

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

Спорно. Не думаю, что абсолютное большинство это поддержит, но лично мне это более чем интересно. Вот думаю как-то хак и кпхп пробовать тыкать.

fernandos ★★★
() автор топика
Ответ на: комментарий от fernandos

ЕМНИП, даже флюксбб поддерживает (или есть пулл-реквест) 8 версию пыха.

новые версии библиотек/фрэймворков/cms/etc поддерживают новые версии языка, но вот чтобы конечный сайт в production взял и переехал на новую версию - большая редкость, если это не делается в несколько кликов в админках

Я с вами соглашусь, но всё же некоторый функционал объявляют устаревшим, некоторый добавляют.

«дизайн» языка остался на том же месте со всеми его проблемами со времён php5. Двойная парадигма, неконсистентность в параметрах функций, и зоопарк функций вместо методов объекта - всё на месте

Кмк, провал php6 как-то слишком сильно подкосил боевой дух core team

Вот думаю как-то хак и кпхп пробовать тыкать

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

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

Ford_Focus ★★★★★
()
Ответ на: комментарий от Ford_Focus

новые версии библиотек/фрэймворков/cms/etc поддерживают новые версии языка, но вот чтобы конечный сайт в production взял и переехал на новую версию - большая редкость, если это не делается в несколько кликов в админках

Это да.

«дизайн» языка остался на том же месте со всеми его проблемами со времён php5. Двойная парадигма, неконсистентность в параметрах функций, и зоопарк функций вместо методов объекта - всё на месте

Мне кажется, это не самая большая проблема. Вот тот факт, что нет поддержки юникода на низком уровня прямо смущает.

Кмк, провал php6 как-то слишком сильно подкосил боевой дух core team

ИМХО, jit этот дух поднял. Шестая версия де-факто была, просто в ней не была реализована часть функционала.

очень жаль, что массово оно так и не взлетело

Действительно жаль, вне своих компаний оно особо не популярно.

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

Это скорее из любопытства, но спасибо за совет.

fernandos ★★★
() автор топика
Ответ на: комментарий от Ford_Focus

Ох уж эти любители говорить за всех. У нас проекты с 5 версии спокойно мигрировали сначала на 7, теперь на 8. Никаких особых проблем не встретили. Часть зависимостей слегка поломалось, что-то поправили сами, потому что держим значительную часть зависимостей прямо в проектах чтобы как раз таки ничего не ломалось никогда. Часть нашего кода поломалось. Но в целом это минимальные, легко устранимые поломки. В этом плане разработчики php молодцы.

Что до проектов, где никогда ничего не обновляют, то это не только php так, это вся индустрия так живёт. Сталкивались с подобным и в Java, и в С++, и даже в последних angular с typescrypt.

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

Абсолютному большинству php разработчиков глубоко плевать на то как быстро будет работать php, потому что база всё равно работает медленее. php уже давно вполне себе шустрый и хоть вряд ли бы люди были бы против, чтобы он догнал С, этого не будет никогда, просто потому, что для этого его надо сделать либо как С, либо как Caml. Но тогда все плюсы php исчезнут.

ixrws ★★★
()
Ответ на: комментарий от ixrws

Часть нашего кода поломалось. Но в целом это минимальные, легко устранимые поломки

звучит так, как будто у вас там свой (не)велосипед и вы регулярно мигрируете на новую версию языка. Звучит хорошо, но в пхп-мире это скорее редкое исключение, но никак не правило

На кой оно кому надо?

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

Брать пхп для, например, crud api уже сегодня ну такое себе решение, а за пределы вэба он никогда особо и не выкатывался в виду своей узкой специализации прямо на уровне языка

Абсолютному большинству php разработчиков глубоко плевать на то как быстро будет работать php, потому что база всё равно работает медленее

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

В зависимости от количества данных, там где пхп нужно было 20-30 минут, шарп теперь справляется за 10-20.

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

но да, я согласен, что пхп почти не тормозит на фоне бидона (который был взят изначально и тратил на ту же задачу 90-130 минут)

Ford_Focus ★★★★★
()
Последнее исправление: Ford_Focus (всего исправлений: 5)
Ответ на: комментарий от Ford_Focus

ни разу не было бы против, если бы пхп9 стал компилируемым языком со строгой статической типизацией

Зачем он? Эта ниша занята c#, Java и ещё пачкой менее распространённых

cobold ★★★★★
()
Ответ на: комментарий от cobold

не так уж сильно занята, на самом деле. и у них там свои тараканы

Ford_Focus ★★★★★
()
Ответ на: комментарий от no-such-file

Есть что? Вы статью вообще читали?

fernandos ★★★
() автор топика
Ответ на: комментарий от Ford_Focus

проекты на пхп никуда не мигрируют

Мигрируют. А как иначе, ставить старый неподдерживаемый пых на новую ос?

пхп9 стал компилируемым языком со строгой статической типизацией

Уже есть Го. Зачем нам второй Го. Парсинг какого-нибудь json или слишком громоздкий в статической типизации, или же по факту делается, как в динамической. ПХП хорош, как он есть.

goingUp ★★★★★
()
Ответ на: комментарий от goingUp

Мигрируют. А как иначе, ставить старый неподдерживаемый пых на новую ос?

докер же. еще можно скомпилять статически в /opt, но лучше докер

Уже есть Го. Зачем нам второй Го

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

да и парсинг жсона в том же шарпе таки не вызывает полыхание пердака

Ford_Focus ★★★★★
()
Ответ на: комментарий от Ford_Focus

докер же. еще можно скомпилять статически в /opt, но лучше докер

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

го - язык-кастрат

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

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.