Pull to refresh

Comments 43

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

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

Знаю я, есть края — походи, поищи-ка, попробуй.
Там такая земля, там такая трава,
А лесов как в местах тех нигде, брат, в помине и нет.
Там в озёрах вода, будто божья роса,
Там искрятся алмазами звезды и падают в горы.
UFO just landed and posted this here

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

UFO just landed and posted this here
UFO just landed and posted this here

Такой себе список, субъективно и ничем не обосновано, с точки зрения синтаксического удобства так точно.
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++, особенно если посмотреть не на абсолютные цифры, а относительно числа людей, использующих эти языки по работе.
UFO just landed and posted this here

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

UFO just landed and posted this here

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

Sign up to leave a comment.