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.

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

Человек-айпадоножка, ты ли это?

нет не я. вы обознались

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

как насчёт сделать аналогичный наброс про Rust?

Вот она во всей красе, нонешняя растомолодёжь. Даже набросить сами не могут, дедушку просить приходится %)

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

Это макрос. Это не конструкция языка, еще раз. Макрос. У макроса свой синтаксис, вот и всё.

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

Нет, разобраться можно, конечно. Наверное. Но…


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

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

В коммон лиспе же элементарная вещь может оказаться обмазанной десятью слоями макросов с именами одно другого загадочнее

камон лисп коварен!


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

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

Зато там методы вызываются через Obj.method(), а не (method Obj)!

У правосторонних арабов ещё интереснее вызовы будут:

                              ()dohtem.jbO
                              (jbO dohtem)

Имхо что совой об пень, что пнем об сову :)

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

Ноуп. У орабов так будет: (كائن الطريقة). И, кстати, симпатишно выходит.

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

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

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

lovesan ★★
() автор топика

В тему обсуждения, раз уж знатоки Lisp, Go и других языков здесь:

  1. Для CL есть Emacs,Vim, LispWorks +REPL в качестве IDE. А для Go что будет лучше использовать? В целом где здесь выигрыш в эффективности каждодневной работы, у каких языков(Java, C++, etc)?

  2. Интересно с точки зрения модной контейнеризации (Docker и иже с ним), где проще будет и быстрее образ выкатить? Где размер образа будет минимальный по размеру?

  3. Что по затратам на з/п и инфраструктуру за месяц/год/5 лет? Насколько эффективно будет тратиться бюджет при использовании различных технологий? (Насколько бы не была бы технология крута бизнес прежде всего считает деньги).

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

А для Go что будет лучше использовать?

Emacs.

где проще будет и быстрее образ выкатить?

Без разницы.

бизнес прежде всего считает деньги

Не заметил.

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

бизнес прежде всего считает деньги

Не заметил.

Везёт же вам… Да тут все интересно, кому водопад денег, а кому бюджеты считай. Интересует точка зрения, если самому бизнес поднимать и расходы считать.

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

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

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

А я в энетрпрайзе сижу. У нас тут своя атмосфера. Денег не считает никто. Оценить влияние производительности труда отдельного сотрудника, равно как и целого отдела, на конечный результат не представляется возможным. Как всё это работает и откуда берётся водопад бабла, которое мы усердно профукиваем я тоже не знаю.

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

В целом где здесь выигрыш в эффективности каждодневной работы, у каких языков(Java, C++, etc)?

CL выигрывает примерно у всего, и не только из-за фич, но и из-за интерактивной разработки и отладки, равной которой нигде нет. Кроме отдельных специфических ниш(embedded на сильно маломощных системах, как пример; отчасти мобильная разработка - коммерческие реализации в это умеют но с некоторыми ограничениями)

Интересно с точки зрения модной контейнеризации (Docker и иже с ним), где проще будет и быстрее образ выкатить? Где размер образа будет минимальный по размеру?

Разницы нет. Основные реализации CL(SBCL, ECL, разные другие, коммерческие всякие) умеют собираться в один бинарник. Некоторые реализации умеют его еще и сжимать и/или удалять ненужное из него.

В контейнер это все запихивается легко и просто, соответственно.

Что по затратам на з/п и инфраструктуру за месяц/год/5 лет? Насколько эффективно будет тратиться бюджет при использовании различных технологий?

Инфраструктура - зависит от объема данных, и тут больше вопросы не к приложению, а к БД, сети и всему такому. Современные реализации CL - оптимизирующие компиляторы, генерирующие машинный код, который по производительности будет на уровне жабы-дотнета, причем памяти будет есть скорее всего меньше, и основные реализации позволяют затюнить код до уровня ассемблера.

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

По ЗП лисп будет выше среднего, если допустим судить по США(или вон я недавно видел вакансию в южной корее, правда не успел туда собеситься). Но тут как грится, «если вы думаете что нанять профессионала это дорого, вы еще не нанимали любителей».

На популярных технологиях - особенно на тех, которые нацелены на идиотов(PHP, Python, Golang и подобные) - заколебешься искать вменяемых людей, и стоить они будут точно так же дорого как лисперы. Дешевый шлак нанимать - себе дороже.

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

Небольшая команда профессионалов это и дешевле и качественней, в итоге. Хороший инструмент(=лисп) идет плюсом, т.к. уменьшает TTM, и повышает качество продукта.

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

В лиспе таких this может быть больше одного, вот и всё.

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

Правда, чем кудрявее диспетчеризация, тем она медленнее, ничего не попишешь.

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

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

Для паттерн-матчинга в CL есть куча библиотек, необязательно для этого использовать обобщенные функции

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

Накину таки на вентилятор:

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

Тоже мне - достижение. Ага. Вот с ними и соревнуйтесь. А плюсы - оставьте их уже людям что «котиков готовить умеют»…

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

из-за интерактивной разработки и отладки, равной которой нигде нет.

Кроме embedded это еще очень хорошо работает в сложной многопоточке, объемных вычислениях, в нагруженной распределенщине и реальном времени.

Небольшая команда профессионалов это и дешевле и качественней, в итоге.

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

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

Даже не стал читать очередное нудное дерьмо от зануды. Говоришь — ты нуднейший и скучнейший персонаж, а в ответ что? То же самое нуденье. Старую собаку не научишь новым трюкам, но чтоб всё было настолько печально… Хотя кого я обманываю, иного я и не ожидал 😊

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

т.к. аргументация вида «да ты идиот» может работать разве что на LOR-е

Сильно подозреваю что другой мы не дождёмся. Мне бы, например, было очень интересно услышать аргументы «а вот мы запилили X, что при затратах Y принесло нам Z денюжков». Только вот - не увидим мы такого. Все будут только шашками размахивать да слюнкой брызгать… Профессионалы, блин… Не мечите Вы бисер, не стОит оно того.

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

Утверждать плох или хорош Go не имею права (так как «не в теме»).

Поэтому «только чай».

Можно ли с использованием Go разработать хорошую архитектуру проекта?

Какие типы алгоритмов на Go сложно реализовать (работа с memory, ...) и будут ли они эффективны?

Это для начала ...

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

Не мечите Вы бисер, не стОит оно того.

Уже где-то выше говорил, что участие в этом сраче для меня отдохновение от текущих проблем, развлекаюсь я так :)

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

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

В очередной раз привлеку внимание общественности к типичной ситуации в данной теме: там, где я обсуждаю аргументы (или подобие оных) собеседников, Virtuos86 и lovesan обсуждают мою занудность, интеллектуальное развитие и образование, позволяя себе приписывать мне вещи, которые я не говорил, не беря при этом на себя труда хоть как-то подтвердить наветы в мой адрес. Характерным примером является заявление lovesan-а о том, что я якобы критиковал Lisp, ведь lovesan так и не сумел привести ни одной цитаты, которая бы доказала его слова.

И это не единственный пример. К сожалению, несколько ограничен во времени, поэтому не могу развернуть мысль.

Однако, позволю себе добавить еще и вот что: Virtuos86 просил, чтобы я больше не нудел в его сторону, и даже не смотря на то, что я предложил ему делать того же самого в мой адрес, он все равно не внял (что и неудивительно с учетом его предыдущего поведения), и все равно пытается донести до меня какой же я человек. Хотя в рамках данной темы хотелось бы обсуждать языки программирования и их применимость в тех или иных условиях.

PS. Все написанное выше является тестом на сообразительность: можно ли найти данном тексте, специально выдержанном в определенном стиле, какие-либо следы иронии и скарказма по поводу «нуднейший и скучнейший» или же все это случайное стечение обстоятельств.

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

отдохновение от текущих проблем, развлекаюсь я так :)

Как я Вас понимаю, правда ;)

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

Есть «лекарство»: попросите disasm, а ещё лучше - понимание во что та или иная конструкция разворачивается…

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

Есть «лекарство»: попросите disasm, а ещё лучше - понимание во что та или иная конструкция разворачивается…

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

Как-то так.

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

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

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

Не смог удержаться:

мы с грехом пополам переварили куцый огрызок от множественной диспетчеризации и костыли

Из классики:

«- Что, сынку, помогли тебе твои ляхи?»

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

я просто посмотрел CLOS, и загрустил, вспоминая старые добрые С++ классы. CLOS оказался классиечкой подделкой под ООП, постоянно втекаемой во многие недоязычки, где ради «гибкости» определения методов вынесены за декларацию класса, отчего класс разваливается и никаких утверждений сделать о классе нельзя.

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

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

тогда вопрос - зачем мы определяли этот тип данных (мышка), если оказалось что она ведет себя неожиданно в разных контекстах?

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

это грустно.

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

зачем мы определяли этот тип данных (мышка), если оказалось что она ведет себя неожиданно в разных контекстах?

Ты и сам ведь знаешь, что есть два подхода к определению классов и ООП: номинальный (мышка — это то, что я назвал мышкой, у неё внутри то, что я скажу и делает она то, что я ей скажу), и структурный — мышка это то, что ведёт себя как мышка, а что у неё внутри и что она такое на самом деле — это неважно.

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

Если мышка ест людей, то наш мир проклят и заслуживает гибели в праведном огне vs если мышка ест людей, то это не мышка %)

Примеры номинального подхода — жаба, шарп, паскаль; примеры структурного — тайпскрипт, го, лиспы.

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

Я тоже загрустил. А почему это произошло, лучше расскажут Лавсан или ugoday, если захотят прокомментировать твои слова.

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

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

Конечно, вы душнейший и зануднейший персонаж в этом чатике. Доказывать тут что? Кто этого не видит, пускай протрет глаза.

и даже не смотря на то, что я предложил ему делать того же самого в мой адрес

Так я скипаю всё, что вы пишете, так что неудивительно, что я пропустил. Кроме того, соглашения такого рода я не заключаю. Давайте, я уже открою страшную тайну всем, кто это прочтет: заигнорьте Евгения в BL и попробуйте почитать этот тред — на некоторых страницах у меня один-два комментария отображаются! 😆 Приходится, скрепя сердце, включать отображение скрытых комментариев. А тут Евгений во все поля, разумеется, нудит, причем личность оппонента ему до фонаря, ибо он примерно одно и то же исполняет всегда. Ну Семен Семеныч…

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

Конечно, вы душнейший и зануднейший персонаж в этом чатике.

А еще я смею требовать пруфов! Неслыханная дерзость для LOR-а, ну невозможно же такое терпеть.

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

Какие типы алгоритмов на Go сложно реализовать (работа с memory, ...) и будут ли они эффективны?

Вообщем с memory non problem работать, но насколько эффективен код?

И главное - «Пригоден ли Go для разработки эффективного API и сколько зависимостей тянет обычный алгоритм?»

У каждого ЯП имеется своя экосистема и есть ли профит от использования API, разработанного иным ЯП (конечно речь не о скриптовых ЯП)?

Сам себе отвечу.
Возможно, если API разработано профи.

https://dev.to/jpoly1219/trees-in-go-14ff Trees in Go

https://ieftimov.com/posts/golang-datastructures-trees/ Golang Datastructures: Trees

https://codertime.ru/blog-ru/struktury-dannyh-i-algoritmy-v-go-2-razvitie-nav... Развитие навыков работы с Go с помощью деревьев

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 6)

Ребята, не переходите на личности и всё будет ok!

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

Я и жалею, распространяю полезные знания. Книга написана простым и понятным английским языком, не ландавшиц какой. Это всё для вашего же блага!

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

Я не могу ответить, потому что не понимаю проблем оппонента. Ну, сложно мне поставить себя на место человека, для которого Obj.method() это «настоящее ООП», а (method Obj) — «фигня какая-то». Лично мне очевидно, что множественная диспетчеризация — это простая концепция, которая автоматически приходит в голову после знакомства с одиночной. Некоторым, вот, не приходит. И что делать? Аналогично, мне очевидно, что вот это концептуально сложнее (и вообще дикий изврат и попытка почесать правой ногой левое ухо). А кто все паттерны зазубрил наизусть, у того никаких сложностей и отторжения.

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

я просто посмотрел CLOS, и загрустил, вспоминая старые добрые С++ классы. CLOS оказался классиечкой подделкой под ООП, постоянно втекаемой во многие недоязычки, где ради «гибкости» определения методов вынесены за декларацию класса, отчего класс разваливается и никаких утверждений сделать о классе нельзя.

Я тебе щас взорву мозг.

В C++ (как и практически во всех языках с симуловском ООП), методы на самом деле ТОЖЕ «вынесены» за классы. И на самом деле являются просто функциями, которые первым аргументом принимают объект класса. Особенно это наглядно видно в Python, но давай рассмотрим C++.

Например, если мы скомпилируем(g++ -c hello.cxx) такой файл:

#include <string>

class Foo
{
public:
    void Hello(const char* who);
};

int main(void)
{
    Foo foo;
    foo.Hello("World");
    return 0;
}

И натравим на полученный объектник nm, то мы найдем там символ _ZN3Foo5HelloEPKc

Что это такое? Это символ, который указывает на функцию Foo::Hello(char const*), которая должна быть определена в другом объектнике. (вот тут можно убедиться в этом: http://demangler.com/)

Это просто внешняя функция от двух аргументов. Типы аргументов: Foo* и std::string

Чтобы в этом убедиться, таки определим эту функцию во внешнем модуле, но уже на сишечке(gcc -c impl.c):

#include <stdio.h>

void _ZN3Foo5HelloEPKc(void* this, const char* who)
{
    printf("Hello, %s!\n", who);
}

Теперь слинкуем и проверим:

lovesan@ubuntu:~$ g++ -o hello hello.o impl.o
lovesan@ubuntu:~$ ./hello
Hello, World!

Исключением, отчасти, является, например, дотнет. Но методы там точно так же это просто функции, которые принимают первым аргументом this. Просто они сгруппированы в классы.

То есть всё твое ООП это, получается, синтаксический сахар…

…Который на лиспе делается макросами, так как симуловское ООП это подмножество CLOS.

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

Давай попробуем с ее помощью определить аналогичный вышеописанному класс:

(define-dotnet-callable-class foo ()
  (:defmethod hello :void ((who :string))
    (format t "Hello, ~a" who)))

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

CL-USER> (defvar *foo* (make-instance 'foo))
*FOO*
CL-USER> (hello *foo* "World")
Hello, World

А теперь, внимание, финт ушами:

(named-readtables:in-readtable bike-syntax)

И вызываем его как в «обычном» ООП (синтаксис становится идентичен Objective-C):

CL-USER> [*foo* Hello "World!"]
Hello, World!

Что же такое hello? Да это просто та же самая функция от двух аргументов.

CL-USER> (describe (function hello))
#<STANDARD-GENERIC-FUNCTION COMMON-LISP-USER::HELLO (1)>
  [generic-function]

Lambda-list: (THIS WHO)
Argument precedence order: (THIS WHO)
Derived type: (FUNCTION (T T) *)
Method-combination: STANDARD
Methods:
  (HELLO (FOO T))

Slots with :INSTANCE allocation:
  SOURCE                         = NIL
  PLIST                          = NIL
  %DOCUMENTATION                 = NIL
  INITIAL-METHODS                = NIL
  ENCAPSULATIONS                 = NIL
  NAME                           = HELLO
  METHODS                        = (#<STANDARD-METHOD COMMON-LISP-USER::HELLO (FOO T) {100866BE33}>)
  METHOD-CLASS                   = #<STANDARD-CLASS COMMON-LISP:STANDARD-METHOD>
  %METHOD-COMBINATION            = #<SB-PCL::STANDARD-METHOD-COMBINATION STANDARD () {100025CDB3}>
  DECLARATIONS                   = NIL
  ARG-INFO                       = #S(SB-PCL::ARG-INFO..
  DFUN-STATE                     = (#<FUNCTION (LAMBDA (SB-PCL::.ARG0. SB-PCL::.ARG1.)..
  %LOCK                          = #<SB-THREAD:MUTEX "GF lock" free owner=0>

Да, кстати обобщенные функции CLOS, как видно это тоже такие объекты CLOS. В Common Lisp вообще у всего есть класс, и всё является объектом, даже небо и даже Аллах.

также я в CLOS не нашел(может плохо искал) обьявлений приватности

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

протектности, финальности

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

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

В CLOS никакого «duck typing», в отличие от питонов и Golang, из коробки нет, и вообще это убогий подход.

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

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

Мне вот довольно очевидно, что от ООП в плюсах куцый огрызок. ООП всё про про построение динамических объектных систем. Построение это требует рантайм-рефлексии и метаобъектного протокола. Ничего подобного в плюсах нет и не будет. Можно навертеть костылями сверху, как делает Qt. Да даже на си можно писать COM. Просто к языку это уже не имеет отношения, и вписывается в него весьма слабо.

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

Зато, блин, методы рядом записаны. Достижение.

Уж шла бы речь хотя бы про жабу-дотнет. Там и точки на привычном месте, и рефлексия есть. Объектные системы уже куда мощнее и естественней получаются.

Впрочем, тут спор сведется к терминологии «что такое ООП». Но можно же хотя бы учитывать, что трактовки бывают разные. И они бывают глубже, чем «инкапсуляция и методы через точку».

А плюсы сильны совсем не этим. И не зря в std ООП почти нет, а в новых стандартах развивают совсем другие направления.

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

РЕСПЕКТ C++ за то, что он предоставляет возможность разработки системного API.

В частности, возможна разработка API для работы с объектами без использования class.

Вообщем-то ООП C++, это всего лишь один из методов (так что-ли?) работы с объектами (и вовсе не панацея).

Пост не о том, что C++ плох.

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

ООП всё про про построение динамических объектных систем.

А что в статически типизированных C++ и Eiffel (это два статически типизированных языка, в которых, имхо, самая продвинутая поддержка ООП, включая множественное наследование) мешает «построению динамических объектных систем»?

Вопрос (возможно душный) без сарказма. Просто вообще не понимаю о чем идет речь (и, возможно, не я один).

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

CL «в среднем» на уровне жабы-дотнета.

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

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

А что в статически типизированных C++ и Eiffel (это два статически типизированных языка, в которых, имхо, самая продвинутая поддержка ООП, включая множественное наследование) мешает «построению динамических объектных систем»?

Compile-time vs Run-time имеется в виду я так понимаю. Мне показалась интересная реализация в Objective-C: там можно ловить «чужие» сообщения и обрабатывать их на лету, к примеру.

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

Мне показалась интересная реализация в Objective-C: там можно ловить «чужие» сообщения и обрабатывать их на лету, к примеру.

Если я правильно помню, то Objective-C в ОО-шной части динамически типизированый вроде?

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

Надо сказать что плюсы «в среднем» на уровне «мало что сегфолтится и течет памятью, так еще и тормозит как питон», потому что IRL никто не пишет на плюсах так как в бенчмарках, а засирают все умными указателями, indirect ссылками(начиная с Pimpl или там std::vector), и так далее.

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

Если я правильно помню, то Objective-C в ОО-шной части динамически типизированый вроде?

ООП как в Smalltalk реализовано. По сути можно конструировать объекты как захочешь если понадобится или уже к существующим экземплярам добавить свойства.

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