Языки программирования

[Bhudh]

Зачем здесь изменяющие операторы в лямбдах, если параметры-числа передаются по значению?

Именно для того, чтобы они возвращали изменённое значение иммутабельного аргумента. Это же стрелочные функции, в них не нужен return при отсутствии фигурных скобок.
До ES5 это выглядит так:

Код (ES5) Выделить Развернуть

[ function(n){ return ++n; }, function(n){ n += 2; }, function(n){ n += 3; } ][n](n);

[Python]

Зачем здесь изменяющие операторы в лямбдах, если параметры-числа передаются по значению?

Именно для того, чтобы они возвращали изменённое значение иммутабельного аргумента. Это же стрелочные функции, в них не нужен return при отсутствии фигурных скобок.
До ES5 это выглядит так:

Код (ES5) Выделить Развернуть

[ function(n){ return ++n; }, function(n){ n += 2; }, function(n){ n += 3; } ][n]();

Так этот код вообще ничего, фактически, не делает. В лямбдах там хотя бы неявным образом происходит return, а в старом синтаксисе изменяется значение только формального параметра (т.е., фактически, локальной переменной, в которую подставляется значение фактического параметра — но не наоборот, значение из формального параметра в фактический параметр не передается). К тому же, здесь формальный параметр опущен — вместо него подставляется undefined, что делает вычисления еще более бессмысленными.

Вот так это работает в node:

Код Выделить Развернуть


> n=1
1
> [ function(n){ return ++n; }, function(n){ n += 2; }, function(n){ n += 3; } ][n]();
undefined
> n
1
> n=0
0
> [ function(n){ return ++n; }, function(n){ n += 2; }, function(n){ n += 3; } ][n]();
NaN
> n
0
>


[Bhudh]

К тому же, здесь формальный параметр опущен

Я уже исправил.

[Python]

К тому же, здесь формальный параметр опущен

Я уже исправил.

На результат влияет, на сам фактический параметр — нет:

Код Выделить Развернуть

> n
0
> [ function(n){ return ++n; }, function(n){ n += 2; }, function(n){ n += 3; } ][n](n);
1
> n
0
>

[Upliner]

Исправить несложно:

Код Выделить Развернуть


> n = 0
0
> [() => ++n, () => n += 2,() => n += 3][n]();
1
> n
1


[maratique]

А если сразу спроектировать язык по этому замыслу, то все гораздо изящнее будет:

Код Выделить Развернуть

if(a<b)
   {b=3;a=sin(b);}
else
   {a=5,b=cos(a);}
Станет

Код Выделить Развернуть

ab<{b3:ab'sin':,a5:ba'cos':}

Кавычки нужны, чтобы отличить переменную sin, от трех переменных s, i, n.
А если основным функциям дать однобуквенные имена типа sin = S, cos = C, tan = T, exp = E, log = L, то совсем классно:

Код Выделить Развернуть

ab<{b3:abS:,a5:baC:}

[Upliner]

Не, тупо гнаться за компактностью -- гиблое дело. Это не намного длиннее, и гораздо понятнее:

Код Выделить Развернуть

a,b = (sin(b), 3) if a<b else (5, cos(a))

[Bhudh]

Это ж тернарный оператор:

Код Выделить Развернуть

a, b = a < b ? (sin(b), 3) : (5, cos(a))

[Python]

Исправить несложно:

Код Выделить Развернуть


> n = 0
0
> [() => ++n, () => n += 2,() => n += 3][n]();
1
> n
1


Цивилизованнее (т.е., ближе к канонам ФП) было бы так, ІМНО:

Код Выделить Развернуть


n=[n=>n+1, n=>n+2, n=>n+3][n](n)


[maratique]

Я когда еще начинал только изучать программирование, сразу почувствовал, что ЯПы несовершенны. Но про себя, наверное, думал, что это я так от незнания думаю, а сами создатели языков — умнющие мужики: если бы было можно попроще сделать, то сделали бы.
Но чем больше я узнавал, тем больше я в этом убеждался. А ведь если подумать немного, то вот факторы, способствовавшие несовершенству:

1)Европейское мышление авторов большинства популярных ЯПов, обусловленное грамматикой их родных языков. И принятой математической нотацией(на 99% европейской)

2)Механизм популяризации, когда популярность набирает не самый изысканный и идейный, а самый блатной. Например, наверняка, богатство фирмы, где работал Риччи, стало причиной распространения Unix'а и Си.
А дальше уже работал принцип преимущества, когда самый успешный захватывает всю землю своими потомками: Си++, Java, C#...

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

Например, вместо европоцентристского Вольфрамовского
solve[{2x+8y-z=4,x-3y+6z=0,7x+5y+2z=3},{x,y,z}]
можно было бы написать
2 8 -1 4 1 -3 6 0 7 5 2 3 3L
Здесь L — унарная функция, значение которой для 3 будет 3*3+3 = 12-арной функцией, принимающей коэффициенты системы.

Или например функция A — addition, сложение. Вместо
1+2+3+4+5+a+b+c
можно написать
1 2 3 4 5abc8A — арность как последний аргумент.

Или можно для ходовых функций договориться, что sin = S, cos = C, tan = T. Тогда, используя особую величину-нечисло _, можно выразить и аркфункции:
sin(x) = xS, но sin(_) = _S уже не число, а обратная функция. Поэтому
arcsin(x) = x_S.

Символов
!"#$%&'()*+,-./0123456789:;<=>@?
ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`{|}~
с учетом полиморфизма и неограниченной гибкости в определении функций хватило бы на огромное кол-во математических и алгоритмических операций.

[Karakurt]

можно было бы написать
2 8 -1 4 1 -3 6 0 7 5 2 3 3L

Нечитаемую хрень. Вы чисто покритиковать, или свой ЯП пишете?

[maratique]

Зато не надо Shift'ами набирать всякие скобки и знаки препинания. Для того, кто много этим занимается, потом уже все очень понятно становится и его эта избыточность бесит.

[maratique]

Нечитаемую хрень. Вы чисто покритиковать, или свой ЯП пишете?

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

Говорят же, что художниктар — не тот, кто умеет рисовать, а тот, кто умеет видеть. Если он увидел, что-то великолепное и захотел это изобразить, то как-нибудь уж нарисует. Хотя рисовать грех или не грех, не понятно.

[kemerover]

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

[maratique]

То есть, хотите сказать, ЯПы намеренно такие избыточные и негибкие, чтобы человеку трудно было ошибиться?
Но тогда, хотя бы те ЯПы, которые предназначены для самого компьютера — байт-коды, например, — они-то хотя бы изысканны и гибки?

[Karakurt]

Главное же не синтаксис, а возможности.

[kemerover]

То есть, хотите сказать, ЯПы намеренно такие избыточные и негибкие, чтобы человеку трудно было ошибиться?

Это один из критериев, который учитывается при разработке ЯП, да. Самые наглядные примеры негибкости ради блага человечества это весь язык Go и borrow checker в Rust.

Но тогда, хотя бы те ЯПы, которые предназначены для самого компьютера — байт-коды, например, — они-то хотя бы изысканны и гибки?

Они оптимизированы для своих юзкейсов. Не знаю, насколько это попадает под изысканность. Про гибкость говорить сложно, это же очень примитивный набор команд, который вживую будут смотреть лишь полтора разработчика в поисках эзотерических багов. Что там надо, кроме Тьюринг-полноты для гибкости? (А в некоторых юзкейсах и она не нужна.)

[Karakurt]

В чем негибок Го?

[maratique]

Главное же не синтаксис, а возможности.

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

[Karakurt]

Кушающий.

[maratique]

Кушающий.

Вот именно. Приходится прибегнуть к совсем другой конструкции. Например, приходится писать cosh(x), хотя можно и cos(i*x)

[Karakurt]

Это разве так важно?

[Bhudh]

Например, можно сказать пьющий человек, но нельзя едящий человек.

Кто Вам это сказал⁈ Это абсолютно нормативное причастие от есть.

[kemerover]

В чем негибок Го?

Нету наследования, дженериков, исключений, нулевых типов; даже тернарного оператора нету. Это первое, что в голову пришло.

[Karakurt]

В чем негибок Го?

Нету наследования, дженериков, исключений, нулевых типов; даже тернарного оператора нету. Это первое, что в голову пришло.

И без этого нормально. Просто непривычно.