Забавно конечно читать про "большой вопрос", когда ООО "ПэйПал РУ" сидит с тобою в одном БЦ и находится здесь уже кажется 5+ лет. И так с очень многими, если не всеми сколько-нибудь крупными компаниями. Я если что все эти идеи роскомнадзора нисколько не поддерживаю, просто констатирую ситуевину.
Вероятно для него и еще некоторых языков, к цифре в заголовке статьи надо будет добавить 12, чтобы получилось 2037, а там уже киберпанк и вот_это_вот_всё ;)
Да, вы правильно заметили, с языками типо кобол или как выше в пример привели coq, очевидно, все будет значимо сложнее, но они и занимают относительно небольшую нишу на рынке.
С sql ИИ как минимум сможет «давать по рукам» за какие нибудь вложенные select-ы в реляционных базах, в общем стараться обезопасить от плохих практик / ошибок. Что-то наверняка будет автоматически оптимизироваться на уровнях слоев абстракций над БД, но опять же соглашусь с вами что в сложных случаях — надо будет действовать по старинке.
С обходом ошибок дело обстоит примерно так же, какие-то известные и повсеместно используемые воркараунды для ошибок — будут предлагаться, а что-то редкое и специфичное надо будет разбирать отдельно самостоятельно, без умных подсказок и автоматизации.
Таким образом — я считаю, что речь не идет о том, что разработчики станут не нужны, а лишь о том как в наиболее популярных кейсах максимально облегчить их работу. А высвободившееся время от работы над популярными/общими кейсами разработчики смогут направить как раз на специфичные оптимизации, фикс сложных кейсов совместимости со сторонним софтом и т.п.
Зря вы так, PHP очень стремительно развивается последнее время, но даже не принимая это во внимание статья не теряет своей актуальности, PHP в ней можно заменить на любой другой язык по желанию :)
Надеюсь депрекейтед нотисы помогут эту веселуху сгладить, но получается, это делает версию 7.4 обязательной для миграции, чтобы плавнее смигрировать на последующие версии. А само изменение хорошее, раньше было менее логично как по мне.
Ой как не хочется в текущем веку забывать про контейнеризацию. На VPS то ее кстати тоже вполне можно сделать. А про shared хостинги, придется извращаться, вы правы.
Почему вы думаете что прелоад будет слабо востребован? Что касается FFI то это инструмент, как мне видится, скорее для разработки библиотек нового уровня, там где требуются большие\сложные математические операции и т.д., то есть для машинного обучения и прочего.
Код заданный через FFI::cdef будет компилироваться условно каждый раз (но не забываем про оптимизации php). Так же есть возможность подгрузить код из C-header файла через FFI::load, но т.к. это занимает значительное время в RFC рекомендуется делать это 1 раз на старте приложения, а работу с FFI оформить через lazy load синглтон дающий доступ к FFI с заданным scope, при этом заранее скомпилировать opcache для него. Пример для второго подхода есть в секции RFC «A Complete PHP/FFI/preloading example».
>Единственное, от чего бы не отказался — это текстбокс поиска/выполнения, который встроен в таскбар.
Просто начните набирать что Вам нужно в момент когда Вы находитесь на «плиточном» экране.
2-е есть в официальном расширении от Google и некоторые другие фичи там тоже есть. Правда мне не совсем понятно почему бы всё это не интегрировать в сам браузер, а не поставлять отдельным расширением.
Сейчас так же. Не рекомендуется и программа сама отказывается открывать каталоги 3 версии, по выходу финала 4-й уже уверили в том что конвертация — будет.
Как мне видится это все во многом справедливо не только для qa senior-ов, но и для других ветвей IT
Забавно конечно читать про "большой вопрос", когда ООО "ПэйПал РУ" сидит с тобою в одном БЦ и находится здесь уже кажется 5+ лет. И так с очень многими, если не всеми сколько-нибудь крупными компаниями. Я если что все эти идеи роскомнадзора нисколько не поддерживаю, просто констатирую ситуевину.
коболили как выше в пример привелиcoq, очевидно, все будет значимо сложнее, но они и занимают относительно небольшую нишу на рынке.С sql ИИ как минимум сможет «давать по рукам» за какие нибудь вложенные select-ы в реляционных базах, в общем стараться обезопасить от плохих практик / ошибок. Что-то наверняка будет автоматически оптимизироваться на уровнях слоев абстракций над БД, но опять же соглашусь с вами что в сложных случаях — надо будет действовать по старинке.
С обходом ошибок дело обстоит примерно так же, какие-то известные и повсеместно используемые воркараунды для ошибок — будут предлагаться, а что-то редкое и специфичное надо будет разбирать отдельно самостоятельно, без умных подсказок и автоматизации.
Таким образом — я считаю, что речь не идет о том, что разработчики станут не нужны, а лишь о том как в наиболее популярных кейсах максимально облегчить их работу. А высвободившееся время от работы над популярными/общими кейсами разработчики смогут направить как раз на специфичные оптимизации, фикс сложных кейсов совместимости со сторонним софтом и т.п.
То есть теперь нет возможности сделать так:
FFI::cdefбудет компилироваться условно каждый раз (но не забываем про оптимизации php). Так же есть возможность подгрузить код из C-header файла черезFFI::load, но т.к. это занимает значительное время в RFC рекомендуется делать это 1 раз на старте приложения, а работу с FFI оформить через lazy load синглтон дающий доступ к FFI с заданным scope, при этом заранее скомпилировать opcache для него. Пример для второго подхода есть в секции RFC «A Complete PHP/FFI/preloading example».Просто начните набирать что Вам нужно в момент когда Вы находитесь на «плиточном» экране.