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

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

Сообщения

[Сортировка по ответам | RSS]

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

2. Сообщение от Qwerty (??), 13-Июн-21, 09:46	–38 +/–
А оно ещё живо? Кто-то на этом пишет?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #25, #26

3. Сообщение от Аноним (3), 13-Июн-21, 09:54	–4 +/–
Статический анализатор в PHP настолько беспомощен, что не может понять, что в функции содержится вызов exit или бросает исключение и поэтому надо переложить написание лишних подсказок на плечи разработчика? А синтаксис перечисления нельзя было взять из Си  или TypeScipt?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #9, #10, #80, #81

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

5. Сообщение от Аноним (5), 13-Июн-21, 10:14	+1 +/–
Нет нельзя! Надо было обязательно слепить что-то среднее между enum'ом и switch'ом, чтобы не как у всех было)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

7. Сообщение от onanim (?), 13-Июн-21, 10:36	–22 +/–
кошмар. делали user-friendly C, а получился вырвиглазный Rust.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #31, #70, #114

8. Сообщение от InuYasha (??), 13-Июн-21, 10:39	–10 +/–
Пока статическую типизаицю не введут, плюс не поставлю. Но они не введут. И уже не ввели. Путь едят кактус.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #22, #45

9. Сообщение от Варенье (?), 13-Июн-21, 10:40	–3 +/–
> А синтаксис перечисления нельзя было взять из Си  или TypeScipt? Подозреваю что лексер они сильно переусложнять не хотели, поэтому взяли синтаксис из Swift
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

10. Сообщение от Ordu (ok), 13-Июн-21, 10:47	+6 +/–
> Статический анализатор в 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".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #95

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

12. Сообщение от Аноним (11), 13-Июн-21, 10:53	+2 +/–
Это сегрегация все типы должны иметь равные возможности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #16

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

14. Сообщение от Аноним (14), 13-Июн-21, 11:33	+1 +/–
А не проще ли с таким синтаксисом писать сразу на статически типизируемом языке?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17, #23, #53

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

16. Сообщение от Аноним (15), 13-Июн-21, 11:46	+2 +/–
И делить на ноль надо разрешить, оскорбление нуля!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #20, #37, #54, #85, #120

17. Сообщение от acroobat (??), 13-Июн-21, 11:54	+/–
Опять со своим руби лезут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #18

18. Сообщение от Аноним (18), 13-Июн-21, 12:03	–2 +/–
А ты не завидуй.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

20. Сообщение от anonymous (??), 13-Июн-21, 12:27	+/–
Никто не мешает добавить число бесконечность (беззнаковый, как в сфере Римана) и разрешить деление на ноль.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #111

21. Сообщение от Онаним (?), 13-Июн-21, 12:38	+2 +/–
> Добавлена поддержка легковесных потоков, именуемых файберами (Fiber) Вау. Накотец-то, ей-богу. У меня давно есть где их применить, очень много где.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24

22. Сообщение от Онаним (?), 13-Июн-21, 12:51	+1 +/–
PHP - язык с динамической типизацией изначально, и будет таковым. Меня например даже напрягает этот последний сахар для не осиливших парадигму.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #87

23. Сообщение от Онаним (?), 13-Июн-21, 12:53	+3 +/–
Проще. Собственно писать на PHP никто за хвост никого не тянет - но на нём пишется очень много. Это показатель того, что язык удобен для своих задач.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #46, #104

24. Сообщение от Онаним (?), 13-Июн-21, 12:53	+/–
(честно говоря задолбался писать обёртки вокруг разных селектов сокетов и прочих ожиданий состояния)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #60

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

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

27. Сообщение от Аноним (27), 13-Июн-21, 13:53	+2 +/–
Ученые покусали редакторов опеннета. >Добавлена поддержка легковесных потоков, именуемых файберами (Fiber) и позволяющими управлять распараллеливанием на низком уровне Под "распараллеливанием" надо понимать non-blocking concurrent multitasking I\O. А не параллельное исполнение двух файберов.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #40

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

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

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

31. Сообщение от Aukamo (ok), 13-Июн-21, 14:33	+4 +/–
Ставил минус ибо не понял: при чём тут Rust, вообще?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #33

33. Сообщение от Аноним (33), 13-Июн-21, 14:40	–1 +/–
Тоже минус. Лучшего синтаксиса мои глаза не видели.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

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

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

37. Сообщение от Sw00p aka Jerom (?), 13-Июн-21, 15:40	+/–
а че тут такого, этоже по факту функция рандома.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

38. Сообщение от Аноним (38), 13-Июн-21, 16:03	+/–
Пхп в принципе норм, окромя отсутствием обратной совместимости.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #47

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

40. Сообщение от Онаним (?), 13-Июн-21, 16:10	+/–
Там нет параллельного исполнения вообще, кстати. Там кооперативное исполнение блокирующих друг друга псевдопотоков - то есть никакого чистого параллелизма нет, и на несколько ядер не раскинуть, но зато это очень удобно с т.з. организации ожидания ввода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #44

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

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

43. Сообщение от Аноним (43), 13-Июн-21, 17:41	+/–
NestJS
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #69, #75

44. Сообщение от Аноним (43), 13-Июн-21, 17:45	+/–
Так на пхп и пишут код, который большую часть времени ожидает ввода-вывода - например, ждёт выполнения запроса к MySQL. Числодробилки на пхп вряд ли кому-то придёт в голову писать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

45. Сообщение от Lex (??), 13-Июн-21, 17:57	+6 +/–
Дык ввели. «Си» называется. Можешь поставить ему плюсик и начинать кодить на нем сайты
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #99

46. Сообщение от Аноним (46), 13-Июн-21, 18:25	–7 +/–
Миллионы мух. На баше тоже много написано, но это вообще ни о чем не говорит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #50, #83

47. Сообщение от Аноним (46), 13-Июн-21, 18:28	+/–
Тогда и node.js норм.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #51

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

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

50. Сообщение от Онаним (?), 13-Июн-21, 19:19	+4 +/–
Говорит. О том, что он удобен для своих задач. В отличие от хипстерских поделок со "стройной идеологией"... и ничем, кроме идеологии, которая на практике оказывается не такой уж и стройной (недавние события ака хруст вс ядро).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

51. Сообщение от Онаним (?), 13-Июн-21, 19:27	–1 +/–
duktape - норм А node.js - это не язык.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #52

52. Сообщение от Онаним (?), 13-Июн-21, 19:27	+/–
(и не его реализация) V8 - тоже норм
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

53. Сообщение от Skynin (?), 13-Июн-21, 19:38	–1 +/–
Разработка на ЯП с статической типизацией - медленнее чем на ЯП с динамической, до определенного размера кодовой базы/команды. Может доходить до "в разы" медленнее. Так что - никогда никакой ЯП с обязательной стат типизацией не заменит PHP/Python/Ruby/JS/(еще какой появится, мало ли) "Академики" и прочие идеалисты пусть воют себе. Есть реалии разработки, которые формируют те кто платит деньги за разработку. А это никак не академики и форумные "ортодоксы" и пуристы. А вот опциональные возможности статической проверки типов, будь то тайп хинтинг, или внешние анализаторы, по аннотациям к коду и т.д. и т.п. - да, дело полезное. Бывает - надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #57

54. Сообщение от Ag (ok), 13-Июн-21, 19:47	+1 +/–
Тогда  вам нужен APL, правда там только 0 / 0 (даст 1). Но все же хоть какая то инклюзивность ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

55. Сообщение от Аноним (55), 13-Июн-21, 20:55	+/–
Ну и синтаксис, жесть. И ещё говорят, что пхп прост для новичков
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #62, #63

56. Сообщение от Рева RarogCmex Денис (?), 13-Июн-21, 20:59	–1 +/–
Интересно, такими темпами PHP дорастёт до Хаскеля или даже выше? Когда зависимые типы туда добавят?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #58, #86

57. Сообщение от Рева RarogCmex Денис (?), 13-Июн-21, 21:05	+/–
Я бы поспорил, сильно зависит от задачи и от языка. На том же хаскеле добавление прстой конкурентности или многопоточности зачастую требует всего трех-четырёх выражений. Иногда одного достаточно, статья с хабра "сложность простоты" об этом. Товарищ просто заменил mapM на mapConcurently и получил ускорение в 4 раза. Плюс в том же хаскеле автовывод типов есть уже 2 десятилетия как. Короче, вывод простой: пилите, Шура, пилите, они золотые. Работать надо, а не коментарии писать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #79

58. Сообщение от Lex (??), 13-Июн-21, 21:18	+/–
Уже давно перерос если сравнивать количество проектов в т.ч новых с применением того и другого
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #101

59. Сообщение от Ненавижу SJW (?), 13-Июн-21, 21:20	–1 +/–
Express?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #67, #76

60. Сообщение от Аноним (60), 13-Июн-21, 21:29	+1 +/–
Я не пхп-шник, но всякие селекты и прочие функции которые ожидают события в ядре как минимум нужно адаптировать под файберы, так как это по факту кооперативная многозадачность и селект в одном файбере положит все синхронное ядро пхп в спячку. Поправьте, если не так
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #61, #64, #65

61. Сообщение от Онаним (?), 13-Июн-21, 22:11	+/–
Всё так. Речь исключительно про либо неблокирующие вызовы, либо очень малый таймаут. Т.е. исключительно для проверки состояния. Сейчас приходится всё это серьёзно обёртывать по сути карманной реализацией тех самых файберов, что имеет достаточно негативный эффект в плане потребления ресурсов проца, ну и за контекстом, который определяет точку "перевхода", в виде конечного автомата внутри - следить самостоятельно, что имеет те же последствия. Здесь же наконец-то можно будет избавиться от фиговой тучи бранчинга, заменив на линейный код с suspend-resume.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

62. Сообщение от Онаним (?), 13-Июн-21, 22:13	+2 +/–
Порог вхождения в PHP уже давно за пределами новичкового. Просто сохранившееся старое заблуждение :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #66

63. Сообщение от Онаним (?), 13-Июн-21, 22:14	–1 +/–
С другой стороны синтаксис в общем виде C-подобен, поэтому если есть опыт с C, и нет застарелых костей в мозге на предмет строгой типизации - проблем не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #137

64. Сообщение от Онаним (?), 13-Июн-21, 22:29	+/–
По сути fread()/fwrite() на стримах вполне себе может быть неблокирующий, включая сокеты. socket_select()'у можно скормить 0 в таймаут, и он становится неблокирующим. У MySQL есть асинхронное API, которое как раз хорошо на файберы ложится. У CURL есть асинхронное API, которое как раз хорошо на файберы ложится. В ZeroMQ и много ещё где тоже есть возможность делать неблокирующие вызовы. Короче, пользы очень много. С тем же ZeroMQ например - там типовой случай, когда полон буфер на запись, и надо бы подождать. Без файберов поддержание очереди REQ/REP-based протокола например со своевременной отменой / пропагацией фейла - это сущий ад, на файберы оно ляжет просто прекрасно - можно убить сфейлившийся файбер и создать новый, который попытается заново согласовать внутренний протокол.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #68

65. Сообщение от Онаним (?), 13-Июн-21, 22:31	+/–
Ещё даже без I/O - всякие шедулеры событий офигенно ложатся на файберы. Можно одновременно внутри кода стартовать несколько длинных событий, и забить на них, пока они не выполнятся. Параллельно что-то откуда-то почитывая (таймер например), и стартуя ещё по необходимости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

66. Сообщение от Аноним (38), 13-Июн-21, 22:32	+2 +/–
Новички уже совсем не те. Раньше смузи не пили, потому и вкатывались в инженерные и прочие не тривиальные вещи легче, т.к. мозги были направлены на решение задач, а не на ритуалы скрам, бородки и балансбоарды всякие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

67. Сообщение от Аноним (69), 13-Июн-21, 23:08	+1 +/–
Экспресс низкоуровневый. Это скорее сравнимо с компонентами Symfony HttpFoundation, чем с самим Symfony.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

68. Сообщение от Аноним (69), 13-Июн-21, 23:13	+/–
Вот только помимо самих файберов нужна реализация асинхронного апи в PDO, ext/curl и всем прочем. Иначе все это закончится написанием асинхронных обвязок к libmysql и прочим libcurl на FFI, что, конечно, интересное упражнение, но ну его.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #71

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

70. Сообщение от СССР (?), 13-Июн-21, 23:24	+3 +/–
но лучше чем питон
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

71. Сообщение от Онаним (?), 13-Июн-21, 23:55	+/–
Ну, указанные уже есть. Судя по тому, что они отдельно parallel с файберами тестировали уже - мы ещё и треды со временем увидим :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #93

72. Сообщение от Онаним (?), 13-Июн-21, 23:57	+2 +/–
Как жы я это пропустил-то > Добавлена возможность использования префиксов "0o" и "0O" для восьмеричных чисел А можно ещё 0_o и 0_O?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #73, #74, #117

73. Сообщение от Аноним (73), 14-Июн-21, 00:41	+/–
О0о0O
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

74. Сообщение от Аноним (73), 14-Июн-21, 00:41	+2 +/–
> А можно ещё 0_o и 0_O? Да: (_O_)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #92, #98

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

76. Сообщение от ананоша (?), 14-Июн-21, 02:47	+1 +/–
Ну да, его и используем конечно же. Страшная вещь)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

77. Сообщение от Аноним (69), 14-Июн-21, 05:51	–1 +/–
Точно так же, как Symfony пилится одним французом (давно уже нет).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

79. Сообщение от Skynin (?), 14-Июн-21, 07:36	+1 +/–
Автовывод типов не делает ЯП с статический типизацией языком с динамической типизацией. А пример приведён смешной,студенческий. Разработка состоит чаще из другой работы, а не оптимизации быстродействия парой чудодейственных строчек кода
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

80. Сообщение от Аноним (80), 14-Июн-21, 09:25	+/–
Что еще ожидать от недоразвитых вебмакак неспособных даже написать помощьный статический анализатор. Анонимным эксперам всё ясно с php, давно. Единственное что анонимным экспертам не ясно, что же такое статический анализатор и зачем он нужен. А так же зачем тип Nothing в kotlin, never в swift и typescript.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

81. Сообщение от Онаним (?), 14-Июн-21, 10:07	+1 +/–
Статический анализатор в динамическом языке... Печалька. Оно вообще может управление отдать через call_user_func(['ex'.chr(105).'t']);, и хрен ты это анализатором разберёшь, грубо говоря. Для продвинутых анализаторов можно пример ещё усложнить, обвешав вызовами C'шного API.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #82, #84, #109

82. Сообщение от Онаним (?), 14-Июн-21, 10:07	+/–
// квадратные скобки лишние, сорян
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

83. Сообщение от Annoynymous (ok), 14-Июн-21, 10:31	–1 +/–
У меня сайт на баше. Вообще не вижу проблемы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

84. Сообщение от Аноним (80), 14-Июн-21, 10:37	+/–
в php вообще-то есть статическая типизация для аргуметов функций и полей классов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #89, #91

85. Сообщение от Аноним (85), 14-Июн-21, 10:38	+1 +/–
В Джаваскрипте можно делать на 0 будет Infininty. Можно даже стринг поделить на ноль будет NaN. Вот где свобода и права всех типов соблюдены.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #107

86. Сообщение от Плюсовик (?), 14-Июн-21, 10:42	+/–
>Интересно, такими темпами PHP дорастёт до Хаскеля или даже выше? Эти два языка создавались для выполнения разных задач и идут разными путями. Это как автобус и самосвал. И то, и другое автомобиль, но эксплуатация их в корне различается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

87. Сообщение от Аноним (85), 14-Июн-21, 10:43	+1 +/–
PHP язык со слабой неявной динамической типизацией. Хотя нужно это только для собеседования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #88, #116

88. Сообщение от Онаним (?), 14-Июн-21, 12:05	+/–
Да и для собеседования не особо нужно, но таки да. Кстати половина режется на оптимизации in_array() для большого числа выборок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

89. Сообщение от Онаним (?), 14-Июн-21, 12:07	+/–
Там скорее тайпчек частично на этапе трансляции, а в основном - в рантайме.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #90

90. Сообщение от Онаним (?), 14-Июн-21, 12:08	+/–
(потому что не для констант и предсказуемых вызовов финальный тип становится известен только в рантайме)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

91. Сообщение от Онаним (?), 14-Июн-21, 12:10	+/–
(ну то есть к реальной статический типизации это имеет слабое отношение, хотя часть оптимизаций применима, конечно же)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

92. Сообщение от Led (ok), 14-Июн-21, 12:53	+7 +/–
>Да: (_O_) Это только для маководов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

93. Сообщение от Gemorroj (ok), 14-Июн-21, 13:27	+/–
так закопали треды же вроде https://github.com/krakjoe/pthreads
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #94

94. Сообщение от Онаним (?), 14-Июн-21, 13:31	+/–
Совместимость с parallel тем не менее уже тестировали. Собственно от parallel + файберов до тредов не так далеко.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

95. Сообщение от Sw00p aka Jerom (?), 14-Июн-21, 13:39	+/–
>Если ты вызываешь из кода php функцию на C, которая прерывает выполнение программы а смысл тогда в статическом анализаторе для языка который по факту является оберткой другого языка?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #96

96. Сообщение от Ordu (ok), 14-Июн-21, 14:51	+1 +/–
>>Если ты вызываешь из кода php функцию на C, которая прерывает выполнение программы > а смысл тогда в статическом анализаторе для языка который по факту является > оберткой другого языка? Я даже не знаю что сказать на это. Что значит "язык является обёрткой другого языка"? Язык C является обёрткой для асма? C++ является обёрткой для C? Как я не кручу в голове твои обёртки, пытаясь понять, что ты хотел сказать, я не могу понять какое это отношение имеет к полезности статического анализатора. Давай мы лучше замнём тему, сделаем вид, что никаких обёрток и не было, и я просто расскажу тебе, зачем статическому анализатору нужно знать про no-return функции? Всё очень просто: если статический анализатор знает, что функция не возвращает управления и завершает программу, то он может сделать вывод, что "вечный" цикл вовсе не вечный, а значит инкремент индекса не выползет за границы буфера. Или может статический анализатор увидит, что один из путей выполнения функции, набитой ветвлениями, не возвращает значения -- он будет ругаться, но если он увидит, что в конце этого пути выполнения стоит no-return функция, то он не будет ругаться. Он не будет захламлять мне вывод своими ворнингами. Меньше фолс-позитивов в работе статического анализатора -- больше внимания уделяется тру-позитивам, и меньше соблазна просто выключить ворнинги к чертям. Но кроме того, no-return атрибут на функции добавляет новых срабатываний статическому анализатору: код расположенный после безусловного exit -- явно не нужный код, оставленный там по ошибке. И неплохо было бы, чтобы программист не забыл бы этот код удалить. Или может удалить вызов exit -- может это он был оставлен по ошибке?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #100

97. Сообщение от Аноним (97), 14-Июн-21, 14:54	+/–
Blazor (гы-гы-гы), а вообще Angular
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

98. Сообщение от Аноним (80), 14-Июн-21, 15:11	+/–
это для местных анонимных коментаторов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

99. Сообщение от Аноним (99), 14-Июн-21, 16:27	+4 +/–
Хорошая идея, одобряю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #134

100. Сообщение от Sw00p aka Jerom (?), 14-Июн-21, 17:13	–1 +/–
> Я даже не знаю что сказать на это. Что значит "язык является > обёрткой другого языка"? Язык C является обёрткой для асма? C++ является > обёрткой для C? Вот что значить вот это "Если ты вызываешь из кода php функцию на C"? пхепешный fopen вызывает lib сишный fopen который вызывает системный сишный сискол open. https://en.wikipedia.org/wiki/Wrapper_function > Давай мы лучше замнём тему, сделаем вид, что никаких обёрток и не было, и я просто расскажу тебе, зачем статическому анализатору нужно знать про no-return функции? Лучше сначала определимся и опишем, что требуется от анализатора, ибо будем говорить о разных вещах. > Всё очень просто: если статический анализатор знает, что функция не возвращает управления > и завершает программу, то он может сделать вывод, что "вечный" цикл > вовсе не вечный, а значит инкремент индекса не выползет за границы > буфера. Если нет возврата управления, то либо "вечный цикл", либо аварийный останов. > Или может статический анализатор увидит, что один из путей выполнения > функции, набитой ветвлениями, не возвращает значения -- он будет ругаться, но > если он увидит, что в конце этого пути выполнения стоит no-return > функция, то он не будет ругаться. Что он будет выдавать, когда столкнется с проблемой останова? Статический анализатор ведь должен простроить граф потока управления. > Или может удалить вызов exit -- может это он был оставлен по ошибке? А как анализатор это может разрешить, что удалить, ошибочно добавленный exit или анюзед код после него. Это решает программист. А анализатор должен сообщить лишь о том, что у тебе тут exit, а код ниже никогда не исполниьтся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #102

101. Сообщение от Аноним (101), 14-Июн-21, 17:51	–1 +/–
Вот только качество и количество это разные вещи xD
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #122

102. Сообщение от 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ообщить модератору
Родитель: #100 Ответы: #108

103. Сообщение от Аноним (103), 14-Июн-21, 21:04	+1 +/–
Помянем.
Ответить | Правка | Наверх | Cообщить модератору

104. Сообщение от Аноним (104), 14-Июн-21, 22:13	+/–
На нем пишется очень много промолчу что он 'простой' все ошибки умирают вместе с интерпретатором после выполнения запроса
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #110

106. Сообщение от Уася (?), 14-Июн-21, 23:16	+/–
Автор! Исправь листинги! Не нужны эти 4 пробела спереди строк. И также используй всегда два пробела в статьях, конвертни в prettier онлайн. А то с телефона это не читается, а хотя могло бы!
Ответить | Правка | Наверх | Cообщить модератору

107. Сообщение от mr.Clin (?), 15-Июн-21, 00:02	+/–
Ага, ровно до тех пор пока не всрёшься с такими приколами )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

108. Сообщение от Sw00p aka Jerom (?), 15-Июн-21, 01:32	–1 +/–
> Эмм... Любой язык, кроме ассемблера, становится обёрткой, если следовать такому определению. > Си ведь тоже не вызывает напрямую сисколлов, а дёргает обёртки из > 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ообщить модератору
Родитель: #102 Ответы: #112

109. Сообщение от Sw00p aka Jerom (?), 15-Июн-21, 01:42	+/–
> Статический анализатор в динамическом языке... > Печалька. Блин аааа, мою портянку выше можно было уместить в ваши две строчки :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

110. Сообщение от Sw00p aka Jerom (?), 15-Июн-21, 01:48	+/–
> На нем пишется очень много промолчу что он 'простой' все ошибки умирают > вместе с интерпретатором после выполнения запроса @ убей все ошибки :) только за этот символ я его (пых) "ненавижу".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #128, #129

111. Сообщение от Da (?), 15-Июн-21, 03:10	+/–
Деление на 0 не равно бесконечности. Деление на 0 просто не имеет смысла по определнию операции деления.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #124

112. Сообщение от 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ообщить модератору
Родитель: #108

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

114. Сообщение от Аноним (113), 15-Июн-21, 03:27	+1 +/–
Делали шаблонизатор для домашних страниц, а получился язык для говнокодинга.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #125

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

116. Сообщение от Здрасьте (?), 15-Июн-21, 07:57	+/–
Ты слабую с нестрогой не перепутал? Си++ — язык со слабой типизацией, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

117. Сообщение от Здрасьте (?), 15-Июн-21, 07:59	+/–
Можно так: 0_0 (подчерк — допустимый разделитель в числах).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #118

118. Сообщение от Онаним (?), 15-Июн-21, 08:19	+1 +/–
0_0 да, но оно не отражает всех моих эмоций, особенно при использовании восьмеричных чисел за пределами chmod().
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117

119. Сообщение от Аноним (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, #127

120. Сообщение от 1 (??), 15-Июн-21, 10:10	+/–
Так "Ноль" или "Нуль" ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

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

122. Сообщение от Lex (??), 15-Июн-21, 11:28	+/–
> Вот только качество и количество это разные вещи xD Применительно к ЯП - нет. Даже наоборот - фактически, бОльшее количество говорит о лучшем общем качестве экосистемы. Чем более ЯП и его инфраструктура применимы к конкретной задаче - тем больше делается проектов его базе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

123. Сообщение от Аноним (123), 15-Июн-21, 11:38	+1 +/–
Его заменило "a" => 1.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119

124. Сообщение от ыы (?), 15-Июн-21, 11:41	+/–
Просто мы еще чегото не знаем о окружающем нас мире...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

125. Сообщение от onanim (?), 15-Июн-21, 11:51	+/–
> Делали шаблонизатор для домашних страниц, а получился язык для говнокодинга. начиная с 7ой версии пых стал довольно неплох.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #132

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

127. Сообщение от Онаним (?), 15-Июн-21, 13:29	+/–
Не, всё ок. Одинаковый ключ, значение заменяется на последнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119

128. Сообщение от Онаним (?), 15-Июн-21, 13:33	+/–
Просто не надо сверх меры применять, где не надо. Оно не зря существует: в C вы вообще ничего не получите на выход, кроме кода ошибки, а здесь можете получить сверху дебажный вывод, который и подавляется @ там, где он ожидаем, но не нужен. Допустим надо почитать сокет, и наплевать на то, что сие чтение может выстрелить дебагом ошибки - в данный конкретный момент. Все ошибки я обработаю оптом позже, или просто сокеты закрою, вне зависимости от состояния.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #145

129. Сообщение от Онаним (?), 15-Июн-21, 13:36	+/–
Впрочем, в восьмёрке некоторые файловые операции теперь стреляют эксепшнами, @#$%, и это @ не подавляется. И если я раньше мог @unlink написать для удаления файла/симлинка, которого может не быть - то теперь мне надо лепить бойлерплейт из @is_file или try { } catch { } вокруг. Напрягает, пришлось для себя обернуть в unlinkSilently() :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #136, #146

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

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

132. Сообщение от Aukamo (ok), 15-Июн-21, 17:25	+/–
> начиная с 7ой версии пых стал довольно неплох. У меня на 5-6 версиях сформировался такой рвотный рефлекс, что до сих пор рефлексивно ищу близжайший пакет при упоминании PHP. Не смотря на моё к нему отношение, PHP занял свою нишу. Для непонятливых: синтаксис тут вообще ни при чём. Си подобный синтаксис был выбран только ради повышения узнаваемости и читаемости (можете вспомнить когда впервые увидили тот-же python или rust, не зная ничего о нём), но сам язык создавался для "домохозяек" и, полагаю, таким и остался. Здесь очень хотелось бы встретить уважаемого Symfony-ста, который разложит в 2х словах как там обстоят дела. Как, уже писал выше, не слежу за языком и всё что с ним происходит уже больше десятка лет. Может он, вдруг, стал строго академическим, но сильно сомневаюсь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #135

133. Сообщение от Aukamo (ok), 15-Июн-21, 17:39	+/–
И это всё что не нравится в TS? Просто отсутсвие какого-то более менее долгоживущего решения (фреймворка)?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

134. Сообщение от InuYasha (??), 16-Июн-21, 10:16	+/–
Так давно уже https://cppcms.com
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99

135. Сообщение от Онаним (?), 16-Июн-21, 10:16	+/–
"Шашечки или ехать". Язык как был, так и остался строго прикладным. Его пытаются слегка обрастить некоторыми "академичными" конструкциями для неосиляторов, но к счастью core team  более-менее адекватна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132

136. Сообщение от Онаним (?), 16-Июн-21, 10:19	+/–
@is_file() кстати плохой бойлерплейт. Надо "почему" в список вопросов новичкам включить :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

137. Сообщение от InuYasha (??), 16-Июн-21, 22:44	–1 +/–
По жизни с пятисотками? ) Я сомтрю, доброта через забор переливается, если ты желаешь кому-то жить с: 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ообщить модератору
Родитель: #63 Ответы: #139

138. Сообщение от АнонимнаяЗалупа (?), 17-Июн-21, 04:21	+1 +/–
PHP для богов
Ответить | Правка | Наверх | Cообщить модератору

139. Сообщение от Онаним (?), 17-Июн-21, 09:16	–1 +/–
Ну я ж говорю, для привыкших к тому, что их компилятор за ручку водит - не годится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #140

140. Сообщение от InuYasha (??), 17-Июн-21, 10:11	–1 +/–
У вас, пыхарей, наверное, две жизни. И одну из них вы тратите на санацию аргументов. )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #144

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

142. Сообщение от Аноним (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ообщить модератору
Родитель: #141 Ответы: #143

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

144. Сообщение от Онаним (?), 17-Июн-21, 13:32	+/–
Санацию пользовательского ввода, если точнее. И привычка очень хорошая. Можете на неё время не тратить, но когда вылезет очередная дырка - не жалуйтесь. А с аргументами в целом всё как раз гораздо проще, ряд конверсий типов имплицитен, и это очень удобно, меньше обёрток вокруг реального алгоритма там, где они предполагаются в любом случае.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

145. Сообщение от Sw00p aka Jerom (?), 17-Июн-21, 22:12	+/–
> а здесь можете получить сверху дебажный вывод, который и подавляется @ там, где он ожидаем, но не нужен. отлично, одно реальное применение, во время отладки, согласен помогает, временно замьютить лишнюю инфу об ошибках, но когда такое видишь в продакшене, сами знаете что.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128

146. Сообщение от Sw00p aka Jerom (?), 17-Июн-21, 22:18	+/–
> Напрягает, пришлось для себя обернуть в unlinkSilently() :D через error_handler можно как игнорировать, так и выбрасывать исключения если функция их не поддерживает, но при этом нужно все оборачивать в try/catch
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

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

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