Когда смотришь на дизайн синтаксиса того или иного языка программирования невольно задумываешься, почему сделано так, а не иначе. Тут я обозреваю лишь некоторые идеи стоящие за этим: "программисту нельзя доверять", "язык должен быть удобен для пользователя", "каким качеством должен обладать язык программирования, чтобы заменить другой?".
Программисту нельзя доверять
Все начиналось с С, сего девизом: «Доверяй программисту», на данный момент всем понятно, что это было ошибкой. Диапазон решений, сильно отличаются, от Rust, на котором не просто довести программу до компилябельного состояния, до Python. Если посмотреть глобально, то со времен ассемблера, со временем у программиста все более и более уменьшается множество возможных программ(сначала у нас отобрали регистры, потом goto, потом самостоятельное управление памятью), которые он может написать, и это хорошо, потому что ограничения по большей части уменьшают возможность написания плохих программ.
Может показаться, что чем больше язык дает возможностей, тем он лучше, но это не так, на самом деле чем меньше в языке возможностей, тем лучше. Как правила, ограничения делают нас сильнее, например запреты на убийство и употребление наркотиков сделало все человечество сильнее.
Эта тенденция продолжится и дальше, а новый язык программирования будет изобретен в тот момент, когда определят, что же еще мешает программистам писать бизнес логику.
Язык должен быть удобен для пользователя
Достаточно простая идея, но раскрывающаяся по-разному.
Чем меньше нажатий клавиш - тем лучше
Время программистов стоит денег(видимо это знали всегда, поэтому begin/end из Паскаля совершенно не прижились, а С получил сильный буст из-за своей синтаксической простоты). Пожалуй, максимально это понимали при дизайне Go, поэтому имеем
type Some int /*вместо*/ type Some = int;
i := 0 /*вместо*/ var i = 0;
import f "fmt" /*вместо*/ import "fmt" as f
for i := 0; i < 10; i++ /*вместо*/ for (i := 0; i < 10; i++)
func f(in int) int /*вместо*/ func f(in: int) -> intВсе больше встроенных функций и классов
При дизайне С++, Страуструп считал, что пользовательские типы, должны быть также удобны как встроенные в язык. Поэтому в C++ можно переопределить operator[] и operator, . Но я считаю, что Страуструп ошибался и между пользовательскими типами и встроенными целая пропасть. И если посмотреть на развитие языков, то все больше и больше в них встроенных функций и классов. В Swift встроен optional(значение, которого может не быть)
func convertToInt(_ str: String) -> Int? {
return Int(str) // Преобразует строку в Int, но может вернуть nil
}
let optionalNumber: Int? = convertToInt("42") // Опциональное значение
// Безопасное извлечение через optional binding
if let unwrappedNumber = optionalNumber {
print("Извлечённое значение: \(unwrappedNumber)")
} else {
print("Значение отсутствует (nil)")
}
// Принудительное извлечение (!), если точно уверены, что значение не nil
if optionalNumber != nil {
let forcedUnwrappedNumber: Int = optionalNumber!
print("Принудительно извлечённое значение: \(forcedUnwrappedNumber)")
}в go chan(по сути многопоточная очередь)
func worker(ch chan string) {
time.Sleep(2 * time.Second) // Имитация работы
ch <- "Работа завершена!" // Отправка данных в канал
}
func main() {
ch := make(chan string) // Создаём канал для передачи строк
go worker(ch) // Запускаем горутину
fmt.Println("Ожидание результата...")
result := <-ch // Блокирующее чтение из канала
fmt.Println(result)
}Синтаксический сахар важен
Когда-то давно было предложение о том, чтобы добавить в C++ именованные параметры.
func(first: 0, second: 1);Но их не добавили, аргументирую это тем, что это и так можно реализовать, например через дополнительные методы у классов и все работает без этого, но они ошиблись, синтаксический сахар очень важен, важно чтобы людям было легко и удобно писать хороший код. Или например лямбды — чистой воды синтаксический сахар, но как же кстати он бывает.
const auto it = std::find(vec.begin(), vec.end(), [](auto el) { return el > 0; });Мета наблюдения
Развитие языка программирования предопределено его философией(и людьми, которым эта философия важна)
Идеи захватывают сознание людей. Поэтому никто не делает бенчмарки C++ против Go, но C++ против Rust - очень много(потому что производительность для Go лишь одна из важных идей, а для C++ и Rust - все).
В C++ всегда самой важной идеей было "абстракция с нулевой стоимостью", чтобы нельзя было переписать программу на C, чтобы она работала быстрее. И по итогу мы видим бесконечно компилирующиеся шаблоны, крайне ограниченная стандартная библиотека, отсутствие пакетного менеджера(ибо на скорость не влияет), да и в целом очень сложный язык с множеством тонкостей. По другую сторону баррикад Go lang, для создателей которого важнее были простота и скорость компиляции(что для бизнеса зачастую куда важнее).
Каким качеством должен обладать язык программирования, чтобы заменить другой?
Не хочется попадать в ошибку выжившего с утверждением, что простота и синтаксический сахар делает языки востребованными, на самом деле нет, только принципиальное отличие языка даёт ему возможность на жизнь.
Действительно, в какой момент новый язык программирования может заменить предыдущий? Как метко подметил Страуструп в "Дизайн и эволюция С++", только в случае больших отличий, новый язык может потеснить старый. И если держать это в голове, то многое становится понятным.
Почему D не заменил C++? Потому что он лишь немного лучше С++, но это улучшение несравнимо с затратами бизнеса и отдельных людей для освоения нового языка. И с другой стороны Java сильно отличается от C++ своим ООП и сборкой мусора. Go отличается от Java ориентацией на разработку серверного ПО, простотой, встроенными корутинами и другим, Rust обеспечивает качественно иной уровень безопасности при разработке, и обещает быть столь быстрым как С++, а Python просто интерпретируемый.
Заключение
Если вам доведется дизайнить новый язык программирования, то позаботьтесь, чтобы
его было трудно использовать неправильно
-
язык был удобным для пользователя
нажатий клавишь меньше
встроенных типов больше (но пользовательские типы не должны быть такими же удобными)
синтаксического сахара больше
образовалось комьюнити, которое будет поддерживать проект
Но ничего из вышеперечисленного не имеет смысла, если ваш язык будет просто немного лучше других, чтобы стать успешным, язык должен быть намного лучше аналогов.
feel free to comment
Комментарии (19)
Lewigh
10.02.2025 17:35Может показаться, что чем больше язык дает возможностей, тем он лучше, но это не так, на самом деле чем меньше в языке возможностей, тем лучше. Как правила, ограничения делают нас сильнее, например запреты на убийство и употребление наркотиков сделало все человечество сильнее.
А запреты на продажу алкоголя породило всплеск роста организованной преступности которые заработали на этом целые состояния. Жил бы язык Java который по идее должен был быть простым языком поэтому был топорным и без излишеств. Но программистом это не пришлось по душе и они обмазали все плагинами с когенерацией и куче рефлексией, что сделало работу с Java на некоторых проектах сходной с работой на JS по предсказуемости.
Время программистов стоит денег(видимо это знали всегда, поэтому begin/end из Паскаля совершенно не прижились, а С получил сильный буст из-за своей синтаксической простоты).
Ну да. Программисты это - это стенографисты, они только непрерывно печатают код и написание лишнего символа стоит денег заказчику. C победил паскаль за счет того что продал свою производительность а не за счет какой-то синтаксической простоты.
Пожалуй, максимально это понимали при дизайне Go, поэтому имеем
А где пример вида?
data, err:= fu() if err!= nil { log.Fatal(err) } /*вместо*/ var data = fu()никто не делает бенчмарки C++ против Go
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-gpp.html
По другую сторону баррикад Go lang, для создателей которого важнее были простота и скорость компиляции(что для бизнеса зачастую куда важнее).
Если бы бизнесу была важна простота и скорость компиляции то он бы везде использовал Python. А вот Go как раз взлетел как раз из-за того что бизнесу внезапно понадобилась еще и производительность.
vadimr
10.02.2025 17:35Си победил Паскаль из-за случайного совпадения, что Windows была написана на Си (хотя классическая Mac OS – на Паскале), а недосягаемо лучший компилятор Паскаля выпускал конкурент Microsoft.
Если бы Фил Кан пошёл работать в Microsoft, а не основал Borland, то сейчас бы о языке Си почти никто не вспоминал.
(Ну, отчасти ещё и Unix сыграл, конечно).
А так это два примерно одинаковых языка.
eimrine
10.02.2025 17:35хотя классическая Mac OS – на Паскале
Там же был момент когда оказалось, что сишные строки настолько удобнее что их начали использовать в некоторых апи при том что остальная часть системы продолжала использовать паскалевские соглашения.
недосягаемо лучший компилятор Паскаля выпускал конкурент Microsoft.
Трубопаскаль это не компилятор, а IDE. Его хорошесть заключалась в том что из коробки есть и компилятор, и документация, и текстовый редактор - всё что надо в эпоху до Интернетов чтобы просто сесть и начать работать. Я скорее поверю что случайность - мир пошёдший по пути "высокоуровнёвого ассемблера" C вместо пути Lisp-машин без compile time и по пути неэффективного универсального языка описания структур json вместо эффективного лисповского. Для кросплатформенного жонглирования битами, вроде возможности запустить одну и ту же программу, допустим, на Big-Endian и Little-Endian, у Паскаля нет выразительных средств. И ЯП разрабатываемый по принципу Собор, а не Базар, вряд ли годится на роль "нашего всего".
dustdevil
10.02.2025 17:35Турбопаскаль это и IDE и компилятор. При этом и то, и другое отличалось немного от Borland Pascal, который был дороже, и выходил за стандарты языка Pascal. Другое дело, что как и с C++, компилятор далеко не лучший. А убили его появление Delphi с его Object Pascal и отказ Borland от дальнейшей поддержки турбика, что эволюционно не верное решение.
PS: а еще Turbo Pascal был лучшим, для программирования... на ассемблере под х86 )))
vadimr
10.02.2025 17:35К тому времени, когда разворачивалась основная конкуренция Си и Паскаля, Паскаль уже весьма далеко отошёл от Вирта и его собора. Радикально он был развит в UCSD и затем в Borland. Собственно, и строк в Паскале в обычном понимании до UCSD не было никаких.
Дело в Турбо Паскале было не только в самом по себе комплекте IDE, поскольку Microsoft выпускала номинально аналогичный ему продукт Quick Pascal. Но силы были не равны.
Что касается Лиспа, то он не приобрёл широкого распространения, в основном, по двум причинам. Во-первых, в 20 веке программы на Лиспе выполнялись медленно из-за очень маленького доступного объёма памяти и постоянной работы сборщика мусора в связи с этим. Во-вторых, Лисп сам по себе – очень семантически насыщенный язык, плотность семантики на единицу текста в нём огромна, что вообще характерно для функциональных языков. На тех же двух страницах кода, на которых программист C++ совершит какое-нибудь элементарное действие вроде создания и инициализации класса, на Лиспе пишется интерпретатор Лиспа. Далеко не все программисты готовы к такой интенсивной работе ума.
tolyanski
10.02.2025 17:35Вообще меня начинает несколько подбешивать мантра, звучащая от каждого попугая, что якобы "Go это простота! Простота это прекрасно!"
easimonenko
10.02.2025 17:35Факторов, влияющих на рост популярности одних языков, и падение других, гораздо больше, чем выделено в статье. Огромную роль играют компании, делающие выбор языка и пропагандирующие и вкладывающиеся в его развитие (Pascal vs C++ и Java). Сообщества свободно-распространяющихся инструментов и компиляторов: чем оно больше, тем лучше (C vs Pascal и Rust). Подогреваемый компаниями и блогерами интерес к определённым подходам, реализованным в конкретном языке (Node.js vs PHP, Perl, Ruby). Развитие компьютерных технологий, эпоха Интернета, приводят к тому, что взлетают те языки, которые больше подходят под новые приложения (Perl vs PHP).
Есть масса, концептуально интересных и сильно отличающихся от мэйнстримных языков (Haskell, Lisp, Idris, Self, Io, Prolog), но они не смогли тех заменить. Почему? Смотри выше.
Наконец, есть нишевые языки, такие как Erlang, 1C, Shell, которые никто просто так, в здравом уме не побежит заменять на что-то другое, более модное. Да, мода тоже имеет значение...
TarakanoLov Автор
10.02.2025 17:35>> Факторов, влияющих на рост популярности одних языков
я не говорил, что это исчерпывающий обзор факторов, скорее только те, что показались мне интересными
>> Огромную роль играют компании, делающие выбор языка и пропагандирующие и вкладывающиеся в его развитие (Pascal vs C++ и Java). Сообщества свободно-распространяющихся инструментов и компиляторов: чем оно больше, тем лучше (C vs Pascal и Rust). Подогреваемый компаниями и блогерами интерес к определённым подходам, реализованным в конкретном языке (Node.js vs PHP, Perl, Ruby). Развитие компьютерных технологий, эпоха Интернета, приводят к тому, что взлетают те языки, которые больше подходят под новые приложения (Perl vs PHP).
согласен
tolyanski
10.02.2025 17:35for i := 0; i < 10; i++ /*вместо*/ for (i := 0; i < 10; i++)Вот это для меня самая раздражающая тема в Go. Когда привык писать if без скобок, а потом пишешь что-то на другом языке, машинально забываешь скобки и "ой бл забыл"
SanchoB
10.02.2025 17:35"begin/end" и сколько времени он украл бы у программиста? А как насчет java? Его тоже как то характеризует слишком многословным. На самом деле все кроется в факте. Знает программист то язык или нет, и сколько времени надо будет что бы переучится
TarakanoLov Автор
10.02.2025 17:35Ну украл бы некоторое не нулевое время. У java есть много других приемуществ, {} строго лучше чем begin/end, но это не означает, что любой лаконичный язык сразу станет супер популярным
re0ah
10.02.2025 17:35Имхо, беда begin end не в многословности, а что они сливаются с окружающим кодом. Глаз не цепляется. Я наоборот многословность считаю плюсом. Но с begin end пример плохой. Это не многословность. Многословность это когда тебе надо точно писать: struct StructName. Когда надо определять каждый пользовательский тип, и делать это в отдельном блоке. И тд.
HemulGM
10.02.2025 17:35
{} - сливаются куда больше, особенно, когда их много. Подсчитать их кол-во, без вспомогательных инструментов не простая задача
HemulGM
10.02.2025 17:35Нисколько это не тратит времени. Достаточно нажать две первые буквы и уже можешь нажать Enter для автоматической вставки begin и end.
Kelbon
10.02.2025 17:35на самом деле чем меньше в языке возможностей, тем лучше
значит самый лучший язык тот, на котором невозможно написать ничего. Что ж...
TarakanoLov Автор
10.02.2025 17:35было бы душно везде в тексте добавлять "в разумных приделах" или "самое главное это баланс между X и Y", поэтому я более категорично писал
kovserg
Так и где закономерности-то?
Например: "Каким качеством должен обладать язык программирования, чтобы заменить другой" - наличие усов у создателей языка :)
"Язык должен быть удобен для пользователя" -> php всё необходимое есть из коробки
"Программисту нельзя доверять" -> вообще-то смысл немного другой низкоквалифицированным специалистам доверять опасно. Поэтому надо сделать больше проверок богу проверок, зато за счет дармовой вычислительной мощности можно использовать дешевую рабочую силу. Поэтому Go, C#, TS, Dart. А сейчас вообще llm любыми способами пытаются впарить.
"Чем меньше нажатий клавиш - тем лучше" -> APL
Почему D не заменил C++ потому что очень дорого. И да Rust это для мазохистов. Есть более достойные кандидаты например zig, nim, crystal.
TarakanoLov Автор
Я предпологал, что закономерность в том, что вот как-то было в старом C++, а в новых языках делается уже подругому, но все равно соглашусь что название не соответствует, поэтому переименовал в "Идеи стоящие за дизайном языков программирования".
>> "Язык должен быть удобен для пользователя" -> php всё необходимое есть из коробки
Ну я не говорил, что эти идеи являются необходимыми или тем более достаточными, для того, чтобы язык стал мейнстримным, я скорее хотел указать на закономерности, что вот так вот лучше чем вот так вот.
>>Почему D не заменил C++ потому что очень дорого.
Это не только очень дорого(но и это тоже), тут также важно, что импакт(польза) от этого не будет перевешивать стоимость перехода на D(ну получается, действительно, очень дорого, на кажется это не противоречит тому, что я говорил)