Считается ли документация хорошим дизайном библиотеки?
Да, рекомендую попробовать писать документацию.
В Go, кстати, для этого достаточно просто написать комментарий над функцией, начинающийся с имени функции — и готовая удобная HTML-страничка готова или доступна через godoc.org.
А вот и пошли аргументы в стиле «сначала добейся».
Нет, просто интересна предметная дискуссия. Если мне кто-то рассказывает о языке Х, то я полагаю, что человек имеет с ним опыт. Если же это «не пробовал, но порицаю», то ценность такой дискуссии нулевая.
Нет. Если совместимости все равно нет, тогда зачем вы к ней аппелируете?
Я к ней аппелирую, потому что это один из моментов, по которым принимаются решения. Уже писал, что дизайн языка — это не черное и белое, и не бинарный выбор «очевидно, что это должно быть так» и «не так». Неужели это и вправду нужно разъяснять 15 комментариев подряд?
Я говорил про комментарий. То, что он должен исходит из его определение.
По определению самолёт — должен летать. Это не повод критиковать наличие шасси у самолёта. Это нужно и это удобно. Так же и тут.
Вам верность лингвистическому определению или практическая польза важна? Сколько вы пишете на Go, кстати?
Про Go, в котором комментарии были заменены на метаданные.
Не хочу снова холиварить насчёт неиспользуемого импорта.
Да нечего тут холиварить — это исключительно привычка. Вы давно на Go пишете? Просто у практически всех эта фича становится любимой — она *гарантирует*, что у вас не будет кучи лишних импортов, вы уверены, что их не будет ни в чьем коде и т.д. — это big deal на самом деле, ворнинги такой эффект не дадут. А во время отладки поставить _ или удалить импорт — оказывается совсем несложно, особенно, если используется goimports, который сам добавляет/удаляет импорты и его вешают на save-хук, вместо go fmt (он drop-in замена go fmt по сути).
Но я призываю поддерживать тех, кто вытягивает всяческие кривульки из тени под лампы прожекторов и говорит ясно и честно: это не лучшее решение.
Тут я только за. Но за объективную дискуссию, а не за «ну это же очевидно, что это плохо, потому что плохо» :) А если уж и обсуждать дизайн, то это должны делать люди, которые, как минимум, знакомы с Go.
Я, кстати, тоже думаю, что если бы потребность в go generate заложили до релиза 1.0, то, возможно, было бы иное решение (хотя мне сложно предположить — какое, нынешний дизайн go generate реально всех устраивает и отлично выполняет свою функцию). Но один из посылов дизайна было — «it must fit well with the existing go command», и это, конечно, важный фактор.
Спасибо. Комментаторы на хабре, конечно, иногда отбивают это желание, но я, все-таки, получаю некоторое удовольствие — переводить мне легко, идею Go я очень хорошо чувствую нутром (она совпадает с моими собственными взглядами), плюс переводы заставляют внимательней углубляться даже в темы, которые, казалось бы я для себя давным давно уже закрыл. Вобщем, сплошная польза ) А если ещё и кому-то это полезней (не все ж, наверное, англоязычные ресурсы легко читают), то тем более хорошо.
Знаете, что мне нравится в Go, так это то, что я могу быть уверен, что его ядром занимаются люди в разы умнее и опытнее меня. Я бы себя посчитал крайне наивным, если бы стал заявлять, что я «вижу очевидный минус, который авторы Go просто не заметили или не додумались». Мне это, кстати, помогло очень быстро пройти эти этапы «WTF, да какое право они имеют мне говорить, что неиспользуемый импорт — это ошибка!». И я очень благодарен такой «радикальности» многих решений Go — они, за меня, заставили меня писать код лучше и чище, не игнорировать ошибки, писать тесты и так далее. Зная, что именно так и задумывалось, я считаю это бесценным — умение смотреть далеко вперед и помогать программистам стать лучше с помощью дизайна языка и тулинга.
К чему это всё я. К тому, что если появится надобность дописать ещё что-то в «специальные комментарии», а уж тем более, если не раз — то и авторы Go и коммьюнити — в котором тоже немало очень толковых людей — среагируют, обсудят и предложат более оптимальное решение, найдя наиболее правильный компромисс. С существующей системой пропозалов и open-source модели Go такой вклад может сделать любой, вобщем-то — авторы Go лишь будут следить, чтобы изменения следовали основной идее Go. Вобщем, чего-чего, а мысль о том, что в Go в комментариях появится каша из всего чего угодно, и всем будет на это наплевать — я не верю. Слишком хорошо знаю людей, которые за этим стоят — в том числе, по личному общению на конференциях.
Ну там примеры из жизни были — «я хочу написать вот именно такую функцию именно таким способом».
Ну а Golang себя не позиционирует, как язык для микросервисов — это, скорее, полезный побочный эффект, что маленькие сервисы писать удобно и легко и Go зачастую начинаются использовать в компаниях, с написания или переписывания отдельных сервисов. Как раз Go «позиционируется» для масштабов Google — большие кодовые базы, большие группы людей и т.д.
Я так понимаю, отдельный синтаксис/сущность — это усложнение грамматики, усложнение языка, лишнее и не нужное. Его плюсы никак не перевешивают минусов. Плюс нарушается прямая совместимость — код «с новым синтаксисом» нельзя будет собрать на предыдущей версии (это не критично, гарантируется только обратная совместимость, но всё же, если можно этого избежать, лучше избегать).
Кроме того, специальные комментарии в Go давно использовались, и выполняют свою функцию отлично, никаких проблем с ними нет.
Называйте вещи своими именами. Это просто _плохая практика_.
Это здорово, что вы знаете что такое «плохие практики». И уверен, вы не слепо навешиваете ярлыки, без понимания их сути.
Расскажите, пожалуйста, какие проблемы ждут Go-программистов из-за такого дизайна go generate?
Я не знаю, как вы умудряетесь новой сущностью ломать совместимость, наверное вы избранный.
Раз избранный, то поясню — новая сущность в Go 1.5 == ошибка компиляции в Go 1.4.
Не за что.
А это плохо.
Неважно, что это не имеет проблем, побочных эффектов, великолепно выполняет свою функцию на практике и облегчает реальный труд, решая реальную задачу. Главное навесить ярлык. Ясно, спасибо.
Для начала хочется сказать, что тип rune для int32 вообще вызывает странное ощущение.
rune — это специальный тип данных для работы с Unicode. Формально это алиас на int32, но выделен в отдельный тип, так как представляет конкретную сущность — «букву», или же codepoint.
В Go специальные комментарии были с самого начала — для тегов сборки. Мне не известно о каких-либо проблемах с этим, напротив — подход convention over configuration себя показал в Go с хорошей стороны. Видимо поэтому, решили для go generate и не плодить новые сущности и фичи языка, а воспользоваться проверенным и удобным способом.
В том-то и дело, что они лишь кажутся такими, потому что вы смотрите с перспективы других языков. Я полностью согласен, что есть хорошие и плохие практики, и «специальных комментарии» — одна из как-бы не очень хороших практик, хотя я сходу не вспомню, где это действительно приводило к проблемам.
Но возьмите в пример такую вещь, как shebang — казалось бы, тоже самое. Но, как показала практика многих десятков лет — это удобное и рабочее решение.
Аналогично и с go generate — мне не встречался ни один случай, где факт того, что go generate описывается комментариев приводил к какой-либо проблеме или путанице. Если вы пишете на Go и для вас это стало проблемой — расскажите, интересно же.
По факту, это практично и удобно, это обратно совместимо и не приводит к непоняткам.
Так что, если не вешать раньше времени ярлыки, а попробовать в деле — то всё окажется не таким, как кажется поначалу.
Ну Make вам никто не мешает использовать. До go generate, в основном, подобная задача решалась именно мейкфайлами, да и сейчас, некоторые их, по привычке, используют с Go. Хотя большая часть проектов, безусловно, стараются, чтобы workflow был стандартным — go generate/build/test.
И, как написано в статье, если вы «заставите» всех пользователей вашего пакета регенерировать файлы на каждом билде — с большой вероятностью, они получат ошибку, так как у них могут быть не установлены нужная программа-генератор. Все таки, это функция автора(ов) пакета.
Всё так, но, смею полагать, это больше не о бекграунде, а о личностных характеристиках. У нас недавно был выпуск подкаста о Go с джавистами, очень здорово пообщались. И вот, джавист со стажем рассказывает о Go, очень неплохо получилось имхо :)
Я, к примеру, не вижу плюсов от «введения новой сущности», зато ломается совместимость. Плодить новую сущность на каждый чих — это именно то, чем Go не является. Если хочется такого, то лучше выбирать другие языки. Если всё таки есть реальные проблемы с go generate или с комментариями — велкам в коммьюнити, выслушают, напишете пропозал, и ваше решение, раз оно реально лучше — имплементируют. Всё просто.
Считается ли документация хорошим дизайном библиотеки?
Да, рекомендую попробовать писать документацию.
В Go, кстати, для этого достаточно просто написать комментарий над функцией, начинающийся с имени функции — и готовая удобная HTML-страничка готова или доступна через godoc.org.
Документация. Это же библиотека. а не конструкция языка.
Нет, просто интересна предметная дискуссия. Если мне кто-то рассказывает о языке Х, то я полагаю, что человек имеет с ним опыт. Если же это «не пробовал, но порицаю», то ценность такой дискуссии нулевая.
Я к ней аппелирую, потому что это один из моментов, по которым принимаются решения. Уже писал, что дизайн языка — это не черное и белое, и не бинарный выбор «очевидно, что это должно быть так» и «не так». Неужели это и вправду нужно разъяснять 15 комментариев подряд?
По определению самолёт — должен летать. Это не повод критиковать наличие шасси у самолёта. Это нужно и это удобно. Так же и тут.
Вам верность лингвистическому определению или практическая польза важна? Сколько вы пишете на Go, кстати?
В Go не заменяли комментарии на метаданные.
Да нечего тут холиварить — это исключительно привычка. Вы давно на Go пишете? Просто у практически всех эта фича становится любимой — она *гарантирует*, что у вас не будет кучи лишних импортов, вы уверены, что их не будет ни в чьем коде и т.д. — это big deal на самом деле, ворнинги такой эффект не дадут. А во время отладки поставить _ или удалить импорт — оказывается совсем несложно, особенно, если используется goimports, который сам добавляет/удаляет импорты и его вешают на save-хук, вместо go fmt (он drop-in замена go fmt по сути).
Тут я только за. Но за объективную дискуссию, а не за «ну это же очевидно, что это плохо, потому что плохо» :) А если уж и обсуждать дизайн, то это должны делать люди, которые, как минимум, знакомы с Go.
Я, кстати, тоже думаю, что если бы потребность в go generate заложили до релиза 1.0, то, возможно, было бы иное решение (хотя мне сложно предположить — какое, нынешний дизайн go generate реально всех устраивает и отлично выполняет свою функцию). Но один из посылов дизайна было — «it must fit well with the existing go command», и это, конечно, важный фактор.
К чему это всё я. К тому, что если появится надобность дописать ещё что-то в «специальные комментарии», а уж тем более, если не раз — то и авторы Go и коммьюнити — в котором тоже немало очень толковых людей — среагируют, обсудят и предложат более оптимальное решение, найдя наиболее правильный компромисс. С существующей системой пропозалов и open-source модели Go такой вклад может сделать любой, вобщем-то — авторы Go лишь будут следить, чтобы изменения следовали основной идее Go. Вобщем, чего-чего, а мысль о том, что в Go в комментариях появится каша из всего чего угодно, и всем будет на это наплевать — я не верю. Слишком хорошо знаю людей, которые за этим стоят — в том числе, по личному общению на конференциях.
Нет, прямая совместимость не гарантируется, но при обсуждении различных дизайнов, там где можно её не ломать, лучше не ломать. Так поняли?
Не очень понимаю, почему язык должен вам что-то, что пришло лично вам в голову, а не создателям языка. Может объясните, чем ваше мнение тут весомей?
Согласен. Только непонятно, про какой вы язык говорите.
Ну а Golang себя не позиционирует, как язык для микросервисов — это, скорее, полезный побочный эффект, что маленькие сервисы писать удобно и легко и Go зачастую начинаются использовать в компаниях, с написания или переписывания отдельных сервисов. Как раз Go «позиционируется» для масштабов Google — большие кодовые базы, большие группы людей и т.д.
Кроме того, специальные комментарии в Go давно использовались, и выполняют свою функцию отлично, никаких проблем с ними нет.
Это здорово, что вы знаете что такое «плохие практики». И уверен, вы не слепо навешиваете ярлыки, без понимания их сути.
Расскажите, пожалуйста, какие проблемы ждут Go-программистов из-за такого дизайна go generate?
Раз избранный, то поясню — новая сущность в Go 1.5 == ошибка компиляции в Go 1.4.
Не за что.
Неважно, что это не имеет проблем, побочных эффектов, великолепно выполняет свою функцию на практике и облегчает реальный труд, решая реальную задачу. Главное навесить ярлык. Ясно, спасибо.
rune — это специальный тип данных для работы с Unicode. Формально это алиас на int32, но выделен в отдельный тип, так как представляет конкретную сущность — «букву», или же codepoint.
habrahabr.ru/post/269887
Но возьмите в пример такую вещь, как shebang — казалось бы, тоже самое. Но, как показала практика многих десятков лет — это удобное и рабочее решение.
Аналогично и с go generate — мне не встречался ни один случай, где факт того, что go generate описывается комментариев приводил к какой-либо проблеме или путанице. Если вы пишете на Go и для вас это стало проблемой — расскажите, интересно же.
По факту, это практично и удобно, это обратно совместимо и не приводит к непоняткам.
Так что, если не вешать раньше времени ярлыки, а попробовать в деле — то всё окажется не таким, как кажется поначалу.
И, как написано в статье, если вы «заставите» всех пользователей вашего пакета регенерировать файлы на каждом билде — с большой вероятностью, они получат ошибку, так как у них могут быть не установлены нужная программа-генератор. Все таки, это функция автора(ов) пакета.