Какой язык короче?

Нормальные люди пишут код не для компилятора, а для других людей. Краткость ЯП и компактность кода зачастую противоположна гибкости и понятности. Объясню цитатой из статьи а-ля java vs python

В начале карьеры кажется: меньше кода — лучше. Потом появляется команда 20–50 человек. Потом сотни тысяч строк. Потом дежурства. Потом звонок в 3 ночи с вопросом «почему упал прод». И внезапно оказывается, что скучные вещи обладают сверхспособностями: строгая типизация, безопасный рефакторинг, явное объявление вместо неявного, статический анализ, compile-time проверки. Вещи, которые в маленьком проекте кажутся бюрократией, в большом экономят часы отладки и нервы дежурного инженера. В этот момент начинаешь понимать странное поведение Java-разработчиков. Они не любят типизацию. Они любят спать.

Любой специализированный DSL под задачу, короче любого общего языка под эту же задачу.
Так что всё сведётся к тому, в какой задаче самый короткий DSL :) Тот собственно и будет короче.

А так, вся краткость заключается в том что вермишель километровых кишков просто за интерфейсом (им же может быть сам синтаксис), то же перемножение матриц в виде а * b внутри хтонь, просто её не видно, плюс хтонь чтобы было невидно.
И тут уже всё сведётся к тому в каких языках можно переопределять односимвольные операторы, плюсы, луа, лиспы, чтобы они делали что-то другое с сложносоставными типами. В этом плане, вот все эти языки и будут короче, хотя если очень постораться сокрощать на выходе опять DSL из целиком переопределённого языка под задачу =)

Подобные вопросы занимали ещё Колмогорова - https://ru.wikipedia.org/wiki/Колмогоровская_сложность

Не нужны никакие DSL-ы. Сокращение кода реализуется декомпозицией. Как в бейсике из 70-х. Ничего нового не придумали. Просто объёмный кусок кода выносится в функцию и в исходном месте заменяется одной строчкой - вызовом функции, вот и всё.

Кто-нибудь пытался анализировать статистику?

Да, пытаются: https://langscompare.site.

Другие языки сами смотрите. :)

Ну так я про то и говорю (кишки внутри наружу интерфейс), но ТС хочет ещё короче. Чтобы не c = mulmat4(a,b), а типа c = a * b второе короче. Вот и всё. Конечно есть ещё варианты, необязательность скобок при вызове функции и сокращение её названия типа c = m4 a b так можно много играться.

А так, значимую если не больщую часть кода занимают осмысленные наименования, делать их сверх короткими, ну разве что как препроцесс перед компилятором, если ему туго с этим. Ну и стремление всё сокращать, а значит впихивать больше семантики на единицу синтаксиса, рождает такие ужастики как сложные шаблоны плюсов и растоманские портянки аля PERLовка :D Иногда это полезно, прикольно, удобно, но всегда можно довести то лаконичного и выразительного хтонически нечитаемого ужаса.

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

C++
Ecosystem
10/10

странно

Чтобы не c = mulmat4(a,b), а типа c = a * b второе короче

Это просто перегрузка оператора и во многих языках доступна из коробки. По сути альтернативная запись вызова функции, это не что-то сверхъестественное.

DSL в моём понимании это реализация своего языка программирования. Со своим синтаксисом, лексикой, со своим компилятором или транспилятором или ещё чем-то. Вот это вот лишнее почти всегда, на мой взгляд.

Сам в шоке! :)

сверхспособностями: строгая типизация, безопасный рефакторинг, явное объявление вместо неявного, статический анализ, compile-time проверки.

Начал за здравие...

Java

...кончил за упокой.

«Горшочек, НЕ ВАРИ!»

Английский. Это баянистый баян

При анализе Второй мировой войны американские военные историки обнаружили очень интересный факт. А именно, при внезапном столкновении с силами японцев американцы, как правило, гораздо быстрее принимали решения — и, как следствие, побеждали даже превосходящие силы противника. Исследовав данную закономерность, учёные пришли к выводу, что средняя длина слова у американцев составляет 5.2 символа, тогда как у японцев 10.8. Следовательно, на отдачу приказов уходит на 56% меньше времени, что в коротком бою играет немаловажную роль. Ради «интереса» они проанализировали русскую речь — и оказалось, что длина слова в русском языке составляет 7.2 символа на слово (в среднем), однако при критических ситуациях русскоязычный командный состав переходит на ненормативную лексику — и длина слова сокращается до (!) 3.2 символов в слове. Это связано с тем, что некоторые словосочетания и даже фразы заменяются одним словом. Для примера приводится фраза:32-ой — приказываю немедленно уничтожить вражеский танк, ведущий огонь по нашим позициям — 32-ой — ё#ни по этому х&ю!

Очевидно - апл.

Life ← {n←(1⌽𝕩)+(¯1⌽𝕩)+(1⌽˘𝕩)+(¯1⌽˘𝕩)+(¯1⌽¯1⌽˘𝕩)+(¯1⌽1⌽˘𝕩)+(1⌽¯1⌽˘𝕩)+(1⌽1⌽˘𝕩)⋄(n=3)∨𝕩∧n=2}

Компактность, наглядность, простота. Пойду перепишу ядро на нем.

Довольна древняя и ошибочная клюква. Все языки примерно равны по длине. Можешь книги посмотреть, переведенные на разные языки, сравнить объем.

А разговорная речь у всех короче.

Довольна древняя и ошибочная клюква. Все языки примерно равны по длине. Можешь книги посмотреть, переведенные на разные языки, сравнить объем.

Во всяком случае, русские книги длиннее английских. За японский язык не скажу.

Короче – Ку!
Остальные – Кю!

Будто в питоне можно сунуть строку в число.

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

апл.

Life ← {n←(1⌽𝕩)+(¯1⌽𝕩)+(1⌽˘𝕩)+(¯1⌽˘𝕩)+(¯1⌽¯1⌽˘𝕩)+(¯1⌽1⌽˘𝕩)+(1⌽¯1⌽˘𝕩)+(1⌽1⌽˘𝕩)⋄(n=3)∨𝕩∧n=2}

Гугло-ИИ говорит, что это его потомок — BQN.

Компактность, наглядность, простота.

Ну да. Вопрос только, сколько к этому привыкать.

Пойду перепишу ядро на нем.

Как на нём сделать GUI? Как работать с бинарными файлами? Есть ли библиотеки для обработки изображений?

И как настраивать клавиатуру? :)

Будто в питоне можно сунуть строку в число.

Запросто. Или проверяй входящие данные и результаты функций, или лови TypeError.

C++ Ecosystem 10/10

странно

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

больщую часть кода занимают осмысленные наименования,

У меня как-то складывается впечатление, что большую часть кода занимают цепочки объектов :) Это зависит от API. Вопрос: какой API проектировался с целью сокращать такие цепочки?

впихивать больше семантики на единицу синтаксиса … полезно, прикольно, удобно, но всегда можно довести то лаконичного и выразительного хтонически нечитаемого ужаса.

Значит нужен компромисс. Кто-нибудь его нашёл? Или вывел критерии, как его искать? (Примеры — «не более 4 уровней отступа» или «функция на 1 экран».)

Краткость ЯП и компактность кода зачастую противоположна гибкости и понятности.

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

https://langscompare.site/

Спасибо.

Чёрный текст на тёмно-синем или тёмно-коричневом фоне. Извращенцы.

И непонятно, как измеряли. Не очень верится в «days to get ‘Hello World’ running correctly» для C++.

https://ru.wikipedia.org/wiki/Колмогоровская_сложность

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

Ой, все…

русские книги длиннее английских.

Boromir smiled

И непонятно, как измеряли.

Можно и самостоятельно, «на глазок»: https://rosettacode.org/wiki/Category:Programming_Tasks. :)

Можешь книги посмотреть, переведенные на разные языки, сравнить объем.

Занимался переводом. Русские параллельные тексты примерно на треть длиннее. Даже если активно выбрасывать слова (не «он кивнул своей головой», а «он кивнул» или даже только «кивнул»).

Я уже не раз и не два замечал, что все самое интересное англоязычное внезапно обретает интересность только в переводе. Что в сериалах, что в играх.

Английский вариант что то вроде: «Town from a box». Переведенный: «Городок из табакерки».

Английский: «Quick sand». Переведенный: «Зыбучие пески».

Начинаешь читать оригинал и все те отсылки, которые ты замечал внезапно.. их нет. Но надеюсь там хотя бы свои есть отсылки, которых я просто не понимаю. Иначе все совсем печально.

Boromir smiled

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

А про Воннегута американцы говорят «хреновый писатель, но ему везло с переводчиками».

Можно и самостоятельно, «на глазок»: https://rosettacode.org/wiki/Category:Programming_Tasks. :)

Очень субъективно. А хочется чтобы сами авторы сформулировали, что стоит за этими числами.

Сайт сломан. Matchups возвращают Access Denied.

Русские параллельные тексты примерно на треть длиннее

Потому что параллельные. Если ту же идею изначально излагать по-русски, то будет не длиннее.

И наоборот. В Войне и мире 466к слов. В английских переводах 550-580к слов.

Короче - это про однобуквенные переменные и форматирование всей программы в одну строку?

Нет, это про синтаксис языков. Из нормальных языков тут лидер - питон. Это с учетом полных переменных и нормальным форматированием. Просто в нем и так довольно лаконичный синтаксис, но еще и куча синтаксического сахара.

Питон - это лидер по ненужности. Может тогда Хаскелль. Там есть и вывод типов и всякие закорючки >>=, <$>

Короче - это про однобуквенные переменные и форматирование всей программы в одну строку?

Какой-то язык позволяет сделать такую программу читаемой?

Сам топи урановые ломы в ртути пиши на хаскеле…

У меня давно есть идея языка strycthon. Это петон, но когда интерпретатор сначала прогоняет mypy или другой чекер и если тест не прошёл то программа падает сразу. Ибо нехрен

Регулярные выражения, наверное

Ну и стремление всё сокращать, а значит впихивать больше семантики на единицу синтаксиса, рождает такие ужастики как сложные шаблоны плюсов и растоманские портянки аля PERLовка :D

Внезапно, есть такая буква в этом слове :)

Давно (лет 5-10) назад читал статью, там ребята оценивали стоимость владения кода и по итогу получилось, что если не брать матёрые DSL и эзотерические языки с функциональщиной, то из популярных в числе первых был Perl.

Да, если постараться то он будет как биток, ты не пишешь код, а хешируешь предыдущий так что в сумме это монолитный моноблококод, ценность которого пропорциональна геометрической сложности его переписать :D при попытке спуститься вниз по вызовам и разбору логике чётутпроисходит едрить его!

Так что его только дописывают всё более усложняя и повышая цену!1!! :D

В PHP вообще всё можно. На нем, как говоришь, так и пишешь. Там всякие array_reverse, array_search, explode, implode. Но так написать можно, что будет работать только на твоем компьютере, только на одном веб-сервере, до первых обновлений.

Но все равно возможности для самореализации и прототипирования безграничны.

А «переменные переменных» - целая эпопея, видимо, вдохновлённая bash/shell.

В PHP вообще всё можно.

Ага, автоматическое приведение типов настолько продвинутое, что считается уязвимостью :) https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Type%20Juggling/README.md#true-statements

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

Если под читаемостью подразумевается читаемость нейросетью, то зачем ей лишние пробелы? Они наверняка забирают себе часть внимания.

F#

C PHP можно «вынести моск» относительно безобидной конструкцией:

$c=array('a','d','f');
$x=array('a','b','c');
echo ${$x[count($x)-1]}[count($x)-2];

Bash по этой части круче, но в bash нет ООП.

читаемость по каким-нибудь объективным критериям

читаемость, писаемость… починяемость!

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