self - это в питоне, в С++ this
Да все до меня дошло, просто я пошел дальше иронизировать.
Срочно вернитесь в зону первоначальной шутки!
*отвязывает лодку
А в чем, собсно, ненависть к с++?
Наглядное объяснение:
- херба саттера не слушают, а он между прочим дело говорит.
- модули в cmake до сих пор не довезли.
- Стандарты раз в 3 года делают (а могли бы каждый месяц-два)
- дрочат на обратную совместимость (а могли бы дрочить поменьше и заставлять почаще переписывать легаси - вот уж точно хуже бы не стало)
- Рефлексию довезут только в 23м. И pattern_matching возможно. А метаклассы тогда вообще хуй знает когда
- никто не горит желанием все переписать на модули (а пора бы)
- в стандартной библиотеке повсюду ужасный_снейк_кейс_нейминг который_уже_даже в_ключевые_слова_языка пробрался (но это лично моя вкусовщина).
- стандарт языка дорогой, нельзя просто взять и прочитать (несколько килодолларов вроде)
- 21 способ инициализации переменной - это пожалуй слишком много
Считаю что с++ отличный язык для работы (ненавижу его уже 10 лет и не собираюсь останавливаться).
- модули в cmake до сих пор не довезли.
- Стандарты раз в 3 года делают (а могли бы каждый месяц-два)
- дрочат на обратную совместимость (а могли бы дрочить поменьше и заставлять почаще переписывать легаси - вот уж точно хуже бы не стало)
- Рефлексию довезут только в 23м. И pattern_matching возможно. А метаклассы тогда вообще хуй знает когда
- никто не горит желанием все переписать на модули (а пора бы)
- в стандартной библиотеке повсюду ужасный_снейк_кейс_нейминг который_уже_даже в_ключевые_слова_языка пробрался (но это лично моя вкусовщина).
- стандарт языка дорогой, нельзя просто взять и прочитать (несколько килодолларов вроде)
- 21 способ инициализации переменной - это пожалуй слишком много
Считаю что с++ отличный язык для работы (ненавижу его уже 10 лет и не собираюсь останавливаться).
Переписывать легаси? Серьезно? Нет, я конечно понимаю что это полезно, но какой-же "Эффективный Менеджер" на это даст время и денег?
Стандарты менять так часто, как ты предлогаешь, это будет геморой.
Стандарты менять так часто, как ты предлогаешь, это будет геморой.
ну ладно, мож раз в 2-3 месяца это я и лишка хватанул, но если бы были инструменты автоматом обновляющие "устаревающие" куски кода (как в некотором swift например). Или если бы выпускали обновления так же часто как в Rust - было бы всяко поприкольней.
И да, я понимаю что в Rust и Swift все проще потому что они ни с кем договариваться не должны. им вообще стандарт не особенно нужен, если там 1-2 компилятора и все. Просто выкати обновление компилятора и радуйся жизни. А стандарт плюсов еще же со всеми согласовать надо. я понимаю почему сейчас так сложно, для этого конечно есть объективные причины. Но от этого менее больно не становится.
И да, я понимаю что в Rust и Swift все проще потому что они ни с кем договариваться не должны. им вообще стандарт не особенно нужен, если там 1-2 компилятора и все. Просто выкати обновление компилятора и радуйся жизни. А стандарт плюсов еще же со всеми согласовать надо. я понимаю почему сейчас так сложно, для этого конечно есть объективные причины. Но от этого менее больно не становится.
А вообще конечно, чисто технически никто не мешает господам погромистам развивать коммуникативные навыки и объяснять менеджерам, на кой хуй нужно раз в год-полтора перетряхивать архитектуру приложений. В качестве аргументов неплохо подойдет "легаси код провоцирует к найму более дорогих специалистов" и "в скорем времени это масштабироваться будет плохо".
да. три способа инициализации вполне достаточно.
640к способов инициализации точно хватит
> модули в cmake до сих пор не довезли
Причём тут C++? Ты из тех кто считает что крестам нужен "менеджер пакетов", кек?
> дрочат на обратную совместимость
Потому что это серьёзная технология для системной разработки, а не хипсторские однодневки. Это в ёбаном JS жизненный цикл фреймворка полтора года, а кресты -- всерьёз и надолго.
> Рефлексию довезут только в 23м
Нахой она не нужна потому что. Деманглинг системными средствами и коллбеки. Для остального есть JIT.
> никто не горит желанием все переписать на модули (а пора бы)
Нет, не пора, и никогда не будет. Модули может и нужны в отдельных случаях, но разделение на декларацию и реализацию (а так же прекомпилирование заголовков) -- отличная штука для больших проектов.
> повсюду ужасный_снейк_кейс_нейминг
Именно что вкусовщина. Поработаешь ещё лет десять и будет вообще похуй.
Причём тут C++? Ты из тех кто считает что крестам нужен "менеджер пакетов", кек?
> дрочат на обратную совместимость
Потому что это серьёзная технология для системной разработки, а не хипсторские однодневки. Это в ёбаном JS жизненный цикл фреймворка полтора года, а кресты -- всерьёз и надолго.
> Рефлексию довезут только в 23м
Нахой она не нужна потому что. Деманглинг системными средствами и коллбеки. Для остального есть JIT.
> никто не горит желанием все переписать на модули (а пора бы)
Нет, не пора, и никогда не будет. Модули может и нужны в отдельных случаях, но разделение на декларацию и реализацию (а так же прекомпилирование заголовков) -- отличная штука для больших проектов.
> повсюду ужасный_снейк_кейс_нейминг
Именно что вкусовщина. Поработаешь ещё лет десять и будет вообще похуй.
1) cmake - система сборки а не менеджер пакетов. к чему вопрос про менеджер пакетов?
А вообще, да - считаю что крестам нужен менеджер пакетов (conan уже неплохо справляется)
2) ах, как я люблю это надуманное противопоставление серьезные мужики - хипстеры недокодеры. А главное что оно благополучно скрыло смысл того что же ты хотел сказать...
Вот по твоему, с++ должен обновляться раз в: месяц/пол года/год/3 года/5 лет/10 лет/поколение/никогда, ибо уже достиг совершенства? то что он всерьез и надолго не значит, что он не должен меняться.
3) тебе не нужна, а вот тем кто интегрирует плюсы с другими языками - нужна. и тем кто хочет существенно расширить compile time вычисления - тоже. мир большой, задачи у всех разные.
4) стандартную библиотеку начнут переводить на модули (так что мне не понятен аргумент про "и никогда не будет"). Модули нужны практически везде, (время компиляции, удобство для систем сборки, уменьшение боли с odr). Модули вполне себе поддерживают разделение на декларацию и реализацию, но с другой стороны позволяют писать и без этого. Ведь по сути это разделение нужно практически в одном единственном месте - в интерфейсе выставляемом наружу из библиотеки.
5) про вкусовщину не вижу смысла спорить. хотя если есть хорошее исследование сравнения читаемости кода - я бы поглядел.
А вообще, да - считаю что крестам нужен менеджер пакетов (conan уже неплохо справляется)
2) ах, как я люблю это надуманное противопоставление серьезные мужики - хипстеры недокодеры. А главное что оно благополучно скрыло смысл того что же ты хотел сказать...
Вот по твоему, с++ должен обновляться раз в: месяц/пол года/год/3 года/5 лет/10 лет/поколение/никогда, ибо уже достиг совершенства? то что он всерьез и надолго не значит, что он не должен меняться.
3) тебе не нужна, а вот тем кто интегрирует плюсы с другими языками - нужна. и тем кто хочет существенно расширить compile time вычисления - тоже. мир большой, задачи у всех разные.
4) стандартную библиотеку начнут переводить на модули (так что мне не понятен аргумент про "и никогда не будет"). Модули нужны практически везде, (время компиляции, удобство для систем сборки, уменьшение боли с odr). Модули вполне себе поддерживают разделение на декларацию и реализацию, но с другой стороны позволяют писать и без этого. Ведь по сути это разделение нужно практически в одном единственном месте - в интерфейсе выставляемом наружу из библиотеки.
5) про вкусовщину не вижу смысла спорить. хотя если есть хорошее исследование сравнения читаемости кода - я бы поглядел.
1) NuGet или conan, а то и одновременно.
2) Менять не всегда значит сделать лучше. Менять - наделать новых ошибок?
3) Задачи разные - по этому под другие задачи нужно брать не С++
4) Что за модули вообще? Чем разделение по разным lib или dll не нравится?
2) Менять не всегда значит сделать лучше. Менять - наделать новых ошибок?
3) Задачи разные - по этому под другие задачи нужно брать не С++
4) Что за модули вообще? Чем разделение по разным lib или dll не нравится?
судя по последнему вопросу ты не очень в теме, да?)
> к чему вопрос про менеджер пакетов?
А к чему сожаления про одну из систем сборки?
> как я люблю это надуманное противопоставление
Just kidding, конечно. Но, вообще, новые стандарты вон меняют язык, и вполне хорошо. Тут трейдоф-то простой: или ебошим каждый день новые концепции, или тщательно подбираем то что не отменяет достигнутых преимуществ. Соотношения качества, стоимости и количества наебать-то можно, но только делается это чем-то действительно стоящим, чего нельзя взять и потребовать потому что хочется.
> вот тем кто интегрирует плюсы с другими языками - нужна
Для этой интеграции есть SWIG и хуева гора надстроек которые никто не хочет учить, пока не прижмёт. Мир большой и все хотят испортить хорошую технологию потому что всякий думает что то что нужнее именно ему -- прям вот ебанись как полезно и нужно. У крестов есть конкретная (неузкая такая, да?) ниша, в которой они сидят: уровень чуть повыше асма, без накладухи на сборку мусора, интроспекцию и рефлексию. Полноценной рефлексии без накладных не будет, а для неполноценной -- JIT и шланговый парсер в помощь (может быть его лучше допилить чем стек насиловать?). Большая часть других языков имеют если не сам вообще Си под капотом, то отличные биндинги которые скриптятся наотличненько.
> разделение нужно практически в одном единственном месте
Нихера ж себе "единственное место" -- да любой проект мало-мальски оптимизированный под сборку содержит тонны одних только forward-деклараций, а архитектура естественным образом распадается на элементы зачастую даже в рамках одной библиотеки.
В чём вообще бенефит модулей? ODR, как и любой принцип -- скорее рекомендация, чем веление строгой необходимости, тем более его целиком и полностью контролирует любой компилятор.
А к чему сожаления про одну из систем сборки?
> как я люблю это надуманное противопоставление
Just kidding, конечно. Но, вообще, новые стандарты вон меняют язык, и вполне хорошо. Тут трейдоф-то простой: или ебошим каждый день новые концепции, или тщательно подбираем то что не отменяет достигнутых преимуществ. Соотношения качества, стоимости и количества наебать-то можно, но только делается это чем-то действительно стоящим, чего нельзя взять и потребовать потому что хочется.
> вот тем кто интегрирует плюсы с другими языками - нужна
Для этой интеграции есть SWIG и хуева гора надстроек которые никто не хочет учить, пока не прижмёт. Мир большой и все хотят испортить хорошую технологию потому что всякий думает что то что нужнее именно ему -- прям вот ебанись как полезно и нужно. У крестов есть конкретная (неузкая такая, да?) ниша, в которой они сидят: уровень чуть повыше асма, без накладухи на сборку мусора, интроспекцию и рефлексию. Полноценной рефлексии без накладных не будет, а для неполноценной -- JIT и шланговый парсер в помощь (может быть его лучше допилить чем стек насиловать?). Большая часть других языков имеют если не сам вообще Си под капотом, то отличные биндинги которые скриптятся наотличненько.
> разделение нужно практически в одном единственном месте
Нихера ж себе "единственное место" -- да любой проект мало-мальски оптимизированный под сборку содержит тонны одних только forward-деклараций, а архитектура естественным образом распадается на элементы зачастую даже в рамках одной библиотеки.
В чём вообще бенефит модулей? ODR, как и любой принцип -- скорее рекомендация, чем веление строгой необходимости, тем более его целиком и полностью контролирует любой компилятор.
- ну про систему сборки я впомнил, так - чисто поныть - понудеть)
- согласен, стандарты плюсов довольно сложная (и много где хорошая) вешчь, чтобы просто так взять и вписать в нее что-то сильно новое и при этом ничего не поломать. Действительно - комитет не на пустом месте так много над новыми фичами думает - там есть над чем подумать. Но с другой стороны, вот те же метаклассы из-за этой тактики придется ждать по меньшей мере до 26го видимо. И что-то здесь все же не так: я ж хочу эту радость при своей жизни поюзать, а не внукам подарить) и желательно в боевом проекте а не в фича-ветке популярного компилятора.
- про SWIG - я и сам из той кучи, которая не хочет его учить) Совершенно согласен, что рефлексия в плюсах не должна стоить в рантайме или вообще ничего или крайне мало.
- Ну дык с модулями как раз и не нужны будут все эти forward- декларации (если я правильно понимаю) там же явно прописываешь, что из модуля идет на экспорт, а что остается. Плюс насколько я помню хедеры в принципе в плюсах появились именно из за этого дурацкого механизма сборки через копирование. Если от него избавиться, то и разделение на h/cpp тоже будет не особенно нужно. Думаю даже в библиотеках можно будет без него обойтись и все сделать на модулях (но я чессказать не пробовал)
- согласен, стандарты плюсов довольно сложная (и много где хорошая) вешчь, чтобы просто так взять и вписать в нее что-то сильно новое и при этом ничего не поломать. Действительно - комитет не на пустом месте так много над новыми фичами думает - там есть над чем подумать. Но с другой стороны, вот те же метаклассы из-за этой тактики придется ждать по меньшей мере до 26го видимо. И что-то здесь все же не так: я ж хочу эту радость при своей жизни поюзать, а не внукам подарить) и желательно в боевом проекте а не в фича-ветке популярного компилятора.
- про SWIG - я и сам из той кучи, которая не хочет его учить) Совершенно согласен, что рефлексия в плюсах не должна стоить в рантайме или вообще ничего или крайне мало.
- Ну дык с модулями как раз и не нужны будут все эти forward- декларации (если я правильно понимаю) там же явно прописываешь, что из модуля идет на экспорт, а что остается. Плюс насколько я помню хедеры в принципе в плюсах появились именно из за этого дурацкого механизма сборки через копирование. Если от него избавиться, то и разделение на h/cpp тоже будет не особенно нужно. Думаю даже в библиотеках можно будет без него обойтись и все сделать на модулях (но я чессказать не пробовал)
Метаклассы в крестах ломают логику языка, в принципе. Наверное, их и можно сделать, но сложно придумать, как это будет встраиваться в то что в языке уже есть. Плюсы -- плохой язык для метапрогрммирования в принципе (лексика шаблонов -- довольно уродливое дополнение, не так ли?), и решать в нём задачи через него не нужно. Если очень хочется так решать задачи, то стоит, наверное, посмотреть на другой язык. Вроде того же раста, где и сборка мусора, и всякие гринлеты и куча всяких ништяков на уровне лексики.
У каждого более-менее выстоявшегося языка есть некая своя внутренняя логика (ну, кроме JS). Которая в частностях выражается в наличии всяких "искусственных ограничений" вроде private/protected/public, const-validity и запрете на неявный даункаст, выведения конструктора копии, реализации ромбовидного наследования etc. etc. И то что классы -- не first class object, в общем, тоже некий важный элемент этой логики. Это не значит, что они не нужны, или не позволят что-то делать более эффективно, это значит, что нужно трижды подумать, прежде чем их добавлять, и подумать семь раз, прежде чем найти им лексическую форму. Темболие у нас есть специализация шаблонов и дивный мир SFINAE (кстати, когда язык приходит к таким обскурам, это, скорее всего, признак того что свой потенциал он исчерпывает).
На самом деле из-за модулей я и начал комментировать. Думал, ты, как их апологет, поделишься в полемическом задоре каким-нибудь лихим кейсом, который я не вижу своим зашоренным взглядом.
У каждого более-менее выстоявшегося языка есть некая своя внутренняя логика (ну, кроме JS). Которая в частностях выражается в наличии всяких "искусственных ограничений" вроде private/protected/public, const-validity и запрете на неявный даункаст, выведения конструктора копии, реализации ромбовидного наследования etc. etc. И то что классы -- не first class object, в общем, тоже некий важный элемент этой логики. Это не значит, что они не нужны, или не позволят что-то делать более эффективно, это значит, что нужно трижды подумать, прежде чем их добавлять, и подумать семь раз, прежде чем найти им лексическую форму. Темболие у нас есть специализация шаблонов и дивный мир SFINAE (кстати, когда язык приходит к таким обскурам, это, скорее всего, признак того что свой потенциал он исчерпывает).
На самом деле из-за модулей я и начал комментировать. Думал, ты, как их апологет, поделишься в полемическом задоре каким-нибудь лихим кейсом, который я не вижу своим зашоренным взглядом.
> Рефлексию довезут только в 23м.
веке?
веке?
походу да(
Меня всегда забавляло сколько же в плюсах способов объявить строку но блин ни одного нормального способа вывести ее на экран с форматированием, ять!
А после знакомства с MFC я точно понял что плюсы это не мое
MFC вообще как радиоактивные отходы - чтобы взаимодействовать с ними нужны толстые перчатки, крепкие нервы и символический стакан водки постфактум
Какой еще MFC про него уже все забыли. Брось каку!
Да и причем тут С++? Это вопросы к Микрософт, а не к С++
Да и причем тут С++? Это вопросы к Микрософт, а не к С++
Это было давно, 10 лет назад. Но травма в моей психике до сих пор жива - LPARAM, WPARAM и вызоы WinAPI навсегда останутся в моем подсознании, как хтонический ужас
я недавно узнал, что вызов WinApi может даже неожиданно упасть где-то у себя в глубине (о чем в документации разумеется не будет ни слова).
а я у себя ошибку 2 дня до этого искал)
а я у себя ошибку 2 дня до этого искал)
А чё, от туда выпилили printf штоле?
А помимо консоли форматировать вывод как? В лейбаке например?
sprintf
Вывод текста в массив байт - очень наглядно, как это связать с лейбаком?
> - стандарт языка дорогой, нельзя просто взять и прочитать (несколько килодолларов вроде)
Это финальные версии. Если ты не разработчик компилятора, то драфта достаточно с головой для любых кейсов. Если нужна какая-то конкретная версия — есть архив всех материалов, ну а для любителей опен-сорса исходники драфтов свободно публикуются на Гитхабе.
Это финальные версии. Если ты не разработчик компилятора, то драфта достаточно с головой для любых кейсов. Если нужна какая-то конкретная версия — есть архив всех материалов, ну а для любителей опен-сорса исходники драфтов свободно публикуются на Гитхабе.
да это то все понятно в общем. и с аргументом про разработчика компилятора, я даже согласен.
мне эта ситуация просто стратегически не нравится. Ну не должно быть так, что сообщество по черновикам восстанавливает что там в стандарте "на самом деле" написано. ерунда какая-то
мне эта ситуация просто стратегически не нравится. Ну не должно быть так, что сообщество по черновикам восстанавливает что там в стандарте "на самом деле" написано. ерунда какая-то
а за ссылку на Github - спасибо. ее я раньше не встречал
По моему наоборот: дохуялерион фич которые невозможно в голове удержать.
На мой взгляд главная проблема в плюсов в том, что для того чтобы читать профессиональный код на плюсах нужен особый склад ума. И дело тут не в какой-то особенной умности или генитальности, а вот в чём...
Обычно, когда ты пишешь код, ты пишешь его чтобы его могли прочитать люди. Чтобы было понятно какого хуя тут делается, и всё такое. На С++ пишут не для людей. На С++ пишут то, что максимально быстро исполнит машина. С пониманием кэша, шины памяти, того что происходит когда тред с твоей программой переносится шедулером с одного ядра на другое, минимизация и разведение по углам тяжёлых операций, бранчинг и предсказуемость, и это ещё до того как ты сунешься в мультитрединг. Программист на С++ должен понимать в деталях как железо исполняет код, чтобы писать так как было удобно железу. При этом он также должен понимать в деталях, как компилятор плюсов генерирует код, чтобы писать так, чтобы генерировался код удобный железу. Обычно в итоге удобный железу код через финскую подушку компилятора приносит в жертву человекочитаемость. Программист на плюсах смотрит на этот код сквозь призму того, как он будет скомпилирован и выполнятся, и говорит "хм, логично". Программист на человеческих языках посмотрит на этот код с точки зрения человека, и сможет только сказать "БЛЯДЬ, ЧТО ТЫ ТАКОЕ?!".
Вот это умение понимать что нагенерит компилятор, и как это пройдёт сквозь железо-затыки, и есть особенность чтения профессионального кода на плюсах, от которой у программистов на других языках волосы дыбом встают, что аж сидеть неудобно.
Если ты пишешь для людей, игнорируя возможности писать для железа, то тебе нахуй не сдались плюсы. Если ты пишешь на плюсах, будь добр использовать то ради чего эта попиздятина существует. Попытки использовать плюсы как обычный человеческий язык программирования и словленный с этого расплав пукана и являются основной причиной ненависти к плюсам.
Обычно, когда ты пишешь код, ты пишешь его чтобы его могли прочитать люди. Чтобы было понятно какого хуя тут делается, и всё такое. На С++ пишут не для людей. На С++ пишут то, что максимально быстро исполнит машина. С пониманием кэша, шины памяти, того что происходит когда тред с твоей программой переносится шедулером с одного ядра на другое, минимизация и разведение по углам тяжёлых операций, бранчинг и предсказуемость, и это ещё до того как ты сунешься в мультитрединг. Программист на С++ должен понимать в деталях как железо исполняет код, чтобы писать так как было удобно железу. При этом он также должен понимать в деталях, как компилятор плюсов генерирует код, чтобы писать так, чтобы генерировался код удобный железу. Обычно в итоге удобный железу код через финскую подушку компилятора приносит в жертву человекочитаемость. Программист на плюсах смотрит на этот код сквозь призму того, как он будет скомпилирован и выполнятся, и говорит "хм, логично". Программист на человеческих языках посмотрит на этот код с точки зрения человека, и сможет только сказать "БЛЯДЬ, ЧТО ТЫ ТАКОЕ?!".
Вот это умение понимать что нагенерит компилятор, и как это пройдёт сквозь железо-затыки, и есть особенность чтения профессионального кода на плюсах, от которой у программистов на других языках волосы дыбом встают, что аж сидеть неудобно.
Если ты пишешь для людей, игнорируя возможности писать для железа, то тебе нахуй не сдались плюсы. Если ты пишешь на плюсах, будь добр использовать то ради чего эта попиздятина существует. Попытки использовать плюсы как обычный человеческий язык программирования и словленный с этого расплав пукана и являются основной причиной ненависти к плюсам.
The last picture should be: "Now I hate myself furthermore."
ну его нахуй
буду эйчаром!
буду эйчаром!
Будет абатся с мозгами исполнителей
Или манагером
Javascript must die!
На самом деле программирование отлично учит тому, что если что-то не так, виноват всегда ты.
Или тот пидарас, который писал либу. Или тот пидарас, который не написал нормальные доки к либе...
Или, если ты кодишь не сам, а в какой-то большой организации, то еще один из сотни твоих коллег, запушивший какое-то говно в ваш проект, сломавшее решительно все.
Или когда ты не в очень большой организации, но проект существует много лет, и ты натыкаешься на код, который, наверное, писал пьяный ублюдок под наркотой, потому что вменяемый человек такое тупое говно написать не мог. Посмотрим, что за уебан это был ... а, да это же я. Не может быть, может, у меня учетку угнали, и кто-то решил поглумиться. Ну не мог это быть я! А, нет, это все-таки был я :-(
хм... а когда это было? может, я только-только начал учить язык? КАК ЭТО ВЧЕРА???
Это что. Я как-то свои записи институтских времен нашел. Я был очень хорош в некоторых дисциплинах (у нас, математиков, математика на десяток дисциплин делится) и даже создавал свои методы оптимизации для вычислений. В общем, нашел я такой метод... И не смог нихуя понять. Работать работает, а почему и как устроено хер знает. Видимо, отупел критически.
У меня были именно не ошибки новичков, не оверинжиниринг, а наркоманская хуета.
Как будто просто бессмысленный набор переменных и операторов. Как будто утром сильно не выспался, на автомате что-то закодил, думая о чем-то другом, как-то оно еще при этом жило, и выявлялось чисто случайно.
Как будто просто бессмысленный набор переменных и операторов. Как будто утром сильно не выспался, на автомате что-то закодил, думая о чем-то другом, как-то оно еще при этом жило, и выявлялось чисто случайно.
Или тот идиот который посал стандарт.
Или тот пидарас, который спроектировал так что приходится элементарные вещи реализовывать через костыли
или тот пидорас, который решил использовать эту либу.
программирование отлично учит тому, что если что-то не так, то кидай в беклог и забывай об этом навсегда
кстати вместо c++ можно поставить Linux )))
или вешалку. вон, один пидар красивую вешалку из железяк сварил, хвастался вроде вчера.
Это очень странно, ненавидеть линукс.
правильно, надо ненавидешь GNU
Ненавидеть Линукс - это нормально. Это отношения любви и ненависти!
с каждым обновлением arch. Неопесуемые чувства
Когда для меня C++ стал языком по умолчанию, больше всего я возненавидел лабы по javascript с его динамической типизацией
И не напоминай. После С++ Жаба ощущается так, будто тебе вдруг предложили надеть клоунский нос и пройти пару кругов по манежу цирка, жонглируя поддельными собачьими экскрементами. Видимо, привычка нужна.
Наоборот вызывает столько же ощущений. Придя с явы в шарп ощущаешь будто в армию попал, где надо пастели заправлять с уголком, сугробы выгляживать, газоны красить и по любому поводу честь отдавать кому надо и кому нет. Типа ну нахуя, когда можно жить простой нормальной жизнью. И через какое-то время вернувшись в яву немного понял подгорания на нее в инетах, когда уже привык к шарпу и разработал себе анал в полной мере, кажется как так как так, что за чудовищная безалаберность!!11 Хочется кричать на всех вокруг почему они суки строем не ходют)
Так ты тот школьник из Ростова? 3 года на С# писал?
Чтобы написать коммент, необходимо залогиниться