У меня есть личный профиль на Quora, и мне нравится читать вопросы и ответы, связанные с программированием. Советую вам делать то же самое, потому что из опыта других программистов можно извлечь пользу для себя. Как бы то ни было, в последнее время я встречаю примерно следующие вопросы:
Какая технология придет на смену JavaScript?
Есть ли у Kotlin шанс заменить Java?
Заменит ли Rust язык C++?
У какого языка на замену C, если выбирать между D, Go и Rust, самые большие перспективы?
Особенно мне нравится последний вопрос, потому что человек, задавший его, настолько убежден в бесславном конце C, что привел готовые альтернативы. Мне кажется, что подобные вопросы стали возникать чаще, чем раньше, с момента публикации академического документа Energy Efficiency across Programming Languages: Как соотносятся энергия, время и память». (При желании можно ознакомиться с текстом здесь). Полагаю, все эти вопросы по факту сводятся к одному: каким будет язык (или языки) программирования будущего? Сегодня, опираясь на результаты из упомянутого выше документа и анализируя иную статистическую информацию, мы попытаемся разобраться в этом вопросе. Но прежде, чем начать, я хочу уверить вас, что буду максимально объективен, поскольку не хочу выдавать желаемое за действительное. Давайте начнем с самого главного: того самого документа.
Документ
Если вы все-таки дочитали до этого места, я почти уверен, что вы видели таблицу, приведенную ниже:
Я видел ее слишком много раз. Куча людей делились ею в различных социальных сетях, и не осталось ни одного человека, который бы не знал эту таблицу. Однако перед тем, как мы углубимся непосредственно в результаты, я хочу кое-что рассказать.
Прежде всего, следует задуматься о том, как измерялись перечисленные в таблице показатели. Как правило, для измерения производительности процессоров применяются бенчмарки. Для оценки языков программирования авторы написали свои бенчмарки из 10 разных задач, при этом для их решения был использован один и тот же алгоритм, приведенный в Computer Language Benchmark Game.
Кроме того, языки программирования были распределены по категориям на основании их парадигмы:
Тем не менее, для тестов производительности парадигма не имеет принципиального значения. Важен тип языка программирования: компилируемый, интерпретируемый или работающий в виртуальной машине. Между ними существует четкая разница в производительности и энергопотреблении. Поэтому каждый язык оценивался в своём классе — это правильное решение.
Следующий шаг — проведение тестов CLBG. Авторы поделились результатами нескольких испытаний. Давайте посмотрим на них.
Энергия измеряется в джоулях, время — в секундах. Коэффициент — это пропорция между энергией и временем, она позволяет вычислить приблизительную энергоемкость языка. Помимо этого, возле каждого языка изображены стрелки вверх и вниз. Стрелка с одинарной линией показывает, на сколько ступеней вверх/вниз продвигается данный язык программирования, если упорядочить таблицу по времени выполнения. Стрелка с двойной линией — то же самое, но упорядочить таблицу предлагается по пиковому объему потребляемой памяти.
Когда я впервые увидел таблицу, представленную выше, в социальных сетях, я подумал, что сортировкой по времени выполнения почему-то пренебрегли. Оказывается, авторы ее указали только для ряда репрезентативных тестов. К примеру, в тесте с бинарным деревом C, C++ и Rust дали наилучшие результаты, но с точки зрения памяти Rust показал несколько худшую производительность. С другой стороны, то же самое относится к C в бенчмарке fannkuch-redux. Так что не всё так однозначно.
В свою очередь, бенчмарк fasta демонстрирует уже совсем другие цифры. Показатели производительности становятся размытыми и нечеткими. Для получения более-менее полной картины стоит рассматривать результаты всех тестов вкупе.
Единственное, что мне понравилось в этой работе, так это то, что авторы сравнивали языки, принимая во внимание класс, к которому они относятся, так что можно сопоставить компилируемые и интерпретируемые языки внутри их собственных классов. Результаты этих 3 тестов приведены ниже.
Мне не хотелось бы перечислять здесь все подробности и частности, рассмотренные в этом документе. Если вы захотите ознакомиться с ней, у вас есть ссылка, и вы сможет сами его прочесть. Как бы то ни было, перед нами итоговая таблице результатов:
Язык C в итоге кажется наилучшим с точки зрения энергопотребления и производительности, но проигрывает по использованию памяти. Впрочем, даже в отношении памяти он совсем не плох. Далее следуют Rust и C++. Можно сказать, что C и Rust являются лучшими языками программирования в ми... Минуточку! Они же не поддерживают объектно-ориентированное программирование. (Вы могли бы подумать, что Rust поддерживает ООП, но фактически в нем есть только интерфейсы (вернее, трейты), но не вся ООП-структура). Тем не менее, в организациях, как правило, активно используется ООП, не говоря уже о важности удобства использования языка. C, C++ и Rust не так уж просты, они заставляют думать о времени жизни объектов, динамическом распределении и т.д.
Итак, что мы узнали? Нам удалось сравнить языки с точки зрения их энергопотребления, требований к памяти и времени, необходимого для завершения процесса. Тем не менее, нельзя на основе только этих данных решить, какой язык лучше. Если же добавить еще больше метрик, результаты станут слишком сложными для понимания.
В связи с этим я хочу внести изменение в эту концепцию: предположим, что люди очень логичны. В экономических исследованиях принято исходить из этого предположения, несмотря на то, что люди не так уж и логичны. Но допустим, что мы очень последовательны и разборчивы. В таком случае, как выбрать самый лучший язык? Путем анализа тенденции использования тех или иных языков программирования. Как можно ее измерить? В виртуальном пространстве пишется огромное количество кода, и большая его часть хранится в приватных репозиториях. Может быть, стоит проверить статистику поисковых систем, поскольку известно, что все разработчики пользуются поиском, когда сталкиваются с проблемами в своем софте? Давайте попробуем.
Статистика Google
Статистические инструменты Google открыты для всех желающих. Я использовал их, чтобы узнать статистику поиска Google по языкам программирования, но столкнулся с ограничениями: можно получить данные только по 5 ключевым словам. Итак, давайте начнем с 3 лучших языков по результатам приведенных выше тестов, а заодно прибавим к ним Java.
Похоже, Java по-прежнему используется чаще, чем другие компилируемые языки, хотя показатели значительно снизились. C и C++ идут вплотную друг к другу. А вот Rust оказался на самом дне. Возможно, это связано с тем, что это новый язык, но справедливости ради следует отметить, что Rust нов лишь на фоне C и C++. Он вышел в июле 2010 года. Прошло почти 12 лет, и с тех пор не произошло никаких заметных изменений. Результаты этой статистики сильно отличаются от тех, что мы видели ранее. Давайте теперь возьмем Java и еще 4 языка: Kotlin, Javascript, Python и Go.
В очередной раз ситуация меняется, мы видим совсем другую картину. Python начал с низов, но сейчас это самый востребованный язык. Java и JavaScript занимают почетное второе место. Теперь Python — безусловный чемпион, но мне хочется провести еще один раунд.
Кажется, у нас есть победитель: это Python! Несмотря на это, необходимо соблюдать максимальную объективность, а мы проанализировали статистику лишь одной поисковой системы. Конечно, это одна из самых распространенных поисковых систем в мире, но результаты в других поисковиках могут существенно отличаться. Впрочем, проводить один анализ за другим и объединять результаты мы не будем, это займет слишком много времени. Благо, что есть компания, которая сделала это за нас.
Индекс TIOBE
TIOBE — это компания, специализирующаяся на оценке и отслеживании качества программного обеспечения. Чтобы узнать о ней больше, посетите их сайт. Их главная услуга — проверка качества кодовой базы программного обеспечения. Они создали показатель под названием TQI (TIOBE Quality Indicator), и ниже приведен пример его использования.
Компания создала индекс языков программирования под названием TIOBE index. С его помощью можно оценить успешность языков программирования на основе трендов поисковых систем, при этом учитываются практически все релевантные поисковые системы. Более подробно о том, как рассчитывается индекс TIOBE, можно прочитать здесь.
На основании этого индекса ниже я приведу актуальные результаты:
Это очень похоже на то, что мы видели в трендах Google. Правда, здесь язык C занимает второе место по распространенности, что оказалось весьма неожиданно. Кроме того, здесь есть исторический график успешности разных языков программирования:
Ясно, что Java долгое время доминировал в этой среде наряду с С. Однако Python набирает все большую популярность и выходит в лидеры. Здесь следует обратить внимание на один важный момент: Тенденции постоянно меняются. Java был первым, но теперь его место занял Python, хотя до 2010 года о нем мало кто слышал. В этой связи возникает вопрос, как можно оценить будущий потенциал языков программирования?
Оценка потенциальных возможностей
В последние 10 лет машинное обучение и искусственный интеллект стали очень популярны. Язык Python оказался наиболее оптимальным для подобных операций, поскольку в нем есть хороший API для языка C, а если вам нужна производительность, можно комбинировать его с C и C++. В этом направлении Python стал самым используемым языком в мире согласно поисковым трендам и индексам.
Однако это не означает, что Python сохранит свое место. Некоторые другие языки могут показать лучшую производительность, чем Python, и вытеснить его. Например, возьмем язык Rust. Amazon и Facebook заявили, что они начали использовать Rust для разработки своих внутренних инструментов CLI (интерфейс командной строки). Кроме того, ядро Linux, начиная с версии 6.1, включает Rust. Это очень значительный объем поддержки для языка программирования, и, мы видим, всего за год он поднялся с 26-го места на 20-е.
Но главный вопрос все еще остается без ответа. Как же нам предсказать будущее?
Ответ
Прошу прощения, что заставляю вас читать эти строки, но данный вопрос не имеет смысла. Мы не политики, никто не платит нам деньги, чтобы мы поддерживали технологические тренды.
Зачем же мы это делаем? Фанатично поддерживаем язык или какую-то технологию? Универсальный ответ: потому что мы ленивы. Мы изучаем язык программирования или технологию, затем формируем зону комфорта в рамках этих инструментов. А потом не хотим менять их, чтобы не выходить за пределы зоны комфорта. Люди, которые слишком фанатично поддерживают C и C++, делают это потому, что они не хотят учить новый язык, например, Rust, с нуля. Люди, которые чересчур рьяно выступают за Rust, делают это потому, что не хотят учить C и C++, так как они сложноваты и в них есть много вещей, с которыми нужно быть осторожным. Я думаю, что оба эти подхода ошибочны и неправильны, и мы не должны совершать эту ошибку.
Языки программирования — это всего лишь инструменты, вроде отверток. Если вам потребуется отвертка с шестигранной головкой, вы не станете заставлять себя работать отверткой с крестовым наконечником. Вы примете решение в соответствии с ситуацией. Если у вас есть возможность выбрать тип самореза, то вы будете учитывать структуру стены. Возможно, в зависимости от ситуации вам понадобится изолента или что-то еще. Инженер должен продумывать оптимальное решение в соответствии с поставленными требованиями.
Если говорить кратко, не существует какого-то универсального языка программирования, который заменил бы все остальные. Есть только требования обстоятельств, и вы должны использовать правильный инструмент, исходя из этих требований. Вот и все.
В силу своей специализации, я обычно использую C, C++, Rust и Python. У меня нет достаточного опыта, чтобы говорить о других языках, но я могу дать вам примерный анализ плюсов и минусов языков, которые я использую. Об этом я написал еще одну статью.
Комментарии (52)
agalakhov
00.00.0000 00:00+25Как человек, работавший почти 20 лет с C++ и с C, могу сказать: эти языки содержат столько разных неочевидных особенностей и так обрастают ими со временем, что подавляющее большинство пишущих на них людей знают их недостаточно хорошо и время от времени вставляют в код конструкции, точной семантики которых не понимают. В большинстве проектов больших команд можно найти в коде именно языковые ошибки, когда код написан "в лоб", но делает немного не то, что задумано, и правильно работает лишь чудом (обычно речь об UB, которое случайно скомпилировалось "как надо", либо о правильной работе кода только в подмножестве всех возможных вариантов). Так что современный C++ и современный C можно смело относить к языкам, слишком сложным, чтобы простой смертный мог их полностью и со всеми нюансами выучить. Что делает их в том числе опасными.
Технически, с точки зрения того, как код компилируется, единственным языком, претендующим на замену C, является Rust. Все остальные языки, такие как Go или Kotlin, изначально более высокоуровневые и конкурируют скорее с Java.
Что касается ООП, то разработчики Rust, будучи людьми, очень хорошо знающими C++, имели веские причины сделать язык без классов. С формально-математической точки зрения такие концепции ООП, как наследование, имеют очень странные и неочевидные свойства. Что приводит все к той же проблеме: люди часто неверно используют ООП и делают на нем очень странные вещи. При этом, имея в языке алгебраические типы данных, можно делать все то же самое, что делается и в ООП, но легче научить человека не лажать.
Судьбу C++ довольно легко предсказать: в скором будущем он превратится в язык, на котором все еще будет много писаться, но под который будет очень сложно и дорого искать квалифицированных специалистов. Сейчас Java стремительно становится таким языком, и уже давно такими стали FORTRAN и COBOL. Причем как минимум фортран (с коболом не работал, не знаю) до сих пор нельзя ничем заменить - это единственный вообще язык, в котором стандарт достаточно четко оговаривает, как именно должны вычисляться выражения с плавающей запятой. Из-за чего числодробильный код, если его перевести с фортрана на какой угодно другой язык, зачастую начинает неправильно считать. Поэтому на фортране сейчас пишется до фига и более, любой код численного моделирования взять, какой-нибудь расчет прочности - там фортран, и код это свежий, активно развивается. А поскольку фортран почти никто не знает, то те немногие, кто его все-таки учат, остаются востребованными, и язык живет.
ksbes
00.00.0000 00:00+2COBOL заменить той же Java или другим языком JVM — формально просто. В самом коболе нет ничего такого уникального. Более того кобол разрабатывался так, чтобы менеджер по продажам глядя на код понимал что происходит (та самая буковка "B").
Но проблема в том, любая реально работающая программа на коболе по сути написана не на коболе, а на особом мета-языке. Который, несмотря на некоторую стандартизацию, всё же различается между фирмами. И потому не то что менеджер — бывалый программист с 50-ти летним стажем не всегда разберётся.
Это как если бы не было С++, а вместо этого на С в каждой конторе писали бы в своём понимании классов и ООП (иногда такое и происходит — видел пару раз).agalakhov
00.00.0000 00:00Кстати, возможно, что та самая киллер-фича кобола - это то, что в нем не плавающая запятая, а BCD. Что сильно снижает вероятность налажать в денежных вычислениях по незнанию.
rg_software
00.00.0000 00:00+4Проблема в том, что не считая вакханалии с C++14 и далее, в целом C++ довольно консервативный язык, переживший десятилетия с достаточно скромными изменениями и хорошей обратной совместимостью. Его монстральность -- это следствие не только проектных решений, но и банального возраста, а жизнь показывает, что другие языки выдерживают испытание временем даже хуже.
В этом смысле любой язык старше 10-15 лет показывает свой тип накапливания энтропии. Java и C# аккумулируют новые средства как не в себя, причём C# ещё и вводит кучу новых ключевых слов и конструкций просто ради syntactic surgar по велению левой пятки. Везде появляются и типизированные контейнеры, и лямбды, и асинхронные операции, и чёрт ещё знает что. Для Java бонусом идёт зоопарк систем сборки и графические библиотеки (AWT/Swing/JavaFX/etc.) Python плюёт на обратную совместимость, из-за чего приходится держать на машине все версии, начиная, наверно, с 3.6 (а ещё 2.7 впридачу).
В языках помоложе порог вхождения ниже, но и чего-то неизбежно не хватает. Ну а дальше юзеры ноют, почему в языке X это есть, а у нас нет, и ещё через десять лет наш язык тоже постепенно превращается в X. Так что в этом контексте C++ ещё не самый плохой вариант, и будет интересно посмотреть, во что превратятся за ближайшие годы его конкуренты.
А вообще... кто нас спрашивает-то? Вот решил Джобс, что на iPhone все будут писать на Objective-C. И всё, как миленькие бросились писать на Objective-C. Потом объявили переход на Swift, и не стало никакого Objective-C. Сик транзит, как говорится.
agalakhov
00.00.0000 00:00+3Да, с накоплением фич это действительно так. Но сказывается и то, кто именно разрабатывает язык. Я слышал от знакомых математиков ругань в адрес комитета C++, что те, кто придумал добавить в язык концепты, изобрели деревянный велосипед и не разбираются в теории типов и заодно в теории категорий. Очень похожая ситуация с ООП, когда в базовых учебниках представляют наследование классов как что-то вроде получения подмножества множества, а математически это ни фига не так и имеет вообще другие свойства. ООП в его Java- или C++-виде разработано наивно, и при глубоком копании там вылезают математические противоречия.
Среди новых языков есть много таких же наивных (D, Kotlin), а есть попытки математизировать подход и сделать "как теория велит" (Rust). Насколько там удастся придерживаться теории, покажет время, но пока получается неплохо.
Всякие вещи вроде лямбд на самом деле очень любит компилятор, а не пользователи. Дело в том, что чем императивнее код, тем труднее его оптимизировать, а для чисто функционального кода оптимизатор написать легче всего. В этом основная причина того, почему "громоздкие" языки нередко обходят C на benchmark game. Оптимизатор компилятора умеет писать код лучше человека, и характерное для C "разжевывание" алгоритма ему только мешает. Тот же алгоритм на шаблонах C++, на Rust, на Haskell, на чем угодно, развязывает компилятору руки, машинный код получается компактнее и изящнее. Дальше уже вопрос, справится ли человек с таким языком. Писать на шаблонах C++ очень трудно, писать то же самое на Haskell на порядок легче, на Rust примерно так же. На данный момент у среднего программиста код на Rust будет получаться лучше, чем на C++ (если честно, я вообще не доверяю коду на C++, написанному средними программистами, потому что за 20 лет уже насмотрелся, ЧТО там бывает).
0xd34df00d
00.00.0000 00:00+1если честно, я вообще не доверяю коду на C++, написанному средними программистами
Не доверяю коду на C++, написанному какими угодно программистами, потому что на нём невозможно писать корректный код за конечное время.
a-tk
00.00.0000 00:00Вместо C++ может быть любой язык на самом деле.
Любой код пишется в системе некоторых допущений относительно внешнего мира.
agalakhov
00.00.0000 00:00Языки все-таки очень разные по сложности освоения. И по вероятности ошибок. На C++ легко сделать ошибку даже в Hello World. На Фортране замена десятичной точки на запятую в корне меняет смысл строки, при этом и до, и после замены строка синтаксически верна и компилируется. На Питоне легко налажать с алиасингом объектов в массивах, но таких пакостей, как в Фортране, нет как класса. На Rust на этапе компиляции лезут даже некоторые архитектурные и логические ошибки, когда компилятор замечает, что не все варианты исполнения рассмотрены или что иногда объект уничтожается раньше, чем предполагал программист. И еще разная сложность маскировки ошибок. На C++ я легко напишу код намеренно с багом, и искать этот баг придется очень долго, без дебаггера большинство людей не увидит. На каком-нибудь Go или Rust так не получится, странная конструкция сразу бросится в глаза.
0xd34df00d
00.00.0000 00:00Не любой. У C++ фрактальная сложность, и на нём очень тяжело писать код, который не будет падать, проезжаться по памяти и иметь прочие UB.
Dooez
00.00.0000 00:00А критика концептов с точки зрения математиков есть где-то в виде текста? Очень интересно.
agalakhov
00.00.0000 00:00К сожалению, не знаю. Самому интересно. Критиковавший человек специализируется как раз на языках и компиляторах, а критика была в духе ":facepalm: ну как так можно-то, тут люди диссертации пишут на тему того, как типы в языке работать должны, а эти слоны в посудной лавке взяли и сделали все поперек учебников". Но в любом случае имелось в виду soundness системы типов.
0xd34df00d
00.00.0000 00:00Проблема в том, что не считая вакханалии с C++14 и далее, в целом C++ довольно консервативный язык, переживший десятилетия с достаточно скромными изменениями и хорошей обратной совместимостью.
C++14 был 10 лет назад, до него два единственных стандарта — C++98/03 и C++11. У меня язык не поворачивается назвать это «пережил десятилетия».
А у кобола тоже достаточно скромные изменения и хорошая обратная совместимость. Не уверен, что это хорошо.
Везде появляются и типизированные контейнеры, и лямбды, и асинхронные операции, и чёрт ещё знает что.
Проблема не в контейнерах и лямбдах, а в том, что они прикручиваются сбоку.
rg_software
00.00.0000 00:00до него два единственных стандарта — C++98/03 и C++11.
Дело не в формальном стандарте, у Питона вообще нет "стандарта", была некая ad hoc реализация автора, и это и был "стандарт", и ничего. "Стандарт" C++ описывался в книге Страуструпа The C++ Programming Language, и по ней и определялось, что в языке, а что нет. И по изданиям видно, что эволюция языка до C++11 была достаточно скромной, а расширение шло в основном за счёт стандартной библиотеки. Соответственно, если язык фактически в ходу с середины 80-х, оттуда и отсчитываем.
Не уверен, что это хорошо.
А я же немного другую тему обсуждаю: если вы любите изменения, но не любите монструозность C++, то будьте готовы, что ваш любимый язык NN трёх лет от роду ещё через 15 лет будет точно так же монструозен. И да, в нём с самого начала будут лямбды, а через 15 лет прикрутят сбоку то, что будет модно через 15 лет.
0xd34df00d
00.00.0000 00:00До этак 2005-2006-го года на плюсах какой-либо переносимый код писать было почти невозможно (можно посмотреть количество костылей и #if'ов по компиляторам в бусте того времени, например), поэтому говорить о какой-либо обратной совместимости языка до более-менее появления соответствующих хоть какому-то единому стандарту (будь то хоть святые писания Страуструпа) реализаций нельзя, потому что обратной совместимости не бывает без простой совместимости, а её не было. При этом даже если бы была одна-единственная реализация, было бы лучше.
Итого получается, что лучшие годы C++ были весьма скоротечны — от середины нулевых до середины десятых (когда, по-вашему, всё сломалось с выходом C++14).
А я же немного другую тему обсуждаю: если вы любите изменения, но не любите монструозность C++, то будьте готовы, что ваш любимый язык NN трёх лет от роду ещё через 15 лет будет точно так же монструозен.
Мой любимый язык — хаскель, ему 30 лет, первый стандарт вышел в том же 98-м. При этом в него добавляют сильно больше фич, чем когда будет добавлено в плюсы (вон, какие-нибудь там QuantifiedConstraints или LinearTypes из недавнего), но эти все фичи почти ортогональны, разумны и работают так, как ожидается, и, что самое главное, не приводят к UB в хитрых комбинациях, и так далее.
Просто, похоже, авторам C++ не повезло разложить язык по очень кривому и неортогональному базису, поэтому всё в итоге зависит от всего, а фичи добавляются там, где сумма имеющихся базисных векторов максимальна.
victor_1212
00.00.0000 00:00> Просто, похоже, авторам C++ не повезло разложить язык по очень кривому и неортогональному базису
мыслите правильно, но требуемая ортогональность также связана с возможностями используемой грамматики (сравните с грамматиками van Wijngaarden для определения ALGOL 68), с учетом того что С++ начинался как препроцессор для C, вероятно таки ожидания оправдал,
хотя по большому счету возможно сложнее, например автор Fortran John Backus считал узким местом языков высокого уровня саму архитектуру von Neumann, см выдержку из его статьи 1979 года -
0xd34df00d
00.00.0000 00:00Так это всего лишь синтаксис, а синтаксис скучный. В семантике куда больше проблем.
rg_software
00.00.0000 00:00поэтому говорить о какой-либо обратной совместимости языка до более-менее появления соответствующих хоть какому-то единому стандарту (будь то хоть святые писания Страуструпа) реализаций нельзя, потому что обратной совместимости не бывает без простой совместимости, а её не было
Я вполне понимаю эту логику, но мне кажется, что с такой меркой подходить к реальному миру просто непродуктивно. Первый стандарт языка С -- это ANSI 1989, и если мы реально будем отсчитывать историю C от 1989 года, то на чём же тогда UNIX написан был? Да, костыльность старого кода C++ очевидна, но тем не менее, тут вопрос с чем мы сравниваем -- с гипотетическим идеалом или с реальными production-level языками того же времени и ниши.
Мой любимый язык — хаскель, ему 30 лет, первый стандарт вышел в том же 98-м.
Страуструп на эту тему высказался: языки делятся на те, которые все ругают, и на которых никто не пишет. Это ни в коем случае не в пику Хаскеля, но надо понимать, что он живёт в условиях "ниже радара" широкой публики, а это совсем не та модель бытования, которую обсуждают в рамках разговора "чего бы такого изучить, чтобы через 30 лет оставалось актуально". Мне, положим, FORTH нравится, он сразу вышел хорошо, там и менять ничего не нужно.
0xd34df00d
00.00.0000 00:00Первый стандарт языка С — это ANSI 1989, и если мы реально будем отсчитывать историю C от 1989 года, то на чём же тогда UNIX написан был?
Насколько несовместимы были между собой разные версии C до 89-го?
Это ни в коем случае не в пику Хаскеля, но надо понимать, что он живёт в условиях "ниже радара" широкой публики, а это совсем не та модель бытования, которую обсуждают в рамках разговора "чего бы такого изучить, чтобы через 30 лет оставалось актуально".
У вас как-то сменился тезис.
Язык растёт и развивается, в него запиливают кучу новых фич, включая требуемые в продакшене, и это не делает его настолько же монстроидальным, как C++. Начинать теперь говорить, что это из-за существенно более низкой доли языка — подгон решения под ответ. Тем более, что про доли-то у вас изначально ничего и не было.
BlackSCORPION
00.00.0000 00:00Странно что никто не говорит того же о питоне, который на 5 лет старше Джава, и такой зоопарк разных подходов, что приходится изучать питон и все сопутствующие инструменты чтобы просто пользоваться продуктами на питоне.
Я не программирую на питон, но когда очередная штука на питоне не работает ни по инструкции, ни перебором минорных версий питона, приходится все же запускать в дебагере и пытаться понять как же её запустить ) а иногда даже писать автору, потому что не хватает знаний понять баг это или ты просто не умеешь его готовить.
agalakhov
00.00.0000 00:00Как раз не странно: дело в том, что Python - высокоуровневый язык, не компилируемый и вообще почти как бейсик, поэтому те, кого не устраивает Python, просто быстро уходят на что-нибудь другое. У Python все преимущества языка синтаксические, а технических нет. Более того, очень многие компоненты Python написаны не на самом Python, а на других языках, и я не про компилятор. Всякие NumPy и иже с ними. Python по построению не универсален, даже при написании просто математики без всякого доступа к железу и системных вызовов используются библиотеки, написанные не на Python.
Напротив, C и C++ до сих пор на некоторых платформах безальтернативны в том смысле, что альтернатива - ассемблер. Другие языки на них не умеют обращаться к платформе иначе, чем через написанные на C или C++ библиотеки. Приходится маяться с C, несмотря на все его недостатки.
GooGreyGreen
00.00.0000 00:00+1Вы почти подтвердили мои слова. Вся проблема многих языков, в том числе и современных т.к. ноги растут из Си и Си-подобных языков, в их слабой эргономике и в ошибочном принципе построения языка. Это как в шутке мыши кололись, плакали, но продолжали есть кактус. Вот за это появилось много подколок в сторону Си. Ими попросту сложно пользоваться надо блин привыкать. Из-за этого и повышенная сложность подготовки и стоимость этой подготовки которая является определяющей в нашем мире. Поэтому как ни прискорбно Си и иже с ними со временем канет в лету или большую часть кода будет писать ИИ.
a-tk
00.00.0000 00:00Если есть языки, которые наследуют стиль Си, то в этом стиле есть что-то привлекательное. С другой стороны, есть языки, которые наследуют стиль у других языков.
nuald
00.00.0000 00:00+5Похоже что автор оригинального текста совершенно не следит за текущими трендами, и есть намного лучше статьи, которые стоит переводить, например: https://verdagon.dev/blog/when-to-use-memory-safe-part-2
Есть очень много проектов, включая от крупных корпораций, которые работают над болячками текущих ЯП, и думаю, мы увидим ещё много чего интересного. И анализировать будущее по поисковым запросам, это вообще последнее дело, потому что профессионалы вообще могут не использовать гуглы и stack overflow, а просто читать документацию (!!!).
MountainGoat
00.00.0000 00:00+7Пишу программу на С++, которая должна собираться и Студией и gcc. Таки о каких стандартах ви мне говорите? В них такие базовые вещи, как литерал, ведут себя по разному. std::unique_ptr пришлось по всей программе перепроверять - ведёт себя по разному. strncpy в студии агрессивно deprecated, а в gcc не имеет альтернативы, если не ставить библиотеку специально для него.
"И каждый уже десять лет учит роли, о которых лет десять как стоит забыть" -- Гребенщиков.
gmtd
00.00.0000 00:00+17100 джунов учат Pythoin по ютюбу и гуглу
Три С программера пишут драйвер для девайса
Два сеньор бэкендера делают серьезную многопоточную систему на Java
Вот вам и вышеприведенные результаты популярности в поисковиках
Суета сует
gogalaim
00.00.0000 00:00+3Критерий стравнения язиков программирования по "энергетической эффективности", это более чем странный критерий сравнения. Тем более, что получить количественвенную оценку языка вряд ли получится. (можно оценить конкретное решение, но это будет оценка алгоритма, но не самого языка)
ksbes
00.00.0000 00:00+1Да и не только энергетическая эффективность. Для многих языков ( Perl, PHP, JavaScript ) задача "нарисовать фрактал Мандельброта в bmp файл" выглядит… странновато. А, например, задача "одновременный вcтречный запрос из симметричных потоков" — так вообще невыполнима (классические JavaScript и Python)
piratarusso
00.00.0000 00:00+4Я бы напомнил некоторые мысли.
Мысль #1: Производительность -это не характеристика языка программирования, а характеристика конкретного приложения, написанного конкретным человеком. Это существенная метрика, но не единственная и не всегда самая важная.
Мысль #2: Языки программирования служат для общения между программистами. И тут мысль #3 играет существенную роль.
Мысль #3: Популярность языков программирования содержит иррациональную составляющую. Я бы назвал это модой.
Мысль #4: Оценить долгосрочные перспективы в таких обстоятельствах затруднительно.
AdVv
00.00.0000 00:00+11) Язык программирования - инструмент. Каждый инструмент лучше подходит для своей задачи. Когда требуется производительный код, то инструмент нужно подбирать соответствующий.
2) Языки программирования служат в первую очередь для общения между программистом и машиной.
3) Содержит иррациональную составляющую, но она далеко не самая определяющая. Есть еще заложенные при проектировании свойства и поддержка крупных компаний.
4) Предсказание будущего вообще занятие крайне неблагодарное.
LordDarklight
00.00.0000 00:00Рассуждения о будущем языке программирования на примере анализа языков программирования из прошлого (ну тут только Swift, Kortlin TypeScript, Dart и с натяжкой Go можно считать современными ЯП - остальные - это всё уже старье - даже Rust - хотя да, пожалуй его сбрасывать со счетов пока не стоит - в силу оригинальной модели управления памятью - но, я всё-таки склонен считать его проходным языком - эдаким первопроходцем нового подхода - и за ним придёт другой похожий ЯП, а то и не один). Но если здраво судить - то все причисленные мной выше ЯП - это всё примерно об одном и том же - семейства императивных языков программирования, с единой базой с корнями растущим из языка Си (и немного из Pascal), и просто построенные на разных механизмах управления памятью. Немного особняком стоит только Python (хотя это уже достаточно старый ЯП, но популярность у него резко возросла лишь в последние десятилетие) - может быть в этом (в изяществе и простоте его достаточно современно синтаксиса и хорошей системе библиотек) и заключается текущая популярность ЯП. Но.... его кросс-платформенность, скорее кросс-применимость пока очень ограничены, что не позволяет ему претендовать на место главного ЯП XXI века, и мне кажется, эти ограничения так и останутся - тут сильно мешает отуствие строгой типизации (хотя через декораторы её и можно ОЧЕНЬ НЕУДОБНО делать - но в целом она отсутствует) - это было и плюсом и минусом данного ЯП - с моей точки зрения сейчас это даже больше минус, сдерживающий дальнейшее развитие ЯП (по сути он уже достиг почти всего, что можно было бы достичь в его структуре); ну разве что многопоточному подходу не хватает достаточного изящества (в основном за зачёт легковесных квазипотоков и гетерегенной архитектуры выполнения) - что тоже очень сильно дальше будет сдерживать развитие данного ЯП в стремительно развивающейся многопоточной среде выполнения современного оборудования (но это не означает, что ЯП Python не сможет это преодолеть).
Но, всё же. Правильно-таки не пытаться смешивать друг с другом типизированные строго компилируемые ЯП и интерпретируемые (в т.ч. с виртуальной машиной) - в будущем разделение области применения этих ЯП будет только возрастать, и они заведомо буду решать разные задачи. Те блоки - где критически важна будет производительность - будут программироваться на ЯП, максимально близких к машинному коду - таких как С и C++, хотя Rust-подобные ЯП со временем могу существенно потеснить Си-подобные ЯП, т.к. при схожей сложности программирования и производительности (особенно в сравнении с С++) Rust код выходит куда более надёжным (на нетривиальных программах).
Отдельное место займут языки условно-прикладного уровня - такие как C#, Kotlin, Swift, и, вероятно, Python - с менеджером памяти разрабатывать ПО будет куда эффективнее (и достаточно надёжно), а обширные библиотеки в купе с развитыми компиляторами (трансляторами кода) дают этим ЯП хороший задел для быстрого написания относительно небольших кросс-платформенных программ и библиотек. Всего, что обладает достаточно фиксированным набором заранее определённой функциональности, требует высокой надёжности, и эффективности.
Но, всё же, ключевую роль в ЯП будущего должны занять ЯП нового поколения - 5-го, выросшего на ныне ещё плохо развитом 4-ом поколении ЯП прикладного уровня (хотя кто-то, я и в том числе к 4-том поколения как раз бы отнёс все эти выше перечисленные ЯП с расширенным управлением памяти и кросс-платформенностью: как C#, Kotlin).
Суть ЯП 5-го поколения - высокий уровень абстракции и декларирования намерений (и высокое сочетания различных парадигм программирования, так что их уже трудно будет по ним разделять). Текст на языках 5-го поколения это в большей степени декларирование того что надо сделать, а не как это надо сделать - т.е. больше по сути просто расширенное декларативное описание постановки задачи (хотя в нём может быть и много более более детальных нюансов - по необходимости, когда нужно акцентировать решение постановки задачи на применения заданных подходов; в т.ч. может применяться ограниченно и императивное, функциональное, объектное и аспектное программирование - опять же по необходимости).
После постановки задачи её уже далее будет решать, условно, искусственный интеллект, с подключённой базой наработок (знаний) - эдакий продвинутый ChatGPT, специально заточенный под решение задач определённого синтаксиса с подключёнными теми или иными пакетами базы знаний (как сервисами, вероятно за отдельную плату).
ИИ будет анализировать постановку задачи, собирать статистику из среды её применения и автоматически генерировать итоговый код (с усиленным применением готовых библиотек, которые будут создаваться, в т.ч. на ЯП более низкого уровня). Этот код будет автоматически тестироваться и и автоматически прогоняться по прикладным тестам (на реальных или условно реальных данных и профилях интерактивной работы пользователя).
Периодически такой код будет автоматически переанализироваться (по актуальной статистике его выполнения и пересобираться по необходимости - все нюансы буду автоматически отправляться в базу знаний).
Периодически сгенерированный код будет отдельно подвергаться внешнему аудиту, по результату которых в исходную постановку могут вноситься уточняющие коррективы, которые так же буду анализироваться и отправляться в базу знаний (чтобы в дальнейшем автоматически уметь их использовать).
Чтобы понять что такое ЯП 5-го поколения можно взглянуть на языки семейства SQL (или NoSQL) - это, конечно не 5-ое поколение, но идеологически они наиболее близки к нему по принципу формирования.
И да, ЯП 5-го поколения должны изначально синтаксически строиться так, чтобы код постановки задачи изначально формировался таким образом, чтобы его легко можно было подвернуть автоматический декомпозиции на предмет распределённого параллельного выполнения. Но при этом этот ЯП должен быть максимально упрощённым для выделения параллельных блоков. Более того, давать возможность (соответствующим отдельным синтаксисом) для ИИ самому решать как распараллелить указанный блок кода (ну или оставить его как есть) - тут ведь ещё ИИ будет опираться на среду выполнения - если в ней нет лишних ресурсов параллелизма, то и распараллеливать нет смысла; так же ИИ будет опираться на статистику профилирования - попробовав прогнать несколько версий кода (с разной стратегий распараллеливания) и выбрав наиболее оптимальную; более того, ИИ в динамике выполнения может менять стратеги распараллеливания. В этом вся мощь ЯП 5-го поколения - кросс-платформенности и динамическая адаптация под среду выполнения! ЯПА 5-го поколения может генерировать по одной и той же постановке задачи совершенно разный код для разных условий применения, при этом перебирая сотни разных вариантов его исполнения, ориентируясь на конкретную статистику реальной среды приложения.
Само собой ЯП 5-го поколения будет и создавать подробный аналитический фидбэк программисту, по анализу поставной кода и анализу его выполнения (в т.ч. предлагаю внести правки в исходную постановку - если узрит там какие-то проблемы; при этом заранее эти правки ИИ сможет опробовать прогнав тесты и собрав статистку, чтобы не быть голословным).
Вот таким должен быть язык программирования будущего - но, это скорее уже вторая половина XXI века, хотя по сути, в предлагаемой идеи нет ничего того, что нельзя было бы сделать уже сейчас - но всё в совокупности, включая натаскивание базы знаний, требует достаточно много ресурсов на разработку, и несёт в себе много революционных концепций в структуре организации как программирования так и дальнейшего практического применения.
А Вы тут заладили Rust или Python буду языками программирования.... и те и другие будут - но у них будет своя ниша, а над ними появится куда более продвинутый ЯП, на котором в основном и будут решать прикладные задачи!
ksbes
00.00.0000 00:00Prolog умер мертворожденным.
Императивность для актуального языка — обязательна. Т.к. подавляющее большинство решаемых элементарных задач (возьми то, сделай с ним это, положи сюда) — императивны. Реальность "императивна"! (хотя и не все религии/космологические модели с этим согласятся)LordDarklight
00.00.0000 00:00Prolog умер мертворожденным
Пролог безусловно декларативный ЯП, но я заведомо не стал его приводить, так как он по сути однопарадигменный ЯП - логический - а я сразу объявил, что ЯП 5-го поколения должен быть непросто мультипарадигменным, а в нём явно не должно быть ярковыраженной ориентированности на какую-то одну парадигму. Усоовно он должен быть настолько же императивным, насколько и функциональным, но не только. И логические конструкции а-ля пролог в нём вполне себе тоже могут иметь место быть
Реальность "императивна"!
Я бы с Вами поспорил - но мне лень (хоть я и бесспорный адепт именно императивного программирования). Просто императивное программирование втундычевают со школьных азов и оно сейчас наиболее распространено в практически применении. Да и императивные ЯП на данный момент более изящны синтаксически. Но это не более чем сложившаяся условность. Да и сейчас эпохи гибридизации. Так что на том же F# можно создавать программы не хуже чем на C# (хоть стиль и не будет чисто функциональным, как и на том же C# современный синтаксис, со времён появления лямбд, уже далёк от чисто императивного).
Но вот SQL - это более императивный ЯП или функциональный? Хотя бы классический ANSI диалект
DenisPantushev
00.00.0000 00:00+3Если сделать язык декларативным и с высоким уровнем абстракции (а я вас удивлю, но такие языки создавались уже лет пятьдесят и более назад), то я гарантирую вам, что появятся сотни мануалов и статей в гугле, как заставить программу выполняться определенным образом - сиречь, КАК программа должна выполняться. Да-да, императивное программирование.
Любая декларативность в языке приводит к тому, что необходимо знать, КАК будет выполняться вычисления и КАК заставить "декларативную" программу выполняться определенным образом. Любые декларативные фишки порождают необходимость иметь специалистов, которые знают, как система рабоает под капотом. Любимые вопросы на собеседованиях - КАК работает система, которая есть "декларативная" и как заставить ее считать определенным образом.
Спринг - декларативная. Любимый вопрос на собеседованиях - как работает под капотом этот спринг.
Все классы коллекций что в Джаве что в Шарпе - основное стремление сделать программирование декларативным, и основной вопрос - КАК работает хеш-мап Джаве, к примеру.
Джава-аннотации - декларативные. Вопрос - как они работаю? Как заставить их работать нужным образом?
Стримы - та-же фигня. Как написать так, чтобы работало наиболее эффективным образом?
Попишите пет-проекты на Прологе и вы шарахаться будете от декларативного программирования.
LordDarklight
00.00.0000 00:00(а я вас удивлю, но такие языки создавались уже лет пятьдесят и более назад)
Я и не утверждал иного (хотя если у Вас есть примеры таких ЯП, я бы бы рад, если бы Вы поделились). Я просто прогнозирую, что именно таков будет ЯП будущего. Но 5-е поколение ему придаёт ИИ анализ, динамическая база знаний и динамическая пересборка под динамически меняющуюся среду выполнения и накопленную статистику.
Ну а высокий уровень абстрагирования и готовности к параллелизму тоже должны быть поставлены во главу угла - ЯП должен сразу под это проектироваться, но при этом оставаться достаточно простым в освоении (хотя бы поэтапно).
как заставить программу выполняться определенным образом
На первых порах таковое вполне может быть. Но тут во вторую главу угла должна ставиться идея адаптируемости, как самого ЯП (в его развитии), так и умного смарт компилятора - чтобы свести такие ситуации к минимуму. Ведь в итоге должна получиться не просто "тупая" обёртка фреймворка по трансляции одного API в другой (на примере нынешних ORM DB, или трансляции, скажем TypeScript в JavaScript) - это должна быть аналитическая система с глубоким смысловым анализатором, которая условно "реально" должна понимать, что от неё хотят и осмысленно обращаться к базе знаний за поиском подходящих паттернов решений тех или иных подзадач. И тут очень много будет зависит от качества входного синтаксиса API и качества соответвующей ему системы знаний. Ну а почти все шероховатости, когда будет требоваться тонкая настройка как раз должны со временем нивелироваться пополнением этой базы знаний или модификацией синтаксиса входного API.
А в остальном - уж лучше ИИ транслятор скажет программисту где и в чём он его не до конца понял (по возможности сразу предложив несколько вариантов интерпретации, с необходимыми поправками-уточнениями для исходного кода - программисту, в общем случае, просто нужно будет одним кликом выбрать нужный вариант), чем будет генерировать какой-то популярный, но не верный для текущего случая код.
Причём анализ можно делать прямо в процессе набора кода - учитывая и предыдущий код и стиль программирования данного программиста - заранее предлагать сделать те или иные уточнения, которые программист может принимать или отвергать - и это всё тоже будет сохраняться в персональный профиль программиста и конкретного проекта. По сути таким путём уже работают AI-помощники по набору кода - тот же Copilot - думаю именно из них далее и будет вырастать прогнозируемая мной система декларативного программирования - все предпосылки уже есть.
Любая декларативность в языке приводит к тому, что необходимо знать, КАК будет выполняться вычисления и КАК заставить "декларативную" программу выполняться определенным образом
Вот этого как раз принципиально хотелось бы избежать (хотя я тут сам себе буду сейчас противоречить). Это ключевая цель - написанная исходная логика должна быть асимптотически блико 100% однозначной к получаемому результату. Если есть заметное противоречие - то ИИ компилятор сразу об этом должен доложить. Но это не означает одно единственное решение - только один результат - а вот множество решений может выбирать компилятор (из описанных мной ранее соображений). Но программист исходя из своих соображений может его особыми синтаксическими хинтами ограничивать в этом выборе или задавать повышенные весовые приоритеты для каких-то стратегий - вот тут да - уже нужно будет разбираться в том, какие решения могут быть на выходе и почему одни неочевидно могут быть лучше других. Но это не обязательно делать рядовому программисту - такое углубление - это рост квалификации программиста. Зачастую, как выше писал, уже уровень внешнего аудита - с привлечение особых специалистов; либо для особых случаев да - при приёме на работу сразу нужно будет предъявлять такие требования. Как выше написал - ИИ трансляция тут должна быть полностью прозрачная для анализа (можно даже готовить особый отладочный результирующий код - чтобы его проще было анализировать для понимания выбранной ИИ стратегии решения).
Спринг - декларативная. Любимый вопрос на собеседованиях - как работает под капотом этот спринг.
По идеи этот вопрос должен быть не уместным в такой формулировке для ЯП 5-го уровня. Так как система подразумевает динамическую адаптацию под условия выполнения. И, во-первых, сама должна выбирать наиболее оптимальные пути решения (чтобы программисту не пришлось углубляться), либо - программист "условно не должен знать" как оно работает, но должен уметь это выяснить на конкретном примере и системе исполнения. И уметь заставить ИИ сгенерировать другие решения, оценить их производительность, и уметь задать хинты для выбора нужного вида решения. Но тут нет ничего трансцендентного. Но это уже требования к программисту определённого уровня квалификации (скорее по алгоритмам той или иной прикладной области - т.е. по стратегиям решений, а не по тому как работает ЯП с ИИ компиляцией) - это лишь подчёркивает то, что роль квалификации программистов с приходом ЯП 5-го уровня по-прежнему будет важна, но вот мат ожидание этой квалификации будет больше смещаться в меньшую сторону т.к. со временем ИИ и без такого анализа научится сам подбирать наиболее оптимальный алгоритм персонально для каждого отдельного случая применения. А для остального - будет проводиться плановый периодический сторонний аудит с приглашением более продвинутых программистов-аналитиков. В итоге на рядовом исполнении будет заметная экономия на специалистах.
основной вопрос - КАК работает хеш-мап Джаве, к примеру.
Для ЯП 5-го поколения таковой вопрос тоже навряд ли должен быть уместным (если от программиста, как написал выше, не требуется глубокое понимание готового кода, хотя хоть какое-то - требоваться должно). Для исходного API скорее коллекции должны быть разделены только по функциональному признаку, чем по вопросам оптимизации. Это уже ИИ компилятор должен сам решить какая в итоге фактическая реализация будет более оптимальной. А при анализе кода выдавать статистический профайлинг - где будет видно сколько времени уходит на те или иные операции - а если тут же будут предложены другие варианты реализации (с таким же профайлингном) - то программисту и без деталей в реализации фактических коллекций будет видно что и где быстрее или медленнее - и если надо, он сможет хинтами пометить коллекцию в исходном коде - как предпочитающую ту или иную реализацию. Но со временем в динамике ситуация может измениться и ИИ может дополнительно рапортовать обратной связью программисту о возникшей потенциальном просадке производительности в таком захинтованном коде - он сможет провести повторный анализ и может выбрать другую коллекцию или убрать лишний хинт, дав ИИ больше свободы (тем более, с уже куда более широкой накопленной статистикой реального приложения, и с паттернами из базы знаний)
Джава-аннотации - декларативные. Вопрос - как они работаю? Как заставить их работать нужным образом?
Это вообще не надо сюда приплетать. Java не декларативный ЯП, без ИИ анализа - это как сравнивать телегу из каменного века и современный автомобиль с автопилотом. Вроде бы колёса и там и там есть, вроде бы едет - а делает всё по-разному и с разной степенью свободы. Впрочем современные автомобильные автопилоты ещё тоже не доросли до "условно" 5-го поколения ЯП (по поколениям развития автопилотов у них вроде бы 2-3-тье поколение: продолжительное автономное вождение, под чётким контролем водителя; но даже в таком случае водителю же не требуется разбираться в том как принимает те или иные решение ИИ автопилота, но правила вождения пока знать надо; на 5-уровне ИИ автопилот будет полностью автономным, хотя я бы всё-таки поставил это на 6-ой уровень, а тогда будет чёткое соответствие с развитым ИИ 5-го поколения и 5-ым уровнем автономного вождения(ныне 4-й): полный автопилот при определённых условиях и размеченной дороге).
Попишите пет-проекты на Прологе и вы шарахаться будете от декларативного программирования.
Спасибо. В институте уже проходил, и даже потом курсовую писал на тему "Экспертной системы" совсем не на прологе (ну это уже другой курс и другая тема были, там ЯП не ограничивали), а на императивном языке (хот я многие писали, кстати, на функциональном, а кто-то и на прологе).
Я совсем не такой декларативный ЯП имею в виду. Напротив, его синтаксис должен быть достаточно свободным. Вот тот же SQL я не зря привёл в пример. Можно же не зацикливаться на ANSI SQL а рассмотреть Transact-SQL или PL/SQL - конечно кто-то скажет что это уже во многом императивный стиль и я с этим не буду спорить. Но суть тут в другом - тут изначально идёт некий посыл того "что надо сделать", с, пока ещё возможно большой, долей того "как это сделать" - но это, всё-таки, не ЯП 5-го поколения ещё. Просто я не хочу загонять декларативный синтаксис в узкие рамки. Просто он не должен исполняться как написан - с прямой трансляцией. Он должен быть разобран ИИ транслятором, должна быть понята логика, должны быть проведены соответствующие аналитические "запросы" к базе знаний и к среде исполнения, собрана статистика, подготовлено несколько решений, проведены профилированные тесты (и тесты надёжности, которые так же должны быть автоматически подготовлены) - и только потом выбрана та или иная реализация для финальной трансляции
Коли будет угодно писать императивно - пишите, функционально - пишите - логически - пишите (в рамках широкого, но всё ;t определённого синтаксиса исходного API) - одну и ту же логику можно описать по-разному - в итоге всё-равно она будет преобразовано в какое-то более-менее единое промежуточное "логическое" дерево трансляции (или несколько вариаций деревьев).
Вот только от ООП парадигмы вряд ли тут удастся далеко уйти - всё-таки на ООП строить каркас гибридных многопарадигменных ЯП проще. И оперировать ИИ транслятору с объектами-сущностями тоже будет проще. Да и как я уже говорил в самом начале - нужно повышать уровень абстракций - а тут уже хорошо проявляется себя АОП - а оно базируется на ООП.
Но для проведения высокого уровня декомпозируемости кода (хотя бы для целей распараллеливания) нужно будет достигать высокого уровня идеологии как ООП так и функциональных подходов. Так что на привычное сейчас ООП императивное программирование такой ЯП навряд будет похож. А вот идеи из эликсира, смалтока и java spring AspectJ, могут быть очень даже востребованы
sshikov
00.00.0000 00:00+1Это уже ИИ компилятор должен сам решить какая в итоге фактическая реализация будет более оптимальной
Это невозможно в общем случае, потому что определяется свойствами данных в рантайме. Ну или замените компилятор на JIT хотя бы.
LordDarklight
00.00.0000 00:00свойствами данных в рантайме
Я уже несколько раз об этом написал - неужели никак не дойдёт - что ЯП 5-го поколения это ЯП с компиляцией под среду исполнения - я не говорю слово "рантайм" - чтобы не сужать все способы ибо одним рантаймом такой подход не ограничивается - но можно и в "рантайм" - и я об этом я тоже упоминал, говоря о динамической перекомпиляции. Всё условно говоря так же (но более продвинуто) как происходит с запросами в СУБД - когда строятся планы исполнения запросов. Но всё же - я больше за использование статических анализаторов и компиляторов - это первичное, динамика - это уже вторичное.
Но если говорить о статике - то не может быть такого, чтобы ПО на ЯП 5+ просто взять и запустить. Оно обязательно должно пройти процесс развёртки под среду выполнения - с её анализом и адаптации программы под неё (но, в принципе, я не исключая и запуск по дефолту - но это наврядли будет оптимально). Серьёзное ПО так не может поставляться без соответствующего базового сопровождения со стороны программистов поставщика, и последующего сопровождения со стороны программистов потребителя. Но это всё условность - думаю, со временем AI развёртка освоится так, чтобы свести такое сопровождение к минимум.
компилятор на JIT хотя бы
Чем JIT не компилятор, я это и не исключал? Но.... всё-таки каждый раз при старте всё перекомпилировать - тоже не вариант! Я за гибридизацию - компиляция при развёртке (deploy) приложения - т.е. что-то типа AOT-компиляции из промежуточного кода, но с предварительным анализом среды исполнения, с кешированием в файлах скомпилированных блоков кода. А затем периодический мониторинг: сбор статистики и профилирование - и перекомпиляция при достижении заданной вероятности улучшения отдельных блоков кода с последующим их фактическим тестированием и если улучшение статистически значимо - установкой как основновных блоков. Возможно даже "параллельная" установка нескольких разных версий одного блока и выработка критериев ветвления - при каких условиях использовать ту или иную реализацию - по сути это всё может напоминать самообучающуюся нейросеть, которая сама себя перестраивает. Это и есть AI-компиляция и исполнение - как ключевая особенность именно языков программирования 5-го поколения.
wibbtwo
00.00.0000 00:00Мне кажется, Вы один в один переписали проспект из японского проекта "Компьютеров пятого поколения" 1980-х годов. Нет?
LordDarklight
00.00.0000 00:00Про компьютеры 5-го поколения безусловно читал, и безусловно опирался на эти материалы. Развитие компьютеров всегда неуклонно связано с развитием систем управления этими компьютерами, в т.ч. языков программирования. Но информации о будущих компьютерах и языках очень и очень мало. По сути, о ЯП 5-го поколения очень нет вообще чёткого представления (про 4-ое то всё очень размыто, как и про 3-тье - есть разные мнения какие ЯП по каким признакам относить к 4-ому поколению, или оставить пока в 3-тьем или говорить о 3+ поколении - я бы вот, всякие C#, Java, Kotlin и т.п. отнёс бы к ЯП 4-го поколения - но сдвинул бы дальнейшую нумерацию на 1; тогда ЯП с AI надо уже относить к 6 поколению, в 4 - некое переходное поколения ЯП с акцентом на Low-Code (это если обобщая): тут и уже и продвинутое визуальное программирование, и всякие хитрые разметки и кодогенерация, и продвинутая помощь IDE в наборе и анализе программного кода, и декларативные замашки - хотя во многом всё это уже есть, да хоть в C# и его платформе Dot NET - тогда может и не надо ничего сдвигать - и указанные ЯП сейчас в активной стадии перехода от поколения 3++++ к 4-ому поколению без появления нового ЯП).
Сами поколения приписываются не на перёд, а постфактум - вот сформируются (и в одночасье поколения не сменяются - это длительный процесс и чем выше поколение - тем это требует существенно больше времени и сам переход всё более размытый - когда очень сложно сказать мы ещё имеем дело со старым или уже с новым поколением. Вот сейчас такой процесс и происходит с ЯП, появившимися в XXI веке - вроде бы их ещё создавали по лекалам 3-его поколения, но сейчас они уже во всю замахиваются критерии, присущие на 4-ому (хоть и нет даже чётких критериев для описания этого 4-го поколения).
А я вот - уже пытаюсь описывать язык программирования 5-го поколения - причём задаю ему вполне конкретные критерии соответствия. Ну вот такой вот я
пророкфантазёр. Просто у меня есть своё виденье этого, пока ещё не очень близкого будущего (конец XXI), но оно основано на тенденциях настоящего. И в целом, я не думаю, что я предлагаю что-то уж больно трансцендентное - я не прогнозирую инструменты ИИ, которые по взмаху волшебной палочки буду делать всё - хотя нынешнее развитие ChatGPT уже многим вскружило голову, что такое будущее уже не за горами. И я считаю что в той или иной мере всё, что я прогнозирую уже можно было бы разрабатывать прямо сейчас - и где-то к середине века уже предоставить вполне революционную рабочую и достаточно продвинутую для коммерческой эксплуатации версию ЯП 5-го поколения (а до этого представляя постепенно отдельные составные блоки в виде отдельных инструментов и в разной степени развития). Но всё же - именно более-менее продвинутый и в полной мере качественно соответствующий всем критериям (хоть это и большая условность) ЯП 5-го поколения должен появиться где-то к концу XXI века, и вряд ли раньше (а то и в начале XXII века), но может появиться и существенно раньше.Кстати, ранее о компьютерах следующего поколения говорили, что это будут уже квантовые. Но вот квантовые компьютеры придумали уже достаточно давно, но развиваются они пока очень медленно (хотя за последние лет 10 прорыв был очень значимый, но до этого буксовали очень долго, да и сейчас - это пока больше дорогая игрушка). Но квантовые компьютеры не просто сложны в построении и программировании, их очень сложно вывести в сектор массового потребления. Скорее всего они так и останутся - отдельными вспомогательными числодробилками. А основные вычисления пока так и останутся на микропроцессорах - которые перейдут к чиплетам и всё больше и больше вычислений будет уходить в распределённые облачные системы. Которые, видимо, и стоит воспринимать как компьютеры следующего поколения - когда условно рядовые вычисления будут распределяться на тысячи, десятки тысяч, сотни тысяч ядер (или APU или ещё какой термин поточнее возникнет - т.е. не только на ядрах процессора, но и на дополнительных вычислительных юнитах).
К облачной гетерогенной архитектору вычислительных систем мы уже переходим. Вот куда более интересным будет последующее поколение компьютеров - когда-то давно (следующими за квантовыми компьютерами) их называли Телепатические компьютеры - системы, которые работают на опережение, предугадывая то, что от них будут запрашивать пользователи - и сразу выдавать уже готовые результаты. Таким компьютерами понадобятся, вероятно, ещё более продвинутые ЯП уже 6-го поколения, где формирование программы будет идти по такому же принципу - система будет стараться, с близкой к 100% точностью, угадать, какая задача перед ней ставится, как её эффективно выполнить, и наперёд будет предлагать пути решения, с готовыми результатами и всевозможными оценками эффективности. Но это уже совсем другая история... навряд-ли она случится даже в XXII веке, хотя, кто знает....
И 6-е поколение ЯП, скорее всего, станет уже последним (или предпоследним) - далее развивать программирование уже не будет смысла - компьютеры уже всё настолько освоят, что научатся взаимодействовать как с людьми, так и с друг другом, так и с окружающим миров без каких-то человеко-удобных программ. Но это уже прогноз на несколько столетий вперёд - скептический или наоборот недальновидный прогноз - это лишь покажет время....
piratarusso
00.00.0000 00:00+1В python типизация строгая. Другое дело, что она динамическая. Хоть это и интерпретатор. Нестрогая типизация присутствует в С. Который как раз компилятор.
LordDarklight
00.00.0000 00:00Спасибо за поправку, конечно же имел в виду отсутствие в Python именно статической типизации
manyakRus
00.00.0000 00:00нужен новый параметр скорость работы программиста :-)
по этому параметру выйграют:
1. 1С Предприятие
2. Python (подходит только для маленьких скриптов)
3. Golang
У пунктов (1) и (2) есть большие ограничения использования,
поэтому выйграет пункт (3) Golang :-)LordDarklight
00.00.0000 00:00-1Хм... критерий правильный (с уточнением - при требовании к высоконадёжному коду), но на мой ваши примеры всё-таки не очень верны:
1С Предприятие 8 - по большей части это не столько ЯП, сколько фреймворк (такой комплексный - содержащий и среду исполнения к различным платформам). Вот только уж больно ограниченный (по функциональности - уловно с большими трудностями по рашиоению функциональных возможностей и интеграции) - да, ля ряда задач подходит хорошо (особенно базирующихся на кроссплатформенном UI но если не требуются какие-то хитрые изыски и анимация - увы UI тут уже сильно устарел и не расширяется никак, кроме как через переход на JavaScript с полным отказом от внутренней реализации), но наш влево-шаг в право - и будут большие проблемы! А Сам ЯП устарел лет на 10 как минимум (а то и на все 20), современные паттерны и тенденции в разработке к 1С Предприятие почти не применимы - значит его эффективность уже весьма сомнительна. Как и есть проблемы с надёжностью и масштабируемостью. В общем - это своё болото. Как мне кажется - большой выигрышь будет только на малых и средних проектах (и тут всё зависит от того насколько они попадут в прокрустово ложе ограничений). На больших - будет полный аутсайдинг. Про BigData и говорить нечего. Ну и применение 1С Предприятие 8 сопряжено с большими расходами на лицензирование платформы - что перекрывает очень большую сферу возможностей его применения!
Python - очень даже активно применяется далеко не на маленьких скриптах - сейчас ЯП (и его среда исполнения) развился очень сильно, и активно занимает как раз область серьёзного алгоритмического анализа данных. Но тут на руку играет хорошая интеграция с Си библиотеками и хорошие фремйорки. Недотки тут больше в области пользовательского взаимодействия. Тут даже на Бигдата уже давно замахиваются. Но в качестве более широкого прикладного применения Python пока не очень широко развит (хоть и стал самым популярным ЯП) - даже в игрушках, где он ранее практически доминировал, как ЯП внутреннего скриптинга, его сейчас активно повыжимали (тот же ЯП Lua или JavaScrtipt)
Golang - на мой взгляд ну уж больно синтаксически корявый ЯП, опять же с рядом ограниченных возможностей применения. Но это лишь моё личное мнение. Он ещё как-то может конкурировать с JavaScipt (Node.js) и c Java EE - в качестве ЯП для основы микросервисов. Но не более того. И уж тем более сомнительно выглядит скорость разработки на данном ЯП (вне указанного сценария). пользовательский UI Golang - это опять печалька.
В лидерах по скорости разработки пока Python, JavaScript и, наверное Java или C#. Но Kotlin стремится потеснить как-минимум JavaScript и Java. Микросервисы, я бы всё-таки не стал разрабатывать на Golang - а если бы и стал - то только API - далее уже переходил бы к библиотекам на более вразумительных ЯП - лично мне нравится C# и Коtlin, но и Python с его специфическими библиотеками списывать со счетов не стоит. Для критично высокоскоростных вычислений - писать библиотеки на C/C++/Rust ТОЛЬКО по реальной необходимости! Хотя со временем, может и Native Kotlin тут сможет потеснить (хотя вряд ли)
DizzyJump
00.00.0000 00:00+1Интересно, если бы энергоэффективность учитывала количество энергии затраченной мозгом для написания бенчмарков, то как бы выглядели таблицы? А если бы время было бы временем написания всех бенчмарков? Почему в исследовании языков игнорируются значимые для бизнеса свойства технологий? Тайм ту маркет, стоимость рабочей силы, обьем задач которые можно решить на условную 1000$ вложенную в зарплаты?
Edward_Full-Stack
00.00.0000 00:00-1Сделайте пожалуйста пост про новый язык программирования AsmX. Вторая версия в разработке. Хотелось бы услышать, позовите, если будет пост про такое. Исходники: https://github.com/langprogramming-AsmX/AsmX
Документация: https://asmx-m26m.vercel.app/
a-tk
00.00.0000 00:00+1А что мешает Вам сделать такую статью?
Бррр..... какая страшная смесь ассемблера, бейсика и досовской командной строки...
Helltraitor
В случае C, C++ и Rust что сравнивается? Компиляторы?
Я это к тому, что разница должна быть небольшой между ними, поскольку они довольно таки низкоуровневые и если компилировать одним llvm, то результат должен быть +/- одинаковым.
Мое нескромное мнение: языки C и C++ должны быть "убиты". Т.е. заменены там, где это возможно, более подходящими альтренативами. Лично мне кажется, что, по крайней мере, стандарты C++ слишком перегружены. Я вижу, как разработчики языка кайфуют от своего дела, но это очень напоминает швейцарский нож: вроде и все есть, а вот отвертку (или вставить нужное) я лучше отдельную возьму
mpaxepnepe
статя так ржаво жoнглирует кофе и змеем, чтобы не отвечать на вопрос про D kоторый заменяет всё остальное а еschё программирует html
a-tk
D умер под весом эффекта второй системы в исполнении собственного автора.
artemisia_borealis
Насчёт умер, не стал бы утверждать. Да, не на хайапе, но в целом развивается, есть сообщество живое. Состояние — бери и пользуйся. Делал несколько небольших проектов для себя, получил удовольствие. Просто всё шикарно.
Выскажу непопулярное мнение: тот же раст при всех его несомненных концептуальных достоинствах имеет уж больно наркоманский синтаксис. На вкус и цвет..., но видеть это ежедневно перед глазами не очень бы хотелось.
yatanai
Тем не менее на крестах, из-за его гибкости, можно описать абсолютно любое поведение, до самых мелочей. Нужно ли оно в коде? Ну...... А вот при написании всяких библиотек это просто сверх инструмент.
a-tk
Можно, но всегда ли нужно?