Комментарии 43
Видимо, пропитанная трупным смрадом гадость, вроде ABAP или APL, не набрала кворума по количеству ответов, чтобы попасть в список)
Знаю я, есть края — походи, поищи-ка, попробуй.
Там такая земля, там такая трава,
А лесов как в местах тех нигде, брат, в помине и нет.
Там в озёрах вода, будто божья роса,
Там искрятся алмазами звезды и падают в горы.
Такой себе список, субъективно и ничем не обосновано, с точки зрения синтаксического удобства так точно.
p.s.
Очередная статья ради статьи?
Хабр, похоже превратился в спам площадку для IT маркетологов.
Хорошо что ещё есть статьи от практикующих инженеров с полезным контентом.
Вопрос как мотивировать хабр добавить фильтрацию по аккаунту что бы исключать этот спам?)
Когда у языка система сборки, можно сказать, встроена в язык, и компилятор сам ловит UB или ошибки управления памятью, а для юнит-тестирования не надо ничего настраивать, то рефакторинг и поддержка старого кода не становятся чем-то неприятным. И да, я про Раст.
Безусловно сам язык тоже важен — его логичность, структура, качество стандартной библиотеки, инструменты. Скорее всего новые языки, написанные с учетом недостатков старых, будут решать их лучше и будут в долгосрочной перспективе лучше.
Но ведь и старые языки — либо их ругают, либо они мертвы. У современных версий активно используемых языков и инфраструктура есть, и инструменты напилены.
Мне очень нравится раст, но он не панацея. Он хорошо решает важный класс проблем, но создает и свои сложности, не так прост, как языки более высокого уровня (это не его задача)
В общем на нем есть где посеять семена будущих проблем.
Скорее время покажет, было ли это действительно хорошим решением.
У современных версий активно используемых языков и инфраструктура есть, и инструменты напилены.Проблема в том, что мало где те же линтеры и статические анализаторы внедрены для тех же C/C++. Да, они есть, но мало кто ими пользуется.
А когда оно уже встроено в компилятор, тогда в любом случае будешь пользоваться.
В JS или C++ миллион стандартов, которые вроде работают и добавляют большие возможности, но создают редкостную боль, выражаемую в проблемах настройки сборки, к примеру.
Более поздние языки с хорошо написаной единой базой, качественной стандартной библиотекой страдают от этого минимально.
Ну и инструменты важны, тут конечно ребята очень хорошо придумали, что сразу и сборка и менеджер пакетов стандартны.
Ну посмотрим, Я пока только ковыряю для сторонних проектов.
Так то Я C# разработчик, хотя писать довелось много на чем.
Мне в целом нравится, пытаюсь использовать для сторонних проектов.
Но есть и сложности — например Zero Cost Abstractions только для компа нулевая стоимость, а для мозга разработчика еще и как не zero. Немного торчащие низкоуровневые детали типа разных типов ссылок, срезов, с одной стороны, заставляют подумать о важных вещах, с другой стороны — не способствуют простой архитектуре. Но и не запрещают ее, конечно.
Это как бы разные слои организации.
Справедливости ради, по такому параметру сравнивать скажем Rust и JS, Python, Java вообще не корректно потому что в 3-х отсальных таких проблем вообще нет и не нужно это по сути для прикладных задач решаемых на этих языках.
Для системного ПО или embedded да. Хотя сейчас современные компиляторы делают много проверок. Что отталкивает от rust это переусложненный с моей точни зрения синтаксис и как все это пишут на трейтах, напоминает мне java enterprise ад — бессмысленый и беспощадный, а синтаксис rust это только поощряет. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
Мне кажется, что разработку ждет еще большое развитие в области архитектур — понимания того, как писать код так, чтобы каждый отдельный кусочек либо писался снова, либо выбрасывался и заменялся другим, вместо переписывания
Но моя фраза была не про это. Моя фраза была про правильную декомпозицию и проектирование точек расширения — писать код так, чтобы изменять его в будущем было просто — нашел место, выкинул один компонент, вставил (написал) другой, profit.
Хорошим примером являются паттерны построения интерфейсов типа MVVM или компонентная модель в играх. Модель отделена от представления, и ты либо меняешь правила под новые требования в модели, либо меняешь визуал, влезая в окошко и меняя одно поле на другое, точно зная, что никакая логика, кроме этого окна, не сломается, а окно будет протестировано. Если все написано вместе, то изменения в логике случайно могут затронуть визуал, и наоборот.
Идеально, если это сделано так, что окна можно отдавать неопытным разработчикам, не волнуясь, что они что-нибудь сломают. И не важно, как плохо сделано окно — всегда легко разобраться, что в нем, либо просто выкинуть и написать новое.
Собственно половина принципов SOLID направлена на то же самое — и SRP, и ISP и, в некоторых трактовках — OCP
что легаси — серьезная архитектурная проблема.
Оно не архитектурная проблема. Оно — проблема неумения документировать и неумения передавать знания.
Это легаси может быть сколь угодно стройным и пользоваться красивыми алгоритмам для вычисления чего-то нужного. Но если забыли объяснить, как именно все задумано и для чего сделано — то получим то что обычно имеем.
Оно — проблема неумения документировать и неумения передавать знания.А толку от документирования и передачи знания, если за время жизни проекта некоторые требования по нескольку раз меняются на диаметрально противоположные? А если попытаться заранее соломки подстелить на все случаи жизни, то получается переусложнённые монструозины с миллиардом зависимостей, в которых за инфраструктурным кодом не видно бизнесс-логики.
А ведь бывает и два в одном — когда сначала наворотили инфраструктурного кода, а потом на нём ещё четыре года кряду допиливали под меняющиеся требования...
А толку от документирования и передачи знания, если за время жизни проекта некоторые требования по нескольку раз меняются на диаметрально противоположные?
Так документация и знания о текущей системе должна меняться одновременно с изменениями в этих требований.
Оно — проблема неумения документировать и неумения передавать знания.Либо нежелания этим заниматься.
Стройность — она ведь не абстрактная в вакууме, она про какие то качества кода.
И красота в этом смысле — это обычно понятность.
Код является самой исчерпывающей документацией на себя и ему больше чем документации необходимо быть хорошо структурированным, понятно именованным и непротиворечивым. В нем должны быть очевидны основные и вспомогательные классы, главные компоненты и составляющие их потроха, основные сущности, с которыми он оперирует.
Для основных сущностей (окошки? Сервисы расчетов? Клиенты?) должны быть предусмотрены понятные точки расширения, основные сервисы должны работать так, чтобы их нельзя было использовать неправильно.
Документация — это отлично, но она устаревает, вечно отстает и десинхронизируется, нужно тратить большие ресурсы на ее поддержание и актуализацию. Документация говнокода со сложным непродуманым апи основных сервисов будет сложнее и больше, чем с простым апи качественного кода.
Качественно декомпозированные и написанные классы дадут хороший шаблон последующим программистам, как расширять существующий код — если ты сейчас не выделил пару разных классов, а сделал 4 ифа, то они могут превратиться в 4 свича, которые так и будут прирастать 3-м, 4-м, 5-м вариантом обработки, вместо того, чтобы стать 3-м, 4-м, 5-м классом.
Я сейчас не про то, что «не пишите говнокод, а пишите хорошо», а про то, что «тщательно проектируйте важные точки, которые с большей вероятностью будут расти, тогда ваш проект переживет говнокод в деталях реализации отдельных классов».
Обычно встречается обратная ситуация — хорошо написаны отдельные классы, но общая архитектура — это мешанина из флажков, синглтонов и переходов откуда угодно куда угодно. И документация такая же — есть описание форматов и деталей каких нибудь алгоритмов, а для части сущностей ни точки входа не найти, ни ответственных.
Код является самой исчерпывающей документацией на себя
Не является. Потому что в нем не написано почему и для чего все это делается. И почему именно так, а не иначе.
Просто самой достоверной и полной.
Причин он конечно не назовет, это не его задача.
А вот быть понятным и удобным для расширения — в том числе одна из задач.
Я не против того, чтобы писать документацию, мой поинт в том, что документацией эту проблему не решить.
Код с плохой организацией будет вызывать больше ошибок даже при постоянной работе с ним, когда программист явно с ним знаком. Если для внесения нового поведения тебе нужно поправить 10 мест, а не 2, это действие будет более опасным в смысле багов вне зависимости от документации.
Если для внесения нового поведения тебе нужно поправить 10 мест, а не 2, это действие будет более опасным в смысле багов вне зависимости от документации.
Я не совсем уверен. Если эти 10 мест описаны и потом могут быть проверены по чек-листу на ревью кода — то это безопаснее, чем когда 2 места как то нашел, поправил, но не уверен, что еще одно место не пропустил.
А документация нужна, например, чтобы новые люди знали все упомянутые точки расширения, а не пытались делать новые, потому что существующих не заметили.
Или другой пример: теоретически, стандартной библиотекой языка или каким-нибудь фреймворком можно пользоваться без документации. Ну а что, в код посмотрел и найдешь, что для чего служит и как использоваться должно. Но защищающие подобный подход вряд ли найдутся. А в отношении конкретного продукта или программы — почему то сплошь и рядом.
Звучит прикольно, но в реальности 3 из 5 проектов написаны так, будто авторы вообще не слышали про архитектуру. Смешения слоев, низкоуровневая часть в бизнес логике (не ради оптимизации, а просто потому что так быстрее), ни о чем не говорящий нейминг и тд и тп. И в итоге спустя год разработки, поддерживать эту кучу лапши уже невозможно, потому что черт его знает, как оно работает и как мой код повлияет на этот клубок из хаков, магии и сайд эффектов.
И как раз это уже похоже на проблему: у большинства разработчиков нет не только архитектурного видения, но даже и понимания того, почему это важно. Слои? Чёт сложно, проще код на месте написать. Абстракции? Много букав, забьём. В результате код не имеет структуры, смысла и внятной логики, его очень сложно читать и невозможно предсказать.
То, чему учат и в чем есть экспертиза — это как писать хороший код. Максимум методы и классы, хороший нейминг. Редко библиотеки.
То есть хорошие классы можно найти, модули — почти никогда.
Как разделять, где делать архитектурные швы, зачем их делать, какие приемы использовать для встраивания — очень редкие навыки.
Редко встречается хотя бы понимание о том, что какие то части, например модели или инфраструктуру, стоит изолировать.
Собственно, и для своих проектов сделать нормально тоже часто не бывает времени, ресурсов и понимания коллег.
Но это ведь не повод не стараться?
Ну и от этого это не меньшая архитектурная проблема.
Концепция интересная, но мне кажется, что тут есть некоторое передёргивание. Одно дело "проект, который сопровождаешь", и другое дело "lore, с которым знакомишься". Вот у многих dreaded languages очень плохой lore.
С другой стороны, 90%, что в вашем следующем новом проекте будет код на bash'е. Это не означает, что bash зелёный. Это dreaded язык, которого очень хочется избегать, но к которому всё время приходится прибегать.
Вот, например, те, кто любит питон — вы хорошо понимаете всю эту чехарду между wheels, eggs, distutis, setuptools, и прочее, и прочее? Я выучил как надо делать. Как оно устроено внутри — я не хочу знать. Потому что я ещё застал pycentral, и мне было больно.
В сфере проектирования ЯП тоже есть прогресс и моральное устаревание. И на мой взгляд, это куда более простое объяснение, чем поддержка или написание нового кода.
По современным стандартам безопасности, выразительности и удобства кандидат из списка любимых даст прикурить своей альтернативе из списка нелюбимых.
Хаскель самый страшный из любимых
Языки любимые и языки страшные. Зелёные пастбища и коричневые поля