После вашего комментария я понял, что мой пост вобщем-то адресовался таким людям, как вы, у которых понятие «простота» кардинально расходится с моим.
Отвечу вам так — вы смотрите на вопрос «простоты» с позиции «простота для меня». Go смотрит на этот вопрос с позиции «простота для всех».
Вы можете как угодно сильно верить, что «исключения — самый простой способ обработки ошибок», но это будет справедливо лишь в рамках вашего опыта и вашей привычки. А уже для меня, к примеру, не справедливо — для меня код, написанный с исключениями, всегда сложнее читать и понимать где и как обрабатываются ошибки, и обрабатываются ли вообще. Не говоря уже о том, что 80% кода, который мне встречался, использует исключения не для обработки ошибок, а для «выкинуть и забыть об этом ненужном случае», что на практике приводит к некорректной и неправильной обработке последних.
Возможно у вас опыт работы сравним с опытом Кена Томпсона или Роба Пайка — тогда я не вправе дискутировать. Но авторы Go утверждают, что исключения и вправду имеют стимул к неверному их использованию, что приводит к увеличению накладной («привнесенной») сложности в результате. Я им верю, особенно учитывая то, что это 100% совпадает с моим личным опытом.
Но вообще да, я хотел написать пост, который бы людям с вот такими, как ваши, взглядами, немного делал понятнее, что подразумевается под «простотой» в Go. Но слишком мало конкретно этому посвятил внимания, мой промах.
Да, было бы точнее, но я не вижу способа как это сделать реальным. Есть проект сравнения языков на основе задач с Rosetta Code — Go там, кстати, тоже жжот — arxiv.org/pdf/1409.0252v4.pdf — но, сложность таких сравнений мне не под силу, увы.
Конечно мне знаком принцип «correlation doesn't imply causation», но логика этого сравнения озвучена — при прочих равных, более сложный язык будет вызывать больше вопросов. Хотя понимаю, что там факторов, которые дают погрешность в ± 100% — целая пачка.
В любом случае — это лучшее, что я придумал на тему «как использовать социальные данные для приблизительной оценки сложности языков».
При этом я буду анализировать языки, которые достаточно универсальны для решения большого круга задач, имеют достаточно большое сообщество и информация о них доступна. Экзотику вроде Brainfuck мы не рассматриваем.
Сложно ответить — я не пишу на C#, и мне самому интересно послушать версии, насколько показатели по нему кореллируют или нет с реальными ощущениями. Подозреваю, что в третьем случае, у C# такой «отрыв» из-за того, что он больше в энтерпрайзе используется, и не особо в open-source сообществе.
Ничего себе. Даже будучи оптимистически настроенным касательно Go на Android/iOS, уж никак не ожидал подобной истории так быстро (особенно учитывая совсем свежий статус gomobile).
Разрабатывается обычный golang package, никаких дополнительных рекомендаций. Экспортные методы будут доступны из android.
А в «обычный golang package» всё же нужно импортить что-то из gomobile и вызывать какие-то функции или это может быть уже существующий пакадж, который писался ещё до того, как gomobile был в мыслях?
Вы правда пишите комментарий к функции isEmpty() «это функция проверяет что все поля объекты пусты», а к функции toString() «это функция переводит внутреннее представления объекта в строку»?
А, вы об этом. Нет, если функция не предназначается для экспорта (не «публичная», не доступная пользователю либу, не будет показана в API), то комментарий можно не писать, golint ругаться не будет. Хотя, если это немного сложнее, чем isEmpty и одним именем/названием тут не обойтись (к примеру, разбирает какой-то кусок протокола) — то да, для таких функций, даже не «публичных», пишу. Даже если это немного избыточно кажется, пишу, потому что это слишком просто, чтобы этого не сделать, а в будущем кому-то потенциально спасет время и нервы.
Скажите честно вы хотя бы пролистывали «Чистый код»?
Полностью не читал, но неоднократно встречал озвученные там идеи в статьях и видео, в целом, солидарен, конечно же со многими озвученными вещами, но на практике пока не встречал кода, который подходит под определение. А вы, полностью следуете этой книге?
Самодокументируемый код — это ещё большая редкость, чем покрытый тестами код. К сожалению, большая часть кода, который я вижу и видел, не подходит под это, поэтому комментарии — особенно с учетом наличия докогенератора по ним — всё остаются хорошей практикой. А
Кстати, из личного опыта — до Go «написание документации» это была второстепенная задача «на потом», и докогенерация из комментов — лишь один из возможных подходов. Боюсь, что «плохие программисты» на самом деле не пишут комменты для докогенератора не потому, что они наизусть знают «Code complete», а потому что для них это тоже второстепенная задача.
Go этот вопрос (создания документации) сводит к простой привычке однострочного коммента перед функцией. Ни больше, ни меньше. Но, наверное людям, не писавшим на Go я так и не смогу объяснить, как это когда язык и тулинг непосредственно влияет на программистов и на результирующий код.
Я рад, если все проекты, даже маленькие side-проекты на дотнете могут похвастаться минимально приемлимой документации и язык/инфраструктура стимулирует программистов это делать. Серьезно, значит MS тут ухватила нить и пошла правильным путем конкретно в этом вопросе.
Но вопрос документации — это лишь один из кирпичиков, и .NET для моих задач не подходит ну вот прямо ни разу.
Но даже после беглого ознакомления становится понятно, что «не выходит из него серебрянная пуля»
И не должна.
И понравился он мне совсем не теми вещами, которые вы описали в статье.
Это не моя статья, это перевод. Хабру надо как-то сделать более различимым, видимо.
где в качестве преимуществ указаны вещи, которые, как я знаю, гарантировано сделаны лучше в других платформах (будем честными, документация и деплой — это не про язык),
Извините, но это про язык. Когда вы начинаете писать на другом языке — вы принимаете и его тулинг и экосистему. В С/С++ тоже можно было всегда делать статические бинарники, но по факту их очень редко делают.
Ну и то, что я писал уже не раз тут в комментариях — речь не о конкретных «вещах, сделанных лучше», которые вы считаете «гарантированно» лучше в других языках. Речь в совокупности всех вместе взятых факторов, которые приводят к тому, что можно получать конечный результат быстрее и качественнее в общем случае. Когда мне расписывают, как чудесна кодогенерация в .Net и как хорошо она показывается в IDE — это чудесно, но какой мне от этого толк, если я хочу писать кроссплатформенный софт?
Речь о финальном результате, а не о частностях. А так, оригинальная статья — это ответ на недавнюю неадекватную критику Go — и фразой в конце про 1-800-GO-SWITCH автор явно дал понять, что не скрывает популистского наклона статьи. :)
Я не понимаю, как наличие потенциальных, но не обязательных возможностей может порождать стимул не писать комментарии.
Я всё таки хочу научиться доносить этот момент, мне он кажется достаточно важным.
Скажите, вы понимаете как в экономике формируется кривая спроса? Я просто хочу параллели провести, но для них нужно понимание основ микроэкономики.
А вы тоже согласны с тем, что простота и сложность никак не влияют на то, пишут или не пишут доки, а те, кто это утверждает (включая авторов Go) — просто фанатики? )
На GOPATH завязан тулинг (go get/go build/etc) — вам дают много удобств, ускоряющих разработку и просят лишь одну вещь — выберите директорию, где будет лежать код.
Ну вам же объяснили и даже доказали. Чтобы стать полезной и нужной фичей, необходимо и достаточно попасть в go-мир. Все остальное априори от лукавого.
Ничего не хочу сказать против или за go, но divan0 типичный фанатик, со всеми вытекающими.
Сами перекрутили, сами обвинили. Зачем?
В этом треде я пытаюсь донести одну вещь — люди всегда идут путем наименьшего сопротивления. Все понимают, что доки это хорошо, но в языке А для достижения результата «хорошие доки всегда» нужно приложить Х усилий и опыта, а я в языке Б — 10*Х. И мой поинт в том, что в итоге хорошие доки будут с большей вероятностью в проектах на языке А.
И поймите одну вещь — я не придумываю объяснения ради объяснений. Я смотрю на себя, на свой опыт, на те причины, по которым я не писал раньше документацию или сводил обработку ошибок к «выкинуть эксепшн». Хотя про все докогенераторы и правила я знал. Но Go поменял правила игры, и не только для меня, поэтому я и пытаюсь это описать максимально открыто и понятно, отталкиваясь только от реальности, а не от теоретических измышлений.
Если вы не хотите понимать о чем речь, не хотите вникнуть, и вам проще проще назвать меня «фанатиком» — пожалуйста, ваше право, но ценности дискуссии это не добавляет.
Отвечу вам так — вы смотрите на вопрос «простоты» с позиции «простота для меня». Go смотрит на этот вопрос с позиции «простота для всех».
Вы можете как угодно сильно верить, что «исключения — самый простой способ обработки ошибок», но это будет справедливо лишь в рамках вашего опыта и вашей привычки. А уже для меня, к примеру, не справедливо — для меня код, написанный с исключениями, всегда сложнее читать и понимать где и как обрабатываются ошибки, и обрабатываются ли вообще. Не говоря уже о том, что 80% кода, который мне встречался, использует исключения не для обработки ошибок, а для «выкинуть и забыть об этом ненужном случае», что на практике приводит к некорректной и неправильной обработке последних.
Возможно у вас опыт работы сравним с опытом Кена Томпсона или Роба Пайка — тогда я не вправе дискутировать. Но авторы Go утверждают, что исключения и вправду имеют стимул к неверному их использованию, что приводит к увеличению накладной («привнесенной») сложности в результате. Я им верю, особенно учитывая то, что это 100% совпадает с моим личным опытом.
Но вообще да, я хотел написать пост, который бы людям с вот такими, как ваши, взглядами, немного делал понятнее, что подразумевается под «простотой» в Go. Но слишком мало конкретно этому посвятил внимания, мой промах.
В любом случае — это лучшее, что я придумал на тему «как использовать социальные данные для приблизительной оценки сложности языков».
А в «обычный golang package» всё же нужно импортить что-то из gomobile и вызывать какие-то функции или это может быть уже существующий пакадж, который писался ещё до того, как gomobile был в мыслях?
Нет.
А, вы об этом. Нет, если функция не предназначается для экспорта (не «публичная», не доступная пользователю либу, не будет показана в API), то комментарий можно не писать, golint ругаться не будет. Хотя, если это немного сложнее, чем isEmpty и одним именем/названием тут не обойтись (к примеру, разбирает какой-то кусок протокола) — то да, для таких функций, даже не «публичных», пишу. Даже если это немного избыточно кажется, пишу, потому что это слишком просто, чтобы этого не сделать, а в будущем кому-то потенциально спасет время и нервы.
Полностью не читал, но неоднократно встречал озвученные там идеи в статьях и видео, в целом, солидарен, конечно же со многими озвученными вещами, но на практике пока не встречал кода, который подходит под определение. А вы, полностью следуете этой книге?
Самодокументируемый код — это ещё большая редкость, чем покрытый тестами код. К сожалению, большая часть кода, который я вижу и видел, не подходит под это, поэтому комментарии — особенно с учетом наличия докогенератора по ним — всё остаются хорошей практикой. А
Go этот вопрос (создания документации) сводит к простой привычке однострочного коммента перед функцией. Ни больше, ни меньше. Но, наверное людям, не писавшим на Go я так и не смогу объяснить, как это когда язык и тулинг непосредственно влияет на программистов и на результирующий код.
А скажите, почему весь внутренний код, который на моем опыте писали Python-программисты — без документации? Плохие программисты попались?
Но вопрос документации — это лишь один из кирпичиков, и .NET для моих задач не подходит ну вот прямо ни разу.
И не должна.
Это не моя статья, это перевод. Хабру надо как-то сделать более различимым, видимо.
Извините, но это про язык. Когда вы начинаете писать на другом языке — вы принимаете и его тулинг и экосистему. В С/С++ тоже можно было всегда делать статические бинарники, но по факту их очень редко делают.
Ну и то, что я писал уже не раз тут в комментариях — речь не о конкретных «вещах, сделанных лучше», которые вы считаете «гарантированно» лучше в других языках. Речь в совокупности всех вместе взятых факторов, которые приводят к тому, что можно получать конечный результат быстрее и качественнее в общем случае. Когда мне расписывают, как чудесна кодогенерация в .Net и как хорошо она показывается в IDE — это чудесно, но какой мне от этого толк, если я хочу писать кроссплатформенный софт?
Речь о финальном результате, а не о частностях. А так, оригинальная статья — это ответ на недавнюю неадекватную критику Go — и фразой в конце про 1-800-GO-SWITCH автор явно дал понять, что не скрывает популистского наклона статьи. :)
Я всё таки хочу научиться доносить этот момент, мне он кажется достаточно важным.
Скажите, вы понимаете как в экономике формируется кривая спроса? Я просто хочу параллели провести, но для них нужно понимание основ микроэкономики.
Если речь идёт о коде под конкретный проект, то посмотрите на gb: habrahabr.ru/post/259967
Сами перекрутили, сами обвинили. Зачем?
В этом треде я пытаюсь донести одну вещь — люди всегда идут путем наименьшего сопротивления. Все понимают, что доки это хорошо, но в языке А для достижения результата «хорошие доки всегда» нужно приложить Х усилий и опыта, а я в языке Б — 10*Х. И мой поинт в том, что в итоге хорошие доки будут с большей вероятностью в проектах на языке А.
И поймите одну вещь — я не придумываю объяснения ради объяснений. Я смотрю на себя, на свой опыт, на те причины, по которым я не писал раньше документацию или сводил обработку ошибок к «выкинуть эксепшн». Хотя про все докогенераторы и правила я знал. Но Go поменял правила игры, и не только для меня, поэтому я и пытаюсь это описать максимально открыто и понятно, отталкиваясь только от реальности, а не от теоретических измышлений.
Если вы не хотите понимать о чем речь, не хотите вникнуть, и вам проще проще назвать меня «фанатиком» — пожалуйста, ваше право, но ценности дискуссии это не добавляет.