Комментарии 50
И какой практический смысл этого исследования? Особенно про PHP, все эти случайные ошибки отлично подсветит IDE, тот же PhpStorm, еще до компилятора. Кроме того не ясно какой error_reporting был выставлен, включен ли тот же strict…
Британские ученые просто отдыхали в Греции :)
Я недавно смотрел по Дискавери, как какой-то британский ученый измерял преступность на Рождественской ярмарке где-то в Германии. Итого: за 45 минут передачи его обсчитали при покупке хотдога и какие то подростки продали ему активированный уголь или что-то в этом духе в качестве героина…
А вы говорите — у нас бюджеты пилят=)
А вы говорите — у нас бюджеты пилят=)
+1, у Perl всегда используют 'use strict', был ли тут выставлен — не понятно.
Похоже, что греческие учёные разрабатывают коварный план вывода страны из кризиса.
Сразу вспоминается злобный гипотетический вирус, который шерстить файлы на предмет исходников, где случайным образом в 5% случаев правит ++ на --, >= на <=, * на ** и наоборот :)
От опечаток избавят тесты, а вот что избавит от опечаток в тестах? :)
Когда начал изучать D, приятная мелочь бросилась в глаза — это вывод компилятора, с предложением исправить идентификатор. К примеру:
name@home:~$ rdmd test.d
test.d(7): Error: undefined identifier tesVar, did you mean variable testVar?
import std.stdio;
void main(string[] args)
{
int testVar;
testVar = 5000;
writeln(tesVar);
}
name@home:~$ rdmd test.d
test.d(7): Error: undefined identifier tesVar, did you mean variable testVar?
С заменой символов в именах, очевидно, справятся языки, в которых требуется явно объявлять переменные.
Но как компилятор вообще может отследить ошибку типа «увеличение или уменьшение числовых литералов на единицу»?
Но как компилятор вообще может отследить ошибку типа «увеличение или уменьшение числовых литералов на единицу»?
Ну все ожидаемо, типизированные языки впереди. Но Python конечно же радует.
Рискну показаться брюзжащим старцем, как на моей аватарке, но в случае C# новомодные var и лямбды без типизации параметров (tmp) => {… }, а заодно и неявная инициализация членов класса, смело могут передвинуть этот язык на одну ступеньку с Ruby, Python и Haskell.
НЛО прилетело и опубликовало эту надпись здесь
Возможно в виду имеется возможность не указывать значение для члена класса при его объявлении. Хотя ни малейшего понятия не имею почему Nomad1 относит это к понижению типизации.
Или, самый безумный вариант — в виду имеется объявление членов класса через Var — так это вообще запрещено, такой класс не скомпилируется.
Или, самый безумный вариант — в виду имеется объявление членов класса через Var — так это вообще запрещено, такой класс не скомпилируется.
Правильно он все пишет. Вывод типов конечно более безопасен, чем динамическая типизация, но вполне вероятна ситуация, когда из-за опечатки типы будут выводиться не те, которые подразумевались. Остается надеяться, что типы поломаются в другом месте и будет ошибка компиляции, но и такое не всегда бывает.
6,5% выдали корректный результат, а 16% — некорректный.
А остальные 77.5%?
Херня какая-то это исследование. Чтобы Хаскел был дальше всех статических… Нонсенс.
Все знают, что рефакторить легче всего код на Хаскел. А рефакторинг — это всегда большая возможность сделать механическую ошибку.
Все знают, что рефакторить легче всего код на Хаскел. А рефакторинг — это всегда большая возможность сделать механическую ошибку.
Да просто доказали что-то, а конкретно что — название исследования не отражает.
Я работал немного на плюсах (в проектах паре участвовал), а потом долго на шарпе. Просто безумство утверждать, что шарп более подвержен ошибкам. А по слухам, Хаскель тем более, гораздо строже.
Могу предположить, что у языков есть некоторая мощность выражения мысли и некоторая избыточность. И корреляция между ними отрицательная. Если больше в языке приходится писать избыточной информации, то больше и возможностей у компилятора обратить на это внимание.
Но опечатки — это самые тупые ошибки, которые встречаются не часто. И действительно, отлавливаются во многих случаях компилятором. А вот работа с указателями и с памятью вживую часто с т.з. компилятора корректна или он не может доказать корректность.
Короче, по опыту, плюсовики намного больше ошибок допускают (это я не по себе сужу, я не имею большого опыта, но работал с плюсовиками). И производительность у них намного меньше. Подчеркну — намного.
А есть языки, в которых можно очень кратко и элегантно выражать свою мысль. И изменение пары символов — это не ошибка, а изменение смысла кода. И, думается, в этом случае ошибок будет меньше. Потому как не нужно измерять количество ошибок на размер файла. Лучше измерять — на задачу. И если язык декларативный, позволяет кратко описывать проблемы, не позволяет ошибаться с памятью и т.д. — то очевидно, на нем и производительность программиста выше, и багов меньше. Особенно смысловых.
Я работал немного на плюсах (в проектах паре участвовал), а потом долго на шарпе. Просто безумство утверждать, что шарп более подвержен ошибкам. А по слухам, Хаскель тем более, гораздо строже.
Могу предположить, что у языков есть некоторая мощность выражения мысли и некоторая избыточность. И корреляция между ними отрицательная. Если больше в языке приходится писать избыточной информации, то больше и возможностей у компилятора обратить на это внимание.
Но опечатки — это самые тупые ошибки, которые встречаются не часто. И действительно, отлавливаются во многих случаях компилятором. А вот работа с указателями и с памятью вживую часто с т.з. компилятора корректна или он не может доказать корректность.
Короче, по опыту, плюсовики намного больше ошибок допускают (это я не по себе сужу, я не имею большого опыта, но работал с плюсовиками). И производительность у них намного меньше. Подчеркну — намного.
А есть языки, в которых можно очень кратко и элегантно выражать свою мысль. И изменение пары символов — это не ошибка, а изменение смысла кода. И, думается, в этом случае ошибок будет меньше. Потому как не нужно измерять количество ошибок на размер файла. Лучше измерять — на задачу. И если язык декларативный, позволяет кратко описывать проблемы, не позволяет ошибаться с памятью и т.д. — то очевидно, на нем и производительность программиста выше, и багов меньше. Особенно смысловых.
А как вообще можно сравнивать ежа с ужом и яблоки с апельсинами?
Как можно сравнивать язык со статической и динамической типизацией?
Язык с компилятором и без???
Британские учёные походу не только в Греции отдохнули, но и открыли там отделение академии ихних наук.
Как можно сравнивать язык со статической и динамической типизацией?
Язык с компилятором и без???
Британские учёные походу не только в Греции отдохнули, но и открыли там отделение академии ихних наук.
Не вижу препятствий, по правде говоря.
На первых двух уровнях ещё можно сравнивать — дальше уже разница существенней и сравнивать нет смысла. Хотя с другой стороны можно сравнить вкус блюд из существ или их некий индекс выживаемости. Но сама методика сравнения крайне ни о чём. Цель — благая, методика гумно.
............ Ёж............................ Уж.............. Царство..... Животные...................... Животные........ Тип......... Хордовые...................... Хордовые........ Класс....... Млекопитающие................. Рептилии........ Отряд....... Erinaceomorpha Gregory, 1910.. Чешуйчатые...... Подотряд.... -............................. Змеи............ Семейство... Ежовые........................ Ужеобразные..... Род......... Евразийские ежи............... Ужи............. Вид......... Обыкновенный ёж............... Обыкновенный уж.
Надо FORTH добавить для полного чемпионства:)
В статье учитываются только какие-то очень синтетические случаи. Если начать таким образом модифицировать реальные приложения, а не чистые алгоритмы, то процент запущенных, но неверно работающих приложений будет гораздо выше.
Взять, к примеру, тот же WPF (C#+XAML) — существует тысяча и один способ сделать так, что приложение скомпилируется, но будет работать неверно, и весьма вероятно, что неверно будет работать только в каком-то одном случае, в какой-то далекой ветке.
Что касается чистого C# — все верно — влияние синтаксических ошибок на результаты разработки на самом деле очень мало — на памяти не наберется и десятка случаев компилирующегося, но неверно работающего алгоритма. Строгая типизация и развитая IDE — наше всё.
Взять, к примеру, тот же WPF (C#+XAML) — существует тысяча и один способ сделать так, что приложение скомпилируется, но будет работать неверно, и весьма вероятно, что неверно будет работать только в каком-то одном случае, в какой-то далекой ветке.
Что касается чистого C# — все верно — влияние синтаксических ошибок на результаты разработки на самом деле очень мало — на памяти не наберется и десятка случаев компилирующегося, но неверно работающего алгоритма. Строгая типизация и развитая IDE — наше всё.
Ожидаемо. Только лидера нужно оценивать по проценту скомпилированного кода.
Конечно, самый лучший язык программирования — тот, который способен без ошибок скомпилировать код после любого вмешательства. И не важно, что приложение после такой компиляции работает неправильно — главное оно работает!
Так по-вашему?
Лидер совершенно справедливо определен по минимальному количеству ошибок в результате. Нет ничего хуже неверно работающего приложения — ошибка на этапе компиляции — самая лучшая и правильная ошибка.
Так по-вашему?
Лидер совершенно справедливо определен по минимальному количеству ошибок в результате. Нет ничего хуже неверно работающего приложения — ошибка на этапе компиляции — самая лучшая и правильная ошибка.
Я сказал, что нужно оценивать по проценту скомпилированного кода, остальное вы додумали сами.
Лучшим назван C++, по отношению правильных ответов к общему количеству тестов. В то же время, по отношению удачно-скомпилированных программ к количеству тестов лидирует Java.
Лучшим назван C++, по отношению правильных ответов к общему количеству тестов. В то же время, по отношению удачно-скомпилированных программ к количеству тестов лидирует Java.
C++ победитель по минимальному количеству Wrong Output, никаких относительностей.
Только этот показатель влияет на конечный результат программирования — работоспособность модифицированного кода.
Java по этому показателю на законном третьем месте.
Только этот показатель влияет на конечный результат программирования — работоспособность модифицированного кода.
Java по этому показателю на законном третьем месте.
Чтобы отловить ошибки после компиляции их нужно покрыть тестами. Здесь мы можем долго рассуждать о 100% покрытии кода тестами и т.п… Но все-таки покрытие кода тестами делает человек. А человек глупее компьютера. Поэтому он может тесты вовсе не написать или написать, но не правильно.
Java позволяет меньшими усилиями (только на этапе компиляции) поймать больше багов. И это уже достоинство исключительно ЯП.
Java позволяет меньшими усилиями (только на этапе компиляции) поймать больше багов. И это уже достоинство исключительно ЯП.
Не хочу долго попусту спорить, но если модифицированные программы на Java реже компилируются и чаще дают неверный результат, чем C# — какой язык лучше относится к случайным опечаткам? А именно это и исследуется — из названия статьи видно.
Это говорит лишь о том, что Java — болеенежный бюрократичный язык, на котором нужно более тщательно писать код, раз за разом получая по рукам от компилятора. При этом доля программ с ошибкой, которая удачно скомпилируется, запустится и выдаст неверный результат будет выше, чем на C++ и C#.
Это говорит лишь о том, что Java — более
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Исследование отношения популярных языков программирования к случайным ошибкам