Все люди не умеют писать код

    В преддверии Moscow Python Conf ++ мы поговорили с Никитой Соболевым, CTO компании «Мы делаем сервисы», о глобальной проблеме управления сложностью кода в разрезе развития языков программирования. А также о том, почему тут со временем ситуация становится только хуже. Плюс расспросили, зачем ему потребовалось создавать собственный линтер.




    — Расскажи в двух словах о себе и своей работе

    Я технический директор «Мы делаем сервисы». Озвучивая название компании, я обычно задаю вопрос: «Как вы думаете, чем мы занимаемся?». По факту мы специализируемся на веб-разработке: frontend и backend для корпоративных клиентов. А еще мы работаем по собственной методологии, которую совершенствуем параллельно с развитием компании — Repeatable Software Development Process (RSDP).

    — На Moscow Python Conf ++ ты будешь рассказывать, в том числе, про собственный линтер. Как твоя работа связана с аудитом и управлением сложностью кода?

    В целом у нас есть два основных направления: непосредственно разработка и все, что вокруг нее: консалтинг, составление требований и, в частности, аудит, в процессе которого я вижу очень много чужого кода. Код абсолютно разный: и тот, что сейчас в разработке, и legacy, который никто никогда уже не будет исправлять; и код, который пишут специалисты заказчика, и тот, что они заказали на стороне. И во всех вариантах кода очень много проблем: одинаковых и разных.

    — Ты будешь выступать перед разработчиками именно на Python. Имеет ли Python какие-то особенности с точки зрения управления сложностью кода?

    Конечно!

    Во-первых, все языки с динамической типизацией в большей степени страдают от неоправданной сложности, как минимум из-за отсутствия дополнительного контекста при чтении кода. А еще тебе позволено больше грязи.

    Во-вторых Python активно развивается. У него появляются новые синтаксические элементы, новые концепции и модули в стандартные библиотеки, которые ломают все, что было до этого.

    — Насколько в Python все плохо? Есть ведь и другие активно развивающиеся языки, например, JavaScript, который как раз за это часто критикуют. В JavaScript ситуация лучше?

    Нет. Я бы даже сказал, что в плане сложности у Python все достаточно хорошо относительно других языков. В JavaScript действительно все плохо по одной простой причине: в коде проекта JS смешиваются сразу несколько сущностей, которые не относятся к самому языку — сторонние плагины и библиотеки, которые используются для сборки проекта. Например, если использовать Webpack, появляется возможность писать функцию `import()`, которая подгружает модули асинхронно. Получается, что сборщик засовывает какие-то свои внутренности в ваш язык программирования, и в итоге вообще непонятно, что происходит.

    Управлять сложностью тяжело, когда язык меняется от установки Babel или плагинов к нему. А чтобы понять, как они работают, нужно следить за стандартами языка, за конкретной реализацией и т.д.

    В Python ситуация намного лучше. Язык развивается достаточно планомерно, и у этого развития есть понятные вехи. В нем нельзя кардинально поменять синтаксис двумя строчками в конфиге. И это все-таки backend, к которому мы привыкли предъявлять более высокие требования, чем к frontend. Однако, по моему мнению, в Python довольно много новых изменений, которые ломают то, что было раньше, принося сомнительную пользу.

    — То есть с развитием языка все становится хуже?

    Если вспомнить, что появился AsyncIO — по сути второй язык внутри Python — конечно, сложность возросла очень сильно. По факту сейчас есть два абсолютно независимых языка программирования с похожим синтаксисом: Python и Python + AsyncIO. То есть Python как сущность стал сложнее ровно в два раза, потому что у него появилось два отдельных потомка, работающих по разным правилам.

    Мнение о том, что это разные языки программирования, не популярно. Однако когда ты просишь противников этого мнения, например, запустить асинхронную функцию из синхронного кода — у них не получается. Библиотеки тоже абсолютно разные. Хочешь использовать синхронную библиотеку для работы с БД — пожалуйста. А хочешь асинхронную — ее нет.

    Но в Python, на котором писали пять лет назад, особо ничего не поменялось и даже наоборот, появились инструменты, которые позволяют упрощать код, например, это аннотации и проверка типов.

    — Влияет ли на управление сложностью то, что в программировании сейчас довольно много людей со слабой технической базой?

    Конечно. Для таких людей даже специальный язык программирования придумали. Называется Go. Я не шучу. Действительно, целью создания языка Go была попытка вовлечения в написание кода студентов и стажеров Google, которые не могут освоить C++. Python им не подходил по производительности, нужно было что-то иное, и в Google придумали Go. Как оказалось, очень много людей готовы на нем писать, потому что он очень простой. Но какой ценой достигнута эта простота? Нам дают не нормальный язык программирования, а его очень урезанную версию — в нем нет практически никаких сложных концептов by design. Нет дженериков, нет такого понятия, как исключения и т.д. И поклонников такого подхода много.

    Но есть и другие разработчики, и для них является проблемой то, что есть языки, в которых нет баланса: ты можешь делать простые вещи просто, а сложные ты не можешь делать вообще никак. Или хотя бы через боль — приходится бороться с инструментом, чтобы что-то сделать. Вот здесь, мне кажется, и кроется проблема управления сложностью.

    — Какие типовые проблемы есть у чужого кода?

    Обычно они разделены на две части.

    Первая — проблемы, связанные с тем, что люди не могут договориться о том, где ставить условные запятые. Ты читаешь один код и видишь запятые в одном месте, переключаешься на другой файл — и видишь запятые в другом месте. Это усложняет восприятие, как если читать книги, напечатанной в одном месте жирным шрифтом, а в другом — курсивом. Это отвлекает от содержания, поскольку мозгу приходится распознавать, что это разный способ написания одного и того же.

    Когда ты поправил синтаксис, начинаешь обращать внимание на семантику, потому что люди пишут концептуально по-разному. К сожалению, нет возможности договориться на этом уровне — нельзя прийти к соглашению, что мы решаем вот такие задачи так, а вот такие — эдак. Невозможно изначально покрыть все кейсы. Этот процесс происходит во время code review непосредственной задачи: когда разработчику объясняют, почему его решение не может быть принято. Если практика code review применяется и ревьюверы хорошие, они отсекают кривые решения и проблем в коде нет. Но обычно мы приходим на аудит туда, где такой процесс не налажен. И проблемы семантики и архитектуры решать намного сложнее, потому что их даже сформулировать и определить для себя порой непросто.

    — И как это выглядит на практике?

    Например, одну и ту же проблему люди могут решать в шаблонах, во вьюхах или в моделях. И нет общепринятого понимания, где конкретно эта задача должна быть решена: никакой документации или паттернов, применимых конкретно к этому проекту (например, здесь мы используем толстые модели и всю логику засовываем в них, а вот тут — тонкие; хорошо это или плохо, сейчас не важно, но мы так договорились).

    — В чем ты видишь главную причину того, что эти проблемы вообще существуют?

    Все люди не умеют писать код.

    Это тезис расшифровывается следующим образом: проблема в том, что мы — люди. И нам вообще очень сложно написать что-то структурированное и логичное. А здесь у нас есть еще и два разнотипных получателя. Во-первых, это человек, который будет этот код читать, и во-вторых, это машина, которая должна его исполнять. Код для машины должен создаваться в соответствии с критериями производительности, потреблением памяти и процессорного времени, а код для человека — на основе принципов читаемости, понятности и т.д. Это две противоположные задачи. И человек, который по сути не может полноценно решить даже одну из них, вынужден решать обе противоречивые задачи одновременно.

    — Но ведь использование разных паттернов программирования — это по сути и есть инженерный поиск? Неужели это плохо?

    Конечно, инженерный поиск важен и нужен. Но он тоже должен быть управляем. Перед каждой подобной задачей необходимо выставлять четкие критерии и ограничения: по затраченному времени, по бизнес-требованиям, по инженерным практикам и инструментам.

    Я гораздо чаще наблюдаю творческий поиск. Там таких ограничений нет, валидации полученных результатов тоже. Качество — как в современном искусстве — не поддается измерению.

    Практически все клиенты, которые обращаются к нам за аудитом, страдают от типичной ситуации: кто-то им что-то сделал, они наняли разработчика, чтобы как-то развить решение, но тот пришел и развел руками: «Я вообще не знаю, что здесь делать, давайте все заново перепишем». Будет ли хорошо, если переписать? Не будет. Когда ты решаешь заново переписать, наступаешь ровно на те же грабли: ты доверяешь задачу другому разработчику, который делает другие ошибки, но в итоге все получается точно так же.

    — Нужен какой-то другой подход?

    Да. Во время аудита мы стараемся найти причину проблем с кодом: не почему кто-то взял и раздул модуль до состояния, что он скролится с трудом, а почему изначально было принято неправильное решение. И мы пытаемся автоматизировать или максимально упростить принятие правильных решений в рамках заданных ограничений.

    Дам небольшой inside к докладу. У всех есть понимание того, что код состоит из строчек — это самая простая сущность, из которой он может состоять. Каждая строчка может быть написана как

    x = 1,

    а может быть как

    x = Math.median(forecast_data) if forecast_data else compute_probability(default_model).

    Между этими двумя строчками очень большая разница, потому что первую ты легко понимаешь, а во второй сконцентрировано очень много логики. Нужно в голове ее выполнить параллельно с интерпретатором. Поэтому нужно начинать управлять тем, как ты пишешь код, с управления одной строчкой кода. Дальше строчка превращается в более сложные концепции — функции, классы, модули и т.д. Но правила, которые ты принимаешь, должны быть едины.

    В итоге мы не занимаемся тем, что запрещаем делать многие вещи. Потому что управление — это про вменяемые запреты.

    — Попадались ли тебе какие-нибудь забавные вещи в чужом коде?

    Безусловно. У меня даже есть репозиторий, где я собираю такие примеры кода.

    Самый страшный пример, который я видел, продемонстрировал мне, что внутри цикла на сотню итераций можно определить функцию. Если честно, когда я на это смотрел, у меня внутри интерпретатор сломался. Я догадывался, но не знал, что так можно.

    Был случай, когда мы видели в коде очень много смешных комментариев. Кто-то жаловался на жизнь, на работу, были и те, кто писал: «Понимаю, что пишу ерунду, но заказчик меня заставляет». Однако заказчики обычно не заставляют тебя писать плохой код. Они просят решить свою задачу, а уж какой код ты там напишешь, им вообще до лампочки.

    — Линтеры, code review — не спасают?

    У меня два ответа. Да, спасают. Нет, не спасают. Спасает, если четко следовать тем правилам и предписаниям, которые дают тебе прошаренные линтеры (те, кто за тебя делают много черновой работы: проверяют функции на сложность, семантику кода и т.п.). Этот элемент должен быть блокирующим. Нельзя просто иногда запускать линтер, чтобы посмотреть на результат. Если ты провалил эти правила, то ты вообще не должен выпускать код в продакшн.

    Но по факту — не спасают. Потому что те проекты, которые это используют, встречаются редко.

    Меня, кстати, часто спрашивают: а как это внедрить? И я отвечаю: очень просто, в CI ставишь строчку — проверить мой код — и если она падает, все, ты внедрил. Осталось только все отрефакторить. Благо, сейчас есть автоформатеры и возможность рефакторить код файл за файлом. Следующий вопрос традиционно: как объяснить бизнесу, что это важно?

    — Есть ли какой-то общий ответ на этот вопрос?

    Для каждого случая ответы разные, поэтому в общем случае сформулировать сложно (вам надо подумать о том, о сем…). Но обычно компании, которые обращаются с этой проблемой, идут именно с технической стороны. Т.е. технари просят нас, как людей, которые умеют и про бизнес поговорить, и про технику понимают, объяснить это бизнесу в их конкретном случае. При такой постановке задачи это очень просто работает. Когда ты приходишь, уже все плохо, и все это понимают. Разговор с бизнесом начинается так: «Вы, наверное, думаете, что ваши программисты сидят и ничего не делают?». И бизнес кивает головой. А ты говоришь, что дело не в этом. Программисты — замечательные ребята, которые пытаются решить ваши проблемы. Но без комплексного подхода к управлению проектом все сваливается в хаос, и это нормально.

    И мы предлагаем вместе придумать правила, позволяющие избежать определенных проблем. Считаем стоимость внедрения разных штук, а потом оцениваем реальные (свершившиеся) потери от того, что таких штук пока нет. Например, программисты целый месяц правили баг, которого не существует или который можно найти за 30 секунд, если использовать определенный подход и инструмент. Цифры хорошо убеждают.

    — В итоге это административная проблема?

    Конечно. Я убежден, что программисты хотят писать хороший код. Но возникают разные препятствия. Кто-то не умеет по причине неопытности. Кто-то потерял мотивацию, потому что всем все равно. Кто-то не знает, что конкретно является хорошим кодом по причине, скажем так, творческих метаний. На кого-то давят — он хочет и может писать, но ему говорят, что это должно быть завтра. А вместо того, чтобы выстраивать партнерские отношения с бизнесом и объяснять, почему завтра этого не будет (или если будет, то потом еще три дня надо будет править), он делает абы как. А такие партнерские отношения интересны и самому бизнесу. Ему же нужно сделать так, чтобы это работало долго и было дешево в обслуживании.

    То есть здесь все вопросы решаемы: нет неразрешимых противоречий.

    — Есть же code style — PEP 8. Это не помогает быстро понять, что же хорошо?

    В плане запятых — помогает. Но что толку, если ты поставишь запятые правильно, а все остальное будет плохо?

    — Не хватает какой-то общеизвестной более высокоуровневой штуки?

    В теории есть некие лучшие инженерные практики. Но они либо неизвестны, либо игнорируются. Когда ты спрашиваешь, почему разработчик не следовал такой практике, он говорит, что вроде слышал, что это хорошая тема, но код и так работает. Когда код перестает работать, ты спрашиваешь понял ли он, откуда вообще взялась соответствующая лучшая практика и зачем ее соблюдать? Нет, не понял. Он считает, что просто ошибся.

    Довольно сложно объяснять человеку, что ошибаться — это нормально. Все ошибаются, мы все люди. Но лучшая инженерная практика как раз и была придумана, чтобы спасти тебя от ошибки или защитить от последствий. Т.е. это некий инструмент техники безопасности, как на предприятиях. Только написан он не кровью, а угробленным временем и деньгами.

    Вообще наша недостижимая глобальная задача — автоматизировать code review, чтобы сам Python (если мы говорим про наш случай) знал, как нужно его писать. Это должен быть инструмент, который поставляет не только возможности, но и ограничения для разработчиков.

    — Зачем ты вообще разрабатываешь линтер? Нельзя ли использовать (или развивать) существующие?

    На самом деле мы так и делаем. Наш линтер по факту является плагином для Flake8. Просто позиционируем его именно как полноценный инструмент, а не просто плагин.

    Почему Flake8, а не Pylint? Pylint делает очень много того, чего именно линтер делать не должен. Например, в нем реализовано очень большое количество проверок на тип, хотя типами должен заниматься type checker. Плюс он выдает очень большое количество ошибок, которых на самом деле нет. А еще мне не нравится его документация, и меня пугает его собственная реализация ast. Он сложен в настройке. Давая возможность конфигурации, ты позволяешь людям сделать неправильный выбор. Поэтому у нас задача — сделать инструмент, который нельзя конфигурировать. Чтобы ты его поставил — и все.

    — Какие гайды легли в основу этого линтера? Или здесь только твой собственный опыт?

    Сейчас в его основе правила, которые мы многие годы формулировали для себя на code review. Какие-то правила портировали из других линтеров: ESLint, Pylint, SonarQube, Credo. Многое взяли из прекрасной работы «CognitiveComplexity». Всегда оглядывались на Кошелек Миллера. Отдельные правила — это мое видение, появившееся после оценки большого количества чужого кода. То есть на данном этапе это «сборная солянка».

    — О чем ты будешь рассказывать на Moscow Python Conf ++?

    В первую очередь — про управление сложностью. Эта тема близка и понятна всем разработчикам. Мы посмотрим на разные метрики, на способы переносить сложности из самого простого составляющего кода — строчки — на самый сложный — модуль. А потом поговорим о холиварной части, где я изложу свое видение того, как нужно или не нужно писать на Python, и попрошу пользователей проголосовать, что им нравится, а что — нет. Для многих разработчиков ограничения (делать А, но не делать В) — покушение на их творческое пространство, поэтому они очень бурно на это реагируют. И вот как раз здесь можно развязать интересную дискуссию.

    — На кого ориентирован доклад?

    Я думаю, что это все-таки сложившиеся разработчики, потому что начинающие программисты еще не сформировали своего четкого мнения. Хотя и им будет интересно послушать и высказаться. Они точно являются нашими пользователями.



    Друзья, спешим напомнить, что до нашей Moscow Python Conf++ осталось меньше месяца. В этом году на ней будет более трех десятков выступлений и целая серия митапов. Финальная программа будет анонсирована на днях, а пока можно ознакомиться с общим списком докладов.
    Конференции Олега Бунина (Онтико)
    801,00
    Конференции Олега Бунина
    Поделиться публикацией

    Комментарии 55

      +12
      >Например, если использовать Webpack, появляется возможность писать функцию `import()`
      Вообще-то это часть спецификации языка.

      >Управлять сложностью тяжело, когда язык меняется от установки Babel или плагинов к нему.
      Фейспалм.

      >А чтобы понять, как они работают, нужно следить за стандартами языка
      Как и в любом другом языке/стеке технологий.

      >в коде проекта JS смешиваются сразу несколько сущностей, которые не относятся к самому языку
      И на два абзаца ниже рассказ о том, что если добавить в Python библиотеку AsyncIO, то все сильно усложняется.

      >Хочешь использовать синхронную библиотеку для работы с БД — пожалуйста. А хочешь асинхронную — ее нет.
      Вот если бы только был такой язык, в котором по-умолчанию все асинхронное.

      «Делайте лучше сервисы».
        +1
        from gevent import monkey
        monkey.patch_all()
        — и все, весь синхронный код становиться асинхронным (почти шутка)
          +1
          > Вот если бы только был такой язык, в котором по-умолчанию все асинхронное.
          Посмотри на Erlang, он почти смог
            +2
            Вот если бы только был такой язык, в котором по-умолчанию все асинхронное.


            Erlang довольно близко подошел к такому. И у него свой собственный подводный сад граблей :)
              0
              Не будет сада — не нужно садовников)
              А так, вполне вменяемо. Уже не первый год использую для разного.
              0
              > Вообще-то это часть спецификации языка.

              Вообще часть спецификации языка это import js-модулей, а вебпак нам несет еще и import для ассетов, css и прочего, вероятнее всего это и имел ввиду автор.
              +18
              Влияет ли на управление сложностью то, что в программировании сейчас довольно много людей со слабой технической базой?

              Конечно. Для таких людей даже специальный язык программирования придумали. Называется Go. Я не шучу. ....

              Нельзя вот так вот навешивать ярлыки и обобщать!
              Я лично большую часть статьи расцениваю как плевок в лицо всем разработчикам в мире в не зависимости от используемого языка программирования и уровня квалификации,
              а высказывание выше — прямым оскорбление всего сообщества golang разработчиков!

              Все люди не умеют писать код

              Прям все?
              Конечно, Никита Соболев, являясь техническим директором компании «Мы делаем сервисы» может внутри компании ненавидеть всех своих подчинённых и всех разработчиков, по должности он не обязан уметь писать код и скорее всего это именно так, но выносить это в паблик, обобщать, навешивать ярлыки и делать выводы это уже откровенное оскорбление!
              А со стороны Онтико это явно провокация, не достойная уважения, фу! фу! фу! Онтико! Грязно!

              Друзья, спешим напомнить, что до нашей Moscow Python Conf++ осталось меньше месяца. В этом году на ней будет более трех десятков выступлений и целая серия митапов. Финальная программа будет анонсирована на днях, а пока можно ознакомиться с общим списком докладов.

              Задумайтесь, если вот такие доклады будут на «Moscow Python Conf++», стоит ли посещать такое мероприятие?
              Вот такие вот люди как Никита Соболев будут там что-то «вещать» со сцены за ваши же деньги… Хм…
                +2
                Все люди разные. Все люди одинаковы. И то и другое правда. В некотором смысле.
                Все люди не умеют писать код. В этом он прав. В некотором смысле.
                У каждого программиста есть свой предел сложности, за которым начинаются проблемы. Что делать, если этот предел многократно превышен? Что делать, если этот предел превышен для фирмы в целом? Человек, который занимается этими вопросами не может закладываться на то, что программисты напишут правильно работающий код. И совершенно точно постулирует отправную точку своей работы: «Все люди не умеют писать код.»
                За всю жизнь я один раз (если не считать учебных задачек и спортивного программирования) видел правильно написанный с первого раза код. Мы около часа обсуждали алгоритм решения практической задачи. Потом мой коллега сел к терминалу и набил около 200 строк на фортране. Когда это с первого раза скомпилировалось я очень удивился. Но оно еще и заработало именно так, как мы хотели. С тех пор прошло ужасно много лет, но ничего похожего я не видел.
                +14
                Товарищ озвучивает довольно спорные тезисы.

                Где можно ознакомиться с его достижениями, которые свидетельствовали бы об авторитетности таких заявлений?
                  +10
                  Краткое исследование показало, что компания «Мы делаем сервисы», находится в стадии ликвидации — zachestnyibiznes.ru/company/ul/1177746045070_7708308765_OOO-MY-DELAEM-SERVISY

                  Может качество кода не связано напрямую с коммерческим успехом, но разве технический директор не отвечает за оптимальное соотношение цены/качества в контексте коммерческой целесообразности?
                    –2
                    Забавная штука, не подозревал что так можно. Вангую, что это механизмы работы с юридическими вопросами, к успешности и финансовым показателям компании в целом не имеющие никакого отношения :)
                      0
                      Дай бог, чтоб у них было все хорошо.
                    +8
                    Достижения легко гуглятся:
                    github.com/sobolevn
                    github.com/wemake-services
                    habr.com/users/sobolevn/posts
                    medium.com/@sobolevn
                    www.moscowjs.ru/speaker/nikita-sobolev
                    events.yandex.ru/lib/talks/4858
                    theoryandpractice.ru/presenters/45416-nikita-sobolev/courses
                    freelansim.ru/freelancers/sobolevn
                    elixir-lang.moscow/speakers/nikita-sobolev-wemake-services
                    facebook.com/expertfridays/videos/1964415190439615
                    it-events.com/events/7360
                    hype.codes/n-sobolev-i-elixir-addition-python
                    www.conferencecast.tv/speaker/8086/nikita-sobolev
                    dev.to/sobolevn
                    bigxp.ru/experts/46


                    Думаю этого достаточно чтобы по достоинству оценить «эксперта» и технического директора компании «Мы делаем сервисы» Никиту Соболева.

                    А я с вами прощаюсь, так как скорее всего сейчас прибежит толпа таких же «экспертов» как технический директор и эксперт Никита Соболев и оба моих комментария заминусуют, как обычно это делается в современном хабре. И не важно что статья оскорбительная, суть статьи была «поднять волну» или «набросить на вентилятор»…

                    P.S.
                    Кто может, тот делает. Кто не может, тот учит. ©Чак Паланик
                    Твой учитель — это не тот, кто тебя учит, а тот, у кого учишься ты. ©Ричард Дэвис Бах
                    Кто умеет — делает, кто не умеет — учит, кто не умеет учить — руководит. ©Джордж Бернард Шоу.
                      +1
                      django-split-settings − это очень хороший пакет.
                        +1
                        Достижения СТО компании легко гуглятся по sbis.ru/contragents/7708308765/770801001

                        200к прибыли в 2017, в стадии ликвидации. Ясно-понятно.
                          +2
                          Думаю этого достаточно чтобы по достоинству оценить «эксперта» и технического директора компании «Мы делаем сервисы» Никиту Соболева.


                          Вот не понимаю я такой манеры общения, хочется, чтобы хабр был профессиональным и конструктивным, но будем обвинять всех в тупости?
                          Вы привели ссылки на публикации, и что?

                          Если вы считаете, что человек не прав, приведите цитату из его утверждений (с ссылками разумеется), потом на источник, который доказывает, что он не прав, желательно сделать так несколько раз. Вы же просто привели публикации, но при этом у него есть публикации и на хабре и на других сайтах, а вы пока лишь, крикнули, что все вокруг плохие специалисты, а вы, видимо, Д’Артаньян. Ну и вставили несколько цитат великих, видимо, чтобы подчеркнуть свою элитарность. Но опять же, и что? Теперь совсем никому ничему не учить и не учиться, потому что три цитаты говорят, что все учителя не профессиональны?

                          Ни в коем случае не утверждаю, что критиковать работу другого человека можно только, если у вас индекс Хирша, список публикаций на хабре, опыт в годах, количество созданных пулреквестов больше, но если вы хотите читать профессиональные статьи, то может и критиковать их стоит профессионально?
                          +4
                          Можно поинтересоваться, что именно вы считаете спорным?

                          Синтаксис языка должен определяться только спецификацией, а не флагами или конфиг-файлами, это бесспорно. Всякие `php.ini` и `use strict` − это плохой дизайн.

                          Go был создан для того, чтобы опустить уровень вхождения в компилируемые ЯП. Роб Пайк это прямо подтверждает.

                          Следовать стайлгайдам необходимо. И управлять сложностью кода в проектах, то есть, грубо говоря, заставлять «рок-звёзд» писать код, понятный джунам − это тоже очень важно.
                            0
                            Go был создан для того, чтобы опустить уровень вхождения в компилируемые ЯП. Роб Пайк это прямо подтверждает.

                            С этим не поспоришь, только в статье это подается как убогость go. И при этом и в следующем же абзаце (да и местами во всей статье в целом) идёт речь о героическом решении проблем, отсутствующих в go в принципе.

                              –2
                              Давайте начнем с

                              Нам дают не нормальный язык программирования, а его очень урезанную версию — в нем нет практически никаких сложных концептов by design. Нет дженериков, нет такого понятия, как исключения и т.д. И поклонников такого подхода много.


                              Утверждение, что отсутствие дженериков, исключений и т.д. делает язык ненормальным, неполноценным урезанным является очень спорным. И даже сам Никита признает спорность, указывая на количество поклонников такого подхода.

                              Как минимум отсутствует определение нормальности и полноты(неурезанности), потому что если под полнотой подразумевать общеупотребимую полноту по Тьюрингу, то приведенное утверждение не спорное, а прямо таки ложное.
                                +5
                                Я честно скажу: я не знаю Go, и не скажу, «нормальный» он на мой вкус или нет. Но когда я слышу: «дженерики не нужны», «лямбды запутывают», «зачем свойства, если есть геттеры и сеттеры», «множественное наследование − бред», «что плохого в бойлерплейтах, есть ведь кодогенерация в IDE» и всё такое, то я сразу вспоминаю дедушку Симпсона из серии про лимонное дерево. Помните?
                                “Lemons being the sweetest fruit available at the time.”
                                  0
                                  Это хорошая метафора, но метафоры не имеют доказательной силы и воздействуют скорее на эмоции, нежели на разум. Чтобы говорить о разумной дискуссии надо определить понятия и строить логические цепочки.

                                  Ведь, согласитесь, не бывает просто «нужны» или «не нужны» в вакууме. Бывает «нужно для чего то».
                                    0
                                    Я не понимаю, как вы хотите, чтобы вам доказали необходимость дженериков или, скажем, каррирования? Метаматематически? Или с точки зрения психофизиологии?

                                    Всё нужно. Нужно расти над собой, узнавать новые вещи. Человеку нужно, а не программе.
                                      0
                                      Согласен, нужно расти над собой.

                                      Именно поэтому я интересуюсь, имеют ли приведенные тезисы под собой объективное основание, либо это мнения, о которых спорить глупо.

                                      И в чем вы несогласны с тем, что не бывает «нужно» в вакууме, без привязки к цели?
                                        0
                                        Та цель — она тоже не в вакууме, а привязана к некоей другой цели. Только проблема в том, что если достаточно долго идти по этой цепочке, то вы придёте к тому, что всё тлен и ничего не нужно.
                                  0
                                  Полнота по Тьюрингу не является чем-то заведомо хорошим. Например, полные по Тьюрингу системы типов имеют очевидные проблемы.

                                  Про поклонников подхода написали хорошо в каком-то соседнем треде — что часть из них и кода-то не пишет.
                                    0
                                    Вопрос был в том, что считать урезанным, а что не урезанным, т.е. полным.
                                    Другого общеизвестного определения полноты, кроме полноты по Тьюрингу я не знаю.

                                    Без определения понятия дискуссия не может быть цивилизованной.
                                      0
                                      Обычно имеют в виду выразительные средства.

                                      Brainfuck для вас не урезан по сравнению с Go?
                                        0
                                        Если разговор идет о моем мнении, то мое мнение состоит в том, что чрезвычайно желательно, чтобы выразительные свойства языка были не шире и не уже, чем нужно для решения поставленных перед языком задач.

                                        Соответственно, если Brainfuck нужен, чтобы факать мозги, то он прекрасен в этой области.

                                        Если же разговор об абстрактной полноте/урезанности, то нужно не мое мнение, а критерии полноты/урезанности.

                                        Разве не так?
                                          0
                                          чрезвычайно желательно, чтобы выразительные свойства языка были не шире и не уже, чем нужно для решения поставленных перед языком задач.


                                          Что намекает либо на нашу возможность предсказывать будущее (заранее знать, какие задачи будут перед языком) либо на работу в изолированном от внешнего мира бункере с замороженной спецификацией и с госзаказом наперевес :)
                                            0
                                            Что намекает либо на нашу возможность предсказывать будущее (заранее знать, какие задачи будут перед языком) либо на работу в изолированном от внешнего мира бункере с замороженной спецификацией и с госзаказом наперевес :)


                                            Я всегда был уверен, что сначала формулируется задача, а потом создается/дорабатывается язык для решения этой задачи. Разве нет?
                                              0

                                              Увы. Долгий эволюционный процесс, длящийся годами и десятилетиями. Постоянно реагирующий на изменения обстановки. Часто — с неожиланными поворотами сюжета (никто не ожидал, что type annotations вылются в gradual typing)

                                            0
                                            Я бы предпочёл, чтобы язык был достаточно мощным, чтобы я мог сам себе создавать выразительные средства и ограничения под задачу вместо изучения нового языка под задачу. Ну там, чистота функций, монадический синтаксис, вот это всё. Но это, опять же, если разговор идёт о субъективном мнении.

                                            А если говорить в контексте дискуссии, то получается, что ваше уточнение об определении урезанности языка как его Тьюринг-(не)полноты делает дискуссию по большому счёту неконструктивной (хотя, возможно, и цивилизованной).
                                              0
                                              Я бы предпочёл, чтобы язык был достаточно мощным, чтобы я мог сам себе создавать выразительные средства и ограничения под задачу вместо изучения нового языка под задачу.

                                              Forth это умеет.
                                              Только, что-то не очень он популярен.
                                              Вероятно, потому что писать расширения для языка который ближе к ассемблеру, чем к C — занятие на любителя.
                                              Полнота по Тьюрингу не является чем-то заведомо хорошим. Например, полные по Тьюрингу системы типов имеют очевидные проблемы.

                                              Можете, пожалуйста, пояснить про проблемы?
                                              И привести пример полной по Тьюрингу системы типов (не очень себе представляю, что это по отношению к типам).
                                                0
                                                Forth это умеет.

                                                Forth умеет немного не то. Вы, вероятно, про околосинтаксические конструкции, а я про систему типов.

                                                Можете, пожалуйста, пояснить про проблемы?

                                                Вывод типов неразрешим, сам тайпчекинг может быть неразрешим. Вы ведь не хотите, чтобы у вас процесс компиляции зависал?

                                                И привести пример полной по Тьюрингу системы типов (не очень себе представляю, что это по отношению к типам).

                                                Возьмите любой язык с зависимыми типами (вроде агды или идриса) и выкиньте требование тотальности функций в type-level language.

                                                Ну или вполне конкретный пример вот. Вот прям там, где «Here, for example, is a program that would make the typechecker loop».
                                      0

                                      Когда говорят про кастрированность языка очень редко подразумевают "общеупотребимую полноту по Тьюрингу". Обычно эта фраза значит, что существует класс задач, который в этом языке делается через жопу. Вам нужно развернуть определение "делается через жопу"?


                                      Право говоря, мне очень странно видеть, что "отсутствие дженериков как признак урезанности" для кого-то является спорным. Уж извините, но хейтят golang за это давно. У существования дженериков (в других языках) есть определенная причина. И нужно доказывать, что плюсы от удаления дженериков перевешивают минусы. Здесь спорно, что их не реализовали. И вовсе не спорно, что их отсутствие осуждается.

                                        +1
                                        Обычно эта фраза значит, что существует класс задач, который в этом языке делается через жопу. Вам нужно развернуть определение «делается через жопу»?


                                        Тогда большинство языков являются кастрированными, поскольку так или иначе каждый имеет слабые стороны. Иначе ведь существовал бы один единственный полный язык, который хорошо решал бы все задачи.

                                        Мы этого не видим.
                                          0
                                          Очень странное рассуждение: отсутствием идеала вы показываете что?
                                          Давайте так: я утверждаю, что brainfuck еще более кастрированный.
                                          Не кажется ли вам странным, что ваше рассуждение не позволяет мне утверждать про кастрированность {uglyLang}, только потому, что другие языки имеют свои слабые стороны?
                                          Или brainfuck — норм язык?
                                  +1
                                  А можно ссылку на гитхаб линтера?
                                    0
                                    Связался с Никитой, скоро ответит
                                    +1
                                    А почему никто до сих пор не написал аналог V8 для Python? C API виновато?
                                    +4
                                    Действительно, целью создания языка Go была попытка вовлечения в написание кода студентов и стажеров Google, которые не могут освоить C++.

                                    А я думал основная фишка Го, это процессы, реализованные средствами рантайма, которые по сравнению с обычными процессами ОС занимают намного меньше ресурсов, и их можно запускать миллионами на одной машине, выжимая тем самым из нее максимум производительности.
                                    А оказывается дело в синтаксисе.
                                    Век живи, век учись…
                                      –4
                                      Увы, дело действительно в синтаксисе. Green threads много у кого есть. У того же Ruby.
                                        +1
                                        green threads в руби нет со времен версии 1.9, т.е уже почти 12 лет.
                                        +5
                                        Вы путате причины появления языка и фишки языка. Корутины были придуманы очень-очень задолго до создания go, и прекрасно реализцются на assm, С и С++ и производительности выжимают больше. Но сделать это ненаделав кучу ошибок гораздо тяжелее. Целью создания go, изначально, была имено простота использования, о чём Роб Пайк и рассказывал: web.stanford.edu/class/ee380/Abstracts/100428-pike-stanford.pdf
                                          +3
                                          Си создали потому, что ленивые и глупые студенты не могут освоить ассемблер в силу слабой технической базы?
                                            –2
                                            Ну нет, совсем другая история. «C» был разработан в процессе переписывания Unix под новую архитектуру. С целью сделать переписывание комфортным для разработчиков. Он решает ровно те задачи, которые у них были на момент работы. К студентам не имеет никакого отношения.
                                              +6
                                              Товарищ, вы просто не знакомы с тем, что жив еще Вирт, что есть «параллельный» мир modula, pascal, oberon. И сказали какую-то глупость о go.
                                              Он не для того, чтобы вчерашних студентов в сеньоры пихать. И, видимо, не знаком с тем, что может сделать сложность с большим проектом.
                                              Может даже узнаете о том, что «примитивный» pascal сделал для java…
                                              Может откроете, что почему-то иногда простота языка важна и за эту простоту начали биться во времена, когда не была массовой профессия программиста и не стояло задачи нанимать «студентов».
                                              Может, однажды вы, эксперт, тоже чему-то научитесь.
                                                0
                                                Жив не только Вирт, а также Керниган. И он занимается Go.
                                            +1
                                            прекрасно реализцются на assm, С ..
                                            насколько я понимаю, это надо либо расставлять операторы типа «yield» (и/или работать с прерываниями и/или стеком) вручную, либо написать написать и вставить в свое приложение вытесняющую многозадачность, чтобы пропущеный yield не подвешивал все потоки, бегущие в процессе. Плюс, Го распределяет бегущие корутины на имеющиеся процессы ОС, чего не делают многие из перечисленных альтернатив.
                                            Поэтому, да, целью Го была простотая работа вот с этим вот всем, но уж никак не ради стажеров, которые не могут освоить синтаксис.
                                          +5
                                          Самый страшный пример, который я видел, продемонстрировал мне, что внутри цикла на сотню итераций можно определить функцию. Если честно, когда я на это смотрел, у меня внутри интерпретатор сломался. Я догадывался, но не знал, что так можно.

                                          Ну что тут можно сказать…
                                            0
                                            Я думаю, что это все-таки сложившиеся разработчики, потому что начинающие программисты еще не сформировали своего четкого мнения. Хотя и им будет интересно послушать и высказаться. Они точно являются нашими пользователями.

                                            Странно, нет четкого мнения у начинающих программистов, но они уже


                                            наши пользователи

                                            Вряд ли

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое