Цель — писать максимально простой и понятный код.

Сложность, конечно, понятие субъективное, однако если взять "среднее по больнице", то некие тенденции вырисовываются.

С одной стороны, если парадигм будет достаточно мало (в теории 1 команды достаточно для всего) — будет весьма сложно.

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

Для примера возьмем Java и Scala. Scala проще или сложнее? Для большинства все-таки сложнее, по этому не все на эту территорию хотят заходить. Но те кто вошел, считают что им проще писать (а может просто чувство собственной исключительности подогревает интерес??? — это еще вопрос).

Так вот. Постепенно функциональщина и пр. монады — протекают и в изначально простые языки. В тот же C# или Java. Протекают под тем соусом, что если вы эти парадигмы освоите — то вам станет проще жить — т.е. выше порог вхождения, но проще потом кодить. Что само по себе довольно спорно и не подтверждено никакими серьезными исследованиями — просто кто-то так думает.

Просьба высказать мысли по этому вопросу.

Здравствуйте, Shmj, Вы писали:

S>Цель — писать максимально простой и понятный код.
Код должен решать какие-то реальные задачи или только удовлетворять эстетическим запросам?

wtf per minute

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

Ещё надо различать понятия "проще писать" и "проще читать". Код может быть просто написать, но потом прочитать его может быть сложно (в том числе автору после того, как контекст из мозгов выпал через некоторое время). В этом плане на Scala может быть проще писать, но вот читать — не факт. Хотя определённый код вроде манипуляции деревьев, там, где хорошо заходит паттерн-матчинг, действительно может получиться компактней и проще на Scala.

Мне на Scala нравилось писать в стиле Java++. Т.е. пишем не выпендриваясь и из Scala-фич используем только те, которые очевидно работают и явно экономят код. Но программисты на Scala любят писать в стиле Haskell--, поэтому я на Scala перестал писать, как только появился Kotlin.

Что касается функциональщины, то определённый код действительно проще выглядит в функциональном стиле. В первую очередь это обработка коллекций, причём такая, которая выглядит как последовательность простых функциональных вызовов вроде filter, map и т.д. Монады я на Java пока не видел, слава богу. В целом тут лично я придерживаюсь консервативных взглядов и избегаю функционального кода, применяя его только там, где он даёт очевидное преимущество. Если очевидного преимущества нет, пишу в императивном или в ООП-стиле.

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

Здравствуйте, kov_serg, Вы писали:

_>Код должен решать какие-то реальные задачи или только удовлетворять эстетическим запросам?

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

Здравствуйте, kov_serg, Вы писали:

S>>Цель — писать максимально простой и понятный код.
_>Код должен решать какие-то реальные задачи или только удовлетворять эстетическим запросам?

Как правило, второе тесно связано с первым Но не у всех. Например, слишком часто если код пишется под девизом — "моноиды, монады, алгебраические типы, фп это круто, красота и тд", то из моей практики никакие другие аргументы всерьёз не воспринимаются. Хилый вывод в логах — не аргумент, нет пошаговой отладки — не аргумент, нет обратной совместимости — не аргумент. "Зато у нас будет всё на фп!!!!!111"

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

Здравствуйте, Shmj, Вы писали:

S>Цель — писать максимально простой и понятный код.

S>Так вот. Постепенно функциональщина и пр. монады — протекают и в изначально простые языки. В тот же C# или Java. Протекают под тем соусом, что если вы эти парадигмы освоите — то вам станет проще жить — т.е. выше порог вхождения, но проще потом кодить. Что само по себе довольно спорно и не подтверждено никакими серьезными исследованиями — просто кто-то так думает.

S>Просьба высказать мысли по этому вопросу.

Вот мысли:

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

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

— Иными словами, баланс между скоростью и качеством разработки (если алфавит хороший или заточенный под продект) и объемом минимальных знаний для новых программистов

— Соответственно, проект на ФП с библиотекой комбинаторов — это китайская грамота для всех, кто не выучил эту библиотеку. Особенно тяжелый случай — если библиотека самодельная.

— Проект на ФП с недокументированной библиотекой комбинаторов — идеальный job security. Никто не сможет поддерживать этот софт, кроме автора.

— Программисты считаю себя инженерами, но на практике крайне редко способны объективно оценивать принимаемые решения, путём выработки критериев качества и проверки решения на соответствие этим критериям.

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

Здравствуйте, Shmj, Вы писали:

S>Сложность, конечно, понятие субъективное, однако если взять "среднее по больнице", то некие тенденции вырисовываются.

Используй анализаторы кода, и всё будет ок.

Здравствуйте, Shmj, Вы писали:

S>Просьба высказать мысли по этому вопросу.

https://rsdn.org/article/philosophy/Complexity.xml

Автор(ы): Игорь Ткачёв
Дата: 06.12.2002

Согласен с мнением vsb о том, что код, который проще писать и код, который проще читать — кардинально разные виды кода.

Возможно, в связи с этим есть перспектива у транспайлеров, которые переводили бы код с "языка для писанины" на "язык для чтения (и легкой модификации)". При этом:

1) На двух классических стадиях жизни проекта "активная разработка" и "эксплуатация одновременно с постоянной поддержкой и расширением" исходный код проекта был бы выражен на двух разных языках/их группах — на группе "первичных" языков и на одном "вторичном" языке.

2) каждый программист-разработчик("писатель") мог бы выбирать свой любимый/более подходящий из нескольких возможных "первичных" языков, а все программисты-"поддерживальщики" (более низкой квалификации) использовали бы стандартный и всем понятный "вторичный" язык, в который бы весь проект был транспилирован по завершению стадии активной разработки.

3) особо продвинутые разработчики могли бы использовать даже уникальный (свой собственный) "первичный" язык — лишь бы существовал стабильный транспайлер с него на выбранный для проекта "вторичный".

4) при увольнении такого "особо умного" весь его код может быть транспилирован в выбранный "вторичный" — нет проблем при его поддержке другими (не такими умными) программистами и т.п.

5) в принципе возможен обратный транспайлер, переводящий "вторичный язык" обратно в "первичный" — не обязательно идеально, допустимы прямые включения кода на вторичном в код на первичном и т.п. С ним становится возможной совместная работа над проектом как "продвинутых", так и "простых" программистов — каждый на своём языке (как вариант, при этом в VCS хранился бы код уже на вторичном языке, "продвинутые" программисты обратно-транспилировали бы его после обновления рабочей копии и туда-транспилировали бы перед коммитом).

Здравствуйте, L_G, Вы писали:

L_G>Согласен с мнением vsb о том, что код, который проще писать и код, который проще читать — кардинально разные виды кода.

L_G>Возможно, в связи с этим есть перспектива у транспайлеров, которые переводили бы код с "языка для писанины" на "язык для чтения (и легкой модификации)".

Зачем еще один обфускатор?

При переводе с одного языка на другой язык программа может перестать работать или потерять что-то или получить новые баги.
Особенности работы runtime-а разных языков, например erlan контролирует ресурсы дочерних процессов, а в отстальных языка вы с этим вынуждены бороться своими велосипедами. То что в одних пишется в одну строку на других это длинная портянка веловсипедов.
И кто сказал что преобрахование будет однозначным. На перле одно и тоже можно написать десятками способов. Так-что при преобразованиях возможны потери. В фортране переменные передаются по ссылке, а не по значению. Что вызывает лютый восторг тех кто переписывает с фортрана на другие языки. В одних языках есть сборщики мусора, в других может нет. Строки отдельная песня. У одних pattern matching встроен у других нет. Регулярки часть языка, у других илбо нет либо могут отличаться. В cilk легко наплодить паралельных потоков, а в некоторых только однопоточная модель. Некоторые имеративные языки, а некоторые декларативные: то что в sql пишется в одну строку на других языках это треш и угар. Модели исполнения тоже могут отличаться например в vhdl вы описываете процессы и соединения, а не последовательность исполнения.

Вообще есть haxe но он несколько для другого.

Здравствуйте, Shmj, Вы писали:

S>Цель — писать максимально простой и понятный код.

S>Сложность, конечно, понятие субъективное, однако если взять "среднее по больнице", то некие тенденции вырисовываются.

S>С одной стороны, если парадигм будет достаточно мало (в теории 1 команды достаточно для всего) — будет весьма сложно.

S>С другой стороны, если парадигм достаточно много — то, как показывает практика, не все могут осилить. Т.е. код может быть короче, но сложность восприятия для большинства возрастает.

S>Для примера возьмем Java и Scala. Scala проще или сложнее? Для большинства все-таки сложнее, по этому не все на эту территорию хотят заходить. Но те кто вошел, считают что им проще писать (а может просто чувство собственной исключительности подогревает интерес??? — это еще вопрос).

S>Так вот. Постепенно функциональщина и пр. монады — протекают и в изначально простые языки. В тот же C# или Java. Протекают под тем соусом, что если вы эти парадигмы освоите — то вам станет проще жить — т.е. выше порог вхождения, но проще потом кодить. Что само по себе довольно спорно и не подтверждено никакими серьезными исследованиями — просто кто-то так думает.

S>Просьба высказать мысли по этому вопросу.

(defn prime? [n]
  (let [sqrt (Math/sqrt n)
        divisors (range 2 (inc sqrt))
        remainders (map (fn [x] (rem n x)) divisors)
        zeroes (filter zero? remainders)]
     (empty? zeroes)))

user=>; (prime? 100)
false
user=>; (prime? 17)
true
user=>; (primes 100)
(1 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97)

Now I want you to think carefully about how we solved this problem. No if statements. No while loops. Instead we envisioned lists of data flowing through filters and mappers. The solution was almost more of a fluid dynamics problem than a software problem. (Ok, that’s a stretch, but you get my meaning.) Instead of imagining a procedural solution, we imagine a data-flow solution.

uncle-bob

Здравствуйте, Shmj, Вы писали:

S>Цель — писать максимально простой и понятный код.

S>Сложность, конечно, понятие субъективное, однако если взять "среднее по больнице", то некие тенденции вырисовываются.

S>С одной стороны, если парадигм будет достаточно мало (в теории 1 команды достаточно для всего) — будет весьма сложно.

S>С другой стороны, если парадигм достаточно много — то, как показывает практика, не все могут осилить. Т.е. код может быть короче, но сложность восприятия для большинства возрастает.

S>Для примера возьмем Java и Scala. Scala проще или сложнее? Для большинства все-таки сложнее, по этому не все на эту территорию хотят заходить. Но те кто вошел, считают что им проще писать (а может просто чувство собственной исключительности подогревает интерес??? — это еще вопрос).

S>Так вот. Постепенно функциональщина и пр. монады — протекают и в изначально простые языки. В тот же C# или Java. Протекают под тем соусом, что если вы эти парадигмы освоите — то вам станет проще жить — т.е. выше порог вхождения, но проще потом кодить. Что само по себе довольно спорно и не подтверждено никакими серьезными исследованиями — просто кто-то так думает.

S>Просьба высказать мысли по этому вопросу.

К вопросу о языках, их легион, и все вроде бы популярны.
На чем же построена эта популярность? Скорее всего, на притоке новых поклонников.
Тогда человек со стороны всегда будет наблюдать бурление вокруг темы.
Так было со scala (ужасный язык с корявыми имплиситами).
Так происходит с F#. Здесь F# — провайдеры типов и не только мой некропост F#.
Т.е. движение туда-сюда есть, а поступательного нет. Но со стороны видим бешеную активность. Отсюда толпы новых фанатов.
Нужно внимательно выбирать языки, платформы и технологии. Хотя от ошибок никто не застрахован.

Здравствуйте, vsb, Вы писали:

vsb>Я считаю, что простой код это такой, который может читать с достаточно большой скоростью человек, не очень хорошо знающий целевой язык. Некий джуниор, скажем так, который потратил условный месяц на изучение языка, основные конструкции выучил, а экзотические — нет.

Вот не надо так обобщать, от языка зависит сильно. Скажем для C++ такой уровень — это Си-с-классами, т.е. крайне плохо поддерживаемое говнище.

Здравствуйте, Shmj, Вы писали:

S>Просьба высказать мысли по этому вопросу.

Прочитал как оценить проститутку года Шо жинка то сбежала?

Спроси начальника, он быстро твой код оценит. Хотя чего там оценивать. Поржать только

Здравствуйте, kaa.python, Вы писали:

KP>Вот не надо так обобщать, от языка зависит сильно. Скажем для C++ такой уровень — это Си-с-классами, т.е. крайне плохо поддерживаемое говнище.

Я не согласен. Если код на C поддерживаем, то от компиляции его C++ компилятором от не станет хуже. Если заменить классо-подобные конструкции на классы, код станет лучше. Т.е. Си с классами получается немного лучше обычного C и всё. Почему он внезапно превратится в говнище?

А вот если шаблонов накрутить, может и говнище получиться.

Здравствуйте, vsb, Вы писали:

vsb>Я не согласен. Если код на C поддерживаем, то от компиляции его C++ компилятором от не станет хуже. Если заменить классо-подобные конструкции на классы, код станет лучше. Т.е. Си с классами получается немного лучше обычного C и всё. Почему он внезапно превратится в говнище?

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

vsb>А вот есть шаблонов накрутить, может и говнище получиться.

Обобщенный код, верифицируемый компилятором, это как раз то, что нужно что бы удешевить поддержку и развитие продукта.

vsb>>Я считаю, что простой код это такой, который может читать с достаточно большой скоростью человек, не очень хорошо знающий целевой язык. Некий джуниор, скажем так, который потратил условный месяц на изучение языка, основные конструкции выучил, а экзотические — нет.

KP>Вот не надо так обобщать, от языка зависит сильно. Скажем для C++ такой уровень — это Си-с-классами, т.е. крайне плохо поддерживаемое говнище.

Сказал человек, который предпочитает писать на Go (по сути Си с классами и сборкой мусора).

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

Здравствуйте, Reset, Вы писали:

R>Сказал человек, который предпочитает писать на Go (по сути Си с классами и сборкой мусора).

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

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

Если у тебя нет команды сеньоров-помидоров, то брать для проекта C++ вообще не надо. Если же такая команда есть, то аккуратное добавление в неё небольшого количества новичков не ухудшит процесса.

KP>Сказал человек у которого вообще нет предпочтений на чем писать (была б статическая типизация), но у которого есть предпочтения к тому, на чем пишет его команда.

Изначальное твое утверждение было, что Си с классами порождает говнокод. Я написал, что по сути Go, на котором ты пишешь по своему выбору, тот же Си с классами. Ты зачем-то спрыгнул с темы и стал писать по то, какой ты герой и как умело настраиваешь процессы в команде.

KP>Если у тебя нет команды сеньоров-помидоров, то брать для проекта C++ вообще не надо.

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

P.S. Судя по тому, что ты

• любишь спрыгивать с неудобных тем (которые сам же начал),
  
• переходишь всегда на тему как ты умеешь правильно наладить процессы разработки,

ты уже давно не разработчик.

Здравствуйте, kaa.python, Вы писали:

KP>Потому что Сишный код так же трудно поддерживаемое говно.

Подтверждается ли это практикой?

Например код ядра Linux это C. Судя по тому, что Linux развивается уже 30 лет, в Linux контрибьютят самые разные люди, видимо на практике поддерживать этот код получается.

Код gcc изначально был на C. Несколько лет назад они его перевели на C++. Предполагаю, что по факту там тот же C с классами. Учитывая, что gcc успешно развивается всё это время и абсолютно конкурентен, видимо поддерживать его код тоже получается.

Интересно было бы узнать, что в clang. Это новый проект, изначально написанный на C++. Я мельком глянул его код, вроде везде всякие указатели, в том числе двойные, ещё и макросы. char* вместо std::string Например

Cookie IONAME(BeginInternalArrayListInput)(const Descriptor &descriptor,
    void **scratchArea, std::size_t scratchBytes, const char *sourceFile,
    int sourceLine) {
  return BeginInternalArrayListIO<Direction::Input>(
      descriptor, scratchArea, scratchBytes, sourceFile, sourceLine);
}

Предполагаю, что это можно квалифицировать, как С с классами?