forum.opennet.ru - "Началось альфа-тестирование PHP 8.1" (140)

"Началось альфа-тестирование PHP 8.1"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Началось альфа-тестирование PHP 8.1"	+/–
Сообщение от opennews (ok), 13-Июн-21, 09:40
Представлен первый альфа-выпуск новой ветки языка программирования PHP 8.1. Релиз намечен на 25 ноября. Основные новшества, уже доступные для тестирования или планируемые к реализации в PHP 8.1:... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55322
Ответить \| Правка \| Cообщить модератору

Оглавление

Так и до хвостовой рекурсии недалеко , lockywolf (ok), 09:40 , 13-Июн-21, (1) +1
А оно ещё живо Кто-то на этом пишет , Qwerty (??), 09:46 , 13-Июн-21, (2) –38

Посмотри вакансии, дурачок Люди получают неплохие деньги , Mad max (?), 10:06 , 13-Июн-21, (4) +12

Ну да больше 0 это неплохой результат , Аноним (11), 10:51 , 13-Июн-21, (11)
Лучше задумайтесь почему так много этих вакансий , КО (?), 10:54 , 13-Июн-21, (13)

Легаси допиливать , Аноним (15), 11:45 , 13-Июн-21, (15) +4
Потому что джава - сильно жЫрно, плюсЫ - громоздко, а питон - медленно, Lex (??), 14:09 , 13-Июн-21, (28) +6

А ещё потому что PHP стал мейнстримом для dynamic web в нужное время и для нег, Aukamo (ok), 14:28 , 13-Июн-21, (29) +3

Аналогично От php восторга не испытываю, но в своем сегменте ему нет равных Ja, Плюсовик (?), 15:00 , 13-Июн-21, (34) +1

- чепуха, MVK (??), 10:42 , 15-Июн-21, (121) –1

Совсем не чепуха Большая часть функционала PHP реализуется C , а вот Java отда, Аноним (130), 16:47 , 15-Июн-21, (130) +1

всё проблемы конкретной реализации, то другой в общем то нет , Аноним (130), 16:48 , 15-Июн-21, (131) +1
- интересно, но объясните тогда почему тогда PHP так нуждается в различных кэшах, MVK (??), 11:24 , 17-Июн-21, (141)

Потому, что базы данных не умеют толково кешировать запросы Не видел ни одного б, Аноним (130), 12:42 , 17-Июн-21, (142)

- на PHP не могут, а на Java могут Ах, да там же есть транзакционный и L2 кэши-, MVK (??), 13:18 , 17-Июн-21, (143)

Он уже давно вполне себе язык , pda (ok), 17:03 , 13-Июн-21, (41) +6

Можно подумать, Ларавель, Вордпресс и прочие поделия - это быстро Да на Питоне , starlette (?), 15:33 , 13-Июн-21, (35) –3

Вот только одна проблема на PHP таки написано А на питоне лет двадцать всё те ж, Онаним (?), 16:08 , 13-Июн-21, (39) +9

Лучше бы вообще не писали Ни на одном языке не написано столько откровенной дря, Аноним (113), 03:24 , 15-Июн-21, (113) –1

а ты конечно лично каждую строку проверил, написанную каждым школьником на бейси, z (??), 12:56 , 15-Июн-21, (126)

Приведи аналоги Laravel, WordPress, Symfony для Python Django да и все Остальн, Плюсовик (?), 18:52 , 13-Июн-21, (48) +1

Их нету, поскольку такую кучу г-на только на похапе написать и можно , Аноним (115), 03:48 , 15-Июн-21, (115)

Видал я тут на Flask админку к базе одной популярной СУБД Описывать можно тольк, Плюсовик (?), 18:58 , 13-Июн-21, (49) +3

Если бы существовали альтернативы, предоставляющие, хотя бы, тот же уровень возм, Аноним (25), 13:04 , 13-Июн-21, (25) +7
Пишу сейчас бэк на типскрипт, лучше бы на пыхе симфони писал, ананоша (?), 13:48 , 13-Июн-21, (26) +3

ОбоснуйUPD помимо того что там бывают ситуации с типами данных, мягко говоря, н, Aukamo (ok), 14:29 , 13-Июн-21, (30) –1

Не вижу гибкого мейнстримного фреймворка уровня симфони, на который не забьют че, ананоша (?), 17:04 , 13-Июн-21, (42) +3

NestJS, Аноним (43), 17:41 , 13-Июн-21, (43)

Только typeorm брать не надо, его автор вообще не в курсе, что такое ORM, и года, Аноним (69), 23:15 , 13-Июн-21, (69)
Это который пилится одним поляком , ананоша (?), 02:45 , 14-Июн-21, (75) +1

Точно так же, как Symfony пилится одним французом давно уже нет , Аноним (69), 05:51 , 14-Июн-21, (77) –1

Express , Ненавижу SJW (?), 21:20 , 13-Июн-21, (59) –1

Экспресс низкоуровневый Это скорее сравнимо с компонентами Symfony HttpFoundati, Аноним (69), 23:08 , 13-Июн-21, (67) +1
Ну да, его и используем конечно же Страшная вещь , ананоша (?), 02:47 , 14-Июн-21, (76) +1

Blazor гы-гы-гы , а вообще Angular, Аноним (97), 14:54 , 14-Июн-21, (97)
И это всё что не нравится в TS Просто отсутсвие какого-то более менее долгоживу, Aukamo (ok), 17:39 , 15-Июн-21, (133)

Статический анализатор в PHP настолько беспомощен, что не может понять, что в фу, Аноним (3), 09:54 , 13-Июн-21, (3) –4

Нет нельзя Надо было обязательно слепить что-то среднее между enum ом и switch , Аноним (5), 10:14 , 13-Июн-21, (5) +1
Подозреваю что лексер они сильно переусложнять не хотели, поэтому взяли синтакси, Варенье (?), 10:40 , 13-Июн-21, (9) –3
Если ты вызываешь из кода php функцию на C, которая прерывает выполнение програм, Ordu (ok), 10:47 , 13-Июн-21, (10) +6

а смысл тогда в статическом анализаторе для языка который по факту является обер, Sw00p aka Jerom (?), 13:39 , 14-Июн-21, (95)

Я даже не знаю что сказать на это Что значит язык является обёрткой другого яз, Ordu (ok), 14:51 , 14-Июн-21, (96) +1

Вот что значить вот это Если ты вызываешь из кода php функцию на C пхепешный , Sw00p aka Jerom (?), 17:13 , 14-Июн-21, (100) –1

Эмм Любой язык, кроме ассемблера, становится обёрткой, если следовать такому , Ordu (ok), 18:21 , 14-Июн-21, (102)

Ну да Опять задам парочку уточняющих вопросов, ибо не ясно, что значит анализ к, Sw00p aka Jerom (?), 01:32 , 15-Июн-21, (108) –1

if a b бла-бла-бла Это есть потенциальная ошибка С точки зрения статическо, Ordu (ok), 03:20 , 15-Июн-21, (112)

Что еще ожидать от недоразвитых вебмакак неспособных даже написать помощьный ста, Аноним (80), 09:25 , 14-Июн-21, (80)
Статический анализатор в динамическом языке Печалька Оно вообще может управлен, Онаним (?), 10:07 , 14-Июн-21, (81) +1

квадратные скобки лишние, сорян, Онаним (?), 10:07 , 14-Июн-21, (82)
в php вообще-то есть статическая типизация для аргуметов функций и полей классов, Аноним (80), 10:37 , 14-Июн-21, (84)

Там скорее тайпчек частично на этапе трансляции, а в основном - в рантайме , Онаним (?), 12:07 , 14-Июн-21, (89)

потому что не для констант и предсказуемых вызовов финальный тип становится изв, Онаним (?), 12:08 , 14-Июн-21, (90)

ну то есть к реальной статический типизации это имеет слабое отношение, хотя ча, Онаним (?), 12:10 , 14-Июн-21, (91)

Блин аааа, мою портянку выше можно было уместить в ваши две строчки , Sw00p aka Jerom (?), 01:42 , 15-Июн-21, (109)

кошмар делали user-friendly C, а получился вырвиглазный Rust , onanim (?), 10:36 , 13-Июн-21, (7) –22

Ставил минус ибо не понял при чём тут Rust, вообще , Aukamo (ok), 14:33 , 13-Июн-21, (31) +4

Тоже минус Лучшего синтаксиса мои глаза не видели , Аноним (33), 14:40 , 13-Июн-21, (33) –1

но лучше чем питон, СССР (?), 23:24 , 13-Июн-21, (70) +3
Делали шаблонизатор для домашних страниц, а получился язык для говнокодинга , Аноним (113), 03:27 , 15-Июн-21, (114) +1

начиная с 7ой версии пых стал довольно неплох , onanim (?), 11:51 , 15-Июн-21, (125)

У меня на 5-6 версиях сформировался такой рвотный рефлекс, что до сих пор рефлек, Aukamo (ok), 17:25 , 15-Июн-21, (132)

Шашечки или ехать Язык как был, так и остался строго прикладным Его пытаются с, Онаним (?), 10:16 , 16-Июн-21, (135)

Пока статическую типизаицю не введут, плюс не поставлю Но они не введут И уже н, InuYasha (??), 10:39 , 13-Июн-21, (8) –10

Это сегрегация все типы должны иметь равные возможности , Аноним (11), 10:53 , 13-Июн-21, (12) +2

И делить на ноль надо разрешить, оскорбление нуля , Аноним (15), 11:46 , 13-Июн-21, (16) +2

Никто не мешает добавить число бесконечность беззнаковый, как в сфере Римана и, anonymous (??), 12:27 , 13-Июн-21, (20)

Деление на 0 не равно бесконечности Деление на 0 просто не имеет смысла по опре, Da (?), 03:10 , 15-Июн-21, (111)

Просто мы еще чегото не знаем о окружающем нас мире , ыы (?), 11:41 , 15-Июн-21, (124)

а че тут такого, этоже по факту функция рандома , Sw00p aka Jerom (?), 15:40 , 13-Июн-21, (37)
Тогда вам нужен APL, правда там только 0 0 даст 1 Но все же хоть какая то , Ag (ok), 19:47 , 13-Июн-21, (54) +1
В Джаваскрипте можно делать на 0 будет Infininty Можно даже стринг поделить на , Аноним (85), 10:38 , 14-Июн-21, (85) +1

Ага, ровно до тех пор пока не всрёшься с такими приколами , mr.Clin (?), 00:02 , 15-Июн-21, (107)

Так Ноль или Нуль , 1 (??), 10:10 , 15-Июн-21, (120)

PHP - язык с динамической типизацией изначально, и будет таковым Меня например д, Онаним (?), 12:51 , 13-Июн-21, (22) +1

PHP язык со слабой неявной динамической типизацией Хотя нужно это только для со, Аноним (85), 10:43 , 14-Июн-21, (87) +1

Да и для собеседования не особо нужно, но таки да Кстати половина режется на опт, Онаним (?), 12:05 , 14-Июн-21, (88)
Ты слабую с нестрогой не перепутал Си 8212 язык со слабой типизацией, напр, Здрасьте (?), 07:57 , 15-Июн-21, (116)

Дык ввели 171 Си 187 называется Можешь поставить ему плюсик и начинать коди, Lex (??), 17:57 , 13-Июн-21, (45) +6

Хорошая идея, одобряю , Аноним (99), 16:27 , 14-Июн-21, (99) +4

Так давно уже https cppcms com, InuYasha (??), 10:16 , 16-Июн-21, (134)

А не проще ли с таким синтаксисом писать сразу на статически типизируемом языке , Аноним (14), 11:33 , 13-Июн-21, (14) +1

Опять со своим руби лезут , acroobat (??), 11:54 , 13-Июн-21, (17)

А ты не завидуй , Аноним (18), 12:03 , 13-Июн-21, (18) –2

Проще Собственно писать на PHP никто за хвост никого не тянет - но на нём пишет, Онаним (?), 12:53 , 13-Июн-21, (23) +3

Миллионы мух На баше тоже много написано, но это вообще ни о чем не говорит , Аноним (46), 18:25 , 13-Июн-21, (46) –7

Говорит О том, что он удобен для своих задач В отличие от хипстерских поделок со, Онаним (?), 19:19 , 13-Июн-21, (50) +4
У меня сайт на баше Вообще не вижу проблемы , Annoynymous (ok), 10:31 , 14-Июн-21, (83) –1

На нем пишется очень много промолчу что он простой все ошибки умирают вместе с, Аноним (104), 22:13 , 14-Июн-21, (104)

убей все ошибки только за этот символ я его пых ненавижу , Sw00p aka Jerom (?), 01:48 , 15-Июн-21, (110)

Просто не надо сверх меры применять, где не надо Оно не зря существует в C вы в, Онаним (?), 13:33 , 15-Июн-21, (128)

отлично, одно реальное применение, во время отладки, согласен помогает, временно, Sw00p aka Jerom (?), 22:12 , 17-Июн-21, (145)

Впрочем, в восьмёрке некоторые файловые операции теперь стреляют эксепшнами, , Онаним (?), 13:36 , 15-Июн-21, (129)

is_file кстати плохой бойлерплейт Надо почему в список вопросов новичкам в, Онаним (?), 10:19 , 16-Июн-21, (136)
через error_handler можно как игнорировать, так и выбрасывать исключения если фу, Sw00p aka Jerom (?), 22:18 , 17-Июн-21, (146)

Разработка на ЯП с статической типизацией - медленнее чем на ЯП с динамической, , Skynin (?), 19:38 , 13-Июн-21, (53) –1

Я бы поспорил, сильно зависит от задачи и от языка На том же хаскеле добавление, Рева RarogCmex Денис (?), 21:05 , 13-Июн-21, (57)

Автовывод типов не делает ЯП с статический типизацией языком с динамической типи, Skynin (?), 07:36 , 14-Июн-21, (79) +1

Вау Накотец-то, ей-богу У меня давно есть где их применить, очень много где , Онаним (?), 12:38 , 13-Июн-21, (21) +2

честно говоря задолбался писать обёртки вокруг разных селектов сокетов и прочих, Онаним (?), 12:53 , 13-Июн-21, (24)

Я не пхп-шник, но всякие селекты и прочие функции которые ожидают события в ядре, Аноним (60), 21:29 , 13-Июн-21, (60) +1

Всё так Речь исключительно про либо неблокирующие вызовы, либо очень малый тайм, Онаним (?), 22:11 , 13-Июн-21, (61)
По сути fread fwrite на стримах вполне себе может быть неблокирующий, включа, Онаним (?), 22:29 , 13-Июн-21, (64)

Вот только помимо самих файберов нужна реализация асинхронного апи в PDO, ext cu, Аноним (69), 23:13 , 13-Июн-21, (68)

Ну, указанные уже есть Судя по тому, что они отдельно parallel с файберами тести, Онаним (?), 23:55 , 13-Июн-21, (71)

так закопали треды же вроде https github com krakjoe pthreads, Gemorroj (ok), 13:27 , 14-Июн-21, (93)

Совместимость с parallel тем не менее уже тестировали Собственно от parallel , Онаним (?), 13:31 , 14-Июн-21, (94)

Ещё даже без I O - всякие шедулеры событий офигенно ложатся на файберы Можно од, Онаним (?), 22:31 , 13-Июн-21, (65)

Ученые покусали редакторов опеннета Под распараллеливанием надо понимать non-b, Аноним (27), 13:53 , 13-Июн-21, (27) +2

Там нет параллельного исполнения вообще, кстати Там кооперативное исполнение бло, Онаним (?), 16:10 , 13-Июн-21, (40)

Так на пхп и пишут код, который большую часть времени ожидает ввода-вывода - нап, Аноним (43), 17:45 , 13-Июн-21, (44)

Пхп в принципе норм, окромя отсутствием обратной совместимости , Аноним (38), 16:03 , 13-Июн-21, (38)

Тогда и node js норм , Аноним (46), 18:28 , 13-Июн-21, (47)

duktape - нормА node js - это не язык , Онаним (?), 19:27 , 13-Июн-21, (51) –1

и не его реализация V8 - тоже норм, Онаним (?), 19:27 , 13-Июн-21, (52)

Ну и синтаксис, жесть И ещё говорят, что пхп прост для новичков, Аноним (55), 20:55 , 13-Июн-21, (55)

Порог вхождения в PHP уже давно за пределами новичкового Просто сохранившееся ст, Онаним (?), 22:13 , 13-Июн-21, (62) +2

Новички уже совсем не те Раньше смузи не пили, потому и вкатывались в инженерны, Аноним (38), 22:32 , 13-Июн-21, (66) +2

С другой стороны синтаксис в общем виде C-подобен, поэтому если есть опыт с C, и, Онаним (?), 22:14 , 13-Июн-21, (63) –1

По жизни с пятисотками Я сомтрю, доброта через забор переливается, если ты жел, InuYasha (??), 22:44 , 16-Июн-21, (137) –1

Ну я ж говорю, для привыкших к тому, что их компилятор за ручку водит - не годит, Онаним (?), 09:16 , 17-Июн-21, (139) –1

У вас, пыхарей, наверное, две жизни И одну из них вы тратите на санацию аргумен, InuYasha (??), 10:11 , 17-Июн-21, (140) –1

Санацию пользовательского ввода, если точнее И привычка очень хорошая Можете на, Онаним (?), 13:32 , 17-Июн-21, (144)

Интересно, такими темпами PHP дорастёт до Хаскеля или даже выше Когда зависимые, Рева RarogCmex Денис (?), 20:59 , 13-Июн-21, (56) –1

Уже давно перерос если сравнивать количество проектов в т ч новых с применением , Lex (??), 21:18 , 13-Июн-21, (58)

Вот только качество и количество это разные вещи xD, Аноним (101), 17:51 , 14-Июн-21, (101) –1

Применительно к ЯП - нет Даже наоборот - фактически, бОльшее количество говорит, Lex (??), 11:28 , 15-Июн-21, (122)

Эти два языка создавались для выполнения разных задач и идут разными путями Это , Плюсовик (?), 10:42 , 14-Июн-21, (86)

Как жы я это пропустил-тоА можно ещё 0_o и 0_O , Онаним (?), 23:57 , 13-Июн-21, (72) +2

О0о0O, Аноним (73), 00:41 , 14-Июн-21, (73)
Да _O_ , Аноним (73), 00:41 , 14-Июн-21, (74) +2

Это только для маководов , Led (ok), 12:53 , 14-Июн-21, (92) +7
это для местных анонимных коментаторов, Аноним (80), 15:11 , 14-Июн-21, (98)

Можно так 0_0 подчерк 8212 допустимый разделитель в числах , Здрасьте (?), 07:59 , 15-Июн-21, (117)

0_0 да, но оно не отражает всех моих эмоций, особенно при использовании восьмери, Онаним (?), 08:19 , 15-Июн-21, (118) +1

Помянем , Аноним (103), 21:04 , 14-Июн-21, (103) +1
Автор Исправь листинги Не нужны эти 4 пробела спереди строк И также используй, Уася (?), 23:16 , 14-Июн-21, (106)
В vardump е a 0 не потерялось , Аноним (119), 08:39 , 15-Июн-21, (119)

Его заменило a 1 , Аноним (123), 11:38 , 15-Июн-21, (123) +1
Не, всё ок Одинаковый ключ, значение заменяется на последнее , Онаним (?), 13:29 , 15-Июн-21, (127)

PHP для богов, АнонимнаяЗалупа (?), 04:21 , 17-Июн-21, (138) +1

Сообщения [Сортировка по времени | RSS]

1. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от lockywolf (ok), 13-Июн-21, 09:40

>Появился новый тип "never", который можно использовать для информирования статических анализаторов о том, что функция прекращает выполнение программы, например, вызывая исключение или выполняя функцию exit.
Так и до хвостовой рекурсии недалеко.

Ответить | Правка | Наверх | Cообщить модератору

2. "Началось альфа-тестирование PHP 8.1" –38 +/–

Сообщение от Qwerty (??), 13-Июн-21, 09:46

А оно ещё живо? Кто-то на этом пишет?

Ответить | Правка | Наверх | Cообщить модератору

4. "Началось альфа-тестирование PHP 8.1" +12 +/–

Сообщение от Mad max (?), 13-Июн-21, 10:06

Посмотри вакансии, дурачок. Люди получают неплохие деньги.

Ответить | Правка | Наверх | Cообщить модератору

11. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Аноним (11), 13-Июн-21, 10:51

Ну да больше 0 это неплохой результат.

Ответить | Правка | Наверх | Cообщить модератору

13. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от КО (?), 13-Июн-21, 10:54

Лучше задумайтесь почему так много этих вакансий.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

15. "Началось альфа-тестирование PHP 8.1" +4 +/–

Сообщение от Аноним (15), 13-Июн-21, 11:45

Легаси допиливать?

Ответить | Правка | Наверх | Cообщить модератору

28. "Началось альфа-тестирование PHP 8.1" +6 +/–

Сообщение от Lex (??), 13-Июн-21, 14:09

Потому что джава - сильно жЫрно, плюсЫ - громоздко, а питон - медленно

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

29. "Началось альфа-тестирование PHP 8.1" +3 +/–

Сообщение от Aukamo (ok), 13-Июн-21, 14:28

А ещё потому что PHP стал мейнстримом для "dynamic web" в нужное время и для него даже компилятор запилили. Постоены гигантские инфраструктуры, способные видерживать солидные нагрузки и хостить кучу клиентов. Есть море CMS и т.д. обещающие всё готовое из коробки, и да, если вам надо просто ребрендинг сделать, зачем платить больше?
Меня всегда на изнанку выворачивало от PHP. За язык его не считаю, но, когда мне надо завести блог, первым делом о WordPress вспоминаю, а не о django\flask & spring (или что там для java).

Ответить | Правка | Наверх | Cообщить модератору

34. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Плюсовик (?), 13-Июн-21, 15:00

>первым делом о WordPress вспоминаю, а не о django\flask & spring (или что там для java)
Аналогично. От php восторга не испытываю, но в своем сегменте ему нет равных.
Java и Ко идет лесом, только для жирного бизнеса. Она раскрывается при хорошем вливании денег и предоставлении больших мощностей железа.
Python... Даже с приходом asyncio и недоделанных либ aio* ситуация не лучше.
Ruby, Rails... Потыкал палочкой, что-то не зашло.
Go слишком много самому нужно делать, а я ленивый старый пень.
То, что предоставляет nodejs  заслуживает внимание, но прихожу в ужас от всех этих реактов и так далее. Тут мы подпорку из реек сделаем, а тут изоленту применим, а там... ммм... степлером пройдем.

Ответить | Правка | Наверх | Cообщить модератору

121. "Началось альфа-тестирование PHP 8.1" –1 +/–

Сообщение от MVK (??), 15-Июн-21, 10:42

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

Ответить | Правка | Наверх | Cообщить модератору

130. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Аноним (130), 15-Июн-21, 16:47

>>Java и Ко идет лесом, только для жирного бизнеса. Она раскрывается при хорошем вливании денег и предоставлении больших мощностей железа.
>- чепуха
Совсем не чепуха. Большая часть функционала PHP реализуется C++, а вот Java отдаёт C++ в лучшем случае переходы в libc. Так как Java-машина очень не спешит компилировать байт-код в машинный, то производительность половину времени примерно как у bochs. Так же сборщик мусора неадекватен и требует указания того, при каком объёме памяти необходимо вызвать сборку мусора. Она не будет вызвана раньше выделения этого объёма, а так же не даст выделить больше. От того Java славится своей прожорливостью к памяти. У того же .NET нет такой проблемы, частичная сборка мусора происходит по таймеру, а так же система сама уведомляет приложения, что надо бы затянуть пояса. Конечно это вс

Ответить | Правка | Наверх | Cообщить модератору

131. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Аноним (130), 15-Июн-21, 16:48

всё проблемы конкретной реализации, то другой в общем то нет.

Ответить | Правка | Наверх | Cообщить модератору

141. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от MVK (??), 17-Июн-21, 11:24

>Большая часть функционала PHP реализуется C++, а вот Java отдаёт C++ в лучшем случае переходы в libc
- интересно, но объясните тогда почему тогда PHP так нуждается в различных кэшах и оптимайзерах (и даже с ними он проигрывает по производительности Java)?
>Так как Java-машина очень не спешит компилировать байт-код в машинный
- откуда дровишки? На сервере (см. термин Server-Class Machine) JVM работает в режиме -server (что означает прекомпиляцию кода)
>сборщик мусора неадекватен и требует указания того, при каком объёме памяти необходимо вызвать сборку мусора
- какой сборщик? Как минимум штуки три различных алгоритма сборки можно использовать исходя из особенностей проекта. Однакож, те задачи на которых понадобится тюнинг сборщика мусора в JVM, для PHP просто неподъемны
>От того Java славится своей прожорливостью к памяти
- дурак и хрен сломать может. В моей практике высоконагруженные приложения вертелись на 32Мб хипа
>У того же .NET нет такой проблемы
- ну вот и сравнивайте его с PHP

Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

142. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Аноним (130), 17-Июн-21, 12:42

> - интересно, но объясните тогда почему тогда PHP так нуждается в различных
> кэшах и оптимайзерах
Потому, что базы данных не умеют толково кешировать запросы.
>(и даже с ними он проигрывает по производительности
> Java)?
Не видел ни одного быстрого сайта на Java, а вот быстрые сайты на PHP делаются легко. Не стоит судить о производительности PHP по WordPress. Java лучше после разогрева в числодробилках реализованных на Java, на реальных задачах она тормозит и не может потягаться в производительности числодробилок реализованных на C++ и просто вызванных из PHP. Сам JIT-компилятор php пока посредственный.
> - откуда дровишки? На сервере (см. термин Server-Class Machine) JVM работает в
> режиме -server (что означает прекомпиляцию кода)
-client уже многие годы игнорируется, то есть вообще всё работает режиме -server. В режиме -server jvm позволяет себе более агрессивные оптимизации. Откуда Вы вытащили, что Java полностью компилирует каждый встреченный при выполнении метод? Для этого есть отдельная опция и с ней программа действительнои надолго замирает при встрече каждого ранее невызваного метода. Но эта опция отключена по умолчанию в любом режиме.
> - какой сборщик? Как минимум штуки три различных алгоритма сборки можно использовать
> исходя из особенностей проекта. Однакож, те задачи на которых понадобится тюнинг
> сборщика мусора в JVM, для PHP просто неподъемны
Любой сборщик мусора Java жрёт ровно столько, сколько разрешили. Не больше и не меньше. Чтобы выжрать гигабайты памяти на секунду, а затем вернуться к еденицам мегабайт не обязательно иметь высокую производительность самого PHP, только его библиотек.
> - дурак и хрен сломать может. В моей практике высоконагруженные приложения вертелись
> на 32Мб хипа
И тормозили из за невозможности аллоциррвать большой объём памяти. Или высоконагруженные они только по количеству одновременных запросов, а не по обработке больших данных. С тем же успехом можно было реализовать тяжёлые места на C++ и приклеить к PHP и этот кусок кода будет работать быстрее того, что написан на Java. В этом суть любого скриптинга. У Java же вообще всё написано на Java, а jit-компилятор Java заведомо хуже компиляторов C++.

Ответить | Правка | Наверх | Cообщить модератору

143. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от MVK (??), 17-Июн-21, 13:18

>Потому, что базы данных не умеют толково кешировать запросы
- на PHP не могут, а на Java могут? Ах, да там же есть транзакционный и L2 кэши
>Не видел ни одного быстрого сайта на Java, а вот быстрые сайты на PHP делаются легко
- может еще увидите) Вот к примеру трейдинговые приложения пишут в основном на Java, наверное извращенцы))
>Не стоит судить о производительности PHP по WordPress
- не стоит судить о Java по технологии портлетов
>на реальных задачах она тормозит
- ни о чем (про тейдинговые приложения я уже вспоминал)

Ответить | Правка | Наверх | Cообщить модератору

41. "Началось альфа-тестирование PHP 8.1" +6 +/–

Сообщение от pda (ok), 13-Июн-21, 17:03

Он уже давно вполне себе язык.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

35. "Началось альфа-тестирование PHP 8.1" –3 +/–

Сообщение от starlette (?), 13-Июн-21, 15:33

Можно подумать, Ларавель, Вордпресс и прочие поделия - это быстро. Да на Питоне нужно сильно постараться, чтобы написать что-то более тормозное чем на большинстве PHP фреймворках или CMS.

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

39. "Началось альфа-тестирование PHP 8.1" +9 +/–

Сообщение от Онаним (?), 13-Июн-21, 16:08

Вот только одна проблема: на PHP таки написано.
А на питоне лет двадцать всё те же "нужно сильно постараться"...

Ответить | Правка | Наверх | Cообщить модератору

113. "Началось альфа-тестирование PHP 8.1" –1 +/–

Сообщение от Аноним (113), 15-Июн-21, 03:24

Лучше бы вообще не писали. Ни на одном языке не написано столько откровенной дряни как на этом шаблонизаторе.

Ответить | Правка | Наверх | Cообщить модератору

126. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от z (??), 15-Июн-21, 12:56

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

Ответить | Правка | Наверх | Cообщить модератору

48. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Плюсовик (?), 13-Июн-21, 18:52

Приведи аналоги Laravel, WordPress, Symfony для Python. Django да и все. Остальные микрофреймворки разной степени готовности со статусом от "в процессе проектирования" до "не готово".

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

115. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Аноним (115), 15-Июн-21, 03:48

Их нету, поскольку такую кучу г-на только на похапе написать и можно.

Ответить | Правка | Наверх | Cообщить модератору

49. "Началось альфа-тестирование PHP 8.1" +3 +/–

Сообщение от Плюсовик (?), 13-Июн-21, 18:58

>Питоне нужно сильно постараться, чтобы написать что-то более тормозное чем на большинстве PHP фреймворках или CMS.
Видал я тут на Flask админку к базе одной популярной СУБД. Описывать можно только нецензурными словами.

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

25. "Началось альфа-тестирование PHP 8.1" +7 +/–

Сообщение от Аноним (25), 13-Июн-21, 13:04

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

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

26. "Началось альфа-тестирование PHP 8.1" +3 +/–

Сообщение от ананоша (?), 13-Июн-21, 13:48

Пишу сейчас бэк на типскрипт, лучше бы на пыхе+симфони писал

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

30. "Началось альфа-тестирование PHP 8.1" –1 +/–

Сообщение от Aukamo (ok), 13-Июн-21, 14:29

Обоснуй
UPD: помимо того что там бывают ситуации с типами данных, мягко говоря, неприятные.

Ответить | Правка | Наверх | Cообщить модератору

42. "Началось альфа-тестирование PHP 8.1" +3 +/–

Сообщение от ананоша (?), 13-Июн-21, 17:04

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

Ответить | Правка | Наверх | Cообщить модератору

43. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Аноним (43), 13-Июн-21, 17:41

NestJS

Ответить | Правка | Наверх | Cообщить модератору

69. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Аноним (69), 13-Июн-21, 23:15

Только typeorm брать не надо, его автор вообще не в курсе, что такое ORM, и годами не понимает, зачем править очевидные архитектурные ляпы типа вызова конструктора при гидрации.
надо брать Mikro-ORM, он активно развивается, и изначально реализуется как полноценный Unit-Of-Work Data Mapper.

Ответить | Правка | Наверх | Cообщить модератору

75. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от ананоша (?), 14-Июн-21, 02:45

Это который пилится одним поляком?

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

77. "Началось альфа-тестирование PHP 8.1" –1 +/–

Сообщение от Аноним (69), 14-Июн-21, 05:51

Точно так же, как Symfony пилится одним французом (давно уже нет).

Ответить | Правка | Наверх | Cообщить модератору

59. "Началось альфа-тестирование PHP 8.1" –1 +/–

Сообщение от Ненавижу SJW (?), 13-Июн-21, 21:20

Express?

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

67. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Аноним (69), 13-Июн-21, 23:08

Экспресс низкоуровневый. Это скорее сравнимо с компонентами Symfony HttpFoundation, чем с самим Symfony.

Ответить | Правка | Наверх | Cообщить модератору

76. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от ананоша (?), 14-Июн-21, 02:47

Ну да, его и используем конечно же. Страшная вещь)

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

97. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Аноним (97), 14-Июн-21, 14:54

Blazor (гы-гы-гы), а вообще Angular

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

133. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Aukamo (ok), 15-Июн-21, 17:39

И это всё что не нравится в TS? Просто отсутсвие какого-то более менее долгоживущего решения (фреймворка)?

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

3. "Началось альфа-тестирование PHP 8.1" –4 +/–

Сообщение от Аноним (3), 13-Июн-21, 09:54

Статический анализатор в PHP настолько беспомощен, что не может понять, что в функции содержится вызов exit или бросает исключение и поэтому надо переложить написание лишних подсказок на плечи разработчика? А синтаксис перечисления нельзя было взять из Си  или TypeScipt?

Ответить | Правка | Наверх | Cообщить модератору

5. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Аноним (5), 13-Июн-21, 10:14

Нет нельзя! Надо было обязательно слепить что-то среднее между enum'ом и switch'ом, чтобы не как у всех было)

Ответить | Правка | Наверх | Cообщить модератору

9. "Началось альфа-тестирование PHP 8.1" –3 +/–

Сообщение от Варенье (?), 13-Июн-21, 10:40

> А синтаксис перечисления нельзя было взять из Си  или TypeScipt?
Подозреваю что лексер они сильно переусложнять не хотели, поэтому взяли синтаксис из Swift

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

10. "Началось альфа-тестирование PHP 8.1" +6 +/–

Сообщение от Ordu (ok), 13-Июн-21, 10:47

> Статический анализатор в PHP настолько беспомощен, что не может понять, что в функции содержится вызов exit или бросает исключение и поэтому надо переложить написание лишних подсказок на плечи разработчика?
Если ты вызываешь из кода php функцию на C, которая прерывает выполнение программы, то статистический анализатор должен каким-то магическим образом знать об этом свойстве внешней функции? Или может у него должна быть база данных всех внешних функций? Или может, всё же, проще добавить в синтаксис возможность задекларировать функцию как никогда не завершающуюся?
> А синтаксис перечисления нельзя было взять из Си  или TypeScipt?
Нет. У них внутри определения типа могут быть объявлены методы. В том числе и внутри enum'а. php, как я понимаю, следит за тем, чтобы синтаксис был бы легко парсящимся, в смысле чтобы не требовалось бы расчехлять весь опыт pattern-matching'а, чтобы определить что следующий statement из себя представляет. Например, функция начинается с ключевого слова function. Класс со слова class. Вариант enum'а со слова case. Они не совсем успешны в следовании этой идеи, и функция реально может начинаться с public static, но тем не менее, такие штуки очень помогают держать синтаксис непротиворечивым и избегать сложностей распутывания контекстных зависимостей.
Люди недооценивают важность таких вещей, но чем проще синтаксис, тем проще с ним работать программно, тем проще создавать тулзы для работы с сорцами. Это, кстати, мысль, которую Вирт не смог донести до окружающих. Он делал свои паскали очень простыми с точки зрения парсинга, но в качестве аргументов к тому, почему это нужно, он невнятно мямлил про скорость компиляции и простоту освоения языка. Но сегодня, когда статистические анализаторы внешние, по отношению к компилятору, и тулзы для рефакторинга, и поддержка редактором синтаксиса языка и поддержка им задач редактирования кода стали обыденностью, простота синтаксиса для программного парсинга стала очень важна.
Чтобы парсить C и тем более C++, тебе потребуется llvm. В принципе, C можно парсить и при помощи sparse. Либо ты будешь парсить регекспами, смиряясь с тем, что ты твой парсер никогда не поймёт, что означает * в данном контексте: слово "указатель" в названии типа? разадресацию указателя? умножение? Да блин, ты замучаешься отличить декларацию переменной, от умножения: "a * b" может быть умножением a и b, а может быть объявлением переменной b с типом "указатель на тип a".

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

95. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Sw00p aka Jerom (?), 14-Июн-21, 13:39

>Если ты вызываешь из кода php функцию на C, которая прерывает выполнение программы
а смысл тогда в статическом анализаторе для языка который по факту является оберткой другого языка?

Ответить | Правка | Наверх | Cообщить модератору

96. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Ordu (ok), 14-Июн-21, 14:51

>>Если ты вызываешь из кода php функцию на C, которая прерывает выполнение программы
> а смысл тогда в статическом анализаторе для языка который по факту является
> оберткой другого языка?
Я даже не знаю что сказать на это. Что значит "язык является обёрткой другого языка"? Язык C является обёрткой для асма? C++ является обёрткой для C?
Как я не кручу в голове твои обёртки, пытаясь понять, что ты хотел сказать, я не могу понять какое это отношение имеет к полезности статического анализатора. Давай мы лучше замнём тему, сделаем вид, что никаких обёрток и не было, и я просто расскажу тебе, зачем статическому анализатору нужно знать про no-return функции?
Всё очень просто: если статический анализатор знает, что функция не возвращает управления и завершает программу, то он может сделать вывод, что "вечный" цикл вовсе не вечный, а значит инкремент индекса не выползет за границы буфера. Или может статический анализатор увидит, что один из путей выполнения функции, набитой ветвлениями, не возвращает значения -- он будет ругаться, но если он увидит, что в конце этого пути выполнения стоит no-return функция, то он не будет ругаться. Он не будет захламлять мне вывод своими ворнингами. Меньше фолс-позитивов в работе статического анализатора -- больше внимания уделяется тру-позитивам, и меньше соблазна просто выключить ворнинги к чертям.
Но кроме того, no-return атрибут на функции добавляет новых срабатываний статическому анализатору: код расположенный после безусловного exit -- явно не нужный код, оставленный там по ошибке. И неплохо было бы, чтобы программист не забыл бы этот код удалить. Или может удалить вызов exit -- может это он был оставлен по ошибке?

Ответить | Правка | Наверх | Cообщить модератору

100. "Началось альфа-тестирование PHP 8.1" –1 +/–

Сообщение от Sw00p aka Jerom (?), 14-Июн-21, 17:13

> Я даже не знаю что сказать на это. Что значит "язык является
> обёрткой другого языка"? Язык C является обёрткой для асма? C++ является
> обёрткой для C?
Вот что значить вот это "Если ты вызываешь из кода php функцию на C"? пхепешный fopen вызывает lib сишный fopen который вызывает системный сишный сискол open.
https://en.wikipedia.org/wiki/Wrapper_function

> Давай мы лучше замнём тему, сделаем вид, что никаких обёрток и не было, и я просто расскажу тебе, зачем статическому анализатору нужно знать про no-return функции?
Лучше сначала определимся и опишем, что требуется от анализатора, ибо будем говорить о разных вещах.
> Всё очень просто: если статический анализатор знает, что функция не возвращает управления
> и завершает программу, то он может сделать вывод, что "вечный" цикл
> вовсе не вечный, а значит инкремент индекса не выползет за границы
> буфера.
Если нет возврата управления, то либо "вечный цикл", либо аварийный останов.
> Или может статический анализатор увидит, что один из путей выполнения
> функции, набитой ветвлениями, не возвращает значения -- он будет ругаться, но
> если он увидит, что в конце этого пути выполнения стоит no-return
> функция, то он не будет ругаться.
Что он будет выдавать, когда столкнется с проблемой останова? Статический анализатор ведь должен простроить граф потока управления.

> Или может удалить вызов exit -- может это он был оставлен по ошибке?
А как анализатор это может разрешить, что удалить, ошибочно добавленный exit или анюзед код после него. Это решает программист. А анализатор должен сообщить лишь о том, что у тебе тут exit, а код ниже никогда не исполниьтся.

Ответить | Правка | Наверх | Cообщить модератору

102. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Ordu (ok), 14-Июн-21, 18:21

> Вот что значить вот это "Если ты вызываешь из кода php функцию на C"? пхепешный fopen вызывает lib сишный fopen который вызывает системный сишный сискол open.
Эмм... Любой язык, кроме ассемблера, становится обёрткой, если следовать такому определению. Си ведь тоже не вызывает напрямую сисколлов, а дёргает обёртки из libc. fopen не вызывает сисколл open напрямую, а дёргает обёртку.
> Лучше сначала определимся и опишем, что требуется от анализатора, ибо будем говорить о разных вещах.
Анализ кода. Как правило с целью найти потенциальные ошибки в коде. Или даже не потенциальные, а самые натуральные ошибки. Когда тебе gcc пишет, что ты в условии if'а использовал =, что скорее всего опечатка, и если ты не хочешь видеть этот варнинг, то он предлагает тебе заключить условие в дополнительные скобки: вот этот варнинг -- как раз работа статического анализатора, встроенного в компилятор. Внешний по отношению к компилятору статический анализатор может выискивать больше подозрительных мест.
Но, в теории, я бы назвал статическим анализатором не только то, что ищет подозрительные места, но например программу, которая, допустим, пытается статическим анализом кода выяснить максимальную глубину стека, которая будет использована. Или, скажем, предсказать где будут бутылочные горлышки производительности. Или, скажем, высчитать максимальный latency наихудшего случая. А в случае, если им не удаётся выполнить свою задачу, то сообщают, что помешало.
Я не упомню таких программ, но исходя из их теоретической возможности: если бы они были, они тоже занимались бы статическим анализом кода, для того, чтобы без запуска программы узнать о ней что-то.
Чтобы понятнее было, можно сравнить с динамическим анализом -- со всякими там профайлерами, valgrind'ами, fuzzing-тестерами, и не только fuzzing, -- которые выясняют что-то о программе, посредством запуска её.
Статический анализ имеет некоторые преимущества: он может формулировать и доказывать утверждения о коде, типа "в этом цикле i всегда будет меньше чем arr.len()", и делать выводы типа
"поэтому проверка условия "i < arr.len()" на каждой итерации цикла не нужна". (ну или ровно наоборот, "WARNING: не удалось доказать, что i<arr.len() следовательно проверка нужна"). В динамике можно лишь статистически проверить такое утверждение, а это совсем не то.
> Если нет возврата управления, то либо "вечный цикл", либо аварийный останов.
while(1) {
   exit(0);
}
Вот тебе "вечный" цикл, который прекращает быть вечным (и вообще циклом), если мы знаем, что exit -- это no-return функция. Если тебе хочется более реалистичного примера, то...
for(i = 0; ; i++) {
    if(fds[i] >= 0)
        close(fds[i]);
    else
        exit(0);
}
Код закрывает все fds, из предположения что все открытые файловые дескрипторы лежат в начале fds, а все неиспользуемые элементы fds < 0, и что как минимум один неиспользуемый там есть. Он закрывает все, и завершает выполнение программы. Если мы не знаем, что exit завершает выполнение программы, то внезапно мы видим вечный цикл, который рано или поздно выйдет за границы массива, либо потому что i станет слишком большим, либо потому, что случится переполнение целого и i станет слишком отрицательным.
Хотя статистическому анализатору это всё равно, не поможет, потому как он не знает про инварианты fds, но мне не придумать сходу ещё более реалистичного примера. А! Можно анализатору подсунуть инварианты fds в виде логических утверждений, и пускай после этого он проверяет их соблюдение, и правильное использование fds тоже проверяет. А когда не может проверить, пускай кидает варнинги, мы будем править код, так, чтобы анализатор справился бы с доказательством.
Впрочем, в php, я подозреваю всё проще. Я думаю, тут не случайно так совпало, что в одном релизе появились и fiber'ы, и noreturn функции: fiber'ы постоянно завершаются. Программа завершается лишь раз, за всё время работы, а fiber'ов много, и почти все они завершаются. И тут, я полагаю, требуется определённое взаимодействие рантайма (который рулит фиберами) и компилятора, чтобы компилятор no-return функции правильно бы норетурнил, прибивая фибер. Ну или что-нибудь в этом роде.
> Что он будет выдавать, когда столкнется с проблемой останова? Статический анализатор ведь должен простроить граф потока управления.
А где там проблема останова вылезет? Как я это вижу, если компилятор может проследить пути выполнения таким образом, чтобы разложить код в линейную последовательность ассемблерных инструкций, или операций интерпретатора, то значит он может определить моменты, где происходит возврат из функции, а возвращаемое значение не предоставлено, так? А если компилятор может, то и статический анализатор сможет. Особенно если он -- часть компилятора.
А ежели компилятор этого не может сделать, то значит он не может завершить компиляцию разумным образом, и значит это ошибка компилятора. То есть в результате статистического анализа в программе была найдена ошибка.
> А как анализатор это может разрешить, что удалить, ошибочно добавленный exit или анюзед код после него. Это решает программист. А анализатор должен сообщить лишь о том, что у тебе тут exit, а код ниже никогда не исполниьтся.
Да, именно так он и делает, он кидает варнинги. Но для того, чтобы решить, что здесь нужно кинуть варнинг, он сначала должен детектировать код, который не будет выполняться никогда. А для этого ему надо знать, что exit -- это no-return функция.

Ответить | Правка | Наверх | Cообщить модератору

108. "Началось альфа-тестирование PHP 8.1" –1 +/–

Сообщение от Sw00p aka Jerom (?), 15-Июн-21, 01:32

> Эмм... Любой язык, кроме ассемблера, становится обёрткой, если следовать такому определению.
> Си ведь тоже не вызывает напрямую сисколлов, а дёргает обёртки из
> libc. fopen не вызывает сисколл open напрямую, а дёргает обёртку.
Ну да.

> Анализ кода. Как правило с целью найти потенциальные ошибки в коде. Или
> даже не потенциальные, а самые натуральные ошибки.
Опять задам парочку уточняющих вопросов, ибо не ясно, что значит "анализ кода", "потенциальные или натуральные ошибки", а за "ошибки" мы не раз обсуждали - это очень широкое понятие, что конкретно принимается за ошибку (то есть нужно определить это множество ошибок)? Приведу пример моего понимания:
1) Анализ кода с точки зрения безопасности алгоритма. (???????? тут много вопросов)
2) Анализ кода с точки зрения корректности алгоритма. (работа алгоритма выдает желаемый результат, при описанных условиях)
3) Анализ кода с точки зрения оптимальности алгоритма. (тут имеется ввиду не то, что анализатор увидев алгоритм сортировки "пузырьком" выдавал предупреждение, мол можно использовать квиксорт, а оптимальное использование как временных (быстродействие), так и пространственных ресурсов (использование памяти))
Хотя предположу, тот же анализ безопасности вытекает из корректности и оптимальности алгоритма. Думаю на текущий момент любую проблему (ошибку) безопасности можно свести к корректности и оптимальности. Алгоритм "безопасный", если он "корректный" и "оптимальный".
Далее про "самые натуральные ошибки" ( :), не мог себе представить какую из ошибок могу считать натуральной, ошибки за которые учительница по рукам линейкой бьет?), так вот надо понять какие "ошибки" имеем ввиду.
1) Синтаксические, грамматические, лексические - приводящие к некорректности алгоритма.
2) Логические - приводящие как к некорректности, так и к неоптимальности.
Что тут еще добавить?
> Когда тебе gcc пишет,
> что ты в условии if'а использовал =, что скорее всего опечатка,
> и если ты не хочешь видеть этот варнинг, то он предлагает
> тебе заключить условие в дополнительные скобки: вот этот варнинг -- как
> раз работа статического анализатора, встроенного в компилятор.
А зачем тут ворнинг? какой в этом смысл, если реально мне не запрещает ЯП использовать в if присваивание =. Ибо результат этого присваивания тем же ЯП будет трактоваться как булево (логическое) значение, а оператор if именно с такими значениями (операндами) работает. Да конечно в большинстве случаев это "банальная" логическая ошибка, но ни как не синтаксическая, грамматическая, лексическая. И решение этой проблемы, в  синтаксическом переосмыслении условного оператора. Зачем компилятору ворнинг, если конкретно эта ситуация допустима в ЯП?

> Внешний по отношению к
> компилятору статический анализатор может выискивать больше подозрительных мест.
Только если он будет следовать каким-то заранее заданным шаблонам (паттернам логических ошибок), ибо не существует анализатора который бы разрешил бы проблему останова, так как это проблема банальный логический парадокс. Если человеческая логика впадает в ступор перед логическими парадоксами, думаете анализатор с ними справится (можно на это не отвечать)?

> Но, в теории, я бы назвал статическим анализатором не только то, что
> ищет подозрительные места, но например программу, которая, допустим, пытается статическим
> анализом кода выяснить максимальную глубину стека, которая будет использована. Или, скажем,
> предсказать где будут бутылочные горлышки производительности. Или, скажем, высчитать
> максимальный latency наихудшего случая. А в случае, если им не удаётся
> выполнить свою задачу, то сообщают, что помешало.
Выше описал это, ток в данном контексте надо отделать понятия профайлинга (Анализ кода с точки зрения оптимальности алгоритма) и статического анализатора (Анализ кода с точки зрения корректности алгоритма.) в обще принятом смысле этого слова. Тут просто мне не ясно, как "статически" произвести профайлинг (без выполнения программы), то есть как оценить оптимальность без исполнения, и сравнения результата с ожидаемым?
> Я не упомню таких программ, но исходя из их теоретической возможности: если
> бы они были, они тоже занимались бы статическим анализом кода, для
> того, чтобы без запуска программы узнать о ней что-то.
Как выше написал, как без запуска программы сравнить ее результат с ожидаемым?
> Чтобы понятнее было, можно сравнить с динамическим анализом -- со всякими там
> профайлерами, valgrind'ами, fuzzing-тестерами, и не только fuzzing, -- которые выясняют
> что-то о программе, посредством запуска её.
> Статический анализ имеет некоторые преимущества: он может формулировать и доказывать утверждения
> о коде, типа "в этом цикле i всегда будет меньше чем
> arr.len()", и делать выводы типа
> "поэтому проверка условия "i < arr.len()" на каждой итерации цикла не нужна".
> (ну или ровно наоборот, "WARNING: не удалось доказать, что i<arr.len() следовательно
> проверка нужна"). В динамике можно лишь статистически проверить такое утверждение, а
> это совсем не то.
Вот тут немного не ясно, хочу увидеть всю конструкцию цикла, не могу представить.
>[оверквотинг удален]
>     else
>         exit(0);
> }
> Код закрывает все fds, из предположения что все открытые файловые дескрипторы лежат
> в начале fds, а все неиспользуемые элементы fds < 0, и
> что как минимум один неиспользуемый там есть. Он закрывает все, и
> завершает выполнение программы. Если мы не знаем, что exit завершает выполнение
> программы, то внезапно мы видим вечный цикл, который рано или поздно
> выйдет за границы массива, либо потому что i станет слишком большим,
> либо потому, что случится переполнение целого и i станет слишком отрицательным.
Смотрите, что такое тип ? - область (диапазон) допустимых значений, из примера выше переменная i имеет тип целочисленного значения (не важно пока со знаком или без) и инкрементируется в бесконечном цикле. Отсюда делаем вывод, что переменная i в данном случае может принять все допустимые значения (допустим MAX_UINT). Далее эта переменная используется в качестве индекса массива fds, размер (длина) которого не превышает MAX_UINT по определению, что индексация массивов находится в области допустимых целочисленных значений без знака. Но если мы обращаемся по индексу, который больше размера (длины) массива, то происходит аварийный останов, из-за выхода за границы массива. Собственно вопрос, как в случае когда размер (длина) массива заранее не известна, статический анализатор скажет (без исполнения), мол тут выход за границы массива? А выход из цикла разве не будет если допустим что аварийного останова нет и после переполнения инта он становится обратно в 0, то по условию это уже освобожденный файловый дескриптор и выполниться exit().
> Хотя статистическому анализатору это всё равно, не поможет, потому как он не
> знает про инварианты fds, но мне не придумать сходу ещё более
> реалистичного примера.
Таки да.
> А! Можно анализатору подсунуть инварианты fds в виде логических
> утверждений, и пускай после этого он проверяет их соблюдение, и правильное
> использование fds тоже проверяет. А когда не может проверить, пускай кидает
> варнинги, мы будем править код, так, чтобы анализатор справился бы с
> доказательством.
А не легче сильно статически это определять? Вспомним язык паскаль, и мнение Кернигана о нем (Почему Паскаль не является моим любимым языком программирования). Помните, мы обсуждали строки сишные и паскалевы их плюсы и минусы, тоже самое и с анализаторами Вывод мой таков, статический анализатор применим в основном в сильно статических (система типов) ЯП, а для "динамических" - динамический анализатор. Не вижу смысла статическим анализатором пытаться анализировать код динамического ЯП. Кстати про no-return функции, что нам предоставляет паскаль? - процедуры (которые ничего не возвращают) и собственно функции. Статический анализатор способен в таком случае распознать no-return "функцию"? А в С что? оператор return. А если его нет?
https://stackoverflow.com/questions/4260048/c-function-defin...
https://stackoverflow.com/questions/45981545/why-does-noretu...
> А где там проблема останова вылезет? Как я это вижу, если компилятор
> может проследить пути выполнения таким образом, чтобы разложить код в линейную
> последовательность ассемблерных инструкций, или операций интерпретатора, то значит он
> может определить моменты, где происходит возврат из функции, а возвращаемое значение
> не предоставлено, так? А если компилятор может, то и статический анализатор
> сможет. Особенно если он -- часть компилятора.
Стоп, стоп, тут не надо путать понятия компиляции с понятием исполнения, компилятор не исполняет!
Ибо как вы представляете себе компиляцию такой программы?
while (true)
{
   [code block] - а тут нет никакой функции или оператора прерывающий цикл.
}
Тоже самое с unused кодом, во многих случаях ни компилятор ни статический анализатор не сможет принять решение является ли код не используемым, исключая некоторые частные случаи, как отметил выше, паттерны заложенные в анализатор или компилятор.
> А ежели компилятор этого не может сделать, то значит он не может
> завершить компиляцию разумным образом, и значит это ошибка компилятора. То есть
> в результате статистического анализа в программе была найдена ошибка.
нет, нет - процесс компиляции и непосредственного выполнения - разные понятия.

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

Ответить | Правка | Наверх | Cообщить модератору

112. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Ordu (ok), 15-Июн-21, 03:20

>> Анализ кода. Как правило с целью найти потенциальные ошибки в коде. Или
>> даже не потенциальные, а самые натуральные ошибки.
> Опять задам парочку уточняющих вопросов, ибо не ясно, что значит "анализ кода",
> "потенциальные или натуральные ошибки", а за "ошибки" мы не раз обсуждали
if(a = b) {
бла-бла-бла
}
Это есть потенциальная ошибка. С точки зрения статического анализатора. Он не знает задумку программиста, он не знает, хотел ли программист сравнить a и b (и написать a == b), или он хотел выполнить присвоение, а полученное значение в a использовать как булевское значение.
Это, судя по интернетам, довольно распространённая ошибка в C, вызванная опечаткой. Но, я повторю, статический анализатор, не знает, ошибка ли это или нет. Я это назвал "потенциальной" ошибкой.
Что же касается "натуральной" ошибки -- я может неудачно слово подобрал, но я "натуральный" использовал в том контексте противопоставляя "потенциальной", наверное, лучше было бы назвать её "актуальной"?
И вот тебе пример, заодно к вопросам про проверки индексов на выход за границы внутри цикла:
Сначала без ошибки, но с лишней проверкой:
for(i = 0; i < arr.len(); i ++) {
    if(i < arr.len()) {
        sum += arr[i];
    }
}
Проверка лишняя, это математически доказуемо, и оптимизаторы эту проверку легко устраняют. Статический же оптимизатор может кинуть варнинг о том, что проверка лишняя. Зачем он будет так делать -- это другой вопрос, отдельный большой и длинный.
Теперь с не лишней проверкой:
for(i = 0; i < arr.len() * 2; i ++) {
    if(i < arr.len()) {
        sum += arr[i];
    }
}
Тут уже не удастся доказать, что проверка лишняя, то есть что устранение этой проверки не изменит результат выполнения кода. Более того, если мы проверку устраним, то статический анализатор сможет доказать, что i выходит за границу arr.len() и кинуть нам варнинг. Но это сработает, только если компилятор представляет себе инварианты массивов. Язык C не представляет: для него массив это просто указатель, ты можешь объявлять переменную как int arr[5], но C потом с радостью позволит тебе индексировать arr числом больше пяти или отрицательным числом. Даже если в коде будет написано arr[-1000], компилятор C не увидит в этом ничего странного. Но статический анализатор может возбудиться от такого. И если он сможет доказать, что индекс достигает 5 и превосходит его, он тоже может возбудиться.
> - это очень широкое понятие, что конкретно принимается за ошибку (то
> есть нужно определить это множество ошибок)?
Естественно это очень широкое понятие, и именно поэтому мы не будем его определять. Всё что ты в разговоре можешь назвать ошибкой, и всё что может быть детектировано как ошибка посредством разглядывания кода и размышлений -- это всё потенциальная цель поиска для статического анализатора.
Хотя, быть может, синтаксические ошибки стоит из этого списка выкинуть, статический анализатор всё ж заточен на работу с "синтаксически корректными" программами, которые компилируются.
>> Внешний по отношению к
>> компилятору статический анализатор может выискивать больше подозрительных мест.
> Только если он будет следовать каким-то заранее заданным шаблонам (паттернам логических
> ошибок), ибо не существует анализатора который бы разрешил бы проблему останова,
> так как это проблема банальный логический парадокс. Если человеческая логика впадает
> в ступор перед логическими парадоксами, думаете анализатор с ними справится (можно
> на это не отвечать)?
Я не видел ни одного статического анализатора, который бы обещал выполнять роль серебряной пули и находить вообще все проблемы. Теоретически мы можем нафантазировать такой, но практически таких нет. Они все решают вполне конкретные задачи, и да, наверное, посредством сопоставления с образцом... Не, не всё можно. И вообще можно зайти и с другой стороны. Можно объявлять инварианты -- логические утверждения, которые должны сохранять истинность на протяжении выполнения программы. Скажем, что индекс в массиве >=0 и меньше длины этого массива. А дальше статический анализатор ищет все индексации массивов, и пытается доказать это утверждение про индекс. Иногда он доказывает его, и всё ок. Иногда он опровергает его, и это можно рассматривать как ошибку. Иногда он не может ни доказать, ни опровергнуть -- тут можно вести себя по разному, можно выкидывать варнинг, ибо нехрен писать код, про который невозможно доказать инварианты.
> Выше описал это, ток в данном контексте надо отделать понятия профайлинга (Анализ
> кода с точки зрения оптимальности алгоритма)
Весь профайлинг, с которым мне приходилось сталкиваться был динамическим. Но если ты настаиваешь, давай разделять профайлинг на динамический и статический. Динамический требует запуска программы для измерения времени, мы не об этом говорим совершенно.
> Тут просто мне не ясно, как "статически" произвести профайлинг (без выполнения
> программы), то есть как оценить оптимальность без исполнения, и сравнения результата
> с ожидаемым?
Я не знаю, как оценить "оптимальность", я не понимаю, что ты имеешь в виду. А вот как провести профайлинг -- это, например, в случае ассемблера, можно попытаться делать так: берёшь мануал к процессору, выковыриваешь оттуда информацию о том, сколько времени занимает выполнение той или иной инструкции, после чего разбиваешь программу на линейные куски без ветвления, считаешь время для каждого куска, а потом начинаешь анализировать ориентированный граф ветвления, высчитывая сколько раз какая итерация цикла выполнится.
Этот последний этап будет, надо полагать, довольно сложным, но если позволить анализатору выводить асимптотическое время, в виде формулы с параметром, то я думаю можно. Другое дело, что формулы могут получиться слишком громоздкими для анализа глазами. Но их потом можно попытаться анализировать при помощи софтины, которая будет искать самые тормоза и пытаться угадать бутылочные горлышки.
> Смотрите, что такое тип ? - область (диапазон) допустимых значений, из примера
> выше переменная i имеет тип целочисленного значения (не важно пока со
> [...]
> находится в области допустимых целочисленных значений без знака. Но если мы
> обращаемся по индексу, который больше размера (длины) массива, то происходит аварийный
> останов, из-за выхода за границы массива.
Нет. Это зависит от языка. C не выполняет никаких аварийных остановов из-за такой мелочи, как выход за границы массива.
> когда размер (длина) массива заранее не известна, статический анализатор скажет (без
> исполнения), мол тут выход за границы массива?
Во-первых, длина может быть известна -- это зависит от языка. Во-вторых, если она не известна, то статический анализатор может исходить из самой общей идеи: неограниченные значения индекса -- это потенциальная ошибка. А здесь он не сможет наложить на значения индекса никаких ограничений, кроме ограничений типа.
> А выход из цикла
> разве не будет если допустим что аварийного останова нет и после
> переполнения инта он становится обратно в 0,
Он становится в INT_MIN, который при четырёхбайтовом инте равен -2^31. А это значит переполнение буфера вниз. Плюс, кстати, это переполнение целого, что в случае C есть UB.
> то по условию это уже освобожденный файловый дескриптор и выполниться exit().
Не, во-первых, про освобождёные фд анализатор будет знать только если ему каким-то образом сообщили про инварианты. Если не сообщили, он вообще никаких допущений о содержимом fds делать не может. Во-вторых, в цикле не зануляются значения fds. Они остаются прежними. Их можно назвать "dangling file descriptors". Повторный проход по массиву повторно вызовет все close.
> А не легче сильно статически это определять? Вспомним язык паскаль, и мнение
> Кернигана о нем (Почему Паскаль не является моим любимым языком программирования).
> Помните, мы обсуждали строки сишные и паскалевы их плюсы и минусы,
> тоже самое и с анализаторами Вывод мой таков, статический анализатор применим
> в основном в сильно статических (система типов) ЯП, а для "динамических"
> - динамический анализатор. Не вижу смысла статическим анализатором пытаться анализировать
> код динамического ЯП.
Да, динамический сложнее анализировать. Но потенциально можно извлечь больше, если анализировать не только функции отдельно, и забывать этот анализ, переходя к другой функции, а строить общую блоксхему выполнения программы, и отслеживать какая функция откуда вызывается, какого типа аргументы туда передаются, и соответственно _доказать_, что например в локальной переменной a функции foo может быть только четырёхбайтовое целочисленное значение, потому что a заполняется из аргумента arg1 строчкой a = arg1 + 3; а все вызовы функции foo кладут в arg1 целочисленное значение.
То есть, можно статически восстановить информацию о типах, и... А дальше можно взять и сказать, что если foo почти всегда вызывается с целочисленным аргументом, лишь один раз туда передаётся строковый, то это подозрительно похоже на ошибку программиста, который задумал foo с целочисленным аргументом, но один раз нечаянно сунул туда строку.
> Кстати про no-return функции, что нам предоставляет паскаль?
Ничего.
> - процедуры (которые ничего не возвращают) и собственно функции. Статический анализатор
> способен в таком случае распознать no-return "функцию"?
Нет.
> А в С что? оператор return. А если его нет?
Если в сишной функции нет оператора return, то возвращаемое значение функции неопределено, то есть это UB. Функция без return'а в C -- это не no-return функция. По-крайней мере в том определении "no-return", которое мы используем в данном разговоре. И паскалевская процедура -- это тоже не no-return функция в этом смысле. no-return функция -- это функция которая не возвращает управление в код, вызвавший её. В стандарте C нет ничего такого, так же как и в pascal'е. Но в gcc, если мне не изменяет память, есть атрибут noreturn или типа того, который можно повесить на функцию, сообщив компилятору, что она noreturn.
>> А где там проблема останова вылезет? Как я это вижу, если компилятор
>> может проследить пути выполнения таким образом, чтобы разложить код в линейную
>> последовательность ассемблерных инструкций, или операций интерпретатора, то значит он
>> может определить моменты, где происходит возврат из функции, а возвращаемое значение
>> не предоставлено, так? А если компилятор может, то и статический анализатор
>> сможет. Особенно если он -- часть компилятора.
> Стоп, стоп, тут не надо путать понятия компиляции с понятием исполнения, компилятор
> не исполняет!
> Ибо как вы представляете себе компиляцию такой программы?
В смысле? Ты ждёшь, что я разложу эту функцию здесь в линейную последовательность команд ассемблера? Ты можешь сделать это без моей помощи: gcc/clang вызванные с аргументом -S выдадут тебе ассемблерный дамп, то есть линейную последовательность ассемблерных команд.
> Тоже самое с unused кодом, во многих случаях ни компилятор ни статический
> анализатор не сможет принять решение является ли код не используемым, исключая
> некоторые частные случаи, как отметил выше, паттерны заложенные в анализатор или
> компилятор.
Да. Есть три варианта:
1. анализатор доказал, что код used
2. анализатор доказал, что код unused
3. анализатор не смог доказать ни того, ни другого.
Первые два случая тривиальны, с точки зрения того, что анализатору делать столкнувшись с ними. Третий случай сложнее, и анализатор может вести себя по-разному. Это зависит от языка, от целей анализатора, возможно от опций запуска анализатора.
>> Да, именно так он и делает, он кидает варнинги. Но для того,
>> чтобы решить, что здесь нужно кинуть варнинг, он сначала должен детектировать
>> код, который не будет выполняться никогда. А для этого ему надо
>> знать, что exit -- это no-return функция.
> И детектирует только по заранее известному паттерну, то есть вы должны создать
> статический анализатор все-возможного говно-кода (грубо говоря).
Скорее всего да. Но если мы будем рассматривать систему доказывающую соответствие кода спецификации, которая задана в виде логических утверждений о коде, то тут ситуация обратна: мы задаём все правильные состояния, а статистический анализатор находит отклонения. Такие программы, правда, не называют статическими анализаторами, но я не вижу качественной разницы, только количественную.
Ведь инварианты можно задавать спорадически, допустим комментариями специального вида. В принципе, даже объявления типов переменных -- это своего рода инварианты, типа "эта переменная хранит только значения типа int". Можно задавать инварианты чаще, и, скажем, для структуры динамического массива с полями buf, size, len, писать инвариант len <= size, а статический анализатор потом будет обращать внимание на все изменения len и size, и пытаться доказать или опровергнуть инвариант, с опорой на код меняющий их. Получать один из трёх вариантов доказано/опровергнуто/хз, и выдавать реакцию вида кинуть варнинг, ошибку, или ничего не кидать.
Можно писать инварианты ещё чаще -- на каждую функцию. Можно вообще на каждый чих: каждый раз, когда можно написать простой инвариант (когда не надо две страницы покрывать математической вязью, когда достаточно простого условия). Ну и, наконец, можно полную спецификацию кода задать. То есть, разница между ubsan и проверкой спецификации скорее количественная, чем качественная.
> Статический анализатор
> это не симулятор исполнения, тогда ему необходимы входные данные, а если
> ему эти данные дать, то это динамический анализатор.
Нет, есть такая штука, как символьные вычисления. Алгебра, короче. Зная какие-то истинные утверждения о значениях переменных, можно доказывать другие. Например, можно сказать, что sqrt(a) <= a, для любого a>=0. А это значит, что, например:
for(i = 0; i < sqrt(arr.len()); i ++) {
    arr[i] = 0;
}
никогда не выйдет за границы массива, вне зависимости от значения arr и arr.len().
Можно взять баблсорт:
for(i = 1; i < arr.len(); i++) {
    for(j = i; j > 0; j --) {
        make_them_ascending(&arr[j-1], &arr[j]);
    }
}
И доказать, что здесь не случится выхода за границы массива, хотя нигде нет непосредственного сравнения j с arr.len(). С одной из границ он сравнивается, а с другой нет, но статический анализ, применив немного логического вывода, может доказать, что всё ок. И для этого вовсе не обязательно выполнять.
Да, вот логический вывод, как раз, сталкивается с проблемой останова, но это будет означать лишь то, что статический анализатор иногда будет долго думать, прерывать свои размышления по таймеру (или по используемой памяти, или ещё по чему), и выводить варнинг "я не могу доказать X в строке N сорца SOURCE_NAME, но, допустим, я доказал, и вот я дальше разбираю остальной код". Или может мы запустим его в sloppy режиме, и он будет нам сообщать только о тех местах, где ему удалось опровергнуть какой-нибудь инвариант. Или может ещё как-нибудь выкрутимся: сделав отрицательный результат поиска багов ненадёжным; или заставив программистов принять такой стиль написания кода, чтобы всё доказывалось...

Ответить | Правка | Наверх | Cообщить модератору

80. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Аноним (80), 14-Июн-21, 09:25

Что еще ожидать от недоразвитых вебмакак неспособных даже написать помощьный статический анализатор. Анонимным эксперам всё ясно с php, давно. Единственное что анонимным экспертам не ясно, что же такое статический анализатор и зачем он нужен. А так же зачем тип Nothing в kotlin, never в swift и typescript.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

81. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Онаним (?), 14-Июн-21, 10:07

Статический анализатор в динамическом языке...
Печалька.
Оно вообще может управление отдать через call_user_func(['ex'.chr(105).'t']);, и хрен ты это анализатором разберёшь, грубо говоря. Для продвинутых анализаторов можно пример ещё усложнить, обвешав вызовами C'шного API.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

82. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 14-Июн-21, 10:07

// квадратные скобки лишние, сорян

Ответить | Правка | Наверх | Cообщить модератору

84. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Аноним (80), 14-Июн-21, 10:37

в php вообще-то есть статическая типизация для аргуметов функций и полей классов

Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

89. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 14-Июн-21, 12:07

Там скорее тайпчек частично на этапе трансляции, а в основном - в рантайме.

Ответить | Правка | Наверх | Cообщить модератору

90. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 14-Июн-21, 12:08

(потому что не для констант и предсказуемых вызовов финальный тип становится известен только в рантайме)

Ответить | Правка | Наверх | Cообщить модератору

91. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 14-Июн-21, 12:10

(ну то есть к реальной статический типизации это имеет слабое отношение, хотя часть оптимизаций применима, конечно же)

Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

109. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Sw00p aka Jerom (?), 15-Июн-21, 01:42

> Статический анализатор в динамическом языке...
> Печалька.
Блин аааа, мою портянку выше можно было уместить в ваши две строчки :)

Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

7. "Началось альфа-тестирование PHP 8.1" –22 +/–

Сообщение от onanim (?), 13-Июн-21, 10:36

кошмар.
делали user-friendly C, а получился вырвиглазный Rust.

Ответить | Правка | Наверх | Cообщить модератору

31. "Началось альфа-тестирование PHP 8.1" +4 +/–

Сообщение от Aukamo (ok), 13-Июн-21, 14:33

Ставил минус ибо не понял: при чём тут Rust, вообще?

Ответить | Правка | Наверх | Cообщить модератору

33. "Началось альфа-тестирование PHP 8.1" –1 +/–

Сообщение от Аноним (33), 13-Июн-21, 14:40

Тоже минус. Лучшего синтаксиса мои глаза не видели.

Ответить | Правка | Наверх | Cообщить модератору

70. "Началось альфа-тестирование PHP 8.1" +3 +/–

Сообщение от СССР (?), 13-Июн-21, 23:24

но лучше чем питон

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

114. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Аноним (113), 15-Июн-21, 03:27

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

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

125. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от onanim (?), 15-Июн-21, 11:51

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

Ответить | Правка | Наверх | Cообщить модератору

132. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Aukamo (ok), 15-Июн-21, 17:25

> начиная с 7ой версии пых стал довольно неплох.
У меня на 5-6 версиях сформировался такой рвотный рефлекс, что до сих пор рефлексивно ищу близжайший пакет при упоминании PHP.
Не смотря на моё к нему отношение, PHP занял свою нишу. Для непонятливых: синтаксис тут вообще ни при чём. Си подобный синтаксис был выбран только ради повышения узнаваемости и читаемости (можете вспомнить когда впервые увидили тот-же python или rust, не зная ничего о нём), но сам язык создавался для "домохозяек" и, полагаю, таким и остался. Здесь очень хотелось бы встретить уважаемого Symfony-ста, который разложит в 2х словах как там обстоят дела.
Как, уже писал выше, не слежу за языком и всё что с ним происходит уже больше десятка лет. Может он, вдруг, стал строго академическим, но сильно сомневаюсь.

Ответить | Правка | Наверх | Cообщить модератору

135. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 16-Июн-21, 10:16

"Шашечки или ехать".
Язык как был, так и остался строго прикладным.
Его пытаются слегка обрастить некоторыми "академичными" конструкциями для неосиляторов, но к счастью core team  более-менее адекватна.

Ответить | Правка | Наверх | Cообщить модератору

8. "Началось альфа-тестирование PHP 8.1" –10 +/–

Сообщение от InuYasha (??), 13-Июн-21, 10:39

Пока статическую типизаицю не введут, плюс не поставлю.
Но они не введут. И уже не ввели. Путь едят кактус.

Ответить | Правка | Наверх | Cообщить модератору

12. "Началось альфа-тестирование PHP 8.1" +2 +/–

Сообщение от Аноним (11), 13-Июн-21, 10:53

Это сегрегация все типы должны иметь равные возможности.

Ответить | Правка | Наверх | Cообщить модератору

16. "Началось альфа-тестирование PHP 8.1" +2 +/–

Сообщение от Аноним (15), 13-Июн-21, 11:46

И делить на ноль надо разрешить, оскорбление нуля!

Ответить | Правка | Наверх | Cообщить модератору

20. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от anonymous (??), 13-Июн-21, 12:27

Никто не мешает добавить число бесконечность (беззнаковый, как в сфере Римана) и разрешить деление на ноль.

Ответить | Правка | Наверх | Cообщить модератору

111. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Da (?), 15-Июн-21, 03:10

Деление на 0 не равно бесконечности.
Деление на 0 просто не имеет смысла по определнию операции деления.

Ответить | Правка | Наверх | Cообщить модератору

124. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от ыы (?), 15-Июн-21, 11:41

Просто мы еще чегото не знаем о окружающем нас мире...

Ответить | Правка | Наверх | Cообщить модератору

37. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Sw00p aka Jerom (?), 13-Июн-21, 15:40

а че тут такого, этоже по факту функция рандома.

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

54. "Re: И делить на ноль надо разрешить, оскорбление нуля!" +1 +/–

Сообщение от Ag (ok), 13-Июн-21, 19:47

Тогда  вам нужен APL, правда там только 0 / 0 (даст 1). Но все же хоть какая то инклюзивность ;)

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

85. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Аноним (85), 14-Июн-21, 10:38

В Джаваскрипте можно делать на 0 будет Infininty. Можно даже стринг поделить на ноль будет NaN. Вот где свобода и права всех типов соблюдены.

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

107. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от mr.Clin (?), 15-Июн-21, 00:02

Ага, ровно до тех пор пока не всрёшься с такими приколами )))

Ответить | Правка | Наверх | Cообщить модератору

120. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от 1 (??), 15-Июн-21, 10:10

Так "Ноль" или "Нуль" ?

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

22. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Онаним (?), 13-Июн-21, 12:51

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

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

87. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Аноним (85), 14-Июн-21, 10:43

PHP язык со слабой неявной динамической типизацией. Хотя нужно это только для собеседования.

Ответить | Правка | Наверх | Cообщить модератору

88. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 14-Июн-21, 12:05

Да и для собеседования не особо нужно, но таки да.
Кстати половина режется на оптимизации in_array() для большого числа выборок.

Ответить | Правка | Наверх | Cообщить модератору

116. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Здрасьте (?), 15-Июн-21, 07:57

Ты слабую с нестрогой не перепутал? Си++ — язык со слабой типизацией, например.

Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

45. "Началось альфа-тестирование PHP 8.1" +6 +/–

Сообщение от Lex (??), 13-Июн-21, 17:57

Дык ввели. «Си» называется.
Можешь поставить ему плюсик и начинать кодить на нем сайты

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

99. "Началось альфа-тестирование PHP 8.1" +4 +/–

Сообщение от Аноним (99), 14-Июн-21, 16:27

Хорошая идея, одобряю.

Ответить | Правка | Наверх | Cообщить модератору

134. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от InuYasha (??), 16-Июн-21, 10:16

Так давно уже https://cppcms.com

Ответить | Правка | Наверх | Cообщить модератору

14. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Аноним (14), 13-Июн-21, 11:33

А не проще ли с таким синтаксисом писать сразу на статически типизируемом языке?

Ответить | Правка | Наверх | Cообщить модератору

17. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от acroobat (??), 13-Июн-21, 11:54

Опять со своим руби лезут.

Ответить | Правка | Наверх | Cообщить модератору

18. "Началось альфа-тестирование PHP 8.1" –2 +/–

Сообщение от Аноним (18), 13-Июн-21, 12:03

А ты не завидуй.

Ответить | Правка | Наверх | Cообщить модератору

23. "Началось альфа-тестирование PHP 8.1" +3 +/–

Сообщение от Онаним (?), 13-Июн-21, 12:53

Проще.
Собственно писать на PHP никто за хвост никого не тянет - но на нём пишется очень много.
Это показатель того, что язык удобен для своих задач.

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

46. "Началось альфа-тестирование PHP 8.1" –7 +/–

Сообщение от Аноним (46), 13-Июн-21, 18:25

Миллионы мух. На баше тоже много написано, но это вообще ни о чем не говорит.

Ответить | Правка | Наверх | Cообщить модератору

50. "Началось альфа-тестирование PHP 8.1" +4 +/–

Сообщение от Онаним (?), 13-Июн-21, 19:19

Говорит.
О том, что он удобен для своих задач.
В отличие от хипстерских поделок со "стройной идеологией"... и ничем, кроме идеологии, которая на практике оказывается не такой уж и стройной (недавние события ака хруст вс ядро).

Ответить | Правка | Наверх | Cообщить модератору

83. "Началось альфа-тестирование PHP 8.1" –1 +/–

Сообщение от Annoynymous (ok), 14-Июн-21, 10:31

У меня сайт на баше. Вообще не вижу проблемы.

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

104. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Аноним (104), 14-Июн-21, 22:13

На нем пишется очень много промолчу что он 'простой' все ошибки умирают вместе с интерпретатором после выполнения запроса

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

110. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Sw00p aka Jerom (?), 15-Июн-21, 01:48

> На нем пишется очень много промолчу что он 'простой' все ошибки умирают
> вместе с интерпретатором после выполнения запроса
@ убей все ошибки :) только за этот символ я его (пых) "ненавижу".

Ответить | Правка | Наверх | Cообщить модератору

128. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 15-Июн-21, 13:33

Просто не надо сверх меры применять, где не надо.
Оно не зря существует: в C вы вообще ничего не получите на выход, кроме кода ошибки, а здесь можете получить сверху дебажный вывод, который и подавляется @ там, где он ожидаем, но не нужен.
Допустим надо почитать сокет, и наплевать на то, что сие чтение может выстрелить дебагом ошибки - в данный конкретный момент. Все ошибки я обработаю оптом позже, или просто сокеты закрою, вне зависимости от состояния.

Ответить | Правка | Наверх | Cообщить модератору

145. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Sw00p aka Jerom (?), 17-Июн-21, 22:12

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

Ответить | Правка | Наверх | Cообщить модератору

129. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 15-Июн-21, 13:36

Впрочем, в восьмёрке некоторые файловые операции теперь стреляют эксепшнами, @#$%, и это @ не подавляется.
И если я раньше мог @unlink написать для удаления файла/симлинка, которого может не быть - то теперь мне надо лепить бойлерплейт из @is_file или try { } catch { } вокруг. Напрягает, пришлось для себя обернуть в unlinkSilently() :D

Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

136. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 16-Июн-21, 10:19

@is_file() кстати плохой бойлерплейт. Надо "почему" в список вопросов новичкам включить :D

Ответить | Правка | Наверх | Cообщить модератору

146. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Sw00p aka Jerom (?), 17-Июн-21, 22:18

> Напрягает, пришлось для себя обернуть в unlinkSilently() :D
через error_handler можно как игнорировать, так и выбрасывать исключения если функция их не поддерживает, но при этом нужно все оборачивать в try/catch

Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

53. "Началось альфа-тестирование PHP 8.1" –1 +/–

Сообщение от Skynin (?), 13-Июн-21, 19:38

Разработка на ЯП с статической типизацией - медленнее чем на ЯП с динамической, до определенного размера кодовой базы/команды. Может доходить до "в разы" медленнее.
Так что - никогда никакой ЯП с обязательной стат типизацией не заменит PHP/Python/Ruby/JS/(еще какой появится, мало ли)
"Академики" и прочие идеалисты пусть воют себе. Есть реалии разработки, которые формируют те кто платит деньги за разработку. А это никак не академики и форумные "ортодоксы" и пуристы.
А вот опциональные возможности статической проверки типов, будь то тайп хинтинг, или внешние анализаторы, по аннотациям к коду и т.д. и т.п. - да, дело полезное. Бывает - надо.

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

57. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Рева RarogCmex Денис (?), 13-Июн-21, 21:05

Я бы поспорил, сильно зависит от задачи и от языка. На том же хаскеле добавление прстой конкурентности или многопоточности зачастую требует всего трех-четырёх выражений.
Иногда одного достаточно, статья с хабра "сложность простоты" об этом. Товарищ просто заменил mapM на mapConcurently и получил ускорение в 4 раза.
Плюс в том же хаскеле автовывод типов есть уже 2 десятилетия как.
Короче, вывод простой: пилите, Шура, пилите, они золотые. Работать надо, а не коментарии писать.

Ответить | Правка | Наверх | Cообщить модератору

79. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Skynin (?), 14-Июн-21, 07:36

Автовывод типов не делает ЯП с статический типизацией языком с динамической типизацией.
А пример приведён смешной,студенческий. Разработка состоит чаще из другой работы, а не оптимизации быстродействия парой чудодейственных строчек кода

Ответить | Правка | Наверх | Cообщить модератору

21. "Началось альфа-тестирование PHP 8.1" +2 +/–

Сообщение от Онаним (?), 13-Июн-21, 12:38

> Добавлена поддержка легковесных потоков, именуемых файберами (Fiber)
Вау. Накотец-то, ей-богу.
У меня давно есть где их применить, очень много где.

Ответить | Правка | Наверх | Cообщить модератору

24. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 13-Июн-21, 12:53

(честно говоря задолбался писать обёртки вокруг разных селектов сокетов и прочих ожиданий состояния)

Ответить | Правка | Наверх | Cообщить модератору

60. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Аноним (60), 13-Июн-21, 21:29

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

Ответить | Правка | Наверх | Cообщить модератору

61. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 13-Июн-21, 22:11

Всё так. Речь исключительно про либо неблокирующие вызовы, либо очень малый таймаут.
Т.е. исключительно для проверки состояния.
Сейчас приходится всё это серьёзно обёртывать по сути карманной реализацией тех самых файберов, что имеет достаточно негативный эффект в плане потребления ресурсов проца, ну и за контекстом, который определяет точку "перевхода", в виде конечного автомата внутри - следить самостоятельно, что имеет те же последствия. Здесь же наконец-то можно будет избавиться от фиговой тучи бранчинга, заменив на линейный код с suspend-resume.

Ответить | Правка | Наверх | Cообщить модератору

64. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 13-Июн-21, 22:29

По сути fread()/fwrite() на стримах вполне себе может быть неблокирующий, включая сокеты.
socket_select()'у можно скормить 0 в таймаут, и он становится неблокирующим.
У MySQL есть асинхронное API, которое как раз хорошо на файберы ложится.
У CURL есть асинхронное API, которое как раз хорошо на файберы ложится.
В ZeroMQ и много ещё где тоже есть возможность делать неблокирующие вызовы.
Короче, пользы очень много. С тем же ZeroMQ например - там типовой случай, когда полон буфер на запись, и надо бы подождать. Без файберов поддержание очереди REQ/REP-based протокола например со своевременной отменой / пропагацией фейла - это сущий ад, на файберы оно ляжет просто прекрасно - можно убить сфейлившийся файбер и создать новый, который попытается заново согласовать внутренний протокол.

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

68. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Аноним (69), 13-Июн-21, 23:13

Вот только помимо самих файберов нужна реализация асинхронного апи в PDO, ext/curl и всем прочем.
Иначе все это закончится написанием асинхронных обвязок к libmysql и прочим libcurl на FFI, что, конечно, интересное упражнение, но ну его.

Ответить | Правка | Наверх | Cообщить модератору

71. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 13-Июн-21, 23:55

Ну, указанные уже есть.
Судя по тому, что они отдельно parallel с файберами тестировали уже - мы ещё и треды со временем увидим :D

Ответить | Правка | Наверх | Cообщить модератору

93. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Gemorroj (ok), 14-Июн-21, 13:27

так закопали треды же вроде https://github.com/krakjoe/pthreads

Ответить | Правка | Наверх | Cообщить модератору

94. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 14-Июн-21, 13:31

Совместимость с parallel тем не менее уже тестировали.
Собственно от parallel + файберов до тредов не так далеко.

Ответить | Правка | Наверх | Cообщить модератору

65. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 13-Июн-21, 22:31

Ещё даже без I/O - всякие шедулеры событий офигенно ложатся на файберы. Можно одновременно внутри кода стартовать несколько длинных событий, и забить на них, пока они не выполнятся. Параллельно что-то откуда-то почитывая (таймер например), и стартуя ещё по необходимости.

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

27. "Началось альфа-тестирование PHP 8.1" +2 +/–

Сообщение от Аноним (27), 13-Июн-21, 13:53

Ученые покусали редакторов опеннета.
>Добавлена поддержка легковесных потоков, именуемых файберами (Fiber) и позволяющими управлять распараллеливанием на низком уровне
Под "распараллеливанием" надо понимать non-blocking concurrent multitasking I\O. А не параллельное исполнение двух файберов.

Ответить | Правка | Наверх | Cообщить модератору

40. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 13-Июн-21, 16:10

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

Ответить | Правка | Наверх | Cообщить модератору

44. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Аноним (43), 13-Июн-21, 17:45

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

Ответить | Правка | Наверх | Cообщить модератору

38. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Аноним (38), 13-Июн-21, 16:03

Пхп в принципе норм, окромя отсутствием обратной совместимости.

Ответить | Правка | Наверх | Cообщить модератору

47. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Аноним (46), 13-Июн-21, 18:28

Тогда и node.js норм.

Ответить | Правка | Наверх | Cообщить модератору

51. "Началось альфа-тестирование PHP 8.1" –1 +/–

Сообщение от Онаним (?), 13-Июн-21, 19:27

duktape - норм
А node.js - это не язык.

Ответить | Правка | Наверх | Cообщить модератору

52. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 13-Июн-21, 19:27

(и не его реализация)
V8 - тоже норм

Ответить | Правка | Наверх | Cообщить модератору

55. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Аноним (55), 13-Июн-21, 20:55

Ну и синтаксис, жесть. И ещё говорят, что пхп прост для новичков

Ответить | Правка | Наверх | Cообщить модератору

62. "Началось альфа-тестирование PHP 8.1" +2 +/–

Сообщение от Онаним (?), 13-Июн-21, 22:13

Порог вхождения в PHP уже давно за пределами новичкового.
Просто сохранившееся старое заблуждение :)

Ответить | Правка | Наверх | Cообщить модератору

66. "Началось альфа-тестирование PHP 8.1" +2 +/–

Сообщение от Аноним (38), 13-Июн-21, 22:32

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

Ответить | Правка | Наверх | Cообщить модератору

63. "Началось альфа-тестирование PHP 8.1" –1 +/–

Сообщение от Онаним (?), 13-Июн-21, 22:14

С другой стороны синтаксис в общем виде C-подобен, поэтому если есть опыт с C, и нет застарелых костей в мозге на предмет строгой типизации - проблем не будет.

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

137. "Началось альфа-тестирование PHP 8.1" –1 +/–

Сообщение от InuYasha (??), 16-Июн-21, 22:44

По жизни с пятисотками? )
Я сомтрю, доброта через забор переливается, если ты желаешь кому-то жить с:
Type error: Argument 1 passed to App\Api::setInitParams() must be of the type integer, string given, called in /opt/AppBase/src/ApiBundle/EventHandler.php on line 422
ну, или классическим Expected argument of type "integer", "null" given.

Ответить | Правка | Наверх | Cообщить модератору

139. "Началось альфа-тестирование PHP 8.1" –1 +/–

Сообщение от Онаним (?), 17-Июн-21, 09:16

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

Ответить | Правка | Наверх | Cообщить модератору

140. "Началось альфа-тестирование PHP 8.1" –1 +/–

Сообщение от InuYasha (??), 17-Июн-21, 10:11

У вас, пыхарей, наверное, две жизни. И одну из них вы тратите на санацию аргументов. )

Ответить | Правка | Наверх | Cообщить модератору

144. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 17-Июн-21, 13:32

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

Ответить | Правка | Наверх | Cообщить модератору

56. "Началось альфа-тестирование PHP 8.1" –1 +/–

Сообщение от Рева RarogCmex Денис (?), 13-Июн-21, 20:59

Интересно, такими темпами PHP дорастёт до Хаскеля или даже выше? Когда зависимые типы туда добавят?

Ответить | Правка | Наверх | Cообщить модератору

58. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Lex (??), 13-Июн-21, 21:18

Уже давно перерос если сравнивать количество проектов в т.ч новых с применением того и другого

Ответить | Правка | Наверх | Cообщить модератору

101. "Началось альфа-тестирование PHP 8.1" –1 +/–

Сообщение от Аноним (101), 14-Июн-21, 17:51

Вот только качество и количество это разные вещи xD

Ответить | Правка | Наверх | Cообщить модератору

122. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Lex (??), 15-Июн-21, 11:28

> Вот только качество и количество это разные вещи xD
Применительно к ЯП - нет. Даже наоборот - фактически, бОльшее количество говорит о лучшем общем качестве экосистемы.
Чем более ЯП и его инфраструктура применимы к конкретной задаче - тем больше делается проектов его базе.

Ответить | Правка | Наверх | Cообщить модератору

86. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Плюсовик (?), 14-Июн-21, 10:42

>Интересно, такими темпами PHP дорастёт до Хаскеля или даже выше?
Эти два языка создавались для выполнения разных задач и идут разными путями.
Это как автобус и самосвал. И то, и другое автомобиль, но эксплуатация их в корне различается.

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

72. "Началось альфа-тестирование PHP 8.1" +2 +/–

Сообщение от Онаним (?), 13-Июн-21, 23:57

Как жы я это пропустил-то
> Добавлена возможность использования префиксов "0o" и "0O" для восьмеричных чисел
А можно ещё 0_o и 0_O?

Ответить | Правка | Наверх | Cообщить модератору

73. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Аноним (73), 14-Июн-21, 00:41

О0о0O

Ответить | Правка | Наверх | Cообщить модератору

74. "Началось альфа-тестирование PHP 8.1" +2 +/–

Сообщение от Аноним (73), 14-Июн-21, 00:41

> А можно ещё 0_o и 0_O?
Да: (_O_)

Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

92. "Началось альфа-тестирование PHP 8.1" +7 +/–

Сообщение от Led (ok), 14-Июн-21, 12:53

>Да: (_O_)
Это только для маководов.

Ответить | Правка | Наверх | Cообщить модератору

98. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Аноним (80), 14-Июн-21, 15:11

это для местных анонимных коментаторов

Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

117. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Здрасьте (?), 15-Июн-21, 07:59

Можно так: 0_0 (подчерк — допустимый разделитель в числах).

Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

118. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Онаним (?), 15-Июн-21, 08:19

0_0 да, но оно не отражает всех моих эмоций, особенно при использовании восьмеричных чисел за пределами chmod().

Ответить | Правка | Наверх | Cообщить модератору

103. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Аноним (103), 14-Июн-21, 21:04

Помянем.

Ответить | Правка | Наверх | Cообщить модератору

106. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Уася (?), 14-Июн-21, 23:16

Автор! Исправь листинги! Не нужны эти 4 пробела спереди строк.
И также используй всегда два пробела в статьях, конвертни в prettier онлайн. А то с телефона это не читается, а хотя могло бы!

Ответить | Правка | Наверх | Cообщить модератору

119. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Аноним (119), 15-Июн-21, 08:39

> $array1 = ["a" => 1];
> $array2 = ["b" => 2];
> $array = ["a" => 0, ...$array1, ...$array2];
> var_dump($array); // ["a" => 1, "b" => 2]
В vardump'е ["a" => 0] не потерялось?

Ответить | Правка | Наверх | Cообщить модератору

123. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от Аноним (123), 15-Июн-21, 11:38

Его заменило "a" => 1.

Ответить | Правка | Наверх | Cообщить модератору

127. "Началось альфа-тестирование PHP 8.1" +/–

Сообщение от Онаним (?), 15-Июн-21, 13:29

Не, всё ок. Одинаковый ключ, значение заменяется на последнее.

Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

138. "Началось альфа-тестирование PHP 8.1" +1 +/–

Сообщение от АнонимнаяЗалупа (?), 17-Июн-21, 04:21

PHP для богов

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Началось альфа-тестирование PHP 8.1"	+1 +/–
Сообщение от lockywolf (ok), 13-Июн-21, 09:40
>Появился новый тип "never", который можно использовать для информирования статических анализаторов о том, что функция прекращает выполнение программы, например, вызывая исключение или выполняя функцию exit. Так и до хвостовой рекурсии недалеко.
Ответить \| Правка \| Наверх \| Cообщить модератору

2. "Началось альфа-тестирование PHP 8.1"	–38 +/–
Сообщение от Qwerty (??), 13-Июн-21, 09:46
А оно ещё живо? Кто-то на этом пишет?
Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Началось альфа-тестирование PHP 8.1"	+12 +/–
	Сообщение от Mad max (?), 13-Июн-21, 10:06
	Посмотри вакансии, дурачок. Люди получают неплохие деньги.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Началось альфа-тестирование PHP 8.1"	+/–
	Сообщение от Аноним (11), 13-Июн-21, 10:51
	Ну да больше 0 это неплохой результат.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Началось альфа-тестирование PHP 8.1"	+/–
	Сообщение от КО (?), 13-Июн-21, 10:54
	Лучше задумайтесь почему так много этих вакансий.
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	15. "Началось альфа-тестирование PHP 8.1"	+4 +/–
	Сообщение от Аноним (15), 13-Июн-21, 11:45
	Легаси допиливать?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "Началось альфа-тестирование PHP 8.1"	+6 +/–
	Сообщение от Lex (??), 13-Июн-21, 14:09
	Потому что джава - сильно жЫрно, плюсЫ - громоздко, а питон - медленно
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	29. "Началось альфа-тестирование PHP 8.1"	+3 +/–
	Сообщение от Aukamo (ok), 13-Июн-21, 14:28
	А ещё потому что PHP стал мейнстримом для "dynamic web" в нужное время и для него даже компилятор запилили. Постоены гигантские инфраструктуры, способные видерживать солидные нагрузки и хостить кучу клиентов. Есть море CMS и т.д. обещающие всё готовое из коробки, и да, если вам надо просто ребрендинг сделать, зачем платить больше? Меня всегда на изнанку выворачивало от PHP. За язык его не считаю, но, когда мне надо завести блог, первым делом о WordPress вспоминаю, а не о django\flask & spring (или что там для java).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	34. "Началось альфа-тестирование PHP 8.1"	+1 +/–
	Сообщение от Плюсовик (?), 13-Июн-21, 15:00
	>первым делом о WordPress вспоминаю, а не о django\flask & spring (или что там для java) Аналогично. От php восторга не испытываю, но в своем сегменте ему нет равных. Java и Ко идет лесом, только для жирного бизнеса. Она раскрывается при хорошем вливании денег и предоставлении больших мощностей железа. Python... Даже с приходом asyncio и недоделанных либ aio* ситуация не лучше. Ruby, Rails... Потыкал палочкой, что-то не зашло. Go слишком много самому нужно делать, а я ленивый старый пень. То, что предоставляет nodejs заслуживает внимание, но прихожу в ужас от всех этих реактов и так далее. Тут мы подпорку из реек сделаем, а тут изоленту применим, а там... ммм... степлером пройдем.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	121. "Началось альфа-тестирование PHP 8.1"	–1 +/–
	Сообщение от MVK (??), 15-Июн-21, 10:42
	>Java и Ко идет лесом, только для жирного бизнеса. Она раскрывается при хорошем вливании денег и предоставлении больших мощностей железа. - чепуха
	Ответить \| Правка \| Наверх \| Cообщить модератору


	130. "Началось альфа-тестирование PHP 8.1"	+1 +/–
	Сообщение от Аноним (130), 15-Июн-21, 16:47
	>>Java и Ко идет лесом, только для жирного бизнеса. Она раскрывается при хорошем вливании денег и предоставлении больших мощностей железа. >- чепуха Совсем не чепуха. Большая часть функционала PHP реализуется C++, а вот Java отдаёт C++ в лучшем случае переходы в libc. Так как Java-машина очень не спешит компилировать байт-код в машинный, то производительность половину времени примерно как у bochs. Так же сборщик мусора неадекватен и требует указания того, при каком объёме памяти необходимо вызвать сборку мусора. Она не будет вызвана раньше выделения этого объёма, а так же не даст выделить больше. От того Java славится своей прожорливостью к памяти. У того же .NET нет такой проблемы, частичная сборка мусора происходит по таймеру, а так же система сама уведомляет приложения, что надо бы затянуть пояса. Конечно это вс
	Ответить \| Правка \| Наверх \| Cообщить модератору


	131. "Началось альфа-тестирование PHP 8.1"	+1 +/–
	Сообщение от Аноним (130), 15-Июн-21, 16:48
	всё проблемы конкретной реализации, то другой в общем то нет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	141. "Началось альфа-тестирование PHP 8.1"	+/–
	Сообщение от MVK (??), 17-Июн-21, 11:24
	>Большая часть функционала PHP реализуется C++, а вот Java отдаёт C++ в лучшем случае переходы в libc - интересно, но объясните тогда почему тогда PHP так нуждается в различных кэшах и оптимайзерах (и даже с ними он проигрывает по производительности Java)? >Так как Java-машина очень не спешит компилировать байт-код в машинный - откуда дровишки? На сервере (см. термин Server-Class Machine) JVM работает в режиме -server (что означает прекомпиляцию кода) >сборщик мусора неадекватен и требует указания того, при каком объёме памяти необходимо вызвать сборку мусора - какой сборщик? Как минимум штуки три различных алгоритма сборки можно использовать исходя из особенностей проекта. Однакож, те задачи на которых понадобится тюнинг сборщика мусора в JVM, для PHP просто неподъемны >От того Java славится своей прожорливостью к памяти - дурак и хрен сломать может. В моей практике высоконагруженные приложения вертелись на 32Мб хипа >У того же .NET нет такой проблемы - ну вот и сравнивайте его с PHP
	Ответить \| Правка \| К родителю #130 \| Наверх \| Cообщить модератору


	142. "Началось альфа-тестирование PHP 8.1"	+/–
	Сообщение от Аноним (130), 17-Июн-21, 12:42
	> - интересно, но объясните тогда почему тогда PHP так нуждается в различных > кэшах и оптимайзерах Потому, что базы данных не умеют толково кешировать запросы. >(и даже с ними он проигрывает по производительности > Java)? Не видел ни одного быстрого сайта на Java, а вот быстрые сайты на PHP делаются легко. Не стоит судить о производительности PHP по WordPress. Java лучше после разогрева в числодробилках реализованных на Java, на реальных задачах она тормозит и не может потягаться в производительности числодробилок реализованных на C++ и просто вызванных из PHP. Сам JIT-компилятор php пока посредственный. > - откуда дровишки? На сервере (см. термин Server-Class Machine) JVM работает в > режиме -server (что означает прекомпиляцию кода) -client уже многие годы игнорируется, то есть вообще всё работает режиме -server. В режиме -server jvm позволяет себе более агрессивные оптимизации. Откуда Вы вытащили, что Java полностью компилирует каждый встреченный при выполнении метод? Для этого есть отдельная опция и с ней программа действительнои надолго замирает при встрече каждого ранее невызваного метода. Но эта опция отключена по умолчанию в любом режиме. > - какой сборщик? Как минимум штуки три различных алгоритма сборки можно использовать > исходя из особенностей проекта. Однакож, те задачи на которых понадобится тюнинг > сборщика мусора в JVM, для PHP просто неподъемны Любой сборщик мусора Java жрёт ровно столько, сколько разрешили. Не больше и не меньше. Чтобы выжрать гигабайты памяти на секунду, а затем вернуться к еденицам мегабайт не обязательно иметь высокую производительность самого PHP, только его библиотек. > - дурак и хрен сломать может. В моей практике высоконагруженные приложения вертелись > на 32Мб хипа И тормозили из за невозможности аллоциррвать большой объём памяти. Или высоконагруженные они только по количеству одновременных запросов, а не по обработке больших данных. С тем же успехом можно было реализовать тяжёлые места на C++ и приклеить к PHP и этот кусок кода будет работать быстрее того, что написан на Java. В этом суть любого скриптинга. У Java же вообще всё написано на Java, а jit-компилятор Java заведомо хуже компиляторов C++.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	143. "Началось альфа-тестирование PHP 8.1"	+/–
	Сообщение от MVK (??), 17-Июн-21, 13:18
	>Потому, что базы данных не умеют толково кешировать запросы - на PHP не могут, а на Java могут? Ах, да там же есть транзакционный и L2 кэши >Не видел ни одного быстрого сайта на Java, а вот быстрые сайты на PHP делаются легко - может еще увидите) Вот к примеру трейдинговые приложения пишут в основном на Java, наверное извращенцы)) >Не стоит судить о производительности PHP по WordPress - не стоит судить о Java по технологии портлетов >на реальных задачах она тормозит - ни о чем (про тейдинговые приложения я уже вспоминал)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	41. "Началось альфа-тестирование PHP 8.1"	+6 +/–
	Сообщение от pda (ok), 13-Июн-21, 17:03
	Он уже давно вполне себе язык.
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору


	35. "Началось альфа-тестирование PHP 8.1"	–3 +/–
	Сообщение от starlette (?), 13-Июн-21, 15:33
	Можно подумать, Ларавель, Вордпресс и прочие поделия - это быстро. Да на Питоне нужно сильно постараться, чтобы написать что-то более тормозное чем на большинстве PHP фреймворках или CMS.
	Ответить \| Правка \| К родителю #28 \| Наверх \| Cообщить модератору


	39. "Началось альфа-тестирование PHP 8.1"	+9 +/–
	Сообщение от Онаним (?), 13-Июн-21, 16:08
	Вот только одна проблема: на PHP таки написано. А на питоне лет двадцать всё те же "нужно сильно постараться"...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	113. "Началось альфа-тестирование PHP 8.1"	–1 +/–
	Сообщение от Аноним (113), 15-Июн-21, 03:24
	Лучше бы вообще не писали. Ни на одном языке не написано столько откровенной дряни как на этом шаблонизаторе.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	126. "Началось альфа-тестирование PHP 8.1"	+/–
	Сообщение от z (??), 15-Июн-21, 12:56
	а ты конечно лично каждую строку проверил, написанную каждым школьником на бейсике, и у тебя статья на эту тему конечно же есть опубликованная в солидном издании.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	48. "Началось альфа-тестирование PHP 8.1"	+1 +/–
	Сообщение от Плюсовик (?), 13-Июн-21, 18:52
	Приведи аналоги Laravel, WordPress, Symfony для Python. Django да и все. Остальные микрофреймворки разной степени готовности со статусом от "в процессе проектирования" до "не готово".
	Ответить \| Правка \| К родителю #35 \| Наверх \| Cообщить модератору


	115. "Началось альфа-тестирование PHP 8.1"	+/–
	Сообщение от Аноним (115), 15-Июн-21, 03:48
	Их нету, поскольку такую кучу г-на только на похапе написать и можно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	49. "Началось альфа-тестирование PHP 8.1"	+3 +/–
	Сообщение от Плюсовик (?), 13-Июн-21, 18:58
	>Питоне нужно сильно постараться, чтобы написать что-то более тормозное чем на большинстве PHP фреймворках или CMS. Видал я тут на Flask админку к базе одной популярной СУБД. Описывать можно только нецензурными словами.
	Ответить \| Правка \| К родителю #35 \| Наверх \| Cообщить модератору


	25. "Началось альфа-тестирование PHP 8.1"	+7 +/–
	Сообщение от Аноним (25), 13-Июн-21, 13:04
	Если бы существовали альтернативы, предоставляющие, хотя бы, тот же уровень возможностей при, хотя бы, том же уровне усилий, то, возможно, от него бы начали отказываться. А так, альтернатив в вебе особо то и не густо.
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	26. "Началось альфа-тестирование PHP 8.1"	+3 +/–
	Сообщение от ананоша (?), 13-Июн-21, 13:48
	Пишу сейчас бэк на типскрипт, лучше бы на пыхе+симфони писал
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	30. "Началось альфа-тестирование PHP 8.1"	–1 +/–
	Сообщение от Aukamo (ok), 13-Июн-21, 14:29
	Обоснуй UPD: помимо того что там бывают ситуации с типами данных, мягко говоря, неприятные.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	42. "Началось альфа-тестирование PHP 8.1"	+3 +/–
	Сообщение от ананоша (?), 13-Июн-21, 17:04
	Не вижу гибкого мейнстримного фреймворка уровня симфони, на который не забьют через полгода
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Началось альфа-тестирование PHP 8.1"	+/–
	Сообщение от Аноним (43), 13-Июн-21, 17:41
	NestJS
	Ответить \| Правка \| Наверх \| Cообщить модератору


	69. "Началось альфа-тестирование PHP 8.1"	+/–
	Сообщение от Аноним (69), 13-Июн-21, 23:15
	Только typeorm брать не надо, его автор вообще не в курсе, что такое ORM, и годами не понимает, зачем править очевидные архитектурные ляпы типа вызова конструктора при гидрации. надо брать Mikro-ORM, он активно развивается, и изначально реализуется как полноценный Unit-Of-Work Data Mapper.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	75. "Началось альфа-тестирование PHP 8.1"	+1 +/–
	Сообщение от ананоша (?), 14-Июн-21, 02:45
	Это который пилится одним поляком?
	Ответить \| Правка \| К родителю #43 \| Наверх \| Cообщить модератору