Статей с подобными заголовками существует уже множество. Но в них постоянно какая-то дичь! Смотрите, Google ещё до основных результатов советует такое:
HCL, Карл! Язык, который не просто очень далёк от «Самых Популярных», но ещё и создан для конфигурации, так что его вообще странно ставить в один ряд с языками общего назначения. Страшно представить приключения новичка, который решит строить карьеру по таким советам. Начнём с того, что по запросу «как выучить HCL» вместо туториалов по языку вылезают тексты о соляной кислоте.
Это только одна из многих дикостей, которые я встретил в подобных текстах. Поэтому захотелось объяснить, что с ними не так — и написать собственный текст получше, ссылку на который можно кидать начинающим. Конечно, аудитории Хабра информация для начинающих не очень требуется, зато хабравчане могут дополнить текст в комментариях, сделав его ещё полезнее.
Оглавление
В чём проблемы
Тексты «какие языки учить» зачастую такие слабые, что опытные разработчики разнесли бы их в пух и прах, но опытные разработчики их просто не открывают. Их открывают новички, у которых нет компетенции, чтобы заметить подвох. В результате новички доверяют всякой ерунде, а проблемы в текстах остаются незамеченными и процветают. Что именно это за проблемы?
Проблема первая: отсутствие содержания. Похоже, иногда эти тексты пишут люди, не имеющие о программировании никакого представления, и они ухитряются писать целые абзацы, в которых не сказано вообще ничего.
Пример: «На сегодняшний день многие студенты выбирают JavaScript в качестве проводника в мир технологий. И правильно делают, ведь человек, знающий JavaScript, вряд ли останется без дела. Популярность и практичность этого языка позволяют ему занять одно из лидирующих мест в списке языков, необходимых к изучению.
Однако также стоит учесть, что JavaScript – это один из наиболее популярных языков программирования. А это значит, что на него существует как достаточный спрос, так и огромное количество предложений. Поэтому если вы изучаете или хотите изучить этот язык, то постарайтесь максимально в нем разобраться и стать отличным специалистом».
Проблема вторая: закидывание читателя мелочами без объяснения главного.
Представьте, что человек захотел впервые купить автомобиль. Он ещё не вполне понимает, какие есть варианты кузовов, приводов и коробок передач. А ему с ходу вываливают список из десяти машин, где смешано в кучу всё: внедорожники, малолитражки, грузовики. И вместо пояснений о том, в чём их принципиальные различия, пишут набор разрозненных фактов вроде «у этого автомобиля есть защита картера». Сильно ли это поможет человеку?
А с текстами о языках происходит именно так. Похоже, когда кому-то ставят задачу написать про них, зачастую автор гуглит по пять случайных фактов про каждый и уверенно идёт за гонораром.
Пример: «Go использовался для создания Ethereum». Что, серьёзно, вот это самая важная информация про язык (когда речь идёт не о Solidity)? Вот она поможет сделать правильный выбор?
Проблема третья: сообщают вещи, которые начинающим попросту ничего не скажут.
Пример: «Недостатки Python: нет таких модификаторов доступа, как protected, private и public».
Так и представляется картина маслом. Школьница Василиса Пупкина, ещё почти ничего не понимающая в программировании, пытается выбрать себе первый язык. Читает такое описание и говорит: «а, ну раз нет модификатора protected, конечно, я предпочту C#». Ну камон, неужели не ясно, что подобная информация даст Василисе только ощущение «всё это программирование непонятная хрень, лучше послушаю песню "Валенки"»?
Проблема четвёртая: бездумное следование рейтингам популярности языков. «А-а-а, Go поднялся в индексе TIOBE на несколько строчек, срочно учим его!» Ну слушайте, а ещё по TIOBE получается, что обучающий язык Scratch обошёл Dart — и что теперь, дартовикам надо срочно перейти на детский язык, что ли?
Все эти пузомерки очень условные: результат зависит от того, какую метрику использовать. Поэтому не надо молиться на конкретные места в рейтингах, будто это какая-то спущенная свыше истина. Да, популярность языка имеет значение (по популярным больше справочного материала и вакансий), но не требуется разбираться «какой самый главный в мире», из ряда самых известных подойдёт любой. А чтобы найти эти «самые известные», не требуется лезть в рейтинги, они и так на слуху.
Пример: «В некоторых списках Python фигурирует на 5-ом месте, в других его ставят на 2-ое».
Проблема пятая: за всем перечисленным порой забывают про области применения, а для новичков это может быть важнее всего. Представим, что школьница Василиса, которая каждый день пользуется кучей мобильных приложений, захотела сделать своё собственное. Какая ей тогда разница, какие модификаторы доступа у Python, кто кого обошёл в рейтингах и на чём написан Ethereum? Всё, что ей надо знать — на чём пишут для iOS и для Android.
Поэтому вот текст, который пробует от всего этого уйти:
Вступление
Дорогой читатель! В интернетах можно увидеть прорву дискуссий, где опытные разработчики спорят, какой язык лучше всех. Не надо вестись на это: лучшего нет. Разные лучше подходят для разных задач и людей.
Поэтому для начала надо понять свои задачи. Из-за чего вообще встал вопрос выбора языка? Захотелось делать что-то конкретное (игры, сайты, мобильные приложения)? Или важно как можно скорее получить работу в IT любой ценой, что бы ни пришлось кодить? Или хочется просто попробовать «посмотрим, интересно ли мне окажется, а там как пойдёт»?
Если хочется заниматься чем-то определённым — тогда важнее не теоретические сравнения языков, а то, какие используются конкретно в этой области. Часть информации об этом можно получить из текста ниже, но есть смысл и погуглить «what languages are used for %интересующая_область%».
Если важно как можно скорее пройти путь до получения работы, тогда тоже важнее текстов-сравнений может оказаться другая вещь. Стоит посмотреть на сайте вроде HeadHunter вакансии Junior-разработчиков своего города: какие языки чаще всего упоминаются в них?
А если нет ни спешки, ни определённого запроса, тогда спрошу так: есть ли потребность делать что-то такое, что пользователь видит глазами? Работа над веб-сервисами делится на фронтенд и бэкенд. Грубо говоря, фронтенд — это «что видно в браузере», а бэкенд — это «что выполняется далеко на сервере, чтобы фронтенду было что показывать». Когда пользователь нажимает на кнопку, её поведение прописал фронтендер — но если это кнопка «перейти к диалогу» и надо показать историю переписки, то дальше бэкенд извлечёт сообщения из базы данных на сервере.
Так что разработчикам-фронтендерам при работе над кодом приходится задумываться о том, как выглядит пользовательский интерфейс, а вот бэкендерам — только непосредственно о коде. Кому-то близка визуальная сторона и хочется показывать пальцем «смотри, мама, вот это добавил я» (для этого подходит фронтенд или мобильная разработка), кому-то больше нравится иметь дело с внутренней логикой, чем с «кнопочками». Так что если уже есть понимание, что ближе, это может помочь с выбором.
А вот теперь можно читать про конкретные языки и решать, какой из них соотносится с личными целями. Расположил популярные языки по хронологии, в порядке их появления:
C (1972) и C++ (1985)
C++ изначально появился как развитие языка C, поэтому я объединил оба в одном пункте. Можно сказать, что это дедушка и отец остальных языков в этом списке: они здесь старше всех и очень повлияли на другие языки.
Сейчас они выглядят не точно так, как в момент появления (у C++ каждые три года принимают новый стандарт, недавно был принят C++20), и с годами всё сильнее различаются. Но идеи, заложенные ещё в начале, продолжают накладывать свой отпечаток. Когда создавался C, компьютеры были куда менее производительными, так что их ресурсы приходилось экономить куда старательнее. И тогда всё было «ближе к железу»: программирование в большей степени, чем сейчас, требовало понимать, как физически работает компьютер.
В результате теперь по сравнению с более современными языками у С и С++ репутация «хардкорных»: требовательных к программисту, зато позволяющих выжать из железа всё. И зачастую используют их как раз там, где действительно нужно выжимать как можно больше: например, в играх. Или в софте не для привычных компьютеров, а для различных других устройств, в которых зачастую маломощные процессоры — от автомобилей до банкоматов.
Раз всё сложно, в чём смысл делать подобное своим первым языком? Тут мнения разнятся. Многие считают, что действительно лучше начинать с чего-то полегче. Но есть и такая позиция: при изучении таких языков лучше понимаешь, как работает компьютер и исполняется код, а это для программиста очень полезно. В общем, можно посоветовать тем, кто не ищет лёгких путей, а хочет понять всё поглубже.
Python (1990)
В каком-то смысле Python — противоположность C: если там «сложно, зато производительно», то здесь «просто, зато к производительности есть вопросы».
Такое категоричное заявление требует уточнений. Во-первых, о простоте: свои хитрости здесь тоже есть, но они не так болезненны для новичков. С какими-то языками сразу врезаешься лицом в стену из непонятных терминов и теряешь всё желание что-то делать, а здесь начинаешь с куда более простого и понятного кода. Для многих базовых задач предоставлены встроенные способы решения, Python называют «языком с батарейками в комплекте». Неудивительно, что его часто рекомендуют в качестве первого языка, и он стал очень популярен в образовании.
Что же до производительности, то Python действительно проигрывает и C++, и многим другим языкам. Но порой его называют «медленным» презрительно, а вот это уже зря. Вспомним слова о том, что языки хороши или плохи не сами по себе, а применительно к задачам. Да, есть задачи, для которых Python не подойдёт — но есть и такие, где разница в скорости между ним и другим языком вообще не будет заметна. У Python есть свои области применения, для которых он достаточно хорош.
Что это за области? Ещё давно Python полюбили учёные — и теперь с его помощью занимаются такими околонаучными вещами, как машинное обучение и data science. В бэкенде веб-сервисов его тоже используют. Про образование уже сказано. А помимо разработки, его любят в системном администрировании — там он отлично подходит для мелких утилит.
Вакансий с упоминанием Python много, но здесь есть нюанс. Порой этот язык называют «вторым лучшим для любой задачи»: всегда удобный вариант, но всегда уступающий чему-то. Из-за этого Python зачастую используют не как основной язык какого-то проекта, а «в дополнение». Поэтому в части случаев может получиться, что в вакансии он вроде и упомянут, но не как основное требование, а как бонус — и его знания недостаточно, чтобы откликнуться на неё. Так что для первых этапов обучения он точно подходит хорошо, а вот насчёт трудоустройства смотрите ситуацию в своём регионе.
JavaScript (1995)
Если в бэкенде разные языки активно конкурируют, то с фронтендом всё проще: там господствует JavaScript. Так что, если вам интересна конкретно эта область, выбор первого языка очевиден. А из-за такого доминирования востребованность языка гигантская, количество вакансий очень большое — так что с точки зрения трудоустройства это тоже хороший вариант.
JS считается относительно простым языком для обучения. Но стоит учесть, что во фронтенде сейчас почти никто не использует «просто JavaScript», нужно будет ещё освоить один из популярных фреймворков (а также научиться пользоваться инфраструктурой). И вот к ним нареканий о сложности заметно больше — так что по пути к карьере фронтендера боль может возникнуть на этом этапе.
При популярности JavaScript и у него, и у всей современной фронтенд-разработки хватает ненавистников. Кто-то говорит, что во фронтенде всё постоянно меняется и надо постоянно переучиваться вместо спокойной работы (правда, в 2020-м таких жалоб уже заметно меньше, пик остался в прошлом). Кто-то жалуется на странности в логике JS. Во многом такие оценки субъективные, их не назвать «правильными» или «неправильными» (одно и то же кого-то злит, а кого-то радует) — так что неизвестно, что будете ощущать лично вы.
Помимо фронтенда, JavaScript используют и в других областях (бэкенде, компьютерных программах, мобильных приложениях и не только), но в них он от господства далёк.
Java (1995)
Не стоит думать, что Java имеет какое-то отношение к JavaScript — хотя названия похожие и языки были представлены миру в один год, они совершенно разные, и сходство названий объясняется сугубо историческими причинами.
Java используется в первую очередь в бэкенде, и хотя не царит там безраздельно, как JS во фронтенде, позиции очень хорошие. Порой можно услышать пренебрежительное «да она уже устарела и вот-вот умрёт». Ну, во-первых, скажу так: эти слова звучат уже лет дцать, а она что-то никуда не делась. Мы в JUG Ru Group проводим конференции по разным языкам, и по Java получаются самые посещаемые, в прошлом году собралось больше 2000 участников — это никак не выглядит смертью.
А во-вторых, даже если исходить из того, что когда-то она умрёт, это не значит «учить её сейчас бессмысленно»: простой инерции явно хватит ещё настолько, что скорее вы сами захотите переключиться на что-то другое, чем придётся делать это вынужденно.
Другая популярная претензия к Java — мол, она «скучная и многословная», и используют её скучные компании вроде банков, а какие-то другие языки позволяют реализовать то же выразительнее и лаконичнее, и их ценят в весёлых стартапах. Ну, тут всё тоже субъективно, как с JS: знаю многих людей, которые говорят о Java с огнём в глазах и видят в банковской разработке множество интересных задач, но если для кого-то скучно, с этим не поспоришь.
C# (2000)
Когда компания Microsoft представила C#, многие назвали это «ответом Microsoft на Java». Разумеется, между этими языками хватает различий (и за прошедшие 20 лет их число лишь увеличилось), но некоторая перекличка действительно есть, и знание любого из этих языков помогает быстрее освоить другой.
Изначально самая заметная разница была не в самих языках (в синтаксисе или рантайме), а в сферах их применения. Microsoft создал C# как часть своей платформы .NET, связанной с Windows. И если нужно было сделать программу для Windows, то напрашивающимся вариантом выглядел .NET. А вот если такую программу, чтобы запускалась и на Windows, и на Linux, и на Mac — тут могла помочь Java.
Но с годами ситуация изменилась: у .NET появилась новая версия .NET Core, уже не привязанная к конкретной операционной системе, а люди стали реже устанавливать программы на компьютер и больше делать в браузере. Это отчасти сблизило сферу применения языков: если посмотреть сейчас вакансии с названием C#, там, как и у Java, часто будет написано что-то вроде «Построение бэкенда для веб-приложений».
Впрочем, это не единственный вариант. В играх на движке Unity тоже используют C#, а это самый популярный движок в мире — так что в геймдеве язык тоже активно представлен (в отличие от Java).
Kotlin (2010)
Этот язык создала в Санкт-Петербурге компания JetBrains. Он совместим с Java, поэтому Java-проекты можно постепенно переводить на Kotlin: не переписывая всё разом, а постепенно добавляя туда Kotlin-код. И многие попробовавшие его Java-разработчики захотели к нему перейти, ощутив, что тут нет «скуки и многословности», всё выразительнее и современнее.
Пока что язык покорил одну конкретную область: разработку приложений для Android. Изначально их писали на Java, но в последние годы начался массовый переход к Kotlin, он стал новым индустриальным стандартом. Поскольку никто не хочет просто выбрасывать уже написанное раньше, сейчас во многих приложениях есть код и на Java, и на Kotlin, поэтому сегодня Android-разработчику желательно знать оба языка. Но похоже, что в будущем будет достаточно Kotlin — уже сейчас во многих Android-вакансиях упомянут только он.
JetBrains совершенно не хотят останавливаться на Android и метят с Kotlin в самые разные ниши, даже те, где не представлена Java. Каких-то успехов в этом компания добивается, с каждым годом язык становится популярнее, но от других вроде той же Java пока что сильно отстаёт, и насколько ещё ему получится вырасти — открытый вопрос. Так что, если учить Kotlin, в Android-разработке это точно очень пригодится, а в других областях — как повезёт.
Swift (2014)
Наконец, самый молодой язык из перечисленных — он был представлен меньше шести лет назад. Обычно за такое время языки не успевают стать достаточно популярными для попадания в такие списки. Но здесь ситуация особая: компания Apple, создавшая его, ясно дала понять, что теперь iOS-приложения надо писать на нём. А тут как Apple скажет — так и будет, свою платформу компания контролирует.
Но вот всё остальное в мире компания Apple не контролирует. Поэтому, хотя в принципе этот язык можно использовать и для других целей, больше его не применяют особо нигде. Есть попытки серверного использования, но по сравнению с основными бэкендными языками это всё кошкины слёзки.
И в итоге выбор получается совсем простой. Хотите писать приложения для айфонов (ну или для Mac, Apple TV, Apple Watch) — учите Swift. Не хотите их писать — не учите Swift. Ну, если хотите делать приложения «для iOS и Android сразу», существуют ещё кроссплатформенные решения вроде Flutter, но они куда менее популярны.
Прочие языки
Молодые: Go, Dart, Rust и так далее
В интернете легко встретить заявления о том, как прекрасен какой-то молодой язык («молодой» в этом контексте может значить около десяти лет). Мол, он исправляет ошибки предшественников, соответствует духу времени и делает разработку куда приятнее.
Охотно верю, что в заметной степени это правда. Но есть проблема: почти все такие языки используются в индустрии заметно меньше тех самых «предшественников». Так что даже в Москве такой выбор резко сужает круг вакансий, а если вы в городе размеров Омска, то Rust-вакансии вряд ли встретите в принципе. Конечно, можно искать удалёнку, но для первой работы это не лучший вариант.
И какие из этих языков со временем по-настоящему расправят крылья, а какие останутся нишевыми или вообще завянут — сказать сложно. А значит, учить такой язык — это отчасти лотерея. Думаю, что начинать разумно всё-таки с проверенного временем языка, а к «стильному, модному, молодёжному» переходить позже, уже хорошо понимая, что именно делаешь и зачем.
Высокооплачиваемые: Scala, F#, Haskell и так далее
Также в интернете можно встретить сравнения зарплат. Обычно из них следует, что больше всего получают разработчики, которые пишут на языках функциональной парадигмы.
Ну, можно гнаться за длинным долларом, но тут подстерегают сразу две ловушки. Во-первых, то же маленькое число вакансий: может оказаться, что вроде как можно заработать большие деньги, только вот негде. А во-вторых, хочется заметить, что обычно эти языки осваивают опытные разработчики, уже овладевшие ранее другими. И поэтому возможен такой эффект: высокая оплата вызвана не самим языком, а опытом разработчиков. Так что, если вы выучите такой язык, но опыта вам не хватает, то не начнёте сразу же магическим образом зарабатывать на уровне ветеранов.
Узкоспецифичные языки: SQL, HTML, Bash и так далее
Упомяну для полноты картины. До этого речь шла о языках общего назначения, на которых гипотетически можно писать что угодно. Но существуют ещё языки, используемые строго для конкретного круга задач. Например, SQL используется конкретно для работы с базами данных. И его знание вам может понадобиться «в дополнение» к вашему основному языку.
Не требуется бросаться учить все такие заранее, до возникновения какой-либо потребности в этом. Но чем больше вы о них знаете, тем лучше.
Заключение
Если о разработчиках что-то известно достоверно, то вот что: они любят дискутировать о языках программирования и часто расходятся во мнениях.
И к этому посту почти наверняка появятся комментарии, что в нём многое некорректно, упущено что-то значимое и вообще надо было всё написать иначе.
Что если я заявляю «надо объяснять главные различия», то надо было обязательно рассказать про типизацию.
Что где-то я забыл упомянуть важнейшую область применения.
В общем, очень вероятны критические комментарии — и это замечательно: в одиночку сложно объять всю индустрию, так что чем больше людей с разным опытом дополнят текст своим видением, тем более полной окажется итоговая картина. Я даже намеренно упустил один популярный язык, про который недостаточно знаю, чтобы хорошо его описать — думаю, его сторонники сами придут в комментарии и восполнят пробел.
А напоследок хочу обратиться к опытным разработчикам с минуткой рекламы. Несмотря на личные предпочтения, я старался в этом тексте не ставить никакой язык выше другого. Тот же подход у компании JUG Ru Group, где я работаю: мы проводим конференции по самым разным языкам и темам (от JS и .NET до тестирования и devops).
И этим летом в наших онлайн-конференциях поучаствуют такие люди, как создатель C++ Бьярне Страуструп и создатель Java Джеймс Гослинг. А ещё будет создатель Stack Overflow Джоэл Спольски — поскольку на SO задают вопросы о самых разных языках, то и ему самому наверняка захотят задать вопрос самые разные разработчики. В общем, на каком бы языке вы ни писали, вероятно, среди этих конференций есть интересные для вас — рекомендую сходить на сайт и проверить лично.
DrPass
Честно говоря, зря вы объединили С и С++ в одном разделе. Сейчас это две совершенно разные парадигмы программирования, и разница между ними пожалуй как между Java и JavaScript — похожие названия и в синтаксисе встречаются схожие конструкции. И на этом всё.
И если С не самый удачный выбор для лёгкого старта в программировании, но по крайней мере, вполне пригоден, то современный С++ можно рекомендовать для старта разве что тем, кто гик до мозга костей, и способен разобраться с кодом вообще на любом языке, хоть брейнфаке.
phillennium Автор
О, как быстро начались ценные дополнения, на которые я надеялся :) Спасибо за комментарий!
Ru6aKa
Elixir в некоторых обзорах тоже советуют учить.
chapuza
Эликсир — это набор макросов для эрланга. Продвинутых, умных, с очень тонко продуманным обращением с AST, но в эликсир люди ходят за виртуальной машиной эрланга и OTP (сиречь, за бесплатными concrurrency и fault-tolerance). В каком-то смысле он как котлин — язык для тех, кто не осилил скалу. С точки зрения рантайма никаких плюсов по сравнению с эрлангом он не дает.
Причем, примерно все в эликсир приходят после того, как язык на котором все работало раньше перестал справляться с чем-нибудь из списка:
Так что в качестве первого языка я совсем не советую, как и эрланг. Нет смысла: OTP решает задачи, которые просто никогда не встают перед джуниорами и даже мидлами. Это больше про «го выбросили в помойку уже давно, а сейчас и джава перестала тянуть».
aenglisc
Не совсем понятно в каком: в эрланге же нет ничего такого, чего не было бы в элике. Не осилить можно разве что тулинг или доки, которые в элике заметно дружелюбнее.
В качестве первого языка… На своём опыте могу сказать, что схема в целом рабочая, но времени займёт много. Ознакомиться как минимум стоит, хотя бы на уровне работы Джо erlang.org/download/armstrong_thesis_2003.pdf
chapuza
Ну, целевая платформа — одна и та же виртуальная машина. Поэтому все, что может один, может и другой.
А в джаве (или скале) прям до хрена такого, что котлином не выразить? Я немного запутался в ваших отрицаниях отрицаний, так что если имелось в виду что-то другое — поправьте :)
В качестве первого языка нужно что-то такое, на мой непросвещенный взгляд, что позволяет увидеть результат быстро — и без фреймворков. Потому что если начинать с фреймворков, то хорошим разработчиком уже не стать никогда.
aenglisc
Я сварщик ненастоящий, но по-моему в котлине нет штук типа каррирования, система типов от скалы сильно отличается, и в целом парадигмально языки не совсем тождественные. Эрланг и эликсир же в этом смысле практически одинаковые, и «не осилив» один вряд ли можно осилить другой.
В целом солидарен, да.
Ru6aKa
Все тьюринг полные языки умеют одно и тоже, но мы же как-то их сравниваем между собой. Под капотом многих языков виртуальная машина java, но мы же опять таки их сравниваем между собой. И отличия очевидны — сколько надо усилий приложить чтобы решить задачу на определенном языке.
В Erlang очень все печально с метапрограммированием. И метапрограммирование на основе макросов позволило реализовать нормальный ORM (ecto) в Elixir. И при этом в Erlang до сих пор нету нормальной реализации ORM.
Есть два разработчика:
первый начинал без фреймворков и для каждой задачи продолжает писать свои решения, в виде своих библиотек.
второй начинал с фреймворка, но не только просто использовал, но и смотрел как внутри устроено.
По Вашей логике первый хороший разработчик, второй нет. Для меня же ответ неоднозначный и неочевидный.
chapuza
Это не совсем так, точнее — совсем не так.
Ормы должны умереть, а
ecto
— просто pet-project Жозе, который уже начинает мешать нормальному развитию собственно языка. У меня тоже, кстати, есть такой смешной проект https://github.com/am-kantox/lazy_for/blob/master/lib/lazy_for.ex — но в продакшн я его не тащу.Каждая селедка — рыба, но не каждая рыба — селедка, как любил говаривать по иному поводу один замечательный персонаж. Логика — наука сложная, но не настолько, чтобы приписывать мне ерунду.
Color
Советовать в качестве ознакомления с ЯП для новичков докторскую на 300 страниц — это сильно
aenglisc
А какая собственно разница, что это именно докторская? По содержанию она мало чем отличается от любой книги по программированию, более того — там довольно много посвящено историческому контексту появления нужды в таком инструменте. 300 страниц — это не особо-то и много для книги, LYSEFGG вон 600.
chapuza
Армстронг — один из лучший популяризаторов CS вообще, у него блистательный стиль изложения, совсем не скучный и очень внятный.
Calc
да что тут сравнивать то?
В Эрланг встроены акторы в парадигму, в скалле и други языках они просто эмулируются. Если сравнить акторы эрланга и библиотеку Akka, то эрланг будет выигрывать по скорости и стабилности.
Скала сделала упор на асинхронность и бекэнд, а котлин на современные треования по кложурам, потокам и Rx/функциональному программированию.
zagayevskiy
Вот щас обидно было.
kovserg
Вот интересно почему goovy не взлетел, такой-же котлин только не котлин.
ps: В gradle именно он используется.
zagayevskiy
Нет, груви не такой же котлин:) это какой-то язык для мутантов-надмозгов-из-параллельной-вселенной, имхо, я вообще не понимаю, как в здравом уме можно
добровольно его выбрать, чтобы писать что-то. Но приходится использовать для конфигов, потому что переводить с груви, на котором все конфиги в интернете на котлин-скрипт это то ещё развлечение.
kovserg
Не понимаю я таких эстетов. tcl, perl, lisp вполне себе языки или тоже для мутантов? Или вы только статически типизированные языки используете из религиозных соображений. Я специально узучал этот groovy что бы разобраться с вездесущем gradle и язык показался очень удобным и продуманным если не считать то что это такая же надстройка как и kotlin которая паразитирует на java, как и swift на objective-c. Но тот же swift уже оброс инопланетянскими косьтылями в синтаксисе, а kotlin еще не успел.
Neikist
Все же правильнее говорить над jvm, а не java. Впрочем у котлина еще есть вариант транспилировать его в js, а так же сырой kotlin native (на котром тоже проекты пишут в проде, ну точнее kotlin multiplatform).
zagayevskiy
Сразу видно, что вы не в теме. Свифт до недавнего времени каждую версию ломал обратную совместимость, и эти их "костыли в синтаксисе" — результат работы над языком. Они могли сделать что угодно и получилось это.
Котлин старше Свифта, его около 5 лет пилили до релиза, вылизывали детали. Он очень продуманный язык.
Neikist
Серьезно? Называете такими-же язык с очень слабой и динамической типизацией и с довольно строгой статической?
Хотя конечно для гредла конфиги на груви удобно писать (пока не понадобиться разобраться в деталях, там начинается чертова магия груви).
Пробовал конфиг на котлине писать — язык со строгой статической типизацией все таки в гредл файлах не очень удобен.
F0iL
Си хоть может и не будет легким на старте, но я бы его в обязательном порядке рекомендовал изучить всем в качестве второго или третьего языка, просто чтобы приобрести понимание того, что скрывается за всеми этими абстракциями и заботливым рантаймом в высокоуровневых языках.
А вообще, лучше расширять кругозор, комбинируя противоположности. Освоили высокоуровневый объектно-ориентированный язык — попробуйте низкоуровневый процедурный (и бонусом можно еще попробовать упороться по функциональщине, но это уже потом). Писали на языке со слабой динамической типизацией — освойте что-нибудь с сильной статической. Был опыт с компилируемыми — возьмите скриптовой интерпретируемый.
Все это неплохо так расширяет горизонт знаний и позволяет сравнить плсы и минусы разных подходов чтобы выбирать более подходящие инструменты в будущем.
proninyaroslav
Тогда уж для этих целей лучше изучить машинные инструкции и архитектуру, а не только си. Парадигма си не менялась со времён PDP (который был по сути портативным ассемблером, и который хорошо адаптирован к архитектуре PDP), поэтому си такой же абстрактный язык, как и остальные. Единственный плюс — нет рантайма, и при вышеперечисленных знаниях архитектуры, компилятора, инструкций можно заранее знать, в какие машинные инструкции будет скомпилирован код (если без оптимизаций конечно). Что в общем и используют low-level разработчики и разработчики ядер.
wholeman
C можно считать подмножеством даже для современного C++, хотя и есть между ними некоторые отличиям. Непонятно, зачем их разделять. На самом деле мне непонятно, зачем сейчас вообще учить C, если даже на ардуине C++ вполне эффективен.
Можно найти задачи, которые не требуют владения всеми конструкциями языка, а тем более всей станартной библиотекой или бустом. При этом знания, полученные при изучении, будут весьма полезны при освоении других языков, которые в той или иной степени используют синтаксические конструкции из C++.
Calc
Давно разошлись по идеологии и путям развития.
Так верно говорить для C и Objective-C, но С++ уже давно не в ту степь смотрит.
wholeman
Куда он смотрит в данном случае не важно. Там появились новые отличия, которые влияют на совместимость? Кажется, в двадцатом что-то собирались делать, но точно не помню.
Fenzales
wholeman
Однако, если Википедия от нас ничего не скрывает, они не настолько велики, чтобы не объединять эти языки в одну группу.
Alexey_Alive
Они достаточно большие. Там, даже, сравнение указателей по разному работает. Разные объектные модели. Про type punning через union, vla, compound literals и прочие фишки C я даже говорить не буду.
DrPass
Ну, это не совсем верно. Правила С++ более строгие, и примеров кода, который компилируется в С, но не компилируется в С++, вы найдёте немало. Да банально порядок объявления функций. В С++ функцию надо объявить перед использованием, а в С не надо.
wholeman
Ну да, C — язык более анархичный. И это ещё один повод его не использовать. Я считаю, что первый язык должен быть достаточно строгим — меньше будет плохого кода.
Alexey_Alive
В смысле, в C не надо?! В C тоже надо. Да, там была фича, что если функция не объявлена, то считается, что она такая int foo(...). Для printf такое подойдёт, а вот malloc уже так работать не будет.
maxzhurkin
Вы ещё предложите BASIC с FORTRAN'ом не разделять по той же причине :)
wholeman
Про них я ничего сказать не могу, ибо не знаю. Я их лет тридцать назад учил, но никогда не использовал.
maxzhurkin
Это был контраргумент к рассмотрению C/C++ «в одном пакете»: BASIC был создан как «детский» вариант «взрослого» FORTRAN
wholeman
Однако, он уже давно перерос «папашу» и от начального варианта с номерами строк ушёл очень далеко. С C этого не произошло.
kovserg
Почему-то школота не может понять что хотя бы один язык должен оставаться неизменным.
Kanut
Я бы сказал что это как с латынью: неизменными остаются только мёртвые языки :)
maxzhurkin
Чего не произошло с C?
Что в BASIC поменялось кроме исчезновения номеров строк?
wholeman
C не изменился настолько сильно, как Basic. Версии, которыми сейчас активно пользуются, а не классика, конечно.
Вы Visual Basic видели? Для многих сейчас это и есть Basic. ЕМНИП сто лет назад в Turbo Basic уже было что-то подобное объектам.
BigBeaver
Бэйсик уже минимум лет 20 ничем не уступает всяким Delphy. До сих пор бы на нем писал, если бы не линукс.
maxzhurkin
А как называется комитет по стандартизации?
Какая последняя версия стандарта?
Какие вообще есть стандарты?
BigBeaver
Микрософт же.
wholeman
Насколько я знаю, есть стандарт де-факто — вижуал бейсик. Остальные всем пофиг.
Groramar
Всё так. Единственное, что VB уже закрыт.
wholeman
Да Вы что! На чём же они теперь макросы для Ёкселя писать предлагают?
Groramar
Всё таки есть большая разница между макросами и старой позицией, до закрытия проектов Майкрософтом, как универсального языка.
BigBeaver
А где можно узнать про закрытие? Вроде, так и выпускается вместе со студией.
wholeman
Вот тут пост был. Groramar несколько поторопился его хоронить — пока это только остановка дальнейшего развития. Какой там срок поддержки у .NET 5?
BigBeaver
Да даже если и прекратят разработку фич, это мало что значит. Даже поддержка VB6 до сих пор сохранилась в винде, и люди продолжают писать.
Вообще считаю VB6 идеальным для новичков, которые не знают, чего хотят. Легкий и лаконичный синтаксис, трудно выстрелить в ногу, есть простая событийная модель. Потом дообучившись работать с памятью и указателями можно мигрировать на любой императивный язык.
Groramar
В современных реалиях, когда «Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!» можно считать что это смерть языка.
IgorPie
Они сильно разъехались за последние 20 лет. Современный С++ — это не то, что пишут в рафинированных книжках, там все по другому.
Plain C примерно так и остался, по-ближе к железу и побольше предсказуемости и машинный код приходится отсматривать, для отлова узких мест.
wholeman
То есть, сейчас текст на C++, использующий только то, что есть в Plain C (плюс аналоги complex, VAL и т.п.), выдаст машинный код, сильно отличающийся от написанного на Plain C?
Alexey_Alive
Аналогов Vla на C++ нет. Даже vla расширение g++ работает абсолютно по-другому, в отличии от C. Если вы соберёте C код C++ компилятором, то, вероятнее всего, там будет неопределённое поведение, но ещё более вероятно, что он не соберётся.
wholeman
Насчёт VLA согласен. Не то, чтобы мне нравилась идея размещать в стеке массивы неопределённой во время компиляции длины, но это может быть эффективно.
Понятно, что не соберётся — это всё же разные языки. Но очень близкие, по крайней мере сравнение Java/JavaScript совсем не к месту.
Alexey_Alive
Vla — это тип, а не синтактический сахар вызова alloca. Vla — не обязательно размещается на стэке. Например, вот.
wholeman
Это понятно. Но такая конструкция уже мало отличается от обычного new.
wholeman
Судя по реакции, здесь много разработчиков, которые активно используют Plain C и со мной не согласны. Не могли бы вы привести пример не слишком экзотического кода на нём, который сильно выигрывает у аналога на C++ по эффективности или простоте.
Не холивара ради, а мне интересно, где я мог бы заметно выгадать от такой замены — для практического использования.
0xd34df00d
Не могу сказать, что активно использую plain C (вообще не использую), но там не надо думать о лайфтаймах объектов, а в плюсах это непрекращающийся источник UB (которыми, впрочем, компилятор не пользуется). Поэтому если вы пытаетесь писать корректный с точки зрения стандарта код, то вам придётся делать нетривиальное количество приседаний для того, чтобы лайфтаймы объектов правильно начались, особенно — до С++20.
IgorPie
это уже тема для статьи
SantaCluster
"Да вы, молодой человек, уже на статью наговорили. И даже не одну" :)
EvilMonk
Поддерживаю просьбу — тоже интересно, где С эффективнее С++
MilesSeventh
C банально изучить проще, не отвлекаясь на всякий сахар и не забивая голову всякими спорными практиками, работая исключительно с данными и алгоритмами. Для новичка это особенно актуально, иметь уверенность в своем инструменте и своих знаниях. Кресты не так уж и много возможостей дадут в сравнении с C, зато забить голову всякими пародиями на ООП запросто могут.
trdm
ИМХО не нужен легкий старт. он лишает дисциплины и понимания политизированности ресурсов.
в профессиональном программировании нужно понимать связь языка с ресурсами компьютера.
дисциплинирующий С этому способствует. И это является отличной базой для старта.
дальше он может выбрать инструмент самостоятельно.
yeputons
C и C++ конечно зря объединили, но вот про современный C++ вы тоже зря. В качестве первого языка C++ подойдёт куда лучше Си (если правильно учить) — можно писать без возни с выделением памяти, без указателей, без ручного освобождения ресурсов, и всё будет прекрасно работать. Есть прекрасный доклад на тему обучения C++ без этого: Stop Teaching C.
Даже для написания
std::cout << "Hello\n"
не требуется ни детального понимания правил поиска имён, ни ADL, ни перегрузки операторов — хватит интуитивного «синтаксис почему-то такой».Хотя мне кажется, что Python или PascalABC.NET (не классический!) подойдут для обучения ещё больше, там меньше абстракций течёт, чем в C или C++.
0xd34df00d
А вот для того, чтобы понять хотя бы сообщение об ошибке в интуитивном
std::cout << "Hello, pair " << x, y << std::endl
, уже придётся таки разбираться.quwy
Вот это как раз не надо. Потому что открыв учебник, написанный 10 лет назад, человек прочитает там "<< и >> — операторы битового сдвига", и получит хорошую прививку от этого вашего программирования. Я, вот, знаю, что можно делать с операторами, но меня все равно корежит от этого синтаксиса, придуманного кем-то, кому лень несколько кнопок лишних нажать.
yeputons
Так и не надо открывать учебники десятилетней давности. Некоторые вон вообще на Turbo C с
<iostream.h>
и запретомstd::string
как глючного и тормозного до сих пор учат — так, конечно, не надо.И как отличить подобную дичь от условно "современного C++" без исходных ссылок на хорошие материалы новичку — непонятно.
Wingtiger
для мк надо — строки как класс занимают 4 килобайта флеша, а это очень дохрена для популярных серий мк.
AnthonyMikh
Во-первых, откуда 4 килобайта, во-вторых, у вас что, компилятор в LTO не умеет?
Wingtiger
умеет. И версия релизная. Если убрать string и все строки заменить массивами символов, то "магическим" образом -4к
0xd34df00d
Это пока в C++ не завезли
consteval
(илиconstinit
, я уже запутался) иconstexpr
-конструкторы для строк.chersanya
А можете пояснить, как связано занимаемый скомпилированной программой объём, и эти все constexpr? Казалось бы, класс string-то всё равно нужно включать.
0xd34df00d
Потому что тогда не будет никаких динамических аллокаций (предполагая, что в С-коде их нет), и компилятору будет легче вырезать вообще все кишки
std::string
.TargetSan
С++? Для обучения? Да вы, батенька, шутник… Вот пара относительно свежих WTF:
По моим скромным наблюдениям, граблей набралось уж очень много. И скорость набора только растёт.
yeputons
В любом языке есть WTF, при обучении (да и при работе) надо выбирать безопасное подмножество. В C++ это сложнее из-за обратной совместимости, конечно.
Для первого языка для изучения алгоритмизации, имхо, больше подойдёт Python, в нём и UB не так часто стреляет. Но можно и на C++, если захочется, просто надо больше аккуратности от преподавателя, чтобы предусмотреть грабли в заданиях.
TargetSan
Это гораздо сложнее.
Вот вы например в курсе, что by-value copy constructor запрещён? Я до недавнего времени например не знал. И таких "подковырок" слишком много. А ещё не забудьте зоопарк систем сборки и пакетных менеджеров, если они вообще применяются.
yeputons
Конечно в курсе. А ему этот by-value параметр конструировать? Только этим же конструктором.
В безопасном подмножестве C++ есть ровно один способ написать copy constructor и ровно один вид move constructor, каждого ровно один вид. Есть правило пяти, которым это прекрасно запоминается.
Для обучения можно ограничиться CMake (да хоть тем, что CLion генерирует) и встроенным в систему пакетным менеджером (apt, homebrew, msys2/vcpkg). Разумеется, в реальности там зоопарк, но незачем про это сразу рассказывать.
И, да, Python и в этих местах сильно удобнее и с батарейками.
AnthonyMikh
Во-первых, лучше правило нуля, а во-вторых, это можно запомнить, но сложно понять, особенно новичку. И это связано отнюдь не с самой предметной областью, а исключительно с заморочками самого C++.
embden
Я про C++ абсолютно согласен. К примеру, у меня есть группа вк, в которой я уже пару месяцев помогаю людям изучать python. Это при том, что я на порядок лучше знаю C++. Но помогать в изучении C++… нет уж, увольте.
Calc
от задач зависит. Та же книга Страуструпа хорошо описывает язык для обучения, но в основном в интернете уроки по Шилду, который приравнивает C к C++.
Ну, а если брать современные задачи, например парсинг json, http запросы, асинхронность, то есть некоторые сложности в погружении.
vt4a2h
Не могу согласиться с утверждением насчёт C++. Подмножества языка, которое можно назвать "современный C++" довольно-таки просто в освоении и использовании. Как вам, например, программирование на C++ без new и простых указателей.
Проблема тут в том, что есть довольно много курсов (учебных материалом) по C++, которые совершенно неправильно подходят к процессу обучения. Я не буду вдаваться в подробности, а лучше приведу пример хороших курсов. Это курсы по C++ от Яндекса, там по-моему человек узнаёт что в языке есть указатели и new где-то к третьему курсу :) Я разумеется могу ошибаться, но как факт, людей не заваливают избыточной сложностью с самого начала.
Ну и касательно относительно пригодности C для "относительно лёгкого старта". Я бы сказал, что на C++ это будет даже легче за счёт абстракций более высокого уровня. Да хотя бы std::vector, std::string, std::*_ptr, ссылки и т.п… Это всё прячет кучу ненужной вначале сложности.
PS
Я склонен рассматривать стандартную библиотеку C++ как в некотором роде часть языка, так как она даже в стандарт входит.
Calc
Стандартная библиотека и есть часть языка, это как «core» в каких нибудь других языках. За основу надо брать Страуструпа, там хорошо всё описано.
vt4a2h
Тут иногда находится о чём поспорить, поэтому я пояснил свою точку зрения, на всякий случай :)
Calc
Ну это как Java рассматривать отдельно от ее Collections и других «встроенных» штук.
TargetSan
Не могли бы вы пояснить этот момент? ЕМНИП наличие поля-ссылки превращает объект в non-copyable, non-movable. Положить ссылку в optional нельзя из-за приколов стандарта. Без указателя дальше либо std::reference_wrapper, либо std::weak_ptr. Первый чертовски многословен, второй добавляет reference counting overhead.
vt4a2h
Ссылки использовать в качестве полей объекта не призываю, равно как и optional. У этих вещей другое назначение.
Использование shared/weak указателей может добавить дополнительные расходы на подсчёт ссылок. Вопрос только в балансе между безопасностью, читабельностью и простотой сопровождения кода и попытками избежать "reference counting overhead". Если вы действительно проанализировали вашу программу и окружение различными инструментами, и пришли к выводу что вот именно использование интеллектуальных указателей приводит к критическим расходам памяти и/или критическому снижению производительности, то наверно вы можете пожертвовать безопасностью, читабельностью и простотой сопровождения. Вероятно так же, что это 0.001% всех случаев, ну или около того.
AnthonyMikh
А это почему?
vt4a2h
Потому что использование ссылки в качестве поля объекта — даже хуже чем использование сырого указателя. Это и на сам объект налагает ограничения и понимать жива ли ссылка довольно сложно. C++ — это не Rust, и получить тут подвисшую ссылку проще простого, отлаживать бывает неприятно.
Но опять же надо понимать, что универсальных правил нет. Если у вас какой-то короткоживущий объект, который ссылку вот прям точно не переживёт или вы можете как-то иначе гарантировать это, то наверно ссылку можно использовать. По-моему опыту опять же, это только усложняет код и архитектуру. Решать разработчику разумеется, но я бы не рекомендовал использовать.
Касательно optional, он по дизайну нужен для передачи или возврата необязательных аргументов. Мне довольно сложно представить ситуация, когда объект, обёрнутый в optional надо где-то долго хранить. В особенности если у вас в архитектуре должным образом используются интеллектуальные указатели.
PS
И да, я прекрасно понимаю, что мы живём не в идеальном мире, и что вокруг куча легаси, и разработчиков, которые не хотят учиться, и тех кто делает всё "тяп-ляп". Так что, дам идеальный и бесполезный совет: смотрите по ситуации.
bfDeveloper
Хотел было возразить, что нет, C++ нормальный первый язык. Я с него начал и продолжаю работать на нём. Но потом понял, что на брейнфаке я тоже писал немало и даже никнейм на хабре к нему отсылает. А я считал себя нормальным человеком :(((