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

Для начала тебе нужно рассказать, что такое «пригодно». Вот есть Fortran, по мне так, можно его использовать для всего вообще. ОС на нем писали, обычные программы тоже, скриптовым его сделать не проблема.

Был (есть?) PL/1 https://ru.wikipedia.org/wiki/ПЛ/1

Можно, конечно. Только не нужно.

Например, в языке может присутствовать как статическая, так и динамическая типизация.

А зависимые типы будут?

Конечно можно. По сути примерно такой язык давно есть и вполне популярен — это С++. На нем можно писать всё. И пишут.

А там есть сборка мусора? А динамические типы?

Нет. Сборку мусора прикрутить можно, но не нужно. Это все необязательно.

Ну вот поэтому и появляются другие языки.

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

Кстати и такой язык есть. Это C#. Низкоуровневый код на нём обычно не пишут. Но в теории, наверное, упороться можно.

Можно, свифт в Эппле является языком «для всего», и на нём, собственно, и делают всё.

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

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

Они разве ушли с ObjC?

В целом язык такой есть - C. Не такой высокоуровневый, но на нём делается всё

Уже сделали. Подскажу: в его названии всего четыре буквы, начинается на букву Л, вторая буква И.

Можно ли… для всего?

Эта ересь возбраняется кучей трудносовместимых парадигм программирования ©.
Но, если очень хочется, то как моделька «для всего», глянь Forth ©.

Уже сделали. Подскажу: в его названии всего четыре буквы, начинается на букву Л, вторая буква И.

Литр? Ну да, с литром можно что угодно напрограммировать.

Они разве ушли с ObjC?

Уже лет десять назад переход начался.

По сути, эффект тот же, как если переходить на Rut: с небезопасного языка в безопасный. Они планомерно сделали новые фреймворки, перелопатили гуйный софт. Было бы интересно и ведро увидеть на нём, но боюсь не осилят.

Сишечка уже придумана.

Создать можно что угодно, и оно даже будет работать у тебя.

надо писать биндинги

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

Ведь биндить тебе придется не просто функцию, а все пространство по сути.

На практике получится, просто будет нецелесообразно. К тому моменту когда ты закончишь свой язык и биндинг популярных и нужных библиотек (даже банальные glib \ xlib) - у тебя получится просто очередной Vala, т.е. транслятор твоей лапши в С-лапшу.

Нет, я имею в виду, если бы и все библиотеки были написаны на этом языке.

Этот язык JavaScript.

Еще не дошел до логического завершения своей эволюции, но постепенно идёт.

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

А вот еще интересная идея для рассмотрения, мог бы быть заменой JavaScript в параллельной вселенной: https://en.wikipedia.org/wiki/Pike_(programming_language)

Нет, я имею в виду, если бы и все библиотеки были написаны на этом языке.

Это даже теоретически сложно допустить.

Библиотека для технологии как правило пишется на том же языке, что и сама технология, это вполне логично.

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

Это даже теоретически сложно допустить.

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

Вот хороший кандидат на два в одном: https://www.red-lang.org/p/about.html

Вот хороший кандидат на два в одном: https://www.red-lang.org/p/about.html

С опаской отношусь к нитакусикам, а синтаксис этой штуки именно такой без видимых на то причин.

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

Можно ли сделать один молоток для всего?

Попроси чатжпт написать тебе такой язык и пример программы :)

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

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

Тут всё дело в определении слова «пригоден». Универсальность — это всегда некоторый компромисс. И заточенность под определённые задач — тоже компромисс, но в другую сторону.

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

Чисто в теории можно ли создать язык программирования, который будет пригоден и для низкоуровневой работы (вместо языка C, например, для разработки ядра), и для написания прикладного ПО и скриптов?

Чисто в теории можно ли объединить ванну с унитазом? Чисто в теории - наверное, да.

Если мы хотим использовать какую-то библиотеку, для неё надо писать биндинги для того языка программирования, откуда хотим её дёргать.

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

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

Почему гипотетического? D давно придумали.

Это естественный язык. Все ораторы выше глубоко больны какой-то компьютерной болезнью из разряда технорелигий.

QVariant - это калька с Variant от мистера Стива Балмера. COM, DCOM - это наше всё, да. Кормильцы милые. Трансцендентные практики - они когда-то были легальными, да. Да и сейчас, при желании...

Мы уже получили питон. Хватит.

А вот прорядить весь этот зоопарк технологий/яп не то что можно, а нужно!

А там есть сборка мусора? А динамические типы?

Есть умные указатели, это и есть один из основных элементов сборки мусора, другой элемент это принцип RAII, он тоже есть в С++.

Динамические типы – есть auto, есть шаблоны, есть приведение типов, так что да, можно сказать, что есть.

Динамические типы – есть auto, есть шаблоны, есть приведение типов, так что да, можно сказать, что есть.

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

Динамическая типизация это в частности, когда мы можем не указывать тип данных явно – это auto.

Приведение типов это изменение типа переменной, оно бывает и неявным. Это как раз и есть изменение типа, а вот когда a=3.14159265, а потом a=«фывафывп» это не изменение типа, а изменение переменной, т.к. типы не согласованы друг с другом, это совсем другой объект, согласись, это сильно отличается от ситуации, когда, например, объект приводится к типу родителя…

Но в целом это все софистика, без конкретных кейсов вся дискуссия лишена смысла.

Да много чего можно, даже из того что есть повыбирать можно. Мешает психология, по сути. Куча откровенно каловых ЯП держатся на:
- легаси
- «батарейках»
- единичных выстреливших проектах

Нафейспальмили то. :)

А с т.з. пользователя именно отсутствие указания типа это динамическая типизация, так это видит обычный программист далекий от CS. И ему до лампочки то, что динамической типизацией называется связывание типа с переменной в момент присваивания значения, он хочет писать a=3.141592, а потом писать a=«asdfasdf» или a="pi = "+a, и не думать обо всех этих типах, их согласовании и пр., ему нужно отсутствие типизации.

Комикс про 14 конкурирующих стандартов.jpg

Зачем это нужно? Все что ты перечислил, можно писать без этого.

Динамическая типизация это в частности, когда мы можем не указывать тип данных явно – это auto.

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

auto a = 5;
a = "hello";

#include <type_traits>

template <typename A, typename B>
void test(A a, B b) {
    auto x = a + b;
    static_assert(std::is_same<decltype(x), int>::value);
}

void test2() {
    test(5, 5); // ok
    
    test(5, 5.5); // fail
}

Определение из википедии: «переменная связывается с типом в момент присваивания значения ... в различных участках программы одна и та же переменная может принимать значения разных типов»

Более лучшим примером, мог бы быть std::variant.

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

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

С т.з. формального определения, конечно, в С++ динамической типизации нет.

auto иногда это конкретный тип выведенный из правой части выражения, а иногда это просто короткая запись шаблона:

int test(auto msg) 
{
    return msg.test();
}

static_assert(std::is_same()) тут тоже будет работать, так что тип на каждую вариацию auto будет известен в момент компиляции. Dynamic для меня, сигнализирует о том, что должны быть возможны случаи, когда на момент компиляции будет совершенно неизвестно чем будет auto.

Например что бы был: std::vector<auto> any_values; и потом можно было бы его пропустить через test(auto a);

Сборка мусора: https://github.com/ivmai/bdwgc

Динамические типы: https://en.cppreference.com/w/cpp/utility/any

Вопрос какой ценой.

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

virtual дает связывание в процессе работы программы.

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

А с т.з. пользователя именно отсутствие указания типа это динамическая типизация

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

a = read_from_file(file); // String
b = a + 10; // Int
c = b + 3.14; // Real
print("File: ".a.", and result value: ".c."\n"); // Concat всего в строку

При этом программа не должна засегфолтиться, если a вдруг будет «Вася». Максимум насрать в warning, а то и просто проигнорить и считать такую a равной 0, ведь нормальная адекватная макака перед важной математической операцией с переменной проверит ее тип, типа if (is_int(a)) {b = a + 10}, если это важно.

PHP кстати в этом плане здорово упрощает человеческую жизнь, иначе бы половина кода наверное состояла из atoi() и itoa().

который будет пригоден и для

Придумали один раз инженеры такой аппарат, который и карандаши точит и х.. дрочит

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

Ахахаха.

Да любой вывод на экран или запись в файл числовой переменной - это уже произвольное изменение типа.

Равно как и чтение из файла числового значения как строки с последующими операциями над значением как над числом. Ну например использование конфигурационных файлов.