Да, согласен, этот момент я не озвучил явно. Сравнение имеет смысл только языков, которые мы признаем как равнозначных по охвату и функционалу, принимая как данное, что на них решают достаточно схожий класс задач.
А «внутренняя стройность и логичность» — да, еще один критерий, но это ещё сложнее доказать и измерить )
Насчет второго — это всё же другое ) Все таки таблицы взяты не с потолка, а из четких соображений о том, что эти цифры могут в той или мере кореллировать со сложностью. А в вашем примере просто график, в котором топорно подогнаны шкалы, чтобы изобразить трендинг. :)
Из реального опыта, как из команд внутри Google, так из всего прошлого опыта Пайка, Томпсона и ко. Не знаю, я себя не ставлю выше них, и легко могу поверить, что они о «хороших» и «плохих» практиках понимают гораздо больше меня.
Ну, я в посте написал, что на каждую критику жду ответа на два вопроса :) Потому что мне всё же интересно, какими ещё косвенными методами можно оценивать сложность.
Функциональные языки вообще не хотел добавлять, потому что первые две методики работают лишь на похожих императивных языках.
Именно потому что сложность других языков на практике имела негативные последствия для разработки, и они проявились лишь с годами практического использования.
Тоесть, не будь других языков («которые писались отнюдь не дураками») или будь они достаточно хороши, Go не появился бы. Я потому и написал про «Go качнул маятник в другую сторону».
Возможно низкая сложность языка является следствием не окончательного понимания предметной области, не полной «вынужденной сложности»?
Нет.
В этом и поинт статьи — сложность не является синонимом «продвинутости» или «зрелости», и в данном случае это ровно наоборот — действительно глубокое понимание предметной области.
Посмотрите видео выступлений Пайка на тему сложности Go — думаю, вы быстро перестанете считать авторов Go за недоучек )
На самом деле я даже сомневался, включать ли Haskell. Методики сравнения, особенно первые две, всё же более адекватный результат покажут на схожих (итеративных) языках.
Я убеждён, что со временем исключения в Go появятся, когда будет осмысленна текущая философия языка.
Она более, чем осмыслена еще 5 лет назад.
Вы, видимо, безоговорочно считаете отсутствие исключений признаком незрелости языка и непонимания глубины темы, игнорируя все слова авторов Go на эту тему.
Да, про C# на последнем графике тоже такое объяснение вижу.
Да и оценивать сложность языка бесполезно. Стоит оценивать сложность разработки на языке, а это уже оценка вместе с экосистемой и только на одинаковом спектре задач.
Не соглашусь. Пусть и с погрешностью, но «сложность разработки на языке» кореллирует со «сложностью языка», которую, по косвенным признакам, я тут и пытался обрисовать.
А про одинаковый спектр задач — уже тут в комментариях постил, посмотрите сравнение по задачам из Rosetta Code — там тоже интересные результаты: arxiv.org/pdf/1409.0252v4.pdf
Смотрите, идея в том, что одним числом рассчитать и оценить сложность нельзя, поэтому я беру 3 методики, которые косвенно кореллируют со сложностью языка, и составляю картинку по ним. Наверное стоило, как результат, сделать разбитие на группы сложности, чтобы не вводить в заблуждение и не было придирок конкретно к отдельным графикам…
Да нет, подстройки выборки тут нет — я изучил всё что осилил о том, как можно оценивать сложность языков, и это три методики, к которым я реально пришёл. Серьезно, если кто-то тут предложит реально выполнимую методику получше (чем составная оценка по разным более грубым методам), я буду только рад.
Да и речь на самом деле о небольшой группе «универсальных» языков. Это не только с точки зрения здравого смысла и контекста статьи важно, но и для статистических данных.
Brainfuck не подходит, потому что это не язык общего назначения и кроме как ради фана или академического инструмента не используется. А так, взять его, чтобы доказать, что вышеиспользованные методы приблизительных оценок имеют очень ограниченную область применения и обладают массой минусов — не интересно, и так же понятно )
В Go читабельность ставится выше краткости. Во многом принципы Go созвучны с Zen Of Python.
По вашему примеру, посмотрите на golang.org/pkg/bufio/#example_Scanner_lines
Контекст задачи слишком обобщён, область — системное/сетевое/серверное программирование. Тут одним примером с БД не обойдешься, увы.
А так, да, насчет практики согласен, и это именно то, где Go однозначно хорош.
А «внутренняя стройность и логичность» — да, еще один критерий, но это ещё сложнее доказать и измерить )
В чем заключается подгонка под результат?
Clojure — императивный язык?
Функциональные языки вообще не хотел добавлять, потому что первые две методики работают лишь на похожих императивных языках.
Именно потому что сложность других языков на практике имела негативные последствия для разработки, и они проявились лишь с годами практического использования.
Тоесть, не будь других языков («которые писались отнюдь не дураками») или будь они достаточно хороши, Go не появился бы. Я потому и написал про «Go качнул маятник в другую сторону».
Нет.
В этом и поинт статьи — сложность не является синонимом «продвинутости» или «зрелости», и в данном случае это ровно наоборот — действительно глубокое понимание предметной области.
Посмотрите видео выступлений Пайка на тему сложности Go — думаю, вы быстро перестанете считать авторов Go за недоучек )
Она более, чем осмыслена еще 5 лет назад.
Вы, видимо, безоговорочно считаете отсутствие исключений признаком незрелости языка и непонимания глубины темы, игнорируя все слова авторов Go на эту тему.
Не соглашусь. Пусть и с погрешностью, но «сложность разработки на языке» кореллирует со «сложностью языка», которую, по косвенным признакам, я тут и пытался обрисовать.
А про одинаковый спектр задач — уже тут в комментариях постил, посмотрите сравнение по задачам из Rosetta Code — там тоже интересные результаты: arxiv.org/pdf/1409.0252v4.pdf
Пол-часа убил только на гугление грамматики для более свежих версий.
Да и речь на самом деле о небольшой группе «универсальных» языков. Это не только с точки зрения здравого смысла и контекста статьи важно, но и для статистических данных.
Brainfuck не подходит, потому что это не язык общего назначения и кроме как ради фана или академического инструмента не используется. А так, взять его, чтобы доказать, что вышеиспользованные методы приблизительных оценок имеют очень ограниченную область применения и обладают массой минусов — не интересно, и так же понятно )