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

Давайте, все-же, возьмем реально существующие ЯП.

Вот те же begin|end супротив {} — второе, очевидно, компактнее — и меньше писать и ясность мысли не теряется — и дураку понятно. Можно сказать что отступы еще яснее, вообще не нужны {} — ну пусть, не так важно.

Далее. Определение и вызов функций.

Вот взять Haskell — в этом отношении ничего лучше не придумать.

fun1 x = x + 1

-- вызов
let result = fun1 1 -- вернет 2

Компактнее придумать сложно. И хитрость там в том, что любая функция принимает 1 аргумент и возвращает 1 аргумент (хотя выглядит так, как будто передается 2 аргумента — просто второй аргумент передается в функцию, которую вернула предыдущая функция). При желании можно уточнить данные.

Т.е. ни скобок — никакой лишней мишуры.

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

Давайте мысли по теме.

Здравствуйте, Shmj, Вы писали:

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

APL же. https://en.wikipedia.org/wiki/APL_(programming_language)

Считает все простые числа от 1 до R. Не спрашивай меня, как

(~R∊R∘.×R)/R←1↓⍳R

S>Вот те же begin|end супротив {} — второе, очевидно, компактнее — и меньше писать и ясность мысли не теряется — и дураку понятно.

Ха, попробуй это доказать фанатикам форматирования кода. Тем, у которых "{ и } должны каждый занимать по отдельной строчке, и ни в коем случае не на одной строке с if".

Здравствуйте, Shmj, Вы писали:

S>Давайте мысли по теме.
Своих нет?
forth, lisp

Здравствуйте, Shmj, Вы писали:

S>Давайте мысли по теме.
Предлагаю следующее: термин "максимальная компактность в ЯП" заменяем более простымм "максимальная компактность в записи чисел". Смотрим, что мы можем достичь, потом думаем, оно нам надо для ЯП?
Уточню, что под максимаьным элементом в ЧУМ называется такой, для которого не существует элемента, большего, чем данный.
Таким образом, легко показать, что максимальной компактности в записи чисел не существует. Даже для позиционных систем записи нет границы компактности, если взять за предпосылку утверждение, что x16 компактнее x10, и x32 компактнее x16. Однако, в гугологии такие системы не годятся даже для подсчета количества нулей у чисел, которыми занимается этот раздел.
Итак, если мы считаем недостижимой максимальную коммпактность записи чисел, то куда уж нам с языками?

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

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

S>Давайте, все-же, возьмем реально существующие ЯП.

Подозреваю, что ты мягко подводишь нас к уже обсуждённому ультракороткому языку программирования RS: https://www.rsdn.org/wiki/4086890

Здравствуйте, Shmj, Вы писали:


S>Компактнее придумать сложно.
S>Давайте мысли по теме.
Зачем? и Главное ЗАЧЕМ?
Ну вот есть

Oberon

на мой взгляд гораздо компактнее хаскеля. Все понятно без бутылки.
BEGIN END убрали для таких вот преверед.

Здравствуйте, Shmj, Вы писали:
S>Давайте мысли по теме.
Вы слишком забегаете вперде. Прежде, чем рассуждать о способах сделать конкретный язык компактным, нужно подумать об основах.

1. Нужен ли "самый компактный язык"?
По очевидным соображениям (если они неочевидны — спрашивайте, я распишу) любая строка длины N является валидной программой на "самом компактном языке".
Хорошо ли это? Для какого-нибудь машинного языка — да, это замечательное свойство.
Но язык программирования разрабатывается не только для машин, но и для людей.
А людям свойственно ошибаться.
Поэтому от реального ЯП нам потребуются следующие два свойства:
а) "коррекция ошибок" — одиночные опечатки должны порождать невалидные программы с соответствующей диагностикой, а не некорректные программы, валидные с т.з. компилятора.
б) "очевидность ошибок" — ошибочный код должен визуально отличаться от корректного кода, чтобы ошибку можно было найти даже без запуска компилятора.

Пример граблей типа "а" — конструкция if в языке C. Я лично находил примеры такого во вполне промышленном коде:

if(calibration_done);
  amplification_ratio = calibrated_amplify;
...
if(amplification_ratio = 0)
  reset_amplifier();
else
  configure_amplifier(amplification_ratio)

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

2. Достижима ли "максимальная компактность"?
Предыдущий пункт намекает на то, что мы могли бы пойти обратным путём: сначала построить самый компактный язык, а затем уже "денормализовать" его, искусственно разредив.
Примерно так поступили при проектировании схемы нумерации кредитных карточек.
Но задача поиска максимально короткой записи для произвольной программы хорошо исследована — она называется "колмогоровская сложность", и доказанно невычислима.

Упс.

Здравствуйте, Pzz, Вы писали:

Pzz>APL же. https://en.wikipedia.org/wiki/APL_(programming_language)

У него есть наследники J и K которые не требуют покупки отдельной клавиатуры

Здравствуйте, Shmj, Вы писали:

S>Вот те же begin|end супротив {} — второе, очевидно, компактнее — и меньше писать и ясность мысли не теряется — и дураку понятно. Можно сказать что отступы еще яснее, вообще не нужны {} — ну пусть, не так важно.

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

Просто пока не придумали ничего существенно более удобного, но оно где-то там есть