Компания Veracode, специализирующаяся на разработке средств для проведения аудита безопасности, опубликовала результаты сравнения языков программирования в контексте безопасности написанного на них кода. Отчёт подготовлен на основе результатов статического анализа более 130 тысяч приложений...Подробнее: https://www.opennet.me/opennews/art.shtml?num=54289
Какие-то языки ни о чём выбраны. Где хайповые языки? Где Rust, Go, Haskell, Ada?
На этих языках еще нечего анализировать, кроме хайпа
is it safe?
Хайп Ada был году в 1980 наверное. И хаскеля тогда же. Так что "еще" тут слабо применимо.
Разве haskell не в начале 90-х появился?
Это побочный эффект от ленивых вычислений.
> Это побочный эффект от ленивых вычислений.Но ведь основная фишка функционального программирования -- отсутствие побочных эффектов.
В том что и дело. Наблюдаемый результат работы алгоритма суть побочный эффект.
Не спорьте... вот ниже вся история и наглядно
> Haskell, Ada
> хайповыеДед, ты опять забыл принять свои таблетки?
Ещё хуже. Мне прописали вводить смузи. Запамятовал вот, пропустил процедуру. Пойду на Nim водить.
Попробуй lean
Cobol и basic.
Ada - хайповый?
Он не только хайповый, но и самый опасный: два 737х уконтропупили на нем.
👉👌 🤨С➕➕
>👉👌дзюбишь?
а swift ?
сферические анализы кала в вакууме
На яве и нете, если плохое качество кода впереди, значит уровень разработчика не очень, значит и в принципе все дубовые ошибки в комплекте :)
Как я и говорил, безопасность -- это не про похапешников. Самый позорный показатель по всему айти в целом.
Ну да, бест практис не сильно распространены и язык более популярный чем остальные в списке. Закономерно
Заказчику работ не нужны practices
> язык более популярный чем остальные в спискеОткуда дровишки? Есть хотя бы один рейтинг популярности ЯП, где бы пыха обгоняла яву, пихон или жс?
Проблема пыха в том, что он одним своим неконсистентным дизайном не располагает к написанию качественного кода. Адская мешанина высокоуровневой Java и низкоуровневого Си. Ну и будем честны, в индустрии "создания сайтов быстро под ключ" работают преимущественно студенты [юрфака].
Борьбу с SQL-инъекциями пыхеры освоили позже всех, помню году в 2007 я заходил на любой сайт на пыхе, подставлял апостроф к айдишнику чего-либо (index.php?id=123') и получал sql syntax error для каждого второго пыхо-сайта, без преувеличений.
денис_борисов.jpg
Ставить жабу по популярности в один ряд с питоном и жс :)
Даже интересно, если не считать разработку под андройд( в которой даба стремительно летит на свалку ), то какова будет реальная «популярность» джавы.
Какая, какая - очень большая. Начиная с корпоративного сектора, которым пользуются миллиарды и десятки тысяч это кодят.
> Какая, какая - очень большая. Начиная с корпоративного сектора, которым пользуются миллиарды
> и десятки тысяч это кодят.Т.е в этом рейтинге в "популярность" джава не зачсчитывается разработка приложений и проч под огромное множество мобильных устройств( и даже не потому, что жаба "нереально крутая", а потому, что это просто один из ключевых применяемых ЯП в разработке приложений для той ОСи ), не так ли ?)
Начиная со сказок про интыпрайз.. ими, впрочем, и заканчивая.. но потом правда окажется, что на джаве говнокодить ощутимо проще, а сам тот говнокод - ощутимо забристей в сравнении со многими другими ЯП а саму жабу усиленно теснят все кому ни лень, в т.ч питон да го.. да даже главконтора потихоньку сваливает в разработке с джавы на Котлин а то и вовсе, на дарт.. но, разумеется, это не потому, что жаба - громоздкий и невыразительный мусор, а потом что она слишком хорошо для них :)
Ты тут для самоуспокоения пишешь?
Как видишь, желающих нет обсуждать подростковые эмоциональные тексты.
Сходи погугли, наберись немного знаний о предмете, о котором тут пытаешься вещать.
> Ты тут для самоуспокоения пишешь?Нет, просто забавляют тормозА, до сих пор всерьез считающие жабу сурьезным ынтепрайзом "и вообще, за ней будущее"(ц)
Автомобилями думаешь тоже никто не пользуется, потому что у тебя его нет?
Умозаключение из области - "Я в тот лес не ходил, но там точно деревьев нет".
Реальность такова, что ты в этом вопросе полностью некомпетентен.
Сходи чтоли на сайты поиска вакансий и глянь потребность в жава разработчиках.
Рынок требует их больше, нежели они есть в наличии.
Также жава плотно соприкасается с веб-разработкой и более чем каждый второй жава разраб знает стек вебтехнологии хттп, жс. цсс, и еще есть там же сишники и много других толковых эникейщиков.
Сразу видно иксперда опеннетовского
> Проблема пыха в том, что он одним своим неконсистентным дизайном не располагает к написанию качественного кода."Откуда дровишки?" (С)
Это утверждение примерно десятилетней давности, сейчас многое изменилось, и Вы, видимо, просто не в курсе. Я говнокодер на 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. И сейчас можно найти множество разнообразных брешей безопасностей в любом другом языке. Микроскоп не виноват, когда ним забивают гвозди.
Просто доля пхп большая, а у остальных значительно меньше. И при чем тут безопасность
Доля пхп значительно меньше жабы. Правильно было бы спросить - что в списке языков программирования делает PHP?
Причем здесь языки и техника програмирования (XSS), можно что С++, что пыхтоне, что на жаве слабать XSS ...
Ну "да" на С++ сплошь и рядом веб приложения бацают :)
Сравнивать ПЫХ и С++ это Apples vs Oranges
> Apples vs OrangesApples vs Seeds
ха-ха. походу исследование отражает умственные способности их использующих
C++? Слабые умственные способности?
Что-то путаешь
Это, конечно, такая средняя температура по больнице. Качество программ сильно зависит от того, кто же именно пишет эти программы, а не от языка, если экосистема достаточно развита.То есть, в любом случае, когда мы пишем программу, она проходит наш внутренний QC, потом QC конторы (если она есть). И финальный результат - количество ошибок, зависит от этого фильтра. На примере С++ - люди могли прогнать AFL, Valgrind, кучу программ для статического анализа и т.д.
А в чём же роль языка? А в том, что сразу после первого раунда кодирования, у нас получается более или менее глючная программа. Например, на Хаскеле она скорее всего вылетать не будет, а на Питоне - скорее всего найдутся какие-то неправильно вызываемые функции.
Но любой программист в конечном итоге протестирует программу до того уровня, к которому он привык, прежде чем "отправлять на золото". Поэтому итоговая программа на Питоне будет настолько же глючной, как и на Хаскеле. Просто если она достаточно сложна, то программист потратит кучу времени на тестирование и отладку Питонной версии. А если нет, то, наоборот, Хаскель затянет этап проектирования своими типами.
Это просто статистика, никто не делает прямых выводов. Но как правило, такая статистика показывает влияние совокупности факторов(какие программисты используют язык, для каких проектов используют язык). К примеру, если в большинстве прпоектов проблемой является баффер оверфлоу это скорее всего плюсы или чистый Си. Это не потому что большинство програмимистов на Си тупые, а потому что у языка есть свои специфичные особенности, которые не сильно обозреваются программистами самоучками. Так что, финальный результат зависит не только от "этого фильтра".
> Это просто статистика, никто не делает прямых выводовРоспотребпозор делает: https://pashev.me/posts/rospotrebnadzor
> Это просто статистика, никто не делает прямых выводов. Но как правило, такая
> статистика показывает влияние совокупности факторов(какие программисты используют язык, для каких проектов используют язык).Статистика-то может и показывает, но есть некоторые сомнения в абсолютно одинаковом качестве анализаторов для разных ЯП (какие-то просто развиваются дольше или командой более квалифицированных специалистов или просто имеют повышенный приоритет в финансировании).
А существенно различающееся качество анализа будет, скорее всего, вносить искажения вплоть до "> ± лапоть".
> Это просто статистика, никто не делает прямых выводов.Тогда на кой чёрт статистика нужна? :-)
> Это не потому что большинство програмимистов на Си тупые, а потому
> что у языка есть свои специфичные особенности, которые не сильно обозреваются
> программистами самоучками. Так что, финальный результат зависит не только от "этого
> фильтра".Переполнение буфера ловится Valgrin, разными программами для статического анализа, правильными примитивами (std::string, например). Проблема в том, что большая часть программистов этим не заморачивается, а языком Цэ пользуется.
все что тут описано в принципе не проблемы языков. Тут проблемы писателей. И как говориться ошибаются все, но одно есть точно, ошибки на плюсах сложнее засечь, особенно новичкам и особенно когда спрос на дешевую работу, что равно новички. а так еще чаще применение языков не в той сфере где нужно. ну плюсы отдельная тема. сам создатель думаю не знает всех фич и опасностей языка, так как комбинаций миллионы. раст думаю так же еще не показал всей "красы" из-за недостатка кода. и ошибок думаю будет не меньше, причем из-за писателей , а не языка.
Проблемы C++ от того, что его упорно смешивают с Си. Как правило указатели используется там, где без них можно обойтись и швыряют их через всю программу. Естественно, что надёжность в данном случае как у Си в котором почти всё отдаётся на откуп программисту.
> Проблемы C++ от того, что его упорно смешивают с Си. Как правило
> указатели используется там, где без них можно обойтись и швыряют их
> через всю программу. Естественно, что надёжность в данном случае как у
> Си в котором почти всё отдаётся на откуп программисту.он тем и хорош , что все под контроль программисту. Проблемы с программистами, нужен хороший уровень знаний и владения языком и тогда он покажет больше раста или го, но таких не так много. управлять вручную большим комбайном кода программы(большой проект) оч сложно и тесты не выявляют всего. это плюсы, тут с этим хуже всего. но когда получается , то программа будет отменной.
> он тем и хорош , что все под контроль программисту.В C отнюдь не всё на деле "под контроль программисту". Это всего лишь довольно лживый (и успешный) пропагандистский лозунг, призванный заставить пользоваться C. А на деле - множество разных ситуаций потери контроля. Так в частности ни в C, ни в C++ так ничего за много лет и не сделано против полной потери контроля в случае хотя бы простого арифметического переполнения... Нет даже простого способа обнаружить такое переполнение. В C++ вводятся совершенно дурацкие вещи, но данная проблема не решается.
> хотя бы простого арифметического переполнения...Ну так далеко не в каждой архитектуре есть способ обнаружить такое переполнение. Есть вполне стандартные конструкции для проверки переполнения, которые для компилятора не сложно превратить в проверку флага на x86. Да придётся делать проверку каждой операции, только хардкор.
> Ну так далеко не в каждой архитектуре есть способ обнаружить такое переполнение.
> Есть вполне стандартные конструкции для проверки переполнения,
> которые для компилятора не сложно превратить в проверку флага на x86.С каждой строкой
нагнетается сайенс
хоть и не хокку.
> он тем и хорош , что все под контроль программисту.Есть чудесная статья "What every compiler writer should know about programmers" про то, что делают современные компиляторы из "портативного ассемблера". Например, сейчас, de facto, запрещены программы с Undefined Behavior, заточенные специально под конкретное поведение конкретного железа.
В качестве дальнейшего чтения могу предложить "C Is Not a Low-level Language".
> Undefined Behavior, заточенные специально под конкретное
> поведение конкретного железа.А при чём здесь железо?
Потеря контроля она и есть потеря контроля. "Железо" не поможет в такой ситуации. Поведение имеет программа на C, а когда она его не имеет... >:-)
> А при чём здесь железо?Почитайте статью. Для примера - под 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 перефигачивает её так, что она оказывается сломанной.
NULL не указывает "на нулевую страницу". Вы не поняли - железо ни при чём. Если у вас обнаружилось, что NULL "указывает на нулевую страницу", то это не "особенности железа". (скорее, это баг компилятора, поскольку оказывается, что NULL указывает на вполне правильную память и объект, который может оказаться и нужным). Для справки: NULL не обязан быть представлен нулевыми битами и определённо не должен быть представлен нулевым физическим адресом, если по этому адресу допустимо и возможно будет необходимо обращаться.
> Там нет потери контроля. Программа заточена под определённое железо, на нём она
> абсолютно предсказуемо работает, но современный компилятор, пользуясь UB перефигачивает
> её так, что она оказывается сломанной.:-)))
Смешное заявление: программа работает, но... не работает. При чём заметьте на том же железе.То есть фактически вы пытаетесь основываться на особенностях компилятора (определённой версии и возможно ещё и определённого режима его работы). Вам кажется что программа должна работать определённо и без потери управления, но это вам только так кажется >:-) Как вы убедились. То, что программа у вас в результате "работает предсказуемо", поскольку вы может быть способны как-то предсказать, как она будет работать, вовсе не значит определённого поведения. Ваши способности к предсказанию и определение поведения программы - вещи весьма разные.
> Смешное заявление: программа работает, но... не работает. При чём заметьте на том же железеДа. Если взять компилятор из 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 отклеился".
О, адвокат Файрфокса подтянулся, тоже то ещё вредоносное поделие.> Да. Если взять компилятор из 80-х, будет работать. Если отключить оптимизации в
> современном компиляторе, будет работать. Если же современный компилятор и с оптимизациями,
> то работать не будет.Что-то мне кажется вопрос скорее в том, как оно будет работать. И дело даже не в оптимизациях.
>> То, что программа у вас в результате "работает предсказуемо", поскольку вы может быть способны как-то предсказать, как она будет работать, вовсе не значит определённого поведения. Ваши способности к предсказанию и определение поведения программы - вещи весьма разные.
> Он дело советует -- сходи и почитай статьи, которые он рекомендует. Вот
> сходи и почитай, и если останется желание позубоскалить, то зубоскаль. Но
> сначала почитай.Незачем нам ходить. Вам упорно кажется, что поведение программ, поведение которых не определено, является определённым. И вы даже упорно пытаетесь довести это до нас. Компиляторы 80х внезапно не делают ваши примеры чем-то иным, поведение всё равно не определено.
> В том-то и проблема, что предсказать поведение программы теперь невозможно, не учитывая
> всех тех UB описанных в стандарте, как UB.
> Взять, скажем, целочисленное переполнение. В C -- это UB. Которое исторически трактовалось
> как "сделать то, что процессор делает при сложении целых".Ага. Ordu начал рассказ, как следует трактовать C. Но сей пересказ того, как ему кажется следовало трактовать, значит в целом ничего.
> То есть, исходный C предполагал, что программист обладает этой "способностью к предсказанию"
> поведения кода с UB, на которую ты тут зубоскалишь.:-))) Это очень плохое предположение. Хотя его и можно допустить. Результат можно наблюдать. Возможно так и было задумано. >:-)
> Знание программистом
> архитектуры даёт ему чёткое понимание того, что произойдёт при разадресации NULL.
> Или что произойдёт при переполнении целого.Может быть и даёт кстати. Вот только Ordu уже похоже должен начать подозревать, что ему почему-то уже "не даёт". И надо будет приучаться жить с этим >:-)
> Потом пришли современные техники оптимизации кода, которые выполняют оптимизацию многими
> фазами, и хоть каждая фаза вполне разумна, но в процессе трансформаций
> кода может теряться смысл выполняемых программой телодвижений, и затем вдруг --
> хоп -- и UB становится русской рулеткой: что сделает отоптимизированная программа
> уже не угадать.Короче, от использования "старого компилятора" программа не превращается в имеющую так сказать лучше определённое поведение. Просто получается пример с программой, не имеющей такового. Здесь следует ещё раз сказать, что такой пример не представляет собой чего-то эмпирически отличного, выглядеть может не хуже, а кому-то и лучше, любого примера работы с вполне определённым поведением :-) Мы уже высказались по поводу этого свойства.
> То есть, современный C переопределил понятие UB
Это опять конечно же не так.
Просто кое-кому приходится открыть для себя, что же это такое наконец. И это ещё с высокой вероятностью не конец >:-)
> О, адвокат Файрфокса подтянулся, тоже то ещё вредоносное поделие.Я что-то сказал в защиту фф? Где? Когда? Слабо найти хотя бы одну ссылку на мою защиту фф за последние 10 лет?
> Что-то мне кажется вопрос скорее в том, как оно будет работать. И
> дело даже не в оптимизациях.Именно в оптимизациях.
>>> То, что программа у вас в результате "работает предсказуемо", поскольку вы может быть способны как-то предсказать, как она будет работать, вовсе не значит определённого поведения. Ваши способности к предсказанию и определение поведения программы - вещи весьма разные.
>> Он дело советует -- сходи и почитай статьи, которые он рекомендует. Вот
>> сходи и почитай, и если останется желание позубоскалить, то зубоскаль. Но
>> сначала почитай.
> Незачем нам ходить.Чувак, у тебя догма отклеилась. Если ты мыслишь догматично, хренли ты спорить лезешь? Никому неинтересны твои догмы. А если тебе не интересно, что тебе говорят, то хренли ты лезешь разговаривать со взрослыми дядями? Мама с папой недостаточно внимания уделяют? Или в школе буллят и никто с тобой не общается?
>> Что-то мне кажется вопрос скорее в том, как оно будет работать. И
>> дело даже не в оптимизациях.
> Именно в оптимизациях.Вы читали вышенаписанное? Там про NULL. И он не нулевой физический адрес, как многим показалось (хотя может "работать" (и судя по написанному работало) и так). И это не "оптимизация".
> Чувак, у тебя догма отклеилась. Если ты мыслишь догматично, хренли ты спорить лезешь? Никому неинтересны твои догмы.
:-)) Ordu ввязавшемуся в спор неинтересно. И неприятно?
Вот кстати "обоснование" выше приведённого примера с нулями (из тех, с которыми нам тут настоятельно советуют знакомиться) звучит довольно странно: "То есть, мы не должны проверять на nullptr лишний раз - это ускоряет программу." - намёк на некую оптимизацию, но... На самом деле непонятно где бы здесь была возможность для оптимизаций и ускорений, по крайней мере стоящих.
>>> Что-то мне кажется вопрос скорее в том, как оно будет работать. И
>>> дело даже не в оптимизациях.
>> Именно в оптимизациях.
> Вы читали вышенаписанное? Там про 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.
> На современном железе программы работают с виртуальными адресами. И дело не в
> языке Си. Трансляция в физические происходит аппаратно через таблицу страниц. Боюсь,
> Вы банально путаете эти два понятия.Есть один широко известный Адрес, который надо было бояться придётся следовать >:-)
Абырвалг?
>>> Что-то мне кажется вопрос скорее в том, как оно будет работать. И
>>> дело даже не в оптимизациях.
>> Именно в оптимизациях.
> Вы читали вышенаписанное? Там про NULL. И он не нулевой физический адрес,
> как многим показалось (хотя может "работать" (и судя по написанному работало)
> и так). И это не "оптимизация".Вообще-то, там обсуждается "под контроль программиста". NULL взят в качестве примера. Тебя этот пример сбивает с толку, я предложил поэтому иной -- целочисленное переполнение. Целочисленное переполнение, судя по всему, не сбивает, и тут выясняется, что принять этот пример ты всё равно не можешь, потому что ты веруешь в какую-то догму, и рефлексировать её не в состоянии.
>> Чувак, у тебя догма отклеилась. Если ты мыслишь догматично, хренли ты спорить лезешь? Никому неинтересны твои догмы.
> :-)) Ordu ввязавшемуся в спор неинтересно. И неприятно?Естественно, когда спор ведётся по правилам детского сада, то есть по принципу: каждый участник повторяет своё утверждение многократно, и проигрывает тот, кому первому надоело.
> Вообще-то, там обсуждается "под контроль программиста". NULL взят в качестве примера. Тебя
> этот пример сбивает с толку, я предложил поэтому иной -- целочисленное
> переполнение. Целочисленное переполнение, судя по всему, не сбивает, и тут выясняется,
> что принять этот пример ты всё равно не можешь, потому что
> ты веруешь в какую-то догму, и рефлексировать её не в состоянии.Во-первых вам к Нам следует обращаться отнюдь не "ты".
Никакого примера с переполнением вы не предложили. Лишь высказались про переполнение и как по-вашему должно работать сложение (во всяком случае похоже попытались - смотреть ниже). Про переполнение, не премину таки отметить, выше написал я.
Ну и поцитирую ещё вас: <<Взять, скажем, целочисленное переполнение. В C -- это UB. Которое исторически трактовалось как "сделать то, что процессор делает при сложении целых".>>. Весёлая цитата, свидетельствующая о незагруженном лишними догмами мышлении - попробуйте вдуматься, что вы здесь написали.
Ну считайте таким образом свой бред про догмы и рефлексирование оных отмеченным и даже удостоенным какого-никакого но не совсем несерьёзного ответа, несмотря на юмор :-)
> Ну считайте таким образом свой бред про догмы и рефлексирование оных отмеченным
> и даже удостоенным какого-никакого но не совсем несерьёзного ответа, несмотря на
> юмор :-)Ох блин, спасибо, вот уважил старика. Как я надеялся, что ты прочитаешь, и ты прочитал /s
Дурень, твоё мышление -- это твоё мышление, это твой рабочий инструмент, твоё средство для выживания в этом мире. Задачивать его в твоих интересах, а не в моих.
> Проблемы C++ от того, что его упорно смешивают с Си.Проблемы у C и C++ в том, что даже вроде бы успешно работающая в тестах программа зачастую может оказаться всё же неправильной. И бывает довольно сложно сказать что либо по поводу правильности выдаваемого конечного результата (не известного заранее) >:-)
По моему опыту всё, на чём я (и не только) писал могло оказаться неправильным. И (в принципе) таковым остаётся пожизненно, т.к. математическое моделирование (выливающееся в покрытие тестами) также допускает ошибки.ASM: Неверное применение инструкций (даже так бывает). Т.к. в современных системах мало справочник перелистать.
ASM,*sh,php: Смешивание кода и данных. Причины разные, а проблемы одни.С (в моём случае это обычно libc, хотя даже дёргай я напрямую за syscall, как в go поступают — то же самое будет): Опять таки, неверные сценарии работы (с posix). Не обеспечил "wait()" после завершения форка — здравствуй, зомби.
С++ (не моё): Многие начинающие пытаются писать "олимпиадный" код. Потому что "круто".
Go: Всё про параллелизм провоцирует трудно отлаживаемые ошибки. 90% мог бы вычистить стат. анализатор, но его нет. Вплоть до анекдотов, когда мьютекс объявлен внутри функции которую должен контролировать (не всю, но не важно). И "замыленный" глаз это не видит. Также прослеживается тенденция "переписать на безопасном go" (dns, ssl). С неизбежным внесением ошибок в логику.
Perl: Легко написать медленный код, не разобравшись в слабостях языка. Хуже того, некоторые вещи (треды) могут работать не так как ожидается из документации. А отлаживать параллельное выполнение на языке который изначально был не про это — ну так себе.
Python (с 3.х — только "одноразовый" код): Попытка сумничать (ну, язык-то позволяет) порождает откровенный идиотизм.
Все "высокоуровневые" языки (у меня "под боком" — java и erlang): Провоцируют пишущего чувствовать себя "в домике". Код "складывается" под нагрузкой самыми причудливыми образами.
…Короче, побрюзжал. Можно идти дальше писать на том что "под рукой". И хорошо, когда это не авионика для "Боингов".
ну так гёдель же еще 100 лет тому назад ...
так шо не парься все ошибаются и я тоже (черт. рекурсия)
> По моему опыту всё, на чём я (и не только) писал могло
> оказаться неправильным.Могло, может быть. Но только годное и работоспособное не могло. То, на чём вы писали. Кроме может быть C. :-)
То, что вы писали - это уже очень другое.
> Кроме может быть C. :-)...а также, извините, Питона, Явы, Perl, Go... >:-)
(тот ещё набор)...
Не совсем.У всех языков есть проблемы.
У похапе проблемы — это фича.
Фича питона — класть поменьше проблем в дизайн.
> Не совсем.
> У всех языков есть проблемы.
> У похапе проблемы — это фича.
> Фича питона — класть поменьше проблем в дизайн.питон вообще довольно приятный язык, особенно в малых дозах. Не так как на нем пишут целые комбайны. я знаю есть цитон и джит, но он не для этого, даже если прост и довольно удобен. ну php прославился давно, чаще правда из-за криводелов.
> Фича питона — класть поменьше проблем в дизайн.В который - второй или третий?
проверяется при помощи функции file_exists(), которая автоматически выполняет десериализацию метаданных из файлов Phar (PHP Archive) при обработке путей, начинающихся с "phar://", что позволяет применить технику атаки "Phar deserialization". Организовав загрузку специально оформленного Phar-файла под видом вложения, злоумышленник может добиться выполнения своего кода на сервере. Так как функция file_exists() определяет MIME-тип по содержимому, а не по расширению, возможна передача phar-файла под видом картинки (например, phar-файл будет разобран, если его передать как evil.jpg)
таблица - теплое с мягким, все как мы любим
Чота Лиспа не увидел))
Фрактааааал! Твой выход!
Поржал, особенно с JS. 7% code quality. А почему так? Потому что любая дичь в коде происходит в песочнице и почти не влияет на безопасность?
И какой смысл тогда этого анализа для оценки ЯЗЫКА!?Хорошо там сверху написано: "сферические анализы кала в вакууме"
Да, очень странно, что JS весь в белом и на коне. Хотя в реальной жизни проблем с ним примерно столько же, сколько и с пыхом.
Так на жсе, в среднем по больнице, не пишут то, что пишут на сях.
Справедливости ради JavaScript давно уже стал достаточно универсальным языком, на котором вполне можно писать, как программы для ПК, так и приложения для смартфонов, не говоря уж об его использования на бэкенде. Мне кажется, что в ближайшие годы JavaScript вполне себе потеснит PHP, но прав ли я покажет время)
Мне кажется что JS лет столько же, сколько PHP, а толку в плане "становления универсальным" нету.
Во-первых, оно настолько невменяемо спроектировано, что производительность любого варианта JS ниже плинтуса.
Во-вторых, встроенная рантайм библиотека настолько скудная, что горами появляются всякие лефтпады.
В-третьих, язык вообще непригоден для написания универсальных приложений, его испохабили промисами и прочим "счастьем", годным только для куцых окружений браузеров.
> невменяемо спроектированоСпроектировано вменяемо. Если не согласен -- приводи конкретные примеры.
> производительность любого варианта JS ниже плинтуса
Производительность V8 уделывает остальные скриптовые языки, поскольку использует JIT-компиляцию.
> встроенная рантайм библиотека настолько скудная
Встроенная рантайм-библиотека покрывает большинство задач. Например, конкретно лефтпад уже давно есть в виде String.prototype.padStart.
> язык вообще непригоден для написания универсальных приложений
Язык вообще пригоден для написания универсальных приложений. Если не согласен -- приводи конкретные аргументы. Промисы так и вообще изначально появились не в яваскрипте, да и пригодились далеко за пределами браузера.
> Спроектировано вменяемо. Если не согласен -- приводи конкретные примеры.
Что это? Список «прикольных)))» вопросов для собеседования? В реальном коде ни с чем таким сталкиваться не приходится. А значительная часть так и вообще имеет аналогии и в других языках. (https://0.30000000000000004.com/ для примера)
> Что это? Список «прикольных)))» вопросов для собеседования? В реальном коде
> ни с чем таким сталкиваться не приходится. А значительная часть так
> и вообще имеет аналогии и в других языках. (https://0.30000000000000004.com/ для примера)Вот именно, оно - натуральное ковно, в реальном коде этого ковна никогда не будет (но Васян скзал, что это не точно), а в языке это есть.
JS абсолютно не приспособлен для решения задач, там нет ничего хорошего по сранению с шарпом или джавой.
> Васян скзал, что это не точноБерешь гитхаб и ищешь реальные примеры по реальному коду, где бы кому-либо пункты из того «списка)))» доставляли неудобства. Пока примеров нет, тот «список)))» не более, чем прикольное))) чтиво под пивасик))) Но может быть ты пишешь бblдл0код такого уровня, что реально сравниваешь пустой массив с пустым массивом через ==. Тогда ошибка не в языке, а в ДНК твоих родителей.
> JS абсолютно не приспособлен для решения задач
JS абсолютно приспособлен для решения задач. Если есть конкретные претензии -- приводи.
> нет ничего хорошего по сранению с шарпом или джавой
Почему божественный JavaScript должен исключать божественную Java? Каждой задаче свой язык.
> https://github.com/denysdovhan/wtfjsИ чем оно отличается от какого-нибудь Undefined behaviour с/c++?
Отличается тем что в ecmascript это определенное и стандартизованное поведение
И ведь это лучше, чем рулетка UB в плюсах?
Используйте typescript
там большинство вопросов уровня 0.3 + 0.2 и "2" + 2
Подскажите, каким языком вы обычно заменяете JavaScript в случаях и местах, когда непрофессиональные или начинающие разработчики останавливают свой выбор на JavaScript? Часто приходится писать универсальные приложения и хотелось бы понимать куда стоит развиваться, ибо, как я понял по комментариям и аргументам, надо бежать от JavaScript.
Нужно стремится к JavaScript! Суровая правда жизни в том, что в веб-разработке на коне будут те, кто углубленно осваивал JavaScript в свое время. Оглянитесь и поймите, что IT-сфера семимильными шагами движется в направлении все большего развития веб-сервисов и веб-приложений.
Уже года три как потеснил, с разморозкой.И вместе с теснением притащил в свои ряды толпы говнокодеров.
Но хотя бы он не такой костыльный, в отличие от пыхи.
влажные мечты ньюфага)
не надо писать на js большие программы, используйти строго статически типизированный typescript
>> Да, очень странно, что JS весь в белом и на коне. Хотя в реальной жизни проблем с ним примерно столько же, сколько и с пыхом.Тут смотря что с чем сравнивать.
Похоже для php анализатор гоняли на WordPress с плагинами, для плюсов на прошивке ардуины, а для js взяли nodejs.
Вот и результаты.
Да уж, какой-то малосвязанный и сложно восрпинимаемый список. Однако, многие моменты он отражает верно.
Посмешило "Code Quality" в .Net. Время идёт, а Это не меняется )
А раста нет, потому что на нём студенты пишут хеллоуворлды.
Нет, потому что он является безопасным языком.
Не является.
Зашел почитать комментарии про Rust.
А чего читать - нет проблем. Почитай лучше про остальные языки как там все плохо у них.
Ну что phpшники? Стало лучше ваше поделие? В каждой версии говорите что вот теперь заживем. 5ая версия мол была не очень а 7 и 8 огонь. Хотя в свое время и 5ую нахваливали. Фрактал плохого дизайна уже не исправить, надо бы закапать но на чем тогда кодить неумехам без желания учиться? А таких всегда много, и пока их много этот ужасный язык со смертельными детскими болячками будет существовать. Может такие аналитические статьи заставят хоть чуть чуть задуматься пхп погромистов с синдромом утенка, и они захотят наконец посмотреть на другие языки а не ждать волшебных изменений в новых версиях.
> и они захотят наконец посмотреть на другие языкиИ на что смотреть? Какой язык может заменить пхп? Была куча взрослых закапывателей (но - "закопать"), но как-то отсохли и отпали.
Если небольшой проект - нода и реакт, javascript же все равно учить надо? Если крупный проект - react/angular + java/kotlin spring. Четкое разделение бекенда и фронта, а не мешанина phpшного кода. Плюс нормальные инструменты для отладки java. Плюс нормальная производительность. Нечеловеческий цикл жизни php приложения не позволяет писать сложную бизнес логику. Лично постоянно сталкиваюсь с пхп проектами на работе - и на каждом совещании только и разговоров как что-то на php развалилось и испортило жизнь клиенту. Бизнесу пофиг, им главное не качество. Php отделы растут быстро, создавая глючные проекты и для их поддержки набирают еще пыхеров. А совместными усилиями они создают еще больше глючных проектов. Им плевать на архитектуру и качество кода. Пхпшник решивший поднять свой скилл и улучшить качество кода неизбежно будет смотреть на другие языки. И это приведет к переходу на другой язык, ну или он не осилит и будет говорить что пыха тоже крута и у каждого инструмента свое предназначение(с). По факту пыха везде смотрится и работает плохо, ну и статья это подтверждает. А закапыватели не отсохли, просто им пофиг на это поделие. Как было пофиг и мне пока я не стал по работе с ним сталкиваться.(я реально думал что php давно и успешно умер, но нет... пока есть программисты без желания учиться - будет и популярность php)
какая каша в голове у этих смузихлебных манагеров, которые нихера не знают про пхп)
давай-давай, придумывай еще сказочки про ужасный пхп, о которм ты ничего не знаешь, но бесишься из-за его популярности)
Да ладно тебе - тут все гораздо хуже. Он же предлагает ноту и жабоскрипт на бекэнд.
Сразу ясно, что это какой-то школьник, который ни разу в жизни ничего в продакшен не писал.А пхп да, ужасен. Хотя альтернатив ему нет.
Как эксперт по пхп подтверждаю - альтернатив просто нет. Есть решения в чем-то лучшие, есть решения лучшие во всём. А есть пхп. Все понимают что это плохая штука, но никто не может сделать альтернативу. Да и зачем делать альтернативу плохому инструменту - если можно не делать, и использовать хорошие инструменты?Все альтернативы умерли - thymeleaf, mustache, freeMarker. Где они все? Многие пытались, но ни у кого не получилось.
>Перечислил шаблонизаторы.Ниче что шаблонизатор это всего лишь либа?
Я могу любой из них заюзать что в спринге что под сервлет в томкате.
Но зачем?
Рендер страниц давно перенесен на фронт. И беку достаточно отдавать модели по ресту, а уж рисовать страницу это дело фронта
>Ниче что шаблонизатор это всего лишь либа?Шаблонизатор это не просто либа. Это целый язык программирования! Откройте hh, введите php - и увидите насколько востребовано программирование на шаблонизаторах. Может ваш thymleaf предоставить те же возможности, что и php? Вряд ли, ведь среди шаблонизаторов только на php написано столько фреймворков.
>Рендер страниц давно перенесен на фронт. И беку достаточно отдавать модели по ресту, а уж рисовать страницу это дело фронтаНу вот вы и подтвердили мои слова. Альтернатив php нет. Вы предлагаете хорошее решение, но это не альтернатива php. Альтернатива php - это если завтра под freemarker появится свой laravel.
Зачем шаблонизатору выполнять что то кроме рендера страницы перед тем как ее отдать браузеру?
Данные шаблонизатору отдает низлежащий стек. В случае jvm там множество вариантов. Все языки и стеки по факту
>Зачем шаблонизатору выполнять что то кроме рендера страницы перед тем как ее отдать браузеру?Данные шаблонизатору отдает низлежащий стек. В случае jvm там множество вариантов. Все языки и стеки по факту
Напомню, что речь шла именно об альтернативе php. Зачем - уже другой вопрос.
То, что у вас есть варианты лучше - ок, но у вас нет альтернатив php.
Кто-то скажет, что вычисления на шаблонизаторе не нужны, что это плохая практика. Но мы уже определили, что php плохой инструмент. Альтернатив ему нет, но есть нормальные решения, позволяющие вообще не использовать php и "альтернативы" ему.
>Альтернатива php - это если завтра под freemarker появится свой laravel.Ну что тут сказать...
Jsp/jsf в ЕЕ лет 20, SpringMVC в спринге не меньше.
Они входят в стеки.
Но используются практически нигде. Стейтфул сервер сайд фронт на шаблонах сейчас применяется только в легаси.
Современный веб это стейтлесс клиент сайд рендер.
Все нормальные инструменты jvm умеют все. И легаси и даже асинхронный реактивный бекенд, который я сомневаюсь что есть в пхп
>Jsp/jsf в ЕЕ лет 20, SpringMVC в спринге не меньше.Это фреймворки java, а не freemarker. Всё равно что сравнивать фреймворки на C(на которой написана "среда исполнения" php) и фреймворки на самом PHP.
Ну тебе же нужен был аналог ларавеля. Чтопизкаропки.
Они и есть аналог.
При этом любой другой шаблонизатор можно подключить как либу.Ну и что там у вас в пхпмирке с асинхронным реактивным бекендом?
Или вы там вообще не слышали что такое реактивный веб и до сих пор рендерите страницы на сервере?
> Ну тебе же нужен был аналог ларавеля. Чтопизкаропки.
> Они и есть аналог.Мне точно не нужен. И это не аналог, я уже объяснил.
> Ну и что там у вас в пхпмирке с асинхронным реактивным бекендом?
Если надо использовать асинхронный бэкенд, то любой php'шник знает что нужно использовать ноду.
> Или вы там вообще не слышали что такое реактивный веб и до
> сих пор рендерите страницы на сервере?В основном да, так и есть.
> Если небольшой проект - нода и реакт, javascript же все равно учить
> надо? Если крупный проект - react/angular + java/kotlin spring. Четкое разделениеJavascript учить НЕ НАДО, но к сожалению придется, пока не переедем на WebAssembly и какой-нибудь Blazor и аналоги.
> пока не переедем на WebAssemblyМусье не в курсе, что WebAssembly не создавался, как замена яваскрипту?
>> пока не переедем на WebAssembly
> Мусье не в курсе, что WebAssembly не создавался, как замена яваскрипту?зато будет использоваться как замена - 100%
доступ к DOM у него уже есть
Telerik и прочие уже клепают контролы
все к этому и движется
У WebAssembly нет доступа к дому, мань. Он лишь в состоянии вызывать функции, которые предоставил ему загрузчик на JavaScript. И, если речь идет не о числодробилках, очень сомнительно, что в обычных формошлепских сценариях WebAssembly будет быстрее, чем JavaScript, поскольку данные, при пересечении границы между WebAssembly и JavaScript, должны (де)кодироваться.Хочешь отправить в wasm строку и получить результат в виде строки? Задекодируй родную яваскриптовую строку из WTF-16 в UTF-8, вызови функцию в wasm, а теперь получи результат, перекодировав его из UTF-8 обратно в WTF-16. В итоге wasm-приложуха будет работать медленнее. Та же проблема у нативных модулей NodeJS, поэтому, например, парсинг XML работает существенно быстрее, если его написали на чистом JS, а не воспользовались сишным libxml2 через врапперы.
>[оверквотинг удален]
> функции, которые предоставил ему загрузчик на 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 - это серьезный шаг.
> Вот надо и потестировать что быстрееВот и протестируй, а затем уже предлагай. Чем больше WebAssembly зависит от браузерного API, тем меньше в нем смысла.
Если wasm выбирается по критерию "он вроде как быстрее", то он этот критерий не пройдет из-за интеропа (js-функцию вызывать гораздо дешевле, чем wasm-функцию, и js-функцию вызывать гораааААААаааздо дешевле, чем ту же самую js-функцию, но через wasm -- а именно это и происходит в твоем PostAsJsonAsync).
Преимуществ перед TypeScript не вижу. Мало того, что он тоже предоставляет async/await, мало того, что он дает TSX-синтаксис для реакта и т.п., так он еще и не будет кодировать/декодировать данные для boundary crossing. Таким образом, TypeScript будет __на_порядки__ быстрее твоего кода.
WebAssembly предназначен для довольно редких задач, и формошлепство с todo-itemами в их число не входит.
1) не для скорости, а для платформы
2) не будет он на порядки быстрее, тупит DOM, а не АПИ к нему и уже тем более, не вычисления, в 99% на UI нет таких вычислений. А если мы говорим о каких-то нестандартных потребностях типа хеширования на клиенте или еще что-то подобное, то такиая числодробилка будет на wasm работать быстрее.Но еще раз повторюсь про быстрее - это тебя волновало! Меня волновал код!
И TS это нечерта не альтернатива ни C# ни Java, TS - это очередной фракенштейн, накачанный стероидами.В общем надо не только слюной брызгать, но и стараться слушать. Тебе про одно говорят, а ты про другое.
P.S. парсинг XML можно сделать с помощью DOM, т.е. самим браузером, что там под капотом JS было хз. Но мне честно говоря пох. И выше написал почему.
> такиая числодробилка будет на wasm работать быстрееПравильно. И это -- один из редчайших случаев, когда wasm реально применяется там, для чего он и создавался. Причем даже в этой задаче твои сишарпы нафиг не нужны, можно заюзать публично доступные алгоритмы на Си. Может даже получится обойтись без malloc/free и получить wasm-бинарник размером меньше 1024 байт.
> TS это нечерта не альтернатива ни C# ни Java
Ты это повторяешь из раза в раз, но так и не сумел представить хоть какой-то аргумент, почему TypeScript плохой. Если речь про бэкенд, то да, в бэке лучше заюзать православную Java + Spring. Но на фронте зачем мне Java, когда уже есть TypeScript?
> парсинг XML можно сделать с помощью DOM
DOM -- не единственный API к XML (а в ноде он так и вовсе отсутствует). Встроенный браузерный API не дает S(t)AX парсера к XML.
тем, что TypeScript это все еще JSесли надо объяснять чем JS плох, то дафай досфидания )))
Да не, слиться любой может. А ты вот попробуй не сливаться и реально попытайся объяснить, чем плох JS.
> Хочешь отправить в wasm строку и получить результат в виде строки? Задекодируй родную яваскриптовую строку из WTF-16 в UTF-8, вызови функцию в wasm, а теперь получи результат, перекодировав его из UTF-8 обратно в WTF-16.Хочу спросить, для повышения образованности. А почему бы не закинуть в wasm строку в WTF-16? wasm жеж ассемблер, какая ему разница, с какими строками работать?
Ts, dart.
Ангуляр и вполне умеет
> Ts, dart.
> Ангуляр и вполне умеетTS - кастрат, потому что под капотом это тот же JS, там из нормального только типизация.
Dart - это дно, может мышки и будут жрать кактус, но это с рождения кактус.
P.S. у меня больше веры в ржавого, чем в дарт.
Заменить в чём?Если в роли инструмента для клепания сайтов, то любой скриптовый язык с нормальным фреймворком фору даст пыхе на сто лет вперёд.
Если в роли затычки для мамкиных говнокодеров, то лучше пусть на своей пыхе и продолжают говнокодить, их так очень легко фильтровать от программистов.
А можно примеры нормальных фреймворков? Таких, что бы были не хуже и не медленнее пхп.
И еще, желательно, чтобы писать было не медленнее и не сложнее.
> А можно примеры нормальных фреймворков? Таких, что бы были не хуже и
> не медленнее пхп.
> И еще, желательно, чтобы писать было не медленнее и не сложнее.Тебе фляжки с джангой для чего-то не хватает?
Медленность упирается в говнокод, сложные вычисления без использования предназначенных для этого библиотек и говнокод.В синтетике питон в сто раз медленнее, на практике он в пять раз быстрее.
Потому что синтетику решает специальная библиотека на сишечке, а кривых запросов в базу меньше.
самый медленный язык в мире(php) в последней версии ускорили на 10%, теперь php бояре выбирают платформу "не медленее php". Это не сложно - все еще любая другая платформа быстрее пыхи. И лучше конечно-же. Другие платформы же не создавались для умственно отсталых.
Любой асинхронный фреймворк на питоне, го или яве работает в десятки или сотни раз быстрее пхп.
Даже синхронный джанго быстрее
Вот ты утёнок! У нас что, ASP.NET отменили?? Причём ламерам можно начать с BASIC, профи сразу прыгнут в C#.
ASP.NET это винда и проприетарщина. Не забываем на каком мы ресурсе, а вот про ASP.NET забываем.. забываем...
На одной работе вот была необходимость запилить костыль на PHP, кодеры, которые всю жизнь дальше делфи ничего не видели, даже проверку параметра через isset и т.п. не сделали, при чем тут язык.
> В проектах на С++ чаще всего встречаются проблемы, связанные с некорректной ... работой с буферами (46.8%)Дырявые плюсовики в принципе не умеют работать с буферами, потому что дырявые
пишу на плюсах, ни про какие буфера ни разу не слышал. массивы знаю, память знаю, вектор знаю, буфера - не знаю. сиськи что ли
Потому что дырявый...
Как на JS написать уязвимость вида "Directory traversal"? Какие директории у клиента в браузере?
Твои представления о том, что JS может выполняться исключительно в браузере, устарели еще в 90-ых. Даже в Проводнике Windows 98 боковая панель с голубоватым уголком была написана на диалекте яваскрипта (JScript).
Видимо опять сравнили количество ошибок в helloword'ах в песочнице с операционными системами и опять открывают амкрику: если ничего не делать, то ничего и не сломается.
А кто-нибудь понял от чего эти проценты взяты? Что символизируют эти циферки и с какого потолка они взяты?Где можно посмотреть кол-во ошибок на каждые 1000 строк кода по каждому языку?
> наиболее проблемным оказался код на PHPКто хотя бы раз видел код на PHP, поймёт (там люди тупо выживают - не до безопасности).
Какие заказчики, такие и исполнители, такой и код. Поспешишь - людей насмешишь, скупой платит дважды, Васька слушает - да ест.
У семи нянек дитя без глаза. Кто рано встаёт, тобу бог подаёт.Итак, симпозиум народного фольклора считается открытым! :))
Кто хочет соскакивает.
>наиболее проблемным оказался код на PHPЭто и так все давно знали.
Лучшие сишные дырени в PHP :)
Какая-то реклама притона для взрослых?
Эта rовностатистика трещит по всем швам:1. НЕ ТОЛЬКО язык влияет на секурность, но корреляция конечно же есть. Примерно процентов на 30.
2. Безопасность - это больше про людей - те самые 70%. Очевидно, что если анализировать FOSS-проекты, то и аудитория там соответствующая - энтузазисты разного пошиба.
3. Без статистики по реально профессиональному коду, говорить о языках вообще незачем. Вот если среди профи посмотреть "секурность кода" - тогда да, можно поговорить о языке и насколько хорошо он помогает прогеру избегать проблем.> наиболее проблемным оказался код на PHP
Кто б удивлялся! За такое г**** берутся лишь ламо, да и язык написан таким же долбоклюем. Так что похапэха - безусловное днищще ИТ.
> Эта rовностатистика трещит по всем швам:Ты на себя-то глянь, да?
> 1. НЕ ТОЛЬКО язык влияет на секурность, но корреляция конечно же есть. Примерно процентов на 30.
> 2. Безопасность - это больше про людей - те самые 70%. Очевидно, что если анализировать FOSS-проекты, то и аудитория там соответствующая - энтузазисты разного пошиба.Откуда ты взял корреляцию в 30%? Из головы выдумал? Покажи, что ты мерял и как ты считал, или балабол. Они хотя б какую-то методику измерений разработали, и хрен с ними с числами, но сами по себе списки распространённых проблем свойственных тому или иному языку весьма любопытны.
> 3. Без статистики по реально профессиональному коду, говорить о языках вообще незачем. Вот если среди профи посмотреть "секурность кода" - тогда да, можно поговорить о языке и насколько хорошо он помогает прогеру избегать проблем.
Что такое "реально профессиональный код", где его можно найти, и как его можно создавать? Предполагая, что ты можешь ответить на этот вопрос, я делаю вывод, что "реально профессиональный код" не существует, никто его не разрабатывает, потому что в любой команде есть пара стажёров/джуниоров, потому что сеньоры слакают, пропуская баги в релизы... Да и вообще, не существует двух одинаковых кодобаз, не существует двух одинаковых команд -- как можно игнорировать эти неустранимые различия, сравнивая языки?
К их исследованию, у меня лично, другие претензии -- там вместо статьи, описывающей методику измерений, какой-то набитый жабаскриптом сайт. Очень красиво и впечатляюще, брызги смузи летят во все стороны, но он без 3rd-party скриптов сайт полунерабочий, а то что работает -- сплошной маркетинговый буллшит, а не описание методики измерений. Статистика же (любая статистика!) -- бессмыслица, в отрыве от методики её получения. Судя по 130k исследованных проектов, данные были получены автоматически. Статическим анализатором? Пример проблемы в студию? Мне скажем очень интересно, что это за CRLF проблемы в java, было бы интересно примерчик. Или что значит "проблемы с менеджментом буферов" в C++? Переполнение буфера идёт отдельной статьёй, а что там ещё может пойти не так? underflow? Ошибки в адресной арифметике? Забыли выделить новый блок памяти под буфер или освободить старый? Но, если что-то из этого, почему это собрано в отдельную категорию с буферами, если адресная арифметика -- это адресная арифметика, а выделение/освобождение памяти -- это управление памятью? То есть это что-то иное? Что именно? Вопросов возникает тьма, а найти ответы на них не представляется возможным.
Всё это исследование -- маркетинговый буллшит. Отделу продаж не выйти за плановые показатели. Вот они и нарисовали красивую цветастую табличку, и стали делать громкие заявления. И опеннет с гиканьем и воем рванулся помогать маркетологам создавать много шума из ничего. Хорошо хоть опеннет в своём корыте инкапсулирован, и шум здесь никак не помогает маркетологам.
Я даже могу подсказать тебе эвристику, как отличать совсем уж буллшит от всего остального: если исследование не буллшит, то к нему должна прилагаться в самом очевидном месте ссылка на pdf, в котором есть ответы на все вопросы к исследованию, которые ты можешь измыслить. Читать pdf не обязательно, достаточно открыть и посмотреть, есть ли там ответы на твои вопросы. Вникать в ответы тоже кстати не обязательно, достаточно посмотреть на их наличие. Это очень грубая эвристика, но она применяется элементарно меньше чем за минуту, и она позволяет отсеять очень много информационного шума.
Если у тебя верхнее образование есть, и, соответственно, ты представляешь себе структуру научной статьи о проведённом исследовании, то обрати внимание на соблюдение этой структуры, чтобы там было введение (вводящее в контекст, в котором исследование проводится), глава посвящённая related works может отсутствовать (это подозрительно, но не критично), должно быть чётко расписано как данные были получены, и как они были обработаны. Плюс должен быть раздел типа discussion, в котором немного балабольства на тему, какие выводы из этого исследования можно сделать, или как это исследование можно улучшить, дополнить другим исследованием, и тп. Если ничего этого нет, то либо исследование целенаправленно пытается ввести тебя в заблуждение, либо оно было проведено дилетантом, который не имеет ни образования в теме проведения исследований, ни опыта проведений этих самых исследований.
Правильный заголовок: PHP признан самым небезопасным языком.
Ниочем. Анализ на уровне отписки студента первого курса по предмету мат. статистики. На троечку.Распилили бабло и сделали отписку.
Раст самый безопастный. Нет кода - нет ошибок.
Code less error too ...