forum.opennet.ru - "Анализ зависимости безопасности кода от используемого языка программирования" (161)

"Анализ зависимости безопасности кода от используемого языка программирования"

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

"Анализ зависимости безопасности кода от используемого языка программирования"	+/–
Сообщение от opennews (??), 20-Дек-20, 18:53
Компания Veracode, специализирующаяся на разработке средств для проведения аудита безопасности, опубликовала результаты сравнения языков программирования в контексте безопасности написанного на них кода. Отчёт подготовлен на основе результатов статического анализа более 130 тысяч приложений... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54289
Ответить \| Правка \| Cообщить модератору

Оглавление

Какие-то языки ни о чём выбраны Где хайповые языки Где Rust, Go, Haskell, Ada , Аноним (1), 18:53 , 20-Дек-20, (1) +17

На этих языках еще нечего анализировать, кроме хайпа, Анонимно (ok), 18:58 , 20-Дек-20, (3) +47

is it safe , mos87 (ok), 19:02 , 20-Дек-20, (6) +1
Хайп Ada был году в 1980 наверное И хаскеля тогда же Так что еще тут слабо п, Аноним (10), 19:05 , 20-Дек-20, (10) +11

Разве haskell не в начале 90-х появился , Ordu (ok), 23:47 , 20-Дек-20, (48) +1

Это побочный эффект от ленивых вычислений , n00by (ok), 10:45 , 21-Дек-20, (97) +6

Но ведь основная фишка функционального программирования -- отсутствие побочных э, Ordu (ok), 12:34 , 21-Дек-20, (106) +1

В том что и дело Наблюдаемый результат работы алгоритма суть побочный эффект , n00by (ok), 14:10 , 21-Дек-20, (115) –1

Не спорьте вот ниже вся история и наглядноhttps www youtube com watch v Og8, OpenEcho (?), 02:30 , 21-Дек-20, (72) –1

Дед, ты опять забыл принять свои таблетки , Аноним (-), 19:04 , 20-Дек-20, (7) +21

Ещё хуже Мне прописали вводить смузи Запамятовал вот, пропустил процедуру Пой, Аноним (1), 19:36 , 20-Дек-20, (19) +5

Попробуй lean, lockywolf (ok), 19:51 , 20-Дек-20, (21) –2

Cobol и basic , lockywolf (ok), 19:09 , 20-Дек-20, (11) –1
Ada - хайповый , Аноним (93), 10:15 , 21-Дек-20, (93)

Он не только хайповый, но и самый опасный два 737х уконтропупили на нем , Соня Мармеладова (?), 12:40 , 21-Дек-20, (107)

Скрыто модератором, iPony129412 (?), 18:55 , 20-Дек-20, (2) –7

Скрыто модератором, mos87 (ok), 19:04 , 20-Дек-20, (8) +6

а swift , Аноним (-), 18:58 , 20-Дек-20, (4) –1
сферические анализы кала в вакууме, mos87 (ok), 19:01 , 20-Дек-20, (5) +11

На яве и нете, если плохое качество кода впереди, значит уровень разработчика не, Секрет (?), 01:07 , 22-Дек-20, (135)

Как я и говорил, безопасность -- это не про похапешников Самый позорный показат, Аноним (9), 19:05 , 20-Дек-20, (9) +3

Ну да, бест практис не сильно распространены и язык более популярный чем остальн, Бел аноним (?), 19:12 , 20-Дек-20, (12)

Заказчику работ не нужны practices, Аноним (14), 19:16 , 20-Дек-20, (14) +3
Откуда дровишки Есть хотя бы один рейтинг популярности ЯП, где бы пыха обгоняла, Аноним (9), 19:28 , 20-Дек-20, (17)

денис_борисов jpg, Нитрофос (?), 20:23 , 20-Дек-20, (29) –1
Ставить жабу по популярности в один ряд с питоном и жс Даже интересно, если не, Lex (??), 20:47 , 20-Дек-20, (30) –1

Какая, какая - очень большая Начиная с корпоративного сектора, которым пользуют, Урри (ok), 00:40 , 21-Дек-20, (58) +2

Т е в этом рейтинге в популярность джава не зачсчитывается разработка приложен, Lex (??), 22:39 , 21-Дек-20, (127)

Ты тут для самоуспокоения пишешь Как видишь, желающих нет обсуждать подростковые, Тариф Анонимище (?), 23:41 , 21-Дек-20, (133) –1

Нет, просто забавляют тормозА, до сих пор всерьез считающие жабу сурьезным ынтеп, Lex (??), 13:24 , 22-Дек-20, (149)

Автомобилями думаешь тоже никто не пользуется, потому что у тебя его нет , max (??), 00:09 , 24-Дек-20, (154)

Умозаключение из области - Я в тот лес не ходил, но там точно деревьев нет Реа, вынь всего и вся (?), 02:05 , 21-Дек-20, (71) –1
Сразу видно иксперда опеннетовского, msgod (?), 09:47 , 21-Дек-20, (87) –1

Откуда дровишки С Это утверждение примерно десятилетней давности, сейчас мно, Аноним (160), 14:41 , 27-Дек-20, (160)

Просто доля пхп большая, а у остальных значительно меньше И при чем тут безопас, Аноним (33), 21:07 , 20-Дек-20, (33)

Доля пхп значительно меньше жабы Правильно было бы спросить - что в списке язык, PHPexpert (?), 21:44 , 20-Дек-20, (37) –3

Причем здесь языки и техника програмирования XSS , можно что С , что пыхтоне, , Аноним (77), 03:34 , 21-Дек-20, (77) +1

Apples vs Seeds, Аноним (85), 09:40 , 21-Дек-20, (85)

ха-ха походу исследование отражает умственные способности их использующих, анонимит (?), 19:16 , 20-Дек-20, (13) +2

C Слабые умственные способности Что-то путаешь , nonon (?), 22:07 , 20-Дек-20, (42) –1

Это, конечно, такая средняя температура по больнице Качество программ сильно за, Vkni (ok), 19:18 , 20-Дек-20, (15) –3

Это просто статистика, никто не делает прямых выводов Но как правило, такая ста, ЧеловекКамелКейс (?), 21:12 , 20-Дек-20, (34) +1

Роспотребпозор делает https pashev me posts rospotrebnadzor, Ковид2024 (?), 21:59 , 20-Дек-20, (41)
Статистика-то может и показывает, но есть некоторые сомнения в абсолютно одинако, Аноним84701 (ok), 23:12 , 20-Дек-20, (47) +1
Тогда на кой чёрт статистика нужна - Переполнение буфера ловится Valgrin, разн, Vkni (ok), 01:23 , 21-Дек-20, (65)

все что тут описано в принципе не проблемы языков Тут проблемы писателей И как, анонимуслинус (?), 19:24 , 20-Дек-20, (16) –2

Проблемы C от того, что его упорно смешивают с Си Как правило указатели испол, Аноним (24), 20:05 , 20-Дек-20, (24) +1

он тем и хорош , что все под контроль программисту Проблемы с программистами, н, анонимуслинус (?), 20:20 , 20-Дек-20, (27) –1

В C отнюдь не всё на деле под контроль программисту Это всего лишь довольно л, АЛМНКАГОГ (?), 01:15 , 21-Дек-20, (64) –1

Ну так далеко не в каждой архитектуре есть способ обнаружить такое переполнение , Аноним (24), 03:39 , 21-Дек-20, (78)

С каждой строкойнагнетается сайенсхоть и не хокку , АЛМНКАГОГ (?), 12:11 , 22-Дек-20, (148) +1

Есть чудесная статья What every compiler writer should know about programmers , Vkni (ok), 01:33 , 21-Дек-20, (67)

А при чём здесь железо Потеря контроля она и есть потеря контроля Железо не п, АЛМНКАГОГ (?), 01:44 , 21-Дек-20, (70)

Почитайте статью Для примера - под AIX POWER вы можете разыменовывать NULL - он, Vkni (ok), 01:46 , 22-Дек-20, (137) +1

NULL не указывает на нулевую страницу Вы не поняли - железо ни при чём Если , АЛМНКАГОГ (?), 02:13 , 22-Дек-20, (139)
- Смешное заявление программа работает, но не работает При чём заметьте , АЛМНКАГОГ (?), 02:43 , 22-Дек-20, (142)

Да Если взять компилятор из 80-х, будет работать Если отключить оптимизации в , Ordu (ok), 03:36 , 23-Дек-20, (150)

О, адвокат Файрфокса подтянулся, тоже то ещё вредоносное поделие Что-то мне каже, АЛМНКАГОГ (?), 12:25 , 23-Дек-20, (151)

Я что-то сказал в защиту фф Где Когда Слабо найти хотя бы одну ссылку на мою , Ordu (ok), 14:05 , 23-Дек-20, (152)

Вы читали вышенаписанное Там про NULL И он не нулевой физический адрес, как мн, АЛМНКАГОГ (?), 03:25 , 26-Дек-20, (155)

Вот кстати обоснование выше приведённого примера с нулями из тех, с которыми , АЛМНКАГОГ (?), 03:47 , 26-Дек-20, (156)
На современном железе программы работают с виртуальными адресами И дело не в яз, n00by (ok), 09:17 , 26-Дек-20, (157)
Есть один широко известный Адрес, который надо было бояться придётся следовать , АЛМНКАГОГ (?), 02:20 , 28-Дек-20, (162)
Абырвалг , n00by (ok), 09:20 , 28-Дек-20, (163)
Вообще-то, там обсуждается под контроль программиста NULL взят в качестве при, Ordu (ok), 11:54 , 26-Дек-20, (158)
Во-первых вам к Нам следует обращаться отнюдь не ты Никакого примера с перепол, АЛМНКАГОГ (?), 02:12 , 28-Дек-20, (161)
Ох блин, спасибо, вот уважил старика Как я надеялся, что ты прочитаешь, и ты пр, Ordu (ok), 12:41 , 28-Дек-20, (164)

Проблемы у C и C в том, что даже вроде бы успешно работающая в тестах программ, АЛМНКАГОГ (?), 01:33 , 21-Дек-20, (68)

По моему опыту всё, на чём я и не только писал могло оказаться неправильным И, PnD (??), 15:18 , 21-Дек-20, (117)

ну так гёдель же еще 100 лет тому назад так шо не парься все ошибаются и я т, Myyx (?), 22:58 , 21-Дек-20, (132)
Могло, может быть Но только годное и работоспособное не могло То, на чём вы пи, АЛМНКАГОГ (?), 03:19 , 22-Дек-20, (143)

а также, извините, Питона, Явы, Perl, Go - тот ещё набор , АЛМНКАГОГ (?), 03:22 , 22-Дек-20, (144)

Не совсем У всех языков есть проблемы У похапе проблемы 8212 это фича Фича пи, GG (ok), 00:01 , 21-Дек-20, (50)

питон вообще довольно приятный язык, особенно в малых дозах Не так как на нем п, анонимуслинус (?), 00:14 , 21-Дек-20, (54) –2
В который - второй или третий , Урри (ok), 00:42 , 21-Дек-20, (59)

проверяется при помощи функции file_exists , которая автоматически выполняет де, Аноним (89), 09:55 , 21-Дек-20, (89) +1

таблица - теплое с мягким, все как мы любим, имя_ (?), 19:31 , 20-Дек-20, (18) +4
Чота Лиспа не увидел , Аноним (20), 19:45 , 20-Дек-20, (20)
Фрактааааал Твой выход , Аноним (22), 19:55 , 20-Дек-20, (22) +5
Поржал, особенно с JS 7 code quality А почему так Потому что любая дичь в ко, n242name (?), 19:57 , 20-Дек-20, (23) +6

Да, очень странно, что JS весь в белом и на коне Хотя в реальной жизни проблем , Аноним (25), 20:07 , 20-Дек-20, (25) +1

Так на жсе, в среднем по больнице, не пишут то, что пишут на сях , Аноним (28), 20:21 , 20-Дек-20, (28) –2

Справедливости ради JavaScript давно уже стал достаточно универсальным языком, н, Дима (??), 20:50 , 20-Дек-20, (31) –6

Мне кажется что JS лет столько же, сколько PHP, а толку в плане становления уни, Аноним (35), 21:18 , 20-Дек-20, (35) –2

Спроектировано вменяемо Если не согласен -- приводи конкретные примеры Производ, Аноним (9), 21:54 , 20-Дек-20, (39) +1

https github com denysdovhan wtfjs, Урри (ok), 00:47 , 21-Дек-20, (60) –4

Что это Список 171 прикольных 187 вопросов для собеседования В реальном, Аноним (9), 01:02 , 21-Дек-20, (63)

Вот именно, оно - натуральное ковно, в реальном коде этого ковна никогда не буде, n242name (?), 02:35 , 21-Дек-20, (73) –2

Берешь гитхаб и ищешь реальные примеры по реальному коду, где бы кому-либо пункт, Аноним (9), 03:20 , 21-Дек-20, (75)

И чем оно отличается от какого-нибудь Undefined behaviour с c , Аноним (81), 08:40 , 21-Дек-20, (81) –1

Отличается тем что в ecmascript это определенное и стандартизованное поведение, Аноним (92), 10:07 , 21-Дек-20, (92)

И ведь это лучше, чем рулетка UB в плюсах , Аноним (81), 21:34 , 21-Дек-20, (124) –1

Используйте typescript , Аноним (89), 10:01 , 21-Дек-20, (90)
там большинство вопросов уровня 0 3 0 2 и 2 2 , Аноним (92), 10:46 , 22-Дек-20, (145)

Подскажите, каким языком вы обычно заменяете JavaScript в случаях и местах, когд, нитрол (ok), 22:12 , 21-Дек-20, (126) –1

Нужно стремится к JavaScript Суровая правда жизни в том, что в веб-разработке н, Дима (??), 01:08 , 22-Дек-20, (136)

Уже года три как потеснил, с разморозкой И вместе с теснением притащил в свои ря, GG (ok), 00:05 , 21-Дек-20, (51) –3

влажные мечты ньюфага , Gemorroj (ok), 00:37 , 21-Дек-20, (56) –5

не надо писать на js большие программы, используйти строго статически типизирова, Аноним (92), 10:53 , 22-Дек-20, (146)

Тут смотря что с чем сравнивать Похоже для php анализатор гоняли на WordPress с , Аноним (69), 01:34 , 21-Дек-20, (69) +1

Да уж, какой-то малосвязанный и сложно восрпинимаемый список Однако, многие мом, InuYasha (??), 20:17 , 20-Дек-20, (26)
А раста нет, потому что на нём студенты пишут хеллоуворлды , Аноним (32), 21:01 , 20-Дек-20, (32) +1

Нет, потому что он является безопасным языком , Аноним (43), 22:17 , 20-Дек-20, (43) –2

Не является , Аноним (44), 22:26 , 20-Дек-20, (44) +1

Зашел почитать комментарии про Rust , Kuromi (ok), 21:36 , 20-Дек-20, (36) +5

А чего читать - нет проблем Почитай лучше про остальные языки как там все плохо, Аноним (128), 22:40 , 21-Дек-20, (128)

Ну что phpшники Стало лучше ваше поделие В каждой версии говорите что вот тепе, Анон666 (?), 21:50 , 20-Дек-20, (38) +31

И на что смотреть Какой язык может заменить пхп Была куча взрослых закапывател, Аноним (46), 23:10 , 20-Дек-20, (46) –17

Если небольшой проект - нода и реакт, javascript же все равно учить надо Если к, anon22 (?), 00:07 , 21-Дек-20, (52) +13

какая каша в голове у этих смузихлебных манагеров, которые нихера не знают про п, Gemorroj (ok), 00:39 , 21-Дек-20, (57) –11

Да ладно тебе - тут все гораздо хуже Он же предлагает ноту и жабоскрипт на бекэ, Урри (ok), 00:55 , 21-Дек-20, (61) –4

Как эксперт по пхп подтверждаю - альтернатив просто нет Есть решения в чем-то л, PHPexpert (?), 10:02 , 21-Дек-20, (91) +3

Ниче что шаблонизатор это всего лишь либа Я могу любой из них заюзать что в спри, msgod (?), 10:33 , 21-Дек-20, (95) –1

Шаблонизатор это не просто либа Это целый язык программирования Откройте hh, в, PHPexpert (?), 10:51 , 21-Дек-20, (98) +1

Зачем шаблонизатору выполнять что то кроме рендера страницы перед тем как ее отд, msgod (ok), 11:29 , 21-Дек-20, (99) –1

Данные шаблонизатору отдает низлежащий стек В случае jvm там множество варианто, PHPexpert (?), 11:36 , 21-Дек-20, (101) +1

Ну что тут сказать Jsp jsf в ЕЕ лет 20, SpringMVC в спринге не меньше Они вход, msgod (ok), 11:35 , 21-Дек-20, (100) –1

Это фреймворки java, а не freemarker Всё равно что сравнивать фреймворки на C н, PHPexpert (?), 11:51 , 21-Дек-20, (102) +1

Ну тебе же нужен был аналог ларавеля Чтопизкаропки Они и есть аналог При этом л, msgod (ok), 12:09 , 21-Дек-20, (104) –1

Мне точно не нужен И это не аналог, я уже объяснил Если надо использовать асинх, PHPexpert (?), 12:15 , 21-Дек-20, (105) +1

Javascript учить НЕ НАДО, но к сожалению придется, пока не переедем на WebAssemb, n242name (?), 02:52 , 21-Дек-20, (74) –3

Мусье не в курсе, что WebAssembly не создавался, как замена яваскрипту , Аноним (9), 03:25 , 21-Дек-20, (76) +1

зато будет использоваться как замена - 100 доступ к DOM у него уже естьTelerik и, n242name (?), 13:28 , 21-Дек-20, (109) –2

У WebAssembly нет доступа к дому, мань Он лишь в состоянии вызывать функции, ко, Аноним (9), 14:29 , 21-Дек-20, (116)

gt оверквотинг удален Байндинги в самих фреймворках не проблема Да сделаны чер, n242name (?), 15:22 , 21-Дек-20, (118) –1

Вот и протестируй, а затем уже предлагай Чем больше WebAssembly зависит от брау, Аноним (9), 15:41 , 21-Дек-20, (119)

1 не для скорости, а для платформы2 не будет он на порядки быстрее, тупит DOM,, n242name (?), 00:05 , 22-Дек-20, (134)

Правильно И это -- один из редчайших случаев, когда wasm реально применяется та, Аноним (9), 01:49 , 22-Дек-20, (138)

тем, что TypeScript это все еще JSесли надо объяснять чем JS плох, то дафай досф, n242name (?), 02:13 , 22-Дек-20, (140)
Да не, слиться любой может А ты вот попробуй не сливаться и реально попытайся о, Аноним (9), 02:24 , 22-Дек-20, (141)

Хочу спросить, для повышения образованности А почему бы не закинуть в wasm стро, Ordu (ok), 21:37 , 21-Дек-20, (125)

Ts, dart Ангуляр и вполне умеет, msgod (ok), 10:40 , 21-Дек-20, (96) –1

TS - кастрат, потому что под капотом это тот же JS, там из нормального только ти, n242name (?), 13:32 , 21-Дек-20, (110)

Заменить в чём Если в роли инструмента для клепания сайтов, то любой скриптовый , GG (ok), 00:08 , 21-Дек-20, (53)

А можно примеры нормальных фреймворков Таких, что бы были не хуже и не медленне, Урри (ok), 00:57 , 21-Дек-20, (62) –1

Тебе фляжки с джангой для чего-то не хватает Медленность упирается в говнокод, с, GG (ok), 01:26 , 21-Дек-20, (66) +1

самый медленный язык в мире php в последней версии ускорили на 10 , теперь php , son (?), 09:18 , 21-Дек-20, (84) +4

Любой асинхронный фреймворк на питоне, го или яве работает в десятки или сотни р, msgod (ok), 12:57 , 21-Дек-20, (108) –1

Вот ты утёнок У нас что, ASP NET отменили Причём ламерам можно начать с BASIC, Gogi (??), 14:02 , 21-Дек-20, (114) –1

ASP NET это винда и проприетарщина Не забываем на каком мы ресурсе, а вот про A, hex (??), 11:43 , 22-Дек-20, (147) +1

На одной работе вот была необходимость запилить костыль на PHP, кодеры, которые , Аноним (85), 09:45 , 21-Дек-20, (86) –1

Дырявые плюсовики в принципе не умеют работать с буферами, потому что дырявые, Fracta1L (ok), 21:55 , 20-Дек-20, (40) –10

пишу на плюсах, ни про какие буфера ни разу не слышал массивы знаю, память знаю, Аноним (103), 12:03 , 21-Дек-20, (103) +3

Потому что дырявый , Косплеер Фрактала (?), 16:08 , 26-Дек-20, (159)

Как на JS написать уязвимость вида Directory traversal Какие директории у кли, Аноним (45), 22:57 , 20-Дек-20, (45)

Твои представления о том, что JS может выполняться исключительно в браузере, уст, Аноним (9), 00:31 , 21-Дек-20, (55) –1

Видимо опять сравнили количество ошибок в helloword ах в песочнице с операционны, Аноним (49), 23:51 , 20-Дек-20, (49)
А кто-нибудь понял от чего эти проценты взяты Что символизируют эти циферки и с, Аноним (79), 06:51 , 21-Дек-20, (79)
Кто хотя бы раз видел код на PHP, поймёт там люди тупо выживают - не до безопас, Аноним (80), 08:21 , 21-Дек-20, (80) +2

Какие заказчики, такие и исполнители, такой и код Поспешишь - людей насмешишь, , Аноним (85), 09:48 , 21-Дек-20, (88) –2

У семи нянек дитя без глаза Кто рано встаёт, тобу бог подаёт Итак, симпозиум на, Gogi (??), 13:58 , 21-Дек-20, (113)

Кто хочет соскакивает , Аноним (128), 22:43 , 21-Дек-20, (129)

Это и так все давно знали , th3m3 (ok), 09:02 , 21-Дек-20, (82)

Лучшие сишные дырени в PHP , Аноним (93), 10:19 , 21-Дек-20, (94)

Какая-то реклама притона для взрослых , Аноним (128), 22:44 , 21-Дек-20, (130)

Эта rовностатистика трещит по всем швам 1 НЕ ТОЛЬКО язык влияет на секурность, , Gogi (??), 13:57 , 21-Дек-20, (112) –1

Ты на себя-то глянь, да Откуда ты взял корреляцию в 30 Из головы выдумал Пока, Ordu (ok), 17:24 , 21-Дек-20, (121)

Правильный заголовок PHP признан самым небезопасным языком , Аноним (120), 17:19 , 21-Дек-20, (120)
Ниочем Анализ на уровне отписки студента первого курса по предмету мат статист, Аноним (122), 19:57 , 21-Дек-20, (122) –1
Раст самый безопастный Нет кода - нет ошибок , Аноним (122), 19:58 , 21-Дек-20, (123) –1

Code less error too , Аноним (128), 22:46 , 21-Дек-20, (131) –1

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

1. "Анализ зависимости безопасности кода от используемого языка ..." +17 +/–

Сообщение от Аноним (1), 20-Дек-20, 18:53

Какие-то языки ни о чём выбраны. Где хайповые языки? Где Rust, Go, Haskell, Ada?

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

3. "Анализ зависимости безопасности кода от используемого языка ..." +47 +/–

Сообщение от Анонимно (ok), 20-Дек-20, 18:58

На этих языках еще нечего анализировать, кроме хайпа

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

6. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от mos87 (ok), 20-Дек-20, 19:02

is it safe?

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

10. "Анализ зависимости безопасности кода от используемого языка ..." +11 +/–

Сообщение от Аноним (10), 20-Дек-20, 19:05

Хайп Ada был году в 1980 наверное. И хаскеля тогда же. Так что "еще" тут слабо применимо.

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

48. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от Ordu (ok), 20-Дек-20, 23:47

Разве haskell не в начале 90-х появился?

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

97. "Анализ зависимости безопасности кода от используемого языка ..." +6 +/–

Сообщение от n00by (ok), 21-Дек-20, 10:45

Это побочный эффект от ленивых вычислений.

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

106. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от Ordu (ok), 21-Дек-20, 12:34

> Это побочный эффект от ленивых вычислений.
Но ведь основная фишка функционального программирования -- отсутствие побочных эффектов.

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

115. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от n00by (ok), 21-Дек-20, 14:10

В том что и дело. Наблюдаемый результат работы алгоритма суть побочный эффект.

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

72. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от OpenEcho (?), 21-Дек-20, 02:30

Не спорьте... вот ниже вся история и наглядно
https://www.youtube.com/watch?v=Og847HVwRSI

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

7. "Анализ зависимости безопасности кода от используемого языка ..." +21 +/–

Сообщение от Аноним (-), 20-Дек-20, 19:04

> Haskell, Ada
> хайповые
Дед, ты опять забыл принять свои таблетки?

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

19. "Анализ зависимости безопасности кода от используемого языка ..." +5 +/–

Сообщение от Аноним (1), 20-Дек-20, 19:36

Ещё хуже. Мне прописали вводить смузи. Запамятовал вот, пропустил процедуру. Пойду на Nim водить.

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

21. "Анализ зависимости безопасности кода от используемого языка ..." –2 +/–

Сообщение от lockywolf (ok), 20-Дек-20, 19:51

Попробуй lean

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

11. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от lockywolf (ok), 20-Дек-20, 19:09

Cobol и basic.

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

93. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (93), 21-Дек-20, 10:15

Ada - хайповый?

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

107. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Соня Мармеладова (?), 21-Дек-20, 12:40

Он не только хайповый, но и самый опасный: два 737х уконтропупили на нем.

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

2. Скрыто модератором –7 +/–

Сообщение от iPony129412 (?), 20-Дек-20, 18:55

👉👌 🤨
С➕➕

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

8. Скрыто модератором +6 +/–

Сообщение от mos87 (ok), 20-Дек-20, 19:04

>👉👌
дзюбишь?

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

4. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от Аноним (-), 20-Дек-20, 18:58

а swift ?

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

5. "Анализ зависимости безопасности кода от используемого языка ..." +11 +/–

Сообщение от mos87 (ok), 20-Дек-20, 19:01

сферические анализы кала в вакууме

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

135. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Секрет (?), 22-Дек-20, 01:07

На яве и нете, если плохое качество кода впереди, значит уровень разработчика не очень, значит и в принципе все дубовые ошибки в комплекте :)

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

9. "Анализ зависимости безопасности кода от используемого языка ..." +3 +/–

Сообщение от Аноним (9), 20-Дек-20, 19:05

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

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

12. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Бел аноним (?), 20-Дек-20, 19:12

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

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

14. "Анализ зависимости безопасности кода от используемого языка ..." +3 +/–

Сообщение от Аноним (14), 20-Дек-20, 19:16

Заказчику работ не нужны practices

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

17. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (9), 20-Дек-20, 19:28

> язык более популярный чем остальные в списке
Откуда дровишки? Есть хотя бы один рейтинг популярности ЯП, где бы пыха обгоняла яву, пихон или жс?
Проблема пыха в том, что он одним своим неконсистентным дизайном не располагает к написанию качественного кода. Адская мешанина высокоуровневой Java и низкоуровневого Си. Ну и будем честны, в индустрии "создания сайтов быстро под ключ" работают преимущественно студенты [юрфака].
Борьбу с SQL-инъекциями пыхеры освоили позже всех, помню году в 2007 я заходил на любой сайт на пыхе, подставлял апостроф к айдишнику чего-либо (index.php?id=123') и получал sql syntax error для каждого второго пыхо-сайта, без преувеличений.

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

29. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от Нитрофос (?), 20-Дек-20, 20:23

денис_борисов.jpg

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

30. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от Lex (??), 20-Дек-20, 20:47

Ставить жабу по популярности в один ряд с питоном и жс :)
Даже интересно, если не считать разработку под андройд( в которой даба стремительно летит на свалку ), то какова будет реальная «популярность» джавы.

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

58. "Анализ зависимости безопасности кода от используемого языка ..." +2 +/–

Сообщение от Урри (ok), 21-Дек-20, 00:40

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

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

127. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Lex (??), 21-Дек-20, 22:39

> Какая, какая - очень большая. Начиная с корпоративного сектора, которым пользуются миллиарды
> и десятки тысяч это кодят.
Т.е в этом рейтинге в "популярность" джава не зачсчитывается разработка приложений и проч под огромное множество мобильных устройств( и даже не потому, что жаба "нереально крутая", а потому, что это просто один из ключевых применяемых ЯП в разработке приложений для той ОСи ), не так ли ?)
Начиная со сказок про интыпрайз.. ими, впрочем, и заканчивая.. но потом правда окажется, что на джаве говнокодить ощутимо проще, а сам тот говнокод - ощутимо забристей в сравнении со многими другими ЯП а саму жабу усиленно теснят все кому ни лень, в т.ч питон да го.. да даже главконтора потихоньку сваливает в разработке с джавы на Котлин а то и вовсе, на дарт.. но, разумеется, это не потому, что жаба - громоздкий и невыразительный мусор, а потом что она слишком хорошо для них :)

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

133. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от Тариф Анонимище (?), 21-Дек-20, 23:41

Ты тут для самоуспокоения пишешь?
Как видишь, желающих нет обсуждать подростковые эмоциональные тексты.
Сходи погугли, наберись немного знаний о предмете, о котором тут пытаешься вещать.

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

149. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Lex (??), 22-Дек-20, 13:24

> Ты тут для самоуспокоения пишешь?
Нет, просто забавляют тормозА, до сих пор всерьез считающие жабу сурьезным ынтепрайзом "и вообще, за ней будущее"(ц)

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

154. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от max (??), 24-Дек-20, 00:09

Автомобилями думаешь тоже никто не пользуется, потому что у тебя его нет?

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

71. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от вынь всего и вся (?), 21-Дек-20, 02:05

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

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

87. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от msgod (?), 21-Дек-20, 09:47

Сразу видно иксперда опеннетовского

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

160. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (160), 27-Дек-20, 14:41

> Проблема пыха в том, что он одним своим неконсистентным дизайном не располагает к написанию качественного кода.
"Откуда дровишки?" (С)
Это утверждение примерно десятилетней давности, сейчас многое изменилось, и Вы, видимо, просто не в курсе. Я говнокодер на PHP с более чем 10-ти летним стажем и могу с уверенностью сказать, что у PHP довольно много инструментов, которые не то что бы просто "способствуют", но и "заставляют" и "помогают" писать качественный код. На PHP, представьте себе!
Во первых, можно использовать (а можно и нет) строгую статическую типизацию. Включаем strict_types, используем typed properties, return type. Второе - используем инструменты для проверки качества кода: рекомендуемый код стайл (всякие там `code sniffer` + `PSR-12`), обнаружение "говна" - `phpmd`, статический анализатор кода с 8-ью уровнями проверки `phpstan`. Разные фреймворки для написания тестов: `phpunit`, `codeception`, `behat`, etc. Мутационное тестирование (изменение кода в рантайме теста с помощью мутаций AST) `infection`, который может засечь ошибки даже в 100% покрытом тестами коде (если таковые имеются, а они имеются в 99% случаев).
Так же смотрим анализ и сравнение производительности для версий 7.4 и 8.0, а не 5.2, например.
Это не проблема языка, что предоставляемые им инструменты зачастую просто не используются.
Ну и по поводу инъекций. Тут тоже камень в огород не к PHP. И сейчас можно найти множество разнообразных брешей безопасностей в любом другом языке. Микроскоп не виноват, когда ним забивают гвозди.

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

33. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (33), 20-Дек-20, 21:07

Просто доля пхп большая, а у остальных значительно меньше. И при чем тут безопасность

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

37. "Анализ зависимости безопасности кода от используемого языка ..." –3 +/–

Сообщение от PHPexpert (?), 20-Дек-20, 21:44

Доля пхп значительно меньше жабы. Правильно было бы спросить - что в списке языков программирования делает PHP?

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

77. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от Аноним (77), 21-Дек-20, 03:34

Причем здесь языки и техника програмирования (XSS), можно что С++, что пыхтоне, что на жаве слабать XSS ...
Ну "да" на С++ сплошь и рядом веб приложения бацают :)
Сравнивать ПЫХ и С++ это Apples vs Oranges

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

85. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (85), 21-Дек-20, 09:40

> Apples vs Oranges
Apples vs Seeds

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

13. "Анализ зависимости безопасности кода от используемого языка ..." +2 +/–

Сообщение от анонимит (?), 20-Дек-20, 19:16

ха-ха. походу исследование отражает умственные способности их использующих

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

42. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от nonon (?), 20-Дек-20, 22:07

C++? Слабые умственные способности?
Что-то путаешь

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

15. "Анализ зависимости безопасности кода от используемого языка ..." –3 +/–

Сообщение от Vkni (ok), 20-Дек-20, 19:18

Это, конечно, такая средняя температура по больнице. Качество программ сильно зависит от того, кто же именно пишет эти программы, а не от языка, если экосистема достаточно развита.
То есть, в любом случае, когда мы пишем программу, она проходит наш внутренний QC, потом QC конторы (если она есть). И финальный результат - количество ошибок, зависит от этого фильтра. На примере С++ - люди могли прогнать AFL, Valgrind, кучу программ для статического анализа и т.д.
А в чём же роль языка? А в том, что сразу после первого раунда кодирования, у нас получается более или менее глючная программа. Например, на Хаскеле она скорее всего вылетать не будет, а на Питоне - скорее всего найдутся какие-то неправильно вызываемые функции.
Но любой программист в конечном итоге протестирует программу до того уровня, к которому он привык, прежде чем "отправлять на золото". Поэтому итоговая программа на Питоне будет настолько же глючной, как и на Хаскеле. Просто если она достаточно сложна, то программист потратит кучу времени на тестирование и отладку Питонной версии. А если нет, то, наоборот, Хаскель затянет этап проектирования своими типами.

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

34. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от ЧеловекКамелКейс (?), 20-Дек-20, 21:12

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

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

41. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Ковид2024 (?), 20-Дек-20, 21:59

> Это просто статистика, никто не делает прямых выводов
Роспотребпозор делает: https://pashev.me/posts/rospotrebnadzor

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

47. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от Аноним84701 (ok), 20-Дек-20, 23:12

> Это просто статистика, никто не делает прямых выводов. Но как правило, такая
> статистика показывает влияние совокупности факторов(какие программисты используют язык, для каких проектов используют язык).
Статистика-то может и показывает, но есть некоторые сомнения в абсолютно одинаковом качестве анализаторов для разных ЯП (какие-то просто развиваются дольше или командой более квалифицированных специалистов или просто имеют повышенный приоритет в финансировании).
А существенно различающееся качество анализа будет, скорее всего, вносить искажения вплоть до  "> ± лапоть".

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

65. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Vkni (ok), 21-Дек-20, 01:23

> Это просто статистика, никто не делает прямых выводов.
Тогда на кой чёрт статистика нужна? :-)
> Это не потому что большинство програмимистов на Си тупые, а потому
> что у языка есть свои специфичные особенности, которые не сильно обозреваются
> программистами самоучками. Так что, финальный результат зависит не только от "этого
> фильтра".
Переполнение буфера ловится Valgrin, разными программами для статического анализа, правильными примитивами (std::string, например). Проблема в том, что большая часть программистов этим не заморачивается, а языком Цэ пользуется.

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

16. "Анализ зависимости безопасности кода от используемого языка ..." –2 +/–

Сообщение от анонимуслинус (?), 20-Дек-20, 19:24

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

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

24. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от Аноним (24), 20-Дек-20, 20:05

Проблемы C++ от того, что его упорно смешивают с Си. Как правило указатели используется там, где без них можно обойтись и швыряют их через всю программу. Естественно, что надёжность в данном случае как у Си в котором почти всё отдаётся на откуп программисту.

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

27. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от анонимуслинус (?), 20-Дек-20, 20:20

> Проблемы C++ от того, что его упорно смешивают с Си. Как правило
> указатели используется там, где без них можно обойтись и швыряют их
> через всю программу. Естественно, что надёжность в данном случае как у
> Си в котором почти всё отдаётся на откуп программисту.
он тем и хорош , что все под контроль программисту. Проблемы с программистами, нужен хороший уровень знаний и владения языком и тогда он покажет больше раста или го, но таких не так много. управлять вручную большим комбайном кода программы(большой проект) оч сложно и тесты не выявляют всего. это плюсы, тут с этим хуже всего. но когда получается , то программа будет отменной.

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

64. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от АЛМНКАГОГ (?), 21-Дек-20, 01:15

> он тем и хорош , что все под контроль программисту.
В C отнюдь не всё на деле "под контроль программисту". Это всего лишь довольно лживый (и успешный) пропагандистский лозунг, призванный заставить пользоваться C. А на деле - множество разных ситуаций потери контроля. Так в частности ни в C, ни в C++ так ничего за много лет и не сделано против полной потери контроля в случае хотя бы простого арифметического переполнения... Нет даже простого способа обнаружить такое переполнение. В C++ вводятся совершенно дурацкие вещи, но данная проблема не решается.

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

78. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (24), 21-Дек-20, 03:39

> хотя бы простого арифметического переполнения...
Ну так далеко не в каждой архитектуре есть способ обнаружить такое переполнение. Есть вполне стандартные конструкции для проверки переполнения, которые для компилятора не сложно превратить в проверку флага на x86. Да придётся делать проверку каждой операции, только хардкор.

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

148. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от АЛМНКАГОГ (?), 22-Дек-20, 12:11

> Ну так далеко не в каждой архитектуре есть способ обнаружить такое переполнение.
> Есть вполне стандартные конструкции для проверки переполнения,
> которые для компилятора не сложно превратить в проверку флага на x86.
С каждой строкой
нагнетается сайенс
хоть и не хокку.

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

67. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Vkni (ok), 21-Дек-20, 01:33

> он тем и хорош , что все под контроль программисту.
Есть чудесная статья "What every compiler writer should know about programmers" про то, что делают современные компиляторы из "портативного ассемблера". Например, сейчас, de facto, запрещены программы с Undefined Behavior, заточенные специально под конкретное поведение конкретного железа.
В качестве дальнейшего чтения могу предложить "C Is Not a Low-level Language".

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

70. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от АЛМНКАГОГ (?), 21-Дек-20, 01:44

> Undefined Behavior, заточенные специально под конкретное
> поведение конкретного железа.
А при чём здесь железо?
Потеря контроля она и есть потеря контроля. "Железо" не поможет в такой ситуации. Поведение  имеет программа на C, а когда она его не имеет... >:-)

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

137. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от Vkni (ok), 22-Дек-20, 01:46

> А при чём здесь железо?
Почитайте статью. Для примера - под AIX/POWER вы можете разыменовывать NULL - он показывает на нулевую страницу. В результате, структуры типа
struct Tree {
   Tree *left;
   Tree *right;
   void *data;
};
можно отлично использовать с nullptr:
Tree * tree = nullptr;
tree->left == nullptr;
tree->right == nullptr;
tree->data == nullptr;
То есть, мы не должны проверять на nullptr лишний раз - это ускоряет программу.
Поскольку Цэ - это системный язык, он должен уметь использовать на 146% возможности конкретного железа. То есть, он должен уметь использовать это поведение системы.
> Потеря контроля она и есть потеря контроля. "Железо" не поможет в такой
> ситуации. Поведение  имеет программа на C, а когда она его
> не имеет... >:-)
Там нет потери контроля. Программа заточена под определённое железо, на нём она абсолютно предсказуемо работает, но современный компилятор, пользуясь UB перефигачивает её так, что она оказывается сломанной.

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

139. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от АЛМНКАГОГ (?), 22-Дек-20, 02:13

NULL не указывает "на нулевую страницу". Вы не поняли - железо ни при чём. Если у вас обнаружилось, что NULL "указывает на нулевую страницу", то это не "особенности железа". (скорее, это баг компилятора, поскольку оказывается, что NULL указывает на вполне правильную память и объект, который может оказаться и нужным). Для справки: NULL не обязан быть представлен нулевыми битами и определённо не должен быть представлен нулевым физическим адресом, если по этому адресу допустимо и возможно будет необходимо обращаться.

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

142. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от АЛМНКАГОГ (?), 22-Дек-20, 02:43

> Там нет потери контроля. Программа заточена под определённое железо, на нём она
> абсолютно предсказуемо работает, но современный компилятор, пользуясь UB перефигачивает
> её так, что она оказывается сломанной.
:-)))
Смешное заявление: программа работает, но... не работает. При чём заметьте на том же железе.
То есть фактически вы пытаетесь основываться на особенностях компилятора (определённой версии и возможно ещё и определённого режима его работы). Вам кажется что программа должна работать определённо и без потери управления, но это вам только так кажется >:-) Как вы убедились. То, что программа у вас в результате "работает предсказуемо", поскольку вы может быть способны как-то предсказать, как она будет работать, вовсе не значит определённого поведения. Ваши способности к предсказанию и определение поведения программы - вещи весьма разные.

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

150. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Ordu (ok), 23-Дек-20, 03:36

> Смешное заявление: программа работает, но... не работает. При чём заметьте на том же железе
Да. Если взять компилятор из 80-х, будет работать. Если отключить оптимизации в современном компиляторе, будет работать. Если же современный компилятор и с оптимизациями, то работать не будет.
> То, что программа у вас в результате "работает предсказуемо", поскольку вы может быть способны как-то предсказать, как она будет работать, вовсе не значит определённого поведения. Ваши способности к предсказанию и определение поведения программы - вещи весьма разные.
Он дело советует -- сходи и почитай статьи, которые он рекомендует. Вот сходи и почитай, и если останется желание позубоскалить, то зубоскаль. Но сначала почитай.
В том-то и проблема, что предсказать поведение программы теперь невозможно, не учитывая всех тех UB описанных в стандарте, как UB.
Взять, скажем, целочисленное переполнение. В C -- это UB. Которое исторически трактовалось как "сделать то, что процессор делает при сложении целых". То есть, сложение в C было таким сложением, как его понимает CPU. Программисты на это полагались и C был задуман именно таким, чтобы программисты на это полагались: C был высокоуровневым ассемблером. Вдумайся в это: C был сделан именно таким с глубокой инженерной мыслью, предоставить программисту возможность писать "высокоуровневый" код, пользуясь при этом низкоуровневыми операциями, дать возможность программисту оставаться настолько близко к железу, насколько это возможно.
То есть, исходный C предполагал, что программист обладает этой "способностью к предсказанию" поведения кода с UB, на которую ты тут зубоскалишь. Знание программистом архитектуры даёт ему чёткое понимание того, что произойдёт при разадресации NULL. Или что произойдёт при переполнении целого.
Потом пришли современные техники оптимизации кода, которые выполняют оптимизацию многими фазами, и хоть каждая фаза вполне разумна, но в процессе трансформаций кода может теряться смысл выполняемых программой телодвижений, и затем вдруг -- хоп -- и UB становится русской рулеткой: что сделает отоптимизированная программа уже не угадать. Вплоть до дурацких ситуаций, когда UB спрятанный в if(condition) { here_UB(); }, присобачивает программе UB даже при !condition. (Хотя, вроде, такие вещи даже современные компиляторы C считают зашкваром).
Таким образом, C перестал быть высокоуровневым ассемблером. Он превратился в минное поле с разложенными по нему граблями. Теперь сложение С -- это не сложение CPU. На подавляющем большинстве машин целые числа хранятся в дополнительном коде (я, честно говоря, даже не знаю никаких современных процессоров, которые бы делали иначе). Но если я хочу использовать переполнение в своих целях -- например мне как раз нужна арифметика в кольце вычетов по модулю степени двойки, и мне пофигу что там случается с битами, которые вылетают за пределы диапазона, которые поддерживает int, мне главное чтобы достаточное количество младших бит сохранилось бы, -- то я не могу это писать на C. Мне придётся подключать ассемблер для таких вещей. Кстати, я давненько не читывал стандарт на C: они там не запилили в стандарт функций, для того, чтобы работать с переполнением без UB? Что-нибудь типа overflowing_add? Ведь куча крипты работает в кольцах по модулю степени двойки, им бы вовсе не помешало такое дополнение к стандарту.
То есть, современный C переопределил понятие UB, нагрузил его новой семантикой. Если раньше UB было чем-то таким, что неопределено ровно до тех пор, пока мы не определились с архитектурой, под которую пишем программу, а дальше оно чётко определено и предсказуемо, то теперь UB -- это карт-бланш компилятору на выполнение абсолютно любых преобразований кода. Теперь UB остаётся UB всегда, переполнение целого может запустить какой-нибудь builtin компилятора, взрывающий процессор, и типа так и надо, типа "ну а чё вы хотели, у вас же UB отклеился".

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

151. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от АЛМНКАГОГ (?), 23-Дек-20, 12:25

О, адвокат Файрфокса подтянулся, тоже то ещё вредоносное поделие.
> Да. Если взять компилятор из 80-х, будет работать. Если отключить оптимизации в
> современном компиляторе, будет работать. Если же современный компилятор и с оптимизациями,
> то работать не будет.
Что-то мне кажется вопрос скорее в том, как оно будет работать. И дело даже не в оптимизациях.
>> То, что программа у вас в результате "работает предсказуемо", поскольку вы может быть способны как-то предсказать, как она будет работать, вовсе не значит определённого поведения. Ваши способности к предсказанию и определение поведения программы - вещи весьма разные.
> Он дело советует -- сходи и почитай статьи, которые он рекомендует. Вот
> сходи и почитай, и если останется желание позубоскалить, то зубоскаль. Но
> сначала почитай.
Незачем нам ходить. Вам упорно кажется, что поведение программ, поведение которых не определено, является определённым. И вы даже упорно пытаетесь довести это до нас. Компиляторы 80х внезапно не делают ваши примеры чем-то иным, поведение всё равно не определено.
> В том-то и проблема, что предсказать поведение программы теперь невозможно, не учитывая
> всех тех UB описанных в стандарте, как UB.
> Взять, скажем, целочисленное переполнение. В C -- это UB. Которое исторически трактовалось
> как "сделать то, что процессор делает при сложении целых".
Ага. Ordu начал рассказ, как следует трактовать C. Но сей пересказ того, как ему кажется следовало трактовать, значит в целом ничего.
> То есть, исходный C предполагал, что программист обладает этой "способностью к предсказанию"
> поведения кода с UB, на которую ты тут зубоскалишь.
:-))) Это очень плохое предположение. Хотя его и можно допустить. Результат можно наблюдать. Возможно так и было задумано. >:-)
> Знание программистом
> архитектуры даёт ему чёткое понимание того, что произойдёт при разадресации NULL.
> Или что произойдёт при переполнении целого.
Может быть и даёт кстати. Вот только Ordu уже похоже должен начать подозревать, что ему почему-то уже "не даёт". И надо будет приучаться жить с этим >:-)
> Потом пришли современные техники оптимизации кода, которые выполняют оптимизацию многими
> фазами, и хоть каждая фаза вполне разумна, но в процессе трансформаций
> кода может теряться смысл выполняемых программой телодвижений, и затем вдруг --
> хоп -- и UB становится русской рулеткой: что сделает отоптимизированная программа
> уже не угадать.
Короче, от использования "старого компилятора" программа не превращается в имеющую так сказать лучше определённое поведение. Просто получается пример с программой, не имеющей такового. Здесь следует ещё раз сказать, что такой пример не представляет собой чего-то эмпирически отличного, выглядеть может не хуже, а кому-то и лучше, любого примера работы с вполне определённым поведением :-) Мы уже высказались по поводу этого свойства.
> То есть, современный C переопределил понятие UB
Это опять конечно же не так.
Просто кое-кому приходится открыть для себя, что же это такое наконец. И это ещё с высокой вероятностью не конец >:-)

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

152. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Ordu (ok), 23-Дек-20, 14:05

> О, адвокат Файрфокса подтянулся, тоже то ещё вредоносное поделие.
Я что-то сказал в защиту фф? Где? Когда? Слабо найти хотя бы одну ссылку на мою защиту фф за последние 10 лет?
> Что-то мне кажется вопрос скорее в том, как оно будет работать. И
> дело даже не в оптимизациях.
Именно в оптимизациях.
>>> То, что программа у вас в результате "работает предсказуемо", поскольку вы может быть способны как-то предсказать, как она будет работать, вовсе не значит определённого поведения. Ваши способности к предсказанию и определение поведения программы - вещи весьма разные.
>> Он дело советует -- сходи и почитай статьи, которые он рекомендует. Вот
>> сходи и почитай, и если останется желание позубоскалить, то зубоскаль. Но
>> сначала почитай.
> Незачем нам ходить.
Чувак, у тебя догма отклеилась. Если ты мыслишь догматично, хренли ты спорить лезешь? Никому неинтересны твои догмы. А если тебе не интересно, что тебе говорят, то хренли ты лезешь разговаривать со взрослыми дядями? Мама с папой недостаточно внимания уделяют? Или в школе буллят и никто с тобой не общается?

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

155. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от АЛМНКАГОГ (?), 26-Дек-20, 03:25

>> Что-то мне кажется вопрос скорее в том, как оно будет работать. И
>> дело даже не в оптимизациях.
> Именно в оптимизациях.
Вы читали вышенаписанное? Там про NULL. И он не нулевой физический адрес, как многим показалось (хотя может "работать" (и судя по написанному работало) и так). И это не "оптимизация".
> Чувак, у тебя догма отклеилась. Если ты мыслишь догматично, хренли ты спорить лезешь? Никому неинтересны твои догмы.
:-)) Ordu ввязавшемуся в спор неинтересно. И неприятно?

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

156. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от АЛМНКАГОГ (?), 26-Дек-20, 03:47

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

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

157. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от n00by (ok), 26-Дек-20, 09:17

>>> Что-то мне кажется вопрос скорее в том, как оно будет работать. И
>>> дело даже не в оптимизациях.
>> Именно в оптимизациях.
> Вы читали вышенаписанное? Там про NULL. И он не нулевой физический адрес,
На современном железе программы работают с виртуальными адресами. И дело не в языке Си. Трансляция в физические происходит аппаратно через таблицу страниц. Боюсь, Вы банально путаете эти два понятия.
> как многим показалось
А что там на самом деле? Не макрос NULL, который "implementation-defined null pointer constant", а сама эта константа:
§6.3.2.3 Pointers
3 An integer constant expression with the value 0, or such an expression cast to type
void *, is called a null pointer constant.

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

162. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от АЛМНКАГОГ (?), 28-Дек-20, 02:20

> На современном железе программы работают с виртуальными адресами. И дело не в
> языке Си. Трансляция в физические происходит аппаратно через таблицу страниц. Боюсь,
> Вы банально путаете эти два понятия.
Есть один широко известный Адрес, который надо было бояться придётся следовать >:-)

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

163. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от n00by (ok), 28-Дек-20, 09:20

Абырвалг?

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

158. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Ordu (ok), 26-Дек-20, 11:54

>>> Что-то мне кажется вопрос скорее в том, как оно будет работать. И
>>> дело даже не в оптимизациях.
>> Именно в оптимизациях.
> Вы читали вышенаписанное? Там про NULL. И он не нулевой физический адрес,
> как многим показалось (хотя может "работать" (и судя по написанному работало)
> и так). И это не "оптимизация".
Вообще-то, там обсуждается "под контроль программиста". NULL взят в качестве примера. Тебя этот пример сбивает с толку, я предложил поэтому иной -- целочисленное переполнение. Целочисленное переполнение, судя по всему, не сбивает, и тут выясняется, что принять этот пример ты всё равно не можешь, потому что ты веруешь в какую-то догму, и рефлексировать её не в состоянии.
>> Чувак, у тебя догма отклеилась. Если ты мыслишь догматично, хренли ты спорить лезешь? Никому неинтересны твои догмы.
> :-)) Ordu ввязавшемуся в спор неинтересно. И неприятно?
Естественно, когда спор ведётся по правилам детского сада, то есть по принципу: каждый участник повторяет своё утверждение многократно, и проигрывает тот, кому первому надоело.

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

161. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от АЛМНКАГОГ (?), 28-Дек-20, 02:12

> Вообще-то, там обсуждается "под контроль программиста". NULL взят в качестве примера. Тебя
> этот пример сбивает с толку, я предложил поэтому иной -- целочисленное
> переполнение. Целочисленное переполнение, судя по всему, не сбивает, и тут выясняется,
> что принять этот пример ты всё равно не можешь, потому что
> ты веруешь в какую-то догму, и рефлексировать её не в состоянии.
Во-первых вам к Нам следует обращаться отнюдь не "ты".
Никакого примера с переполнением вы не предложили. Лишь высказались про переполнение и как  по-вашему должно работать сложение (во всяком случае похоже попытались - смотреть ниже). Про переполнение, не премину таки отметить, выше написал я.
Ну и поцитирую ещё вас: <<Взять, скажем, целочисленное переполнение. В C -- это UB. Которое исторически трактовалось как "сделать то, что процессор делает при сложении целых".>>. Весёлая цитата, свидетельствующая о незагруженном лишними догмами мышлении - попробуйте вдуматься, что вы здесь написали.
Ну считайте таким образом свой бред про догмы и рефлексирование оных отмеченным и даже удостоенным какого-никакого но не совсем несерьёзного ответа, несмотря на юмор :-)

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

164. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Ordu (ok), 28-Дек-20, 12:41

> Ну считайте таким образом свой бред про догмы и рефлексирование оных отмеченным
> и даже удостоенным какого-никакого но не совсем несерьёзного ответа, несмотря на
> юмор :-)
Ох блин, спасибо, вот уважил старика. Как я надеялся, что ты прочитаешь, и ты прочитал /s
Дурень, твоё мышление -- это твоё мышление, это твой рабочий инструмент, твоё средство для выживания в этом мире. Задачивать его в твоих интересах, а не в моих.

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

68. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от АЛМНКАГОГ (?), 21-Дек-20, 01:33

> Проблемы C++ от того, что его упорно смешивают с Си.
Проблемы у C и C++ в том, что даже вроде бы успешно работающая в тестах программа зачастую может оказаться всё же неправильной. И бывает довольно сложно сказать что либо по поводу правильности выдаваемого конечного результата (не известного заранее) >:-)

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

117. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от PnD (??), 21-Дек-20, 15:18

По моему опыту всё, на чём я (и не только) писал могло оказаться неправильным. И (в принципе) таковым остаётся пожизненно, т.к. математическое моделирование (выливающееся в покрытие тестами) также допускает ошибки.
ASM: Неверное применение инструкций (даже так бывает). Т.к. в современных системах мало справочник перелистать.
ASM,*sh,php: Смешивание кода и данных. Причины разные, а проблемы одни.
С (в моём случае это обычно libc, хотя даже дёргай я напрямую за syscall, как в go поступают — то же самое будет): Опять таки, неверные сценарии работы (с posix). Не обеспечил "wait()" после завершения форка — здравствуй, зомби.
С++ (не моё): Многие начинающие пытаются писать "олимпиадный" код. Потому что "круто".
Go: Всё про параллелизм провоцирует трудно отлаживаемые ошибки. 90% мог бы вычистить стат. анализатор, но его нет. Вплоть до анекдотов, когда мьютекс объявлен внутри функции которую должен контролировать (не всю, но не важно). И "замыленный" глаз это не видит. Также прослеживается тенденция "переписать на безопасном go" (dns, ssl). С неизбежным внесением ошибок в логику.
Perl: Легко написать медленный код, не разобравшись в слабостях языка. Хуже того, некоторые вещи (треды) могут работать не так как ожидается из документации. А отлаживать параллельное выполнение на языке который изначально был не про это — ну так себе.
Python (с 3.х — только "одноразовый" код): Попытка сумничать (ну, язык-то позволяет) порождает откровенный идиотизм.
Все "высокоуровневые" языки (у меня "под боком" — java и erlang): Провоцируют пишущего чувствовать себя "в домике". Код "складывается" под нагрузкой самыми причудливыми образами.
…Короче, побрюзжал. Можно идти дальше писать на том что "под рукой". И хорошо, когда это не авионика для "Боингов".

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

132. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Myyx (?), 21-Дек-20, 22:58

ну так гёдель же еще 100 лет тому назад ...
так шо не парься все ошибаются и я тоже (черт. рекурсия)

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

143. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от АЛМНКАГОГ (?), 22-Дек-20, 03:19

> По моему опыту всё, на чём я (и не только) писал могло
> оказаться неправильным.
Могло, может быть. Но только годное и работоспособное не могло. То, на чём вы писали. Кроме может быть C. :-)
То, что вы писали - это уже очень другое.

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

144. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от АЛМНКАГОГ (?), 22-Дек-20, 03:22

> Кроме может быть C. :-)
...а также, извините, Питона, Явы, Perl, Go... >:-)
(тот ещё набор)...

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

50. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от GG (ok), 21-Дек-20, 00:01

Не совсем.
У всех языков есть проблемы.
У похапе проблемы — это фича.
Фича питона — класть поменьше проблем в дизайн.

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

54. "Анализ зависимости безопасности кода от используемого языка ..." –2 +/–

Сообщение от анонимуслинус (?), 21-Дек-20, 00:14

> Не совсем.
> У всех языков есть проблемы.
> У похапе проблемы — это фича.
> Фича питона — класть поменьше проблем в дизайн.
питон вообще довольно приятный язык, особенно в малых дозах. Не так как на нем пишут целые комбайны. я знаю есть цитон и джит, но он не для этого, даже если прост и довольно удобен. ну php прославился давно, чаще правда из-за криводелов.

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

59. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Урри (ok), 21-Дек-20, 00:42

> Фича питона — класть поменьше проблем в дизайн.
В который - второй или третий?

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

89. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от Аноним (89), 21-Дек-20, 09:55

проверяется при помощи функции file_exists(), которая автоматически выполняет десериализацию метаданных из файлов Phar (PHP Archive) при обработке путей, начинающихся с "phar://", что позволяет применить технику атаки "Phar deserialization". Организовав загрузку специально оформленного Phar-файла под видом вложения, злоумышленник может добиться выполнения своего кода на сервере. Так как функция file_exists() определяет MIME-тип по содержимому, а не по расширению, возможна передача phar-файла под видом картинки (например, phar-файл будет разобран, если его передать как evil.jpg)

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

18. "Анализ зависимости безопасности кода от используемого языка ..." +4 +/–

Сообщение от имя_ (?), 20-Дек-20, 19:31

таблица - теплое с мягким, все как мы любим

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

20. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (20), 20-Дек-20, 19:45

Чота Лиспа не увидел))

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

22. "Анализ зависимости безопасности кода от используемого языка ..." +5 +/–

Сообщение от Аноним (22), 20-Дек-20, 19:55

Фрактааааал! Твой выход!

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

23. "Анализ зависимости безопасности кода от используемого языка ..." +6 +/–

Сообщение от n242name (?), 20-Дек-20, 19:57

Поржал, особенно с JS. 7% code quality. А почему так? Потому что любая дичь в коде происходит в песочнице и почти не влияет на безопасность?
И какой смысл тогда этого анализа для оценки ЯЗЫКА!?
Хорошо там сверху написано: "сферические анализы кала в вакууме"

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

25. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от Аноним (25), 20-Дек-20, 20:07

Да, очень странно, что JS весь в белом и на коне. Хотя в реальной жизни проблем с ним примерно столько же, сколько и с пыхом.

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

28. "Анализ зависимости безопасности кода от используемого языка ..." –2 +/–

Сообщение от Аноним (28), 20-Дек-20, 20:21

Так на жсе, в среднем по больнице, не пишут то, что пишут на сях.

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

31. "Анализ зависимости безопасности кода от используемого языка ..." –6 +/–

Сообщение от Дима (??), 20-Дек-20, 20:50

Справедливости ради JavaScript давно уже стал достаточно универсальным языком, на котором вполне можно писать, как программы для ПК, так и приложения для смартфонов, не говоря уж об его использования на бэкенде. Мне кажется, что в ближайшие годы JavaScript вполне себе потеснит PHP, но прав ли я покажет время)

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

35. "Анализ зависимости безопасности кода от используемого языка ..." –2 +/–

Сообщение от Аноним (35), 20-Дек-20, 21:18

Мне кажется что JS лет столько же, сколько PHP, а толку в плане "становления универсальным" нету.
Во-первых, оно настолько невменяемо спроектировано, что производительность любого варианта JS ниже плинтуса.
Во-вторых, встроенная рантайм библиотека настолько скудная, что горами появляются всякие лефтпады.
В-третьих, язык вообще непригоден для написания универсальных приложений, его испохабили промисами и прочим "счастьем", годным только для куцых окружений браузеров.

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

39. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от Аноним (9), 20-Дек-20, 21:54

> невменяемо спроектировано
Спроектировано вменяемо. Если не согласен -- приводи конкретные примеры.
> производительность любого варианта JS ниже плинтуса
Производительность V8 уделывает остальные скриптовые языки, поскольку использует JIT-компиляцию.
> встроенная рантайм библиотека настолько скудная
Встроенная рантайм-библиотека покрывает большинство задач. Например, конкретно лефтпад уже давно есть в виде String.prototype.padStart.
> язык вообще непригоден для написания универсальных приложений
Язык вообще пригоден для написания универсальных приложений. Если не согласен -- приводи конкретные аргументы. Промисы так и вообще изначально появились не в яваскрипте, да и пригодились далеко за пределами браузера.

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

60. "Анализ зависимости безопасности кода от используемого языка ..." –4 +/–

Сообщение от Урри (ok), 21-Дек-20, 00:47

> Спроектировано вменяемо. Если не согласен -- приводи конкретные примеры.
https://github.com/denysdovhan/wtfjs

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

63. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (9), 21-Дек-20, 01:02

Что это? Список «прикольных)))» вопросов для собеседования? В реальном коде ни с чем таким сталкиваться не приходится. А значительная часть так и вообще имеет аналогии и в других языках. (https://0.30000000000000004.com/ для примера)

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

73. "Анализ зависимости безопасности кода от используемого языка ..." –2 +/–

Сообщение от n242name (?), 21-Дек-20, 02:35

> Что это? Список «прикольных)))» вопросов для собеседования? В реальном коде
> ни с чем таким сталкиваться не приходится. А значительная часть так
> и вообще имеет аналогии и в других языках. (https://0.30000000000000004.com/ для примера)
Вот именно, оно - натуральное ковно, в реальном коде этого ковна никогда не будет (но Васян скзал, что это не точно), а в языке это есть.
JS абсолютно не приспособлен для решения задач, там нет ничего хорошего по сранению с шарпом или джавой.

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

75. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (9), 21-Дек-20, 03:20

> Васян скзал, что это не точно
Берешь гитхаб и ищешь реальные примеры по реальному коду, где бы кому-либо пункты из того «списка)))» доставляли неудобства. Пока примеров нет, тот «список)))» не более, чем прикольное))) чтиво под пивасик))) Но может быть ты пишешь бblдл0код такого уровня, что реально сравниваешь пустой массив с пустым массивом через ==. Тогда ошибка не в языке, а в ДНК твоих родителей.
> JS абсолютно не приспособлен для решения задач
JS абсолютно приспособлен для решения задач. Если есть конкретные претензии -- приводи.
> нет ничего хорошего по сранению с шарпом или джавой
Почему божественный JavaScript должен исключать божественную Java? Каждой задаче свой язык.

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

81. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от Аноним (81), 21-Дек-20, 08:40

> https://github.com/denysdovhan/wtfjs
И чем оно отличается от какого-нибудь Undefined behaviour с/c++?

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

92. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (92), 21-Дек-20, 10:07

Отличается тем что в ecmascript это определенное и стандартизованное поведение

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

124. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от Аноним (81), 21-Дек-20, 21:34

И ведь это лучше, чем рулетка UB в плюсах?

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

90. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (89), 21-Дек-20, 10:01

Используйте typescript

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

145. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (92), 22-Дек-20, 10:46

там большинство вопросов уровня 0.3 + 0.2 и "2" + 2

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

126. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от нитрол (ok), 21-Дек-20, 22:12

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

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

136. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Дима (??), 22-Дек-20, 01:08

Нужно стремится к JavaScript! Суровая правда жизни в том, что в веб-разработке на коне будут те, кто углубленно осваивал JavaScript в свое время. Оглянитесь и поймите, что IT-сфера семимильными шагами движется в направлении все большего развития веб-сервисов и веб-приложений.

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

51. "Анализ зависимости безопасности кода от используемого языка ..." –3 +/–

Сообщение от GG (ok), 21-Дек-20, 00:05

Уже года три как потеснил, с разморозкой.
И вместе с теснением притащил в свои ряды толпы говнокодеров.
Но хотя бы он не такой костыльный, в отличие от пыхи.

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

56. "Анализ зависимости безопасности кода от используемого языка ..." –5 +/–

Сообщение от Gemorroj (ok), 21-Дек-20, 00:37

влажные мечты ньюфага)

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

146. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (92), 22-Дек-20, 10:53

не надо писать на js большие программы, используйти строго статически типизированный typescript

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

69. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от Аноним (69), 21-Дек-20, 01:34

>> Да, очень странно, что JS весь в белом и на коне. Хотя в реальной жизни проблем с ним примерно столько же, сколько и с пыхом.
Тут смотря что с чем сравнивать.
Похоже для php анализатор гоняли на WordPress с плагинами, для плюсов на прошивке ардуины, а для js взяли nodejs.
Вот и результаты.

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

26. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от InuYasha (??), 20-Дек-20, 20:17

Да уж, какой-то малосвязанный и сложно восрпинимаемый список. Однако, многие моменты он отражает верно.
Посмешило "Code Quality" в .Net. Время идёт, а Это не меняется )

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

32. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от Аноним (32), 20-Дек-20, 21:01

А раста нет, потому что на нём студенты пишут хеллоуворлды.

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

43. "Анализ зависимости безопасности кода от используемого языка ..." –2 +/–

Сообщение от Аноним (43), 20-Дек-20, 22:17

Нет, потому что он является безопасным языком.

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

44. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от Аноним (44), 20-Дек-20, 22:26

Не является.

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

36. "Анализ зависимости безопасности кода от используемого языка ..." +5 +/–

Сообщение от Kuromi (ok), 20-Дек-20, 21:36

Зашел почитать комментарии про Rust.

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

128. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (128), 21-Дек-20, 22:40

А чего читать - нет проблем. Почитай лучше про остальные языки как там все плохо у них.

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

38. "Анализ зависимости безопасности кода от используемого языка ..." +31 +/–

Сообщение от Анон666 (?), 20-Дек-20, 21:50

Ну что phpшники? Стало лучше ваше поделие? В каждой версии говорите что вот теперь заживем. 5ая версия мол была не очень а 7 и 8 огонь. Хотя в свое время и 5ую нахваливали. Фрактал плохого дизайна уже не исправить, надо бы закапать но на чем тогда кодить неумехам без желания учиться? А таких всегда много, и пока их много этот ужасный язык со смертельными детскими болячками будет существовать. Может такие аналитические статьи заставят хоть чуть чуть задуматься пхп погромистов с синдромом утенка, и они захотят наконец посмотреть на другие языки а не ждать волшебных изменений в новых версиях.

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

46. "Анализ зависимости безопасности кода от используемого языка ..." –17 +/–

Сообщение от Аноним (46), 20-Дек-20, 23:10

> и они захотят наконец посмотреть на другие языки
И на что смотреть? Какой язык может заменить пхп? Была куча взрослых закапывателей (но - "закопать"), но как-то отсохли и отпали.

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

52. "Анализ зависимости безопасности кода от используемого языка ..." +13 +/–

Сообщение от anon22 (?), 21-Дек-20, 00:07

Если небольшой проект - нода и реакт, javascript же все равно учить надо? Если крупный проект - react/angular + java/kotlin spring. Четкое разделение бекенда и фронта, а не мешанина phpшного кода. Плюс нормальные инструменты для отладки java. Плюс нормальная производительность. Нечеловеческий цикл жизни php приложения не позволяет писать сложную бизнес логику. Лично постоянно сталкиваюсь с пхп проектами на работе - и на каждом совещании только и разговоров как что-то на php развалилось и испортило жизнь клиенту. Бизнесу пофиг, им главное не качество. Php отделы растут быстро, создавая глючные проекты и для их поддержки  набирают еще пыхеров. А совместными усилиями они создают еще больше глючных проектов. Им плевать на архитектуру и качество кода. Пхпшник решивший поднять свой скилл и улучшить качество кода неизбежно будет смотреть на другие языки. И это приведет к переходу на другой язык, ну или он не осилит и будет говорить что пыха тоже крута и у каждого инструмента свое предназначение(с). По факту пыха везде смотрится и работает плохо, ну и статья это подтверждает. А закапыватели не отсохли, просто им пофиг на это поделие. Как было пофиг и мне пока я не стал по работе с ним сталкиваться.(я реально думал что php давно и успешно умер, но нет... пока есть программисты без желания учиться - будет и популярность php)

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

57. "Анализ зависимости безопасности кода от используемого языка ..." –11 +/–

Сообщение от Gemorroj (ok), 21-Дек-20, 00:39

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

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

61. "Анализ зависимости безопасности кода от используемого языка ..." –4 +/–

Сообщение от Урри (ok), 21-Дек-20, 00:55

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

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

91. "Анализ зависимости безопасности кода от используемого языка ..." +3 +/–

Сообщение от PHPexpert (?), 21-Дек-20, 10:02

Как эксперт по пхп подтверждаю - альтернатив просто нет. Есть решения в чем-то лучшие, есть решения лучшие во всём. А есть пхп. Все понимают что это плохая штука, но никто не может сделать альтернативу. Да и зачем делать альтернативу плохому инструменту - если можно не делать, и использовать хорошие инструменты?
Все альтернативы умерли - thymeleaf, mustache, freeMarker. Где они все? Многие пытались, но ни у кого не получилось.

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

95. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от msgod (?), 21-Дек-20, 10:33

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

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

98. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от PHPexpert (?), 21-Дек-20, 10:51

>Ниче что шаблонизатор это всего лишь либа?
Шаблонизатор это не просто либа. Это целый язык программирования! Откройте hh, введите php - и увидите насколько востребовано программирование на шаблонизаторах. Может ваш thymleaf предоставить те же возможности, что и php? Вряд ли, ведь среди шаблонизаторов только на php написано столько фреймворков.
>Рендер страниц давно перенесен на фронт. И беку достаточно отдавать модели по ресту, а уж рисовать страницу это дело фронта
Ну вот вы и подтвердили мои слова. Альтернатив php нет. Вы предлагаете хорошее решение, но это не альтернатива php. Альтернатива php - это если завтра под freemarker появится свой laravel.

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

99. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от msgod (ok), 21-Дек-20, 11:29

Зачем шаблонизатору выполнять что то кроме рендера страницы перед тем как ее отдать браузеру?
Данные шаблонизатору отдает низлежащий стек. В случае jvm там множество вариантов. Все языки и стеки по факту

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

101. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от PHPexpert (?), 21-Дек-20, 11:36

>Зачем шаблонизатору выполнять что то кроме рендера страницы перед тем как ее отдать браузеру?
Данные шаблонизатору отдает низлежащий стек. В случае jvm там множество вариантов. Все языки и стеки по факту
Напомню, что речь шла именно об альтернативе php. Зачем - уже другой вопрос.
То, что у вас есть варианты лучше - ок, но у вас нет альтернатив php.
Кто-то скажет, что вычисления на шаблонизаторе не нужны, что это плохая практика. Но мы уже определили, что php плохой инструмент. Альтернатив ему нет, но есть нормальные решения, позволяющие вообще не использовать php и "альтернативы" ему.

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

100. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от msgod (ok), 21-Дек-20, 11:35

>Альтернатива php - это если завтра под freemarker появится свой laravel.
Ну что тут сказать...
Jsp/jsf в ЕЕ лет 20, SpringMVC в спринге не меньше.
Они входят в стеки.
Но используются практически нигде. Стейтфул сервер сайд фронт на шаблонах сейчас применяется только в легаси.
Современный веб это стейтлесс клиент сайд рендер.
Все нормальные инструменты jvm умеют все. И легаси и даже асинхронный реактивный бекенд, который я сомневаюсь что есть в пхп

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

102. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от PHPexpert (?), 21-Дек-20, 11:51

>Jsp/jsf в ЕЕ лет 20, SpringMVC в спринге не меньше.
Это фреймворки java, а не freemarker. Всё равно что сравнивать фреймворки на C(на которой написана "среда исполнения" php) и фреймворки на самом PHP.

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

104. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от msgod (ok), 21-Дек-20, 12:09

Ну тебе же нужен был аналог ларавеля. Чтопизкаропки.
Они и есть аналог.
При этом любой другой шаблонизатор можно подключить как либу.
Ну и что там у вас в пхпмирке с асинхронным реактивным бекендом?
Или вы там вообще не слышали что такое реактивный веб и до сих пор рендерите страницы на сервере?

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

105. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от PHPexpert (?), 21-Дек-20, 12:15

> Ну тебе же нужен был аналог ларавеля. Чтопизкаропки.
> Они и есть аналог.
Мне точно не нужен. И это не аналог, я уже объяснил.
> Ну и что там у вас в пхпмирке с асинхронным реактивным бекендом?
Если надо использовать асинхронный бэкенд, то любой php'шник знает что нужно использовать ноду.

> Или вы там вообще не слышали что такое реактивный веб и до
> сих пор рендерите страницы на сервере?
В основном да, так и есть.

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

74. "Анализ зависимости безопасности кода от используемого языка ..." –3 +/–

Сообщение от n242name (?), 21-Дек-20, 02:52

> Если небольшой проект - нода и реакт, javascript же все равно учить
> надо? Если крупный проект - react/angular + java/kotlin spring. Четкое разделение
Javascript учить НЕ НАДО, но к сожалению придется, пока не переедем на WebAssembly и какой-нибудь Blazor и аналоги.

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

76. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от Аноним (9), 21-Дек-20, 03:25

> пока не переедем на WebAssembly
Мусье не в курсе, что WebAssembly не создавался, как замена яваскрипту?

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

109. "Анализ зависимости безопасности кода от используемого языка ..." –2 +/–

Сообщение от n242name (?), 21-Дек-20, 13:28

>> пока не переедем на WebAssembly
> Мусье не в курсе, что WebAssembly не создавался, как замена яваскрипту?
зато будет использоваться как замена - 100%
доступ к DOM у него уже есть
Telerik и прочие уже клепают контролы
все к этому и движется

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

116. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (9), 21-Дек-20, 14:29

У WebAssembly нет доступа к дому, мань. Он лишь в состоянии вызывать функции, которые предоставил ему загрузчик на JavaScript. И, если речь идет не о числодробилках, очень сомнительно, что в обычных формошлепских сценариях WebAssembly будет быстрее, чем JavaScript, поскольку данные, при пересечении границы между WebAssembly и JavaScript, должны (де)кодироваться.
Хочешь отправить в wasm строку и получить результат в виде строки? Задекодируй родную яваскриптовую строку из WTF-16 в UTF-8, вызови функцию в wasm, а теперь получи результат, перекодировав его из UTF-8 обратно в WTF-16. В итоге wasm-приложуха будет работать медленнее. Та же проблема у нативных модулей NodeJS, поэтому, например, парсинг XML работает существенно быстрее, если его написали на чистом JS, а не воспользовались сишным libxml2 через врапперы.

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

118. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от n242name (?), 21-Дек-20, 15:22

>[оверквотинг удален]
> функции, которые предоставил ему загрузчик на JavaScript. И, если речь идет
> не о числодробилках, очень сомнительно, что в обычных формошлепских сценариях WebAssembly
> будет быстрее, чем JavaScript, поскольку данные, при пересечении границы между WebAssembly
> и JavaScript, должны (де)кодироваться.
> Хочешь отправить в wasm строку и получить результат в виде строки? Задекодируй
> родную яваскриптовую строку из WTF-16 в UTF-8, вызови функцию в wasm,
> а теперь получи результат, перекодировав его из UTF-8 обратно в WTF-16.
> В итоге wasm-приложуха будет работать медленнее. Та же проблема у нативных
> модулей NodeJS, поэтому, например, парсинг XML работает существенно быстрее, если его
> написали на чистом JS, а не воспользовались сишным libxml2 через врапперы.
Байндинги в самих фреймворках не проблема.
Да сделаны через интероп, ну так практически теже проблемы в TS,
Bridge.NET или любых транспайлерах. Но эту тему будут развивать, не так ли?
уже сейчас Blazor при примере позволяет писать вот так:

@using System.Net.Http
@inject HttpClient Http
<input @bind="newItemName" placeholder="New Todo Item" />
<button @onclick="@AddItem">Add</button>
@code {
    private string newItemName;
    private async Task AddItem()
    {
        var addItem = new TodoItem { Name = newItemName, IsComplete = false };
        await Http.PostAsJsonAsync("api/TodoItems", addItem);
    }
}
Вот надо и потестировать что быстрее какой-нибудь вуй или кнокаут.
Но я не думаю что первомансу будет страдать, а вот выбирать язык для RIA - это серьезный шаг.

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

119. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (9), 21-Дек-20, 15:41

> Вот надо и потестировать что быстрее
Вот и протестируй, а затем уже предлагай. Чем больше WebAssembly зависит от браузерного API, тем меньше в нем смысла.
Если wasm выбирается по критерию "он вроде как быстрее", то он этот критерий не пройдет из-за интеропа (js-функцию вызывать гораздо дешевле, чем wasm-функцию, и js-функцию вызывать гораааААААаааздо дешевле, чем ту же самую js-функцию, но через wasm -- а именно это и происходит в твоем PostAsJsonAsync).
Преимуществ перед TypeScript не вижу. Мало того, что он тоже предоставляет async/await, мало того, что он дает TSX-синтаксис для реакта и т.п., так он еще и не будет кодировать/декодировать данные для boundary crossing. Таким образом, TypeScript будет __на_порядки__ быстрее твоего кода.
WebAssembly предназначен для довольно редких задач, и формошлепство с todo-itemами в их число не входит.

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

134. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от n242name (?), 22-Дек-20, 00:05

1) не для скорости, а для платформы
2) не будет он на порядки быстрее, тупит DOM, а не АПИ к нему и уже тем более, не вычисления, в 99% на UI нет таких вычислений. А если мы говорим о каких-то нестандартных потребностях типа хеширования на клиенте или еще что-то подобное, то такиая числодробилка будет на wasm работать быстрее.
Но еще раз повторюсь про быстрее - это тебя волновало! Меня волновал код!
И TS это нечерта не альтернатива ни C# ни Java, TS - это очередной фракенштейн, накачанный стероидами.
В общем надо не только слюной брызгать, но и стараться слушать. Тебе про одно говорят, а ты про другое.
P.S. парсинг XML можно сделать с помощью DOM, т.е. самим браузером, что там под капотом JS было хз. Но мне честно говоря пох. И выше написал почему.

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

138. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (9), 22-Дек-20, 01:49

> такиая числодробилка будет на wasm работать быстрее
Правильно. И это -- один из редчайших случаев, когда wasm реально применяется там, для чего он и создавался. Причем даже в этой задаче твои сишарпы нафиг не нужны, можно заюзать публично доступные алгоритмы на Си. Может даже получится обойтись без malloc/free и получить wasm-бинарник размером меньше 1024 байт.
> TS это нечерта не альтернатива ни C# ни Java
Ты это повторяешь из раза в раз, но так и не сумел представить хоть какой-то аргумент, почему TypeScript плохой. Если речь про бэкенд, то да, в бэке лучше заюзать православную Java + Spring. Но на фронте зачем мне Java, когда уже есть TypeScript?
> парсинг XML можно сделать с помощью DOM
DOM -- не единственный API к XML (а в ноде он так и вовсе отсутствует). Встроенный браузерный API не дает S(t)AX парсера к XML.

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

140. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от n242name (?), 22-Дек-20, 02:13

тем, что TypeScript это все еще JS
если надо объяснять чем JS плох, то дафай досфидания )))

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

141. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (9), 22-Дек-20, 02:24

Да не, слиться любой может. А ты вот попробуй не сливаться и реально попытайся объяснить, чем плох JS.

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

125. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Ordu (ok), 21-Дек-20, 21:37

> Хочешь отправить в wasm строку и получить результат в виде строки? Задекодируй родную яваскриптовую строку из WTF-16 в UTF-8, вызови функцию в wasm, а теперь получи результат, перекодировав его из UTF-8 обратно в WTF-16.
Хочу спросить, для повышения образованности. А почему бы не закинуть в wasm строку в WTF-16? wasm жеж ассемблер, какая ему разница, с какими строками работать?

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

96. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от msgod (ok), 21-Дек-20, 10:40

Ts, dart.
Ангуляр и вполне умеет

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

110. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от n242name (?), 21-Дек-20, 13:32

> Ts, dart.
> Ангуляр и вполне умеет
TS - кастрат, потому что под капотом это тот же JS, там из нормального только типизация.
Dart - это дно, может мышки и будут жрать кактус, но это с рождения кактус.
P.S. у меня больше веры в ржавого, чем в дарт.

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

53. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от GG (ok), 21-Дек-20, 00:08

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

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

62. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от Урри (ok), 21-Дек-20, 00:57

А можно примеры нормальных фреймворков? Таких, что бы были не хуже и не медленнее пхп.
И еще, желательно, чтобы писать было не медленнее и не сложнее.

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

66. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от GG (ok), 21-Дек-20, 01:26

> А можно примеры нормальных фреймворков? Таких, что бы были не хуже и
> не медленнее пхп.
> И еще, желательно, чтобы писать было не медленнее и не сложнее.
Тебе фляжки с джангой для чего-то не хватает?
Медленность упирается в говнокод, сложные вычисления без использования предназначенных для этого библиотек и говнокод.
В синтетике питон в сто раз медленнее, на практике он в пять раз быстрее.
Потому что синтетику решает специальная библиотека на сишечке, а кривых запросов в базу меньше.

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

84. "Анализ зависимости безопасности кода от используемого языка ..." +4 +/–

Сообщение от son (?), 21-Дек-20, 09:18

самый медленный язык в мире(php) в последней версии ускорили на 10%, теперь php бояре выбирают платформу "не медленее php". Это не сложно - все еще любая другая платформа быстрее пыхи. И лучше конечно-же. Другие платформы же не создавались для умственно отсталых.

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

108. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от msgod (ok), 21-Дек-20, 12:57

Любой асинхронный фреймворк на питоне, го или яве работает в десятки или сотни раз быстрее пхп.
Даже синхронный джанго быстрее

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

114. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от Gogi (??), 21-Дек-20, 14:02

Вот ты утёнок! У нас что, ASP.NET отменили?? Причём ламерам можно начать с BASIC, профи сразу прыгнут в C#.

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

147. "Анализ зависимости безопасности кода от используемого языка ..." +1 +/–

Сообщение от hex (??), 22-Дек-20, 11:43

ASP.NET это винда и проприетарщина. Не забываем на каком мы ресурсе, а вот про ASP.NET забываем.. забываем...

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

86. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от Аноним (85), 21-Дек-20, 09:45

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

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

40. "Анализ зависимости безопасности кода от используемого языка ..." –10 +/–

Сообщение от Fracta1L (ok), 20-Дек-20, 21:55

> В проектах на С++ чаще всего встречаются проблемы, связанные с некорректной ... работой с буферами (46.8%)
Дырявые плюсовики в принципе не умеют работать с буферами, потому что дырявые

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

103. "Анализ зависимости безопасности кода от используемого языка ..." +3 +/–

Сообщение от Аноним (103), 21-Дек-20, 12:03

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

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

159. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Косплеер Фрактала (?), 26-Дек-20, 16:08

Потому что дырявый...

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

45. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (45), 20-Дек-20, 22:57

Как на JS написать уязвимость вида "Directory traversal"? Какие директории у клиента в браузере?

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

55. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от Аноним (9), 21-Дек-20, 00:31

Твои представления о том, что JS может выполняться исключительно в браузере, устарели еще в 90-ых. Даже в Проводнике Windows 98 боковая панель с голубоватым уголком была написана на диалекте яваскрипта (JScript).

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

49. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (49), 20-Дек-20, 23:51

Видимо опять сравнили количество ошибок в helloword'ах в песочнице с операционными системами и опять открывают амкрику: если ничего не делать, то ничего и не сломается.

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

79. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (79), 21-Дек-20, 06:51

А кто-нибудь понял от чего эти проценты взяты? Что символизируют эти циферки и с какого потолка они взяты?
Где можно посмотреть кол-во ошибок на каждые 1000 строк кода по каждому языку?

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

80. "Анализ зависимости безопасности кода от используемого языка ..." +2 +/–

Сообщение от Аноним (80), 21-Дек-20, 08:21

> наиболее проблемным оказался код на PHP
Кто хотя бы раз видел код на PHP, поймёт (там люди тупо выживают - не до безопасности).

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

88. "Анализ зависимости безопасности кода от используемого языка ..." –2 +/–

Сообщение от Аноним (85), 21-Дек-20, 09:48

Какие заказчики, такие и исполнители, такой и код. Поспешишь - людей насмешишь, скупой платит дважды, Васька слушает - да ест.

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

113. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Gogi (??), 21-Дек-20, 13:58

У семи нянек дитя без глаза. Кто рано встаёт, тобу бог подаёт.
Итак, симпозиум народного фольклора считается открытым! :))

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

129. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (128), 21-Дек-20, 22:43

Кто хочет соскакивает.

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

82. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от th3m3 (ok), 21-Дек-20, 09:02

>наиболее проблемным оказался код на PHP
Это и так все давно знали.

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

94. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (93), 21-Дек-20, 10:19

Лучшие сишные дырени в PHP :)

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

130. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (128), 21-Дек-20, 22:44

Какая-то реклама притона для взрослых?

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

112. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от Gogi (??), 21-Дек-20, 13:57

Эта rовностатистика трещит по всем швам:
1. НЕ ТОЛЬКО язык влияет на секурность, но корреляция конечно же есть. Примерно процентов на 30.
2. Безопасность - это больше про людей - те самые 70%. Очевидно, что если анализировать FOSS-проекты, то и аудитория там соответствующая - энтузазисты разного пошиба.
3. Без статистики по реально профессиональному коду, говорить о языках вообще незачем. Вот если среди профи посмотреть "секурность кода" - тогда да, можно поговорить о языке и насколько хорошо он помогает прогеру избегать проблем.
> наиболее проблемным оказался код на PHP
Кто б удивлялся! За такое г**** берутся лишь ламо, да и язык написан таким же долбоклюем. Так что похапэха - безусловное днищще ИТ.

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

121. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Ordu (ok), 21-Дек-20, 17:24

> Эта rовностатистика трещит по всем швам:
Ты на себя-то глянь, да?
> 1. НЕ ТОЛЬКО язык влияет на секурность, но корреляция конечно же есть. Примерно процентов на 30.
> 2. Безопасность - это больше про людей - те самые 70%. Очевидно, что если анализировать FOSS-проекты, то и аудитория там соответствующая - энтузазисты разного пошиба.
Откуда ты взял корреляцию в 30%? Из головы выдумал? Покажи, что ты мерял и как ты считал, или балабол. Они хотя б какую-то методику измерений разработали, и хрен с ними с числами, но сами по себе списки распространённых проблем свойственных тому или иному языку весьма любопытны.
> 3. Без статистики по реально профессиональному коду, говорить о языках вообще незачем. Вот если среди профи посмотреть "секурность кода" - тогда да, можно поговорить о языке и насколько хорошо он помогает прогеру избегать проблем.
Что такое "реально профессиональный код", где его можно найти, и как его можно создавать? Предполагая, что ты можешь ответить на этот вопрос, я делаю вывод, что "реально профессиональный код" не существует, никто его не разрабатывает, потому что в любой команде есть пара стажёров/джуниоров, потому что сеньоры слакают, пропуская баги в релизы... Да и вообще, не существует двух одинаковых кодобаз, не существует двух одинаковых команд -- как можно игнорировать эти неустранимые различия, сравнивая языки?
К их исследованию, у меня лично, другие претензии -- там вместо статьи, описывающей методику измерений, какой-то набитый жабаскриптом сайт. Очень красиво и впечатляюще, брызги смузи летят во все стороны, но он без 3rd-party скриптов сайт полунерабочий, а то что работает -- сплошной маркетинговый буллшит, а не описание методики измерений. Статистика же (любая статистика!) -- бессмыслица, в отрыве от методики её получения. Судя по 130k исследованных проектов, данные были получены автоматически. Статическим анализатором? Пример проблемы в студию? Мне скажем очень интересно, что это за CRLF проблемы в java, было бы интересно примерчик. Или что значит "проблемы с менеджментом буферов" в C++? Переполнение буфера идёт отдельной статьёй, а что там ещё может пойти не так? underflow? Ошибки в адресной арифметике? Забыли выделить новый блок памяти под буфер или освободить старый? Но, если что-то из этого, почему это собрано в отдельную категорию с буферами, если адресная арифметика -- это адресная арифметика, а выделение/освобождение памяти -- это управление памятью? То есть это что-то иное? Что именно? Вопросов возникает тьма, а найти ответы на них не представляется возможным.
Всё это исследование -- маркетинговый буллшит. Отделу продаж не выйти за плановые показатели. Вот они и нарисовали красивую цветастую табличку, и стали делать громкие заявления. И опеннет с гиканьем и воем рванулся помогать маркетологам создавать много шума из ничего. Хорошо хоть опеннет в своём корыте инкапсулирован, и шум здесь никак не помогает маркетологам.
Я даже могу подсказать тебе эвристику, как отличать совсем уж буллшит от всего остального: если исследование не буллшит, то к нему должна прилагаться в самом очевидном месте ссылка на pdf, в котором есть ответы на все вопросы к исследованию, которые ты можешь измыслить. Читать pdf не обязательно, достаточно открыть и посмотреть, есть ли там ответы на твои вопросы. Вникать в ответы тоже кстати не обязательно, достаточно посмотреть на их наличие. Это очень грубая эвристика, но она применяется элементарно меньше чем за минуту, и она позволяет отсеять очень много информационного шума.
Если у тебя верхнее образование есть, и, соответственно, ты представляешь себе структуру научной статьи о проведённом исследовании, то обрати внимание на соблюдение этой структуры, чтобы там было введение (вводящее в контекст, в котором исследование проводится), глава посвящённая related works может отсутствовать (это подозрительно, но не критично), должно быть чётко расписано как данные были получены, и как они были обработаны. Плюс должен быть раздел типа discussion, в котором немного балабольства на тему, какие выводы из этого исследования можно сделать, или как это исследование можно улучшить, дополнить другим исследованием, и тп. Если ничего этого нет, то либо исследование целенаправленно пытается ввести тебя в заблуждение, либо оно было проведено дилетантом, который не имеет ни образования в теме проведения исследований, ни опыта проведений этих самых исследований.

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

120. "Анализ зависимости безопасности кода от используемого языка ..." +/–

Сообщение от Аноним (120), 21-Дек-20, 17:19

Правильный заголовок: PHP признан самым небезопасным языком.

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

122. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от Аноним (122), 21-Дек-20, 19:57

Ниочем. Анализ на уровне отписки студента первого курса по предмету мат. статистики. На троечку.
Распилили бабло и сделали отписку.

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

123. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от Аноним (122), 21-Дек-20, 19:58

Раст самый безопастный. Нет кода - нет ошибок.

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

131. "Анализ зависимости безопасности кода от используемого языка ..." –1 +/–

Сообщение от Аноним (128), 21-Дек-20, 22:46

Code less error too ...

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

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

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

Партнёры:

Хостинг:

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

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

1. "Анализ зависимости безопасности кода от используемого языка ..."	+17 +/–
Сообщение от Аноним (1), 20-Дек-20, 18:53
Какие-то языки ни о чём выбраны. Где хайповые языки? Где Rust, Go, Haskell, Ada?
Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Анализ зависимости безопасности кода от используемого языка ..."	+47 +/–
	Сообщение от Анонимно (ok), 20-Дек-20, 18:58
	На этих языках еще нечего анализировать, кроме хайпа
	Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Анализ зависимости безопасности кода от используемого языка ..."	+1 +/–
	Сообщение от mos87 (ok), 20-Дек-20, 19:02
	is it safe?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Анализ зависимости безопасности кода от используемого языка ..."	+11 +/–
	Сообщение от Аноним (10), 20-Дек-20, 19:05
	Хайп Ada был году в 1980 наверное. И хаскеля тогда же. Так что "еще" тут слабо применимо.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	48. "Анализ зависимости безопасности кода от используемого языка ..."	+1 +/–
	Сообщение от Ordu (ok), 20-Дек-20, 23:47
	Разве haskell не в начале 90-х появился?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	97. "Анализ зависимости безопасности кода от используемого языка ..."	+6 +/–
	Сообщение от n00by (ok), 21-Дек-20, 10:45
	Это побочный эффект от ленивых вычислений.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	106. "Анализ зависимости безопасности кода от используемого языка ..."	+1 +/–
	Сообщение от Ordu (ok), 21-Дек-20, 12:34
	> Это побочный эффект от ленивых вычислений. Но ведь основная фишка функционального программирования -- отсутствие побочных эффектов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	115. "Анализ зависимости безопасности кода от используемого языка ..."	–1 +/–
	Сообщение от n00by (ok), 21-Дек-20, 14:10
	В том что и дело. Наблюдаемый результат работы алгоритма суть побочный эффект.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	72. "Анализ зависимости безопасности кода от используемого языка ..."	–1 +/–
	Сообщение от OpenEcho (?), 21-Дек-20, 02:30
	Не спорьте... вот ниже вся история и наглядно https://www.youtube.com/watch?v=Og847HVwRSI
	Ответить \| Правка \| К родителю #10 \| Наверх \| Cообщить модератору


	7. "Анализ зависимости безопасности кода от используемого языка ..."	+21 +/–
	Сообщение от Аноним (-), 20-Дек-20, 19:04
	> Haskell, Ada > хайповые Дед, ты опять забыл принять свои таблетки?
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	19. "Анализ зависимости безопасности кода от используемого языка ..."	+5 +/–
	Сообщение от Аноним (1), 20-Дек-20, 19:36
	Ещё хуже. Мне прописали вводить смузи. Запамятовал вот, пропустил процедуру. Пойду на Nim водить.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Анализ зависимости безопасности кода от используемого языка ..."	–2 +/–
	Сообщение от lockywolf (ok), 20-Дек-20, 19:51
	Попробуй lean
	Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Анализ зависимости безопасности кода от используемого языка ..."	–1 +/–
	Сообщение от lockywolf (ok), 20-Дек-20, 19:09
	Cobol и basic.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	93. "Анализ зависимости безопасности кода от используемого языка ..."	+/–
	Сообщение от Аноним (93), 21-Дек-20, 10:15
	Ada - хайповый?
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	107. "Анализ зависимости безопасности кода от используемого языка ..."	+/–
	Сообщение от Соня Мармеладова (?), 21-Дек-20, 12:40
	Он не только хайповый, но и самый опасный: два 737х уконтропупили на нем.
	Ответить \| Правка \| Наверх \| Cообщить модератору

2. Скрыто модератором	–7 +/–
Сообщение от iPony129412 (?), 20-Дек-20, 18:55
👉👌 🤨 С➕➕
Ответить \| Правка \| Наверх \| Cообщить модератору


	8. Скрыто модератором	+6 +/–
	Сообщение от mos87 (ok), 20-Дек-20, 19:04
	>👉👌 дзюбишь?
	Ответить \| Правка \| Наверх \| Cообщить модератору

4. "Анализ зависимости безопасности кода от используемого языка ..."	–1 +/–
Сообщение от Аноним (-), 20-Дек-20, 18:58
а swift ?
Ответить \| Правка \| Наверх \| Cообщить модератору

5. "Анализ зависимости безопасности кода от используемого языка ..."	+11 +/–
Сообщение от mos87 (ok), 20-Дек-20, 19:01
сферические анализы кала в вакууме
Ответить \| Правка \| Наверх \| Cообщить модератору


	135. "Анализ зависимости безопасности кода от используемого языка ..."	+/–
	Сообщение от Секрет (?), 22-Дек-20, 01:07
	На яве и нете, если плохое качество кода впереди, значит уровень разработчика не очень, значит и в принципе все дубовые ошибки в комплекте :)
	Ответить \| Правка \| Наверх \| Cообщить модератору

9. "Анализ зависимости безопасности кода от используемого языка ..."	+3 +/–
Сообщение от Аноним (9), 20-Дек-20, 19:05
Как я и говорил, безопасность -- это не про похапешников. Самый позорный показатель по всему айти в целом.
Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Анализ зависимости безопасности кода от используемого языка ..."	+/–
	Сообщение от Бел аноним (?), 20-Дек-20, 19:12
	Ну да, бест практис не сильно распространены и язык более популярный чем остальные в списке. Закономерно
	Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Анализ зависимости безопасности кода от используемого языка ..."	+3 +/–
	Сообщение от Аноним (14), 20-Дек-20, 19:16
	Заказчику работ не нужны practices
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Анализ зависимости безопасности кода от используемого языка ..."	+/–
	Сообщение от Аноним (9), 20-Дек-20, 19:28
	> язык более популярный чем остальные в списке Откуда дровишки? Есть хотя бы один рейтинг популярности ЯП, где бы пыха обгоняла яву, пихон или жс? Проблема пыха в том, что он одним своим неконсистентным дизайном не располагает к написанию качественного кода. Адская мешанина высокоуровневой Java и низкоуровневого Си. Ну и будем честны, в индустрии "создания сайтов быстро под ключ" работают преимущественно студенты [юрфака]. Борьбу с SQL-инъекциями пыхеры освоили позже всех, помню году в 2007 я заходил на любой сайт на пыхе, подставлял апостроф к айдишнику чего-либо (index.php?id=123') и получал sql syntax error для каждого второго пыхо-сайта, без преувеличений.
	Ответить \| Правка \| К родителю #12 \| Наверх \| Cообщить модератору


	29. "Анализ зависимости безопасности кода от используемого языка ..."	–1 +/–
	Сообщение от Нитрофос (?), 20-Дек-20, 20:23
	денис_борисов.jpg
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "Анализ зависимости безопасности кода от используемого языка ..."	–1 +/–
	Сообщение от Lex (??), 20-Дек-20, 20:47
	Ставить жабу по популярности в один ряд с питоном и жс :) Даже интересно, если не считать разработку под андройд( в которой даба стремительно летит на свалку ), то какова будет реальная «популярность» джавы.
	Ответить \| Правка \| К родителю #17 \| Наверх \| Cообщить модератору


	58. "Анализ зависимости безопасности кода от используемого языка ..."	+2 +/–
	Сообщение от Урри (ok), 21-Дек-20, 00:40
	Какая, какая - очень большая. Начиная с корпоративного сектора, которым пользуются миллиарды и десятки тысяч это кодят.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	127. "Анализ зависимости безопасности кода от используемого языка ..."	+/–
	Сообщение от Lex (??), 21-Дек-20, 22:39
	> Какая, какая - очень большая. Начиная с корпоративного сектора, которым пользуются миллиарды > и десятки тысяч это кодят. Т.е в этом рейтинге в "популярность" джава не зачсчитывается разработка приложений и проч под огромное множество мобильных устройств( и даже не потому, что жаба "нереально крутая", а потому, что это просто один из ключевых применяемых ЯП в разработке приложений для той ОСи ), не так ли ?) Начиная со сказок про интыпрайз.. ими, впрочем, и заканчивая.. но потом правда окажется, что на джаве говнокодить ощутимо проще, а сам тот говнокод - ощутимо забристей в сравнении со многими другими ЯП а саму жабу усиленно теснят все кому ни лень, в т.ч питон да го.. да даже главконтора потихоньку сваливает в разработке с джавы на Котлин а то и вовсе, на дарт.. но, разумеется, это не потому, что жаба - громоздкий и невыразительный мусор, а потом что она слишком хорошо для них :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	133. "Анализ зависимости безопасности кода от используемого языка ..."	–1 +/–
	Сообщение от Тариф Анонимище (?), 21-Дек-20, 23:41
	Ты тут для самоуспокоения пишешь? Как видишь, желающих нет обсуждать подростковые эмоциональные тексты. Сходи погугли, наберись немного знаний о предмете, о котором тут пытаешься вещать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	149. "Анализ зависимости безопасности кода от используемого языка ..."	+/–
	Сообщение от Lex (??), 22-Дек-20, 13:24
	> Ты тут для самоуспокоения пишешь? Нет, просто забавляют тормозА, до сих пор всерьез считающие жабу сурьезным ынтепрайзом "и вообще, за ней будущее"(ц)
	Ответить \| Правка \| Наверх \| Cообщить модератору