Здравствуйте, Mr.Delphist, Вы писали:

MD>Никто не должен. Хочешь — делай дефолтный конструктор, хочешь — нет. При желании можно вообще всё в фабрику и интерфейсы спрятать — тогда вовсе не знаешь, какой класс должен создаться.
Только тогда у вас стандартные фрэймворки не будут работать.

MD>В общем, мне пока не встречалось сценария, когда бы Newtonsoft не смог.
Не спорю. Но аттрибуты во-первых не всегда можно навесить, во-вторых это вносить в POCO зависимости, в-третьих заменить одну библиотеку на другую становится сложнее.

Взять тот же elm
https://guide.elm-lang.org/effects/json.html
вместо аттрибутов у нас есть функция которая явно декодирует json.
легко заменить одну функцию на другую того же интерфейса.

И так весь дотнет c#. ты вертишься вокруг шаблонных решений мс.
по сути дотнет это и есть фрэймворк. с неочень хорошими дефолтными решениями.

Здравствуйте, vdimas, Вы писали:

V>Еще это утилита описания тех самых пакетов, опять же, сами пакеты утилита упаковывает, она вызывает целевые пакетные менеджеры.

То есть я могу взять какой-то C++ проект с гитхаба, запустить на нём CMake, и все пре-реквизиты для сборки этого проекта сами скачаются из публичных репозиториев в нужном для моей платформы виде, и всё соберётся?
Покажите мне этот C++ проект. Мне интересно.

V>Но вот я тебе и предложил попробовать ручками выполнить похожие действия, чтобы ты включил здравый смысл — это что, вся индустрия мается этим вручную?
V>И сам себе ответил бы на свой бред.

В последний раз, когда я трогал С++ проект (я уже и не помню, что это было), там было полторы страницы инструкций, что откуда скачать и что куда положить, чтобы оно начало собираться.
Половина ссылок вела на мёртвые сайты, остальная половина — на устаревшие версии библиотек, которые уже не поддерживались.
То есть вместо dotnet build там надо было пару дней потрахаться, разбираясь, что откуда качать, и до конца уверенности, что собралось то, что нужно, не было.

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

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

Здравствуйте, vdimas, Вы писали:

V>>>Ставь ноду вручную из исходников или из архива бинарников — на выбор.
V>>>Осилишь?
I>>Какой в этом смысл?

V>А какой смысл нести всякую чухню, что в С++ нет менеджеров пакетов?

Непонятно, что ты понимаешь под менеджером пакетов. Ты описываешь вариант эмуляции пакетного менеджера при помощи cmake и dpkg и rpm.
Что делать, например, на винде, когда нет ни dpkg ни rpm ?
Вероятно, ты предложишь эмулировать средствами nuget

V>Например, CMake — это не утилита сборки проектов, хотя многие далёкие от темы относят её к таковой.
V>Это утилита описания проектов и их зависимостей, одновременно утилита ресолвинга этих зависимостей.

Похоже, её авторы и есть те недалёкие, о которых ты говоришь, т.к. уни утверждают
"CMake is an open-source, cross-platform family of tools designed to build, test and package software. "

Здравствуйте, vaa, Вы писали:

vaa>Только тогда у вас стандартные фрэймворки не будут работать.
Какие фреймворки и в каком сценарии? Не понимаю пока.

vaa>Не спорю. Но аттрибуты во-первых не всегда можно навесить, во-вторых это вносить в POCO зависимости, в-третьих заменить одну библиотеку на другую становится сложнее.
vaa>Взять тот же elm
vaa>https://guide.elm-lang.org/effects/json.html
vaa>вместо аттрибутов у нас есть функция которая явно декодирует json.
vaa>легко заменить одну функцию на другую того же интерфейса.

Если через кастомный конвертер — никаких атрибутов добавлять не надо. Есть контракт JsonConverter (на выбор даже два, обобщённый и строго-типизированный), который реализуешь исходя из своих задач. Иметь таких реализаций можно сколько угодно, и подставлять в парсер какой-либо из них по необходимости.

vaa>И так весь дотнет c#. ты вертишься вокруг шаблонных решений мс.
vaa>по сути дотнет это и есть фрэймворк. с неочень хорошими дефолтными решениями.

Аналогично, можно накидать кучу претензий на Java-стек (Spring явно не без греха и вовсе не верх удобства), про мобильные тулчейны (что Android, что iPhone, без слёз говорить нельзя), и т.д. и т.п.
В общем, если вспомнить старую истину, то все вещи вокруг делятся на два типа: те, которые ругают, и те, которыми просто не пользуются.

Здравствуйте, Serginio1, Вы писали:

S>Каждая новая версия андроида не совместима с предыдущей. Постоянно нужно учитывать текущую версию, и для неё вызывать новые методы, ибо старые не работают

Что хуже, они могут даже работать, но... более "улучшено"

Здравствуйте, Sinclair, Вы писали:

S>Охотно верю. Но всё же докер — не панацея. Для вашего приложения это, наверное, адекватное решение.
Ну да, везде его, конечно же пихать, только потому что модно, не стоит.

S>А для комманд-лайн утилиты, задача которой — взаимодействовать с файлами на моей файловой системе и с публичным веб-сервисом, поднимать пачку докер-контейнеров — оверкилл.
Согласен.

S>Ну, вот у меня, к примеру, докер на ноуте неожиданно стоит. А если бы нет? Это надо сначала качать докер, потом качать WSL2, потом ставить обновления, потом лезть в биос, чтобы включить виртуализацию.
S>Примерно это я и называю "гигабайт говна в пререквизитах".
Ну вообще под WIndows Workstation он у меня работал без всяких дополнительных плясок. Вот на Windows Server с ним проблемы, если надо запустить линуксовый контейнер. Там только с определенной версии работает.


SK>>Как обычно все зависит от того как сделано приложение. Вот я сейчас в конторе, так тут, чтобы приложение на жабе запустить надо взять бубен и ходить с ним, надеясь, что все сработает.
S>Странно — а что мешает сделать docker-compose build, docker-compose up?
Потому что приложению хер знает сколько лет, когда про докер еще никто не слышал. Там даже в maven структура говно у этого проекта. Просто кто-то когда-то услышал maven и, не разобравшись, насрал.
Сейчас, чтобы просто сделать docker совместимое приложение, там надо постараться, я уже предлагал, но слишком большое сопротивление от старперов, которые не знают про docker ничего.

S>На дотнете придётся специально постараться — например, завязаться на какую-нибудь экзотическую нативную либу.
S>В остальном экспириенс по установке дотнета даже туда, где его нет, гораздо комфортнее экспириенса по установке докера.
Да, тут согласен, MS зоопарк зависимостей лучше разрулил, чем в джаве. Maven родился как раз из-за того, что вечно при установке джава приложений начинались исключения типа "ClassNotFound Exception".

Здравствуйте, netch80, Вы писали:

N>Хм, я периодически читаю, как на винде делается настройка рабочей обстановки (куда и как записывать какие переменные, что в них вписывать), и сразу забываю, потому что понять этот продукт паука-наркомана невозможно. По сравнению с этим, методы в Unix банальны, просты и работают.

Поэтому разные софтины кладут свои настройки и логи кто в /var, кто в /usr, а кто-то — в /etc

N>Боюсь, с авторами Python периодически случается то же самое. Возможно, они выбирают добровольца, который одновременно применяет LSD и амфетамины, он в приходе лечит работу под Windows, потом он уезжает восстанавливаться и затем они ждут следующего камикадзе.

А можно было бы просто нанять Win-программиста, чтобы сделал как положено на этой платформе. Ведь если я буду разрабатывать под Linux, вряд ли будет осмысленным переизобретать там RegEdit и системный реестр? И это вызовет праведный гнев "открытого" сообщества как alien-технология, верно?
Однако для "открытых" кроссплатформенных решений почему-то в норме вещей требовать ставить на винду эмуляцию package manager, воссоздавать структуру системных папок на пингвиний лад и т.п. Прямо по "демократическим методичкам" работают товарищи, не особо скрывая двойных стандартов.

Здравствуйте, SkyKnight, Вы писали:
SK>Ну вообще под WIndows Workstation он у меня работал без всяких дополнительных плясок. Вот на Windows Server с ним проблемы, если надо запустить линуксовый контейнер. Там только с определенной версии работает.
Что значит "без всяких дополнительных плясок"?
Официальные инструкции докера говорят обратное: https://docs.docker.com/docker-for-windows/install/

SK>Сейчас, чтобы просто сделать docker совместимое приложение, там надо постараться, я уже предлагал, но слишком большое сопротивление от старперов, которые не знают про docker ничего.
А я думал, что в докер можно любую хрень запаковать. Ну, то есть просто берёшь, ставишь один раз базовый имадж, потом руками разворачиваешь всё, как надо, и публикуешь новый имадж.
Но я в докере — нуб, только в магистратуре его рукой трогал.

Здравствуйте, Sinclair, Вы писали:

S>Что значит "без всяких дополнительных плясок"?
S>Официальные инструкции докера говорят обратное: https://docs.docker.com/docker-for-windows/install/
Честно, вот, я просто поставил, запустил и у меня заработало

S>А я думал, что в докер можно любую хрень запаковать. Ну, то есть просто берёшь, ставишь один раз базовый имадж, потом руками разворачиваешь всё, как надо, и публикуешь новый имадж.
S>Но я в докере — нуб, только в магистратуре его рукой трогал.
Для этого надо сделать Dockerfile и потом еще docker-compose.yml, чтобы можно было использовать docker-compose build, docker-compose up
Так как у нас несколько сервисов, то имеет смысл их сгруппировать и разнести в разные контейнеры. В общем надо сидеть, смотреть, думать, но так как гланый архитектор через 3 года идет на пенсию ему эти телодвижения не хочется делать.

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

Поэтому имеем то говно, которое заслуживаем

Здравствуйте, Ikemefula, Вы писали:

V>>А потом сравним с возможностями какой-нить IntelliJ IDEA первой половины нулевых.
V>>По итогам сравнения дружно поржём над убогостью тулчейна JS (ты — "да я шутил", я — "я тоже посмеялся"), на этом и разойдёмся.
I>А если я скажу, скажем, что IDEA, ты как, осилишь её сравнение с IDEA первой половины нулевых, или уйдешь тихо скулить куда попало?

А в чём проблема?
Мы же будем сравнивать современные возможности IDEA для поддержки JS, с возможностями IDEA из середины нулевых для поддержки Джавы.
Вот и посмотрим, достигла ли сегодня поддержка JS хотя бы того уровня 16-тилетней давности.


V>>>>Что значит лишь одно — в этой среде недостаточно обитает компетенции.
I>>>Ровно наоборот. Жээс уже давненько экспортирует компетенции.
V>>Исключительно импортирует.
I>Уже давно не так.

Пустой трёп.
Если бы ты знал такие примеры, где библиотеки JS используются в других языках, ты бы обязательно кинул в меня этими ссылками, со всей этой своей пролетарской ненавистью, тебе так характерной. ))

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


V>>Исчезающе мало.
V>>Как какое нужное приложение на смартфоне ни возьми — оно чаще в родной технологии GIU сделано, а если со сложной графикой — плюс нейтив.
I>Количество веб-приложений на порядок больше всех мобильных вместе взятых.

Количество веб-приложений на ноде?
Под простачка решил сыграть? ))

- Кто на меня?
Встаёт амбал:
— Ну, я!
— Как зовут?
— Ваня...
— Кто на меня с Ваней?

Взять этот сайт — серверная часть дотнетая, JS сугубо на клиенте, его рядом с общим объемом кода приложения не видно и под микроскопом.
А в лидерах всё-равно PHP.


V>>А вот мобильная аппликуха провайдера, где пару кнопок, пару текстовых филдов, оплатить интернет, в общем, где требуется убогий GUI примерно из 95-го года парадигмой (с точностью до оформительских стилей) — вот там JS, да.
I>Вероятно, это ты выбрал самого дешманского провайдера.

Обычного, они все одинаковые.
Интерфейс их мобильных аппликух простейший.
Потому что это бесплатное приложение.


V>>А за что, если не за деньги?
V>>Или тебе подписка — не деньги?
I>Сейчас продажа именно софта скукоживается. А вот услуги, контент — вот это всё на высоте.

Ты на вопрос не ответил — подписка уже не деньги?


I>Ты же сам привел пример про внутригровые покупки — это же не продажа софта.

Но внутри игры не JS, там С++ и Lua.


I>Это ровно та же продажа услуг. Софт как раз бесплатный и становится всё бесплатнее.

Прекрасно!
Наконец ты осознал, что тот софт, что пишут на JS, он почти бесплатный и/или становится всё бесплатнее.

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

Там девиз всегда был один — дешевизна и простота.
Именно поэтому у огромного числа современных приложений GUI-интерфейс, по-сути, ничем не отличается от GUI приложух 2000-го года (с точностью до оформительского разнообразия).
GUI этот беден, несчастен и в принципе неразвиваем, потому что отсутствует инструментарий его развития.

Развитие принципов GUI идёт сегодня в основном в нейтивных либах (не обязательно языки С/С++) и лишь в одном не-нейтивном проекте на должном уровне — на языке Dart/Flutter. Это ключевое и единственное, что заставило меня внимательно туда посмотреть.

Потому что разработчики WPF-либы, увы, опозорились на весь мир, продемонстрировав, что не понимают, как надо разрабатывать GUI-библиотеки.
Маленькая подсказка — всю аналогичную реализацию XAML-кухни можно запросто сделать поверх Flutter.

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

Еще я видел отдельные попытки когда на JS писались контролы для канвы HTML-страницы.
Но эта канва не связана с остальным наполнением GUI страницы.
И когда полностью нарисованный с 0-ля GUI на канве, то тормозит оно так, что смотреть на такое можно только из любопытства.

Я уверен, что рано или поздно webasm доведут до ума, но там тоже будет рулить нейтив, ес-но.
webasm — это что-то типа llvm, только с предустановленным драйвером графики и драйвером канала общения с хостером, например, с HTML-страницей.

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


V>>Так я и зашёл:
V>>http://www.rsdn.org/forum/flame.comp/8063135.1
I>Слабовато зашел. Попробуй еще раза три. Не впечатлило.

Я уже понял, что ты не умеешь пользоваться поиском.
Введи senior C++ или team leader C++ и попустись.


V>>Львиное большинство работает за укзанные 80-120тыс.
V>>Это для разработки бесплатных проектов только.
I>Это потому, что разработчиов во фронте намного бОльше и низкий порог вхождения — работа найдется для всех.

Наивный.
Оно не характерно для JS, это так для индустрии в целом.
Потому что чем выше профессионал, тем больше охотятся за ним, чем он за работодателем.
Из-за этой особенности и существуют HR-конторы, и даже цветут и пахнут.

Мне поднадоело тыкать тебя в твои косяки — ты не обращал внимания на требуемый опыт в таких объявлениях, а там почти всегда 1-3 года, т.е. это объявление для студентов-старшекурсников или вчерашних студентов.


I>То есть, ты путаешь теплое с мягким.

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


V>>В плюсах это вчерашний студент, сеньёр.
I>Ты вероятно предпочел не смотреть те ЗП, что не вписываются в твои единичные примеры

Да пофик, дай мне единичные примеры самых-самых топ-вакансий JS c окладом 600 тыс/мес и годовым бонусом в размере 12-24 окладов.
Или бонус опционами в размере оклада с коэффициентом 100.


V>>Лазил по вакансиям С++ и не смотрел на требуемый опыт работы, а там где от 2-3-х лет, это для студентов, как раз с 3-4 курса обычно начинают подрабатывать.
I>Плодить сто вакансий смысла нет. Контора указывает минимальные требования и где то реальную ЗП ближе к максимуму. Из этого не следует, что все кандидаты получат 350.
I>Это следует из тех других вакансий, намного ниже, которые ты смотреть не хочешь.

Это следует из твоего непонимания того, что в начальный период карьеры программисты относительно часто меняют работу, в среднем раз в 2-3 года.
Т.е., вакансий на низкооплачиваемые места будет объективно больше из-за в разы большей текучки.


V>>В ЖС не часто делят по сеньёрам, джуниорам и прочим регалиям, что говорит об убогости основного стада.
I>Вероятно так в твоей конторке. Делят на градации в зависимости от числа человек такого же профиля в конторе.

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


I>Если больше нескольких десятков — надо уже ранжировать.

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

И неужели ты не знаешь — почему?
Или стыдно признаться?
Потому что там особо некуда расти.


V>>В более-менее серьзных разработках на ЖС основу разработчиков составляет относительно низкооплачиваемое низкоквалифицированное стадо.
I>А ты когда спишь, тоже пальцы растопыриваешь, или только на форуме?

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

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

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

А потом напишет макет и тесты на стороне JS, а остальное стадо пойдёт в хвосте по принципу "делай как я".


V>>Это только отчётность.
V>>Т.е., 1% функциональности системы управления предприятием.
I>Важно, что бизнес смотрит на софт со стороны фронтенда.

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


I>А потому те самые фронты делают видимой и твою работую.

Не надо т.н. "бизнес" считать за идиотов. ))
Они прекрасно знают, за что именно платят.

А тебя послушать, так разработчики БД тоже не нужны, и вообще все те, кто не имеет к JS отношения.
А на деле грамотным разработчикам БД тоже платят больше, чем во фронтенде.

Не зря термин фронтенд прилепилось к связке HTML/CSS/JS, бо это просто "енд" — верхушка остального айсберга.


I>Очевидно, что нынче лучше всего продаётся контент — смотри продажи в стриминге.

Но приложения-кинотеатры в основном не на HTML/JS.
Хотя, некоторые некритичные экраны GUI там бывают выполнены и по этой технологии.
Но ключевые, влияющие на основной юзер-экпиренс — нет.


V>>Но там редко JS, если только браузерная игруха. ))
I>В любом случае там будет тот или иной скриптовый движок, Lua например.

Во-первых, Lua компиллируемая, исходников скриптов у клиента не будет.

Во-вторых, у меня нет предубеждений к технологиям по их названиям, иначе мне не был бы любопытен Dart/Flutter.
Претензии к нынешнему JS и его связке с CSS/HTML у меня по совокупности сугубо технических признаков.

Если/когда тот же TS вытеснит JS до той степени, что JS отомрёт насовсем, а TS избавится от атавизмов совместимости с JS...
Одновременно с этим, понятное дело, машинка v8 будет доработана до оптимальной поддержки именно TS, и следующим естественным шагом будет компиляция в некий байт-код, сугубо с учётом поребности TS, а не уже умершего к тому моменту JS.
А следующим естественным шагом будет организация версионности и кеша бинарных библиотек на стороне браузеров — вот тогда приходи опять, поговорим. ))

Но, боюсь, webasm покроет все эти потребности раньше, поэтому я окажусь в этой области всё-равно раньше тебя.
(т.е. наша контора будет выпускать свои либы и под webasm)


V>>Взять хотя бы платных теле-провайдёров или онлайн-кинотеатров.
I>...
V>>GUI такого приложения — это высокооптимизированное нейтивное приложение поверх OpenGL/Vulkan/Metal и т.д.
I>Не заметил тут ничего высокооптимизированого. Такой UI встречается в вебе с 10х. Я не занимаюсь фронтом, вобщем, могу и ошибаться.

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


V>>Т.е., вот тебе сервис, сугубо интернетный, но никаким JS там не пахнет.
V>>Потому что оно приносит деньги, поэтому GUI должен быть на высшем уровне.

I>В МеГоГо товарищи не осилили стейтменеджмент, как и в IVI.
I>Собственно, на этом уже можно ставить точку

Это ты про браузерную морду?
Опять твоя стандартная ошибка — это ж бесплатное приложение.
Оно просто светится мордой, туда ведёт реклама.
Это просто "точка входа", считай, чтобы дать координаты, рассказать о возможностях, показать список фильмов/сериалов/телеканалов.

Но платят-то люди за подписку, которой пользуются на телеке, а не на сайте.

Не, можно, конечно, оплатить подписку с целью смотреть контент исключительно с сайта, ХЗ.
Но что-то мне подсказывает, что в живой природе такие ситуации крайне редки.

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


V>>После нормальной приложухи от сайта хочется блевать, это как выйти из космолёта и сесть в телегу на конной упряжке.
I>А ты ими пользовался? МеГоГо кривой, шо сабля. Иви еще хуже.

Я не могу судить в асболютном смысле, но могу сравнивать с браузерной версией.
И тебе того же советую объективности ради.


I>Ты хоть бы Нетфликс привел в качестве примера или Amazon Prime.

GUI локальной приложухи Нетфликс особо от ivi не отличается по функционалу.
Но в плане контента ivi прикольней, всё-таки у Нетфликс упор на собственный контент, оно им, такое ощущение, "тычет в морду".


V>>Вообще-то, если внутриигровых, то там с вероятностью 99.9% С++.
I>Неважно, сколько там нативного. В нормамальных играх весь верхний слой это скрипты, скрипты, скрипты.

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

И даже здесь ты включил демагогию — lua не описывает GUI, а ты рассуждал, что "бизнес видит, за что платит".
В игрухе клиент видит работу графического движка, писанного на С++, работу низлежащей графической технологии, типа OGL/Metal и т.д., написанных на Си.
(если DirectX, то С/С++)


V>>Лишь относительно недавно, когда унифицировали UWP и десктопную версию.
V>>Еще года 3 назад это было не так.
I>Куда идет тренды, ты наверное понял? Если что, нативную реализацию выбросили.

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


V>>Тимс теперь бесплатный от слова совсем, он теперь как самостоятельный продукт не продаётся.
V>>Ни по какой подписке.
I>Просто другая бизнес-модель. Тимс призван чего то там улучшить с Офисом 365.

Да понятно всё... ))


V>>Скайп не окупился, когда окупится — неизвестно.
I>Не смеши людей. Разработка UI там ничтожные издержки по сравнению со всем остальным.

Это где ты работаешь, разработка GUI — ничтожные издержки.
А приложухи типа Тимы, Слак, Скайп — это серьезные приложухи по меркам остальных проектов на Электрон-подобных фреймворках.

Иначе бы нафига приходили постоянные обновления Скайпа?
Один бы раз сделали и всё...


V>>И убрав несколько функций старого Скайпа, например, вызова GUI-диалога настройки камеры из её драйвера.
V>>Т.е. теперь ХЗ как камеру настроить, если на руках только Skype.
I>Дешманская камера купленая в середине нулевых? У меня все само работает, на всех телефонах и всех ноутбуках

Хоть бы голову включил.
Дешманские камеры не имеют множества настроек.


I>>>А мы говорим про UI. Забыл?
V>>Мы говорим о том, что за GUI на ЖС не платят.
I>И откуда у толп жээс фронтендов ЗП берется?

У этих "толп" невысокая ЗП.
Это сопутствующие расходы.


V>>Способ GUI на WebControl+JS изначально и был создан именно с целью клепать по-быстрому на коленке максимально дешевое GUI.
V>>Это такова официальная генеральная миссия сей технологии и она не изменилась ни на йоту.
V>>И качество+отзывчивость такого GUI — притча во языцех.
I>UI вообще тормозил во все времена.

Последний раз в 1995-м году.
Потом опять стал чуть подтормаживать, когда пошла мода делать GUI на основе WebControl.
Потом опять стал подтормаживать, когда появился WPF.
Потом опять стал подтормаживать, когда драйвером приложухи поверх WebControl стала нода, вместо нейтива или хотя бы дотнета.

На компьютере из 2000-го года, когда нейтивное GUI уже давно летало со скоростью света, современные поделия на Электроне+JS+ноде будут минутами запускаться, потом по десятку секунд реагировать на каждый клик. ))

Кароч, я ХЗ что тут обсуждать, позорище и есть позорище...


I>И когда был на MFC, и когда на WTL, и на QT. Даже консольный UI в дос приложениях тоже тормозил. Как только что более менее нормально — "UI тормозил"

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


I>Тот же Скайп здесь же ругали задолго до его покупки Микрософтом.
I>Отлистай форум да убедись.

Зато до покупки MS им совершалось большего всего VoIP звонков среди других приложений (аппаратную IP-телефонию не берём).
А как MS выпустили первую UWP-версию скайпа...
Да я как её поставил...
Этот ужас, летящий на крыльях ночи...

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

Ну конечно, народ валом повалил со скайпа на конкурирующие технологии, поэтому Скайп до сих пор не отбил вложения.
ИМХО, виной тому ублюдочное решение сделать для UWP "по-быстрому".
Результат известен.

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

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


I>В конце 90х связка MFC и IE была одной из самых популярных тем — см. IE4.

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

Здравствуйте, Ikemefula, Вы писали:

V>>А какой смысл нести всякую чухню, что в С++ нет менеджеров пакетов?
I>Непонятно, что ты понимаешь под менеджером пакетов.

т.е., проблема в тебе?


I>Ты описываешь вариант эмуляции пакетного менеджера при помощи cmake и dpkg и rpm.

Не юли, я описывал apt или yum.


I>Что делать, например, на винде, когда нет ни dpkg ни rpm ?

Для начала выйти на минуточку в гугл.


I>Вероятно, ты предложишь эмулировать средствами nuget

В своей конторе мы распространяем внутренние либы С++ на виндах через NuGet через artifactory.
Для линухов — родными пакетными менеджерами этих систем.

А зачем NuGet "эмулировать"?


V>>Например, CMake — это не утилита сборки проектов, хотя многие далёкие от темы относят её к таковой.
V>>Это утилита описания проектов и их зависимостей, одновременно утилита ресолвинга этих зависимостей.
I>Похоже, её авторы и есть те недалёкие, о которых ты говоришь, т.к. уни утверждают
I>"CMake is an open-source, cross-platform family of tools designed to build, test and package software. "

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

Прочти еще немного её документации — там об этом подробно рассказывается.
В общем, RTFM!

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

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

Здравствуйте, Sinclair, Вы писали:

V>>Еще это утилита описания тех самых пакетов, опять же, сами пакеты утилита упаковывает, она вызывает целевые пакетные менеджеры.
S>То есть я могу взять какой-то C++ проект с гитхаба, запустить на нём CMake, и все пре-реквизиты для сборки этого проекта сами скачаются из публичных репозиториев в нужном для моей платформы виде, и всё соберётся?

Почему CMake?
Я же написал — это уже "второй эшелон".

Если в линуховых make configure есть ресторинг — то да.
В виндовых для С++ проектов восстановления зависимостей делается через nuget restore.

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

Ну вот у нас проекты хостятся на github, я делаю форк, подхватываю зависимости и собираю.
Поищи проекты с packages.config.

У тебя мои проекты не соберутся, потому что надо настроить фиды Nuget, бо по-умолчанию у тебя будет настроен только nuget.org.
Но и там уже полно нейтивных проектов:
https://www.nuget.org/packages?q=tags%3Anative
(потому что https://docs.microsoft.com/en-us/nuget/guides/native-packages)

Еще: https://www.nuget.org/profiles/coapp/
Раньше было несколько независимых открытых реестров NuGet (в т.ч. coapp) для нейтивных библиотек, но они в последние буквально 2-3 года начали массово сливаться в nuget.org.

Cреди проприетарных фидов всё более популярен jfrog.


V>>Но вот я тебе и предложил попробовать ручками выполнить похожие действия, чтобы ты включил здравый смысл — это что, вся индустрия мается этим вручную?
V>>И сам себе ответил бы на свой бред.
S>В последний раз, когда я трогал С++ проект (я уже и не помню, что это было), там было полторы страницы инструкций, что откуда скачать и что куда положить, чтобы оно начало собираться.

У меня такое в Питоне — зависимости не устанавливаются автоматом.
А это один из популярнейших скриптовых языков.

В джаве аналогично — зависимости не устанавливаются автоматом, хотя проектов на Java всё еще больше, чем на C#.

Да и студия до VS 2017 спотыкалась в процессе restore, в сети миллион обсуждений эпохи MSVS 2015.

В общем, было понятно, что тебе очень захотелось примазаться к неплохо продуманной инфраструктуре NuGet, но нет, мимо. ))
Мы давно используем NuGet для обслуживания нейтивных зависимостей под виндами.

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


S>Половина ссылок вела на мёртвые сайты, остальная половина — на устаревшие версии библиотек, которые уже не поддерживались.

Вот демагогище...
Дык, найди проекты на C# времён VS 2015 и ранее, столкнёшься ровно с той же ситуацией.

Здравствуйте, vdimas, Вы писали:

V>Почему CMake?
V>Я же написал — это уже "второй эшелон".
Вы написали, что CMake — это утилита ресолвинга зависимостей. Вот я хочу увидеть проект, в котором CMake зарезолвит зависимости.

V>Если в линуховых make configure есть ресторинг — то да.
V>В виндовых для С++ проектов восстановления зависимостей делается через nuget restore.
Хм. А кросс-платформенных проектов С++ не существует?

V>У меня такое в Питоне — зависимости не устанавливаются автоматом.
При всей моей нелюбви к питону, установка зависимостей в нём всё же предусмотрена из коробки. Это если мы говорим о питоновых зависимостях. Вот как только в нём встречается какой-то натив — тогда да, добро пожаловать в С++.
V>В джаве аналогично — зависимости не устанавливаются автоматом, хотя проектов на Java всё еще больше, чем на C#.
А как же maven?

V>Да и студия до VS 2017 спотыкалась в процессе restore, в сети миллион обсуждений эпохи MSVS 2015.


V>Мы давно используем NuGet для обслуживания нейтивных зависимостей под виндами.
V>Т.е., у тебя было недостаточно эрудиции относительно NuGet, но ты рассчитывал использовать его как аргумент, что является нарушением инженерной этики.
Нет, мне было интересно, как обстоят дела с управлением зависимостями в С++.
Хорошо, что есть nuget. Не вполне понимаю, как управлять зависимостями на линуксе. Впрочем, похоже это неважно, т.к. кроссплатформенного тулчейна для С++ всё равно не существует.

Здравствуйте, Ночной Смотрящий, Вы писали:

KP>>

You can be a good coder in any language (C++, C, Java, Scala, Rust, Haskell, OCaml, Erlang, Python, Ruby, PHP, Node.JS, C# etc.), but willing to work on Golang

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

Почему "кого попало" если требование "you can be good"?
Хорошему программисту освоить +1 язык не является нерешаемой задачей.
Ведь он уже стал хорошим программистом на предыдущем языке.

Тут было бы желание, как грится.
Ну и вот, для желающих перейти на Go удобная вакансия.

Здравствуйте, kaa.python, Вы писали:

НС>>Неважно сколько лет языку, важно количество серьезных проектов, а их более менее много стало совсем недавно. Да и 11 лет для языка — совсем немного.
KP>Docker, Kubernetes, Terraform... Слышал такие слова, или у вас там свой заповедный .NET мирок?

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

Здравствуйте, AleksandrN, Вы писали:

AN>MS периодически забивает на свои, ранее внедряемые, средства разработки.
AN>Для C++ они сначала написали библиотеку MFC, потом забили и сделали WTL.

Э, нет.
WTL был сделан одним из разработчиков для внутренних нужд.
WTL — это небольшая либа поверх ATL.

MS выкатили WTL, но не поддерживали.
А потом и вовсе отдали опенсорсу.

Никогда MFC не заменялось WTL и даже не планировалось.


AN>Продвигали VBA, потом забили и начали продвигать .NET. И на него тоже забьют, когда посчитают нужным.

Уже забили и продвигают .Net Core. ))
Причём, проект, по историческим меркам, считай, только начался, ему еще жить и жить до очередного "забивания".

Здравствуйте, Sinclair, Вы писали:

V>>Почему CMake?
V>>Я же написал — это уже "второй эшелон".
S>Вы написали, что CMake — это утилита ресолвинга зависимостей. Вот я хочу увидеть проект, в котором CMake зарезолвит зависимости.

Бери любой на CMake.
(будем считать, что я тебя "подловил", т.к. здесь ты просил заресолвить, а не восстановить их локально)


V>>Если в линуховых make configure есть ресторинг — то да.
V>>В виндовых для С++ проектов восстановления зависимостей делается через nuget restore.
S>Хм. А кросс-платформенных проектов С++ не существует?

Существуют.
В которых куча поддиректорий в поддиректории build, например.


V>>У меня такое в Питоне — зависимости не устанавливаются автоматом.
S>При всей моей нелюбви к питону, установка зависимостей в нём всё же предусмотрена из коробки. Это если мы говорим о питоновых зависимостях.

Это если разработчик предусмотрел какие-нить requirements.txt.
В плюсах ровно с аналогичной сложностью можно перечислить зависимости для yum, apt, zypper, pacman, NuGet и т.д., т.е. автоматизировать их установку.


V>>В джаве аналогично — зависимости не устанавливаются автоматом, хотя проектов на Java всё еще больше, чем на C#.
S>А как же maven?

Я не говорил, что в джаве нет пакетных менеджеров, их там несколько популярных, в т.ч. упомянутый maven.
Но не сложилось единого мирового реестра.

Просто для поржать — вот дефолотный "центральный" репозиторий:
https://repo.maven.apache.org/maven2/
Пролистай до конца.
Это всё.


V>>Да и студия до VS 2017 спотыкалась в процессе restore, в сети миллион обсуждений эпохи MSVS 2015.
S>

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

И только в одном из обновлений VS 2017 появился новый MSBuld, в котором появился элемент PackageReference и соответсвующая стадия сборки — restore.

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


V>>Мы давно используем NuGet для обслуживания нейтивных зависимостей под виндами.
V>>Т.е., у тебя было недостаточно эрудиции относительно NuGet, но ты рассчитывал использовать его как аргумент, что является нарушением инженерной этики.
S>Нет, мне было интересно, как обстоят дела с управлением зависимостями в С++.
S>Хорошо, что есть nuget.

Ес-но.
Именно поэтому я не мог ошибиться, что ты подразумевал именно NuGet, т.к. на сегодня не существует другого пакетного менеджера, интегрированного в систему сборки проектов.
(по крайней мере в мейнстриме)


S>Не вполне понимаю, как управлять зависимостями на линуксе.

Легко — перечисляя в файле зависимости и подавая этот файл родному пакетному менеджеру как аргумент, т.е. ровно так же как в питоне или node.js.
И это верно не только для C++, ес-но.

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

Собсно, необходимость быть независимым от всего этого зоопарка заставила питон и node.js обзавестись дублирующей функциональностью пакетных менеджеров.
А вот с нейтивными либами похуже (любыми нейтивными, не только С/С++) — там традиционно серьезная зависимость от конкретной платформы.


S>Впрочем, похоже это неважно, т.к. кроссплатформенного тулчейна для С++ всё равно не существует.

Можно сказать, что существует — LLVM.
Ой, это же опять "виртуальный процессор"!

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

Здравствуйте, vdimas, Вы писали:

V>(будем считать, что я тебя "подловил", т.к. здесь ты просил заресолвить, а не восстановить их локально)
Ресолвинг — это и есть восстановление. Если зависимость — от .obj, для которого есть исходник, то ресолвинг — это компиляция.
Если от .lib — то линковка. Если он внешнего пакета, то ресолвинг — это скачивание пакета.

По-прежнему ждём


V>Существуют.
V>В которых куча поддиректорий в поддиректории build, например.
Вот это всё — какие-то семидесятые.

V>Это если разработчик предусмотрел какие-нить requirements.txt.
а если нет, то можно запустить pipreqs.

V>В плюсах ровно с аналогичной сложностью можно перечислить зависимости для yum, apt, zypper, pacman, NuGet и т.д., т.е. автоматизировать их установку.
Для всех? Или для кого-то одного?

V>Я не говорил, что в джаве нет пакетных менеджеров, их там несколько популярных, в т.ч. упомянутый maven.
То есть, всё же устанавливаются.

V>Но не сложилось единого мирового реестра.
Речь не о единости реестра, а о штатном способе инсталляции зависимостей — в том числе и внутри build pipeline.
Как видим, в С++ ничего похожего нет — каждый дрочит как он хочет. Кто-то через nuget, кто-то через apt, кто-то через yum, кто-то просто через externals.

V>Просто для поржать — вот дефолотный "центральный" репозиторий:
V>https://repo.maven.apache.org/maven2/
V>Пролистай до конца.
V>Это всё.
Берём первый попавшийся Java проект на гитхабе: https://github.com/Anuken/Mindustry
Все зависимости качаются (если нужно) в процессе билда. Всё делается одной командой.
Берём первый попавшийся С++ проект на гитхабе. Читаем раздел Integration, впечатляемся.

V>Да понятно, что ответить тебе нечего.
Понятно, что С++ по-прежнему фокусируется на особенностях языка, забивая на тулчейн. "нам не нужны модули, достаточно текстового препроцессора для инклуда хидеров". "Нам не нужен ABI, пусть он остаётся платформенно- и компиляторо-зависимым". Повторное использование в С++ просто имеет самый низкий приоритет. Какая-нибудь убогая нода с самого начала проектировалась для повторного использования, поэтому там из коробки менеджер пакетов. Мейнстримом ноды является "я возьму 99% готового кода, добавлю в него немножко клея и специфической логики, и у меня получится редистрибьютабл приложение". Мейнстримом С++ является "я напишу мой личный код на моей личной машине и скомпилирую под неё же, чтобы запускать его прямо здесь". Все желающие собирать код на машине X так, чтобы он использовался на машине Y — экстремалы.
Все желающие писать код на машине X, чтобы его использовали при сборке на машине Y для исполнения на машине Z — ещё большие экстремалы, и должны страдать.

V>Скорее всего потому, что на тот момент ты не пользовался той функциональностью, про которую спрашиваешь сейчас.
V>А она тогда была реализована через packages-config.
V>И только в одном из обновлений VS 2017 появился новый MSBuld, в котором появился элемент PackageReference и соответсвующая стадия сборки — restore.
Это непринципиальное улучшение. Управление пакетами было и до этого; то, что в msbuild не было автоматического restore, легко лечилось пребилд степом.
Ведь в С++ вы и сейчас предлагаете использовать packages.config, не так ли

V>До этого пакетный менеджер жил отдельно от системы сборки, как оно есть в node.js, питоне и т.д., где для восстановления зависимостей необходимо ручками пинать пакетный менеджер.
Можно ручками. А можно — изнутри сборочного скрипта. А можно, как в С++ — иметь рулоны инструкций про то, как собирать чудо на каждой из платформ.

V>Ес-но.
V>Именно поэтому я не мог ошибиться, что ты подразумевал именно NuGet, т.к. на сегодня не существует другого пакетного менеджера, интегрированного в систему сборки проектов.
V>(по крайней мере в мейнстриме)
maven? gradle? you name it.
Можно посмотреть на то, как устроены GitHub actions для java, С#, node.js проектов.
А можно — на C++. Разница будет видна невооружённым взглядом.

V>Легко — перечисляя в файле зависимости и подавая этот файл родному пакетному менеджеру как аргумент, т.е. ровно так же как в питоне или node.js.
V>И это верно не только для C++, ес-но.
Отлично. То есть для кросс-платформенной сборки, мне нужно поддерживать 100500 "файлов с зависимостями". И то, что мой проект собирается на голой винде, не означает, что он же соберётся на убунту.
Я всё правильно понял?

V>Но вся зоопарковость Linux тут проявляется в полной мере, т.к. одни и те же пакеты в разных сборках Linux могут называться по-разному.
V>И наличие того или иного пакета зависит от воли ментейнеров данной сборки Linux.
Ну, то есть в С++ забит болт на вопросы сборки и дистрибуции, поэтому имеем вот этот вот зоопарк и геморрой на ровном месте. Просто комитету неважно, насколько легко повторно использовать написанный на С++ код.
И это странно — скажем, даже убогий повершелл, в котором специально ограничивали возможность повторного использования, т.к. его цель — это одноразовые однострочники, и тот имеет встроенный менеджер пакетов.
Можно сколько угодно кивать на тёмное прошлое C# и других языков, но по факту получается так, что С++ на поколение отстаёт от "языков для нубов".

V>Собсно, необходимость быть независимым от всего этого зоопарка заставила питон и node.js обзавестись дублирующей функциональностью пакетных менеджеров.
V>А вот с нейтивными либами похуже (любыми нейтивными, не только С/С++) — там традиционно серьезная зависимость от конкретной платформы.
Дело даже не в том, что нейтив платформенно зависим. А в нежелании вообще заниматься вопросами организации сборочного конвеера.

V>Можно сказать, что существует — LLVM.
V>Ой, это же опять "виртуальный процессор"!
И как мне llvm поможет собрать на винде библиотеку для ubuntu?

Здравствуйте, Sinclair, Вы писали:

V>>(будем считать, что я тебя "подловил", т.к. здесь ты просил заресолвить, а не восстановить их локально)
S>Ресолвинг — это и есть восстановление.

Нифига.
Ресолвинг в С++ — это поиск и конфигурирование путей к заголовкам и библиотекам.


S>Если зависимость — от .obj, для которого есть исходник, то ресолвинг — это компиляция.

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


S>Если от .lib — то линковка. Если он внешнего пакета, то ресолвинг — это скачивание пакета.
S>По-прежнему ждём

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

Через полтора года ты сможешь хвастаться всем этим...
И буквально малюсенький вопрос стоит — кто мне будет ЗП платить за этот период? ))


V>>В которых куча поддиректорий в поддиректории build, например.
S>Вот это всё — какие-то семидесятые.

Отнюдь.
Чем дальше, тем больше поддиректорий в поддиректории build.


V>>Это если разработчик предусмотрел какие-нить requirements.txt.
S>а если нет, то можно запустить pipreqs.

С вероятностью успеха примерно 50%.


V>>В плюсах ровно с аналогичной сложностью можно перечислить зависимости для yum, apt, zypper, pacman, NuGet и т.д., т.е. автоматизировать их установку.
S>Для всех? Или для кого-то одного?

Для каждой сборки Linux свой файл.
Спасает то, что многие сборки являются как бы ответвлениями от "материнкой" сборки.
Например, чуть ли не половина сборок базируются на DEB-Linux.


V>>Я не говорил, что в джаве нет пакетных менеджеров, их там несколько популярных, в т.ч. упомянутый maven.
S>То есть, всё же устанавливаются.

Откуда именно?


V>>Но не сложилось единого мирового реестра.
S>Речь не о единости реестра, а о штатном способе инсталляции зависимостей — в том числе и внутри build pipeline.

Этого в Джава нет.
Хотя я понимаю и унутре всячески сочувствую твоему представлению о прекрасном.


S>Как видим, в С++ ничего похожего нет — каждый дрочит как он хочет. Кто-то через nuget, кто-то через apt, кто-то через yum, кто-то просто через externals.

С++ тут не при чём, это заморочки платформенного уровня.


V>>Просто для поржать — вот дефолотный "центральный" репозиторий:
V>>https://repo.maven.apache.org/maven2/
V>>Пролистай до конца.
V>>Это всё.
S>Берём первый попавшийся Java проект на гитхабе: https://github.com/Anuken/Mindustry
S>Все зависимости качаются (если нужно) в процессе билда. Всё делается одной командой.

Не-не-не.
Никакой "одной командой", и никаких "в процессе билда".
Это разработчики либы нехило озаботились впендюрить такую функциональность.
Но "стандартной" такой нет.

А так-то, если поднапрячься, то в любой технологии можно впендюрить подобное.
Будет ли это что-то доказывать? — да аж ничего.
Незначительные флуктуации вакуума...


S>Берём первый попавшийся С++ проект на гитхабе. Читаем раздел Integration, впечатляемся.

Была бы у тебя совесть, ты бы точно так же подобрал наоборот.


V>>Да понятно, что ответить тебе нечего.
S>Понятно, что С++ по-прежнему фокусируется на особенностях языка, забивая на тулчейн.

Рехнулся?
Вроде был адекватным несколько постов?

При чём тут "особенности языка"?
Речь о зависимостях.

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

В итоге, С++ проектам приходится уметь собираться в зоопарке архитектур, где отличия — по кол-ву поддерживаемой функциональности.
Ты эта... посмотрел бы хоть раз на какой-нить Config.h, который конфигурируется целью make configure.
Там будет полторы-две сотни макроопределений навроде #PLATFORM_HAS_EVENTFD 1

В исходниках затем ветвление на макропроцессоре: есть в АПИ ОС eventfd — пользуем, нет — эмулируем на пайпах и регистре-защёлке.


S>"нам не нужны модули, достаточно текстового препроцессора для инклуда хидеров". "Нам не нужен ABI, пусть он остаётся платформенно- и компиляторо-зависимым". Повторное использование в С++ просто имеет самый низкий приоритет. Какая-нибудь убогая нода с самого начала проектировалась для повторного использования, поэтому там из коробки менеджер пакетов.

Поэтому она тормозит.
Ты реально решил вот прямо сейчас повторять мантры религии из 2005-го?
Серьёзно? ))

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


S>Мейнстримом ноды является "я возьму 99% готового кода, добавлю в него немножко клея и специфической логики, и у меня получится редистрибьютабл приложение".

Менйстрим ноды сделан плюсовиками, вроде меня.
Потому что Node.js — это насквозь нейтивная технология, и добавлять туда либы — это надо уметь, это надо понимать, как устроены JS-объекты, как нужно с ними общаться, чтобы не потекла память или не произошёл проход по памяти и т.д.
В общем, это не для средних умов технология, что касается добавления туда библиотек, основные которые являются обёртками над хорошо известными C/C++ библиотеками.

С другой стороны — ничего нового, под Lua была примерно та же история...


S>Мейнстримом С++ является "я напишу мой личный код на моей личной машине и скомпилирую под неё же, чтобы запускать его прямо здесь". Все желающие собирать код на машине X так, чтобы он использовался на машине Y — экстремалы.

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


S>Все желающие писать код на машине X, чтобы его использовали при сборке на машине Y для исполнения на машине Z — ещё большие экстремалы, и должны страдать.

Поплачь, поплачь.
Вызови сочувствие у читателей...

А это... как его... ты сайтом не ошибся, случаем?
Домохозяйки тусуются не здесь.


V>>Скорее всего потому, что на тот момент ты не пользовался той функциональностью, про которую спрашиваешь сейчас.
V>>А она тогда была реализована через packages-config.
V>>И только в одном из обновлений VS 2017 появился новый MSBuld, в котором появился элемент PackageReference и соответсвующая стадия сборки — restore.
S>Это непринципиальное улучшение.

Хрен там, это именно то, о чём ты спрашивал.
Т.е., относительно недавняя функциональность.
И твой вопрос выдал тебя с головой — ты никогда не конфигурировал проекты с большим кол-вом зависимостей.
Потому что на момент хождения VS2015 или первых версий VS2017 в наличии была такая функциональность, которая не позволила бы задавать вопросы так, как ты задал.
Ты бы сидел молча и не отсвечивал. ))


S>Управление пакетами было и до этого; то, что в msbuild не было автоматического restore, легко лечилось пребилд степом.

Ой нубство...
Что угодно можно вылечить чем угодно.
Только это всегда закат солнца вручную.
MS Build однажды предложил автоматизацию.

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


S>Ведь в С++ вы и сейчас предлагаете использовать packages.config, не так ли

Но ты же им пользовался до VS 2017 SP2?
Не умер?

И нода же пользуется отдельным файлом зависимостей?
И питон?
А почему С+ нельзя?


V>>До этого пакетный менеджер жил отдельно от системы сборки, как оно есть в node.js, питоне и т.д., где для восстановления зависимостей необходимо ручками пинать пакетный менеджер.
S>Можно ручками.

Не можно, а нужно, т.к. другого пути нет.


S>А можно — изнутри сборочного скрипта.

Пошла демагогия.
Или, таки, нубство?
Ты всерьёз считаешь, что для сборки С++ запрещено писать сборочные скрипты? ))

У меня такое сложилось ощущение, что ты пока не определился, что именно ты пытаешься доказать.
Судя по всполохам мыслей — чисто потрындеть ни о чём.


S>А можно, как в С++ — иметь рулоны инструкций про то, как собирать чудо на каждой из платформ.

С++ не обязывает тебя к этому — пиши такие же скрипты.
Собсно, в большинстве С++ проектов есть готовые скрипты примерно под десяток платформ или больше.
Но соберу проект и без них под любую платформу.
Потому что хорошо работающий код бесценнен, а потраченное время нуба на "а как собрать этот проект???" ничего не стоит.
Не умеешь — потерялся и не раздражаешь.
Идёшь семечками торговать.


V>>Именно поэтому я не мог ошибиться, что ты подразумевал именно NuGet, т.к. на сегодня не существует другого пакетного менеджера, интегрированного в систему сборки проектов.
V>>(по крайней мере в мейнстриме)
S>maven?

Не имеет центрального реестра, поэтому не работает в ситуации, когда ты форкнул проект с github.


S>Можно посмотреть на то, как устроены GitHub actions для java, С#, node.js проектов.
S>А можно — на C++. Разница будет видна невооружённым взглядом.

Потому что детсад и то и другое.
Открой для себя TeamCity.

Вот нафига С++ разработчикам технологии из середины нулевых?
Тебя устраивает — твой выбор.
Меня нет, бо это для дохозяек и прочего стада обезьянок.
Их выслушают, улыбнутся, и забудут о них через минуту.
Мало ли кто там жужжит, стукаясь о стекло, не понимая, что это всего лишь стекло?
Форточка рядом...
Всё-равно всё реально работающее написано на плюсах.
И нода, и питон, и дотнет.


V>>Легко — перечисляя в файле зависимости и подавая этот файл родному пакетному менеджеру как аргумент, т.е. ровно так же как в питоне или node.js.
V>>И это верно не только для C++, ес-но.
S>Отлично. То есть для кросс-платформенной сборки, мне нужно поддерживать 100500 "файлов с зависимостями".

На практике 5 платформ: DEB, RPM, Pacman, Zypper, Nuget.
Остальное экзотика.
И даже экзотики вряд ли наберётся более 10 вариантов к перечисленному.


S>И то, что мой проект собирается на голой винде, не означает, что он же соберётся на убунту.

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


S>Я всё правильно понял?

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


V>>Но вся зоопарковость Linux тут проявляется в полной мере, т.к. одни и те же пакеты в разных сборках Linux могут называться по-разному.
V>>И наличие того или иного пакета зависит от воли ментейнеров данной сборки Linux.
S>Ну, то есть в С++ забит болт на вопросы сборки и дистрибуции

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


S>поэтому имеем вот этот вот зоопарк и геморрой на ровном месте.

Опять нет.
Весь этот миллион кода не спроста по-разному сконфигурирован.
А по банальной причине — универсального ответа на любой вопрос нет.


S>Просто комитету неважно, насколько легко повторно использовать написанный на С++ код.

Опять нет.
На уровне исходников проблем нет.
Главное что? — предоставить соотв. ср-ва для написания максимально-эффективного кода для данной платформы.
Все ср-ва сборки и конфигурирования тоже есть, иначе было бы невозможно включать эти проекты (а их многие-многие тысячи) в дистрибутивы Linux.


S>И это странно — скажем, даже убогий повершелл, в котором специально ограничивали возможность повторного использования, т.к. его цель — это одноразовые однострочники, и тот имеет встроенный менеджер пакетов.

Это потому что сама Windows не имеет.
Отсылаю твои претензии к MS.


S>Можно сколько угодно кивать на тёмное прошлое C# и других языков, но по факту получается так, что С++ на поколение отстаёт от "языков для нубов".

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


V>>Собсно, необходимость быть независимым от всего этого зоопарка заставила питон и node.js обзавестись дублирующей функциональностью пакетных менеджеров.
V>>А вот с нейтивными либами похуже (любыми нейтивными, не только С/С++) — там традиционно серьезная зависимость от конкретной платформы.
S>Дело даже не в том, что нейтив платформенно зависим. А в нежелании вообще заниматься вопросами организации сборочного конвеера.

Ты это сейчас всёрьез?
Большинство проектов в *никсах собираются так:

make configure

потом:

make

потом:

make install

И это норма еще с 1985-го.

Но, блин, твои оценочные суждения доставляют, однако.
Я тоже львиную долю рабочего времени провожу в виндах, но достаточно эрудирован в 4-5 самых популярных сборках Linux.
А в которых не эрудирован — стараюсь не рассуждать, больше спрашиваю.

Твой основной косяк — тебе нравится спорить на те темы, в которых ты ни бум-бум.
Ты тем самым экономишь себе время, собирая ключевую информацию от оппонентов, но в итоге всё-равно получается поверхностность.

Я помню наши споры про соционику.
Помню твои восклицания, мол, прочитал о Есенине — да, это я.
Это как раз нормально.
Ненормально, когда ДонКихот говорит, да, я Есенин.
Потому что ты не Дн-Кихот.

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

А внутреннего стремления к абсолютному владению предметом у тебя нет — т.к. тебе достаточно сравнивать себя с окружающими.
Это или безотцовщина или отец твоим воспитанием не занимался.

Кароч, мне еще в прошлые разы надоела твоя лженаучная чушь (определение лженауки — это когда ошибочные утверждения подаются/подкрепляются ссылками на официальную науку).
Я, конечно, тоже обожаю оригинальные идеи, но если они примитивные и уже доказали свою нежизнеспособность — это просто скукатень.


V>>Можно сказать, что существует — LLVM.
V>>Ой, это же опять "виртуальный процессор"!
S>И как мне llvm поможет собрать на винде библиотеку для ubuntu?

RTFM!

Здравствуйте, vdimas, Вы писали:

V>Большинство проектов в линухах собираются так:
V>make configure

V>потом:
V>make

V>потому:
V>make install

V>И это норма еще с 1985-го.

Они так действительно собираются в ходовых конфигурациях, но только если версии библиотек дистрибутива те же, что нужны пакету. И чтобы это работало стабильно, нужны большие усилия авторов проектов для написания конфигов autoconf и разруливания всевозможных вариантов опций и зависимостей. Все библиотеки при этом устанавливаются вручную, разумеется.
Героическими усилиями все это решаемо, конечно.