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.

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

И былые заслуги Common Lisp-а здесь вообще ни при чем.

Common Lisp от 1989 с поправками в 90-х это пик Computer Science Запада(цивилизации) для динамического языка. И «динамичность» включает не только типизацию. Опциональная статическая типизация в стандарте как декларации для компилятора, а не адаптация computer science для математиков.

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

Оторвался от дел, чтобы сообщить вам, что вы очередной илитарий от лишпа. Сейчас вам разъяснят более подробно, что сие означает 🙂.

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

lovesan победил.

«Шас спою».
Качну Common Lisp и стану НАСТОЯЩИМ ЛИСПЕРОМ.

Пословицы многие не верны.
Правильно так.

"Старикам везде у нас дорога, молодым везде у нас почёт".

В маршрутках пока говорят «молодой человек» и это вообщем-то радует.

lovesan подбрось свои любимые ссылочки по Common Lisp.

Надеюсь, что таки разработаю ЯП - «ТЗ» (техническое задание).
Ну вы поняли о чём речь.
Кстати «как» - знаю, осталось за малым - сделать.

-------------------------------------------------------------------
https://github.ink/sbcl/sbcl
https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/
https://github.com/ieure/clip Common Lisp на практике
https://common-lisp.net/downloads (и on line)
https://portacle.github.io/

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

@lovesan подбрось свои любимые ссылочки по Common Lisp.

«Practical Common Lisp». Видите, говорят ЯП далёкий от реальности, а вы видели какой-нибудь «Practical C++», например? Впрочем, возможно и видели, мог кто-то написать.

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

Шутка

Так это, чтобы «совесть чиста была».

https://github.com/portacle/portacle/releases/download/1.4/lin-portacle.tar.xz

https://github.com/portacle/portacle/releases/download/1.4/mac-portacle.dmg

https://github.com/portacle/portacle/releases/download/1.4/win-portacle.exe

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

Видите, говорят ЯП далёкий от реальности, а вы видели какой-нибудь «Practical C++»,

Использую C++ лишь для разработки API, а практическое использование - например в 1С 8.3 (хотя конечно можно и в Python, ...).

Вдохновляет, когда в 1С в штатном языке программирования переменные используются не предоставляемые 1С, а свои ..., но внешне код не отличишь от 1С (да и объекты свои).

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

Как я и предполагал. Судя по времени выхода первой редакции, совпадающее примерно с выходом PCL (а может, лисповская книженция была вдохновлена ею? 🙂) многих авторов в то время практическое применение языков программирования заботило. Однако, славы за данным трудом я не припомню — ее кто-нибудь массово из плюсовиков читал, в отличие от настольной книги лисперов?

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

Аналогично с Common Lisp (или Eiffel, или Ada, или еще что-то). Его роль, продвинутость и значимость в 1990-х не должны играть решающей роли при выборе в качестве инструмента в 2020-х.

В 90-х выбирали между 8 и 16 бит. Компания Microsoft внедряла концепт графического интерфейса вместо кажется Norton Commander в терминале(сам GUI как концепт уже был в 80-х у некоторых компаний). Потом лет 10 были споры о нормальности automatic GC для проектов. Когда Java стали внедрять в 2000-х, Microsoft сразу создала клон с вариациями. До ~2005 университеты за гранты и без изучали как оптимизировать Java.

Из «нового» в 2020 только Goroutines в Go с максимальной производительностью. Единственное чего нет в Common Lisp. Но какие-то «green threads» есть почти у всего. Но ни у кого нет полностью интерактивной разработки где гранулярность компиляции одна фукция в проектах любого размера. Даже обработка исключений интерактивна.

«Былые заслуги».

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

краснокнижных лисперов так мало, что даже если они читали «священную книгу» все, все равно их будет меньше, чем плюсовиков, прочитавших любую книгу по с++.

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

дешевый приемчик 😁
не забываем, что количество не означает качество: лиспер шутя сделал тред месяца, а чего добились плюсовики на ЛОР? стыдоба да и только 😊

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

В 90-х выбирали между 8 и 16 бит.

Если говорить об IBM PC совместимых компьютерах, то выбора уже особо и не было, шел переход с 16- на 32-бит. Intel представил свой первый 32-х битный процессор еще в 1985-ом.

Компания Microsoft внедряла концепт графического интерфейса вместо кажется Norton Commander в терминале(сам GUI как концепт уже был в 80-х у некоторых компаний).

Windows 1.0 вышел в 1985-ом. Windows 3.0 (собственно, с этой версии Windows и начался) – в 1990-ом.

Windows NT 3.1 – в 1993-ем. OS/2 2.1 – в 1993-ем.

NT и OS/2 2 – это уже 32-х битовые ОС.

Потом лет 10 были споры о нормальности automatic GC для проектов.

Споров не было. VB был доминирующим в своей нише. Были реализации SmallTalk и Lisp-ов от различных производителей. Был Eiffel.

Вопрос был не в наличии GC, вопрос был в железе с достаточном количеством памяти, чтобы программы с GC не тормозили. Как раз к концу 1990-х эта проблема была закрыта.

Когда Java стали внедрять в 2000-х

Java начали внедрять во второй половине 1990-х. В начале 2000-х Java уже вполне себе доминировала в нише корпоративного ПО и начала вытеснять C++.

Итого: вы с датами лет на 10 так ошиблись.

Ну и все еще непонятно в чем смысл ваших комментариев про «былые заслуги»? Вы думаете, что их у Common Lisp кто-то пытается отобрать?

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

На сайты *.ru попадаю случайно раз в несколько лет. ad hominem не волнует вообще.

Интересен Go, снова. Композиция вместо наследования и как это влияет на моделирование симуляций в коде. Композиция почти нигде не описывается как основной инструмент в отличии от class-based, или Simula-like.

Массивы и вообще контейнеры в Go инварианты, нельзя привести массив типов к массиву супер-типов потому что концепта наследования нет. Только композиция. Структуры встраиваются в другие структуры inline, не указатель(но это можно сделать явно). Нет рекомендаций как - «выберите любой верхний класс из иерархии и наследуйте для своих целей». В Go берешь любую структуру с методами и встраиваешь в свою композицией - сочетание любых несвязанных типов в производный.

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

имеет смысл обсудить преимущества парусного торгового флота

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

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

Как обычно, лайк, подписка, пишите в комментариях свои соответствия.

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

Итого: вы с датами лет на 10 так ошиблись.

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

Ну и все еще непонятно в чем смысл ваших комментариев про «былые заслуги»?

Этот термин не применим к Common Lisp.

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

Нет. Лисп это раллийный автомобиль WRC, в котором от обычного автомобиля только руль и колеса. Если там что-то сломается, в ближайшей автомастерской вам не помогут, и даже не в ближайшей — только в той, где его создали или похожей. В отличие от обычного авто. Другое дело, что люди жалуются, что раньше обычное авто можно было починить, имея в голове знания устройства примитивного ДВС и умея пользоваться рожковым ключом с отверткой, а сейчас понакрутили всего, кроме как «резину» поменять и «незамерзайку» долить с антифризом лучше и не соваться.

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

лиспер шутя сделал тред месяца,

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

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

Создатели Python и Ruby никогда не задумывали эти языки для того в каком виде их стали использовать, другие.

Оба опытные программисты C, для них не существует проблемы производительности.

Python вырос из учебного языка ABC для обучения в Нидерландах. Показывать стекфреймы идеально соответствует назначению языка. Guido van Rossum отвечая на вопросы говорит что пишет только скрипты и автоматизацию на Python, логично. Для этого управление памятью с reference counting полностью достаточно и красиво реализовано.

Yukihiro Matsumoto в университете изучал создание компиляторов, потому создание Ruby для работы с «C» было реализуемой задачей для него.

Когда их языки становились популярными, они стали скрывать что знают Lisp. Иначе возник бы вопрос чем эти языки лучше интерпретаторa Lisp который не создал бы никаких проблем с версиями синтаксиса. Matsumoto использовал Emacs до создания Ruby, и использует Emacs до сих пор. Rossum так же пользуется Emacs.

EDIT. Экскурс:

Относительно фундаментальное как исследователь создал John Ousterhout, язык TCL по контракту с Sun. До того как Sun наняла бывшего соавтора Emacs(Gosling) для создания концепции языка названного позже Java. TCL это универсальный синтаксис по простоте аналогичный Lisp. Как исследователь в университетах Ousterhout выдвинул теорию названую его именем «Ousterhout’s dichotomy». Он предложил смотреть на программирование как сочетание скриптового языка и статического языка реализации. В TCL встроены events как потом скопировали в Javascript по заказу в Netscape. В TCL можно писать встроенный код C который передаётся компилятору.

Stallman объявил TCL ересью и сказал что это не нужно когда есть Lisp. И был во много прав. Признали подход дихотомии Оустерхута, хотя многие отрицали её значимость. В итоге за пределами GNU отказались и от Lisp и от дихотомии - стали использовать Python как язык сам в себе. Со временем появились вопросы на stackverflow что быстрее, Python или C.

tp_for_my_bunghole
()
Последнее исправление: tp_for_my_bunghole (всего исправлений: 3)
Ответ на: комментарий от Virtuos86

«Practical Common Lisp». Видите, говорят ЯП далёкий от реальности, а вы видели какой-нибудь «Practical C++», например?

Ещё вспомнился «Practical OCaml», и я это даже читал. Кстати, о всякой лютой маргинальщине обычно есть очень клёвые книги. А вот у попсы с этим плохо почему-то.

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

чтобы понять — код это, данные или ещё что.

Ну, здрасьте, у нас тут лисп. Мы сами не знаем код это или данные.

Одно другому не мешает. Списки обычно используют для кода — это не мешает их использовать как структуру данных (когда надо, скажем, стек на коленке сварганить). Векторы и мапы хоть и данные, но ими можно описать код для какого-то domain-specific интерпретатора — и так часто и делают. Тут вопрос в удобстве восприятия, а не однозначной категоризации раз и навсегда.

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

Иначе возник бы вопрос чем эти языки лучше интерпретаторa Lisp который не создал бы никаких проблем с версиями синтаксиса.

Этот вопрос стоит, на самом деле до сих пор, и касается не только скриптовых языков, но и вообще например .NET/C# или JVM/Java - зачем все это нужно если есть CL - решительно непонятно. То есть, зачем это нужно корпорациям, может и понятно - подсадить на свои продукты итд, но зачем это нужно среднестатистическому разработчику, и зачем за это агитировать - непонятно вообще.

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

Clojure это не Lisp.

Lisp в первую очередь это Машина:

Весь код программы Lisp находится в памяти. Гранулярность компиляции одна функция - это значит что наводишь курсор на код и нажимаешь eval. Эта функция сразу помещается в исполняемую память. Для завершения сессии программирования весь образ программы в памяти сохраняется на диск(функция как save-lisp-and-die). Перед сохранением откатывается текущий стэк. Запуск этой программы в следующий раз означает загрузку всего образа в память и указание с какой функции начать исполнение. Входные функции могут быть разные.

Для Lisp нет дебаггеров. Сам Lisp это дебаггер. Исключения(exceptions) могут быть интерактивные. Когда происходит ошибка в runtime, откатывается стек до обработчика и показывает командную строку в терминале(REPL) предлагая варианты перезапуска с этой точки. Это может быть мощным инструментом для создания игр например.

Разработка с загруженным рабочим образом даёт возможность найти значение/определение абсолютно любого символа. Для динамических языков как Python чаще используют статический анализ(Jedi) кода для «go to definition», что для динамики просто приблизительная оценка.

Никакой обфускации кода(изменение имён), все символы в Lisp доступны всегда в рантайме. Не знаю как в Clojure, на VM Java.

Ни одна современная система кажется не предлагает ничего аналогичного. Guile Scheme это Lisp, но в Scheme ошиблись с тем что у них будет очень минималистичная реализация(«не так как в Common Lisp»). Теперь уже 7-й пересмотр стандарта Scheme, R7RS. A компиляция Guile из «C» makefile идёт вроде намного дольше чем SBCL.

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

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

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

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

Если говорить про обсуждаемый фрагмент кода на Лиспе

Не знающие концепты Common Lisp даже представить не могут что стоит за тем кодом. Показывание такого кода ничего не даст.

Design by contract, с проверкой условий до и после метода, или полная отмена в целом. В Eiffel скорее нет близко к такому уровню, хотя это считается одной из основных характеристик языка.

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

там по коду понятно, что указывается тип одного из аргументов. А в комментарии в коде это сказано напрямую 🙃.

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

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

Lisp в первую очередь это Машина:

Лисп это операционная система, по сути.

Тот же save-lisp-and-die это гибернация ОС. Condition System из CL == синхронные сигналы Unix, или же SEH из Windows, итд.

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

Clojure это не Lisp.

Если что-то плавает, как утка, и крякает, как утка — вероятно, это таки да утка %)

Весь код программы Lisp находится в памяти.

А у кложи где — в астрале?

Гранулярность компиляции одна функция

Одна форма, да. В кложе, насколько мне известно, так и есть.

весь образ программы в памяти сохраняется на диск

Вот тут да, похоже на заметное отличие. Даже АОТ-скомпилированная в байткод кложа вряд ли сможет продолжить выполнение с той же точки, где оно закончилось в прошлый раз. В некоторых случаях может быть полезно, но вообще это палка о двух концах — воспроизводимости можно не ждать с таким подходом. Что я там наэвалил в прошлый раз? Кто знает. Если перекомпилирую полностью с исходников — заработает? Б-г ведает.

Для Lisp нет дебаггеров. Сам Lisp это дебаггер.

Ну, собственно, CIDER использует запущенный процесс кложи в хвост и в гриву — для навигации по коду, для поиска документации, для дебага. Без репла это всё не работает.

предлагая варианты перезапуска с этой точки

Да, conditions/restarts в кложе нет — то ли ограничения платформы, то ли нежелание Рича заморачиваться, когда уже есть исключения, которые лучше, чем ничего. (Continuations туда же. И tail call elimination вручную.)

все символы в Lisp доступны всегда в рантайме

Таки да.

В общем и целом похоже на то, что кложа скорее лисп, чем не лисп — гомоиконность, макросы, всё как мы любим. Плюс эффективные неизменяемые структуры данных, человеческое concurrency, беспроблемный интероп с популярной платформой (несколькими платформами) с охреневающим охватом и огромными пользовательскими/девелоперскими сообществами.

Не просто лисп, а лисп с человеческим лицом %)

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

Программист в Lisp вообще не думает о синтаксисе. symbol после скобки даёт высокоуровневое представление. Как езда на велосипеде не требует постоянного осознания происходящего процесса, кроме того что вокруг.

Немец придумал режим wisp для Guile в котором вместо скобок отступы. Он популяризует это в качестве демонстрации. www.draketo.de/proj/with-guise-and-guile/wisp-tutorial.html

На самом деле когда программируешь в Lisp то есть keybinding «прыгнуть на начало текущей формы». Далее эту форму можно вырезать и переставить. Или закоментить целиком и лишние закрывающие скобки переносятся на новую строку после коммента для сохранения корректности кода. Или перемещения вверх по вложенности скобок. Или выделение всей формы(функции) просто прыгая на закрывающую скобку. Многое другое, и всё это в несколько нажатий клавиш. Вот это по настоящему создаёт «аппаратное ускорение».

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

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

Лисп это операционная система, по сути.

Название Maшина точнее. Это отсылка к Lisp Machine mainframes, которые действительно были собственной ОС. Но в стандарт не входит как организовать дисковые пространство с нуля, важнее принципы коммуникации с Машиной.

В Forth описывается как работает базовая организация диска на блоки. Но функции просто слова без параметров которые берут объекты из вершины стека и помещают туда результаты.

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

Программист в Lisp вообще не думает о синтаксисе.

А программист на кложе не думает о нём в два раза сильнее %)

прыгнуть на начало текущей формы

Structural editing огонь, постоянно пользуюсь.

В любом другом языке не сделаешь такую навигацию легко.

Ну Емакс пытается, но выходит так себе. Си-подобные поделия ориентированы на строки, а не на формы.

Джейсончики вот можно так шевелить, да.

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

Guile в котором вместо скобок отступы

Максимально проклято. Какой-то недохацкель без преимуществ хацкеля.

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

Да брось. Эти сказки, что лиспокод сложно читать. Что ж, видимо лисперы уберменши, раз это им не мешает. А может, не так и сложно или это ни на что не влияет вообще, а?

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

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

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

Состояние Rich Hickey оценивается в $18 млн.

Даже те кто программируют в самой Java я полностью одобряю если у них стабильная работа из года в год и можно вести образ жизни - пропагандисткий образ которой создали журналисты из Калифорнии пишущие о якобы нехватке программистов.

Но мне нравится Common Lisp и мутабельность, и то что не на Java VM. Вот Grammarly на Common Lisp, основная разработка велась из Киева.

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

Да, conditions/restarts в кложе нет — то ли ограничения платформы, то ли нежелание Рича заморачиваться, когда уже есть исключения, которые лучше, чем ничего. (Continuations туда же. И tail call elimination вручную.)

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

Не просто лисп, а лисп с человеческим лицом %)

Скорее жаба с человеческим лицом, если по факту говорить 🙂.

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

Эти сказки, что лиспокод сложно читать

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

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

это ни на что не влияет вообще

Удобство использования ещё как влияет на всё подряд. Что удобнее:

(def m {:id 1 :name "Joe"})

или

(defparameter *h* (make-hash-table))
(setf (gethash :id *h*) 1)
(setf (gethash :name *h*) "Joe")

А где проще понять, что тут речь идёт о мапе, даже не надевая очков? А? А?

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

Их, тру лисперов, кстати, поэтому от кложуры и бомбит, что там жабка под капотом

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

А как он тебе сделает рестарты, если в жабомашине в ее системе экзепшенов их нет?

В ABCL же как-то сделали, насколько я понимаю.

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

И часто ты руками коллекции набиваешь в коде? Не в хелловорлдах, а в рабочем коде. А работа с этими хэшами как выглядеть будет в кложе и в cl?

А? А?

Напиши макросню, которая спрячет бройлерплейт, стандартно.

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

А как он тебе сделает рестарты, если в жабомашине в ее системе экзепшенов их нет?

В ABCL же как-то сделали, насколько я понимаю.

Сами набыдлокодили? Эт надо уточнить. Наверное, та еще содомия в реализации, заставить жабомашину делать то, что она не умеет.

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

Напиши макросню, стандартно.

В итоге приход в новый проект начинается с зубрения тонн чужой нескучной макросни для самых элементарных вещей. А ведь умный дядька Ларри Уолл не зря предупреждал, что easy things should be easy*, и люди к тебе потянутся %)


* but hard things possible

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

Наверное, та еще содомия в реализации, заставить жабомашину делать то, что она не умеет.

Рич тоже знает толк в извращениях — прикрутил же к кложе горутины на макросах %)

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

часто ты руками коллекции набиваешь в коде?

Ну вот у меня конфиги в EDN, это ехал вектор через мап.

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

Эти сказки, что лиспокод сложно читать

Факт, что мало кто хочет это делать.

Факт, что почти никто не хочет смазывать такой интерес деньгами в общем и целом. И факт, что сейчас слишком многие тыжпрограммисты из-за меркантильных соображений, а не потому что в детстве на трубопаскале игры писали консольные. Какой им Лисп? 🙂☹️

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

нравится … мутабельность

😱

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

В конце концов, я же просто кот.

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