Здравствуйте, Sinclair, Вы писали:
V>>Ну, в дотнете отродясь не являлось, это было именно нахождение и рекурсивное построение зависимостей. S>Предлагаю закрыть бессмысленный технологический спор. Речь о том, что у всех не-динозавров есть решения типа S>
S>gem install
S>pip install
S>npm install
S>go get
S>
S>и т.д. И в С++ неизбежно появится что-то вроде этого.
Я давал уже тебе ссылки.
Основные претенденты на лидерство в ближайшее десятилетие vcpkg и Conan.
Вангую за vcpkg.
Он гладко интегрируются с CMake и MSBuild-проектами С++, т.е. виндовыми.
Если MSBuild (ну а вдруг) когда-нибудь интегрируется с CMake и Make, то будет еще один.
Но не 115-й способ собирать проекты, а еще один способ способ доставлять зависимости, что на практике будет означать минимальное кол-во дополнительных строк описания интеграции в систему билда, т.к. зависимости в CMake уже описаны.
V>>И предложенное тобой — изобретение нового способа собирать С++ проекты, расцениваю как неудовлетворительное. )) S>Вы опять спорите с голосами в голове. Техническое решение предложили вы, я вообще ничего не писал о "способе реализации".
Про 115-е было от тебя.
По-сути, это было такое предположение, что в этой области обитают дебилы, которые ищут себе проблемы.
Странное предполжение, т.к. происходить может лишь обратное — сообщество пытается проблемы решить.
А проблемы были созданы до нас, вот этой современной зоопарковостью линухов.
И были созданы в те времена, когда ни о какой онлайн-доставке зависимостей речи не шло.
Так-то, был бы у нас один Linux, примерно как есть одна Windows и MacOS (пусть даже одновременно нескольких используемых версий) — вопрос вообще никогда не стоял бы, хосподя...
V>>Проекты С++ уже давно собираются MSBuild на Windows. V>>MSBuild уже есть на линухах. V>>Его просто надо доработать, например, дописать к нему плагины плюс файлы-конфигурации targets в поставке для конкретной платформы. S>Совершенно неважно, доработаете ли вы мсбилд или у вас там будет какой-нибудь cpp restore. S>Вы всё ещё барахтаетесь на детсадовском уровне — "как мне сделать xxx". S>Чтобы из него выйти, надо научиться задаваться вопросами типа "зачем", а не "как".
Вот в этом твой косяк.
Ты не ориентируешься в современной ситуации, но порассуждать охота.
Ссылку я тебе дал, поработай над эрудицией.
S>С точки зрения современного С++ разработчика, вы предлагаете новый способ собирать проекты на линуксе.
Это ты предлагаешь, от непонимания, как всё устроено и работает.
S>Потому что сейчас никто в здравом уме не собирает С++ на линуксе через msbuild, так что его наличие для линукса нерелевантно.
Опять мимо.
С++ проекты собираются по-разному.
Но всё это множество вариантов можно свести к make configure, make, make install.
Или к build.bat/build.sh.
А что там под капотом — какая разница тому, кому надо лишь собрать проект, не погружаясь в подробности?
V>>Э-э-э, не понял вопроса? S>Оно и видно.
Это к тебе обращались — ты не понял вопроса? ))
S>>>Всё, что вы получили — ещё один способ собирать C++ проекты на линуксе. V>>Я получу способ не просто доставлять зависимости в проект, а возможность тонко управлять этим процессом. S>Что-то мне подсказывает, что это не будет сильно тоньше, чем в CMake.
Тоньше, ведь в CMake я просто указываю ID продуктов и их модулей, ограничения на версии.
Но я не указываю, откуда их брать и в каком виде.
Например, для девелоперской сборки иногда имеет смысл получить зависимый проект в исходниках, чтобы зайти в него дебаггером.
А для релизной достаточно зависимости на бинарный пакет.
Вариантов-то дофига.
Например, готовим одновременно выпуски над LTS-версиями зависимостей и самыми актуальными, в итоге можно добавить еще конфигураций в проект, где для каждой конфигурации будут свои ограничения на версии зависимостей, где эти ограничения могут быть не константами, а переменными — в CMake такое запросто, в отличие от простейших requirements.txt.
Мне тут даже несколько странно, что приходится всё это пояснять на такой итерации.
V>>И не обязательно "всё переделывать" в уже имеющихся проектах. S>
Угу, в этом твой косяк — пытаться рассуждать о вещах, в которых не компетентен.
V>>Конкретные цели и элементы есть как встроенные в MSBuild, так и существующие в виде внешних плагинов. V>>Не думаю, что плагин для запуска CMake прям такой уже был бы сложный. S>Ага. То есть у нас msbuild запустит CMake, тот построит нужные файлы, и запустит msbuild...
Ну тебя же не смущает, что MSBuild многократно запускает MSBuild?
А Make многократно запускает Make?
Или ты и этого не знал?
И про CMake ты опять в спешке упустил — он не собирает проекты, он окучивает стадию configure.
Собирает уже Make или MSBuild.
Т.е., цепочка там такая может быть:
configure: MSBuild+CMake
build: MSBulid
package: Nuget
install: CMake или Nuget
Существующая сегодня цепочка аналогичная за тем исключением первой строки:
configure: CMake
build: MSBulid
package: Nuget
install: CMake или Nuget
Судя по твоим рассуждениям, этого ты тоже не знал.
S>Что-то не ладится. Главный вопрос: вот существующие проекты как перевести на вашу будущую технологию? Кто это будет делать, и зачем?
Если ты уже перешёл по ссылке и прочитал, то вопрос должен быть исчерпан.
"Кто и зачем" и прочие эмоциональные от тебя нон-стоп вещи периодически провоцируют меня на ответ в этом же бестолковом духе.
Завязывай, бо мне слишком много чего есть ответить прямой речью.
Давай образно, у нас примерно такое обсуждение, ты начал:
— вот я взял электросамокат, нажал педаль и сразу поехал, а ты пока свою машину заправишь, пока масло проверишь — сликом много возни!
— ваши самокаты обслуживаются специальным сервисом и вам не принадлежат, и потому всегда готовы, а у нас исторически куча владельцев личных автомобилей... но да, тема удобная, у нас уже вовсю используют подобные сервисы, и вот рядом со мной построили сервис, который будет содержать мою машину в состоянии немедленной готовности к старту, хотя, постройка этого сервиса оошлась чуть дороже, чем постройка сервиса для самокатов... но и фиг с ним, это одноразовые затраты, верно?
— Что? Вам сервисы? Зачем? Вы же все там в своём коконе закуклились, куда вы лезете???
— через минуту проехал на 100 км/ч мимо ползущего на 20км/ч самокатчика и даже не посмотрел в его сторону...
V>>Дык, MSBuild всё еще сырой, не зря его версии скачут чуть ли не в два раза быстрее версий Студии. S>Дело не в MSBuild, а в том, как реализовать на нём кроссплатформенную сборку.
Это шутка такая?
S>Всё упирается в то, что под виндой уже написаны targets и props, рассчитанные на vc.
Точно "упирается"? ))
Откуда тогда там взялись targtes и props под clang?
Ты иногда как скажешь, так не знаешь, как реагировать...
И вообще, в Visual Studio ты можешь по ssh зайти на Linux (в докер, допустим), собирать и визуально отлаживать в привычной манере свой код.
Чем я обычно и занимаюсь по работе.
S>А для того, чтобы собирать, допустим, на линуксе те же самые проекты, таргетящие винду, придётся упасть и отжаться.
Но вообще ты хочешь странного.
Кросс-платформенная разработка — это одно, а кроссплатформенный билд — чуть другое.
Для этого должен быть воссоздан кросс-платформенный тулчейн.
Например, в линухах ты не можешь собирать из одной сборки Linux под другую, но есть докер, т.е. виртуальное окружение.
Для виндов есть wine.
V>>Но он движется в правильном направлении. V>>Разумеется, рано или поздно он покроет и C++ проекты, причём, кроссплатформенно. S>Насчёт "разумеется" я вовсе не уверен. Потому что ни Микрософт, ни Линукс комьюнити это не интересно.
Интересно и тем, и другим, т.к. облака в MS на линухах.
И всё чаще под Linux разрабатывают из под Windows.
Выходит, ты и этого не знал.
V>>Но нужна будет в какой-то момент готовая инфраструктура, а именно — наполнение многими тысячами нетивных пакетов под разные платформы репозитория nuget. S>Воот, вы уже начинаете потихоньку понимать, что проблема — вовсе не в том, чтобы написать .targets, который использует для сборки gcc вместо vc.
Да это вообще не проблема, ес-но.
Прблемы всегда инфраструктурного характера, остальные решаются относительно малой кровью.
S>Кто будет делать это наполнение?
А кто уже наполнил nuget тысячами нейтивных проектов?
S>Как вы их собираетесь мотивировать?
Удобством.
А как еще?
S>Вот это — продуктовые вопросы, и на них удовлетворительных ответов нет.
Та самая паника из истории про самокаты? ))
S>Если бы комитет взялся продвигать какое-то одно решение — неважно, msbuild, nuget, или что-то особенное — то был бы шанс на консолидацию усилий.
Комитет чего?
S>А без этого над вами просто посмеются и всё.
Конкретно ты просто паникуешь.
S>Но эти технические проблемы — ничто перед вопросом "а как сделать так, чтобы в мире, заполненном телегой, вайбером, ватсаппом и вконтактом, вашим мессенджером пользовался хоть кто-то".
Но почему-то появились и телега, и вайбер и т.д.
Хотя были и скайп, и ICQ, и google-talk/hangouts/duo.
V>>В итоге пришлось аж лезть на сайт билд-машины ActiveState Python и там формировать образ специфичной инсталляхи Питона с конкретно-прописанными зависимостями библиотек, бо в дефолтной инсталляхе это всё не взлетало из-за конфликтов версий зависимостей других модулей. S>Ужас какой.
Добро пожаловать в Питон! ))
V>>Но по твоей ссылке настраивается еще несколько репозиториев. S>Вы так говорите, как будто это плохо.
Конечно, плохо.
Ты же хотел взять проект 10-тилетней давности и чтобы он собрался.
А там захардкоженные ссылки в интернет.
S>Кто-то из вендоров выбирает публикацию через свой репозиторий — это совершенно нормально. Вот вы же сами мне рассказываете о том, что в ваших проектах используются дополнительные репозитории nuget.
Но эти вещи не захардкожены в проекте.
И мы уже переезжали более одного раза и в системе контроля версий, и в реестре пакетов.
А проекты те же.
Мир изменчив, поэтому захардкоженные ссылки — это убожество.
Показывает весь блеск и нищету, как грится.
V>>Но и тут не прокатило — когда абстракции над железом/архитектурой станут бесплатными, тогда я приму этот аргумент. V>>Особенно в контексте этого спора — сравнения с С++. S>Всё наоборот — это вы пытаетесь съехать с темы сборки на тему сравнения байт-кода с нативом.
Да это твой был аргумент про байт-код джавы, совершенно нелепый в этом обсуждении.
Я ХЗ почему тебе так и не удалось научиться контроллировать свой экстремизм...
Каждый божий раз тебя колбасит от вдумчивого собеседника к какой-то наркомании нифига не соображающей, и это потребляет терпение.
S>На голубом глазу делая вид, что не приводили только что LLVM как аргумент кроссплатформенности C++.
Привёл, попросил включить голову. ))
Когда LLVM покажет сравнимое кач-во оптимизации с vc, gcc, intel compiler, тогда можно будет чуть по-другому смотреть на этот аргумент.
Но пока оно есть как есть.
V>>И да, по одной из приведённых тобой ссылок, таки, некоторые зависимости для джава-проекта загружались в исходниках, просто ты невнимательно смотрел, что там по твоим ссылкам написано. )) S>Ну и отлично — вы сами же опровергли свой собственный аргумент.
Какой? Я сказал, что происходящее "круче", выяснилось, что "не круче".
Ну пусть на сравнимом уровне, но фиг с ним — я высмеял оба варианта как не отвечающие современным требованиям.
Нахрена мне такая система сборки, где я должен ручками писать скрипт на полторы тыщи строк?
Знаешь, почему CMake стал таким популярным?
Не потому что "вот так случилось", перевод на него проектов бывал относительно болезненным, и у нас в т.ч.
Там банальная причина — это поддержка библиотек.
Сам CMake обрастает библиотеками, мы у себя тоже разработали несколько библиотек нему.
В итоге, на описания целевых проектов любо-дорого посмотреть.
И еще сам язык CMake заточен на конкатенацию и обработку строк и строковых списков, в т.ч. достаточно нетривиальную, управлемую условиями.
А в том же maven эти базовые операции представляют из себя ужас, летящий на крыльях ночи. ))
S>Только что загрузка исходников в С++ проекте была "в разы круче, чем в java", и тут же оказывается, что джава может делать то же самое — просто я невнимательно смотрел. S>Прикольно с вами спорить — можно просто хмыкать, а вы сами себя закопаете.
Или ты опять накосячил — так и не посмотрел на свои ссылки.
Ссылку на джава-проекты, где среди прочих тоже были ссылки на проекты в исходниках, ты дал уже в следующем сообщении.
И было сказано "это даже круче", т.к. система сборки по моим ссылкам делала больше, чем по твоим, на которые я отвечал.
И насколько я понимаю, тебе бы стоило посыпать голову пеплом, когда я привёл аналогичные твоим ссылкам для С++, а не искать, к чему бы еще прицепиться. ))
Как ни крути, подход POM.XML — это деревянная телега из 19-го века, где лошадь заменили паровым двигателем.
В общем, бесконечно далеко от представлений о современном инструменте описания сборки.
Здравствуйте, vdimas, Вы писали:
V>Я давал уже тебе ссылки. V>Основные претенденты на лидерство в ближайшее десятилетие vcpkg и Conan.
V>Вангую за vcpkg.
V>Он гладко интегрируются с CMake и MSBuild-проектами С++, т.е. виндовыми.
Отлично. Вижу, вы всё же ознакомились с положением дел в отрасли. Начали мы с того, что люди, неспособные самостоятельно собрать заброшенный проект под нужную им платформу, вообще на пляже не нужны.
Дальше пошли рассказы про то, что без вас никто не напишет менеджер пакетов для С++ (ну, мы уже в курсе, что многопоточность, гуй на IWebBrowser2, и архитектуру учётных систем изобрели лично вы, а до вас все топором брились и молились колесу). Потом про то, что msbuild почти готов овладеть линкусом, и "Разумеется, рано или поздно он покроет и C++ проекты, причём, кроссплатформенно". Затем от "разумеется" мы перешли к "ну, а вдруг", и к тому, что аналоги у npm install для C++ всё же есть.
Жаль, конечно, что вы потратили столько времени на кривляния. Я даже не знаю, с чем это связано — с тем, что вы сами про них не знали два дня назад, то ли просто с вашей манерой разбавлять каждую ложку полезной инфы бочкой бахвальства и оскорблений. Если честно, и знать особо не хочу.
V>Или ты опять накосячил — так и не посмотрел на свои ссылки. V>Ссылку на джава-проекты, где среди прочих тоже были ссылки на проекты в исходниках, ты дал уже в следующем сообщении. V>И было сказано "это даже круче", т.к. система сборки по моим ссылкам делала больше, чем по твоим, на которые я отвечал.
Было сказано "в разы круче" — обычное надувание щёк в вашем любимом стиле. V>И насколько я понимаю, тебе бы стоило посыпать голову пеплом, когда я привёл аналогичные твоим ссылкам для С++, а не искать, к чему бы еще прицепиться. )) V>Как ни крути, подход POM.XML — это деревянная телега из 19-го века, где лошадь заменили паровым двигателем. V>В общем, бесконечно далеко от представлений о современном инструменте описания сборки.
ну, вы же просили список зависимостей в XML — вот вам список зависимостей в XML.
При том, что речь о довольно-таки древней жаве, которая вовсе не передовик современного производства.
На этом дискуссию можно заканчивать — то, что я хотел узнать, я узнал.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[29]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ikemefula, Вы писали:
V>>Ты бегаешь от сути проблемы языка JS. I>Это как раз бенефит, для разработки простых вещей тебе кроме dev tools даже редактор не нужен.
Ну вот мы и пришли к сути, которую все и так знают, в общем-то.
В кач-ве редактора блокнотик, в кач-ве отладчика — примитивные devtools браузера.
ХЗ зачем было столько бегать... ))
V>>И мне жаль неплохой, в общем-то, язык TS из-за его вынужденной совместимости с JS. V>>Но эта гиря, походу, навечно. I>Это целенаправленное решение
Мы все знаем прошлое этого решения.
Впрос стоит — что делать с этим в будущем?
I>>>Надо бы без "если". V>>Если речь об отладке, то надо как я написал. I>Я и говорю — надо без "если". В силу нативности плюсов такое принципиально невозможно. Глупо с этим спорить.
"Такое" — это что именно?
Ты только что рассуждал об отладке, я тоже.
I>>>Похоже, ты старательно избегаешь эти примеры V>>Я могу о них не знать — это же было твоё утверждение. V>>Просто ты не можешь его подтвердить. I>Очевидно, что ты старательно пропустил все примеры
Ну ты же сам говорил, что я хреновый телепат.
А здесь ты ни одного примера не привёл.
V>>Какие именно? Что я решил, что ты фронтенд разработчик? V>>И ты всё-равно меня не поправил пока, в какой области работаешь. I>Какой смысл что либо тебе доказывать
Дать инфу ты назвал доказать.
Бредятина.
Но я догадываюсь о причинах твоей скромности, ес-но.
V>>Я дал тебе ссылки на ЗП+бонусы для нейтивных тимлидов, там примерно твоего стажа обычно достаточно, кто-то же должен упорядочивать основную массу более молодых разработчиков... I>Единичный пример это не статистика.
Это вводишь строку поиска тимлидов и получаешь выборку.
Я же предлагал тебе самому проверить.
И в другой раз, когда тебе захочется сравнить расклады в различных технологиях — для объективности ищи вакансии на примерно свой стаж.
Иначе ты так и будешь сравнивать себя со вчерашними или сегодняшними студентами.
Насколько я понимаю, твой стаж в р-не 20 лет плюс-минус?
Это ведь дохренищща...
V>>Еще я знаю ситуацию в Белоруссии, что там редко работают на заграничного работодателя напрямую, чаще оформлены в местной же конторе, примерные ЗП в которых я тоже знаю. V>>Мои оценки близки к истине, даже если ты занят не во фронтенде, а на бэкенде на JS. I>Ну да, разброс ЗП всего от 100$ до 8000$ судя по hh
За чистый JS $8000 не платят, ес-но.
V>>Практически единственный для тебя выход в вашей реальности — самому создать подобное предприятие, т.е. быть его владельцем. I>И снова телепатия.
Это был совет, а не телепатия.
V>>Тогда ты сможешь сократить разрыв в доходах примерно до 2-х раз. I>2х раз относительно какой именно цифры?
Я приводил более одного раза.
V>>И если ты до сих пор этого не сделал, со своими демонстрируемыми амбициями, то ты еще более странный тип, чем пытаешься казаться. I>А на кой ляд мне это делать?
Мой жизненный опыт подсказывает, что твоя жена (если есть) была бы не против повышения твоих доходов в разы.
Ды и ты бы сам не отказался.
Рецепт я тебе озвучил, он работает, у меня у самого была контора одно время.
Просто случилось так, что опытным плюсовикам стали более-менее платить и без этой головной боли.
Тот самый реннесанс нейтива в конце нулевых.
Плюс кучно пошли мобильные устройства, сразу повысился спрос на нейтивных программистов.
А он общий на все области IT, бо нетивному программисту всё-равно что программировать — кодеки, драйвера, сетевые протоколы, составные части ОС, виртуализацию, VM для байткодов ваших абстракций, графические либы, шейдеры и т.д. до бесконечности.
Re[35]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Основные претенденты на лидерство в ближайшее десятилетие vcpkg и Conan. V>>Вангую за vcpkg. V>>Он гладко интегрируются с CMake и MSBuild-проектами С++, т.е. виндовыми. S>Отлично. Вижу, вы всё же ознакомились с положением дел в отрасли.
Видел бы — не спрашивал бы всякую ерунду и не делал слишком громких заявлений.
Я не хотел приводить vcpkg в пример, бо еще рано, надо бы еще лет 5 дать на набор жирка.
А к тому моменту не понятно, кто будет в лидерах.
Но лидеров останется немного, это к бабке не ходи.
CMake уже сожрал 99% билд-задач в новых проектах, а большинство поддерживаемых старых на него к 2021-му году уже перепрыгнули.
Просто ни дай боже какой-нить пакетный менеджер С++ начнёт совсем сдавать позиции, типа как начал MS Teams, и добровольно отдастся CMake, что в CMake появится возможность подгружать зависимости онлайн изкаробки, типа как MS Teams теперь бесплатно доступна в Office 365, и всё — и ситуация опять поменяется.
S>Начали мы с того, что люди, неспособные самостоятельно собрать заброшенный проект под нужную им платформу, вообще на пляже не нужны.
В C# та же история, 15-тилетней давности проект с лохматыми зависимости ты вряд ли одной командой соберёшь.
Будешь разбираться, исправлять, опять разбираться/исправлять и так по-кругу.
Я такое уже проходил более одного раза.
S>Дальше пошли рассказы про то, что без вас никто не напишет менеджер пакетов для С++
Не допилит MSBuild+Nuget для Linux для поддержки нейтивных проектов, я же сразу сказал, что пока реально работает только NuGet под виндами в этой реальности.
Остальное постольку-поскольку, т.е. скорее нет, чем да.
Говорилось о текущих приоритетах .Net Core разработчиков, которые этот MSBuid уже портировали на Linux, в т.ч. для нейтивных проектов.
Но требуется доводить это всё до ума, чем они явно в ближайшие годы заниматься не будут.
Вопрос реально подвис в воздухе, ты об этом был не в курсе, ну так я тебе и озвучивал.
S>ну, мы уже в курсе, что многопоточность, гуй на IWebBrowser2, и архитектуру учётных систем изобрели лично вы, а до вас все топором брились и молились колесу
Если "я" — это плюсовый программист из второй половины 90-х, то да, многопоточное GUI (и вообще асинхронщина) — это всё прошло обкатку на плюсах в те годы, т.е. использовалось примерно на 10 лет раньше, чем в других технологиях.
HTML-Dialog аналогично, тоже примерно на 10 лет раньше, чем стало мало-по-малу появляться в заметных кол-вах на других технологиях.
Я понимаю, что тебя это бесит, но не понимаю, зачем унижаться еще больше?
S>Потом про то, что msbuild почти готов овладеть линкусом
Для только что вышедших из леса краткая сводка новостей 5-тилетней давности:
— MSBuild овладел Linux с первым выпуском .Net Core.
S>и "Разумеется, рано или поздно он покроет и C++ проекты, причём, кроссплатформенно".
Так уже покрыл, но лишь для части сценариев.
S>Затем от "разумеется" мы перешли к "ну, а вдруг", и к тому, что аналоги у npm install для C++ всё же есть.
Все же нет.
Наполнение vcpkg на прямо сегодня неудовлетворительное, т.е. это как npm, у которого отобрали пакеты из репозитория.
Например, у Питона тоже есть/были альтернативные пакетные менеджеры (та же Анаконда), но рассуждать о них сегодня неинтересно, т.к. актуальность репозиториев отстаёт от pip.
В общем, всё течёт, всё изменяется...
О чём-то еще рано говорить, о чём-то уже поздно.
S>Жаль, конечно, что вы потратили столько времени на кривляния.
Обиделся? ))
Понимаю, Акела сделал столько резких заявлений и промахнулся...
А что помешало самостоятельно набрать в гугле "C++ package manager list".
О чём ты думал, накручивая на максимум свой сарказм?
V>>Или ты опять накосячил — так и не посмотрел на свои ссылки. V>>Ссылку на джава-проекты, где среди прочих тоже были ссылки на проекты в исходниках, ты дал уже в следующем сообщении. V>>И было сказано "это даже круче", т.к. система сборки по моим ссылкам делала больше, чем по твоим, на которые я отвечал. S>Было сказано "в разы круче" — обычное надувание щёк в вашем любимом стиле.
Но если бы ты внимательней прошёлся по своим собственным ссылкам, то не было бы так обидно, верно?
Ты бы не отвечал невпопад "зато там байт-код".
Сечёшь, в чём косяк?
Как обычно — в поверхностности.
S>ну, вы же просили список зависимостей в XML — вот вам список зависимостей в XML.
Нихрена себе файл на 2 тыс строк для описания 15 зависимостей. ))
А сколько раз мне надо было повторить про "закат солнца вручную", чтобы до тебя дошло моё личное отношение к подобным "удобствам"?
Я дал аналогичную характеристику и своим ссылкам-примерам, про такой же закат.
Это всё 19-й век.
По-идее, такой глядящий исключительно в светлое будущее Синклер должен был меня всячески поддерживать в этом мнении.
S>При том, что речь о довольно-таки древней жаве, которая вовсе не передовик современного производства.
Речь у тебя была конкретно про Maven, а эта штука моложе MSBuild.
S>На этом дискуссию можно заканчивать — то, что я хотел узнать, я узнал.
Это еще не мейнстрим, но как GCC 11 попадёт в основные сборки Linux и выйдет релизная VS 2022 — будет мейнстримом.
Потому что, к бабке не ходи, рано или поздно тут поднимется жуткий визг вокруг модулей С++ от хейтеров нейтива, будут в своей манере цепляться, плеваться и до последнего искать недостатки, как это обычно и происходит.
100% будет похлеще этого обсуждения про пакетные менеджеры.
Так ты хоть будешь предупреждён, т.е. вооружён, уже не накосячишь...
Re[9]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, gandjustas, Вы писали:
S>>Неужели нельзя, что гугл говорит? Сам iOS то на чем написан? G>Неважно на чем написан. Важно что C-код ты не запустишь на iOS.
Здравствуйте, vdimas, Вы писали:
V>Видел бы — не спрашивал бы всякую ерунду и не делал слишком громких заявлений.
В смысле? Вы несли пургу восемь постов подряд, и только к концу перешли хоть к какому-то конструктиву.
V>Я не хотел приводить vcpkg в пример, бо еще рано, надо бы еще лет 5 дать на набор жирка.
V>Просто ни дай боже какой-нить пакетный менеджер С++ начнёт совсем сдавать позиции, типа как начал MS Teams, и добровольно отдастся CMake, что в CMake появится возможность подгружать зависимости онлайн изкаробки, типа как MS Teams теперь бесплатно доступна в Office 365, и всё — и ситуация опять поменяется.
Ваши рассуждения про MS Teams тоже смехотворны.
V>В C# та же история, 15-тилетней давности проект с лохматыми зависимости ты вряд ли одной командой соберёшь. V>Будешь разбираться, исправлять, опять разбираться/исправлять и так по-кругу.
Ну, именно поэтому в C# проблему решили. Хорошо, что её пытаются решить в С++ тоже.
S>>Дальше пошли рассказы про то, что без вас никто не напишет менеджер пакетов для С++
V>Не, я конечно вижу иррациональное упорство в духе "мне все врут!!!", но у тебя есть гугл, в конце концов: V>https://developercommunity.visualstudio.com/t/native-c-msbuild-on-linux/926169
Рад за ваше умение пользоваться гуглом
Я видел С++ проекты, которые успешно собираются при помощи msbuild и под виндой, и под линуксом.
Так что вы слегка опоздали со ссылкой на вопрос "где взять таргеты msbuild для g++". Зато ответ, который там дан, полностью подтверждает моё утверждение о том, что MS эта тема неинтересна.
S>>ну, мы уже в курсе, что многопоточность, гуй на IWebBrowser2, и архитектуру учётных систем изобрели лично вы, а до вас все топором брились и молились колесу V>Если "я" — это плюсовый программист из второй половины 90-х, то да, многопоточное GUI (и вообще асинхронщина) — это всё прошло обкатку на плюсах в те годы, т.е. использовалось примерно на 10 лет раньше, чем в других технологиях. V>HTML-Dialog аналогично, тоже примерно на 10 лет раньше, чем стало мало-по-малу появляться в заметных кол-вах на других технологиях.
Да нет, почему же. Мы же с вами не первый год на форумах — вы все эти заслуги регулярно приписываете лично себе, Валюкову Дмитрию Владимировичу. А вовсе не какому-то абстрактному сообществу С++ программистов из второй половины девяностых.
V>Я понимаю, что тебя это бесит, но не понимаю, зачем унижаться еще больше?
Что именно бесит? Ваш неприкрытый нарциссизм? Да ну нет же. Он меня скорее забавляет. Вот если бы я сам не писал на плюсах во второй половине девяностых и начале 2000х, то, наверное, было бы обидно.
Ну, в предположении, что я вашим самовосхвалениям поверил бы.
V>Для только что вышедших из леса краткая сводка новостей 5-тилетней давности: V>- MSBuild овладел Linux с первым выпуском .Net Core.
Ну, так вы уже научились собирать С++ проекты на линуксе при помощи msbuild? Или только планируете выяснить, как именно должен быть устроен "плагин для запуска CMake"?
V>Так уже покрыл, но лишь для части сценариев.
Ну, вот уже ближе к теме.
V>Все же нет. V>Наполнение vcpkg на прямо сегодня неудовлетворительное, т.е. это как npm, у которого отобрали пакеты из репозитория.
Наполнение напрямую зависит от traction. Это же классический экспоненциальный эффект соцсети — людям интересно пользоваться репозиториями, в которых много пакетов; и пополнять интереснее те репозитории, которыми много кто пользуется. Решение этой проблемы напрямую зависит не от вашей личной способности за три года найти готовые таргеты и допилить их для вызова nuget из msbuild, а от инвестиций в поддержание репозитория. V>О чём-то еще рано говорить, о чём-то уже поздно.
S>>Жаль, конечно, что вы потратили столько времени на кривляния.
V>Но если бы ты внимательней прошёлся по своим собственным ссылкам, то не было бы так обидно, верно? V>Ты бы не отвечал невпопад "зато там байт-код".
Он не "зато", а просто есть. Я не увидел, где именно жава тащит зависимости в исходниках в проекте pinot, и не могу сказать, за каким хреном это понадобилось — возможно, оттого, что какая-то из зависимостей просто не опубликована в виде jar. Я констатировал очевидную вещь, с которой нет никакого смысла спорить: в java взаимноднозначно отображение исходников в байт-код.
Это для С++ придётся либо выкладывать бинари под весь зоопарк платформ, а также все варианты "хочу линковать статически; хочу динамически; хочу, чтобы либа была слинкована ко мне статически, но сама пусть импортирует зависимости динамически" и т.п., либо выкладывать исходники с "надеюсь, что на вашем компиляторе это тоже соберётся".
Ничего "крутого" в этом нет — это проблема, а не преимущество.
V>Нихрена себе файл на 2 тыс строк для описания 15 зависимостей. ))
Это вы как посчитали? Я вот насчитал полтораста зависимостей. Ну, наверное, какие-то из них — транзитивные (чем, кстати, страдал в своё время и nuget), но вы же хотели проект с "лохматыми зависимостями"? Вот я вам дал такой проект. Кроме того, pom.xml содержит вовсе не только зависимости. Эдак я могу посмеяться над тем, что какой-нибудь CMakeLists.txt для проекта с жалкими 3 зависимостями занимает 1980 строк. Или над vcxproj, которые с пятью зависимостями триста строк занимают.
И это мы ещё говорим о проектах, которые не особо-то кроссплатформенные — ни один из них не умеет собрать на линукс-машине екзешник для винды.
V>По-идее, такой глядящий исключительно в светлое будущее Синклер должен был меня всячески поддерживать в этом мнении.
Я бы поддерживал, если бы вы не метались между "нет и не надо" и "есть, не хуже прочих".
S>>При том, что речь о довольно-таки древней жаве, которая вовсе не передовик современного производства. V>Речь у тебя была конкретно про Maven, а эта штука моложе MSBuild.
Да там разница в полгода — не о чем говорить. При этом сам nuget, который бесспорный передовик управления пакетами, появился ажно в 2010 (это без интеграции в msbuild).
V>Это ты еще про модули не видел: V>https://habr.com/ru/company/yandex_praktikum/blog/554874/ V>Это еще не мейнстрим, но как GCC 11 попадёт в основные сборки Linux и выйдет релизная VS 2022 — будет мейнстримом.
Ага, не видел. Пока что выглядят неюзабельно — с таким подходом им ещё лет десять до минимально приемлемого уровня ползти. Но молодцы, что наконец вынули голову из того места, где она была, и начали хоть как-то догонять нынешний стандартный уровень.
V>100% будет похлеще этого обсуждения про пакетные менеджеры.
Всё может быть. Лично мне на всё это, как бы это помягче выразиться, наплевать. Я, если припрёт, на любом языке могу писать. Хоть на С, хоть на D, хоть на M.
Но при наличии выбора, я предпочитаю платформу, которая разработчика уважает. В которой заранее потрачены усилия на то, чтобы новичок мог быстро начать приносить пользу — а не тратить своё время на борьбу с заранее разложенными граблями.
Это же как офис — понятно, что выходцы из девяностых могут программировать и одним пальцем через feature phone, стоя в телефонной кабинке в минус 40. Но как ни крути, удобнее работать в офисе класса А, с бесплатным кофе, шумозащитными покрытиями и на современном компьютере с хорошим интернетом. Не вижу никакого смысла гордиться тем, что "да я в ваши годы шёл по гололёду от проходной до нашего подвала три километра в гору и против ветра, работал за чугунной клавиатурой, сидя в валенках, а ссать ходил во двор в дыру в стене".
Надо стремиться к лучшему.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[30]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>>>Ты бегаешь от сути проблемы языка JS. I>>Это как раз бенефит, для разработки простых вещей тебе кроме dev tools даже редактор не нужен.
V>Ну вот мы и пришли к сути, которую все и так знают, в общем-то. V>В кач-ве редактора блокнотик, в кач-ве отладчика — примитивные devtools браузера. V>ХЗ зачем было столько бегать... ))
Для разработки простых вещей ни в одном ЯП не нужно ничего, кроме блокнота и компилятора-интерпретатора.
Или ты хочешь сказать, что в С++ даже для простых вещей нужна ИДЕ и windbg?
I>>Это целенаправленное решение
V>Мы все знаем прошлое этого решения. V>Впрос стоит — что делать с этим в будущем?
Ровно то же, что и сейчас — развивать это направление, типизировать новые фичи, добавлять типизацию для старых, пилить компайлер-сервис, что бы это было легко внедрять направо-налево.
I>>>>Надо бы без "если". V>>>Если речь об отладке, то надо как я написал. I>>Я и говорю — надо без "если". В силу нативности плюсов такое принципиально невозможно. Глупо с этим спорить.
V>"Такое" — это что именно? V>Ты только что рассуждал об отладке, я тоже.
Простой кейс — вне условий разработки "открыть приложение" на машине заказчика открыть приложуху, посмотреть его трафик, данные, проверить, что пошло не так.
И эти действия будет выполнять совсем не разработчик, и часто даже не технарь.
Например, кастомер сообщает о проблеме xxx. Тестировщики воспроизвести не могут, разработчики — тоже.
Такие проблемы это норма для нативных приложений. Пиши не пиши в суппорт, там сообщают "а у нас всё хорошо, в логах чисто, дайте описание получшие"
Отсюда ясно, что каждое жээс приложение поставляется с мощным встроеным отладчиком, который мало чем уступает ИДЕ.
I>>Очевидно, что ты старательно пропустил все примеры
V>Ну ты же сам говорил, что я хреновый телепат.
Разумеется, эта проблема телепатией не решается, как и любая другая. Надо раскрыть глаза да посмотреть.
V>А здесь ты ни одного примера не привёл.
Смотришь, но не видишь Redux, MobX, UI контролы. Более того — сам веб-ui протискивается вообще везде — десктоп на него мигирует, и частично даже мобайл. Это и есть экспорт. Спрос именно на плюшки, которые дает js-html-css.
Далее, jsx, как концепция рендеринга. Это следующее поколение, тот путь, с которого свернул wpf. И это уже подхватили вне жээса.
Далее, сам жээс пролез даже в IoT и даже в микроконтроллеры. И это снова экспорт жээсного подхода.
Если бы ты читал помедленнее, то сам бы заметил без моей помощи
I>>Какой смысл что либо тебе доказывать
V>Дать инфу ты назвал доказать.
Если ты что либо утверждаешь, то мне надо бы понять, какие у тебя основания заявлять такое. На кой ляд мне кидаться всё это оспаривать?
V>Но я догадываюсь о причинах твоей скромности, ес-но.
Скорее всего это еще один пример телепатии. Не стесняйся, покажи еще один мастер-класс
I>>Единичный пример это не статистика.
V>Это вводишь строку поиска тимлидов и получаешь выборку. V>Я же предлагал тебе самому проверить.
Проверил, всё ровно так же.
V>И в другой раз, когда тебе захочется сравнить расклады в различных технологиях — для объективности ищи вакансии на примерно свой стаж.
Ты ведь ты тужишься обсуждать мою ЗП, а у меня интерес проще — сравнить зп фронтов на hh с зп c++ на том же hh.
V>Насколько я понимаю, твой стаж в р-не 20 лет плюс-минус?
Что тебя побудило так думать?
I>>Ну да, разброс ЗП всего от 100$ до 8000$ судя по hh
V>За чистый JS $8000 не платят, ес-но.
Ты с торга вернулся обратно в отрицание. Раз вакансии есть, значит — платят.
I>>А на кой ляд мне это делать?
V>Мой жизненный опыт подсказывает, что твоя жена (если есть) была бы не против повышения твоих доходов в разы. V>Ды и ты бы сам не отказался.
Вероятно, это ты про себя говоришь, выглядит, будто это ты чем то недоволен.
V>Рецепт я тебе озвучил, он работает, у меня у самого была контора одно время.
была советы даешь, будто у тебя свой альфабет или, на худой конец, гугл
V>Просто случилось так, что опытным плюсовикам стали более-менее платить и без этой головной боли.
"опытным плюсовикам стали более-менее платить"
V>А он общий на все области IT, бо нетивному программисту всё-равно что программировать — кодеки, драйвера, сетевые протоколы, составные части ОС, виртуализацию, VM для байткодов ваших абстракций, графические либы, шейдеры и т.д. до бесконечности.
Это как раз иллюзия. 80% нативных точно так же решают простые задачи, как и 80% фронтов. Задачи другие, но тем не менее простые.
В С++ слишком много напускной сложности, типа продраться через билды, продраться через их отсутствие, продраться через отладку, продраться через отсутствие отладки.
А вот конкретные предметные области это оставшиеся 20%.
Собственно, именно такой расклад и показывает HH. А потому с ЗП все более менее одинаково — за простые задачи как раз простые задачи без учета языковости.
Единственное, что ломает картину, это спрос. И вот здесь из общей массы выделяются те 20%
Re[10]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
S>>>Неужели нельзя, что гугл говорит? Сам iOS то на чем написан? G>>Неважно на чем написан. Важно что C-код ты не запустишь на iOS.
V>https://stackoverflow.com/questions/10289890/how-to-write-ios-app-purely-in-c V>Objective-C "понимает" чистый С, для него это подмножество.
Это как раз означает что нельзя взять произвольный нетривиальный C-код и запустить его на iOS. На iOS нет CRT.
Re[37]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Видел бы — не спрашивал бы всякую ерунду и не делал слишком громких заявлений. S>В смысле? Вы несли пургу восемь постов подряд, и только к концу перешли хоть к какому-то конструктиву.
Да нет, пургу нёс кто-то другой, не делая труда вдуматься, что ему говорят и почему именно так.
С тем же успехом я мог общаться с забором.
Даже если ты на слово не верил (допустим), мог бы проверить самостоятельно...
А в конце вовсе решил дуримаром прикинуться?
Отлично. Вижу, вы всё же ознакомились с положением дел в отрасли.
Это ж днище. ))
Если я тебе ссылки дам на мои упоминания vcpkg за недавние даты до этого обсуждения, шляпу есть будешь?
Здравствуйте, Sinclair, Вы писали:
V>>Просто ни дай боже какой-нить пакетный менеджер С++ начнёт совсем сдавать позиции, типа как начал MS Teams, и добровольно отдастся CMake, что в CMake появится возможность подгружать зависимости онлайн изкаробки, типа как MS Teams теперь бесплатно доступна в Office 365, и всё — и ситуация опять поменяется. S>Ваши рассуждения про MS Teams тоже смехотворны.
Угу, после слова "смехотворный" ты обычно садишься в лужу.
Нечего сказать по-делу — лучше промолчать.
V>>В C# та же история, 15-тилетней давности проект с лохматыми зависимости ты вряд ли одной командой соберёшь. V>>Будешь разбираться, исправлять, опять разбираться/исправлять и так по-кругу. S>Ну, именно поэтому в C# проблему решили.
Да не решили проблему, старые проекты по-прежнему не собираются.
И на будущее проблема лишь трансформировалась, но не сильно, т.к. в сути осталась той же:
— если какие-нить пакеты со временем в NuGet протухнут (а они регулярно протухают, объявляются deprecated, заменяются пакетами с другими ID, если происходят ломающие изменения, а потом и вовсе через какой-то период исчезают), то по прошествии кучи лет может случиться так, что с наскока ты и концов не будешь знать, где искать.
И начнётся привычное нудное гугление обрывков давнишних упоминаний в сети незнакомых идентификаторов с целью понять "а что это за зверь такой был N лет назад... или даже M???".
S>Хорошо, что её пытаются решить в С++ тоже.
Её пытаются решить давно.
Практически, всё время.
Просто смысл сравнивать молодой дотнет одного вендора интернетной эпохи с десятками (одно время) компиляторов С++ и их форматами проектов, и всё это еще с доинтернетной эпохи, т.е. прилично развития шло в эпоху раздробленности комьюнити.
Сначала должно было случиться главное — они все должны были умереть.
Остался MS VC, gcc, clang и Intel Compiler.
Причём, последний не создаёт своей экосистемы, он под линухами кушает аргументы gcc, под виндами кушает аргументы MS VC, т.е. ребята из Intel хорошо понимают суть проблемы.
Это как с браузерами — пока десяток независимых движков не расстреляли нафик, стандарты W3C топтались на месте хрен его знает сколько.
Переход MS на оперсорсный движок webkit я только приветствую, в таких делах лучше работать на одну копилку.
И да, упоротое хейтерство красноглазых в адрес MS и Windows все 90-е и нулевые тоже не способствовало кроссплатформенной интеграции.
С браузерами тоже история мутная вышла в начале нулевых по этой же причине — MS вызывала раздражение всей индустрии из-за невероятных успехов Windows/Office и т.д.
Это хоть понимаешь? ))
Проблема этого обсуждения в другом — я совершенно уверен, что всем этим контекстом ты владеешь неплохо, т.е. мне нет нужды в эту сторону распинаться, бо все читатели и так вкурсе.
Но твоя позиция, когда ты с лёгкостью позволяешь себе отметать всем известный контекст — я её иначе как иррациональной не воспринимаю.
Поэтому и "дурдом" (С).
И про "домохозяек" туда же было, из-за демонстративного отключения тобой мозгов, что сразу становится жаль потраченного времени.
Здравствуйте, vdimas, Вы писали:
V>Если я тебе ссылки дам на мои упоминания vcpkg за недавние даты до этого обсуждения, шляпу есть будешь?
Тебя самого так заносит. Тот же Юнити в итоге работает то со средой. Ты же утверждал, что никакого моно нет.
И в итоге молчание. Я например всегда признаю свои ошибки.
Напомню про наш спор про Dart и TypeScript. Прошло время и мои утверждения касательно TS оправдались, а Dart даже flutter не вытащил.
Опять же много голословного. Например про .Net Native. Нет там среды. И проблема как раз там с докомпиляцией кода из-за отсутствия среды.
Тебе приводят ссылки, но ты им не веришь, но при этом сам никаких ссылок подтверждающие твои утверждения не приводишь!
Я не к тому, что ты плохой, а к тому, что мы на форуме должны получать достоверную информацию. Не уверен, не утверждай
Всем свойственно ошибаться. Но не всем свойственно признавать свои ошибки!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, gandjustas, Вы писали:
V>>Objective-C "понимает" чистый С, для него это подмножество. G>Это как раз означает что нельзя взять произвольный нетривиальный C-код и запустить его на iOS.
Выглядело, что речь шла о как таковой возможности разрабатывать на Си под iOS.
Re[31]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ikemefula, Вы писали:
V>>Ну вот мы и пришли к сути, которую все и так знают, в общем-то. V>>В кач-ве редактора блокнотик, в кач-ве отладчика — примитивные devtools браузера. I>Для разработки простых вещей ни в одном ЯП не нужно ничего, кроме блокнота и компилятора-интерпретатора.
Теперь мы подошли к сути этой сути.
Блин... куда ты дел адекватного когда-то Плутония Эксперимент?
Выглядит, будто ты его съел, а перед смертью заставил несчастного выложить тебе пароли от его аккаунтов. ))
Сорри, но по такому сценарию бегать вокруг очевидного ваще облом...
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Objective-C "понимает" чистый С, для него это подмножество. G>>Это как раз означает что нельзя взять произвольный нетривиальный C-код и запустить его на iOS.
V>Выглядело, что речь шла о как таковой возможности разрабатывать на Си под iOS.
Кроссплатформенный код
Re[39]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Serginio1, Вы писали:
V>>Если я тебе ссылки дам на мои упоминания vcpkg за недавние даты до этого обсуждения, шляпу есть будешь? S>Тебя самого так заносит. Тот же Юнити в итоге работает то со средой. Ты же утверждал, что никакого моно нет.
Но не пытался скинуть своё невладение инфой на других, когда мне эту инфу более-менее убедительно дали (тот коллега, что юзает Unity).
По-факту я чуть отложил вопрос для личной актуальной проверки, надо чтобы руки дошли.
Т.к. когда я на неё смотрел несколько лет назад, то проект у меня компилялся в нейтивный в релизе.
Возможно, я не прошёлся внимательно по всем допустимым конфигурациям.
S>И в итоге молчание. Я например всегда признаю свои ошибки.
Если бы ты пользовался Unity, ты бы прямо сказал как оно есть, а не рассуждал о своих представлениях.
Упоротость спора там была именно в этом — ты её даже не щупал.
А я щупал как-то пару раз с разницей примерно в 7 лет.
Проверю лично — отпишусь.
S>Напомню про наш спор про Dart и TypeScript. Прошло время и мои утверждения касательно TS оправдались, а Dart даже flutter не вытащил.
У гугла на сервере и на странице Дарт (который автоматом переводится в JS на странице), последний Angular разработан на Дарт, скомпиллирован в т.ч. JS.
Но особенно цветёт и пахнет в мобильном сегменте, бо там и выбрать не из чего.
Electron+JS — убожество, Джава/Котлин — родная либа GUI муторная в использовании, а по возможностям недалеко ушла от Electron+JS.
Что-то интересное в GUI там можно делать или на Xamarin или на Flutter, а больше толком не на чем.
(не считая нейтивные QT и/или с крутой 3D графикой, но таких в общей массе доля небольшая) https://doc.qt.io/qt-5/deployment-android.html
S>Опять же много голословного.
Это у тебя много голословного.
Имеешь привычку рассуждать о том, чем лично не занимался и даже не пробовал.
S>Например про .Net Native. Нет там среды.
И про это ты точно так же не знаешь.
А мог бы поисследовать и рассуждать предметно.
И среда там есть аж бегом, без ней .Net Native не живёт.
S>Тебе приводят ссылки, но ты им не веришь
По ссылкам насчёт .Net Native всё верно, неверна твоя их интерпретация.
S>но при этом сам никаких ссылок подтверждающие твои утверждения не приводишь!
Они есть даже по твоим ссылкам.
И да, цитаты из доки я тебе приводил, сама дока ищется на раз гуглом, было бы желание.
S>Я не к тому, что ты плохой, а к тому, что мы на форуме должны получать достоверную информацию.
Ну так и давай достоверную.
Инженер может давать экспертную оценку только в рамках своей компетенции, не забыл еще?
Re[13]: MS забило на дотнет. Питону - да, сишарпу - нет?
V>Проверю лично — отпишусь.
Ждемс.
S>>Напомню про наш спор про Dart и TypeScript. Прошло время и мои утверждения касательно TS оправдались, а Dart даже flutter не вытащил.
V>Где это они "не оправдались"? V>https://github.com/search?q=flutter&type=repositories V>https://github.com/search?l=Dart&q=Dart&type=Repositories V>https://github.com/Solido/awesome-flutter
V>У гугла на сервере и на странице Дарт (который автоматом переводится в JS на странице), последний Angular разработан на Дарт, скомпиллирован в т.ч. JS.
И какой процент людей пользуются дартом и тс?
V>Но особенно цветёт и пахнет в мобильном сегменте, бо там и выбрать не из чего. V>Electron+JS — убожество, Джава/Котлин — родная либа GUI муторная в использовании, а по возможностям недалеко ушла от Electron+JS.
S>>Опять же много голословного.
V>Это у тебя много голословного. V>Имеешь привычку рассуждать о том, чем лично не занимался и даже не пробовал.
Я то как раз говорю о том, в чем разбирался S>>Например про .Net Native. Нет там среды.
V>И про это ты точно так же не знаешь. V>А мог бы поисследовать и рассуждать предметно. V>И среда там есть аж бегом, без ней .Net Native не живёт.
Ну вот нет там среды! Кроме сборщика мусора. Если бы среда была, то не было бы проблем с докомпиляцией и рефлексией.
Подтверди свои утверждения ссылками. Опять голословный треп.
S>>Тебе приводят ссылки, но ты им не веришь
V>По ссылкам насчёт .Net Native всё верно, неверна твоя их интерпретация.
NET Native заменяет полную среду CLR на оптимизированную среды выполнения, которая в первую очередь содержит сборщика мусора. Оптимизированная среда выполнения находится в библиотеке mrt100_app.dll, которая является локальной для приложения и имеет размер только несколько сотен килобайт. Это возможно потому, что статическое связывание устраняет необходимость во многих операциях, реализуемых средой CLR.
То есть по твоему в несколько сотен килобайт умещается JIT ер?
Была бы среда докомпилирующая в рантайме, не было бы этих проблем.
Сссылки сестра!
S>>Я не к тому, что ты плохой, а к тому, что мы на форуме должны получать достоверную информацию.
V>Ну так и давай достоверную. V>Инженер может давать экспертную оценку только в рамках своей компетенции, не забыл еще?
Я даю ссылки, но ты их достоверными не считаешь!
Кстати и тесты производил https://rsdn.org/forum/dotnet/6738556.1
Опять опрос stack overflow? ))
Т.е. опрос тех, у кого возникают вопросы?
И тебя не смущает, что на первом месте Rust, который в рейтинге TIOBE на 30-м месте?
А дарт в этом же рейтинге на 22-м?
А топ выглядит так:
Питон
Си
Джава
S>И смотрим как растет популярность TS.
Смотрю как много Rust и TS вызывает вопросов на SO. ))
S> Ну Xamarin может использовать и блазор в натив, и сейчас MAUI кроссплатформенный развивается, ну и родные андроидные axml
Это да, XAML позиции не сдаёт, а даже набирает.
Но XAML-подобные GUI идеальнее всего подходят для статического GUI, а Flutter изначально проектировался с упором на динамику.
Простое ветвление прямо в коде намного органичней смотрится, чем ветвление в JS, где или согласно условиям рендерят текст HTML, или ручками напихивают DOM, или переключают стили/классы видимые/невидимый.
Все три способа — убожество.
При кажущейся лаконичности последнего, у него расползаются зависимости м/у HTML-страницей, логикой в JS-коде и CSS-стилями, что приводит к той самой забористой каше современного фронтенда, где в одном месте чуть дунул — и всё поломалось.
V>>Это у тебя много голословного. V>>Имеешь привычку рассуждать о том, чем лично не занимался и даже не пробовал. S> Я то как раз говорю о том, в чем разбирался
С Unity ты не разбирался, посему твоё упорство выглядело странным.
Особенно когда ты не мог поверить, что в нейтивном релизе есть GC, но нет "среды".
V>>И среда там есть аж бегом, без ней .Net Native не живёт. S> Ну вот нет там среды!
Native (AOT) compilation is a great scenario addition to .NET Core apps on Windows, OS X and Linux. We've seen significant startup and throughput benefits of native compilation for Windows UWP apps, using .NET Native.
...
CoreRT is a refactored and layered .Net Core runtime. The base is a small native execution engine that provides services such as garbage collection(GC). This is the same GC used in CoreCLR.
...
CoreRT offers great benefits that are critical for many apps.
...
The native compiler generates a SINGLE FILE, including the app, managed dependencies and CoreRT.
Firstly, what exactly is CoreRT? From its GitHub repo:
— a .NET Core runtime optimized for AOT (ahead of time compilation) scenarios, with the accompanying .NET native compiler toolchain
...
So whilst CoreRT is a run-time, it also needs a compiler to put everything together, from Intro to .NET Native and CoreRT:
.NET Native is a native toolchain that compiles CIL byte code to machine code (e.g. X64 instructions). By default, .NET Native (for .NET Core, as opposed to UWP) uses RyuJIT as an ahead-of-time (AOT) compiler, the same one that CoreCLR uses as a just-in-time (JIT) compiler.
...
The Runtime
All the user/helper code then sits on-top of the CoreRT runtime, from Intro to .NET Native and CoreRT:
CoreRT is the .NET Core runtime that is optimized for AOT scenarios, which .NET Native targets.
Точный GC не может работать без метаинформации, поэтому, там и метаинформации овердофига.
Можно сравнивать у разных объектов результат вызова GetType(), работает is и as, работает проверка на отношение base/derived и т.д. и т.п.
S>Кроме сборщика мусора. Если бы среда была, то не было бы проблем с докомпиляцией и рефлексией.
Для этого надо было бы оставить символьные строки, соотв. названиям неймспейсов, классов и их мемберов.
А насчёт докомпиляции — по ссылке для особо понятливых несколько раз повторяется, что это AOT-технология, но при этом используется тот же самый RuiJIT.
Native compiled apps startup faster since they execute already compiled code. They don't need to generate machine code at runtime nor load a JIT compiler.
А тебя послушаешь, так даже в случае обычного дотнета, после того как JIT перевёл в нейтив весь наличествующий байткод, сразу "среда" перестаёт быть "средой".
Ведь происходящее далее не сильно будет отличаться от происходящего в .Net Native UWP.
S>Подтверди свои утверждения ссылками. Опять голословный треп.
А в сад тебе не прогуляться, к остальным двоечникам? ))
Здравствуйте, Sinclair, Вы писали:
V>>Это ты еще про модули не видел: V>>https://habr.com/ru/company/yandex_praktikum/blog/554874/ V>>Это еще не мейнстрим, но как GCC 11 попадёт в основные сборки Linux и выйдет релизная VS 2022 — будет мейнстримом. S>Ага, не видел. Пока что выглядят неюзабельно — с таким подходом им ещё лет десять до минимально приемлемого уровня ползти. Но молодцы, что наконец вынули голову из того места, где она была, и начали хоть как-то догонять нынешний стандартный уровень.
Компиляция в модули — двоякоострая технология.
Экономя на повторной компиляции файлов (хотя, и с этим сейчас эффективно борются через pch), она требовательна к объёму оперативки, т.е. как в нулевых на линухах с 500MB юзер-спейса не взлетит.
Она требует компиллируемости всего и сразу, что не всегда удобно в случае лохматых зависимостей м/у проектами одной разработки, т.к. не позволяет работать независимо над отдельными cpp-файлами, как это принято сейчас — в процессе разработки разработчик периодически вызывает компиляцию только тех cpp-файлов, над которыми в данный момент работает.
То бишь, в нынешней схеме запросто можно иметь зависимости от некомпилябельных проектов — главное, чтобы интерфейсные h-файлы описывали что требуется, а наполнить "тела" можно и в процессе, что позволяет на плюсах достичь намного лучшего разделения труда, чем в C# и Джаве.
В этих технологиях аналогичное традиционно достигается через натурально перебарщивание с интерфейсами.
Т.е. даже если в архитектуре конечного продукта половина из них и нафик не упёрлась, но без них невозможно эффективно распараллеливать разработку. ))
В общем, не зря в хелперах рефакторинга Джава и C# чуть ли не первой функциональностью идёт генерирование пустых методов-заглушек — как раз борются с описанными сценариями.
Это удобно, но это ловушка, бо интерфейсы многих базовых вещей порой заставляют обильно рассыпать в наследниках "Not implemented.." вовсе не по причине забывчивости.
В плюсах в этом сценарии будет ошибка линковки, т.е. будет хорошо видно, что именно еще не реализовано.
S>Но при наличии выбора, я предпочитаю платформу, которая разработчика уважает.
Слабая демагогия, не торкает. ))
Платформа настолько тебя уважает, что пакетный менеджер Nuget вышел на боевую готовность спустя ~15 лет после выхода дотнета.
S>В которой заранее потрачены усилия на то, чтобы новичок мог быстро начать приносить пользу
ПХП!
S>Не вижу никакого смысла гордиться тем, что "да я в ваши годы шёл по гололёду от проходной до нашего подвала три километра в гору и против ветра, работал за чугунной клавиатурой, сидя в валенках, а ссать ходил во двор в дыру в стене".
"В наши годы" (С) происходило чуть другое характерное — цена ошибки была выше, а совершить её было проще.
Ну и, худшее обращение знаний в индустрии, в итоге меньшее кол-во общедоступных полезных библиотек и т.д. до бесконечности.
S>Надо стремиться к лучшему.
Напомню, что мы рассуждали конкретно о кроссплатформенной сборке.
Так вот, линусятки угомонились со свои хейтерством только примерно к 2012-му.
До этого задаче "кроссплатформенность" порой выдавали не просто низкий приоритет, а строго отрицательный, — многие проекты разрабатывались с полным игнором возможности собирать их под виндой. ))
И вот ты из 2021-го пытаешься взять проект нулевых и удивляешься, а что это у нас с кроссплатформанностью???
А там примерно то же, что плюсовики слышали от джава и шарп девелоперов в адрес нейтивного программирования.
Только здесь прямое хейтерство в адрес Windows как платформы исполнения разрабатываемых программ.
И основные работы по одновременному покрытию широкого круга платформ выполнялись в рамках коммерческих проектов, бо опенсорс был фактически неумолим насчёт маздая. ))
Ты же видел хотя бы раз проекты на основе Cygwin и аналогичных?
Это когда стало понятно, что всё мн-во опенсорсных проектов портировать на родные ср-ва сборки Windows попросту нереально, они воссоздали на виндах gcc и минимальные binutils.
Это оказалось в разы дешевле. ))
Но это вообще не пришей кобыле хвост технология получается...
В общем, это сейчас улеглось малость...
Но эти ваши хейтерские страсти объективно вредили индустрии примерно с конца 90-х.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
S>> Что же так популярность дарта то не растет? S>>https://habr.com/ru/company/skillfactory/blog/504194/
V>Опять опрос stack overflow? )) V>Т.е. опрос тех, у кого возникают вопросы?
V>И тебя не смущает, что на первом месте Rust, который в рейтинге TIOBE на 30-м месте? V>А дарт в этом же рейтинге на 22-м? V>А топ выглядит так: V>Питон V>Си V>Джава
Где ты увидел Rust на первом месте
JS на первом месте, затем Питон, Java и C#, PHP и TS!!! S>>И смотрим как растет популярность TS.
V>Смотрю как много Rust и TS вызывает вопросов на SO. ))
TS это замена самому популярному языку. Вопросов много потому что активно развивается и куча нововведений!
S>> Ну Xamarin может использовать и блазор в натив, и сейчас MAUI кроссплатформенный развивается, ну и родные андроидные axml
V>Простое ветвление прямо в коде намного органичней смотрится, чем ветвление в JS, где или согласно условиям рендерят текст HTML, или ручками напихивают DOM, или переключают стили/классы видимые/невидимый.
То же самое можно делать и напрямую создание компонентов в коде. Кстати на Xamarin сначала вообще не было редактора и все описывалось в коде аналогично Dart,
но декларативно описывать прощею V>Все три способа — убожество. V>При кажущейся лаконочности последнего, у него расползаются зависимости м/у HTML-страницей, логикой в JS-коде и CSS-стилями, что приводит к той самой забористой каше современного фронтенда, где в одном месте чуть дунул — и всё поломалось.
Но при этом альтернативы, которая вытеснила HTML то и нет. Вот TS активно вытесняет JS, но он и компилируется в JS.
V>>>Это у тебя много голословного. V>>>Имеешь привычку рассуждать о том, чем лично не занимался и даже не пробовал. S>> Я то как раз говорю о том, в чем разбирался
V>С Unity ты не разбирался, посему твоё упорство выглядело странным. V>Особенно когда ты не мог поверить, что в нейтивном релизе есть GC, но нет "среды".
Угу чего мне не верить если в .Net Native есть GC но нет среды? Я говорил про отладку в среде и то, что для андроида она опциональна.
И присутствует моно. Ты же отрицал моно и среду. Типа все в С++ V>>>И среда там есть аж бегом, без ней .Net Native не живёт. S>> Ну вот нет там среды!
V>Ошибаешься: V>https://github.com/dotnet/corert/blob/master/Documentation/intro-to-corert.md V>
V>Native (AOT) compilation is a great scenario addition to .NET Core apps on Windows, OS X and Linux. We've seen significant startup and throughput benefits of native compilation for Windows UWP apps, using .NET Native.
V>...
V>CoreRT is a refactored and layered .Net Core runtime. The base is a small native execution engine that provides services such as garbage collection(GC). This is the same GC used in CoreCLR.
V>...
V>CoreRT offers great benefits that are critical for many apps.
V>...
V>The native compiler generates a SINGLE FILE, including the app, managed dependencies and CoreRT.
V>Firstly, what exactly is CoreRT? From its GitHub repo:
V>- a .NET Core runtime optimized for AOT (ahead of time compilation) scenarios, with the accompanying .NET native compiler toolchain
V>...
V>So whilst CoreRT is a run-time, it also needs a compiler to put everything together, from Intro to .NET Native and CoreRT:
V>.NET Native is a native toolchain that compiles CIL byte code to machine code (e.g. X64 instructions). By default, .NET Native (for .NET Core, as opposed to UWP) uses RyuJIT as an ahead-of-time (AOT) compiler, the same one that CoreCLR uses as a just-in-time (JIT) compiler.
V>...
V>The Runtime
V>All the user/helper code then sits on-top of the CoreRT runtime, from Intro to .NET Native and CoreRT:
V>CoreRT is the .NET Core runtime that is optimized for AOT scenarios, which .NET Native targets.
V>Точный GC не может работать без метаинформации, поэтому, там и метаинформации овердофига. V>Можно сравнивать у разных объектов результат вызова GetType(), работает is и as, работает проверка на отношение base/derived и т.д. и т.п.
Ну во первых ты говоришь про CoreRT, который возможно и будет использовать JIT компилятор в рантайме. Но во всех твоих ссылках нет ссылок на JIT в рантайме!!!
is и as прекрасно работают в Delphi ибо есть информация в VMT по отрицательным смещениям. S>>Кроме сборщика мусора. Если бы среда была, то не было бы проблем с докомпиляцией и рефлексией.
V>Для этого надо было бы оставить символьные строки, соотв. названиям неймспейсов, классов и их мемберов. V>А насчёт докомпиляции — по ссылке для особо понятливых несколько раз повторяется, что это AOT-технология, но при этом используется тот же самый RuiJIT.
Опять же речь про CoreRT. Опять проблема не AOT, а в рантайме. Для .Net Native нет JIT компиляции в рантайме, а значит и нет среды в нормальном понимантт.
Под понятием среда в .Net Native это GC, без JIT компиляции в рантайме! (на всякий случай ибо JIT англ. Just-in-Time, компиляция «на лету») V>
V>Native compiled apps startup faster since they execute already compiled code. They don't need to generate machine code at runtime nor load a JIT compiler.
Образы IL Fallback — NGEN содержат как машинный код, так и MSIL для сборки (среди других структур данных). Если во время выполнения происходит что-то, что заставляет CLR нуждаться в машинном коде, который он не может найти в образе NGEN, он может вернуться к JITing. В текущем предварительном просмотре разработчика .NET Native в нативном образе присутствует только нативный код. Это означает, что если код отсутствует в изображении, он никогда не будет выполняться во время выполнения.
Что по твоему должен компилировать JIT если не IL кода? S>>Подтверди свои утверждения ссылками. Опять голословный треп.
V>А в сад тебе не прогуляться, к остальным двоечникам? )) Вот за что мне нравится с тобой общаться! Подымаешь настроение.
и солнце б утром не вставало, когда бы не было меня
Вот за что мне нравится с тобой общаться! Подымаешь настроение.
