холиварте мой Холивар

ЯННП

Пшел вон.

Пятница только началась, но некоторые уже в кондиции.

Кто посмел Анонимусу рот затыкать! ( erthink красава сохранил, так их :) ) А если по делу как был С/С++ так и останется ещё лет 20, а русты и роуи выйдут на массовую сцену ровно тогда когда объём кода станет таким что хочет кто-то того или нет этот код должен продолжать работать и так по накатной.

How many people supposes to allow that the #JS or a #Java could overcome C/C++ ?

Лет ми спик дип фром май харт. У меня от этого больше подгорело

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

D - for Desktop. C - for Kernel. Rust - for Basic environment (binutils).

Java - for Web (back).

C++ must die.

Java тут не при чем. При чём одна большая идея: ты не должен управлять жизнью объектов языка.

В том коде, который ты описываешь, не должно быть создания объекта (оно произошло автоматически когда-то ранее, когда решит IoC/DI) и не должно быть удаления объекта с хипа (оно произойдет когда-то позже, когда решит GC). Кроме того из любого объекта можно сослаться на любой, минуя процедуру ручного создания и линковки (этим опять же занимается IoC/DI) на основании метаинформации.

Чтобы такая модель существовала, язык должен обладать несколькими свойствами, например - full runtime reflection, чтобы бегать по полям и автоматически линковать одни объекты с дргуими в рантайме. (Хотя с некоторыми допущениями можно опуститься до линковки в compile time reflection)

С++ такими свойствами не обладает, а вот Java/C# - обладает. Поэтому C++ в текущем виде будет отмирать, пока в него на уровне стандарта не добавят GC и IoC/DI хоть в каком-то виде.

С++ такими свойствами не обладает

А должен?

пропиарился - молодец

ставлю лайк и подписываюсь на канал

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

Возьмем Java - раньше там был только GC, а потом появился Spring Framework. Spring взял на себя вопрос создания объектов. Теперь большинство новых джава-приложений пишется на Spring. Де-факто он стал обязательной частью экосистемы. Почему? Потому что программисту больше не нужно думать о порядке запуска конструкторов и архитектуре инициализации - за него эту задачу решает Spring. К сожалению, в рантайме, и каждый перезапуск - заново, но все готовы с этим мириться в свете того, насколько это удобно - думать не самому, а отдать автоматике.

По сути, на текущем этапе развития Человечества, мы специфицируем только императивное поведение объектов. Старый класс проблем менеджмент создания-удаления исчез.

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

(Вначале это будут некие зачатки FP/reactive программирования «первого» уровня - они уже и сейчас есть: list.stream.filter.map.sort.collect(). Потом будут пруферы с восстановлением событий. Потом полноценная декларация результатов, реализацию которых сочиняет ии.)

И вот на этом этапе все текущие языки отправятся в утиль. Системы станут настолько сложны, что нельзя будет ответить на вопрос «как это должно работать». Соответственно, все языки, отвечающие на вопрос «как это должно работать» (все императивные языки) отправятся в утиль.

А через какое-то время и декларативные языки могут отправиться в утиль. Ибо они отвечают на вопрос «что должно получиться», а этот ответ - результат рефлексии людей о мире. Но если в какой-то момент появится ИИ, он сможет рефлексировать состояние мира ничуть не хуже людей, и самостоятельно выдвигать спецификации. К этому времени наступит долгожданное засасывание в сингулярность :)

Следующий этап - когда программы будут писать нейросетки.

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

Системы станут настолько сложны, что нельзя будет ответить на вопрос «как это должно работать».

Но тогда они станут не нужны из-за невозможности их поддерживать.

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

Но тогда люди станут не нужны, как вид.

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

Дело Пашки Морквина PaulCarroty живет.

Я что хочу сказать, императивщина на чём-то типа плюсов никуда не денется.

Может хоть на язык нормальный перейдет.

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

Что здесь происходит?

Хорошо сказал.

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

Ну пусть швейцарский нож. Этим лес не валят. Ни в пром.масштабах, никак. Си/плюсы это ближе к машиностроению. Делать какой-нибудь там веб на плюсах всё равно, что сделать мясорубку из токарного.

В идеале этим ни лес не валят, ни конверты не вскрывают.

Задачей плюсов должно было быть «попробовать засунуть все, что только можно, в C, и умереть». Полпути пройдено.

Задачей плюсов должно было быть «попробовать засунуть все, что только можно, в C, и умереть». Полпути пройдено.

Там после auto весь путь уже пройден несколько раз.

Твой английский — говно.

Твой русский — говно.

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

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

holly

Holy Molly

Поэтому C++ в текущем виде будет отмирать, пока в него на уровне стандарта не добавят GC

Слишком толсто.

Свитер буржуйский, ищи более нейтральный ресурс.

не должно быть создания объекта (оно произошло автоматически когда-то ранее, когда решит IoC/DI) и не должно быть удаления объекта с хипа (оно произойдет когда-то позже, когда решит GC). Кроме того из любого объекта можно сослаться на любой, минуя процедуру ручного создания и линковки (этим опять же занимается IoC/DI) на основании метаинформации.

а вот Java/C# - обладает.

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

Скайнет уже рядом, осталось подключить жабу к ракетам.

Но зачем?

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

Доставляешь ;)

Рантайм - это ниша.
Си и плюсы - это другая ниша.

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

Но зачем?

Терминатора смотрел? «Мы рождены чтоб сказку сделать былью!»(ц)

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

Java, кстати, довольно давно умеет в embedded - либо в виде JavaCard (которое по названию Java, а по сути - гемор не меньше Си), либо в виде коммерческих решений вроде Excelsior JET. Но год назад появились зачатки бесплатного решения для полноценной Java - генератор native-image из GraalVM. Пока что native-image умеет очень мало, несопоставимо с Джетом, но разработчики фигачат новый код как будто на спидах

Сейчас в рамках GraalVM активно развивается диалект под названием System Java - это «полноценная» Java, но с «низкоуровневой» семантикой операций с памятью. Она нужна для переписывания Java на Java, и выбрасывания C++ из критичных систем вроде JIT-компилятора и GC. Из компилятора уже выбросили. Может быть, какая-то адаптация System Java когда-нибудь сможет работать в kernel mode? Ну и в любом случае, никто не отменял управления железом из юзерспейса.

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

А ты видел, какой я жирный?

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

Интересный факт (или не очень): только малая часть жобокодеров понимает как работает spring. Оно и не надо, работает же. Я и сам не знаю. Это пугает.

Она нужна для переписывания Java на Java

Вот блин. Я-то думал java все время только ускоряют, а они вон чо.

Так оно и ускоряется. Просто взгляни, какой там C++ код и всё поймешь. Я раньше люто фанател от идеи «стать разработчиком джавы», потом разобрался в вопросе, и теперь чувствую что как будто бы в говне измазался. Желания поубавилось раз так в сто. То же самое про C# - там GC вообще погенерён из лиспа и представляет собой листинг на 2 мегабайта чистейшего ада. Неудивительно, что они всё стараются переписать на нормальных языках (Java/C#), красиво и аккуратно.

Но тогда люди станут не нужны, как вид.

Нужны кому? Нужны для чего? Они, вроде бы, и сейчас ни разу не нужны.

Дык любой проект, длящийся 20 лет это ад. Вообще, любой большой проект это ад, даже если его вчера написали. От ЯП тут мало что зависит.

пока в него на уровне стандарта не добавят GC

с разморозкой! только оно нафиг никому не нужно

Но кто код будет писать, если не будет людей?