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.

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

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

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

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

Или же речь шла про сериализацию/десериализацию графа?

Да.

Ясное дело, в плюсах всё что нужно делают. И в си делают. Я говорю, что делается это в обход объектной системы C++, практически без ее участия.

Логика простая. Если есть объекты, то их бывает надо сохранить-восстановить. Вполне конкретная и жизненная задача. Где-то это может сделать метаобъектная система, или библиотечная функция, ее использующая. Без дополнительных приседаний. В плюсах - нет, не может. Хотя бы поэтому (это пример) она слабее.

Объекты есть, а инфраструктуры под них нет.

И самые-самые ООП-шные из них – самые тормознутые

Конечно, ООП медленное. Уже поэтому его нельзя сделать полноценным в плюсах. И это необязательно плохо.

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

Логика простая. Если есть объекты, то их бывает надо сохранить-> >восстановить. Вполне конкретная и жизненная задача. Где-то это >может сделать метаобъектная система, или библиотечная функция, ее >использующая. Без дополнительных приседаний. В плюсах - нет, не >может. Хотя бы поэтому (это пример) она слабее.

Объекты есть, а инфраструктуры под них нет.

В С++ этого нет (это да), а разработать API, реализующее всё выше вами сказанное вполне реально.

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

каким образом? Для общего случая в крестах это сделать нельзя.

это такие же сказки, как и сказки о том что якобы к C++ можно прикрутить GC

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

Немного полемики.

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

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

Сериализация есть, а API позволяющего работать с объектом любой сложности (в памяти и на диске) - нет.

Это же C++!
На нём всё можно реализовать.

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

а вы работаете с обьектами «любой сложности»?

вообще вот непонятно, что такое «обьект любой сложности» и чем он так сложен, и что там у вас стряслось.

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

Нет, не прога, а API, которое позволит работать с Excel, если ему предоставить метаданные.

В постах форумчан много категоричных утверждений, которые «не очень».

С++ прекрасно подходит для разработки системного API.

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

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

Ну давайте по паре-тройке моментов пройдемся.

Во-первых, сериализация-десериализация. Это же только в простых случаях вы увидите, что есть поле типа unsigned char и тупо запишите/прочитаете его. В более сложных случаях вам потребуется, например, проверять его значение на допустимость, чтобы не читать заведомый мусор. Проверять взаимные значения нескольких полей (типа если поле f1 имеет значение X, то поля f2 и f3 должны быть нулевыми). Ориентироваться на версионность данных (типа если на диске лежит значение объекта версии 1, то поля f4 там нет и оно должно получить значение Y). Иногда, ради экономии места, может потребоваться «ужимать» значение: если в поле f5 типа unsigned char диапазон актуальных значений от 0 до 12, то нет смысла записывать все 8 бит, можно ограничится 4-мя, а оставшиеся 4 бита задействовать под значение из поля f6 и т.д.

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

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

В-третьих, все таки непонятно что именно вы называете динамическими системами.

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

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

Так что ваш тезис на счет динамических систем все еще непонятен.

Где-то это может сделать метаобъектная система, или библиотечная функция, ее использующая. Без дополнительных приседаний. В плюсах - нет, не может. Хотя бы поэтому (это пример) она слабее.

Ну вот в Rust-е библиотека Serde делает что-то подобное без всяких метаобъектных систем.

Так что для достижения ваших локальных целей по примитивной сериализации/десериализации вполне достаточно иметь рефлексию (которую в C++ лет через 5-6 таки добавят). Насколько это будет сочетаться с ООП – хз. Но C++ не чисто ОО-язык изначально, так что пофиг по большому счету.

Конечно, ООП медленное.

Примеры C++ и Eiffel-я доказывают обратное.

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

каким образом? Для общего случая в крестах это сделать нельзя.

Дело вовсе не в C++.

Ваше утверждение будет верно лишь в том случае, если невозможно разработать алгоритмы, реализующие задачу.

Если можно, то и на C++ это возможно разработать.

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

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

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

Шутка

Наверное, но речь всё же о С++, который немножко отличается от brainfuck,

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

Ruby тормоз, потому как никто не парился с его произодительностью

ЕМНИП, там проблема в аналоге питоньего GIL, который ставит аналогичный крест на попытках разогнать и это корыто.

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

Технически любую систему можно реализовать на brainfuck

А фактически на это может не хватить индусов в Индии.

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

Проблема производительности бидонов и рубей не только в GIL, хотя он конечно играет роль.

Дело в том, что там через жопу написали основную реализацию, выставив наружу кишки в т.ч. например стекфреймов интерпретатора. Как это развидеть назад и убрать никто не понимает. Это же относится например к модели GC - изначально это черезжопно написанный подсчет ссылок, по типу «умных» указателей. И опять, это выставлено наружу(ну типа, del в бидоне). Ну и всем этим типа, пользуются. What has been seen in the public API cannot be unseen. Разве что делать Python 4, например. Правда, вопрос почему это не поправили в Python еще версии 3? Когда можно было ломать обратную совместимость? У меня на это только один ответ - идиоты сраные, потому что.

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

Да в принципе не великий секрет, что в таких запущенных случаях старый интерпретатор надо выкинуть и написать новый. Но людей, которые за это заплатят, уже не найдешь теперь. Они уже успели Go себе сделать, в питон больше не вляпаются. А пример прекрасного переписанного несовместимого со старым кодом ненужно перед глазами – Perl 6, ныне Rakudo. Настолько классный, что его даже переименовали, чтобы откреститься от ошибки и потом тихой сапой выпустить Perl 7 какой, после ветки 5 🙂

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

А вот при стандартизации CL, кстати, из стандарта старательно выгребали все неоднозначное говно, которое в т.ч. может повлиять на производительность.

Были огромные срачи на тему COMPILER-LET, на тему MOP и прочего. Я уже не говорю даже про интерфейсы к ФС, многопоточности итд. В итоге - в CL со всеми этими вещами все отлично, хоть и не стандартизировано.

Сразу видно - умные люди проектировали, а не сраные недоучки какие-то типа бидонистов.

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

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

это всратое легаси говно

нахер не всрались

все неоднозначное говно

(дальше считать не буду - не интересно)

Даже если опустить проблемы лексикончика Элочки-людоедочки - почему вас вопросы дефекации настолько озадачивают? Вы заднеприводный? Или вы считаете эпатажность на уровне младшей школы - это круто?

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

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

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

Фокусироваться надо не на форме, а на сути. Если вы, конечно, не интеллигент в пятом поколении — тем почти физически трудно воспринимать не очень культурную речь. Или не илитарий плюсишник, который отдыхает, нудя на ЛОР’чике. Ну те в принципе калеченные разумом после поделия шведа, простительно.

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

Ну а что. Кто-то же должен в конце концов объективно освещать реальное положение дел в этой индус-трии.

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

Сейчас опять разгорится спор «но они взлетели, а лишп не взлетел», хотя взлетели они не из-за недостатков, а лишп соответственно не взлетел (уточню: на текущий момент, не надо вспоминать времена, когда лисп-машины делали, и лишп был на взлете) не из-за достоинств. Не умеют люди мух от котлет отделять, всё вместе всегда.

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

Или не илитарий плюсишник

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

который отдыхает, нудя на ЛОР’чике.

Где я нудил? Отдыхаю и развлекаюсь местами - да, Вы меня разгадали ;)

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

Эвона как.

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

Где я нудил?

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

Речь шла про меня, ведь это я здесь единственный иллитарий по мнению Virtuos86.

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

не надо вспоминать времена, когда лисп-машины делали, и лишп был на взлете

Следуя этой логике имеет смысл обсудить преимущества парусного торгового флота. Не, ну а почему бы не вспомнить времена (несколько сот лет, однако) когда он был доминирующим? И достиг, не побоюсь этого слова, совершенства в своем развитии. Те же чайные клипера были вершиной инженерного искусства своего времени.

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

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

Слушать критику парусного судоходства от людей, которые никогда не ходили под парусом и не могут отличить фал от шкота, просто смешно.

Ну а обсуждать долю парусного флота в во всемирных морских грузоперевозках могут только душные иллитарии с двумя курсами провинциального ПТУ за плечами.

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

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

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

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

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

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

Я вас не читаю, напомню. Что-то короткое еще автоматически успевает прочитаться одним взглядом, а «портянки» – нееее, ну его на фиг ))). Не люблю, когда любой труд пропадает втуне, а здесь именно тот случай.

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

Блеать, опять попытки умничать постфактум. А главное – никакого риска нет, когда твои рассуждения опираются на текущую реальность, а не на «а вот если бы» 😄. Иначе придётся спорить с реальностью, а это занятие для илитариев 🤣. Сплошной шах и мат, все бежим писать на Go! (Кроме сами знаете кого 😏.)

Virtuos86 ★★★★★
()

lovesan, «серебряной пули» не будет.
«Грамматики» (которые используются для разработки компиляторов) не пригодны для создания readable синтаксиса программ.

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

Что касаемо Go, то его «улучшают» и результат будет - «доулучшаются».

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

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

С разморозкой. Зеленые друзья уже вспомнили и пилят бюджетики на «паруса» (на самом деле «ветродвижители») для танкеров :) экономят топливо для доставки топлива... это я не знаю какой уже уровень вложенности пост- или метаиронии: yo dawg so we heard you like fuel economy with sails, so we put huge sails on fuel supertanker so you can economy fuel while you sail...

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

Не раскрыта тема «go — это оберон с фигурными скобочками...» wait... oh shi! Лавсанчег прыгнул на Вирта :)

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

Сплошной шах и мат, все бежим писать на Go! (Кроме сами знаете кого 😏.)

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

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

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

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

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

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

лиспоподобная скриптота

это eLisp или еще нечто подобное (CLisp или как там его), но никак не могучий, богатырский конпелируемый Common Liшp! И сверху плюсцов он может только их крыть 🤣 (некорректно, но не мог удержаться 😁).

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

Я вас не читаю, напомню.

Не беспокойтесь, не для вас было написано.

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

С разморозкой. Зеленые друзья уже вспомнили и пилят бюджетики на «паруса» (на самом деле «ветродвижители») для танкеров :)

;)

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

Но тема то не новая, если мне не изменяет склероз, подобные прожекты описывались в «Юном технике» (или в «Технике молодежи») еще в 1980-х.

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

В «Катерах и яхтах» регулярно писали про очередных пересекателей Атлантики под «не-парусом».

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

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

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

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

долю парусного флота в во всемирных морских грузоперевозках

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

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

Вот, я, к слову, и ссылочку припас.

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

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

Откуда ж я знаю ваши возможности.

а, так это вы мне посылали. понятно.

alysnix ★★★
()

Стереотипичное описание Go. Многих оттолкнуло от языка поддержка BLM салариманами в Google. Описание отношения к языку в самом Google скорее верное. Посе разочарования в Python как в языке общего назначения стали смотреть по сторонам и увидели решение многих проблем в Go. Rob Pike и другие использовали любой шанс для популяризации языка.

Язык с 90-х создавался НЕ для привлечения пользователей Python, а для C++, как альтернативная версия развития C.

Создание производных типов через композицию, без наследования. Практически множественное наследование. Наверное единственный язык сейчас в котором настоящая композиция. Struct embedding, field&method shaddowing. Goroutines/channels лучшее решение обоих конкурентности и параллелизма.

Компилятор написан на Go(self-hosting), но для встроенного ассемблера мало документации.

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

Вопрос в том, кем являетесь лично вы в этой картине мира.

Беспристрастным историком технического прогресса, например.

Если…

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

Грубо говоря, парусная лодка уместна, если вы обычный рыбак на Шри-Ланке, а барк «Крузернштерн» уместен для обучения курсантов. Потому что сегодня вот так, а 200 лет назад было иначе.

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

Т.е. если вы Пол Грэм одиночка-стартапер, в одно рыло (или с парой-тройкой своих небинарных партнеров) клепающий новый перспективный продукт и для вас лично Common Lisp любимый и удобный инструмент, то это одно дело.

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

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

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

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

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

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