Как стать автором
Обновить

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

Видимо, пропитанная трупным смрадом гадость, вроде ABAP или APL, не набрала кворума по количеству ответов, чтобы попасть в список)

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

Знаю я, есть края — походи, поищи-ка, попробуй.
Там такая земля, там такая трава,
А лесов как в местах тех нигде, брат, в помине и нет.
Там в озёрах вода, будто божья роса,
Там искрятся алмазами звезды и падают в горы.
Почему APL «гадость»?!
— с одной стороны — очень красивый язык! :)
— с другой стороны, на нём нет такого количества легаси, чтобы считаться «коричневым» языком из этой статьи

Но зато то легаси, которое есть, такое махровое, что прочитать его уже невозможно.

А откуда у APL взялось живое легаси? O_O

Потому что типов нет.

Такой себе список, субъективно и ничем не обосновано, с точки зрения синтаксического удобства так точно.
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, и мне было больно.

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

Как интересно это получилось в статье, C#, находясь только в списке любимых, попал в «коричневые языки поддержки», а ну к примеру Haskell, находясь ещё и в списке страшных языков, попал в «зелёные языки новых проектов». Аналитика уровня пятница? :)
Python и JavaScript тоже явно мимо. Вообще есть ещё другой критерий любимости языка — сколько людей выбирают его для пет-прожектов. Та же джава, например, в этом плане сильно уступает C/C++, особенно если посмотреть не на абсолютные цифры, а относительно числа людей, использующих эти языки по работе.

А почему нет? Новые проекты на хаскеле отлично начинать.

Хаскель самый страшный из любимых

Согласен. На фоне идриса или агды выглядит набором костылей.

А чем он страшный? (Не на фоне идрса, естественно).

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