LINUX.ORG.RU

Почему Go это плохо, и он вам, на самом деле, не нужен.

 ,


7

15

Давайте я вам поясню про язык Go, откуда у него растут корни, и почему его на самом деле не стоит использовать. То что напишу ниже, это взято как из инсайдерской информации, так и из материалов, доступных в интернетах.

Дело в том, что Go это, на самом деле, «решение» внутренних гугловских проблем. Но отнюдь не проблем горизонтального масштабирования серверного ПО, как многие почему-то думают. Он приспособлен специально для использования в гугле вот в каком контексте.

Гугл нанимает большое количество тупых студентов, только-только после вуза или ПТУ, и заставлять их писать хоть какой-то простой код. И делать минимум ошибок, при этом. Для этого Go сделан таким тупым и упрощенным. И выкинут в паблик он только для того, чтобы вероятность, что у такого студента, только пришедшего в гугл, было хоть какое-то знание Go, была выше нуля.

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

Из гугла же идет маразматическая система управления зависимостями Го, которая заточена на монорепы.

Тут возникает вопрос - а почему этому тимлиду не дать в руки кодогенератор, вместо всей этой accidental complexity, возникающей из-за огромного количества строк кода, и из-за затрат на коммуникацию?

А тут надо понимать, как внутри устроены огромные корпорации типа гугла.

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

Естественно, это все отражается на качестве продуктов, и это видно как по полному прекращению инноваций в гугле, так и по постоянно мелькающим и закрывающимся высерам этой компании - hangouts, duo, google plus, google wave, и прочее и прочее, можете еще вспомнить много чего.

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

Никакой мифической простоты в отладке и в понимании кода Go не приносит. Да и сложность программных систем растет совершенно не из-за понятности/непонятности какой-то отдельной взятой строчки кода или функции. Потому, что, во-первых, понятность это понятие субъективное, во-вторых потому, что, отдельно взятая фунцкия на 5 строк понятна любому опытному программисту, будь она написана хоть на Rust, хоть на Common Lisp.

Сложность программных систем возникает из-за их размера. И Go эту проблему значительно ухудшает. Человек не может удерживать в голове слишком много вещей, даже если каждая отдельная вещь - очень простая. Количество RAM в голове ограничено.

В случае если вы не хотите выкидывать кучу денег просто так, и скорее предпочли бы нанять немного, но более-менее опытных программистов, Go будет только вреден, потому что все вменяемые люди от него, на самом деле, плюются. Он реально отталкивает опытных людей, которые способны понять сложные требования и написать, и поддерживать, более-менее сложные системы уровнем хотя бы нескольких сервисов плюс БД и MQ.

★★
Ответ на: комментарий от den73

новые люди становятся всё тупее, сказывается развращённость родителей

Ага, традиционных ценностей не хватает.

rumgot ★★★★★
()
Ответ на: комментарий от den73

объявление имя: тип, а не тип имя для сложных типов даёт большое преимущество, т.к. оно читается слева направо, в отличие от Си, Явы, C#. Т.е. тоже исправлена многолетняя ошибка проектирования, которая не столь важна, как ООП, но тоже влияет на производительность труда.

Херня какая-то. Чем оно лучше? А когда тип вначале, то ты читаешь не слево направо?

rumgot ★★★★★
()
Ответ на: комментарий от rumgot

у тебя может быть длинный тип особенно в пору любви к темлейтам и маааленькое такое имя переменной, которое надо еще найти в этой каше.

это важно для читабельности. чем значимей информация, тем левее она должна быть в предложении. ибо читаем мы слева направо.

alysnix ★★★
()
Ответ на: комментарий от Elidee

можно ли определить свое макро или функцию с именем loop и заменить стандартную реализацию своей?

Как говорил классик, можно и яйца дверью специально прищемить %)

Nervous ★★★★★
()
Ответ на: комментарий от alysnix

у тебя может быть длинный тип особенно в пору любви к темлейтам и маааленькое такое имя переменной

А может быть наоборот. И что тогда?

это важно для читабельности. чем значимей информация, тем левее она должна быть в предложении

Имя переменной значимее ее типа? Это сравнение странное. Важно и то и то.

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

rumgot ★★★★★
()
Ответ на: комментарий от rumgot

А что, выводить список всех доступных в данной единице трансляции переменных/функций?

Это будет попытка угадать. Кроме того, если я пишу библиотеку шаблонов, то в текущей единице трансляции не будет ни одного пользовательского типа.

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

eao197 ★★★★★
()
Ответ на: комментарий от ugoday

тут идет явный вызов кастомной функции. В лиспах же можно переопределить всякие loop, map, filter и т.д. которые делают что-то свое. В итоге у каждого проекта - свой язык.

Еще могу привести пример такой:

  • что делает ‘+’ в Go? Складывает числа или строки
  • что делает ‘+’ в Python? Хрен его знает, надо смотреть каждый класс.
Elidee
()
Ответ на: комментарий от Elidee

В лиспах же можно переопределить всякие loop, map, filter и т.д

А в C я могу сделать #define true false и что? Или ещё лучше #define 3 7. Давайте всё-таки различать ситуации нечаянно выстрелил себе в ногу и совершил суицид чтобы получить страховку.

что делает ‘+’ в Go? Складывает числа или строки

Ин да реал ворлд в Го вы будете смотреть, что делает вызвов API GET: /calc/plus и результат может вас не порадовать. Это раз. Далее, если вы решили переопределить оператор сложения, значит тому есть причина. Эта же причина будет действовать и в Гошном коде. Поэтому вместо оператора + у вас будет Calculator.evaluate.plus(op1, op2), с которым тоже придётся разбираться отдельно.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

Ин да реал ворлд в Го вы будете смотреть, что делает вызвов API GET: /calc/plus и результат может вас не порадовать.

Точно также надо смотреть и в программе на лиспе что делает этот вызов API. Но в лиспе каждый раз когда смотришь что делает этот вызов и встречаешь вроде бы стандартную форму или оператор - надо думать и проверять что она делает, как зависит ее поведение от фазы луны. А в Go + всегда +.

Elidee
()
Ответ на: комментарий от rumgot

Имя переменной значимее ее типа? Это сравнение странное. Важно и то и то.

тип привязан к имени. читать какой-то пространный тип на три строки темлейтов… только для того, чтобы понять к какой переменной он призан - это странное удовольствие.

тип - вообще вспомогательная, конкретизирующая переменную информация.

alysnix ★★★
()
Ответ на: комментарий от Elidee

встречаешь вроде бы стандартную форму или оператор - надо думать и проверять что она делает

Паранойя — она такая %)

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

Предупредить — да, мол, здесь была переопределена такая-то функция. Кложа так и делает, CL тоже.

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 4)
Ответ на: комментарий от Nervous

Да, думают также, и даже с тех пор в другом месте тоже вместе работали.

den73 ★★★★★
()
Ответ на: комментарий от Elidee

Проблема в том, что вы сейчас теоретизируете. Вам кажется, что ваши аргументы неотразимы, но это всего лишь ваша фантазия.

ugoday ★★★★★
()
Ответ на: комментарий от Elidee

Но так как писать такой код многим программерам становится скучно

Кстати, по-первости, я на го очень ругался из-за недостаточной «выразительности» в некоторых местах. Где-то из-за отсутствия дженериков и прочее. Пока не побился головой в тот треш который у меня получался и не начал писать «как в методичке сказано, без выпендрёжа» и стало несколько многословнее, но для понимания проще.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Nervous

Разработка ЯП является, с одной стороны, инженерной дисциплиной, а с другой, восприятие ЯП является формой любви и идеализации. Ничем иначе невозможно объяснить, что люди могут считать нормой, когда функция создаётся одним служебным словом и четырьмя скобками:

(lambda () )

, а для создания локальной переменной нужно слово и 6 скобок:

(let ((a 1)) )

Это просто анекдот, а не инженерное решение. Даже Паскаль с его BEGIN-ом нервно курит в сторонке. Про go я уж и не говорю, в Го реально хороший синтаксис. Если чуть подумать, то, наверное, такой перекос возникл из-за того, что лисп изначально был про лямбда-исчисления, и поэтому лямбды так главнее. Но когда он становится промышленным языком, на котором пишут большой код, лямбда исчисление отходит на второй план. А важно, чтобы конструкции были удобными. Некоторые любят жрать кактус. Но от этого факт того, что с инженерной точки зрения это ошибка в языке, никуда не исчезает. Именно это является проблемой лиспа, а не скобочки. Я просто это объяснил и показал, как это можно исправить. А дальше уже твоё дело, как этой информацией распорядиться.

А с точки зрения правомерности использования «перги», то в лиспе есть макросы и лисперы этим гордятся. Я сделал свой макрос, который решал мою проблему (точнее не мою, а имевшую место в языке). Просто это сделал я, а не кто-то авторитетный для тебя, не Пол Грэм с его _f и не автор анафорических макросов. И _f, и анафорические макросы встречаются в коде, и их смысл ровно в том же: сократить некоторые конструкции для удобство. Всё дело в авторитете, поэтому у тебя и разное восприятие. Если бы ты не был предвзят, то ты бы признал, что perga - это классная штука, потому что придраться тут особо не к чему.

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 4)
Ответ на: комментарий от den73

функция создаётся одним служебным словом и четырьмя скобками:

потому что нужно S-выражение. а оно, если не атомарное, должно быть в скобках

alysnix ★★★
()
Ответ на: комментарий от alysnix

Ты не на то отвечаешь. Проблема не в 4, а проблема в том. что 6 больше 4. А при том переменные нужны чаще, чем функции. Т.е. есть перекос. Чтобы избавиться от 6 скобок, придумали даже такой костылёк, как &aux. Он сейчас не в моде, но его можно в реальном коде встретить. Сам факт его существования говорит, что не одному мне не нравятся 6 скобок. Вам нравятся - продолжайте жрать кактус, но если вы считаете это нормальным, то это только от любви и идеализации. Любовь зла, полюбишь и козла. А так это абсурд, скажите любому и он вас засмеёт.

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от den73

Ничем иначе невозможно объяснить, что люди могут считать нормой, когда функция создаётся одним служебным словом и четырьмя скобками:

(lambda () …)

А как ты предлагаешь это делать? Специальный литерал придумать, типа #(...)? А как его программно конструировать/изменять?

а для создания локальной переменной нужно слово и 6 скобок:

(let ((a 1)) …)

Просто биндинг может быть как парой символ-выражение, так и просто символом, и тогда подразумевается, что его значение должно быть nil. Отсюда лишние скобки.

В кложе это выглядит так — если нужен nil, пишешь явно. Скобок становится гораздо меньше.

(let [a 1] ...)
Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 2)
Ответ на: комментарий от Nervous

Мне не потому плевать на его мнение, что мне в принципе плевать, а потому, что я не пишу сейчас на лиспе. И потому что он написал просто бессодержательный сарказм. Был бы содержательный сарказм - было бы больше внимания.

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

поэтому лямбды так главнее

Ничего там не главнее. Как по мне - весь лисп это AST кишками к программисту, потому и макросы так хорошо легли, ты ast->ast по-сути преобразуешь.

Потому и «синтаксис» такой. ИМХО.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Nervous

А как ты предлагаешь это делать?

Проблема не в 4 скобках, а в неравенстве 6>4

В кложе это выглядит так — если нужен nil, пишешь явно.

В CL это так же вообще-то. Как я предлагаю, я уже написал выше. По-хорошему, было бы так:

(def-perga-fun f ()
  (let a 1)
  (let b 2))

На каждую переменную нужно две скобки и одно слово. Но я понял со временем, что определять свой defun - это пагубная затея, поэтому не удалось сделать так хорошо, и получился всё же костыль:

(defun f ()
  (perga
    (let a 1)
    (let b 2)
    !))

Всё равно лучше, чем

(defun  f ()
  (let ((a 1)
        (b 2))
      !))

По скобкам всё ещё выигрыш, по вложенности тоже выигрыш.

den73 ★★★★★
()
Ответ на: комментарий от Dark_SavanT

С точки зрения синтаксиса - это AST кишками наружу, с точки зрения семантики - это всё же лямбда-исчисление изначально.

den73 ★★★★★
()
Ответ на: комментарий от Nervous

Разные суждения высказывают, почему Лисп имеет такой синтаксис.
Sorry за повтор суждения.

В 80-х и начале 90-х CPU компьютеров, да и memory были на порядки меньше нынешних.
Поэтому программисты старались разработку эффективных алгоритмов.
Что касаемо Лисп, то он прост для парсинга и тем самым меньше времени тратилось на компиляцию, ...
Также его можно было использовать для embedded устройств.

Forum0888
()
Ответ на: комментарий от den73

для создания локальной переменной нужно слово и 6 скобок

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

У него по-прежнему есть своя довольно узкая ниша где он востребован, но не более того.

Obezyan
()
Ответ на: комментарий от ugoday

Проблема в том, что вы сейчас теоретизируете. Вам кажется, что ваши аргументы неотразимы, но это всего лишь ваша фантазия.

Нет, тоеретизированием это может показаться в одном случае - если ты пишешь код от обеда и до зарплаты.

В проектах с командами болше 2х человек - мои примеры это вполне реальные проблемы. В любой команде нужно добавлять новичков. И новому человеку нужно вникнуть в проект. А чем «выразительнее» язык - тем больше времени новичок проводит в состоянии «тут вообще нихрена не понятно как же оно работает». Потому что надо вникнуть не только в проектную область, но и в самодельный язык.

Предвижу совет - нанимать квалифицированных. Но «квалифицированные» проводят ровно такое же количество времени в состоянии «этот говнокод надо выкинуть и переписать все с нуля».

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

Elidee
()
Последнее исправление: Elidee (всего исправлений: 1)
Ответ на: комментарий от Obezyan

Там иначе было никак, компьютер под который создавали Lisp не умел работать ни с чем кроме списков (cell-ячеек).

В перге тоже нет ничего, кроме cell-ячеек. Да и на тех же cell ячейках реальный let - не единственно возможный. Например, тот же aux является примером, как делать переменные по-другому. Или вот так можно было:

(let имя значение . тело)

Или

(LET имя1 значение1 имя2 значение2 :BODY . тело)

С точки зрения расхода памяти интерпретатором тут нет особой разницы. Так что 6 скобок - это произвольный выбор авторов лиспа.

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

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от Elidee

В проектах с командами болше 2х человек - мои примеры это вполне реальные проблемы. В любой команде нужно добавлять новичков. И новому человеку нужно вникнуть в проект. А чем «выразительнее» язык - тем больше времени новичок проводит в состоянии «тут вообще нихрена не понятно как же оно работает». Потому что надо вникнуть не только в проектную область, но и в самодельный язык.

Ну, примерно это и есть одна из основных причин возникновения таких языков как go и их массовое быстрое распространение. Это рационально и правильно. И только в углу ноют полтора недооцененных илитария. Гуглам нет времени дрочить в лиспы, там работы много.

slew
()
Ответ на: комментарий от slew

Им настолько нет времени дрочить в лиспы, что они даже написали своё (авторитетное) руководство по стилю программирования на лиспе, вот оно: https://google.github.io/styleguide/lispguide.xml

Кроме того, ChatGPT заявляет, что "Google использует Common Lisp для разработки и поддержки системы поиска Google Search. ", хотя надо ещё спросить, где доказательства этого.

Так что (если чуть пофантазировать) пока макаки пишут на Го перекладывание json-ов, в том же гугле в углу сидят полтора элитария и ковыряются в движке поиска.

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 4)
Ответ на: комментарий от alysnix

тип привязан к имени

Переменная привязана к типу…

читать какой-то пространный тип на три строки темлейтов

Use using/typedef, Luke…

тип - вообще вспомогательная, конкретизирующая переменную информация.

Тип - это более общая информация, он может относиться к разным переменным, а вот переменная может быть объявлена только одна с одним и тем же именем в одном месте (области видимости).

rumgot ★★★★★
()
Ответ на: комментарий от Elidee

Нет, тоеретизированием это может показаться в одном случае

Милейший. Вы именно, что теоретизируете. Выдумываете аргументы и рассуждаете на заданную тему. Это не плохо, но было бы гораздо убедительнее, если бы вы рассказали случай из собственной практики, как разбирались с чужим lisp-кодом и обнаружили там ужосы.

ugoday ★★★★★
()
Ответ на: комментарий от rumgot

конструкция называется, и по смыслу является - «декларацией переменной».

декларация переменной обязательно включает имя переменной, тип (явный или который может быть вычислен по выражению инициализации) и выражение инициализации.

декларация переменной, когда тип идет первым, неудобна если имя типа длинное, или тип описан явно, например

struct {
 ....
 ....
 ....
 //тут еще примерно 150 строчек
} variable_name;

куда проще читать декларацию

variable_name : struct {
....
....
примерно 150 строчек
}

}

alysnix ★★★
()
Ответ на: комментарий от Nervous

Специальный литерал придумать, типа #(…)?

Emacs умеет подменять (lambda (x) (+ x 1)) на (𝛌 (x) (+ x 1)). Лично меня вполне устраивает.

ugoday ★★★★★
()

для тех кто пользуется голангом или хвалит его… читали эссе?

50 оттенков голанг

интересно мнение практикующих.

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)

Приходилось многие ЯП программирования использовать для разработки: Алгол-60, Fortran, Pascal, PL-1, Мнемокод, Assembler, ...,
PHP, Perl, ..., ..., ... и ни разу не возник помысел, что синтаксис ЯП неудобен.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 2)
Ответ на: комментарий от den73

Так что (если чуть пофантазировать) пока макаки пишут на Го перекладывание json-ов, в том же гугле в углу сидят полтора элитария и ковыряются в движке поиска.

Либо сидят на поддержке сервиса поиска билетов, который Гугл давно у кого-то купил. Как помрут - Гугл этот сервис и закроет, не впервой :)

А стайлгайд - последствие бюрократии в любой большой компании. Если используется язык - должен быть и стайлгайд.

Elidee
()
Ответ на: комментарий от den73

Так что (если чуть пофантазировать) пока макаки пишут на Го

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

slew
()
Ответ на: комментарий от den73

В перге тоже нет ничего, кроме cell-ячеек.

Потому что в самом Lisp внутри нет ничего кроме cell-ячеек.

Ну и я не знаю, что это за мифический такой компьютер.

IBM 704. Lisp сделали чтобы на нем расчеты проводить, cons изначально вообще машинные слова создавал из 4х аргументов-кусков регистра для этой машины.

Lisp оптимизирован под работу с 2мя 15-битными словами на 36-битной архитектурe. Под этот же компьютер создали и Fortran трахнув Basic Algol-ом, просто Lisp использовал подход «все список», а Fortrant - «все символ» (для удобства ввода с перфокарт).

Со временем фортран менялся стараясь отвечать вызовы современности - добавлялись новые функции, легаси объявлялось устаревшим и тд. А Лисп - застыл в развитии (я про CL, а не Scheme или Closure).

Архитектурную необходимость работы с cell-ячейками объявили выразительностью, метапрограмимрованием и просто перенесли на уровень выше и теперь неокрепшие умом Лисперы (я сейчас не про Вас, а про автора этой темы) скобачуют в конструкциях оптимизированных под 36 бит на 32/64 битных архитектурах и очень удивляются почему Lisp не имеет мировой популярности в современном мире.

Obezyan
()
Ответ на: комментарий от Obezyan

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

А Лисп - застыл в развитии

Да, даже Кобол развивается.

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от alysnix

конструкция называется, и по смыслу является - «декларацией переменной».

декларация переменной обязательно включает имя переменной, тип (явный или который может быть вычислен по выражению инициализации) и выражение инициализации.

Ты это написал так, как будто это доказывает, что имя переменной лучше писать слева. Хотя по моему не доказывает.

куда проще читать декларацию

Куда проще объявить тип отдельно.

И вот по мне вот такая конструкция выглядит кринжово:

i: int = 5;
i: auto = 5

или так что-ли:

i = 5 : int;
i = 5 : auto;

???

Херотень одним словом.

rumgot ★★★★★
()
Последнее исправление: rumgot (всего исправлений: 1)
Ответ на: комментарий от den73

Так что (если чуть пофантазировать) пока макаки пишут на Го перекладывание json-ов, в том же гугле в углу сидят полтора элитария и ковыряются в движке поиска.

А еще в Google-овских стайлгайдах есть гайд для Vim script. Нужно еще и из этого сделать далеко идущие выводы.

eao197 ★★★★★
()
Ответ на: комментарий от den73

Из этого никак не следует, что нужно именно 6 скобок.

Это было нужно чтобы IBM 704 понимал что от него хотят в терминах списков.

Главное преимущество Lisp является его же главной проблемой: все является списком, управляющие конструкция языка могут быть данными и наоборот, даже когда Вы пишите

(list 1 2 3)

Lisp на самом деле использует запись списками

(cons 1 (cons 2 (cons 3 nil)))

И так во всем все «сложнее» car,cdr и cons. Ограничение архитектуры IBM 704. А скобочки это просто удобный символ тк на клавиатуре были отдельные кнопки со скобочками, не так как сейчас через shift на 0 и 9. Были бы отдельно фигурные скобки на клавиатуре вместо круглых, писали бы на них.

Obezyan
()
Ограничение на отправку комментариев: