Ok, думаю, теперь лучше стало понятно, что вы имели в виду. Призывы переводить компанию, которая уже пишет на языке X и имеет большой штат программистов им владеющих, на какой-то другой ЯП действительно выглядят весьма странно.
На C++ не так сложно писать, как лет 10 назад.
Ну, может, как-нибудь загляну поизучать современный C++. Пока меня Rust устраивает в качестве альтернативы. Но допускаю, что и в C++ действительно стало сильно лучше, чем было. С годами вы почти угадали, наверно даже на пару лет больше, чем 10, уже прошло))
Ну, к примеру: Ruby, Elixir, Rust, JavaScript, C# Как тут уже написали, SQL тоже можно посчитать, хотя вряд ли кто сейчас активно хранимки на нём пишет. А чисто запросы, наверно, на полноценный ЯП не тянут. HTML и CSS, пожалуй, тоже не стоит в этот список включать))
А вообще, конкретный набор не столь важен. Важно, чтобы они были разноплановые, в разных парадигмах. Потому что переключаться между языками в рамках одной парадигмы - это вообще дело техники.
P.S. Термин "владеть" для простоты определим как "мочь решать задачи бизнеса при помощи данного ЯП". Какого-то супер-пупер олимпиадного уровня знаний каждого закоулочка стандартной библиотеки и всей экосистемы я не вкладывал в этот термин.
Ну, вы как-то странно сначала назвали всех, кто выбирает не C++ недопрограммистами, а потом C++ программистов выставляете какими-то тугоумами, которым тяжело другой язык освоить.
В моём понимании Senior Software Engineer должен нормально владеть хотя бы 5 языками программирования, а шапочно знаком быть ещё с большим кол-вом. Иначе он тупо не сможет выбирать стек, наиболее подходящий под задачу и будет как в анекдоте микроскопом гвозди заколачивать, а значит и лычку Senior не заслуживает. Поэтому по первому вопросу - да, я считаю, что сеньору легко взять и перейти на другой язык.
Что касается аргументов "ЗА", они зависят от конкретной ситуации. В подавляющем большинстве веб-проектов большая часть времени уходит на IO - работу с СУБД, файлами, внешними сервисами и т.д. Поэтому разумнее для большинства проектов выбирать те языки, на которых проще описывать бизнес-логику с минимальным кол-вом синтаксического шума.
С++ имеет смысл рассмотреть для отдельных сервисов в проектах с целевой нагрузкой более 10k rps. И да, на нём действительно сложно писать. Я вполне осознанно его забросил, потому что мне не нравится отвлекаться на ручное управление памятью и помнить 100500 случаев, когда возможно UB. Это создаёт когнитивную нагрузку, которая сильно отвлекает вас от основной логики проекта, замечаете вы это или нет. Когда стоит цель выжать из имеющейся железки максимум, например, при написании AAA-игры, этот tradeoff оправдан. Но когда вы за все ваши неудобства получите +5% или, если повезёт, +10% к производительности вашего веб-приложения (а на приложениях с нагрузками порядка 100-1000 rps так и будет по факту), то C++ неудачный выбор.
Если бы это было правдой, то до сих пор был бы такой набор языков: Fortran, Lisp, Cobol, Basic, Pascal, C++, Smalltalk, Ada.
Последующие языки появились как раз из-за наличия в вышеперечисленных неудобств и неэффективностей. Подумайте об этом. Зачем вам новомодный C++, когда есть проверенный временем Fortran?
ощущение от знания С++ - как будто выучил китайский язык в мире ЯП
Да ну, на аналогию с китайским скорее уж Haskell тянет. С++ не особо отличается от большинства мейнстримовых языков, хотя бы потому, что они почти все из одного языкового семейства "С-подобных". С++ скорее на французский похож - при первом знакомстве непонятно зачем половина написанных символов нужна xD
Я понял не так. Я думаю, эксперты нужны для того, чтобы судья приняла во внимание их экспертное заключение. А будет оно базироваться на 100 аккаунтах или на миллионе на трудозатраты судьи по идее не повлияет. А перепроверять экспертов вроде не входит в полномочия судьи, она то может в этом вообще не разбираться, т.к. это не её область.
Да дело то не в отрицании. Просто язык тем лучше, чем больше он даёт механизмов защиты от этой кривизны и лени. И тем хуже, чем легче словить последствия от них.
Тем не менее, через 3 месяца после выхода Go 1.0 она уже была. А сколько лет с релиза D 1.0 прошло до включения в GCC?
а дженерики не раскалывают сообщество
Потенциально раскалывают. Но языку уже 10 лет, теперь он может себе позволить хоть несовместимую версию 2.0 выпустить, это уже не сильно заафектит его популярность.
Всё, что вы перечислили, на популярность не влияет вообще.
Поделитесь тогда своим мнением почему D настолько непопулярен?
В этом я могу вас понять. Но D, к сожалению, закопали сами разработчики, сначала расколов и так небольшое комьюнити на Phobos и Tango прям аккурат в момент релиза 1.0. А потом и полгода не прошло, как бросились вторую мажорную версию языка пилить. В довершение ко всему этому ещё и не уловили тренд на OpenSource. Тем самым отложив интеграцию с gcc лет на 10.
А программисту хочется хотя бы иметь ощущение, что авторы ЯП понимают, что они делают, и придерживаются хоть какой-то генеральной линии. Возможно, в этом и причина популярности Go. Да, генеральная линия его разработчиков - треш и угар, но они неукоснительно её придерживались, как минимум, 8 лет.
Ну, там основной смысл в том, что вы можете начать думать в терминах процессов - на верхнем уровне всё есть процесс. Когда это реализуется на уровне отдельной библиотеки, то такого кайфа уже не будет. Так как авторы других библиотек далеко не всегда будут поддерживать эту модель.
Я вообще за минимальный и тупой язык
Как же вы с Haskell уживаетесь? Я бы не назвал его ни минималистичным, ни тупым.
Лично мне распределённый STM больше понравился.
По-моему, DSTM, как и CloudHaskell, тоже давно заброшен.
Жаль. Строго типизированные акторы были бы интересны. Но это, наверно, на уровне самого языка надо делать, т.к. объём работ большой и авторы отдельной библиотеки на одном энтузиазме далеко не уедут.
Don’t worry. Мы уже выше разобрались кто что имел в виду. Всё ok)
Ok, думаю, теперь лучше стало понятно, что вы имели в виду. Призывы переводить компанию, которая уже пишет на языке X и имеет большой штат программистов им владеющих, на какой-то другой ЯП действительно выглядят весьма странно.
Ну, может, как-нибудь загляну поизучать современный C++. Пока меня Rust устраивает в качестве альтернативы. Но допускаю, что и в C++ действительно стало сильно лучше, чем было. С годами вы почти угадали, наверно даже на пару лет больше, чем 10, уже прошло))
Ну, к примеру: Ruby, Elixir, Rust, JavaScript, C#
Как тут уже написали, SQL тоже можно посчитать, хотя вряд ли кто сейчас активно хранимки на нём пишет. А чисто запросы, наверно, на полноценный ЯП не тянут. HTML и CSS, пожалуй, тоже не стоит в этот список включать))
А вообще, конкретный набор не столь важен. Важно, чтобы они были разноплановые, в разных парадигмах. Потому что переключаться между языками в рамках одной парадигмы - это вообще дело техники.
P.S. Термин "владеть" для простоты определим как "мочь решать задачи бизнеса при помощи данного ЯП". Какого-то супер-пупер олимпиадного уровня знаний каждого закоулочка стандартной библиотеки и всей экосистемы я не вкладывал в этот термин.
Ну раз уживаются, значит они, как минимум, не считают расты, питоны и явы недоязыками. А это уже совсем другой разговор.
Ну, вы как-то странно сначала назвали всех, кто выбирает не C++ недопрограммистами, а потом C++ программистов выставляете какими-то тугоумами, которым тяжело другой язык освоить.
В моём понимании Senior Software Engineer должен нормально владеть хотя бы 5 языками программирования, а шапочно знаком быть ещё с большим кол-вом. Иначе он тупо не сможет выбирать стек, наиболее подходящий под задачу и будет как в анекдоте микроскопом гвозди заколачивать, а значит и лычку Senior не заслуживает. Поэтому по первому вопросу - да, я считаю, что сеньору легко взять и перейти на другой язык.
Что касается аргументов "ЗА", они зависят от конкретной ситуации. В подавляющем большинстве веб-проектов большая часть времени уходит на IO - работу с СУБД, файлами, внешними сервисами и т.д. Поэтому разумнее для большинства проектов выбирать те языки, на которых проще описывать бизнес-логику с минимальным кол-вом синтаксического шума.
С++ имеет смысл рассмотреть для отдельных сервисов в проектах с целевой нагрузкой более 10k rps.
И да, на нём действительно сложно писать. Я вполне осознанно его забросил, потому что мне не нравится отвлекаться на ручное управление памятью и помнить 100500 случаев, когда возможно UB. Это создаёт когнитивную нагрузку, которая сильно отвлекает вас от основной логики проекта, замечаете вы это или нет.
Когда стоит цель выжать из имеющейся железки максимум, например, при написании AAA-игры, этот tradeoff оправдан. Но когда вы за все ваши неудобства получите +5% или, если повезёт, +10% к производительности вашего веб-приложения (а на приложениях с нагрузками порядка 100-1000 rps так и будет по факту), то C++ неудачный выбор.
Если бы это было правдой, то до сих пор был бы такой набор языков:
Fortran, Lisp, Cobol, Basic, Pascal, C++, Smalltalk, Ada.
Последующие языки появились как раз из-за наличия в вышеперечисленных неудобств и неэффективностей. Подумайте об этом. Зачем вам новомодный C++, когда есть проверенный временем Fortran?
Как-то вы непоследовательны. Каллиграфия то вообще к конкретному языку отношения не имеет. Она есть для всех языков с письменностью.
Да ну, на аналогию с китайским скорее уж Haskell тянет. С++ не особо отличается от большинства мейнстримовых языков, хотя бы потому, что они почти все из одного языкового семейства "С-подобных".
С++ скорее на французский похож - при первом знакомстве непонятно зачем половина написанных символов нужна xD
Согласен, в диапазоне $40-$70/час вполне можно найти хороших специалистов, которые возможно и 100+ часов в месяц смогут уделить, а не как агенство.
А что не так? Слабая статическая типизация)
Я понял не так. Я думаю, эксперты нужны для того, чтобы судья приняла во внимание их экспертное заключение. А будет оно базироваться на 100 аккаунтах или на миллионе на трудозатраты судьи по идее не повлияет. А перепроверять экспертов вроде не входит в полномочия судьи, она то может в этом вообще не разбираться, т.к. это не её область.
Ух-ты, целых 100 аккаунтов? Просто космический объём работы и потрясающая репрезентативность исследования!!!1!1!
Ну вот, сначала 64 Mb - неинтересно, а потом удивляетесь, почему Java за прожорливость недолюбливают.
Да дело то не в отрицании. Просто язык тем лучше, чем больше он даёт механизмов защиты от этой кривизны и лени. И тем хуже, чем легче словить последствия от них.
Тем не менее, через 3 месяца после выхода Go 1.0 она уже была. А сколько лет с релиза D 1.0 прошло до включения в GCC?
Потенциально раскалывают. Но языку уже 10 лет, теперь он может себе позволить хоть несовместимую версию 2.0 выпустить, это уже не сильно заафектит его популярность.
Поделитесь тогда своим мнением почему D настолько непопулярен?
Могу предложить вам попробовать Elixir. Сообщество дружелюбное, теоркат знать не требуют, инструментарий удобный: iex, mix, hex.
В этом я могу вас понять. Но D, к сожалению, закопали сами разработчики, сначала расколов и так небольшое комьюнити на Phobos и Tango прям аккурат в момент релиза 1.0. А потом и полгода не прошло, как бросились вторую мажорную версию языка пилить. В довершение ко всему этому ещё и не уловили тренд на OpenSource. Тем самым отложив интеграцию с gcc лет на 10.
А программисту хочется хотя бы иметь ощущение, что авторы ЯП понимают, что они делают, и придерживаются хоть какой-то генеральной линии. Возможно, в этом и причина популярности Go. Да, генеральная линия его разработчиков - треш и угар, но они неукоснительно её придерживались, как минимум, 8 лет.
Да, они. Но к JVM у меня какая-то личная неприязнь. Всё, что я на ней видел, имело медленный старт и дико жрало память.
Возможно, в Akka.NET тоже что-то подобное есть, но до F# я пока не добрался)
Ну, там основной смысл в том, что вы можете начать думать в терминах процессов - на верхнем уровне всё есть процесс. Когда это реализуется на уровне отдельной библиотеки, то такого кайфа уже не будет. Так как авторы других библиотек далеко не всегда будут поддерживать эту модель.
Как же вы с Haskell уживаетесь? Я бы не назвал его ни минималистичным, ни тупым.
По-моему, DSTM, как и CloudHaskell, тоже давно заброшен.
Жаль. Строго типизированные акторы были бы интересны. Но это, наверно, на уровне самого языка надо делать, т.к. объём работ большой и авторы отдельной библиотеки на одном энтузиазме далеко не уедут.