Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 203
Т.е. по всем трем методикам выходит, что разработка на C в 3-7 раз проще, чем разработка на C#.
Вы согласны с этим тезисом или как можете объяснить это соотношение?
Вы согласны с этим тезисом или как можете объяснить это соотношение?
Сложно ответить — я не пишу на C#, и мне самому интересно послушать версии, насколько показатели по нему кореллируют или нет с реальными ощущениями. Подозреваю, что в третьем случае, у C# такой «отрыв» из-за того, что он больше в энтерпрайзе используется, и не особо в open-source сообществе.
Ну вот вы вроде сами понимаете, что отношение кол-ва репозиториев на гитхабе к кол-ву вопросов на SO очень и очень слабо коррелирует с сложностью языка, возможно даже слабее чем отношение популяции канадских бобров к средней зарплате в РФ.
Конечно мне знаком принцип «correlation doesn't imply causation», но логика этого сравнения озвучена — при прочих равных, более сложный язык будет вызывать больше вопросов. Хотя понимаю, что там факторов, которые дают погрешность в ± 100% — целая пачка.
В любом случае — это лучшее, что я придумал на тему «как использовать социальные данные для приблизительной оценки сложности языков».
В любом случае — это лучшее, что я придумал на тему «как использовать социальные данные для приблизительной оценки сложности языков».
Объективно говоря, C# как язык — это java 8 + пяток простых сахарных помогалок. Многие сходяться во мнении, что экосистема явы имеет более высокий порог вхождения, чем C#. Ну а тут, судя по графику, C# сложнее java в почти 4 раза.
Смотрите, идея в том, что одним числом рассчитать и оценить сложность нельзя, поэтому я беру 3 методики, которые косвенно кореллируют со сложностью языка, и составляю картинку по ним. Наверное стоило, как результат, сделать разбитие на группы сложности, чтобы не вводить в заблуждение и не было придирок конкретно к отдельным графикам…
Показатели по C# вообще никак не коррелируют с реальными ощущениями. Я писал на JS, на C++, имел некий контакт со Scala и Java — так что нет, сравнительные показатели в ваших графиках критики ощущениями не выдерживают.
Кстати, «два вопроса для критиков» я специально для вас написал ) Ответьте, если не сложно )
а) какой есть метод лучше, для оценки сложности языка (в терминологии сложности данной статьи)?
В данной статье так и не определен термин «сложность», поэтому что-то предложить здесь сложно.
б) как можно объяснить достаточно очевидную корелляцию результатов у всех трех методик, если они несостоятельны и их результаты — результат случайного распределения?
Во-первых, для трех методик можно говорить и о банальном совпадении. Во-вторых, первая и вторая методика коррелируют друг с другом безотносительно того, показывают они сложность, или нет.
А теперь немножко об (формальных) ошибках в ваших методиках.
Вот вы говорите, что в JS 41 ключевое слово, а в C# — 79. Но вы не учитываете несколько занятных вещей. Во-первых, JS указывает каждое слово один раз (несмотря на различное поведение), а C# — столько раз, сколько различных семантик у него есть. Во-вторых, в списке ключевых слов C# есть type aliases и два оператора, которые учитывать тоже некорректно.
Или вот вы говорите, что по тегу C# на SO 812 тысяч вопросов. Однако стоит открыть произвольный, как выяснится, что единственное, чем он связан с C# — это то, что на нем написан код, а вся суть вопроса к языку отношения не имеет. И таких там большинство, это я вам говорю как человек, который на этот тег подписан.
Я писал на множестве языков, в том числе несколько лет на C#, затем несколько лет на Java, попутно использую JS и считаю, что имею весьма не плохое знание Scala.
Нет. C# не сложен. Он не должен выделяться. Единственное мое объяснение: он популярен для коммерческой разработки, но не популярен для open source проектов.
Вообще 3 точки: C, Java и C# дискредитируют все методы оценки.
Да и оценивать сложность языка бесполезно. Стоит оценивать сложность разработки на языке, а это уже оценка вместе с экосистемой и только на одинаковом спектре задач.
Нет. C# не сложен. Он не должен выделяться. Единственное мое объяснение: он популярен для коммерческой разработки, но не популярен для open source проектов.
Вообще 3 точки: C, Java и C# дискредитируют все методы оценки.
Да и оценивать сложность языка бесполезно. Стоит оценивать сложность разработки на языке, а это уже оценка вместе с экосистемой и только на одинаковом спектре задач.
Да, про C# на последнем графике тоже такое объяснение вижу.
Не соглашусь. Пусть и с погрешностью, но «сложность разработки на языке» кореллирует со «сложностью языка», которую, по косвенным признакам, я тут и пытался обрисовать.
А про одинаковый спектр задач — уже тут в комментариях постил, посмотрите сравнение по задачам из Rosetta Code — там тоже интересные результаты: arxiv.org/pdf/1409.0252v4.pdf
Да и оценивать сложность языка бесполезно. Стоит оценивать сложность разработки на языке, а это уже оценка вместе с экосистемой и только на одинаковом спектре задач.
Не соглашусь. Пусть и с погрешностью, но «сложность разработки на языке» кореллирует со «сложностью языка», которую, по косвенным признакам, я тут и пытался обрисовать.
А про одинаковый спектр задач — уже тут в комментариях постил, посмотрите сравнение по задачам из Rosetta Code — там тоже интересные результаты: arxiv.org/pdf/1409.0252v4.pdf
«сложность разработки на языке» кореллирует со «сложностью языка»
И что же мы имеем по метрикам?
- Количество ключевых слов. Как-то я не вижу сложности тут. Меньше всего ключевых слов у лиспа. Где clojure в вашем сравнении? По вопросам и репозиториям он не менее популярен, чем Go. Я бы не назвал разработку на лиспе очень уж простой. Или тот же js: в новой версии добавили несколько ключевых слов: let, const и class, тем самым только упростив разработку.
- Количество правил. Было бы интересно, но при первом же взгляде на цифры понимаешь эфемерность метрики. У scala меньше, чем у java на 50 и меньше, чем у C# более чем вдвое. При всей моей любви к scala… Это скорее соревнование по лаконичности записи правил, а не по их количеству.
- Количество вопросов на SO в сравнении с количеством репозиториев. C# как-бы говорит нам, что смотреть тут не на что.
Ну, я в посте написал, что на каждую критику жду ответа на два вопроса :) Потому что мне всё же интересно, какими ещё косвенными методами можно оценивать сложность.
Функциональные языки вообще не хотел добавлять, потому что первые две методики работают лишь на похожих императивных языках.
Функциональные языки вообще не хотел добавлять, потому что первые две методики работают лишь на похожих императивных языках.
Функциональные языки вообще не хотел добавлять, потому что первые две методики работают лишь на похожих императивных языках.
clojure настолько же императивный, как и все остальные.
И настолько же ФП, как и C#, JS, java8 и scala. +- погрешность. Например в scala есть typeclass.
И уж точно не сравнится с haskell.
И я уже обосновал вам, что по первой методике вы похожих не выбрали. Существенная часть ключевых слов scala относится к системе типов (те самые дженерики), еще часть — к ФП. Где тут похожесть с go?
жду ответа на два вопроса :)
1. Формальный критерий субъективной оценки? Нет уж, спасибо. Можно посмотреть скорость разработки схожих задач схожими командами и скорость «выгорания» людей при работе с языком, но у нас нет такой возможности.
2. как можно объяснить достаточно очевидную корелляцию результатов у всех трех методик
Насчет второго — это всё же другое ) Все таки таблицы взяты не с потолка, а из четких соображений о том, что эти цифры могут в той или мере кореллировать со сложностью. А в вашем примере просто график, в котором топорно подогнаны шкалы, чтобы изобразить трендинг. :)
Clojure — императивный язык?
Clojure — императивный язык?
эти цифры могут в той или мере кореллировать со сложностьюа могут и не коррелировать.
топорно подогнаны шкалыу вас — топорно подогнаны метрики и выборка языков. См. clojure.
Можно конечно предположить, что причина в корреляции между спектром применения и полнотой языка (первые 2 метрики) и коммерческой успешностью (последняя), но я бы поостерегся делать столь далеко идущие выводы.
Clojure — императивный язык?
Внезапно, правда? Более того, он не следит на сайдэффектами, так что по некоторым определениям он не ФП (как и все здесь, кроме haskell).
Так, на всякий случай: Clojure — императивный язык?
> б) как можно объяснить достаточно очевидную корелляцию результатов у всех трех методик, если они несостоятельны и их результаты — результат случайного распределения?
Есть такая штука как KPI. Её легко измерить начальнику(иначе она бессмысленна), её легко «подогнать» подчинённому.
Люди хотели язык упростить — повыкидывали концепции и ключевые слова. KPI вы успешно измерили.
Упростился ли язык от того, что можно писать
value = «12345» + (string)6789
а не
value = «12345» + 6789
— нет. В первом случае надо помнить про волшебное слово, а во втором — держать в голове правила, по которым произойдёт конкатенация (или сложение?).
А «string.Format(»{0}{1}", «12345», 6789)" вообще в БНФ не попадает
Поэтому у вас по «сложности» проигрывают языки с развитой статической системой типов.
> Пусть и с погрешностью, но «сложность разработки на языке» кореллирует со «сложностью языка», которую, по косвенным признакам, я тут и пытался обрисовать.
Пока вы не дали определения «сложности языка» тут бесполезно соглашаться или нет.
Вы слона по хвосту оцениваете.
Это не придираясь к диванной аналитике по мелочам, типа что потерялись всякие codeplex.
Есть такая штука как KPI. Её легко измерить начальнику(иначе она бессмысленна), её легко «подогнать» подчинённому.
Люди хотели язык упростить — повыкидывали концепции и ключевые слова. KPI вы успешно измерили.
Упростился ли язык от того, что можно писать
value = «12345» + (string)6789
а не
value = «12345» + 6789
— нет. В первом случае надо помнить про волшебное слово, а во втором — держать в голове правила, по которым произойдёт конкатенация (или сложение?).
А «string.Format(»{0}{1}", «12345», 6789)" вообще в БНФ не попадает
Поэтому у вас по «сложности» проигрывают языки с развитой статической системой типов.
> Пусть и с погрешностью, но «сложность разработки на языке» кореллирует со «сложностью языка», которую, по косвенным признакам, я тут и пытался обрисовать.
Пока вы не дали определения «сложности языка» тут бесполезно соглашаться или нет.
Вы слона по хвосту оцениваете.
Это не придираясь к диванной аналитике по мелочам, типа что потерялись всякие codeplex.
*с дальних рядов* А добавьте пожалуйста в графики Brainfuck! Спасибо.
При этом я буду анализировать языки, которые достаточно универсальны для решения большого круга задач, имеют достаточно большое сообщество и информация о них доступна. Экзотику вроде Brainfuck мы не рассматриваем.
Так-то оно понятно, что крайности не показатель, и во всём важен баланс. Но интересно же. Для чистоты эксперимента, так сказать. А то ведь подстройка выборки под результат не есть гуд.
Да нет, подстройки выборки тут нет — я изучил всё что осилил о том, как можно оценивать сложность языков, и это три методики, к которым я реально пришёл. Серьезно, если кто-то тут предложит реально выполнимую методику получше (чем составная оценка по разным более грубым методам), я буду только рад.
Да и речь на самом деле о небольшой группе «универсальных» языков. Это не только с точки зрения здравого смысла и контекста статьи важно, но и для статистических данных.
Brainfuck не подходит, потому что это не язык общего назначения и кроме как ради фана или академического инструмента не используется. А так, взять его, чтобы доказать, что вышеиспользованные методы приблизительных оценок имеют очень ограниченную область применения и обладают массой минусов — не интересно, и так же понятно )
Да и речь на самом деле о небольшой группе «универсальных» языков. Это не только с точки зрения здравого смысла и контекста статьи важно, но и для статистических данных.
Brainfuck не подходит, потому что это не язык общего назначения и кроме как ради фана или академического инструмента не используется. А так, взять его, чтобы доказать, что вышеиспользованные методы приблизительных оценок имеют очень ограниченную область применения и обладают массой минусов — не интересно, и так же понятно )
Зато это было бы весьма по-научному. Читайте про фальсифицируемость. Сейчас вы эмпирически предполагаете, что теория не работает на Брейнфаке. А если вы его измерите и попугаями, и удавами, то можно будет уже предметно от цифр отталкиваться. И с умным видом заявить, что на нём теория сползла до уровня погрешности, и применяться не может.
Я не знаю, откуда вы взяли, что я считаю «оценку количества keyword-ов» универсиальной теорией расчет сложности языков, применимую ко всем языкам, но я несколько раз это явно дал понять — единственный реальный метод _оценить_ сложность я вижу в совокупности нескольких оценочных методик, и проследить корелляцию.
И столько же раз написал, что да, прекрасно понимаю, насколько примитивной и грубой оценкой является первая методика, но при этом я, да, считаю что она не лишена оснований для группы императивных языков. Вы же не будете мне доказывать, что количество ключевых слов в C++ чисто случайно больше, чем в Go, и чисто случайно Go субъективно называется более простым?
Но если вы хотите гнуть свою линию «нет брейнфака — никакой взаимосвязи быть не может» — продолжайте, но мне странны такие доводы от логически мыслящих людей.
И столько же раз написал, что да, прекрасно понимаю, насколько примитивной и грубой оценкой является первая методика, но при этом я, да, считаю что она не лишена оснований для группы императивных языков. Вы же не будете мне доказывать, что количество ключевых слов в C++ чисто случайно больше, чем в Go, и чисто случайно Go субъективно называется более простым?
Но если вы хотите гнуть свою линию «нет брейнфака — никакой взаимосвязи быть не может» — продолжайте, но мне странны такие доводы от логически мыслящих людей.
Вы же не будете мне доказывать, что количество ключевых слов в C++ чисто случайно больше, чем в Go, и чисто случайно Go субъективно называется более простым?
Я могу попробовать. Сравните велосипед и мотоцикл по количеству деталей и необходимых навыков для управления. А потом сравните их же по простоте преодоления больших дистанций.
И почему вы сравниваете Go и C++? Вот, возьмите из вашего графика Scala & JS с одинаковым количеством keywordов. Или Haskell и C# (первый считается более сложным, во втором больше keywordов по вашему графику). Вы подтасовываете теорию под то, что хотите видеть вы сами.
Нет-нет, я пытаюсь этими графиками попробовать дать ответ на вопрос «А докажи, что Go проще C++ или Java?» людям, которые не пробовали Go, и считают все утверждения о простоте — выдумкой. То, сколько и кто и как едет — это уже тем отдельного холивара :)
Ну госпади, какая разница сколько keywordов учить — 25 или 50? Людей не волнует как долго им придется учить язык до уровня владения «ниндзя»; их волнует то, как быстро они смогут написать что-то на нем. Если для написания «hello %username%» им придется призывать последний круг ада и танцевать голышом на канате, то сомневаюсь что им поможет факт, что в языке всего 10 keywords.
Не, как аргумент для дебилов — это конечно покатит.
Не, как аргумент для дебилов — это конечно покатит.
Всё, я устал писать одинаковые комменты ) Признаю это как свой фейл.
Речь не в том, «сколько keyword-ов учить», а в том, что это кое-как коррелирует со сложностью языка, и это легко подсчитать, поэтому годится как одну из методик. Аргументы про «просто случайное распределение» я выслушал, понял, и не согласен.
Речь не в том, «сколько keyword-ов учить», а в том, что это кое-как коррелирует со сложностью языка, и это легко подсчитать, поэтому годится как одну из методик. Аргументы про «просто случайное распределение» я выслушал, понял, и не согласен.
Речь не в том, «сколько keyword-ов учить», а в том, что это кое-как коррелирует со сложностью языка, и это легко подсчитатьДа ну, это коррелирует со сложностью разработки компилятора и IDE для данного языка. У тебя нету никакого графика «сложности» языка и ты рассуждаешь о корреляции между сложностью и количеством чего-нибудь? Че, правда? Дай сводный график твоих трех методик и реальный график сложности языков и сравни.
Аргументы про «просто случайное распределение» я выслушал, понял, и не согласен.Да бля, ты сам-то на график посмотри. Ты смотришь на Go и C++, я смотрю на JS & Scala & C#. Какое еще нахер случайное распределение (мы до него еще тупо не дошли), если ты тупо игнорируешь свой график и чужое мнение?
У тебя ни keywordы не были посчитаны правильно, ни bnf-грамматики. Сначала нужна нормализация, приведение к общему виду. А то получается так, что в одном языке медленный глючный компилятор и три правила в грамматике, а в другом языке быстрый оттестированный компилятор и пятьсот правил грамматики.
Какой еще блин анализ на необработанных данных?
Ой, простите. Haskell же функциональный, да. Поглядите на C и C# в рамках какого-нибудь написания какого-нибудь хабра.
> но мне странны такие доводы от логически мыслящих людей.
ru.wikipedia.org/wiki/Чучело_(логическая_уловка)
ЗЫ. Вы сразу в конце статьи дописывайте «кто не согласен — тот дурак»
ru.wikipedia.org/wiki/Чучело_(логическая_уловка)
ЗЫ. Вы сразу в конце статьи дописывайте «кто не согласен — тот дурак»
habrahabr.ru/post/259279/#comment_8445561
Наконец-то кто-то это начал. Но повторюсь, в идеале сравнивать количество сущностей нужно на конкретных типовых задачах, тогда это будет иметь смысл, ведь никто не будет изучать все конструкции языка сразу, а изучив их это становится скорее преимуществом.
Т.е. нужно что-то вроде кучи таких вещей todomvc.com, где каждый представитель языка (сообщество) решает задачу оптимальным способом. А в итоге имеем график сравнения сложностей для этой задачи и комплексный график по всем задачам.
Наконец-то кто-то это начал. Но повторюсь, в идеале сравнивать количество сущностей нужно на конкретных типовых задачах, тогда это будет иметь смысл, ведь никто не будет изучать все конструкции языка сразу, а изучив их это становится скорее преимуществом.
Т.е. нужно что-то вроде кучи таких вещей todomvc.com, где каждый представитель языка (сообщество) решает задачу оптимальным способом. А в итоге имеем график сравнения сложностей для этой задачи и комплексный график по всем задачам.
Да, было бы точнее, но я не вижу способа как это сделать реальным. Есть проект сравнения языков на основе задач с Rosetta Code — Go там, кстати, тоже жжот — arxiv.org/pdf/1409.0252v4.pdf — но, сложность таких сравнений мне не под силу, увы.
Собственно, и что? Просто это разного уровня сущности.
В C++ это способ пробежаться по коллекции, а в Rust это еще реализация стандартных алгоритмов над коллекцией по умолчанию.
The iteration protocol is defined by the Iterator trait in the std::iter module. The minimal implementation of the trait is a next method, yielding the next element from an iterator object.
The Iterator trait provides many common algorithms as default methods.
Т.е. для создания своего надо только next реализовать. Для остальных методов есть дефолтная реализация.
The iteration protocol is defined by the Iterator trait in the std::iter module. The minimal implementation of the trait is a next method, yielding the next element from an iterator object.
The Iterator trait provides many common algorithms as default methods.
Т.е. для создания своего надо только next реализовать. Для остальных методов есть дефолтная реализация.
Не совсем — подходы слегка отличаются. В Rust Iterator это что-о близкое к концепции iterable в Python, только статически организованное. В С++ библиотека висит снаружи, опираясь на абстракцию итератора, в Rust включена в этот самый итератор.
Зато в C++ есть зачем-то поле distance… Какое отношение оно имеет к абстрактному итератору?
И, кстати, если сильно всё переделывать — снаружи использование данной коллекции ничем не будет
отличаться, а как в C++ — не уверен. Не приходилось такое проделывать.
Но суть не в этом, Rust это язык по сложности сопоставимый с C++, который требует усилий по отслеживанию времени жизни, декомпозиции на трейты и т.п. непростые вещи.
Согласен, но способов выстрелить себе в ногу в runtime убавилось — этого и добивались.
Да и отсутствия наследия конца 90х благотворно сказывается на стройность языка.
Это не говоря про бюрократию Rust, вроде списка из почти ста возможных ошибок компляции doc.rust-lang.org/error-index.html.
Опять же, на мой вкус, это не страшно. Размер стандарта C++ последних версий — вот где бюрократия.
Ставить в ряд с Ruby и Go естественно не стоит — ниши и цели разные. Но вот сравнить с близкими альтернативами по предложенным параметрам — почему нет. Собстенно это автор и предлагает, вроде бы.
P.S. кто-то похоже обиделся на один из моих комментариев выше и теперь нормально цитаты не отображаются — прошу прощения.
Зато в C++ есть зачем-то поле distance… Какое отношение оно имеет к абстрактному итератору?
И, кстати, если сильно всё переделывать — снаружи использование данной коллекции ничем не будет
отличаться, а как в C++ — не уверен. Не приходилось такое проделывать.
Но суть не в этом, Rust это язык по сложности сопоставимый с C++, который требует усилий по отслеживанию времени жизни, декомпозиции на трейты и т.п. непростые вещи.
Согласен, но способов выстрелить себе в ногу в runtime убавилось — этого и добивались.
Да и отсутствия наследия конца 90х благотворно сказывается на стройность языка.
Это не говоря про бюрократию Rust, вроде списка из почти ста возможных ошибок компляции doc.rust-lang.org/error-index.html.
Опять же, на мой вкус, это не страшно. Размер стандарта C++ последних версий — вот где бюрократия.
Ставить в ряд с Ruby и Go естественно не стоит — ниши и цели разные. Но вот сравнить с близкими альтернативами по предложенным параметрам — почему нет. Собстенно это автор и предлагает, вроде бы.
P.S. кто-то похоже обиделся на один из моих комментариев выше и теперь нормально цитаты не отображаются — прошу прощения.
Такие же штуки в Java (stream) и C# (linq) выглядят ни разу не лучше. Вы сравнили теплое с мягким.
Я так понимаю вас испугал в Rust список шаблонных методов типа skip,take, max, zip — почти 1 в 1 тоже самое что содержиться в классе Enumerable С# (и stream для java) который linq. Так после реализации их в том же Enumerable они не кажутся мне страшными в итераторе в Rust.
Во-вторых, в Java и C# есть итераторы, и они определяются так же просто как и в обычных языках, зачем вы stream и linq приплели — не понятно.
В Java и C# данные операции отдельно по историческим причинам. Изначально их там вообще не было. В той же scala, где библиотека коллекций писалась сразу высокоуровневой, похожий набор методов есть в Iterable.
Во-первых, в C# итератор — это не коллекция.
И причины у этого не исторические, а просто потому, что итератор — это не коллекция.
И причины у этого не исторические, а просто потому, что итератор — это не коллекция.
Так никто не утверждал, что итератор — коллекция.
Речь шла про «голый» итератор и набор ништяков в виде Linq.
Мол, в Rust итератор — это
А в C# — отдельно
Речь шла про «голый» итератор и набор ништяков в виде Linq.
Мол, в Rust итератор — это
move_next плюс функциональные ништяки.А в C# — отдельно
MoveNext, а потом отдельно появился Linq.1) Скажите, в Rust
(1..1000)
.filter(|&x| 1 == 1)
.filter(|&x| 1 == 1)
.first()
создаст 3 копии коллекции в памяти (надеюсь в синтаксисе не наврал)? и по каждой из них сделает проход?
в C#.
Enumerable.Range(1,1000)
.Where(x => 1 == 1)
.Where(x => 1 == 1)
.First();
— нет и нет, потому, что Where возвращает не коллекцию.
Итератор — это не коллекция, функциональные ништяки тут ни при чём.
2) habrahabr.ru/post/147363 — а в Rust как «функциональные ништяки» добавляют?
(1..1000)
.filter(|&x| 1 == 1)
.filter(|&x| 1 == 1)
.first()
создаст 3 копии коллекции в памяти (надеюсь в синтаксисе не наврал)? и по каждой из них сделает проход?
в C#.
Enumerable.Range(1,1000)
.Where(x => 1 == 1)
.Where(x => 1 == 1)
.First();
— нет и нет, потому, что Where возвращает не коллекцию.
Итератор — это не коллекция, функциональные ништяки тут ни при чём.
2) habrahabr.ru/post/147363 — а в Rust как «функциональные ништяки» добавляют?
Да причем тут вообще коллекции? Вы среагировали на «библиотека коллекций»? Ну уж извините, так это называется в scala.
Сам интерфейс Iterator (Iterable, etc) ничего не говорит о создании промежуточных коллекций. Также как он ничего не говорит про однопоточность/многопоточность обработки.
Вопрос номер 1 некорректен. Ибо с таким интерфейсом итератора всегда можно написать какой-нибудь LazyRange, не создающий промежуточных коллекций.
В той же scala, где весь набор таких методов прямо в Iterable (на самом деле в еще более общем интерфейсе — Traversable),
создаст 2 промежуточные коллекции, а
промежуточных коллекций не создаст.
Сам интерфейс Iterator (Iterable, etc) ничего не говорит о создании промежуточных коллекций. Также как он ничего не говорит про однопоточность/многопоточность обработки.
Вопрос номер 1 некорректен. Ибо с таким интерфейсом итератора всегда можно написать какой-нибудь LazyRange, не создающий промежуточных коллекций.
В той же scala, где весь набор таких методов прямо в Iterable (на самом деле в еще более общем интерфейсе — Traversable),
(1 to 1000)
.filter(x => 1 == 1)
.filter(x => 1 == 1)
.head()создаст 2 промежуточные коллекции, а
(1 to 1000).view
.filter(x => 1 == 1)
.filter(x => 1 == 1)
.head()промежуточных коллекций не создаст.
> Ибо с таким интерфейсом итератора всегда можно написать какой-нибудь LazyRange, не создающий промежуточных коллекций.
Формально — да.
Вопрос не в том, что можно создать, а в том, как с этим работать. Если мне приходит IEnumerable — я знаю, например, что Count() может быть достаточно долгим, а пытаться обойти больше 1 раза — плохая идея. И это принципиально влияет на выбранные алгоритмы.
LazyRange написать вы можете, но выставив его как абстракцию Iterator вы подложите грабли любому, использующему ваш код.
Формально — да.
Вопрос не в том, что можно создать, а в том, как с этим работать. Если мне приходит IEnumerable — я знаю, например, что Count() может быть достаточно долгим, а пытаться обойти больше 1 раза — плохая идея. И это принципиально влияет на выбранные алгоритмы.
LazyRange написать вы можете, но выставив его как абстракцию Iterator вы подложите грабли любому, использующему ваш код.
LazyRange написать вы можете, но выставив его как абстракцию Iterator вы подложите грабли любому, использующему ваш код.
В Python так вполне живут.
В Python так вполне живут.
ну как… Может и живут. Если клепать сайтики с полусотней записей на страничку — без разницы, конечно. Python в энтерпрайзе, с переколбашиванием миллионов записей, мне не попадался.
Только C# писался для других целей, поэтому там так не делают.
Только C# писался для других целей, поэтому там так не делают.
Linq в C# это, несомненно, гениальная библиотека. Но это именно гениальное дополнение к жутковатому легаси, а не нечто, идеальное во всех отношениях. Не стоит рассматривать ее как единственно возможный путь.
а это не совсем про Linq. Или совсем не про Linq.
IEnumerable и ICollection (IQueryable) — это не часть Linq, это абстракции структур данных, поддерживающие (располагающие) к разным кейсам использования.
в Rust этого разделения нет.
Linq не идеален, но лучшего (для моих задач) я пока не видел. И я не считаю его дополнением к легаси.
IEnumerable и ICollection (IQueryable) — это не часть Linq, это абстракции структур данных, поддерживающие (располагающие) к разным кейсам использования.
в Rust этого разделения нет.
Linq не идеален, но лучшего (для моих задач) я пока не видел. И я не считаю его дополнением к легаси.
Обратит внимание на коллекции в scala. На мой взгляд это пока один из лучших подходов, хоть и не без недостатков.
Коллекции в scala сохраняют как можно большую часть исходного контракта и при этом очень хорошо расширяются. Например
Коллекции в scala сохраняют как можно большую часть исходного контракта и при этом очень хорошо расширяются. Например
"abc".filter(_ != 'b') // "ac"Надо посмотреть поближе, но именно такой extension метод написать на C# не сложно.
Ну, то есть буквально
new String(«abc».Where(_ => _ != 'b').ToArray()); // вот это уже легаси
Ну, то есть буквально
new String(«abc».Where(_ => _ != 'b').ToArray()); // вот это уже легаси
В scala один из принципиальных моментов — отсутствие этих «ToArray». То есть они там есть (есть даже обобщенный метод to: «abc».to[Vector]), но использовать их обычно не надо.
Ну и да, строка в scala — это как раз легаси строка из java.
Огромное преимущество подхода scala перед Linq — возможность работы с персистентными коллекциями благодаря переопределению методов, чего не добиться с extension methods.
Ну и да, строка в scala — это как раз легаси строка из java.
Огромное преимущество подхода scala перед Linq — возможность работы с персистентными коллекциями благодаря переопределению методов, чего не добиться с extension methods.
Я не могу сказать почему конструктор строки не принимает enumerable, но это точно не проблема linq
Вы где-то видите в моем коде конструктор строки?
> отсутствие этих «ToArray»
Я думаю вы про мой код
Я думаю вы про мой код
Именно. В моем коде не было «mkString». Вот тут нет «toArray»:
Array('a', 'b', 'c').filter(_ != 'b') // Array(a, c)«abc».filter(_ != 'b') — возвращает строку «ac»?
«abc».view.filter(_ != 'b') — уже не вернёт строку(должно же быть ленивым?)? И не массив? А как получить строку/массив?
«abc».view.filter(_ != 'b') — уже не вернёт строку(должно же быть ленивым?)? И не массив? А как получить строку/массив?
«abc».view.filter(_ != 'b').force
> .force
Тот же ToArray(), вид сбоку. Хотя строками через Linq работать не очень красиво (но в общем то и не надо).
А вот идея отделить ленивое от неленивого мне нравится.
Тот же ToArray(), вид сбоку. Хотя строками через Linq работать не очень красиво (но в общем то и не надо).
А вот идея отделить ленивое от неленивого мне нравится.
На все типы данных ToType не напасешься. Сам Linq довольно беден на методы ToType. ToSet, например, нет.
Да и сам код с force не упоминает конкретный тип, что позволяет при необходимости сменить тип только в одном месте.
Да и сам код с force не упоминает конкретный тип, что позволяет при необходимости сменить тип только в одном месте.
> На все типы данных ToType не напасешься. ToSet, например, нет.
Внезапно, мне почему-то объекты нужны в правильном порядке. Я не помню когда Set в последний раз использовал.
> Да и сам код с force не упоминает конкретный тип
Разницы между ToArray и ToList с практической стороны тоже немного. Я себе не представляю, что бы метод принимал Array, перемылывал, возвращал Array, а потом я вдруг захотел бы что бы он принимал List и возвращал List.
И оба они реализуют IList.
Ну, наверное неплохо, но и бесполезно.
Да что хорошего мне бы мог вернуть
new Dictionary<int, int>().Select(x => x.Value).force
или
new HashSet().OrderBy(x => x.Value).force
?
Внезапно, мне почему-то объекты нужны в правильном порядке. Я не помню когда Set в последний раз использовал.
> Да и сам код с force не упоминает конкретный тип
Разницы между ToArray и ToList с практической стороны тоже немного. Я себе не представляю, что бы метод принимал Array, перемылывал, возвращал Array, а потом я вдруг захотел бы что бы он принимал List и возвращал List.
И оба они реализуют IList.
Ну, наверное неплохо, но и бесполезно.
Да что хорошего мне бы мог вернуть
new Dictionary<int, int>().Select(x => x.Value).force
или
new HashSet().OrderBy(x => x.Value).force
?
Внезапно, мне почему-то объекты нужны в правильном порядке. Я не помню когда Set в последний раз использовал.
У вас какой-то очень специфичный узкий круг задач, что вам не нужен Set.
new Dictionary<int, int>().Select(x => x.Value).force
Зачем тут force? Тут же нет ленивых коллекций.
new Dictionary<int, int>().Select(x => x.Value) — это IEnumerable<`Int>
И? force — метод исключительно ленивых коллекций, позволяющий превращать их в неленивые.
У Iterable его просто нет.
У Iterable его просто нет.
> У Iterable его просто нет.
о как…
А new HashSet().OrderBy(x => x.Value) — это на ленивый HashSet потянет?
> У вас какой-то очень специфичный узкий круг задач, что вам не нужен Set.
Возможно. Наверное на нашем workflow его заменяет ToDictionary() и
.Select(x => x.prop)
.Distinct()
И результат — immutable, строить для него Set — это как-то…
о как…
А new HashSet().OrderBy(x => x.Value) — это на ленивый HashSet потянет?
> У вас какой-то очень специфичный узкий круг задач, что вам не нужен Set.
Возможно. Наверное на нашем workflow его заменяет ToDictionary() и
.Select(x => x.prop)
.Distinct()
И результат — immutable, строить для него Set — это как-то…
это на ленивый HashSet потянет
У Set нет orderBy. Хотите сортировку — приводите к Seq: mySet.seq
Distinct
distinct и в scala есть (в Seq).
Но мне Set обычно для быстрой проверки нужен. В C# я его тоже Dictionaty заменял, но это не от хорошей жизни. Выкрутиться-то всегда можно.
И результат — immutable
В scala все коллекции неизменяемые по умолчанию. Мутабельные коллекции еще импортировать надо. Их стараются без необходимости не использовать.
Какая связь с Count вообще? Используйте наследника Iterable с гарантированной сложностью Size.
Iterable — самый базовый контракт. Хотите дополнительных условий — используйте наследников.
Какие еще грабли? Контракт не нарушен. Более того, как ниже уже отметили, в расте по умолчанию эти операции ленивые.
Iterable — самый базовый контракт. Хотите дополнительных условий — используйте наследников.
Какие еще грабли? Контракт не нарушен. Более того, как ниже уже отметили, в расте по умолчанию эти операции ленивые.
> Контракт не нарушен
а у вас контракт подразумевает ограничение Count() по сложности?
в C# разумно предполагать, что он отличается для Enumerable и коллекции.
в Rust — видимо, «хрен его знает».
Это просто более слабый контракт.
> Используйте наследника Iterable с гарантированной сложностью Size.
А есть стандартный?
а у вас контракт подразумевает ограничение Count() по сложности?
в C# разумно предполагать, что он отличается для Enumerable и коллекции.
в Rust — видимо, «хрен его знает».
Это просто более слабый контракт.
> Используйте наследника Iterable с гарантированной сложностью Size.
А есть стандартный?
Есть Iterator, где есть
И есть ExactSizeIterator — An iterator that knows its exact length.
count() с O(n) и size_hint() (предполагаемая верхняя граница; может быть неизвестна).И есть ExactSizeIterator — An iterator that knows its exact length.
Толково. А ExactSumIterator есть?
Ну то есть мне надо посчитать среднее по данным из чужого кода.
В c# я могу написать функцию, хорошо работающую примерно в 100% случаев, даже если данных — терабайт. Примерно так(да, я знаю что int не бесконечен):
public int Avg(IEnumerable enumerable)
{
var collection = enumerable as ICollection;
if (collection != null)
{
return collection.Sum() / collection.Count;
}
var query = enumerable as IQueryable;
if (query != null)
{
return query.Sum()/query.Count();
}
var sum = 0;
var count = 0;
foreach (var i in enumerable)
{
sum += i;
count++;
}
return sum/count;
}
что мне делать с ExactSizeIterator я пока не понял (только не надо упоминать, что считалка среднего где-то встроена. Это пример)
Ну то есть мне надо посчитать среднее по данным из чужого кода.
В c# я могу написать функцию, хорошо работающую примерно в 100% случаев, даже если данных — терабайт. Примерно так(да, я знаю что int не бесконечен):
public int Avg(IEnumerable enumerable)
{
var collection = enumerable as ICollection;
if (collection != null)
{
return collection.Sum() / collection.Count;
}
var query = enumerable as IQueryable;
if (query != null)
{
return query.Sum()/query.Count();
}
var sum = 0;
var count = 0;
foreach (var i in enumerable)
{
sum += i;
count++;
}
return sum/count;
}
что мне делать с ExactSizeIterator я пока не понял (только не надо упоминать, что считалка среднего где-то встроена. Это пример)
Не очень удачный пример:
Вот пример на Rust.
Sum() — O(n), а коли так, мне видется, можно заодно и посчитать count.Вот пример на Rust.
Я этим примером хочу показать, что вы не знаете, когда выгоднее collection.Sum(), а когда foreach. Поэтому мало показать 2 варианта, надо показать как вы выбираете какой применить.
foreach эквивалентен вашему avg2, худший случай.
collection.Sum() — O(n), но коллекция по смыслу неленива (для ленивых есть другие интерфейсы), поэтому всё в оперативной памяти, никаких LazyRange оберток вокруг терабайтного файла тут быть не должно. ExactSizeIterator же подобного не обещает? То есть Avg1() не лучше foreach/avg2, можно выкинуть (или надеяться, что у ExactSizeIterator sum() как-то оптимизирован, что наивно).
query.Sum() — выполняется, скорее всего, на стороне БД (возможно O(1)) и мне не надо терабайт данных вычитывать. Вот тут Sum — очень выиграет, даже если в БД это O(n).
foreach эквивалентен вашему avg2, худший случай.
collection.Sum() — O(n), но коллекция по смыслу неленива (для ленивых есть другие интерфейсы), поэтому всё в оперативной памяти, никаких LazyRange оберток вокруг терабайтного файла тут быть не должно. ExactSizeIterator же подобного не обещает? То есть Avg1() не лучше foreach/avg2, можно выкинуть (или надеяться, что у ExactSizeIterator sum() как-то оптимизирован, что наивно).
query.Sum() — выполняется, скорее всего, на стороне БД (возможно O(1)) и мне не надо терабайт данных вычитывать. Вот тут Sum — очень выиграет, даже если в БД это O(n).
Всё равно, если ваш источник данных/коллекция не позволяют получить нужную сложность — ничего не поможет. Если поддерживают — в любом случае будет использоваться оптимизированный конкретный вариант.
Ничто не мешает доопределить свои варианты Iterator, обязывающие иметь нужную сложность конкретных методов, если вам хочется статически это гаратнтировать.
Из коробки есть только наиболее общие. По понятным причинам, все возможные сочетания засунуть в std просто не реально.
Ничто не мешает доопределить свои варианты Iterator, обязывающие иметь нужную сложность конкретных методов, если вам хочется статически это гаратнтировать.
Из коробки есть только наиболее общие. По понятным причинам, все возможные сочетания засунуть в std просто не реально.
В общем случае я не могу сделать итератор, который посчитает collection.Sum() / collection.Count() за один проход, для этого нужен foreach. Вы предлагаете 2 раза проходить или не пользоваться оптимизированы вариантами?
С подходом ExactSizeIterator в стд добавить все комбинаторные комбинации действительно нельзя (хотя и в шарпе тут не сильно удобно).
И я не хочу никого обязывать иметь сложность, для этого придется предрасчитывать показатели под мой алгоритм извне (а фактически реализовать на 99% подсчет среднего в итераторе). А если алгоритм поменяется — вызывающий код переписывать?
С подходом ExactSizeIterator в стд добавить все комбинаторные комбинации действительно нельзя (хотя и в шарпе тут не сильно удобно).
И я не хочу никого обязывать иметь сложность, для этого придется предрасчитывать показатели под мой алгоритм извне (а фактически реализовать на 99% подсчет среднего в итераторе). А если алгоритм поменяется — вызывающий код переписывать?
Предлагаю Average сделать, если нужно гарантировано за один проход.
В общем случае я не могу сделать итератор, который посчитает collection.Sum() / collection.Count() за один проход, для этого нужен foreach
Да что вы такое говорите.
collection.Aggregate(new { sum = 0, count = 0 }, (item, total) => new { sum = total.sum + item, count = total.count + 1 })На больших объемах GC расстраивается от такого, кстати. Спасает нормальный класс и изменяемые свойства.
> Да что вы такое говорите.
1) я про Rust и итератор, а не про Linq
2) я про collection.Sum() / collection.Count(), а не про (item, total) => new { sum = total.sum + item, count = total.count + 1 }.
3) Aggregate не оптимизируется вообще никак.
1) я про Rust и итератор, а не про Linq
2) я про collection.Sum() / collection.Count(), а не про (item, total) => new { sum = total.sum + item, count = total.count + 1 }.
3) Aggregate не оптимизируется вообще никак.
1. Коллекция останется в единственном экземпляре. Методы filter создают маленькие структурки с двумя ссылками на коллекцию-источник и предикат.
2. Я под «функциональными ништяками» имел в виду набор методов вроде filter, map, fold, first, nth, sum и т.д.
Если в C# — это «надстройка» над IEnumerable, то в Rust набор входит в трейт Iterator, наравне с move_next.
По ссылке монада Maybe. Аналог в Rust — тип Option.
2. Я под «функциональными ништяками» имел в виду набор методов вроде filter, map, fold, first, nth, sum и т.д.
Если в C# — это «надстройка» над IEnumerable, то в Rust набор входит в трейт Iterator, наравне с move_next.
По ссылке монада Maybe. Аналог в Rust — тип Option.
1. Должен дополнить: в Rust iterator adaptors (к коим как раз относится filter и проч.) ленивые. Их нужно пнуть, например, собрать в другую коллекцию или проитерировать (for… in ..). Иначе фактически ничего не произойдёт, а Rust покажет warning.
> Методы filter создают маленькие структурки с двумя ссылками на коллекцию-источник и предикат.
Посмотрите ответ выше про LazyRange.
> Аналог в Rust — тип Option.
нене, я спросил «как расширять», а не «есть ли аналог». Потому что Maybe то «наравне», а в Rust — фиксированный интерфейс.
Посмотрите ответ выше про LazyRange.
> Аналог в Rust — тип Option.
нене, я спросил «как расширять», а не «есть ли аналог». Потому что Maybe то «наравне», а в Rust — фиксированный интерфейс.
То, что описано в статье, это не функциональные ништяки, а extension methods. Причем их использование там крайне неудачное.
В даном случае стоило бы использовать Option/Maybe, а не неявную возможность null.
В даном случае стоило бы использовать Option/Maybe, а не неявную возможность null.
Это просто пример под руками. Весь Linq — это extension methods.
Ещё раз, новые функциональные ништяки в Rust добавить нельзя?
Ещё раз, новые функциональные ништяки в Rust добавить нельзя?
Весь Linq — это extension methods.Для Linq-подобных интерфейсов extension methods не нужны. Нужны они только если надо навесить это поверх легаси.
Что вы подразумеваете под «новые функциональные ништяки»?
> Нужны они только если надо навесить это поверх легаси.
Соглашусь, всю эту фигню с наследованием, traits, mixins можно заменить на старый добрый god object
Соглашусь, всю эту фигню с наследованием, traits, mixins можно заменить на старый добрый god object
Почему вы считаете extension methods единственным подходом?
В скала есть stream api. Кстати, тоже над легаси. И никаких extension methods.
В scala есть аналог extension methods, но в коллекциях он не используется ибо не нужно.
В Rust эти методы тоже в Iterable.
В скала есть stream api. Кстати, тоже над легаси. И никаких extension methods.
В scala есть аналог extension methods, но в коллекциях он не используется ибо не нужно.
В Rust эти методы тоже в Iterable.
Я не считаю его единственным подходом. Я считаю его подходом не хуже.
Хотя бы потому, что IEnumerable реализуется без наследования проще, чем интерфейс с полусотней методов. А «ибо не нужно» аргументом не считаю.
Хотя бы потому, что IEnumerable реализуется без наследования проще, чем интерфейс с полусотней методов. А «ибо не нужно» аргументом не считаю.
Чем же проще? У этого интерфейса всего 1 абстрактный метод.
Зато подход с extension methods не позволяет переопределять методы, например сделать sum по range константной сложности, как в Rust и Scala.
Зато подход с extension methods не позволяет переопределять методы, например сделать sum по range константной сложности, как в Rust и Scala.
Хотя бы потому, что IEnumerable реализуется без наследования проще, чем интерфейс с полусотней методов.На всякий случай уточню, что в Rust эта полусотня методов бесплатна :) Из обязательных для реализации только
next().М, кажется, я вас понял.
и всё, что «умеет итерироваться» — коллекции, адапторы и т.д. — будет поддерживать и новый ништяк.
trait AwesomeThing {
// ...
}
impl<T: Iterator> AwesomeThing for T {
// ...
}и всё, что «умеет итерироваться» — коллекции, адапторы и т.д. — будет поддерживать и новый ништяк.
В чем Go проще C#?
Тем что в нем нет исключений? Как результат у вас будет весь код усеян проверками ошибок. Что несомненно сделает его сложнее.
Исключения упрощают обработку ошибок.
Тем, что там нет LINQ, который экономит мое время и делает код понятнее?
А что на счет метапрограммирования? Где шаблоны или дженерики? Где работа с кодом как с данными (деревья выражений)? Как создавать удобные, универсальные API интерфейсы в Go? Или по вашему хорошее Api это сложно и ненужно?
То что в Go вырезали циклы или скобочки, это вообще никого не волнует. Это не делает язык проще.
Java, C# не просто так имеют все свои возможности. Каждая из них направлена на то, чтобы сделать код проще.
Почему по вашему, вырезав все эти улучшения можно получить лучший язык?
Мои пункты описывающие «простой» современный язык:
* Простая и надежная обработка ошибок. (Лучше исключений ничего не придумали)
* Работа с данными как в памяти, так и в других источниках (Лучше LINQ ничего не придумали)
* Простое использование многопоточности и асинхронности (У C# это довольно сложно получилось не смотря на все старания)
* Выполнение правила: если программа скомпилировалась — она работает (к сожалению мы еще далеки до этого)
* Возможность писать большие проекты. Пока вы пишите HelloWorld — можете рассуждать о простоте сколько хотите. Но как только количество строк исчисляется миллионами или десятками миллионов, все модные «простые» языки сдуваются. Остается Java да C# и нет альтернативы.
* Наличие тулзов и библиотек. Что лучше, простой язык или кнопка «Создать приложение»?
Тем что в нем нет исключений? Как результат у вас будет весь код усеян проверками ошибок. Что несомненно сделает его сложнее.
Исключения упрощают обработку ошибок.
Тем, что там нет LINQ, который экономит мое время и делает код понятнее?
А что на счет метапрограммирования? Где шаблоны или дженерики? Где работа с кодом как с данными (деревья выражений)? Как создавать удобные, универсальные API интерфейсы в Go? Или по вашему хорошее Api это сложно и ненужно?
То что в Go вырезали циклы или скобочки, это вообще никого не волнует. Это не делает язык проще.
Java, C# не просто так имеют все свои возможности. Каждая из них направлена на то, чтобы сделать код проще.
Почему по вашему, вырезав все эти улучшения можно получить лучший язык?
Мои пункты описывающие «простой» современный язык:
* Простая и надежная обработка ошибок. (Лучше исключений ничего не придумали)
* Работа с данными как в памяти, так и в других источниках (Лучше LINQ ничего не придумали)
* Простое использование многопоточности и асинхронности (У C# это довольно сложно получилось не смотря на все старания)
* Выполнение правила: если программа скомпилировалась — она работает (к сожалению мы еще далеки до этого)
* Возможность писать большие проекты. Пока вы пишите HelloWorld — можете рассуждать о простоте сколько хотите. Но как только количество строк исчисляется миллионами или десятками миллионов, все модные «простые» языки сдуваются. Остается Java да C# и нет альтернативы.
* Наличие тулзов и библиотек. Что лучше, простой язык или кнопка «Создать приложение»?
После вашего комментария я понял, что мой пост вобщем-то адресовался таким людям, как вы, у которых понятие «простота» кардинально расходится с моим.
Отвечу вам так — вы смотрите на вопрос «простоты» с позиции «простота для меня». Go смотрит на этот вопрос с позиции «простота для всех».
Вы можете как угодно сильно верить, что «исключения — самый простой способ обработки ошибок», но это будет справедливо лишь в рамках вашего опыта и вашей привычки. А уже для меня, к примеру, не справедливо — для меня код, написанный с исключениями, всегда сложнее читать и понимать где и как обрабатываются ошибки, и обрабатываются ли вообще. Не говоря уже о том, что 80% кода, который мне встречался, использует исключения не для обработки ошибок, а для «выкинуть и забыть об этом ненужном случае», что на практике приводит к некорректной и неправильной обработке последних.
Возможно у вас опыт работы сравним с опытом Кена Томпсона или Роба Пайка — тогда я не вправе дискутировать. Но авторы Go утверждают, что исключения и вправду имеют стимул к неверному их использованию, что приводит к увеличению накладной («привнесенной») сложности в результате. Я им верю, особенно учитывая то, что это 100% совпадает с моим личным опытом.
Но вообще да, я хотел написать пост, который бы людям с вот такими, как ваши, взглядами, немного делал понятнее, что подразумевается под «простотой» в Go. Но слишком мало конкретно этому посвятил внимания, мой промах.
Отвечу вам так — вы смотрите на вопрос «простоты» с позиции «простота для меня». Go смотрит на этот вопрос с позиции «простота для всех».
Вы можете как угодно сильно верить, что «исключения — самый простой способ обработки ошибок», но это будет справедливо лишь в рамках вашего опыта и вашей привычки. А уже для меня, к примеру, не справедливо — для меня код, написанный с исключениями, всегда сложнее читать и понимать где и как обрабатываются ошибки, и обрабатываются ли вообще. Не говоря уже о том, что 80% кода, который мне встречался, использует исключения не для обработки ошибок, а для «выкинуть и забыть об этом ненужном случае», что на практике приводит к некорректной и неправильной обработке последних.
Возможно у вас опыт работы сравним с опытом Кена Томпсона или Роба Пайка — тогда я не вправе дискутировать. Но авторы Go утверждают, что исключения и вправду имеют стимул к неверному их использованию, что приводит к увеличению накладной («привнесенной») сложности в результате. Я им верю, особенно учитывая то, что это 100% совпадает с моим личным опытом.
Но вообще да, я хотел написать пост, который бы людям с вот такими, как ваши, взглядами, немного делал понятнее, что подразумевается под «простотой» в Go. Но слишком мало конкретно этому посвятил внимания, мой промах.
Не говоря уже о том, что 80% кода, который мне встречался, использует исключения не для обработки ошибок, а для «выкинуть и забыть об этом ненужном случае», что на практике приводит к некорректной и неправильной обработке последних.
Отвечу вам так — вы смотрите на вопрос «простоты» с позиции «простота для меня». Go смотрит на этот вопрос с позиции «простота для всех».
Не попадайтесь на этот же крючёк.
Исключения и возвращаемые коды закрывают разные аспекты обработки ошибок. И те и те нужно уметь готовить. Я убеждён, что со временем исключения в Go появятся, когда будет осмысленна текущая философия языка.
Я убеждён, что со временем исключения в Go появятся, когда будет осмысленна текущая философия языка.
Она более, чем осмыслена еще 5 лет назад.
Вы, видимо, безоговорочно считаете отсутствие исключений признаком незрелости языка и непонимания глубины темы, игнорируя все слова авторов Go на эту тему.
Она более, чем осмыслена еще 5 лет назад.
5 лет назад Go только-только заявил о себе, он в принципе в то время не мог иметь законченный вид. Набор же нововведений в нём достаточно велик, чтобы требовать годы их проверки практикой.
Если Вы считаете, что можно на раз выдать идеальную большую систему без недостатков и недоработок, то Вы сильно ошибаетесь. Любая сложная система со временем эволюционирует. По-другому не бывает. И Go не раз ещё изменится.
В C нет исключений и я его считаю зрелым языком. Не читайте между строк.
Извините, но философия Go была фактически заложена в первый же день, и первые три года обсуждался и оттачивался дизайн языка, а не его философия.
5 лет назад Go только-только заявил о себе, он в принципе в то время не мог иметь законченный вид.Некоторые его аспекты — может быть. Но вот конкретно исключения — нет, решение об их применении было принято чуть не двадцать лет назад людьми, которые работали как с языками «зараженными» исключениями (Java, Python), так и с языками, где был выбор (C++) — причём в последнем случае выбор был сознательно сделан в пользу неиспользования исключений.
Вывод по результатам более, чем десятилетнего эксперимента на кодовой базе в десятки миллинов строк и тысячах разработчиков вполне однозначен: исключения послали в *опу. Правильно это сделали или неправильно — можно обсуждать долго. И обсуждалось это тоже долго. Потому что все понимали, что это решение можно принять только один раз:
For existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.Замените здесь «C++» на «Go» и вы поймёте почему даже если вдруг Go появятся исключения (ну там, если разработку вдруг передадут в Микрософт, мало ли что) их в Гугле использовать не будут — а значит пока разработка Go контролируется людьми из Гугла их в языке не будет тоже.
Вот и прекрасная иллюстрация того, почему «простота в Go» — это не «простота для всех», а «простота для Google».
Google — это авангард разработки ПО, они рождают новые технологии и языки, сталкиваются с проблемами и масштабами, с которыми другие столкнутся через 10 лет. Поэтому да, те, кому хватает для всех своих задач Perl-а и «всего за 3 часика написать деплой скрипт на баше» — те, конечно, будут считать точку зрения Google на проблематику разработки странной.
Google — это авангард разработки ПО, они рождают новые технологии и языки, сталкиваются с проблемами и масштабами, с которыми другие столкнутся через 10 лет.
Ну, мы же все понимаем, что это, гм, весьма тенденциозное заявление.
Но самое главное даже не в этом, а в том, что — даже если это так — большая часть разработчиков и через десять лет не столкнется с проблемами Google (потому что маленьких компаний больше чем больших), и, вероятно, им гугловский подход и не полезен?
А откуда Go берет информацию о «всех»? Из вашего описания выходит только что это «простота как ее понимают авторы языка», что от «простоты для меня» отличается только авторитетом.
Из реального опыта, как из команд внутри Google, так из всего прошлого опыта Пайка, Томпсона и ко. Не знаю, я себя не ставлю выше них, и легко могу поверить, что они о «хороших» и «плохих» практиках понимают гораздо больше меня.
А это все равно не имеет отношения ко всем, так же как олигократия и меритократия не имеет отношения к демократии. Это опыт конкретных людей в конкретном сообществе с конкретной культурой (точно так же как C# написан на основании реального опыта внутри MS). Дальше можно бесконечно обсуждать, правильно ли Пайк и Томпсон понимают простоту, или нет, но в итоге это сведется к апеляции к авторитету.
Ясно «простота для меня» и «простота для всех» — достаточно сложно определяемые понятия, но разницу в подходах достаточно точно описывают слоганы Perl'а и Python'а. «Простота для меня» — это есть больше одного способа сделать это, а «простота для всех» — это Должен быть один — и желательно только один — очевидный способ сделать это. Грубо говоря «простота для меня» — это сложность написания программы, а сложность для всех — это сложность чтения исходников незнакомой программы.
Понятно, что всегда есть некоторый конфликт между этими двумя вещами (чем меньше у тебя понятий в языке, тем длиннее оказывается программа, что тоже усложняет её чтение) и понятно, что иногда способы оказываются неудачными и «только один способ» меняется со временем (тот же Python изначально предлагал только один способ обработки командной строки, потом появился более очевидный способ, а теперь есть ещё более очевидный… но потом от одного из трёх всё-таки отказались), но среднем — чем больше тебе дают свободы тем проще и понятнее программу писать и тем сложнее её читать.
Хорошим примером является отказ разработчиков Go от Style Guide: пробелы расставляются так, как их расставит gofmt (и это не обсуждаются), а более сложные вещи описываются в мануалах и туториалах, а не в отдельно существющем Style Guide.
Понятно, что всегда есть некоторый конфликт между этими двумя вещами (чем меньше у тебя понятий в языке, тем длиннее оказывается программа, что тоже усложняет её чтение) и понятно, что иногда способы оказываются неудачными и «только один способ» меняется со временем (тот же Python изначально предлагал только один способ обработки командной строки, потом появился более очевидный способ, а теперь есть ещё более очевидный… но потом от одного из трёх всё-таки отказались), но среднем — чем больше тебе дают свободы тем проще и понятнее программу писать и тем сложнее её читать.
Хорошим примером является отказ разработчиков Go от Style Guide: пробелы расставляются так, как их расставит gofmt (и это не обсуждаются), а более сложные вещи описываются в мануалах и туториалах, а не в отдельно существющем Style Guide.
чем больше тебе дают свободы тем проще и понятнее программу писать и тем сложнее её читать.
Это утверждение недоказуемо.
Понимаете ли, удивительный факт, но увеличение числа понятий в естественных языках почему-то не усложняет чтение литературы; более того, это увеличение, напротив, позволяет выражать более сложные вещи проще. Почему вы считаете, что в языках программирования наоборот? (мы, естественно, говорим о чтении человеком, а не анализе компьютером)
я думаю правильнее сравнивать с чтением литературы на не родном языке. Так вот это как минимум в среднем становится сложнее, чем больше там разных слов и по разному составленных предложений
Так вот это как минимум в среднем становится сложнее, чем больше там разных слов и по разному составленных предложений
Только в том случае, если вы владеете языком ниже определенного уровня. Кстати, для родного языка тоже верно.
Только в том случае, если вы владеете языком ниже определенного уровня. Кстати, для родного языка тоже верно.Вы всегда можете пропустить какое-нибудь двадцать пятое значение одного из сотен тысяч слов, а всякие идеомы легко пролетают мимо людей, даже если вы являетесь носителем.
Разбираться во всех этих аллегориях, смаковать их — интересное времяпровождение, но оно ну никак не делает чтение книг проще.
Наоборот, книги, которые написаны просто обычно считаются скучными, пресными и неинтересными. Потому что их задача — как раз занять ваш мозг. При чтении же программ ваш мозг и так достаточно занят, совершенно нет никакого смысла загружать ещё и аллегориями языка.
Понимаете ли, удивительный факт, но увеличение числа понятий в естественных языках почему-то не усложняет чтение литературыУсложняет. Без вариантов. Сравните книжки для детей и взрослых.
Вам может быть приятнее читать книги, написанные богатым языком, интереснее, но «проще»? Ни в коем случае.
Сравните книжки для детей и взрослых.
Найти вам теорию относительности, изложенную в словах не длинее четырех букв?
Хотя, конечно, книжки для детей дошкольного (и иногда раннего школьного возраста) иногда используют упрощенный словарь, но вы правда хотите ориентироваться на программистов с таким уровнем развития?
Вам может быть приятнее читать книги, написанные богатым языком, интереснее, но «проще»? Ни в коем случае.
Именно проще. Введение нового понятия, более точно отражающего суть объекта или явления, упрощает изложение, а не усложняет его.
Попробуйте в книге по программированию заменить понятие «компилятор» на «программу, выполняющую перевод из языка высокого уровня в язык более низкого уровня». Везде. Количество понятий, несомненно, уменьшится, но упростится ли текст?
увеличение числа понятий в естественных языках почему-то не усложняет чтение литературы
Я тут, конечно, излишне категоричен. Правильнее добавить «в определенных пределах».
Ну давайте еще раз вернемся к обработке ошибок в Go.
(PS Хотя вот
- Есть ли в go механизм, гарантирующий невозможность скомпилировать код, не проверяющий возвращаемый
error, или хотя бы выдающий предупреждение об этом? - Правильно ли я понимаю, что ошибки «изнутри» языка (например, nil dereferencing) при этом кидаются как
panic, а не какerror?
(PS Хотя вот
defer — это круто)Есть ли в go механизм, гарантирующий невозможность скомпилировать код, не проверяющий возвращаемый error, или хотя бы выдающий предупреждение об этом?Нет, так как задача — не заставить человека сделать что-то, а сделать так, чтобы ошибка была видна. «Просто так» проигнорировать ошибку не получится, так как у вас программа не скомпилируется с сообщением о неиспользованной переменной. Всегда можно использовать «blank identifier» (подчёркивание), чтобы «проглотить» ошибку без жалоб, но это оставляет «следы» в коде, что, собственно, и требуется.Правильно ли я понимаю, что ошибки «изнутри» языка (например, nil dereferencing) при этом кидаются как panic, а не как error?Конечно. Как вы можете обработать nil dereference? И зачем? Это только разработчик может сделать увидев Stack Trace.
Нет, так как задача — не заставить человека сделать что-то, а сделать так, чтобы ошибка была видна. «Просто так» проигнорировать ошибку не получится, так как у вас программа не скомпилируется с сообщением о неиспользованной переменной. Всегда можно использовать «blank identifier» (подчёркивание), чтобы «проглотить» ошибку без жалоб, но это оставляет «следы» в коде, что, собственно, и требуется.
Я искренне подозреваю — поправьте меня, если это не так — что нет никакого способа отличить blank identifier на месте
error от blank identifier на месте любого другого возвращаемого значения. Ведь так?Конечно. Как вы можете обработать nil dereference? И зачем? Это только разработчик может сделать увидев Stack Trace.
Вот мы и пришли к тому, что в Go, фактически, два механизма обработки ошибок —
error и panic. Выводы из этого занятны, но, в общем случае, сводятся к тому, что обработка ошибок в Go концептуально не отличается от аналогичной в других языках с поддержкой exceptions.Вот мы и пришли к тому, что в Go, фактически, два механизма обработки ошибок — error и panic. Выводы из этого занятны, но, в общем случае, сводятся к тому, что обработка ошибок в Go концептуально не отличается от аналогичной в других языках с поддержкой exceptions.
Спеку языка не читай, делай желаемые для себя выводы :) Ок.
Что в спеке языка противоречит сказанному мной? Механизм обработки ошибок один?
panic нельзя перехватить или бросить пользовательским кодом?
Технически Вы правы, их два. Но один (исключения) искусственно ограничен в возможностях (отсутствие try приводит к тому что минимальная единица убиваемая panic-ом это функция, требование вызывать recover непосредственно в defer-функции усложняет использование вспомогательных функций для обработки исключений, соглашение о том, что panic никогда не должен покидать пределы своего пакета приводит к тому что окружающий код в принципе совершенно не готов обрабатывать исключения выкинутые вашим кодом). В результате этих ограничений второй механизм обработки ошибок вроде бы и есть, но в реальном коде пользоваться им получается очень ограниченно. Авторы Go не стесняются и сами его использовать для обработки ошибок в случаях когда нужно по-проще раскрутить стек вызовов, например при рекурсивном парсинге. В общем и целом по факту реально механизмов обработки ошибок в Go… может и не один, но и никак не два — скажем, их 1¼. :)
Важно, что их больше одного — и теперь, вместо того, чтобы получить единообразную (и централизованную в нужных мне границах) обработку ошибок, я должен делать это двумя разными способами.
в Go разделены ошибки и исключения.
Ошибки это предусмотренные состояния, файл не открылся, сеть упала и т.п., то что можно обработать и жить дальше.
Паника, это что-то что не входит в нормальную работу и после нее возможно стоит вообще оставить выполнение программы: выход за границу массив, ошибка выделения памяти, дедлоки и т.п. то есть то что в месте непосредственного вызова не решается, а перехватывается каким то совсем абстракным кодом, который грубо говоря залогирует панику, сдампит что сможет на диск и завершит приложение.
ЗЫ панику бывает ещё используют для раскручивания стека, но вот гугл от этого уходит кстати
Ошибки это предусмотренные состояния, файл не открылся, сеть упала и т.п., то что можно обработать и жить дальше.
Паника, это что-то что не входит в нормальную работу и после нее возможно стоит вообще оставить выполнение программы: выход за границу массив, ошибка выделения памяти, дедлоки и т.п. то есть то что в месте непосредственного вызова не решается, а перехватывается каким то совсем абстракным кодом, который грубо говоря залогирует панику, сдампит что сможет на диск и завершит приложение.
ЗЫ панику бывает ещё используют для раскручивания стека, но вот гугл от этого уходит кстати
Это все предположения и намерения. Фактически же для двух разных задач одно и то же поведение может быть как ожидаемой ошибкой, так и исключительной ситуацией. Это с одной стороны, а с другой, если мне по каким-то причинам нужно поймать все ошибочные состояния (исключительное состояние является ошибочным, но не обязательно наоборот), мне нужно обрабатывать n+1 разную ситуацию (где n — это количество потенциально ошибочных вызовов в скоупе).
в смысле предположения?
Если вы не обработаете err в случае открытия файла например программа все равно дальше упадет при обращении к nil, так что не вижу проблемы с разным поведением
в Go ошибки не ловят, ошибка это просто некое значение. Вот вы вызываете некий метод, у него есть error вы его обрабатываете, хотите выкинуть его наверх, выкидывайте.
Хотите возвращать прям свой объект ошибки (ну вот хотите), напишите defer который будет оборачивать err если он != nil
Я так понимаю вы хотели что-то такое:
func test() (b byte, err error)
{
if err = some_method; err != nil {
return
}
}
С одной стороны кода становится немного больше (на первый взгляд), но в коде сразу видно где бывают ошибки и что с ними происходит.
Ну и самое главное — «никто не обрабатывает исключения», именно для нивелирования этого и придумали всякие аннотации с информацией о том что метод что-то там генерирует и т.п.
А ещё в библиотеках нужно оборачивать исключения в свой тип исключений иначе его могут не правильно поймать. И в целом делать это правильно вызывая из своего кода чужой будет даже тяжелее чем обрабатывать error который приходит, как одно из значений.
В общем то как это сделано в Go не серебрянная пуля, собственно как и исключения, но причины у этого вполне обоснованные.
Если вы не обработаете err в случае открытия файла например программа все равно дальше упадет при обращении к nil, так что не вижу проблемы с разным поведением
в Go ошибки не ловят, ошибка это просто некое значение. Вот вы вызываете некий метод, у него есть error вы его обрабатываете, хотите выкинуть его наверх, выкидывайте.
Хотите возвращать прям свой объект ошибки (ну вот хотите), напишите defer который будет оборачивать err если он != nil
Я так понимаю вы хотели что-то такое:
func test() (b byte, err error)
{
if err = some_method; err != nil {
return
}
}
С одной стороны кода становится немного больше (на первый взгляд), но в коде сразу видно где бывают ошибки и что с ними происходит.
Ну и самое главное — «никто не обрабатывает исключения», именно для нивелирования этого и придумали всякие аннотации с информацией о том что метод что-то там генерирует и т.п.
А ещё в библиотеках нужно оборачивать исключения в свой тип исключений иначе его могут не правильно поймать. И в целом делать это правильно вызывая из своего кода чужой будет даже тяжелее чем обрабатывать error который приходит, как одно из значений.
В общем то как это сделано в Go не серебрянная пуля, собственно как и исключения, но причины у этого вполне обоснованные.
в смысле предположения?
В том смысле, что мы хотим, чтобы вызываемая библиотека работала так, и предполагаем, что программист так написал. Но в реальности мы не знаем, какие ситуации как он трактовал.
Если вы не обработаете err в случае открытия файла например программа все равно дальше упадет при обращении к nil, так что не вижу проблемы с разным поведением
Это если я результат использую, а не прокидываю дальше. Но даже если использую — я получу panic в другом месте, и happy debugging.
в Go ошибки не ловят, ошибка это просто некое значение.
В данном случае «ловить» = «обрабатывать».
Ну и самое главное — «никто не обрабатывает исключения», именно для нивелирования этого и придумали всякие аннотации с информацией о том что метод что-то там генерирует и т.п.
А это не надо нивелировать. Необработанное исключение долетит доверху и сложит приложение. Типичный fail early.
А ещё в библиотеках нужно оборачивать исключения в свой тип исключений иначе его могут не правильно поймать.
Зачем? Вы про какой-то конкретный язык говорите?
В общем то как это сделано в Go не серебрянная пуля, собственно как и исключения, но причины у этого вполне обоснованные.
Ну вот я этого обоснования пока не осознал. И, что важнее, я точно не считаю, что то, как сделано в Go — проще (или «меньше понятий», ага).
> я получу panic в другом месте, и happy debugging.
я вам на конкретный вопрос отвечал про ожидаемую ошибку. не хотите обрабатывать, не обрабатывайте, оно все равно упадет
> Необработанное исключение долетит доверху и сложит приложение
Так. в том то и цель чтобы не было не обработанных ошибок, для складывания есть panic.
> Зачем? Вы про какой-то конкретный язык говорите?
затем, что вы должны понимать что происходит иначе когда у вас закончится память, у вас исключения повалятся например в том же блоке catch хотя по идее не должны.
> И, что важнее, я точно не считаю, что то, как сделано в Go — проще (или «меньше понятий», ага).
а я кстати не говорил, что это проще, вообще обработка ошибок это то что на самом деле мало кто делает, потому что это скучно, сложно и не интересно и такая явность их возврата как раз для мотивации этой обработки и делалась
я вам на конкретный вопрос отвечал про ожидаемую ошибку. не хотите обрабатывать, не обрабатывайте, оно все равно упадет
> Необработанное исключение долетит доверху и сложит приложение
Так. в том то и цель чтобы не было не обработанных ошибок, для складывания есть panic.
> Зачем? Вы про какой-то конкретный язык говорите?
затем, что вы должны понимать что происходит иначе когда у вас закончится память, у вас исключения повалятся например в том же блоке catch хотя по идее не должны.
> И, что важнее, я точно не считаю, что то, как сделано в Go — проще (или «меньше понятий», ага).
а я кстати не говорил, что это проще, вообще обработка ошибок это то что на самом деле мало кто делает, потому что это скучно, сложно и не интересно и такая явность их возврата как раз для мотивации этой обработки и делалась
я вам на конкретный вопрос отвечал про ожидаемую ошибку. не хотите обрабатывать, не обрабатывайте, оно все равно упадет
Только не там, и не так, как ожидалось. Это плохо. А еще же бывают операции, которые никакого ожидаемого результата не возвращают.
Так. в том то и цель чтобы не было не обработанных ошибок, для складывания есть panic.
Это возвращает нас к вопросу «кто принимает решение о том, стоит ли складывать приложение или нет».
затем, что вы должны понимать что происходит иначе когда у вас закончится память
Так зачем для этого оборачивать исключения? Как раз наоборот, критические исключения трогать не надо, пусть летят себе вверх.
а я кстати не говорил, что это проще
Весь пост про это.
такая явность их возврата как раз для мотивации этой обработки и делалась
Вот только я не вижу, как это мотивирует обрабатывать ошибки. Всегда же можно поставить blank identifier.
> Весь пост про это.
Ну так пост то не мой. В целом я тоже приходил к выводу, что Go простой в обучении язык. Но аргументация в посте мне нравится.
> Это возвращает нас к вопросу «кто принимает решение о том, стоит ли складывать приложение или нет».
это зависит от того что произошло, если вас вызывают не правильно, говорят выдели мне 200гб памяти, а столько нет или обратись к -2 элементу в массиве это паника, это не нормально, программа написана не правильно, ее нужно переписывать и т.п.
если вы не можете достучаться до сервиса погоды, это нормально это ситуация, которая должна быть предусмотрена и обработана, если у вас http библиотека, вы возвращаете error если сервис запроса погоды вы ее обрабатываете и можете скрыть внутри себя (например вернуть старые данные или ничего не вернуть, а в фоне повторять попытки)
Ну вы же сами выделил критические исключения, кто решает критическое это исключение или нет?
> Всегда же можно поставить blank identifier.
мотивировать != заставить (это кстати можно притянуть к простоте — несмотря на строгость типизации, писать программу ты можешь как хочешь)
error в Go не содержит информации о месте где его создали и т.п., даже больше error это обычно глобальный immutable объект. так что вы можете получать 10, 100к и т.п. ошибок в секунду и у вас приложение будет работать, а вот если вы попробуете сгенерировать столько же исключений, будет грустно.
Ну так пост то не мой. В целом я тоже приходил к выводу, что Go простой в обучении язык. Но аргументация в посте мне нравится.
> Это возвращает нас к вопросу «кто принимает решение о том, стоит ли складывать приложение или нет».
это зависит от того что произошло, если вас вызывают не правильно, говорят выдели мне 200гб памяти, а столько нет или обратись к -2 элементу в массиве это паника, это не нормально, программа написана не правильно, ее нужно переписывать и т.п.
если вы не можете достучаться до сервиса погоды, это нормально это ситуация, которая должна быть предусмотрена и обработана, если у вас http библиотека, вы возвращаете error если сервис запроса погоды вы ее обрабатываете и можете скрыть внутри себя (например вернуть старые данные или ничего не вернуть, а в фоне повторять попытки)
Ну вы же сами выделил критические исключения, кто решает критическое это исключение или нет?
> Всегда же можно поставить blank identifier.
мотивировать != заставить (это кстати можно притянуть к простоте — несмотря на строгость типизации, писать программу ты можешь как хочешь)
error в Go не содержит информации о месте где его создали и т.п., даже больше error это обычно глобальный immutable объект. так что вы можете получать 10, 100к и т.п. ошибок в секунду и у вас приложение будет работать, а вот если вы попробуете сгенерировать столько же исключений, будет грустно.
* аргументация не нравится
это зависит от того что произошло, если вас вызывают не правильно, говорят выдели мне 200гб памяти, а столько нет [...] это не нормально, программа написана не правильно, ее нужно переписывать и т.п.
если вы не можете достучаться до сервиса погоды, это нормально это ситуация, которая должна быть предусмотрена и обработана,
Вот вы только что приняли два решения, которые ни на чем не основаны. Представьте, что у меня есть сервис, который раз в пять минут забирает погоду и обрабатывает ее. Так вот, я вполне могу считать, что ошибки «сервис погоды недоступен» и «на сервере не хватило памяти на обработку» эквивалентны — причем и в варианте «фиг с ним, через пять минут починится», и в варианте «критическая ситуация, падаем, зовем админа».
error в Go не содержит информации о месте где его создали и т.п., даже больше error это обычно глобальный immutable объект. так что вы можете получать 10, 100к и т.п. ошибок в секунду и у вас приложение будет работать, а вот если вы попробуете сгенерировать столько же исключений, будет грустно.
О, это внезапно performance-driven decision? Окей, я ничего не имею против такой аргументации, только что мне делать, если у меня никогда не будет столько ошибок (btw, если у вас столько ошибок — приложение надо класть, на мой вкус, почти в любой ситуации это флуд), зато мне важнее иметь стабильное приложение, которое при любой неожиданной ситуации падает и рестартует?
> Так вот, я вполне могу считать, что ошибки «сервис погоды недоступен» и «на сервере не хватило памяти на обработку» эквивалентны
ну так есть recover я же не os.Exit в конце концов написал. внутри своей либы общения с погодой я не могу ничего сделать с тем что нет памяти, а вот на уровне приложения уже можно решить что делать.
то есть вы запустили горутины общения с погодой она упала по памяти, вы в recover решили что нужно делать и сделали. (panic кстати не закрывает приложение, он только раскручивает стек вызовов горутины и если дошел до конца завершает её, приложение может условно даже не заметить этого)
Собственно в случае исключений будет та же самая логика.
> О, это внезапно performance-driven decision?
внезапно в мире есть не только черное и белое, а решения не обязательно принимаются лишь из-за чего-то одного, но производительность тут сыграла не последнюю роль, это факт.
> только что мне делать, если у меня никогда не будет столько ошибок
Не использовать Go? Пишите на чем-то скриптовом, с точки зрения скорости написание это будет быстрее, я например пишу на PHP.
Ни один язык не заменяет здравый смысл.
ну так есть recover я же не os.Exit в конце концов написал. внутри своей либы общения с погодой я не могу ничего сделать с тем что нет памяти, а вот на уровне приложения уже можно решить что делать.
то есть вы запустили горутины общения с погодой она упала по памяти, вы в recover решили что нужно делать и сделали. (panic кстати не закрывает приложение, он только раскручивает стек вызовов горутины и если дошел до конца завершает её, приложение может условно даже не заметить этого)
Собственно в случае исключений будет та же самая логика.
> О, это внезапно performance-driven decision?
внезапно в мире есть не только черное и белое, а решения не обязательно принимаются лишь из-за чего-то одного, но производительность тут сыграла не последнюю роль, это факт.
> только что мне делать, если у меня никогда не будет столько ошибок
Не использовать Go? Пишите на чем-то скриптовом, с точки зрения скорости написание это будет быстрее, я например пишу на PHP.
Ни один язык не заменяет здравый смысл.
ну так есть recover
Он работает только в одну сторону. И это два способа вместо одного.
Собственно в случае исключений будет та же самая логика.
… только в случае исключений у меня (почти никогда) нет альтернативных способо возврата ошибок, и я все обрабатываю единообразно.
Не использовать Go?
Вот и я об этом же.
Прочёл- а точнее вычитал и пост и каменты. Много про сравнение языков-ну просто вариация Луркморе-ту. Мало про сложность. Мало в посте — мало на хабре-мало в русНЭТЕ_ — пичаль
В том что ему не нужен .net framework?
Исключения не упрощают обработку ошибок, генерацию и игнорирование, да, а вот обработку нет. (ну и почитайте про panic)
Про дженерики вопрос давний, так скажем нет единого мнения как это должно выглядеть, сейчас это вполне решается кодогенерацией.
Больше чем в 10 языках из статьи нет LINQ, тоже самое про деревья выражений.
Вы путаете язык и «стандартную библиотеку», и тот же LINQ далеко не сразу появился.
Ну и чисто по букве правил — Go под них подходит
PS ну и это как-то странно, язык не простой, потому что в нем нет дженериков, динамической генерации кода во время выполнения и т.п.
Исключения не упрощают обработку ошибок, генерацию и игнорирование, да, а вот обработку нет. (ну и почитайте про panic)
Про дженерики вопрос давний, так скажем нет единого мнения как это должно выглядеть, сейчас это вполне решается кодогенерацией.
Больше чем в 10 языках из статьи нет LINQ, тоже самое про деревья выражений.
Вы путаете язык и «стандартную библиотеку», и тот же LINQ далеко не сразу появился.
Ну и чисто по букве правил — Go под них подходит
PS ну и это как-то странно, язык не простой, потому что в нем нет дженериков, динамической генерации кода во время выполнения и т.п.
Исключения не упрощают обработку ошибок, генерацию и игнорирование, да, а вот обработку нет. (ну и почитайте про panic)Ой да ну ладно вам. Это тот еще холивар: вы с легкостью найдете людей, которые считают что исключения это самый лучший способ; и с легкостью найдете людей, которые считают коды возврата ошибок замечательной штукой. Причем каждый, сука, встречается с обработкой ошибок в контексте разных задач и даже мозгами не думает, когда ему говорят что в другой задаче другой подход будет более адекватным.
Только вот в языке, в котором нету исключений нельзя их сделать руками; а вот в языке, в котором есть исключения можно легко сэмулировать коды возврата ошибок через тип Or[Result, Error]. Я лично встречался с обоими типами задач — там где оба подхода являются более адекватными.
Больше чем в 10 языках из статьи нет LINQ, тоже самое про деревья выражений.LINQ — это довольно примитивная вещь. IQueryProvider — это уже далеко не примитивная вещь (по сути я ни разу не видел людей, которые умеют это писать, но через эту штуку и работает C# -> SQL).
А деревья выражений — это по сути кодогенерация в runtime с доступом к рефлексии. Если сравнивать с рефлексией и динамическими вызовами, то компиляция деревьев выражений позволяет добиться скорости руками написанного кода (даже больше, потому что весь синтаксический сахар сразу уходит и пишется максимально производительный код).
Если сравнивать с чистой кодогенерацией, то деревья выражений позволяют чуточку больше (легкий доступ к метаданным уже работающей программы) и одновременно чуточку меньше (в edit-time у вас нету информации о сгенерированном коде, т.е. вы не можете притвориться что вы вот сейчас сгенерируете код, а потом просто и легко переименуете поле).
Вы путаете язык и «стандартную библиотеку», и тот же LINQ далеко не сразу появился.В C# язык и стандартная библиотека развиваются весьма параллельно, хотя разработчики компилятора предпочитают не завязываться на существование стандартной библиотеки.
А почему была выбрана версия Ruby 1.4? Она вышла в 1999 году.
Жалко в сравнениях нету какого-нибудь clojure, который целиком почти сам на себе написан.
На самом деле я даже сомневался, включать ли Haskell. Методики сравнения, особенно первые две, всё же более адекватный результат покажут на схожих (итеративных) языках.
Если вы пройдетесь по ключевым словам в scala, то увидите, что многие из них относятся к областям, не охваченным Go. Так что нет тут никакой «схожести». Есть только подгонка под результат. Ибо clojure настолько же императивный, как и scala.
Пост надо бы переименовать, он не то чтобы именно о Go — даже по графикам он не в лидерах :-)
Давайте возьмем, например, метрику «количество вопросов на SO по отношению к репам на GH»
Большинство приведенных в списке языков имеют такое большое число по одной очень простой причине — новички крайне редко пишут на Go, Rust, Haskell,… зато много пишут на Ruby, JS, C++, Java, C#,…
Вот если на Go появится много вакансий по миру, в него придут джуны, в общем, в случае успеха — через 5 лет можно будет еще раз посмотреть на эту метрику.
Говоря же о других метриках, по моему субъективному ощущению количество кейвордов говорит о том, что
1. Сколько же в этом языке кейвордов (удивительно)
2. К насколько широкому классу задач стараются приложить этот инструмент
3.… Привнесенная сложность
Да, Го действительно прост, но, на мой взгляд, он пока еще не прошел испытания злобным продакшеном в полной мере и хотя бы 3-4 мажорных версий. Возможно низкая сложность языка является следствием не окончательного понимания предметной области, не полной «вынужденной сложности»?
На данный момент ГО нерепрезентативен для таких вот исследований и его данные будут врать. Возможно даже в разы.
Большинство приведенных в списке языков имеют такое большое число по одной очень простой причине — новички крайне редко пишут на Go, Rust, Haskell,… зато много пишут на Ruby, JS, C++, Java, C#,…
Вот если на Go появится много вакансий по миру, в него придут джуны, в общем, в случае успеха — через 5 лет можно будет еще раз посмотреть на эту метрику.
Говоря же о других метриках, по моему субъективному ощущению количество кейвордов говорит о том, что
1. Сколько же в этом языке кейвордов (удивительно)
2. К насколько широкому классу задач стараются приложить этот инструмент
3.… Привнесенная сложность
Да, Го действительно прост, но, на мой взгляд, он пока еще не прошел испытания злобным продакшеном в полной мере и хотя бы 3-4 мажорных версий. Возможно низкая сложность языка является следствием не окончательного понимания предметной области, не полной «вынужденной сложности»?
На данный момент ГО нерепрезентативен для таких вот исследований и его данные будут врать. Возможно даже в разы.
Возможно низкая сложность языка является следствием не окончательного понимания предметной области, не полной «вынужденной сложности»?
Нет.
В этом и поинт статьи — сложность не является синонимом «продвинутости» или «зрелости», и в данном случае это ровно наоборот — действительно глубокое понимание предметной области.
Посмотрите видео выступлений Пайка на тему сложности Go — думаю, вы быстро перестанете считать авторов Go за недоучек )
Ну что вы, я, разумеется, не считаю авторов Go за недоучек, напротив — опытнейшие и матерые ребята. Однако все остальные языки так же писались отнюдь не дураками, которые тоже читали Брукса. И они почему-то пошли другим путем. И пока я не понимаю до конца почему — я и отношусь с некоторым недоверием к тому, что простота Го окончательна.
И пока я не понимаю до конца почему
Именно потому что сложность других языков на практике имела негативные последствия для разработки, и они проявились лишь с годами практического использования.
Тоесть, не будь других языков («которые писались отнюдь не дураками») или будь они достаточно хороши, Go не появился бы. Я потому и написал про «Go качнул маятник в другую сторону».
Сравнение конечно ни о чем, но забавное:)
Я бы еще добавил, что примитивная «простота» — не главное в языке. Это слишком однобокий критерий. Например, количество ключевых слов должно быть не большим и не маленьким, оно должно быть соответствующим внутренней логике языка. Количество роли не играет вообще. Применение одного и того же ключевого слова для разных целей (чем грешит тот же С++ ради «совмесимости с legacy кодом») не есть хорошо. Когда ключевыми словами обозначается все подряд — тоже плохо.
Главное в языке — внутренняя стройность и логичность, отсутствие «белых пятен» в плане фич. Я уже писал об этом здесь — если в языке чего-то нет, программисты все равно это сделают, но оно будет не органично встроено в язык, а прикручено сбоку изолентой (C++/Boost), что сильно отрицательно скажется на удобстве использования.
Я бы еще добавил, что примитивная «простота» — не главное в языке. Это слишком однобокий критерий. Например, количество ключевых слов должно быть не большим и не маленьким, оно должно быть соответствующим внутренней логике языка. Количество роли не играет вообще. Применение одного и того же ключевого слова для разных целей (чем грешит тот же С++ ради «совмесимости с legacy кодом») не есть хорошо. Когда ключевыми словами обозначается все подряд — тоже плохо.
Главное в языке — внутренняя стройность и логичность, отсутствие «белых пятен» в плане фич. Я уже писал об этом здесь — если в языке чего-то нет, программисты все равно это сделают, но оно будет не органично встроено в язык, а прикручено сбоку изолентой (C++/Boost), что сильно отрицательно скажется на удобстве использования.
Да, согласен, этот момент я не озвучил явно. Сравнение имеет смысл только языков, которые мы признаем как равнозначных по охвату и функционалу, принимая как данное, что на них решают достаточно схожий класс задач.
А «внутренняя стройность и логичность» — да, еще один критерий, но это ещё сложнее доказать и измерить )
А «внутренняя стройность и логичность» — да, еще один критерий, но это ещё сложнее доказать и измерить )
Половина поста — рассуждения о сложности, а дальше графики, которые к сложности не имеют отношения, да еще и само понятие сложности никак не формализовано.
Более того, совершенно неочевидно как выбор языка влияет на сложность. И как-то странно сравнивать без контекста задачи. Например нужно делать запросы в бд из кода приложения, в c# есть linq и сложность написания запросов будет сильно ниже, чем на том же go.
Более того, совершенно неочевидно как выбор языка влияет на сложность. И как-то странно сравнивать без контекста задачи. Например нужно делать запросы в бд из кода приложения, в c# есть linq и сложность написания запросов будет сильно ниже, чем на том же go.
Где сравнение с D? Пока тот же подсчет слов на нем выглядит проще некуда. На Go такая же краткость и лаконичность возможна?
import std.stdio, std.string;
void main() {
uint[string] dictionary;
foreach (line; stdin.byLine()) {
foreach (word; splitter(strip(line))) {
if (word in dictionary) continue; // Nothing to do
auto newlD = dictionary.length;
dictionary[word] = newlD;
writeln(newlD, '\t', word);
}
}
}
D пропустил, каюсь.
В Go читабельность ставится выше краткости. Во многом принципы Go созвучны с Zen Of Python.
По вашему примеру, посмотрите на golang.org/pkg/bufio/#example_Scanner_lines
В Go читабельность ставится выше краткости. Во многом принципы Go созвучны с Zen Of Python.
По вашему примеру, посмотрите на golang.org/pkg/bufio/#example_Scanner_lines
А можно пример подсчета слов на Go? Просто сравнить читабельность хочется.
Или может это отдельной статьей лучше сделать? Я думаю многим было бы интересно.
Или может это отдельной статьей лучше сделать? Я думаю многим было бы интересно.
Чуть-чуть примером ошибся, там же, рядом: golang.org/pkg/bufio/#example_Scanner_words
Если говорить о читабельности, то тут DSL и функциональные языки радостно показывают гулю.
Поржал, крутая статистика.
Так на заметку, в том же haskell вы считаете все скобки, а если посчитать только слова, 22 получается (haskell98 lexical structure).
Язык и правда простой, только вот многовато понтов. Давно ждал релиза одной базы на go (influxdb), зарелизили, баг на баге багом погоняет, базового функционала, который кстати был заявлен, нет. Зато 5700 звезд, 560 форков, и 125 разработчиков, и в результате за год работы пшик(только над этой версией).
Задумка хорошая, исполнение пока на двоечку, уж подумываю не самому ли написать, а то ждать поднадоело.
Если убрать весь шум: для простых утилит, язык вполне себе, для больших и сложных проектов я пока сильно сомневаюсь.
Так на заметку, в том же haskell вы считаете все скобки, а если посчитать только слова, 22 получается (haskell98 lexical structure).
Язык и правда простой, только вот многовато понтов. Давно ждал релиза одной базы на go (influxdb), зарелизили, баг на баге багом погоняет, базового функционала, который кстати был заявлен, нет. Зато 5700 звезд, 560 форков, и 125 разработчиков, и в результате за год работы пшик(только над этой версией).
Задумка хорошая, исполнение пока на двоечку, уж подумываю не самому ли написать, а то ждать поднадоело.
Если убрать весь шум: для простых утилит, язык вполне себе, для больших и сложных проектов я пока сильно сомневаюсь.
InfluxDB это да, ребята отожгли. Они его переписали чуть ли не с нуля, с 0.8 на 0.9, делая это в мастер ветке, причем.
Про большие и сложные проекты — посмотрите на Docker, достаточно большой.
Про большие и сложные проекты — посмотрите на Docker, достаточно большой.
Присоединяюсь к претензии. divan0, или убирайте из ключевых слов хаскеля операторы и скобки, или добавляйте их ко всем прочим языкам, а то нечестно выходит.
А расскажите мне про функцию max(a,b) на Go пожалуйста?
Четыре строчки, напишете сами?
да-да, вот по 4 строчки в каждом проекте под каждый требуемый тип данных.
и смотри потом не перепутай.
а еще max(list) в десятке вариантов, правда, зачастую не работающий для пустого list.
f.e.:
github.com/search?utf8=%E2%9C%93&q=language%3Ago+max&type=Code&ref=searchresults
и смотри потом не перепутай.
а еще max(list) в десятке вариантов, правда, зачастую не работающий для пустого list.
f.e.:
github.com/search?utf8=%E2%9C%93&q=language%3Ago+max&type=Code&ref=searchresults
а зачем делать специальную функцию под каждый тип?
что мешаешь по месту написать max так как вам нужно, собственно по вашей же ссылке находятся такие примеры:
max := 0 if some > max { max = some }
что мешаешь по месту написать max так как вам нужно, собственно по вашей же ссылке находятся такие примеры:
max := 0 if some > max { max = some }
Действительно, зачем вообще нужны функции, если их функционал можно руками встроить в каждое место?
Зачем нужны inline'ы? Просто пишите инлайн!
Зачем нужны inline'ы? Просто пишите инлайн!
ну смотрите — на абстрактном max(a, b) вроде и правда всё плохо, но давайте что-то более жизненное:
например есть список неких структур, например заказов, нужно найти дату последнего заказа:
var maxDate uint = 0
for o := range orders {
maxDate := max(maxDate, o.createdAt)
}
или так:
var maxDate uint = 0
for o := range orders {
if o.createdAt > maxDate {
maxDate = o.createdAt
}
}
в читаемости как по мне даже несколько выиграло + в отличии от первого варианта, во втором кол-во присваиваний будет равно кол-ву заказов только в худшем случае. про формирование списка массива значений я думаю и говорить не стоит
PS сейчас с читаемостью всё плохо в обоих случаях т.к. хабр удаляет пробелы и не дает делать подсветку кода
например есть список неких структур, например заказов, нужно найти дату последнего заказа:
var maxDate uint = 0
for o := range orders {
maxDate := max(maxDate, o.createdAt)
}
или так:
var maxDate uint = 0
for o := range orders {
if o.createdAt > maxDate {
maxDate = o.createdAt
}
}
в читаемости как по мне даже несколько выиграло + в отличии от первого варианта, во втором кол-во присваиваний будет равно кол-ву заказов только в худшем случае. про формирование списка массива значений я думаю и говорить не стоит
PS сейчас с читаемостью всё плохо в обоих случаях т.к. хабр удаляет пробелы и не дает делать подсветку кода
item, maxDate = orders.maxBy(o => o.createdAt)
Вообще max() обычно для другого:
maxDate := max([ o.createdAt for o in orders ])
maxDate := max([ o.createdAt for o in orders ])
а можете указывать на каких языках это примеры? c# по maxBy я вроде опознал (только там результат без maxDate будет?)
по поводу сформировать массив для для max — на вскидку такое должно быть либо в компилятор встроено либо что-то с ленивыми вычислениями, иначе у нас мало того что массив создастся так ещё и кучу элементов туда надо добавить будет.
по поводу сформировать массив для для max — на вскидку такое должно быть либо в компилятор встроено либо что-то с ленивыми вычислениями, иначе у нас мало того что массив создастся так ещё и кучу элементов туда надо добавить будет.
А вы у своих коллег спросите, вам ближе :)
(если я правильно все понял)
(если я правильно все понял)
Интересная тема — метрики сложности ЯП.
Первые две метрики точно не годятся для поставленной задачи, ведь самый простой язык по ним — Brainfuck!
6 операторов, да 2 условных оператора — истинно самый простой язык.
А третья метрика, вообще непонятно от чего зависит.
От библиотек, от компиляторов, сред программирования, ленивости программистов, репозиториев с либами, и их удобства.
Ну и от языка, конечно, тоже. В общем совсем не понятно что означает то или иное число.
Вообще, я думаю, из-за того, что сложность бывает разных типов, хорошую метрику построить будет проблематично.
Какой бы простой Go или Lua не был, в решении математических задач WolframAlpha или Matlab надерут ему задницу по простоте.
Ставлю на Эмпирику. Так что продолжаем холиварить!
Первые две метрики точно не годятся для поставленной задачи, ведь самый простой язык по ним — Brainfuck!
6 операторов, да 2 условных оператора — истинно самый простой язык.
А третья метрика, вообще непонятно от чего зависит.
От библиотек, от компиляторов, сред программирования, ленивости программистов, репозиториев с либами, и их удобства.
Ну и от языка, конечно, тоже. В общем совсем не понятно что означает то или иное число.
Вообще, я думаю, из-за того, что сложность бывает разных типов, хорошую метрику построить будет проблематично.
Какой бы простой Go или Lua не был, в решении математических задач WolframAlpha или Matlab надерут ему задницу по простоте.
Ставлю на Эмпирику. Так что продолжаем холиварить!
Первый толковый комментарий :)
Ну, нет, я вообще хотел в список включить только 3-4 схожих по охвату и подходам языка. Вот, согласитесь, сложность Go vs С++ неспроста кореллирует с количеством ключевых слов в Go и C++ :)
С эмпирикой всё понятно, но её не докажешь, аргументы «я чувствую это по своему опыту» не работают.
Первые две метрики точно не годятся для поставленной задачи, ведь самый простой язык по ним — Brainfuck!
Ну, нет, я вообще хотел в список включить только 3-4 схожих по охвату и подходам языка. Вот, согласитесь, сложность Go vs С++ неспроста кореллирует с количеством ключевых слов в Go и C++ :)
Ставлю на Эмпирику.
С эмпирикой всё понятно, но её не докажешь, аргументы «я чувствую это по своему опыту» не работают.
C++ проектировался очень давно, на основе еще более древнего Си (который сам по себе содержит массу архитектурных решений, которые в современном мире выглядят как ошибки), метапрограмминг на шаблонах С++ получился «случайно» и только потом язык стали ориентировать на эту возможность (но все равно там очень много случайных по сути решений).
Go проектировался с нуля значительно позже С++, с учетом огромного опыта проектирования других языков. Но, как уже было сказано, в Go нет очень многих фич.
Тут некоторое время назад была серия статей про Оберон, где автор утверждал что минимум фич (и ключевых слов заодно) это хорошо. Хотя по факту там нет почти ничего, кроме старого процедурного программирования.
В общем, сравнивая количество ключевых слов, языки сравнивать совершенно некорректно. Нужно рассматривать семантику языков, их суть.
Go проектировался с нуля значительно позже С++, с учетом огромного опыта проектирования других языков. Но, как уже было сказано, в Go нет очень многих фич.
Тут некоторое время назад была серия статей про Оберон, где автор утверждал что минимум фич (и ключевых слов заодно) это хорошо. Хотя по факту там нет почти ничего, кроме старого процедурного программирования.
В общем, сравнивая количество ключевых слов, языки сравнивать совершенно некорректно. Нужно рассматривать семантику языков, их суть.
Где же lisp?
Лисперам некогда в холивар, они считают сколько скобочек закрыть надо.
Боюсь большинство лисперов уже давно пользуются rainbow brackets + highlight matching brackets. Кстати, весьма удобная штука даже для C#. Так что лисперы свободны для холивара.
Максимальная вложенность, насколько понимаю, ограничена 16,777,216. А что дальше-то делать?
Как что? Зацикливать! Очень хотелось бы посмотреть на то как будет выглядеть код с соответствующим количеством пробелов. Не, я конечно понимаю, что троллинг, но в лиспе не принято делать глубокую вложенность, вместо этого предпочитают выделять функции, да и вообще думать мозгами.
P.S.: ничего, некоторые люди живут с ограничением в 128 вложенных if else if
P.S.: ничего, некоторые люди живут с ограничением в 128 вложенных if else if
А еще можно сравнить по объему спека
Метод сравнения по Stack Overflow говорит скорее о средней по популяции использующих язык склонности искать решения самостоятельно и не задавать (простых и глупых) вопросов.
Ты говоришь сложно о простых вещах и, создаётся впечатление, сам запутался в привнесённой тобой сложности.
Как мне кажется, понятия сложности и простоты в ЯП и программировании настолько субъективны, что неминуемо, стоит только задуматься над этой проблемой, появляются всё новые и новые языки программирования, призванные упростить сложность, неподвластную автору очередного шедевра.
Проблема, однако, в том, что упрощение в одном месте ведёт к ещё большему усложнению в других местах. Это хороший результат для исследовательского проекта — можно написать кучу диссертаций, но совершенно не пригодно для использования.
Поэтому, проблема понятна, но выбранная методика расчетов напоминает методику трёх «П» — пол, палец, потолок.
Лично я, для того, чтобы «определить сложность языка», да и чтобы изучить его, обычно переписываю на изучаемом языке какой-нибудь проект, например компилятор.
Чтобы изучить Активный Оберон, я переписал на нём Free Pascal Compiler, чтобы изучить Модулу-3 я переписал на ней компилятор Активного Оберона. Хотя на Go я не писал, но я переписывал компилятор для некоего подмножества языка на Активном Обероне, понятно, что читать исходный код на Go приходилось. Сейчас я начинаю переписывать компилятор Активного Оберона на C#, чтобы изучить его, использую для этого платформу Roslyn. И вот что я скажу по этому поводу — для меня код на C# читается и понимается легче, чем код на Go, да и пишется быстрее.
То есть C# как язык мне кажется проще Go. Более того, читая код Roslyn, мне показалось, что я читаю код на Активном Обероне.
То есть восприятие сложности/простоты языка снова упирается в субъективные ощущения.
Как мне кажется, понятия сложности и простоты в ЯП и программировании настолько субъективны, что неминуемо, стоит только задуматься над этой проблемой, появляются всё новые и новые языки программирования, призванные упростить сложность, неподвластную автору очередного шедевра.
Проблема, однако, в том, что упрощение в одном месте ведёт к ещё большему усложнению в других местах. Это хороший результат для исследовательского проекта — можно написать кучу диссертаций, но совершенно не пригодно для использования.
Поэтому, проблема понятна, но выбранная методика расчетов напоминает методику трёх «П» — пол, палец, потолок.
Лично я, для того, чтобы «определить сложность языка», да и чтобы изучить его, обычно переписываю на изучаемом языке какой-нибудь проект, например компилятор.
Чтобы изучить Активный Оберон, я переписал на нём Free Pascal Compiler, чтобы изучить Модулу-3 я переписал на ней компилятор Активного Оберона. Хотя на Go я не писал, но я переписывал компилятор для некоего подмножества языка на Активном Обероне, понятно, что читать исходный код на Go приходилось. Сейчас я начинаю переписывать компилятор Активного Оберона на C#, чтобы изучить его, использую для этого платформу Roslyn. И вот что я скажу по этому поводу — для меня код на C# читается и понимается легче, чем код на Go, да и пишется быстрее.
То есть C# как язык мне кажется проще Go. Более того, читая код Roslyn, мне показалось, что я читаю код на Активном Обероне.
То есть восприятие сложности/простоты языка снова упирается в субъективные ощущения.
От вашей статьи веет популизмом и даже троллингом.
Я не понимаю, как можно сравнивать языки из разных областей применения и когда между релизами некоторых из них уже прошло более 30 лет?
Google выпустил молоток. Давайте теперь сравнивать его с отвёртками, пилами, гаечными ключами и рубанками. Количество запросов по работе с рубанком на StackOverflow больше чем с молотком («вау!» — слышен возглас удивлённой публики), значит молотком от Google действительно проще пользоваться. У молотка одна ручка, у пилы две и они с разных сторон («вау!» — публика в экстазе), тут молоток так же показал себя с лучшей стороны.
В этом и заключается ваш троллинг: возьмём инструменты, которые применяются к решению разных задач и будем их сравнивать.
— Что лучше выбрать: Go или C++? А может мне Java подойдёт? Или надо Haskell изучать?
— Выбирать нужно то, что подойдёт для решения твоей задачи.
И оценивать инструмент по кол-ву keyword-ов и вопросов на StackOverflow — не лучшая затея.
Я не понимаю, как можно сравнивать языки из разных областей применения и когда между релизами некоторых из них уже прошло более 30 лет?
Google выпустил молоток. Давайте теперь сравнивать его с отвёртками, пилами, гаечными ключами и рубанками. Количество запросов по работе с рубанком на StackOverflow больше чем с молотком («вау!» — слышен возглас удивлённой публики), значит молотком от Google действительно проще пользоваться. У молотка одна ручка, у пилы две и они с разных сторон («вау!» — публика в экстазе), тут молоток так же показал себя с лучшей стороны.
В этом и заключается ваш троллинг: возьмём инструменты, которые применяются к решению разных задач и будем их сравнивать.
— Что лучше выбрать: Go или C++? А может мне Java подойдёт? Или надо Haskell изучать?
— Выбирать нужно то, что подойдёт для решения твоей задачи.
И оценивать инструмент по кол-ву keyword-ов и вопросов на StackOverflow — не лучшая затея.
Спасибо за критику по делу. Статья, конечно, популистская и холивары после тех графиков были неминуемы :) Но вообще, это ответ на комментарии из других статей, где меня доставали вопросами «а как ты докажешь, что Go проще C++». Впрочем, те же люди здесь сейчас вообще любое утверждение сводят к «а докажи? раз нет формального способа доказать 100% — значит ложь».
Это вы это понимаете, и я понимаю. Но реальность такова, что мне приходится сейчас увольняться из компании, потому что тим-лиды у нас ничего кроме С++ не знают, и знать не хотят, и пишут на нем всё — вопрос «выбора подходящего инструмента» там даже не стоит. Страдает продукт, страдает компания, страдают все. И судя, по комментариям, таких людей «одного языка» много.
Так что, даже если хотя бы один человек из-за таких популистских статей, решит взглянуть на Go и расширит круг своих познаний — я уже буду считать, что цель достигнута. Хотя, надоело конечно уже, план выполнен ))
— Выбирать нужно то, что подойдёт для решения твоей задачи.
Это вы это понимаете, и я понимаю. Но реальность такова, что мне приходится сейчас увольняться из компании, потому что тим-лиды у нас ничего кроме С++ не знают, и знать не хотят, и пишут на нем всё — вопрос «выбора подходящего инструмента» там даже не стоит. Страдает продукт, страдает компания, страдают все. И судя, по комментариям, таких людей «одного языка» много.
Так что, даже если хотя бы один человек из-за таких популистских статей, решит взглянуть на Go и расширит круг своих познаний — я уже буду считать, что цель достигнута. Хотя, надоело конечно уже, план выполнен ))
Может оно и к лучшему что вы увольняетесь из этой компании, в которой «такие» тимлиды. Например, в островке правильно подошли к выбору инструмента для своей задачи оценив все за и против. Вот такие подходы к оценке инструмента мне нравятся.
вообще вы странно считали.
Взял пример из 1 таблицы — количество ключевых слов.
Го — 25
правда, не подсчитано количество ключевых слов-операторов.
А их в Го — 48.
В Хаскеле действительно 55, но вместе с операторами.
То есть 28 ключевых слов + 27 ключевых слов-операторов.
Так что будьте внимательными при построении таблиц
Взял пример из 1 таблицы — количество ключевых слов.
Го — 25
правда, не подсчитано количество ключевых слов-операторов.
А их в Го — 48.
В Хаскеле действительно 55, но вместе с операторами.
То есть 28 ключевых слов + 27 ключевых слов-операторов.
Так что будьте внимательными при построении таблиц
А, да? Нет, операторы я не хотел учитывать, конечно же.
Вообще, уже понял, что было ошибкой считать «побольше языков». Изначально хотел сравнить только группу из 4-5 императивных языков, которые я рассматриваю, как универсальные кроссплатформенные языки для серверного софта — C++, Go, Python, Java, Ruby, но потом решил, что появится масса вопросов «А где язык X?» и решил добавить и остальные, тем более, что это было относительно просто.
Вообще, уже понял, что было ошибкой считать «побольше языков». Изначально хотел сравнить только группу из 4-5 императивных языков, которые я рассматриваю, как универсальные кроссплатформенные языки для серверного софта — C++, Go, Python, Java, Ruby, но потом решил, что появится масса вопросов «А где язык X?» и решил добавить и остальные, тем более, что это было относительно просто.
Вот почему на хабре по С++, Rust, C#, Java и т.п. как правило серьезные статьи по делу, а про Swift, Go и наверное JS большинство статей состоят из сплошной воды и восхищения языком?
Типа «смотрите какой swift офигенный, потому что в нем split и форматирование строк есть», «50 хаков на моем любимом js, первым из которых записан тернарный оператор» или «херня ваш rust, вот есть Go его сделали в гугле, поэтому он клевый и простой а еще потому что про него меньше вопросов задают на stack overflow»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сложно о простоте Go