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

V>Часто люди спрашивают в интернете, стоит ли учить такой-то язык программирования. И вот у меня возникла мысль.

V>1) С одной стороны знать много языков программирования вроде как хорошо, широкий кругозор.
V>2) С другой это лишь отнимает силы от того, чтобы выучить хотя бы один язык, но профессионально.

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

V>https://rsdn.org/poll/7808

Автор: velkin
Дата: 10.03.21
Вопрос: Что лучше, знать один язык программирования профессионально или несколько на среднем уровне?

А где вариант "Один профессионально и несколько на среднем уровне"?

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

Какой отверткой лучше уметь пользоваться — плоской или крестообразной?
А чем лучше — молотком или плоскогубцами?

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

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

Где-то я читал про такую концепцию, которая на западе называется "T-people" (такое название — по аналогии с перевернутой буквой T). Это когда у человека какой-то определенный скилл прокачан на хорошем уровне, но также есть и некоторые скиллы в смежных областях. Так вот, утверждается, что именно такие работники особо ценны, и я с этим утверждением полностью согласен.

Это применимо также и в программировании. Какой-то язык надо знать хорошо (не обязательно быть совсем уж суперпрофи в нем, но хороший уровень поддерживать надо). А какие-то другие языки можно знать на более поверхностном уровне.

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

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

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

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

V>Часто люди спрашивают в интернете, стоит ли учить такой-то язык программирования. И вот у меня возникла мысль.
Именно учить язык программирования не нужно вообще. Язык нужно учиться использовать для решения каких либо прикладных задач. Под каждую конкретную задачу будет оптимален определенный ЯП и определенная парадигма программирования. Соответственно нужно знать максимум парадигм, их границы применимости, достоинства и недостатки. И уметь применять эти парадигмы при необходимости на любом языке. А знания конкретного языка, на деле это нужно только для прохождения собеседования в говноконторы, где придется заниматься разгребанием дерьма.

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

G>>А где вариант "Один профессионально и несколько на среднем уровне"?

V>Вопрос специально поставлен так, чтобы не казалось, что можно выучить больше за тоже самое время, например:
V>1) Один профессионально и несколько на среднем уровне.
V>2) Несколько профессионально и ни одного на среднем уровне.
V>3) Несколько профессионально и несколько на среднем уровне.

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

Но ведь на практике требуется знание нескольких языков, один хорошо (типа твоя специализация) и несколько дополнительно. Например, у меня основная специализация — Java. Но по работе на разных местах и в разных компаниях мне приходилось дополнительно работать на C++, Питоне, HTML/CSS/JavaScript/TypeScript, Xslt/XPath, Delphi, C#, Visual Basic, Linux Bash, Perl, а про SQL я уже молчу, это вообще считается основой компьютерной грамотности. Поэтому сосредоточение на одном языке — это считаю в общем случае неправильным.

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

V>Часто люди спрашивают в интернете, стоит ли учить такой-то язык программирования. И вот у меня возникла мысль.

V>1) С одной стороны знать много языков программирования вроде как хорошо, широкий кругозор.
V>2) С другой это лишь отнимает силы от того, чтобы выучить хотя бы один язык, но профессионально.

Человеку вполне посильно выучить несколько языков на профессиональном уровне.

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

G>Это утопия, на рынке всегда будут иметь преимущество у более узких специалистов, которые владеют одним языком и парадигмой (а остальными языками и парадигмами более поверхностно), но владеют ими на голову выше чем такой вот разноплановый леонардо. А овладеть на экспертном уровне несколькими языками и парадигмами могут только единицы.
Что такое владение языком на экспертном уровне? Умение компилировать в уме граничные случаи какие, что любят проверять на собеседованиях? На экспертном уровне крайне неплохо знать предметную область, также на экспертном уровне нужно разбираться в исходниках проекта. Владение языком на экспертном уровне требуется исключительно разработчикам средств разработки, которые будут писать соответствующие анализаторы кода. Вот только это подразумевает владение предметной областью. Ну и сам разработчик конкретного языка тоже его знает на экспертном уровне, ибо он в курсах зачем это все сделано именно так, а не иначе.

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

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

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

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

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

V>>Часто люди спрашивают в интернете, стоит ли учить такой-то язык программирования. И вот у меня возникла мысль.
E>Именно учить язык программирования не нужно вообще. Язык нужно учиться использовать для решения каких либо прикладных задач. Под каждую конкретную задачу будет оптимален определенный ЯП и определенная парадигма программирования. Соответственно нужно знать максимум парадигм, их границы применимости, достоинства и недостатки. И уметь применять эти парадигмы при необходимости на любом языке. А знания конкретного языка, на деле это нужно только для прохождения собеседования в говноконторы, где придется заниматься разгребанием дерьма.

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

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

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

AA>Все равно, если работаешь на дядю будешь писать на яп который тебе предложат.


Ну этот самый "дядя" не даст человеку проект на Python,
если в резюме этот самый человек ему писал насчёт C++ или насчет .NET C#

То есть — если даже и даст, то далеко не сразу и (скорее всего) менее ответственные части.

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

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

H>Если оператор сравнения объектов сравнивает идентичность экземпляров объекта, тогда почему в первом случае будет true?

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

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

V>У профессионала как минимум программа:
V>1) Должна правильно работать.
V>2) Выполнять все возложенные на неё задачи.

1) ...и быть покрытой автотестами

И я бы добавил третий пункт:
3) Соответствовать best practices, clean code и парадигмам, без велосипедов и тайнописи

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

vsb>>Я не очень понимаю, что такое "выучить язык профессионально". Я знаю очень мало языков, которые можно "учить" долго. Это C++, Haskell, возможно Rust. Подавляющее число языков простые и для того, чтобы выучить их на 100% или около того, времени много не нужно.

V>Небольшая программа новичка может выглядеть точно так же, как программа профессионала, особенно если новичок грамотно использует подражание хорошему коду, но что насчёт роста программы.

V>У профессионала как минимум программа:
V>1) Должна правильно работать.
V>2) Выполнять все возложенные на неё задачи.

V>Звучит просто, но на деле это не просто.

V>По первому пункту программа может:
V>1) Не работать.
V>2) Работать неправильно.

V>Почему? Потому что её сговнякали на коленке, а не спроектировали. Не учитывали что и как она делает, как попало выделяли память и распределяли по коду данные, и всё в таком роде.

Проектирование к знанию языка не имеет никакого отношения. Знание языка это когда ты знаешь, чем for отличается от while.

V>По второму пункту программа может:
V>1) Не выполнять все возложенные на неё задачи.
V>2) Выполнять их через одно место.
V>3) Доставлять неудобство пользователю при работе с ней.

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

Это к делу вообще не относится.

V>Про ту же Java я читал статью где утверждалось, что она дескать не такая тормознутая, как о ней принято думать, просто программисты добавляют туда очень много абстракций, что сильно замедляет работу. Но если это так, то кому польза от этих абстракций? Уж явно не пользователям у которых всё подвисает после каждого действия, а по мере накопления данных работать в таких программах становится невозможно и ищутся аналоги.

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

Аналоги пользователь искать не может. Там, где применяется Java, софт пользователю спускается "сверху", решение принимает не пользователь, а менеджер, который с этой программой работать никогда не будет. Собственно отсюда корень бед и идёт, язык тут вообще не при чём.

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

S>Это очень крупная градация. Для языков типа С++ надо хотя бы 0-9, плюс разбиение на области: язык, стандартная библиотека, архитектура приложений, управление зависимости и сборка и т.п.
S>И Александреску и Страуструп говорили, что знают С++ на 7-8 по 10-бальное шкале, ЕМНИП. И это люди которые продают свои знания подводных камней этого языка. Потом "знание языка" != "хороший код".

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

Часто люди спрашивают в интернете, стоит ли учить такой-то язык программирования. И вот у меня возникла мысль.

1) С одной стороны знать много языков программирования вроде как хорошо, широкий кругозор.
2) С другой это лишь отнимает силы от того, чтобы выучить хотя бы один язык, но профессионально.

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

https://rsdn.org/poll/7808

Автор: velkin
Дата: 10.03.21
Вопрос: Что лучше, знать один язык программирования профессионально или несколько на среднем уровне?

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

G>А где вариант "Один профессионально и несколько на среднем уровне"?

Вопрос специально поставлен так, чтобы не казалось, что можно выучить больше за тоже самое время, например:
1) Один профессионально и несколько на среднем уровне.
2) Несколько профессионально и ни одного на среднем уровне.
3) Несколько профессионально и несколько на среднем уровне.

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

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

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

Все зависит от задач. А язык — это просто инструмент.
Определи круг задач для опроса.

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

K>Кстати, для того чтобы знать что-то из других языков — не обязательно их спецом изучать. Просто часто бывает так, что по работе столкнешься с какой-то новой незнакомой технологией — и тогда не надо сразу заявлять "мы таким делам вовсе не обучены", а можно попытаться хоть немного разобраться в ней. Возможно, возникшая задача окажется простой и некритичной, и поверхностных знаний для ее решения будет достаточно, зато появится дополнительный полезный опыт.

Я не знаю как компании оценивают уровень владения языками программирования и совпадает ли это с моей оценкой.
1) Джун (новичок)
2) Мидл (средний)
3) Сеньор (профи)

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

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

SIT>Все зависит от задач. А язык — это просто инструмент.
SIT>Определи круг задач для опроса.

Нет, нет, нет, всё не так просто. Для примера предположим человек выбрал C++, он знает все парадигмы этого языка. Ему можно заказывать всё что угодно, но именно в ограниченном круге задач. Если нужен хотя бы скриптовый язык, вроде Lua, Python, то предполагается, что он не может их использовать эффективно. Или, например, кто-то выбрал PHP, он может что угодно на нём сделать, никакая веб-программа на этом языке не является для него секретом. Но при этом никаких Ruby или ещё чего-то похожего, это не говоря уже про отдалённое.

Я как бы поставил умозрительное условие:
1) Или программист ограничен во всём, кроме одного языка программирования, но на нём он творит чудеса.
2) Или он этакий мастер на все руки, но идеального исполнения от него ждать не стоит.

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

V>Я как бы поставил умозрительное условие:
V>1) Или программист ограничен во всём, кроме одного языка программирования, но на нём он творит чудеса.
V>2) Или он этакий мастер на все руки, но идеального исполнения от него ждать не стоит.

Так и к чему относится твоё умозрение? Только не к реальной жизни...

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

V>Вопрос специально поставлен так, чтобы не казалось, что можно выучить больше за тоже самое время, например:

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

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

V>>Вопрос специально поставлен так, чтобы не казалось, что можно выучить больше за тоже самое время, например:

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

Императивщины мало знать, сейчас везде прёт функциональщина, асинхронщина, реактивщина, неблокировщина.

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

H>Какой отверткой лучше уметь пользоваться — плоской или крестообразной?

Соответствующей болту. Причем что касается крестообразных, желательно еще уметь не только различать размеры шлицов, но и отличать Phillips от Pozidriv, и выбирать правильную отвертку в зависимости от болта, а то все шлицы срежешь.

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

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

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

V>>Вопрос специально поставлен так, чтобы не казалось, что можно выучить больше за тоже самое время, например:
TB>Если один язык выучишь нормально, то дальше императивную логику, не требующую знания фишек языка, можешь спокойно писать на любом.

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

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

Pzz>Человеку вполне посильно выучить несколько языков на профессиональном уровне.

Можно, но если программист средний в каком-либо одном языке, то он может или выучить ещё один язык до среднего уровня, или повысить текущий до профи. На то и другое будет потрачено время, да и не факт, что запала хватит на всё. В мире более 8 тысяч языков программирования. Говорят, что фраза про 10 тыс. часов это профанация. Ну, а всё же, если посвятить улучшению 4 часа в сутки, тогда это 2.5 тыс. суток. Если заниматься каждый день, то это ≈6.85 лет. А если не каждый, а если меньше 4 часов. В топике всего лишь вопрос, кто что думает по этому поводу.

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

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

G>>А где вариант "Один профессионально и несколько на среднем уровне"?

V>А под изучением языка программирования понимается не только синтаксис, но и свои наработки в виде алгоритмов или библиотек алгоритмов, умение сразу же использовать данный язык для решения задач.
На самом деле без знания нескольких языков, просто невозможно программировать профессионально на одном.
Тот же C# развивается в разных направления. Linq аналог SQL, функциональщина ближе к F#
dynamic ближе к JS итд. Те же алгоритмы будут по разному использоваться

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

Pzz>>Человеку вполне посильно выучить несколько языков на профессиональном уровне.

V>Можно, но если программист средний в каком-либо одном языке, то он может или выучить ещё один язык до среднего уровня, или повысить текущий до профи. На то и другое будет потрачено время, да и не факт, что запала хватит на всё. В мире более 8 тысяч языков программирования. Говорят, что фраза про 10 тыс. часов это профанация. Ну, а всё же, если посвятить улучшению 4 часа в сутки, тогда это 2.5 тыс. суток. Если заниматься каждый день, то это ≈6.85 лет. А если не каждый, а если меньше 4 часов. В топике всего лишь вопрос, кто что думает по этому поводу.

Что ты называешь профессиональным владением языком?

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

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

Из 8000 языков, которые есть в мире, полезных и практически используемых и десятка не наберется. Остальные 9990 учить не обязательно.

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

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

V>Я не знаю как компании оценивают уровень владения языками программирования и совпадает ли это с моей оценкой.
V>1) Джун (новичок)
V>2) Мидл (средний)
V>3) Сеньор (профи)
Это очень крупная градация. Для языков типа С++ надо хотя бы 0-9, плюс разбиение на области: язык, стандартная библиотека, архитектура приложений, управление зависимости и сборка и т.п.
И Александреску и Страуструп говорили, что знают С++ на 7-8 по 10-бальное шкале, ЕМНИП. И это люди которые продают свои знания подводных камней этого языка. Потом "знание языка" != "хороший код".

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

SIT>Так и к чему относится твоё умозрение? Только не к реальной жизни...

Почему тогда не все поголовно профи, почему профи так мало, почему всякие конторы их так мучительно ищут? А это не говоря уже о том, что новичку до среднего тоже надо напрячься и как-то перейти на следующий уровень владения языком.

Я не очень понимаю, что такое "выучить язык профессионально". Я знаю очень мало языков, которые можно "учить" долго. Это C++, Haskell, возможно Rust. Подавляющее число языков простые и для того, чтобы выучить их на 100% или около того, времени много не нужно. Та же Java, на которой я пишу много лет, что её там учить, с минимальными усилиями к саморазвитию через год ты её будешь знать практически всю.

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

А прям быть специалистом по какой-нибудь подсистеме Альфабанка на мейнфрейме IBM S/390 — путь тупиковый, имхо, хотя и в нём есть свои плюсы, но и опасности.

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

vsb>Я не очень понимаю, что такое "выучить язык профессионально". Я знаю очень мало языков, которые можно "учить" долго. Это C++, Haskell, возможно Rust. Подавляющее число языков простые и для того, чтобы выучить их на 100% или около того, времени много не нужно.

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

У профессионала как минимум программа:
1) Должна правильно работать.
2) Выполнять все возложенные на неё задачи.

Звучит просто, но на деле это не просто.

По первому пункту программа может:
1) Не работать.
2) Работать неправильно.

Почему? Потому что её сговнякали на коленке, а не спроектировали. Не учитывали что и как она делает, как попало выделяли память и распределяли по коду данные, и всё в таком роде.

По второму пункту программа может:
1) Не выполнять все возложенные на неё задачи.
2) Выполнять их через одно место.
3) Доставлять неудобство пользователю при работе с ней.

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

Про ту же Java я читал статью где утверждалось, что она дескать не такая тормознутая, как о ней принято думать, просто программисты добавляют туда очень много абстракций, что сильно замедляет работу. Но если это так, то кому польза от этих абстракций? Уж явно не пользователям у которых всё подвисает после каждого действия, а по мере накопления данных работать в таких программах становится невозможно и ищутся аналоги.

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

E>Под каждую конкретную задачу будет оптимален определенный ЯП и определенная парадигма программирования.

С этим я согласен.

E>Соответственно нужно знать максимум парадигм, их границы применимости, достоинства и недостатки. И уметь применять эти парадигмы при необходимости на любом языке.

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

E>А знания конкретного языка, на деле это нужно только для прохождения собеседования в говноконторы, где придется заниматься разгребанием дерьма.

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

Я не пытаюсь агитировать за тот или иной вариант, а просто предлагаю остановиться и подумать. Люди же действуют так, как привыкли. Часто привыкают к чему-то неосознанно, не обязательно к лучшему варианту, а как сложилось по жизни.

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

G>>Это утопия, на рынке всегда будут иметь преимущество у более узких специалистов, которые владеют одним языком и парадигмой (а остальными языками и парадигмами более поверхностно), но владеют ими на голову выше чем такой вот разноплановый леонардо. А овладеть на экспертном уровне несколькими языками и парадигмами могут только единицы.

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

Владение на экспертном уровне, это когда не допускаются всякие хитрые баги, скажем, в Java, такие:

Integer a1 = 10;
Integer a2 = 10;
System.out.println(a1 == a2);

Выведет true.

Integer a1 = 10_000;
Integer a2 = 10_000;
System.out.println(a1 == a2);

Выведет уже false.
Хотя Khimik бы сделал вывод, как он недавно писал на форуме про аналогию, что, "по аналогии, мы здесь тоже ожидаем true", ведь 10 и 10_000 — оба целых числа, имеют вроде бы аналогичные свойства.

Эксперт же такой ошибки не допустит.

"Прелесть" таких багов в том, что они могут просочиться на прод и долгое время там жить, а разрабы проекта в силу эффекта Даннинга-Крюгера будут выдавать на гора такой вот код и считать что экспертом быть не нужно когда разрабатываешь промышленные системы. Приведенный пример конечно маловероятен, т.к. сравнение объектов по == само по себе является индикатором плохого кода, но в других областях, таких как многопоточность, транзакции, AOP, перформанс, там подобного рода ошибки из-за отсутствия экспертизы допускаются часто.

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

V>И опять же откуда берётся дерьмо, которое нужно разгребать? Ведь кто-то и когда-то его написал. Написал его тот, кто не был профессионалом. И вот теперь нужен профессионал, который может его разгрести.
Просто для сведения. У меня был в свое время проект, написанный профессионалами, которые язык знали бесконечно лучше меня. Если что, аутсорс контора была. Язык был Objective C, я на нем вообще не писал. Вот только этот профессионал такую спегетти там наворотил, что постоянно то память текла, то какие то баги странные. И так как баги меня лично достали, вынужден был разгребать до приемлемого уровня творчество этого профессионала. Разгреб только до уровня что баги прекратились, совсем красоту не наводил, единственное, что почикал копипаст, ну и повыпилил что одна функция делает 10 различных побочных эффектов. При этом я язык не изучал практически вообще, мельком пробежался по основам и если что непонятно, то гуглил. Соответственно профессиональным владением языком у меня там и не пахло. Единственное, почему я взялся, я нормально себя чувствовал в среде AppCode, там как раз вышла альфа версия, для написания UI тогда была не пригодна, а вот для рефакторингов годилось, практически для меня все было без дискомфорта, единственное что под виртуалкой приходилось не Ctrl кнопку нажимать, а Win, а так даже хоткеи те же самые.

И меня блин весьма повеселило кое что в этом году. У меня больше 10 лет опыта Java, с 4-й по 11-ю. Но последние 5 лет я пишу на JVM языках, Java кода там где то около процента, критичные места, где я хочу быть уверен что не будет какого оверхеда дополнительного, хотя все фреймворки и библиотеки использую вполне джавовские. Сказал про это, мне сказали что техническая часть команды не готовы собеседовать людей с такими перерывами в работе . То есть зарезали меня по резюме не HR, а именно что технари .

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

G>Эксперт же такой ошибки не допустит.
Конечно не допустит, на ровном месте сгородить boxing, использовать явный тип, а не var, плюс еще операция == не над примитивами. Основы любого языка, экспертного уровня даже близко не требуется. Более того, подобные фичи про кажется 256 кешируемых Integer — это как раз крайне вредное знание, ибо завязано оказывается на реализацию. Только это к языку никакого отношения не имеет. Можно было бы в свое время попасться действительно на приколы с реализацией substring от какой мегабайтной строки.

G>"Прелесть" таких багов в том, что они могут просочиться на прод и долгое время там жить, а разрабы проекта в силу эффекта Даннинга-Крюгера будут выдавать на гора такой вот код и считать что экспертом быть не нужно когда разрабатываешь промышленные системы. Приведенный пример конечно маловероятен, т.к. сравнение объектов по == само по себе является индикатором плохого кода, но в других областях, таких как многопоточность, транзакции, AOP, перформанс, там подобного рода ошибки из-за отсутствия экспертизы допускаются часто.
Такие ошибки проскакивают в 99 процентах случаях исключительно по невнимательности. И ловить подобное нужно тестированием, а не внимательностью. Причем тестировать под разными платформами и разными конфигурациями. Более того, подобные баги по большому счету нормальны, ибо весьма интересное плавающее поведение можно найти где угодно, в любой сторонней библиотеке случаются очень интересные приколы. Довольно большое количество весьма курьезных случаев могу вспомнить, когда причина была именно в ошибочной сторонней либе, причем еще и в стандартной библиотеке приколы случаются. А вот случаев, когда кто то именно не знал какого то поведения, такого на практике вспомнить вообще не могу. Тупо невнимательность в основном, надежда на то, что другие пишут без багов .

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

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

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

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

G>Ошибка выжившего? Я вот наоборот, встречал как целые проекты, которые разрабатывались без знания фундаментальных вещей, например кастомная БД-прослойка, не умеющая в транзакции, т.к. авторы не знали что это такое, так и просто какие-то эпизодические баги, бутылочные горлышки или техдолг. Поэтому проблему экспертных знаний считаю не надуманной, а реальной. Да и сам часто натыкаюсь на подобные проблемы уже в своем лице.
Транзакции — это не экспертные знания, это основы. Бутылочные горлышки прекрасно видны в профайлере. Вот только проблема, так как на собеседовании умение пользоваться профайлером не проверяют, то процентов 90 разработчиков даже среднего уровня даже не знает как это запускать и даже по каким ключевым словам гуглить. Техдолг — да, есть такое, встречается. Но снова никакого отношения к экспертному уровню владения языком это не имеет. Чаще всего это недостаток времени, плюс обоснованное нежелание лезть туда, что работает. Для эффективного программирования действительно нужно знать и уметь до черта. Вот только именно язык программирования сюда если и входит, то с огромной натяжкой и далеко не на первом месте. Более важен навык поиска ошибки на любом языке, а также умение писать так, чтобы минимизировать как появление ошибки, так и минимизировать возможные последствия появления ошибки, а также максимально быстрое обнаружение ошибки.

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

G>>Ошибка выжившего? Я вот наоборот, встречал как целые проекты, которые разрабатывались без знания фундаментальных вещей, например кастомная БД-прослойка, не умеющая в транзакции, т.к. авторы не знали что это такое, так и просто какие-то эпизодические баги, бутылочные горлышки или техдолг. Поэтому проблему экспертных знаний считаю не надуманной, а реальной. Да и сам часто натыкаюсь на подобные проблемы уже в своем лице.
E>Транзакции — это не экспертные знания, это основы. Бутылочные горлышки прекрасно видны в профайлере. Вот только проблема, так как на собеседовании умение пользоваться профайлером не проверяют, то процентов 90 разработчиков даже среднего уровня даже не знает как это запускать и даже по каким ключевым словам гуглить. Техдолг — да, есть такое, встречается. Но снова никакого отношения к экспертному уровню владения языком это не имеет. Чаще всего это недостаток времени, плюс обоснованное нежелание лезть туда, что работает. Для эффективного программирования действительно нужно знать и уметь до черта. Вот только именно язык программирования сюда если и входит, то с огромной натяжкой и далеко не на первом месте. Более важен навык поиска ошибки на любом языке, а также умение писать так, чтобы минимизировать как появление ошибки, так и минимизировать возможные последствия появления ошибки, а также максимально быстрое обнаружение ошибки.

Пожалуй да, я наверное стал рассматривать общие экспертные знания, а если говорить именно об экспертном знании только грамматики и семантики языка программирования, да ещё и выкинуть API, библиотеки и фреймворки из рассмотрения, то возможно тут ты действительно прав.

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

E>У меня был в свое время проект, написанный профессионалами, которые язык знали бесконечно лучше меня. Если что, аутсорс контора была. Язык был Objective C, я на нем вообще не писал. Вот только этот профессионал такую спегетти там наворотил, что постоянно то память текла, то какие то баги странные.

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

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

V>... почему всякие конторы их так мучительно ищут?

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

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

G>Пожалуй да, я наверное стал рассматривать общие экспертные знания, а если говорить именно об экспертном знании только грамматики и семантики языка программирования, да ещё и выкинуть API, библиотеки и фреймворки из рассмотрения, то возможно тут ты действительно прав.

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

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

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

Может ли человек быть профессионалом во всём? Хотелось бы верить, но скорее всего он не будет профессионалом ни в чём. И проблемы начнут проявляться не на хеллоу ворлдах и учебных примерах, а на больших программах, которые бесконтрольно разрастаются непонятно во что.

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

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

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

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

G>>Пожалуй да, я наверное стал рассматривать общие экспертные знания, а если говорить именно об экспертном знании только грамматики и семантики языка программирования, да ещё и выкинуть API, библиотеки и фреймворки из рассмотрения, то возможно тут ты действительно прав.

V>Так понятно, что люди топят за некоторые универсальные шаблоны и прочее, но их нет. Для конкретного языка не существует абстрактного шаблона проектирования и не существует абстрактных архитектур или абстрактного функционала. Я об этом прямо в топике написал, потому что это важно.

V>Хотя аргументы в стиле и чтец, и жнец и на дуде игрец тоже стоит послушать, для того и создан топик. Пока противники профессионализма меня лишь убедили, что новички, а то и среднячки запросто напишут говнокод. Была попытка обозвать их профессионалами, чтобы опорочить последних, но нет, те кто пишут говнокод не профессионалы.

V>На одном языке программирования наговнокодил, на другом наговнокодил, на третьем наговнокодил. В чём тогда преимущества владения множеством языков программирования? А появляется говнокод не просто от отсутствия времени, как любят некоторые говорить, а от отсутствия необходимого опыта на получение которого по сути тоже нужно время, причём очень много.

V>Может ли человек быть профессионалом во всём? Хотелось бы верить, но скорее всего он не будет профессионалом ни в чём. И проблемы начнут проявляться не на хеллоу ворлдах и учебных примерах, а на больших программах, которые бесконтрольно разрастаются непонятно во что.

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

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

V>Не профессионал их не знает. Более того, по аналогии с конструкциями и алгоритмами из одного языка программирования будет работать с другими. А они не будут работать так же, это не говоря уже о том, что возможно их и не стоило использовать так же.

Соглы. Это всё приводит к тому, что профессионал — это тот, кто "в теме", пропитан zeitgeist, о чем ещё Голубицкий писал.
А то ведь бывает, что профессионал из одной области начинает писать код на другом языке, и тот даже работает, но поддерживать его невозможно, потому человек привнёс zeitgeist из другой сферы, например из ассемблера в джава энтерпрайз, или даже внутри джавы — из хардкорного DDD в анемичный мейнстрим. Несколько раз такое видел.

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

V>Так стоит ли распыляться.
стоит конечно. как определить что яп достоин дальнейшего изучения/использования.
методом проб и ошибок. с оглядкой на авторитеты. Если мне советуют изучить CL для расширения сознания я прислущаюсь.
CL офигенный мощный как C++ но при этом простой как бейсик. пару минусов: малая распространненость, заточенность под опенсорс(линукс, веб, постгрес).
чуть меньгая скорость выполнения. мультипарадигменный.
или взять F#. ЯП помогает писать правильно. используя строгую типизацию, иммутабильность и экспрешн.
Правда, потом понимаешь что скорость важна, но всякие плюсы вызвают рвоту. так начинаешь поглядывать на rust.
Чуть сложнее F#, но в то же время такой же быстрый как си.
Вообщем, благословляю.
Все равно, если работаешь на дядю будешь писать на яп который тебе предложат.

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

УП>Твои градации — это какая-то академическая задача, не имеющая практического смысла. Реально же градации 2: можешь писать прикладной код, и можешь писать заумь вроде некоторых бустовских библиотек.
Твой ответ — наглядная демонстрация того, что далеко не все понимают, насколько разными могут быть требования к прикладному коду.

УП>И в большинстве случаев первый вариант вполне достаточен.
Как ты оцениваешь "большиство" мест?

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

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

G>Императивщины мало знать, сейчас везде прёт функциональщина, асинхронщина, реактивщина, неблокировщина.

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

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

V>В каком-то роде я задал вопрос, что лучше, быть мидлом в нескольких языках, или сеньором в одном.

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

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

G>Владение на экспертном уровне, это когда не допускаются всякие хитрые баги, скажем, в Java, такие:
G>

G>Integer a1 = 10;
G>Integer a2 = 10;
G>System.out.println(a1 == a2);
G>

G>Выведет true.

G>

G>Integer a1 = 10_000;
G>Integer a2 = 10_000;
G>System.out.println(a1 == a2);
G>

G>Выведет уже false.
G>Хотя Khimik бы сделал вывод, как он недавно писал на форуме про аналогию, что, "по аналогии, мы здесь тоже ожидаем true", ведь 10 и 10_000 — оба целых числа, имеют вроде бы аналогичные свойства.

G>сравнение объектов по == само по себе является индикатором плохого кода

Если оператор сравнения объектов сравнивает идентичность экземпляров объекта, тогда почему в первом случае будет true?

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

G>>Императивщины мало знать, сейчас везде прёт функциональщина, асинхронщина, реактивщина, неблокировщина.

H>Асинхронные и неблокирующие операции не противоречат императивной парадигме, а прекрасно в неё укладываются.

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

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

G>>Владение на экспертном уровне, это когда не допускаются всякие хитрые баги, скажем, в Java, такие:
G>>

G>>Integer a1 = 10;
G>>Integer a2 = 10;
G>>System.out.println(a1 == a2);
G>>

G>>Выведет true.

G>>

G>>Integer a1 = 10_000;
G>>Integer a2 = 10_000;
G>>System.out.println(a1 == a2);
G>>

G>>Выведет уже false.
G>>Хотя Khimik бы сделал вывод, как он недавно писал на форуме про аналогию, что, "по аналогии, мы здесь тоже ожидаем true", ведь 10 и 10_000 — оба целых числа, имеют вроде бы аналогичные свойства.

G>>сравнение объектов по == само по себе является индикатором плохого кода

H>Если оператор сравнения объектов сравнивает идентичность экземпляров объекта, тогда почему в первом случае будет true?

Это как раз та проблема экспертных знаний, о которой я говорю. Чтобы понять этот код, мало обычной логики и здравого смысла, нужны ещё и тайные знания (ну не совсем тайные, но — особые знания о работе платформы Java, усложняющие семантику языка). И считаю это — плохо.

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

H>Если оператор сравнения объектов сравнивает идентичность экземпляров объекта, тогда почему в первом случае будет true?

И после этого ругают javascript

Лучший ЯП для обучения это common lisp простой как бейсик, мощный как плюсы, работает везде. мультипарадигменный (В отличии от жабы в которой даже инты объекты, в сишарпе хотя бы сравниваются по значению)

(loop for i from 1 to 100 do
        (format t "~d~%" i))

(defstruct person name age)

(defvar p (make-person :name "Alice" :age 12))

(write-line (person-name p))

обнаружил довольно простой и удобный способ работы с лиспом в вс кодэ.
достаточно установить любую подсветку синтаксиса и интерпритатор(в линуксе лучше запускать через rlwrap).
во встроенном терминале. а потом выделяем текст и через палитру комманд (run selected text in active terminal).
это конечно не очень круто но зато быстро(не нужно изучать емакс и настройку SLIME).
Ну а вторым нужно учить rust. строгая типизация, системный, основан на выражениях (if и т.п. полноценные выражения).
говорят слишком мелкие пакеты и непонятная работа с ошибками. но в базе я попробовал сегодня повторить пример игры угадай число из раста-бук — мне понравилось.
но, как уже говорил, жизнь конечно внесет свои коррективы, хотя если стремится к мечте то можно и на любимом ЯП писать.

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

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

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

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

void do_read_header()
  {
    auto self(shared_from_this());
    boost::asio::async_read(socket_,
        boost::asio::buffer(read_msg_.data(), chat_message::header_length),
        [this, self](boost::system::error_code ec, std::size_t /*length*/)
        {
          if (!ec && read_msg_.decode_header())
          {
            do_read_body();
          }
          else
          {
            room_.leave(shared_from_this());
          }
        });
  }

  void do_read_body()
  {
    auto self(shared_from_this());
    boost::asio::async_read(socket_,
        boost::asio::buffer(read_msg_.body(), read_msg_.body_length()),
        [this, self](boost::system::error_code ec, std::size_t /*length*/)
        {
          if (!ec)
          {
            room_.deliver(read_msg_);
            do_read_header();
          }
          else
          {
            room_.leave(shared_from_this());
          }
        });
  }

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

AA>Лучший ЯП для обучения это common lisp простой как бейсик, мощный как плюсы, работает везде. мультипарадигменный (В отличии от жабы в которой даже инты объекты, в сишарпе хотя бы сравниваются по значению)

Должна быть какая-то причина, по которой он заглох, кроме "тупые эффективные манагеры так решили" (что не обьясняет ровным счетом ничего). Видимо, примитивный синтаксис и семантика eval/apply хорошо подходили, когда не было компиляторов и интерпретаторов более сложных грамматик. Как только появились, от скобочек стало рябить в глазах, а от префиксной нотации мозг стал уставать. И никакие макры и мультиметоды не спасли язык.

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

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

AA>>Лучший ЯП для обучения это common lisp простой как бейсик, мощный как плюсы, работает везде. мультипарадигменный (В отличии от жабы в которой даже инты объекты, в сишарпе хотя бы сравниваются по значению)

__>Должна быть какая-то причина, по которой он заглох, кроме "тупые эффективные манагеры так решили" (что не обьясняет ровным счетом ничего). Видимо, примитивный синтаксис и семантика eval/apply хорошо подходили, когда не было компиляторов и интерпретаторов более сложных грамматик. Как только появились, от скобочек стало рябить в глазах, а от префиксной нотации мозг стал уставать. И никакие макры и мультиметоды не спасли язык.

Не соглащусь насчет заглох, не популярен — да, но развивается и очень активно. и используется.
Проблема непопулярных языков в статьях типа "что учить в 2021 году?" в которых из года в год публикуются поисковые тренды (js, c, java).
Если не знаешь о чем-то, то его и не существует или как говорят что может быть слаще морковки.
насчет рябить это не к лиспу а к ЯП типа плюсов или раста. вот уже где кол-во символов зашкаливает.
а скобок одинаково (hello "Alice"), hello("Alice");
и там и там скобок ровно две, только в плюсах еще и разделители, которые вообщем-то не нужны при наличии четких правил синтаксических.
Повторю свое мнение, что в лиспы легко въехать и на его базе изучить конпцепции программирования базовые: алгоритмы, ООП, ФП, рекурсию, вектора, списки и т.д.
от изучения до написания первой рабочей программы там требуется от силы 1-2 недели. в отличии от плюсов тех же.

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

P>Числа до 100 вроде в жаве объявлены как константы, поэтому в первом случае а1 и а2 будут ссылаться на один существуюший объект, а во втором создадут по новому объекту каждый. Такие вот спрятаные грабли для тех кто с этим не сталкивался

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