Ответы для темы «Почему Go это плохо....»

Да. В Scheme/Racket есть ещё обобщение лямбды под названием «продолжение».

Когда можно не только загнать в переменную любую функцию и выполнить, но и загнать в неё же безусловный переход.

«настоящий программист может программировать на Фортране на любом языке». Но в реальности язык определяет как минимум базовую абстракцию

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

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

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

Нужны знания разных смысловых полей, определяемых языками.

То есть, желательно изучить Си++ (ООП как пространство имён, итераторы, указатели), схему (лямбды, макросы, продолжения), CLOS (ООП как обобщённые функции), Smalltalk/Ruby/Erlang (ООП на сообщениях), Форт (слово на текущее состояние), Хаскель (ленивые чистые структуры).

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

В первый раз меня выкинуло из темы Лавсана когда тема набрала 1К постов. Мой скор был 48, ограничение стало в 50. Через 2 дня мой скор подрос до 50, я успел написать пару ответов и в этот момент тема перевалила за 2К постов и ограничивающий барьер поднялся до 1й звезды (скор 100). Ответ написал, а кнопку нажать уже не смог.

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

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

Вот в Racket можно всё.

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

В кложе выкрутились по-другому: quasiquote делает имена функций namespace-qualified:

`(+ 1 2)
;; => (clojure.core/+ 1 2)

в Racket можно всё

Некоторые языки гибче других, да.

Ты не офигел? Скор для того и нужен, чтобы ты НЕ отправлял комментарии.

Скор нужен, чтобы на него дрочить и точка. Больше он ничего внятного не отображает. Пишу это как пятизвёздочный регистрант.

То есть, желательно изучить Си++ (ООП как пространство имён, итераторы, указатели), схему (лямбды, макросы, продолжения), CLOS (ООП как обобщённые функции), Smalltalk/Ruby/Erlang (ООП на сообщениях), Форт (слово на текущее состояние), Хаскель (ленивые чистые структуры).

Желательно. И SICP тут будет этакий one book to rule them all, one book to find them, one book to bring them all and in the darkness bind them %)

Я из интереса начал читать SICP и мне понравилось, сложилось впечатление (наверняка ложное), что Scheme - довольно лёгкий для понимания язык. Но т.к. мне нужно изучать С++ - пока отложил его в сторону, на потом.

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

Вот в Racket можно всё.

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

Плюс, остаётся проблема с библиотеками. Используешь вот ты две библиотеки в проекте: одна в ООП стиле, другая в функциональном. И в итоге у тебя в коде получается говно.

В кложе выкрутились по-другому: quasiquote делает имена функций namespace-qualified:

В CL они тоже принадлежат пакету. Но labels или flet перекрывают именно ту функцию.

((labels (+ (a b) (- a b))
  ... ; здесь cl:+ переопределён
  )

Хотя в кложе let не перекрывает встроенный. Но можно имя явно написать:

=>(defmacro f [x] `(+ ~x 2))
#'user/f
=>(f 5)
7
=>(let [clojure.core/+ (fn [x y] (- x y))] (f 5))
3

SICP тут будет этакий one book to rule them all

Не будет. Ибо нет там ни указателей ни итераторов ни ООП ни даже ленивых чистых структур.

нет там ни указателей ни итераторов ни ООП ни даже ленивых чистых структур.

Этого в SICP и не должно быть. За деталями конкретной реализации надо идти в мануал конкретной реализации. Но за каждой конкретной реализацией стоят общие принципы, которые от реализации к реализации не меняются.

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

В Racket просто настраиваемая среда. Можно сравнить с .Net на котором есть и C# и F# и VB.Net и можно вызывать функции, написанные на одном языке, из другого.

Так и в Racket. Есть бестиповый основной, есть типизированный Typed Racket, есть lazy с ленивыми структурами, есть hackett с монадами, …

Задача Racket только в том, чтобы предоставить достаточно мощную семантику базовой системы. А то продолжения, например, невозможны ни в SBCL ни в JVM. Базовые операции просто не позволяют переписывать стек. В Racket же есть и продолжения и сборщик мусора с привязкой финализаторов на момент очистки и эфемероны (обобщение слабых ссылок) и хранители ресурсов (custodians) и много всякого.

Используешь вот ты две библиотеки в проекте: одна в ООП стиле, другая в функциональном.

А чем мешает одно другому? В CL и C++ эти два стиля тоже хорошо уживаются.

Это не детали реализации. Это именно базовые элементы мышления. Которые в SICP не упомянуты.

Но за каждой конкретной реализацией стоят общие принципы, которые от реализации к реализации не меняются.

В случае ООП есть общий принцип полиморфизм. Где про него в SICP хоть полслова.

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

Э-э-э, в первый раз слышу про эту систему ограничения на форуме. Я-то имел в виду самый заурядный барьер в виде ограничения комментирования для новорегов. Сочувствую, честно 🤷‍♂️. Я в свое время, видимо, шкворец отрастил тихой сапой, прежде чем в срачи влезать начал, поэтому не напоролся на такую досадную неприятность.

ни указателей ни итераторов ни ООП ни даже ленивых чистых структур.

Всё это (ну, кроме указателей) адепт SICP сможет написать сам (хотя ещё и не будет понимать зачем, но книжка и так толстая, нельзя требовать ещё и это).

В качестве шутки:

Почитал историю Лиспа и Scheme и вот что интересное заметил. Одну из фундаметнальных книг по лиспу написал Guy L Steele. Он же потом задизайнил Scheme убрав из лиспа все шереховатости и странности. После чего задизайнил Java которая стала очень популярной.

Из этого можно сделать вывод что Java - это высшая ступень эволюции Лиспа. :)

Из этого можно сделать вывод что Java - это высшая ступень эволюции Лиспа. :)

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

задизайнил Java которая стала очень популярной.

Из этого можно сделать вывод что Java - это высшая ступень эволюции Лиспа

Как бы, одно из другого следует. А если серьёзно, то сначала он сделал лисп для инженеров (Common Lisp), потом лисп для академиков (Scheme). Потом лисп для прикладных программистов (Java).

Замечу, что все три языка принципиально без UB и чем дальше, тем идеология надёжного контракта жёстче. Не зря лучшие парсеры XML на Java.

Указатели тоже может. Я в рамках Scheme делал.

Проблема в том, что на базе Scheme это очень сильно тормозит. Хоть ООП, хоть указатели.

Всё равно, что вместо нормальной арифметики давать числа Пеано.

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

А почему?

Потому что базовым кирпичиком является замыкание.

А в остальных языках сам указатель является базовым кирпичиком, потому что в терминах указателей и байтов работает процессор.

Это проблема для тех, кто на нём научится.

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

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

Вот он, видимо, как раз хотел оградить тему от комментариев уровня «гузкой говняный лишп». Но получилось, как всегда.

Ну и да, в тему приглашается @lovesan, видишь, как нехорошо получилось.

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

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

Можно ли создать процессор, который работает в терминах замыканий?

Не нужно C++ учить, нет в нем смысла

здесь cl:+ переопределён

А вот херушки. Будет package lock в нормальных реализациях.

Это не детали реализации. Это именно базовые элементы мышления

Указатели? Итераторы? Как страшно жыть %)

Это конкретные реализации некоторых общих идей. Указатель — это ссылка на объект (имя), итератор — это stateful object. Всё это в SICP обсуждается. И потоки значений там обсуждаются тоже.

Конкретные примеры — это, конечно, хорошо и наглядно, но за деревьями конкретных примеров было бы неплохо видеть лес объединяющих их принципов.

Ничего страшного, информацией об акробатических этюдах с битовыми массивами и указателями и так все интернеты завалены, обладая хорошей базой можно выучить эти ваши итераторы с ООП и паттернами. Вообще, сложно поверить в программиста, который ничего кроме SICP не читал и ничего кроме scheme не знает. А вот обратное случается сплошь и рядом: начнёт кто с Явы или С++ и всё, ничего кроме он уже воспринять не в состоянии.

А вот что он сам говорит про Java:

We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp.

Т.е. Java создавалась для того чтобы перетащить зашоренных крестовиков хотя бы на полпути к лиспу

Одна проблемка - Racket уже стал жирнее CL, вплотную подбирается к C++, и вобщем-то настолько же отвратителен, неудобен и непрактичен.

Про либы я вообще не говорю, их нет.

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

Да нет, они просто сделали там в комитете «язык для дураков» и «язык получше C++»

Проблема «языков для других, менее умных» вообще стоит в индустрии довольно остро - java, golang и прочее. Зачем всех будущих коллег априори считать за идиотов и делать для них какие-то специальные языки - не совсем понятно.

Указатель — это ссылка

И в С++?

начнёт кто с Явы или С++ и всё, ничего кроме он уже воспринять не в состоянии.

Вообще говоря, после долгой практики разработки на плюсах, в другие ЯП и в разработку на них как-то сходу влетаешь. Исключения разве что для всякой экзотерики вроде хаскеля. Я начинал с лишпа (модули для одного научного софта для физиков клепал). Заметно сложнее потом въезжал в Cи. С++ еще сложнее дался, причем не зубрежка стандарта/синтаксиса, а именно практика разработки на нем работающих и не падающих программ. Все остальные перлы с питонами и гошками после плюсов давались с полпинка. С++ вот сейчас самый сложный из всех практически используемых ЯП-ов. ЯП для илитариев, но только делом занятых илитариев. Умение писать на нем работающие без корок программы-это мастерство.

общий принцип полиморфизм. Где про него в SICP хоть полслова.

А если найду? %)

Все вы так говорите. А потом путаете умение ходить по граблям С++ с умением программировать вообще.

Дык, все сказано до нас

C++ — довольно таки примитивное, но монстровое поделие, полное исторически сложившихся нелепых нагромождений. Человек, который хорошо в нем ориентируется — это хорошее зубрилко, а не хороший программист. Умение героически преодолевать трудности, которые создает твой собственный инструмент, вместо того, чтобы решать непосредственно прикладную задачу, в современном мире ценится разве что только среди прыщавых сосок. Работодатель же это сомнительное умение не ценит, и совершенно справедливо.

это кто ж такое сказал?

Подозреваю, что Лавсан говорит с нами на языке @Antichrist -а

Теперь понятно почему на ней столько всего написано, в том числе и хорошего.

Нет, вот здесь описано как это работает