Интересные обсуждения
темы заинтересовавшие velkin
Программисты недоучки
06.12.2025
|
Shmj
|
Заметили ли вы что почти все ЯП (львиная доля) используют одни и те же синтаксические правила.
К примеру функция почти всегда — нечто и скобочки:
Но вот в Haskell, для примера, сделали иначе — т.к. там основа не данные а функции — то перевернули эту концепцию. Но такие языки так не вышли (и не выйдут) из ниши специализированных.
Далее. Почти везде операторы имеют одинаковый смысл, понятный любому человеку в мире — как то присвоение (=) или + — * / и т.д.
Почти везде доступ к члену объекта через .
Начало и конец очень часто {}. Но Python тут выделился — такого уродства больше никто не придумал. И как оно у них вообще получилось не ясно.
Работа с голой памятью, указателями — часто * и &
Уже молчу про пробел — пробел и в китайском пробел, не удивлюсь что и у инопланетных жителей есть такая же клавиша пробела.
Т.е. эти символьные вещи стали неким стандартом уже, который выше отдельных правил конкретного языка.
К примеру функция почти всегда — нечто и скобочки:
fun1()Но вот в Haskell, для примера, сделали иначе — т.к. там основа не данные а функции — то перевернули эту концепцию. Но такие языки так не вышли (и не выйдут) из ниши специализированных.
Далее. Почти везде операторы имеют одинаковый смысл, понятный любому человеку в мире — как то присвоение (=) или + — * / и т.д.
Почти везде доступ к члену объекта через .
Начало и конец очень часто {}. Но Python тут выделился — такого уродства больше никто не придумал. И как оно у них вообще получилось не ясно.
Работа с голой памятью, указателями — часто * и &
Уже молчу про пробел — пробел и в китайском пробел, не удивлюсь что и у инопланетных жителей есть такая же клавиша пробела.
Т.е. эти символьные вещи стали неким стандартом уже, который выше отдельных правил конкретного языка.
| 06.12.2025 37 комментариев |
S>К примеру функция почти всегда — нечто и скобочки:
Потому что ЯП создавали (да и создают) люди подкованные не просто в CS но в математике. Потому там используется, скажем так, общепризнанный "математический синтаксис".
S>Но вот в Haskell, для примера, сделали иначе
А хаскель поскольку там задрочились математики конкретным разделом (лямбда-исчислением), то и синтаксис там соответствующий, как Чёрч завещал, грубо говоря.
S>Почти везде доступ к члену объекта через .
S> {}
S> * и &
А тут, очевидно, "так исторически сложилось" — вышел и обрел популярность Си, вот с него, условно говоря, синтаксис и стали передирать.
Стал бы популярным в те времена другой ЯП с другим синтаксисом, сегодня твой пост был бы точно таким же, только вместо & у тебя стояло бы что-то другое.
S>Далее. Почти везде операторы имеют одинаковый смысл, понятный любому человеку в мире — как то присвоение (=) или + — * / и т.д.
Язык математики же.
S>не удивлюсь что и у инопланетных жителей есть такая же клавиша пробела.
Ой не факт. Допустим, у инопланетян никогда не возникло печати? Вот и нет концепции пробела вообще.
А если инопланетяне к тому же не охотники (в настоящем или прошлом), то очень может быть, что даже с символом стрелки будут огромные проблемы.
W>Ой не факт. Допустим, у инопланетян никогда не возникло печати? Вот и нет концепции пробела вообще.
W>А если инопланетяне к тому же не охотники (в настоящем или прошлом), то очень может быть, что даже с символом стрелки будут огромные проблемы.
Охотники? Символ стрелки это же указатель направления.
Но может не быть именно стрелки, потому что философски стрелка как бы говорит нам — двигай туда где встретятся (пересекутся) все параллельные:
SK>Охотники? Символ стрелки это же указатель направления.
Ну да. Стилизованная стрела лука. А луком человечество пользуется уж более 60 000 лет. Потому стрелка такая привычная для тебя, например.
Ну в общем стрела, дротик, ккопье — атрибуты охотника.
А теперь попробуй представить себе цивилизацию, которая никогда не охотилась, и соответственно ни копья, ни стрелы придумано не было?
Думаешь там все еще будет очевидным символ "←" ?
Ну и "двигайся туда" я например вижу не срелку, а трекгольник. Уже разночтения в таком простом моменте.
W>Здравствуйте, Stanislaw K, Вы писали:
SK>>Охотники? Символ стрелки это же указатель направления.
W>Ну да. Стилизованная стрела лука. А луком человечество пользуется уж более 60 000 лет. Потому стрелка такая привычная для тебя, например.
W>Ну в общем стрела, дротик, ккопье — атрибуты охотника.
W>А теперь попробуй представить себе цивилизацию, которая никогда не охотилась, и соответственно ни копья, ни стрелы придумано не было?
W>Думаешь там все еще будет очевидным символ "←" ?
W>Ну и "двигайся туда" я например вижу не срелку, а трекгольник. Уже разночтения в таком простом моменте.
Бороться за выживание, наверно, будет всякий вид на всякой планете, т. е. охотниками в широком смысле будут, другое дело, что на какой-то планете почти все природные материалы могут быть твёрдыми, и почти не быть эластичных, тогда стрелять из лука они не будут, ибо изготовить будет не из чего.
S>>К примеру функция почти всегда — нечто и скобочки:
W>Потому что ЯП создавали (да и создают) люди подкованные не просто в CS но в математике. Потому там используется, скажем так, общепризнанный "математический синтаксис".
Ну не совсем из этого следует такой прямой вывод.
История LISP говорит, что там предполагали для пользователей использовать так называемые M-выражения, когда вызов типа sin(x) писался бы sin[x], а, например, длина гипотенузы была бы hypot[x;y]. Обрати внимание на квадратные скобки и точку с запятой. Вот это изобретали математики для себя. S-выражения, типа (sin x) и (hypot x y), предполагались внутри. Но в итоге от M-выражений отказались и всё перевели на S-выражения. М-выражения используются сейчас в некоторых движках сходного идеологического источника (λ-исчисление), как kdb+.
Скобки при вызове функции — вот в Pascal и Ruby их нет, если и аргументов нет.
Деление — косая черта в строку это фактически новодел 1950-60-х. До этого такой синтаксис был последним из альтернативных.
Можно ещё поискать примеров.
S>>Но вот в Haskell, для примера, сделали иначе
W>А хаскель поскольку там задрочились математики конкретным разделом (лямбда-исчислением), то и синтаксис там соответствующий, как Чёрч завещал, грубо говоря.
И из него получилось не только то, что в Haskell.
S>>Далее. Почти везде операторы имеют одинаковый смысл, понятный любому человеку в мире — как то присвоение (=) или + — * / и т.д.
W>Язык математики же.
И тут _почти_ да. Звёздочка для умножения — артефакт ограниченности кодировок. Про деление я написал выше. В юникоде добавили × и ÷ (принятое в англосаксонском мире для деления), но поезд успел уйти.
А как же КонецЕсли?
По кол-ву разрабов возможно даже и превосходит.
S>Почти везде доступ к члену объекта через .
objc, вызов конструктора: [[class alloc] init: param];
обходятся без точки
правда сейчас язык практически умер и спрятался за синтаксический сахар в виде Swift
S>Заметили ли вы что почти все ЯП (львиная доля) используют одни и те же синтаксические правила.
Это потому, что почти все ЯП (львиная доля) являюются представителями группы Си-подибных языков. Потому у них и синтаксис похожий, примерно как в Си.
Вот Паскаль, например, и прочие Дельфи и Ада, восходят синтаксисом не к Си, а к Algol 60. И поэтому на Си местами весьма сильно не похожи.
S>Но вот в Haskell, для примера, сделали иначе — т.к. там основа не данные а функции — то перевернули эту концепцию. Но такие языки так не вышли (и не выйдут) из ниши специализированных.
Я дико извиняюсь, а какая у Хаскеля специализация?
Pzz>Я дико извиняюсь, а какая у Хаскеля специализация?
Как? Творить добро, конечно — чистый и светлый мир идей: https://www.ozon.ru/product/izuchay-haskell-vo-imya-dobra-2864964385/
Pzz>>Я дико извиняюсь, а какая у Хаскеля специализация?
S>Как? Творить добро, конечно — чистый и светлый мир идей: https://www.ozon.ru/product/izuchay-haskell-vo-imya-dobra-2864964385/
Тогда он должен бы быть похож на эльфийский. Ну или на священную латынь, на худой конец...
S>>Заметили ли вы что почти все ЯП (львиная доля) используют одни и те же синтаксические правила.
Pzz>Это потому, что почти все ЯП (львиная доля) являюются представителями группы Си-подибных языков. Потому у них и синтаксис похожий, примерно как в Си.
Я когда какой-нибудь DSL изобретаю, у меня или сишечка, или плюсики начинают получаться. Странно, да?
Я просто 25 лет на плюсах пишуНи как не могу понять, как так получается.Pzz>Вот Паскаль, например, и прочие Дельфи и Ада, восходят синтаксисом не к Си, а к Algol 60. И поэтому на Си местами весьма сильно не похожи.
Крышечки в Паскале для указателей я так и не осилил, хотя Паскаль изучал до сишечки. Концепция указателей мне была знакома, я на асме Z-80 несколько лет до него писал, а вот не зашло
Pzz>>Вот Паскаль, например, и прочие Дельфи и Ада, восходят синтаксисом не к Си, а к Algol 60. И поэтому на Си местами весьма сильно не похожи.
M>Крышечки в Паскале для указателей я так и не осилил, хотя Паскаль изучал до сишечки. Концепция указателей мне была знакома, я на асме Z-80 несколько лет до него писал, а вот не зашло
Хуже того, там еще и богомерзкие then ... else вместо благословенных Ричи и воспетых Керниганом фигурных скобок.
Pzz>Хуже того, там еще и богомерзкие then ... else вместо благословенных Ричи и воспетых Керниганом фигурных скобок.
Должен заметить, богомерзкие они только в алголоподобных языках. А в Фортране 77 очень даже к месту.
M>>Крышечки в Паскале для указателей я так и не осилил, хотя Паскаль изучал до сишечки. Концепция указателей мне была знакома, я на асме Z-80 несколько лет до него писал, а вот не зашло
После Most Vexing Parse начинаешь понимать, чем они лучше.
Pzz>Хуже того, там еще и богомерзкие then ... else вместо благословенных Ричи и воспетых Керниганом фигурных скобок.
Благословенными они становятся только когда обязательно присутствуют вокруг любого структурного вложения (Rust, Go), а до этого они только чуть менее богомерзкие.
M>>>Крышечки в Паскале для указателей я так и не осилил, хотя Паскаль изучал до сишечки. Концепция указателей мне была знакома, я на асме Z-80 несколько лет до него писал, а вот не зашло
N>После Most Vexing Parse начинаешь понимать, чем они лучше.
Я не очень понял эту мысль...
Pzz>>Хуже того, там еще и богомерзкие then ... else вместо благословенных Ричи и воспетых Керниганом фигурных скобок.
N>Благословенными они становятся только когда обязательно присутствуют вокруг любого структурного вложения (Rust, Go), а до этого они только чуть менее богомерзкие.
Да! То, что Go сделал их синтаксически-обязательными, это очень круто. Я очень оценил и теперь и в Си так пишу.
Но это же не повод вместо фигурных скобок писать целое слово, как в Паскаке.
M>>>>Крышечки в Паскале для указателей я так и не осилил, хотя Паскаль изучал до сишечки. Концепция указателей мне была знакома, я на асме Z-80 несколько лет до него писал, а вот не зашло
N>>После Most Vexing Parse начинаешь понимать, чем они лучше.
Pzz>Я не очень понял эту мысль...
Ну в C стиле у тебя есть какие-нибудь, для предельной простоты, `int *p;`
Если ты его переделываешь в стиле Pascal/Go/Rust/где_то_ещё `var p: *int;` -- то какой метод разыменования указателя? И вот тут возникает вопрос о конфликте символов (да, я это не упомянул сразу). Если для указателя свой символ, как ^ в Паскале, то `var p: ^int` -- это понятно, но тогда чтобы не надо было скобок (потому что в C, `p->x` это `(*p).x`, а не `*p.x`), он ставится постфиксом (в Паскале мы имеем `p^.x`). А если использовать ту же звёздочку, то парсинг тоже не очень лёгкий: `p*` ещё зависит от последующего, `p*.x` это доступ к элементу, а вот `p*x` это умножение. Парсинг усложняется, и я не готов давать зуб, что он влезет в какой-нибудь обычно желаемый LALR(1).
Может, подумав над этим плотно пару часов, я и нашёл бы, что конфликта парсинга нет. Но чтобы так совсем твёрдо и сейчас -- не уверен. А если отдельный символ -- то тут уверенность железобетонная.
Pzz>>>Хуже того, там еще и богомерзкие then ... else вместо благословенных Ричи и воспетых Керниганом фигурных скобок.
N>>Благословенными они становятся только когда обязательно присутствуют вокруг любого структурного вложения (Rust, Go), а до этого они только чуть менее богомерзкие.
Pzz>Да! То, что Go сделал их синтаксически-обязательными, это очень круто. Я очень оценил и теперь и в Си так пишу.
Pzz>Но это же не повод вместо фигурных скобок писать целое слово, как в Паскаке.
С этим согласен на 201%. Скобки хорошо видны, лаконичны и позволяют поиск парной в обе стороны универсальным методом, пригодным для почти любых редакторов или текстовых анализаторов не ниже некоторого базового уровня.
Но их ввести в общий узус стало возможно только тогда, когда настал более-менее тотальный ASCII везде вокруг. Вспоминаем "иНЖАЛИД ДЕЖИЦЕ" -- в те времена и в англоязычном мире они не гарантировались. В EBCDIC были, но впихнуты в достаточно поздние версии.
Если ты посмотришь в стандарты Фортрана, там есть такое понятие, как "processor character set" -- какие символы должны поддерживаться для исходников. В версии даже 1995 года там нет {}. (В 2008 — уже есть. Для 2000 не могу найти.) Понятно, что им для этих символов нужна была языковая фича, но это уже времена очевидной победы Юникода, а они ещё ASCII не освоили.
N>Если ты посмотришь в стандарты Фортрана, там есть такое понятие, как "processor character set" -- какие символы должны поддерживаться для исходников. В версии даже 1995 года там нет {}. (В 2008 — уже есть. Для 2000 не могу найти.) Понятно, что им для этих символов нужна была языковая фича, но это уже времена очевидной победы Юникода, а они ещё ASCII не освоили.
о, подобную эпидерсию я в играх встречал, где шрифт — это малюсенькая картинка, и буква I — это левая часть от E, или типа того, и все буквы/символы отсортированы по высоте и ширине. Правда давненько это было, времён игрушек для телефонов с j2me (не смартфонов, а может и смартфонов уровня Symbian от Nokia)
Pzz>Здравствуйте, netch80, Вы писали:
Pzz>>>Хуже того, там еще и богомерзкие then ... else вместо благословенных Ричи и воспетых Керниганом фигурных скобок.
N>>Благословенными они становятся только когда обязательно присутствуют вокруг любого структурного вложения (Rust, Go), а до этого они только чуть менее богомерзкие.
Pzz>Да! То, что Go сделал их синтаксически-обязательными, это очень круто. Я очень оценил и теперь и в Си так пишу.
Pzz>Но это же не повод вместо фигурных скобок писать целое слово, как в Паскаке.
Все эти вкусы так субъективны! Когда я в первый раз в своей жизни (школьником) увидел код на языке C (по книге Болски "Язык программирования Си"), то я не сразу понял, где там программный код, а где условный странный какой-то псевдокод с фигурными скобками, звездочками и стрелками, а тогда мне уже были знакомы и Паскаль, и Фортран, и Бейсик.
Все это настолько вкусовщина. Если бы на языке С не написали Unix, то тогда был бы большой вопрос, какие были бы сейчас предпочтения у программистов в основной массе. Однако у истории нет сослагательного наклонения. Поэтому имеем засилье синтаксиса языка C в программировании. К этому можно относиться по-разному, но это факт
Мне в начале синтаксис языка C совершенно не понравился. Стал привыкать, когда по телеку стали крутить рекламу рабочих станций, где прямо акцентировали внимание на то, что там был C++. Да и в журналах компьютерных стали много писать о разных компиляторах для C++ (сейчас такого разнообразия нет). Я почувствовал, что тема выстрелила, и только тогда стал интересоваться языками C и C++ более глубоко, хотя примеры на языке C в начале я и за программный код-то не посчитал (см. выше про книгу Болски)
D>Все эти вкусы так субъективны! Когда я в первый раз в своей жизни (школьником) увидел код на языке C (по книге Болски "Язык программирования Си"), то я не сразу понял, где там программный код, а где условный странный какой-то псевдокод с фигурными скобками, звездочками и стрелками, а тогда мне уже были знакомы и Паскаль, и Фортран, и Бейсик.
Ну, фиг знает, я Паскаль изучал раньше сишечки, и уже тогда меня Begin/End бесили. Это просто визуальный мусор, который захламляет код и делает его сильно хуже читаемым на ровном месте. И когда я узнал сишечку — скобки прям вот сразу зашли
D>Все это настолько вкусовщина. Если бы на языке С не написали Unix, то тогда был бы большой вопрос, какие были бы сейчас предпочтения у программистов в основной массе. Однако у истории нет сослагательного наклонения. Поэтому имеем засилье синтаксиса языка C в программировании. К этому можно относиться по-разному, но это факт
Ну, фик знает
D>Мне в начале синтаксис языка C совершенно не понравился. Стал привыкать, когда по телеку стали крутить рекламу рабочих станций, где прямо акцентировали внимание на то, что там был C++. Да и в журналах компьютерных стали много писать о разных компиляторах для C++ (сейчас такого разнообразия нет). Я почувствовал, что тема выстрелила, и только тогда стал интересоваться языками C и C++ более глубоко, хотя примеры на языке C в начале я и за программный код-то не посчитал (см. выше про книгу Болски)
Что, прям по телеку плюсики рекламировали?
N>>Благословенными они становятся только когда обязательно присутствуют вокруг любого структурного вложения (Rust, Go), а до этого они только чуть менее богомерзкие.
Pzz>Да! То, что Go сделал их синтаксически-обязательными, это очень круто. Я очень оценил и теперь и в Си так пишу.
Ну, фик знает. Вообще, я лично пишу код "воздушным", добавляю и отдельные пустые строки, и даже двойные, для того, чтобы показать, что "повествование" делает какой-нибудь "флэшбэк", который не относится прямо вот непосредственно к предыдущему абзацу.
Но вот в if'ах, если там однострочное действие, всё же пишу без фигурных скобок
Pzz>Я дико извиняюсь, а какая у Хаскеля специализация?
По факту, Haskell — это устоявшаяся лингва франка в области статически типизированного функционального программирования. Раньше в этой роли был первородный ML, но теперь больше Haskell (как представитель уже всего семейства языков ML). А лиспы — по-прежнему для динамически типизированного функционального программирования
К языкам из семейства ML еще относятся OCaml и F#
Что касается возможности функционального программирования стать популярным, то это сильно вряд ли. Главным образом, для этого нужны определенные склады характера, склады мышления. Их не один и не два, но скажем так, что большинство людей мыслит иначе — и для них действительно (обычное) императивное программирование подходит много лучше. Хотя некоторые идеи функционального программирования все же дошли и до мейнстрима, впрочем, не затронув сути. Может быть, только Rust является некоторым исключением, где идея программирования в типах нашла более яркое выражение (это характерная черта статически типизированных языков функционального программирования)
S>Т.е. эти символьные вещи стали неким стандартом уже, который выше отдельных правил конкретного языка.
И что? Семантика всем привычна по уже существующим языкам, зачем изобретать что-то новое? Тем более, что для математических операторов символы взяты из математики. Семантика вызова функций тоже оттуда. Что у тебя вызывает подгорание?
S>>Т.е. эти символьные вещи стали неким стандартом уже, который выше отдельных правил конкретного языка.
M>И что? Семантика всем привычна по уже существующим языкам, зачем изобретать что-то новое? Тем более, что для математических операторов символы взяты из математики. Семантика вызова функций тоже оттуда. Что у тебя вызывает подгорание?
x = x + 1 => x — x = 1 => 0 = 1 => x не существует. Это математика.
Из-за фашистов, в программировании, вместо нормальной записи:
x + 1 → x
которая читается "к иксу прибавить один и записать в икс" мы имеем крайне извращённый синтаксис. Даже символа стрелки на клавиатуре нет. Из-за фашистов. Ну или из-за анитифашистов, которые те же фашисты, только наоборот.
Короче, привычка — это не аргумент. Привычка может быть дурной и даже пагубной.
BFE>Здравствуйте, Marty, Вы писали:
S>>>Т.е. эти символьные вещи стали неким стандартом уже, который выше отдельных правил конкретного языка.
M>>И что? Семантика всем привычна по уже существующим языкам, зачем изобретать что-то новое? Тем более, что для математических операторов символы взяты из математики. Семантика вызова функций тоже оттуда. Что у тебя вызывает подгорание?
BFE>x = x + 1 => x — x = 1 => 0 = 1 => x не существует. Это математика.
Ну математики тупые, за столько лет не дошли до использования разных символов для присваивания и равенства, только какие-то извращения чтобы их различить: ≝, ≜
M>>>И что? Семантика всем привычна по уже существующим языкам, зачем изобретать что-то новое? Тем более, что для математических операторов символы взяты из математики. Семантика вызова функций тоже оттуда. Что у тебя вызывает подгорание?
BFE>>x = x + 1 => x — x = 1 => 0 = 1 => x не существует. Это математика.
P>Ну математики тупые,
Что за странный и необоснованный вывод про тупость математиков?
P>за столько лет не дошли до использования разных символов для присваивания и равенства, только какие-то извращения чтобы их различить: ≝, ≜
Математики мыслят утверждениями, а программисты — действиями. Для разных целей нужны разные языки.
Вот математика: ] x = 0
Вот программирование: 0 → index
Что общего? Цифра?
Но при этом все тащат математику в программирование. Инертность мышления, не иначе.
P>Ну математики тупые, за столько лет не дошли до использования разных символов для присваивания и равенства, только какие-то извращения чтобы их различить: ≝, ≜
Вообще-то для присваивания и равенства у математиков используются разные символы. Присваивание — =, равенство — .EQ., причём скоро 70 лет как. Инициализация тоже делается не так, как присваивание. Это сейчас всё в кучу напихали.
Я всегда говорил: Фортран — наше всё!
P>>Ну математики тупые, за столько лет не дошли до использования разных символов для присваивания и равенства, только какие-то извращения чтобы их различить: ≝, ≜
P>Вообще-то для присваивания и равенства у математиков используются разные символы. Присваивание — =, равенство — .EQ., причём скоро 70 лет как. Инициализация тоже делается не так, как присваивание. Это сейчас всё в кучу напихали.
P>Я всегда говорил: Фортран — наше всё!
"Присваивание" для математиков это вообще крайне непонятная концепция.
Я как-то однокласснику пытался объяснить смысл фортрановского X=X+1. Сейчас я, конечно, умнее, и могу рассказать про взаимное соответствие императивного и функционального стиля, состояние программы и пр., а тогда я просто не мог понять, что ему непонятно. Big fail для обоих, он не понял идею и обиделся, а я не понял его проблему и остался в недоумении. Но сейчас он доктор наук и декан, а я инженер без степени ;\
А в вузе была вечная проблема, когда появляется формула типа `c=a+b`, а что из них было определено раньше, что новое, и это определение `c`, требование для `c`, приходящего извне, или что-то третье — надо вытаскивать клещами из контекста и преподавателя.
И обрати внимание, что .EQ. и прочие символы возникли тогда, когда пользователям перестало хватать арифметического IF и потребовался логический, а знак `=` был прочно занят операцией "создание нового состояния исполняющей среды модификацией предыдущего состояния посредством замены значения, соответствующего конкретному имени" (в народе просто "присваивание" "переменной").
Так что -- то, что ты говоришь, это не математика, а именно и только Fortran.
N>"Присваивание" для математиков это вообще крайне непонятная концепция.
Для тех, с которыми я работал — вполне понятная.
Они знали, чем вычисления отличаются от машинных вычислений. При этом не пихали сравнение с машинным эпсилон куда ни попадя. Прикладники.
N>Я как-то однокласснику пытался объяснить смысл фортрановского X=X+1.
А когда я узнал, что при вычислениях на ЭВМ целые числа не являются подмножеством вещественных, я вообще в шоке какое-то время был. Но написав несколько программ на Фортране, пришёл в норму.
N>А в вузе была вечная проблема, когда появляется формула типа `c=a+b`, а что из них было определено раньше, что новое, и это определение `c`, требование для `c`, приходящего извне, или что-то третье — надо вытаскивать клещами из контекста и преподавателя.
Ну да. Причём преподаватель на распечатке делал правки, а на любой связанный с ними вопрос отвечал: "Так надо".
N>И обрати внимание, что .EQ. и прочие символы возникли тогда, когда пользователям перестало хватать арифметического IF и потребовался логический, а знак `=` был прочно занят операцией "создание нового состояния исполняющей среды модификацией предыдущего состояния посредством замены значения, соответствующего конкретному имени" (в народе просто "присваивание" "переменной").
Тут не знаю. Я начинал с Фортрана 4, в нём все эти символы уже были.
N>Так что -- то, что ты говоришь, это не математика, а именно и только Fortran.
Нормальная прикладная математика. Которая на Фортране и реализовывалась.
N>>"Присваивание" для математиков это вообще крайне непонятная концепция.
P>Для тех, с которыми я работал — вполне понятная.
P>Они знали, чем вычисления отличаются от машинных вычислений. При этом не пихали сравнение с машинным эпсилон куда ни попадя. Прикладники.
Согласен, сужаю своё замечание до "чистых" математиков.
N>>И обрати внимание, что .EQ. и прочие символы возникли тогда, когда пользователям перестало хватать арифметического IF и потребовался логический, а знак `=` был прочно занят операцией "создание нового состояния исполняющей среды модификацией предыдущего состояния посредством замены значения, соответствующего конкретному имени" (в народе просто "присваивание" "переменной").
P>Тут не знаю. Я начинал с Фортрана 4, в нём все эти символы уже были.
Я тоже начинал с 4-го, но потом интересовался историей. Там много забавного.
Например, в 1-м целые начинались с буквы X, а все прочие были вещественными. На правило типа "IMPLICIT INTEGER/I-N/" замена произошла как раз при переходе на Fortran II. Логический IF появился, кажется, только в III, до этого был только арифметический, потому у '=' не было конфликта. Синтаксис FORMAT менялся несколько раз. Парсинг выражений делался подстановкой каскадов скобок, разбирать приоритеты иначе вначале не умели. И это только то, что с ходу вспомнилось.
N>>Так что -- то, что ты говоришь, это не математика, а именно и только Fortran.
P>Нормальная прикладная математика. Которая на Фортране и реализовывалась.
Ну в наше время уже совсем не только. Сейчас, да, математик без понимания какого-то Питона уже как инвалид без рук, а он императивный.
Но ещё в 90-е было слишком много снобизма по поводу средств, я его застал.
S>Заметили ли вы что почти все ЯП (львиная доля) используют одни и те же синтаксические правила.
Вы говорите не про "почти все ЯП" и не про "усреднённый синтаксис".
Вы говорите про совершенно конкретное семейство языков, которые основаны на наследии Си. Очень легко проследить дерево наследования С->C++->Java->Js->Ts, Java->C#, Java->Kotlin, и так далее.
Во всех этих языках есть заметные общие черты. Примерно так же, как во всех европейских языках, кроме греческого, за основу взята латынь, письмо справа налево, понятие строчных/заглавных букв, и более-менее общая пунктуация.
А всё остальное — это семейство Алгола (Паскаль, Оберон, процедурный SQL), семейство Lisp, семейство лямбда-языков типа Хаскела, и всякие нишевые отщепенцы.
S>Уже молчу про пробел — пробел и в китайском пробел, не удивлюсь что и у инопланетных жителей есть такая же клавиша пробела.
句法研究滥觞于公元前4世纪的梵文文法学家波你尼的著作
Китайцы как раз пробел не используют так как мы. Больше между предложениями или частями предложений, но не между каждым словом.
S>Т.е. эти символьные вещи стали неким стандартом уже, который выше отдельных правил конкретного языка.
И? Закончи мысль.
S>>Т.е. эти символьные вещи стали неким стандартом уже, который выше отдельных правил конкретного языка.
R>И? Закончи мысль.
Получается что запись почти одинаковая, уже есть в JS, C#, Dart — те же async|await, изучив концепцию в одном — будешь знать и использовать везде.
Со временем языки усреднятся и возможно что будет один общий язык.
S>Получается что запись почти одинаковая, уже есть в JS, C#, Dart — те же async|await, изучив концепцию в одном — будешь знать и использовать везде.
А, ну я, кажется, понял, откуда растут ноги. Ты несколько лет пыталсся распространить на С++ свой опыт работы с "приятными" языками, получил жестокий облом и ударился в мечты?
S>Со временем языки усреднятся и возможно что будет один общий язык.
И что нужно делать в связи с этой вновь открывшейся информацией? Бросить всё и вместе с тобой ждать светлого будущего?
S>Заметили ли вы что почти все ЯП (львиная доля) используют одни и те же синтаксические правила.
Это потому, что языки программирования писали программисты обладающие знанием математики и других языков программирования. Для примера книга Дизайн и эволюция языка C++. Страуструп Бьерн на странице 21 можешь посмотреть небольшую схему на каких языках основывались следующие языки вплоть до C++. Или можешь в интернете открыть более общие схемы наследования для большего количества языков программирования.
S>Далее. Почти везде операторы имеют одинаковый смысл, понятный любому человеку в мире — как то присвоение (=) или + — * / и т.д.
Поздравляю, ты только что открыл для себя математику и её знаки, подраздел арифметика, по-русски переводится как числа. К слову сказать разные известные математики использовали похожие, но не идентичные знаки. Для примера деление и умножение.
В программировании же часто использовалось то, что было на клавиатурах терминалов доступа. Если нужного знака не было, его заменяли наиболее подходящим, который был.
S>Уже молчу про пробел — пробел и в китайском пробел, не удивлюсь что и у инопланетных жителей есть такая же клавиша пробела.
S>Т.е. эти символьные вещи стали неким стандартом уже, который выше отдельных правил конкретного языка.
Я лично рекомендую прочитать тебе книгу.
Архитектура компьютера. 6-е издание. Таненбаум Эндрю, Остин Тодд
С первых подглав вроде страницы 20 "Языки, уровни и виртуальные машины" ты откроешь для себя много нового.
Я когда-то написал статью Почему программисты прошлого были умнее (26.05.2022).
Если бы я писал сейчас, то я бы добавил ещё пятое поколение наративщиков или вайбкодеров. Дело в том, что за последние годы терминология ещё подвергалась изменениям. Опять же я мог бы дать им другое название исходя из смысла их процессов как я это сделал в статье.
То, что в программировании используются математические знаки, в частности из арифметики, по-русски значит числа меня не удивляет от слова совсем. Но в своё время меня больше удивил не пробел, который по твоему мнению должны использовать даже инопланетяне.
Когда-нибудь задумывался почему красная строка называется красной, хотя она не красная и даже не строка, а по сути отступ в начале строки? Но что если взглянуть на древние тексты Египта, как пишут в статьях про происхождения красной строки.
[img=large]https://static.dzeninfra.ru/s3/zen-apps/desktop2/3.399.1/s2L8dMk/1lts1q331014a0cR9qostKxWSbZJkBSuDMuLDa7j87kaV5yX8PStKl6O5ZU4OOkZ5rO804KxiuTaT7w216C143lU0gErulJizWwTP8ND1BfTWmF7r39UJuE6x5q4e5yswE9A5pVzrbKcwIE4LUaFyxHzf5846lMG5McfHoOEhYXbDPaCJtA7zU0VR0K4dNorJa44rTMjZ14R53juiqKzlueGtvHpE757YjUB5Gj0wqCvJ69IxiB4feFqu[/img]
[img=large]https://avatars.dzeninfra.ru/get-zen_doc/1860870/pub_5e8202b60d0caf37692914af_5e8203f34dc6b06f644d8e25/scale_1200[/img]
Мораль здесь в том, что китайский язык тоже был изменён и нужно смотреть старые тексты в которых никакого пробела не было. И я не знаю, что там инопланетяне будут использовать, но в книгах часто любят вспоминать про когнитивную психологию.
Многое уже изобрели до нас. А часть переизобрели и оно было другим. Но лично для меня важно воплощены ли идеи в программе или нет. Обнаружил ты например, что в программировании используются плюс и минус из математики и прочие знаки. А дальше что? Какую пользу это может принести тебе лично и другим?
Все и так знали, кто учился в школе эти знаки, причём с начальных классов. А читать умели ещё до поступления в школу. Многие принципы известны, но мало успешно применяются в повседневной жизни через программы.
Те же когнитивные психологи не программисты. А программисты работают на корпоратов США. Очевидно, что распределённая система гораздо более устойчива, но корпоратам выгоднее сделать централизованную. Вот и всё.
Кто остаётся? Написаны ли все программы? А потом ещё технологии меняются, а основы забываются. Ниже уровня ассемблера не только машинный код, но и ещё до кучи уровней вплоть до вентилей.
Или на самом ли деле лично ты можешь извлечь из абстракций только на верхних уровнях огромную пользу или они идут во вред? По мне так это тупик, путь в никуда, деградация.