Здравствуйте, vdimas, Вы писали:
V>А в чём проблема? V>Мы же будем сравнивать современные возможности IDEA для поддержки JS, с возможностями IDEA из середины нулевых для поддержки Джавы. V>Вот и посмотрим, достигла ли сегодня поддержка JS хотя бы того уровня 16-тилетней давности.
А если например, назову Chrome Dev Tools, ты тоже будешь утверждать, что в середине нулевых такое было вообще везде? Ну, скажем, подключился к любой приложухе и сразу видишь вообще всё изнутри?
V>Пустой трёп. V>Если бы ты знал такие примеры, где библиотеки JS используются в других языках, ты бы обязательно кинул в меня этими ссылками, со всей этой своей пролетарской ненавистью, тебе так характерной. ))
Снова телепатия. Ты, похоже, и зп мою знаешь, и эмоциональное состояние считываешь. Телепатия говорит о том, что ты про себя пишешь, на самом деле.
V>В этой реальности всё наоборот — нода импортирует в себя библиотеки из других языков.
Какой смысл мне тебя разубеждать?
I>>Количество веб-приложений на порядок больше всех мобильных вместе взятых.
V>Количество веб-приложений на ноде?
Мы про UI. У тебя память отказывает?
V>Взять этот сайт — серверная часть дотнетая, JS сугубо на клиенте, его рядом с общим объемом кода приложения не видно и под микроскопом.
О то ж — UI на жээсе. Сейчас новых уникальных сайтов, сайтиков, сайтищ появляется в разы больше чем мобильных приложений.
Это ж элементарно — количество мобайл разработчиков вообще говоря давно перестало расти. По вакансиям видно.
V>Обычного, они все одинаковые. V>Интерфейс их мобильных аппликух простейший. V>Потому что это бесплатное приложение.
Нужно смотреть не на абстрактную бесплатность, а на бизнесмодель.
Кроме того, бизнес всегда смотрит на систему через призму фронтенда. Как бы ты ни запилил биллинг, если фронт кривой, на тебя будут смотреть с сомнением
I>>Сейчас продажа именно софта скукоживается. А вот услуги, контент — вот это всё на высоте.
V>Ты на вопрос не ответил — подписка уже не деньги?
Подписка — это большие деньги. Продажа софта — малые. Так понятно?
I>>Ты же сам привел пример про внутригровые покупки — это же не продажа софта. V>Но внутри игры не JS, там С++ и Lua.
Ужос. Lua — скрипт. Или ты не в курсах?
V>Наконец ты осознал, что тот софт, что пишут на JS, он почти бесплатный и/или становится всё бесплатнее.
Важно, что нативный софт, см. браузер, уже давно бесплатный.
V>Именно поэтому у огромного числа современных приложений GUI-интерфейс, по-сути, ничем не отличается от GUI приложух 2000-го года (с точностью до оформительского разнообразия).
Покажи пример.
V>GUI этот беден, несчастен и в принципе неразвиваем, потому что отсутствует инструментарий его развития.
На десктопе было чем развивать, внятные инструменты были. И что? Упс, весь десктоп загнулся. Гы-гы.
V>Развитие принципов GUI идёт сегодня в основном в нейтивных либах (не обязательно языки С/С++) и лишь в одном не-нейтивном проекте на должном уровне — на языке Dart/Flutter. Это ключевое и единственное, что заставило меня внимательно туда посмотреть.
Наоборот, всё это идет сейчас в веб-приложениях. Те "иксперименты в нативных либах" это заимствование у Жээс пять лет назад.
Стейтменеджмент — заимствование из жээса. Как то так.
Скажем, в дотнете появилась MVVM лет 15 назад. С тех пор в жээсе эти идеи многократно эволюционированили — knockout, а теперь вот mobX.
Обычный mvc в жээсе перешел на иммутабельные рельсы, многократно эволюционировал и теперь последние поколения это redux, который лезет в другие платформы.
V>Потому что разработчики WPF-либы, увы, опозорились на весь мир, продемонстрировав, что не понимают, как надо разрабатывать GUI-библиотеки. V>Маленькая подсказка — всю аналогичную реализацию XAML-кухни можно запросто сделать поверх Flutter.
Только это нахрен никому не упало.
V>Но мухи будут отделены от котлет, т.е. при надобности можно будет оперировать котлетами без мух, активно развивая эту библиотеку. V>Но в WPF нельзя. V>Поэтому развития там и нет, по-сути.
Ты снова сам себя разоблачил. WPF был обмазан инструментами по самые нидерланды. И зашел в тупик. Ы?
V>Еще я видел отдельные попытки когда на JS писались контролы для канвы HTML-страницы. V>Но эта канва не связана с остальным наполнением GUI страницы. V>И когда полностью нарисованный с 0-ля GUI на канве, то тормозит оно так, что смотреть на такое можно только из любопытства.
Когда UI полностью отрисован в дотнете, скажем, на system.drawing, он тормозит еще хуже.
А если UI полностью отрисован в С++, скажем, на gdi+, он тормозит так же плохо, как и system.drawing.
V>Я уже понял, что ты не умеешь пользоваться поиском. V>Введи senior C++ или team leader C++ и попустись.
Я так и сделал. Поставил регион Россия, вбил твоего сеньора, и узнал, что 80% работают за ЗП до 250тыс.
А ты врал, что 350 чуть не все да сходу
Поздравляю вас, сударь, соврамши
V>Наивный. V>Оно не характерно для JS, это так для индустрии в целом.
В целом это характерно там, где порог вхождения низкий. В С++ так не получится, т.к. вход долгий и трудный.
V>Мне поднадоело тыкать тебя в твои косяки — ты не обращал внимания на требуемый опыт в таких объявлениях, а там почти всегда 1-3 года, т.е. это объявление для студентов-старшекурсников или вчерашних студентов.
Так все объявления дают, указывают минимальную платку по опыту, и максимальную по зп. Из этого не значит, что все кандидаты такую зп и получат, что собственно и происходит.
V>Да пофик, дай мне единичные примеры самых-самых топ-вакансий JS c окладом 600 тыс/мес и годовым бонусом в размере 12-24 окладов. V>Или бонус опционами в размере оклада с коэффициентом 100.
Ты снова хочешь вывести статистику из единичных случаев?
V>В моей конторке нет выделенных JS-разработчиков, хотя на JS мы иногда пишем, как и на других скриптовых языках.
Это объясняет все твои аргументы
Ты предсказуемый, однако. Вся твоя телепатия на поверку оказалась рассказами про твою конторку в 100 человек.
V>Надо и де-факто ранжируют — разные вещи.
Наоборот. Все крупные конторы — ранжируют.
V>На JS почти никогда не ранжируют. V>Собсно, в вакансиях на JS почти никогда требуемый ранг не пишут.
Похоже, у тебя и юрист с врачом только тогда чегото стоят, когда пишут на С++
V>Ключевой специалист решит задачу, пользуясь своей универсальностью, бо он не просто JS-программист, он хорошо понимает работу внутренней кухни той же ноды. V>Он напишет вам либу или обертку над нейтивной либой, причём, свяжет её грамотно с JS-интерфейсом, а там местами очень нетривиально, чтобы было и корректно и эффективно. V>И всё на плюсах, ес-но.
Ога. Я даже не помню в каком году последний раз встречал такую либу, ну, кроме тех, что сам сделал.
V>А потом напишет макет и тесты на стороне JS, а остальное стадо пойдёт в хвосте по принципу "делай как я".
Скорее попросит кого то, что бы ему помогли со скриптовой частью и тестами.
I>>Важно, что бизнес смотрит на софт со стороны фронтенда.
V>Основная масса работников — бухгалтера, касссиры, кладовщики, экспедиторы и т.д. работают с локальными GUI-приложухами, которые вовсе не на Электроне.
Пока что да. Но ситуация в целом меняется, хотя и не быстро. Никто в своём уме не переписывает приложения абы переписать.
V>А тебя послушать, так разработчики БД тоже не нужны, и вообще все те, кто не имеет к JS отношения.
Нужны. Только бизнес сможет понять, что БД работает как положено, когда поиграется с функционалом, доступным на фронтенде.
По другому бизнес не умеет, т.к. образование и опыт у него совсем не в той области.
V>Но ключевые, влияющие на основной юзер-экпиренс — нет.
Успойся, среди самых продвинутых стриминговых сервисов нет ни одного с выдающимся UI. Эти вещи давно обкатаны на жээсе.
Выбор не-жээс обоснован нем, что телевизор имеет крайне ограниченый набор возможностей, куда не впилишь хром-подобный движок.
Вот и всё.
V>Во-первых, Lua компиллируемая, исходников скриптов у клиента не будет.
Тем не менее Lua это скриптовый язык.
I>>Не заметил тут ничего высокооптимизированого. Такой UI встречается в вебе с 10х. Я не занимаюсь фронтом, вобщем, могу и ошибаться.
V>Или у тебя нет телека последних поколений или на этом телеке ты не установил и не подписался на какой-нить сервис-кинотеатр. V>Дык, установи, подпишись, приходи опять, поболтаем...
Давно. О чем и говорю — твой пример с Ivi и MeGoGo кроме смеха ничего не вызывает.
V>Это ты про браузерную морду?
Это про то, что я вижу в телевизоре последнего поколения.
V>Опять твоя стандартная ошибка — это ж бесплатное приложение.
Ты телепатию то выключаешь хоть иногда?
V>Но платят-то люди за подписку, которой пользуются на телеке, а не на сайте.
Я перепробовал целую кучу провайдеров и выяснил, что твои, которые ты назва "высокооптимизированые" вобщем ничем толком и не блещут.
Megogo — на троечку. Ivi — на двоечку.
UI заимствован из веба, ничего оригинального и интересного. Ну разве что для перформанса оверлеи прикрутили.
Зато опаскудили стейтменеджмент. Предполагаю "написали mvc с 0-ля"
V>Я не могу судить в асболютном смысле, но могу сравнивать с браузерной версией. V>И тебе того же советую объективности ради.
Т.е. ты сравнил дерьмо с дерьмом и мне того же советуешь? Возьми да прикрути другие сервисы, есть куда удобнее и UI интереснее.
V>GUI локальной приложухи Нетфликс особо от ivi не отличается по функционалу. V>Но в плане контента ivi прикольней, всё-таки у Нетфликс упор на собственный контент, оно им, такое ощущение, "тычет в морду".
UI Ivi кривой шо сабля, а Netflix хотя бы стейтменеджмент сделали годным.
V>И даже здесь ты включил демагогию — lua не описывает GUI, а ты рассуждал, что "бизнес видит, за что платит". V>В игрухе клиент видит работу графического движка, писанного на С++, работу низлежащей графической технологии, типа OGL/Metal и т.д., написанных на Си. V>(если DirectX, то С/С++)
HUD как правило это скриптовая работа. Менюхи — скриптовая. Поведение персов — скриптовая. AI — скриптовая.
V>Это где ты работаешь, разработка GUI — ничтожные издержки.
Снова телепатия?
V>А приложухи типа Тимы, Слак, Скайп — это серьезные приложухи по меркам остальных проектов на Электрон-подобных фреймворках.
Конечно серьёзные, кто бы спорил. Только их же бакенд куда больше по бюджету.
V>Дешманские камеры не имеют множества настроек.
Понял. Тебе и здесь нужен закат солнца вручную
V>>>Мы говорим о том, что за GUI на ЖС не платят. I>>И откуда у толп жээс фронтендов ЗП берется?
V>У этих "толп" невысокая ЗП.
hh с тобой не согласен. Фронтов, во первых, намного больше с++. А во вторых, ЗП как минимум не хуже.
Собственно влияние спроса никто не отменял, а на фронт спрос дичайший.
I>>UI вообще тормозил во все времена.
V>Последний раз в 1995-м году.
Успокойся. Отмотай форум на 5, 10, 15 и 20 лет назад и найдешь плак и ной
— ааа, тормозит скайп
— ааа, тормозит мфц
— ааа, тормозит скайп
— ааа, тормозит UI xxx
— ааа, тормозит UI yyy
Я тебе страшное скажу — в 90х было ровно то же. И даже вне винды, в том же ДОС было ровно так же.
Хоть на ассемблере, хоть на СИ, а найдется некто, кто не справится с перформансом.
V>На компьютере из 2000-го года, когда нейтивное GUI уже давно летало со скоростью света, современные поделия на Электроне+JS+ноде будут минутами запускаться, потом по десятку секунд реагировать на каждый клик. ))
Что тормозило на этих самых компьютерах из 2000го можно узнать из форумов того времени.
I>>И когда был на MFC, и когда на WTL, и на QT. Даже консольный UI в дос приложениях тоже тормозил. Как только что более менее нормально — "UI тормозил"
V>Уже в 1998-м это всё не тормозило от слова никак.
Наоборот
V>И консоль тормозила только виндовая, потому что у неё медленный скролл.
Я тебе про дос, а ты мне про винду.
Куча жалоб была, скажем, про Dos Navigator, что в ём консольный UI тормозит.
V>Только не из виндовой консоли удалённо или в докере, бгг...
Можно запросто найти софтину, которая делает закат солнца вручную, и делает меееееедленный вывод в консоль. Вывод — консоль тормозит
I>>Тот же Скайп здесь же ругали задолго до его покупки Микрософтом. I>>Отлистай форум да убедись. V>Зато до покупки MS ...
То есть, ты не отрицаешь, что Скайп тормозил во все времена. Ну и славненько.
V>Ну конечно, народ валом повалил со скайпа на конкурирующие технологии, поэтому Скайп до сих пор не отбил вложения.
Миллиарды продаж в год и не отбил?
V>Если бы эту версию выкатили для UWP тогда, ситуация могла развиваться по-другому.
Ога. Кокурентов скайпа выросло столько, что по пальцам не пересчитаешь.
В приложениях типа скайпа должен быть UI на веб-основе, иначе плакать будешь горькими слезами. Например, тебе придется написать свой рендеринг html но для uwp.
I>>В конце 90х связка MFC и IE была одной из самых популярных тем — см. IE4.
V>Свяка MFC и IE изкаробки появилась в 6-м MFC, который я использовал с 99-го года, а пик пришёлся на начало нулевых.
Это в вашей конторке пик был в начале нулевых. А во всем мире он как раз спадать начал к тому времени, т.к. в начале нулевых дотнет просто сдул почти весь МФЦ.
Здравствуйте, vdimas, Вы писали:
I>>Что делать, например, на винде, когда нет ни dpkg ни rpm ?
V>Для начала выйти на минуточку в гугл.
Похоже, это основной аргумент. Какие функции тебе нужны от пактеного менеджера, когда ты разрабатываешь софтину?
I>>Вероятно, ты предложишь эмулировать средствами nuget
V>В своей конторе мы распространяем внутренние либы С++ на виндах через NuGet через artifactory. V>Для линухов — родными пакетными менеджерами этих систем.
Именно. Т.е. нет инструмента чисто для разработки на плюсах, как nuget для дотнета, как npm для js.
V>А зачем NuGet "эмулировать"?
Ты мне объясни, это ж ты эмулируешь при помощи nuget "мы распространяем внутренние либы С++ на виндах через NuGet через artifactory"
То есть, ты буквально написал, что для с++ в винде у вас родного инструмента нет, и вы побираетесь, эмулируя этот инстурмент при помощи nuget.
Re[28]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>Ресолвинг в С++ — это поиск и конфигурирование путей к заголовкам и библиотекам. Изобретение своих трактовок для общепринятых терминов — ну, так.
V>Ты даже не представляешь, сколько всего мы ждём. V>Но это всё бесплатное-опенсорсное. V>Если ты или я это не сделаем — никто не сделает. V>По крайней мере в ближайшие месяцы/годы/десятилетия. V>А лично мне реально некогда... V>Для меня эта задача, положа руку на — тьфу, за полтора года успею примерно такое: V>- сделаю первую версию V>- получу по мозгам критику отовсюду, исправлю/доработаю V>- потом опять добавлю/исправлю, к 3-й версии всё будет более-менее. V>Через полтора года ты сможешь хвастаться всем этим... V>И буквально малюсенький вопрос стоит — кто мне будет ЗП платить за этот период? ))
Нет. Даже если мы наймём команду из десяти человек, то через пять лет у нас будет 115й способ собирать проекты на С++, с околонулевым комьюнити.
Мы только увеличим фрагментацию, которой и так достаточно.
V>Чем дальше, тем больше поддиректорий в поддиректории build.
Вот именно это наращивание поддиректорий и есть семидесятые.
V>С вероятностью успеха примерно 50%.
С чего это?
V>Для каждой сборки Linux свой файл. V>Спасает то, что многие сборки являются как бы ответвлениями от "материнкой" сборки. V>Например, чуть ли не половина сборок базируются на DEB-Linux.
Ну вот это и есть ужас.
V>Откуда именно?
Откуда наконфигурили, оттуда и устанавливаются.
V>Этого в Джава нет.
И maven и gradle умеют качать зависимости.
V>С++ тут не при чём, это заморочки платформенного уровня.
Нет.
V>>>Просто для поржать — вот дефолотный "центральный" репозиторий: V>>>https://repo.maven.apache.org/maven2/ V>>>Пролистай до конца. V>>>Это всё. S>>Берём первый попавшийся Java проект на гитхабе: https://github.com/Anuken/Mindustry S>>Все зависимости качаются (если нужно) в процессе билда. Всё делается одной командой.
V>Не-не-не. V>Никакой "одной командой", и никаких "в процессе билда".
Именно одной командой.
gradlew desktop:dist
V>Это разработчики либы нехило озаботились впендюрить такую функциональность. V>Но "стандартной" такой нет.
Берём другой первый попавшийся проект на java. https://github.com/apache/pinot#building-pinot
mvn clean install -DskipTests -Pbin-dist
V>А так-то, если поднапрячься, то в любой технологии можно впендюрить подобное. V>Будет ли это что-то доказывать? — да аж ничего. V>Незначительные флуктуации вакуума...
Всё наоборот. Флуктуации вакуума — это C++ проекты, которые можно собрать где-то, кроме заботливо подготовленного енвайронмента. Потому что нет общестандартного решения. И никто его не ищет.
V>Была бы у тебя совесть, ты бы точно так же подобрал наоборот.
У вас был шанс подобрать наоборот. Но вместо примера репозитория, который честно стягивает зависимости и строится на более-менее любой платформе, мы имеем рассуждения о том, как круто было бы написать такой движок.
V>При чём тут "особенности языка"? V>Речь о зависимостях.
Я думал, это очевидно. В приличных языках ещё со времён Pascal есть средства модульности — прямо на уровне языка.
То есть я прямо в исходнике могу промаркировать зависимости.
Есть понятие модуля — есть искушение сделать систему распространения модулей. Это, конечно, необязательно (например, для паскаля или Delphi ничего подобного до сих пор не существует, афаик).
А в С++ всё что есть — #include "lib.h". Вот уж не думал, что придётся объяснять базовые вещи.
V>Проблема в том, что разные сборки линуха даже имеют разные АПИ уровня ОС.
А это-то тут при чём? В АПИ уровня ОС упирается маленькая часть RTL. Да, её можно делать платформенно-зависимой.
Большая часть логики никакого отношения к ОС не имеет. Нафига мне в каком-нибудь парсере/сериализаторе JSON АПИ уровня ОС?
Тем не менее, даже парсеры JSON вынуждены проходить через унижение "опиши 15 способов сборки для каждой среды".
V>В исходниках затем ветвление на макропроцессоре: есть в АПИ ОС eventfd — пользуем, нет — эмулируем на пайпах и регистре-защёлке.
S>>"нам не нужны модули, достаточно текстового препроцессора для инклуда хидеров". "Нам не нужен ABI, пусть он остаётся платформенно- и компиляторо-зависимым". Повторное использование в С++ просто имеет самый низкий приоритет. Какая-нибудь убогая нода с самого начала проектировалась для повторного использования, поэтому там из коробки менеджер пакетов.
V>Поэтому она тормозит. ) Рассуждения уровня "а ещё я туда ем".
Нет, тормозит она не поэтому. По вашему же мнению, лучший в мире менеджер пакетов сейчас у C#. Как мы знаем из бенчмарков, C# вовсе не тормозит. Удивительным образом, оказывается что наличие модульности и менеджера пакетов не коррелирует с быстродействием.
V>Ну если нет в АПИ ОС eventfd, то никакие твои причитания на форумах это не изменят, не понимаешь, что ле? ))
А что, у нас 100% проектов нуждаются в eventfd? И те, которые нуждаются — никак не могут использовать некую абстракцию, изолированную в отдельной библиотеке, которая для каждой платформы предоставляет свою реализацию?
Или это упражнение по проектированию архитектуры — rocket science для C++?
V>Любой чирикающий попугай, который попробует нести чушь на эту тему, автоматически приравнивается к домохозяйке, которой нечего делать в подобных обсуждениях. V>Как грится, идите лучше накрутите бигуди, а взрослых дядек от работы отвлекать не надо. V>И без вас хлопот хватает...
Ваш любимый приём — увести разговор в сторону
V>Судя по описанию — это драйвер.
Нет, это любой первый попавшийся проект.
Попробуйте навелосипедить какой-нибудь простейший парсер CSV так, чтобы его мог использовать С++ разработчик, работающий на любой платформе и компиляющий под любую целевую платформу.
Либо страдать будет этот разработчик, привинчивая интеграцию со своим проектом, либо вы, готовя 150 инструкций про то, как вами пользоваться под каждой из платформ.
Драйвер, my ass.
V>Что угодно можно вылечить чем угодно.
Вопрос только в объёмах. Современные платформы разработки берут значительную часть геморроя на себя. С++ перекладывает его на конечного разработчика — вот и всё.
Как вы уже неоднократно доказали, можно и С++ проект научить нормально собираться — просто для этого придётся потратить на порядок больше усилий, чем в любой java/node/python/ruby/etc.
V>Но интересуют "стандартные" сценарии. V>Остальное от лукавого.
Согласен. В С++ стандартных сценариев вовсе нет. Остальное — от лукавого.
V>И нода же пользуется отдельным файлом зависимостей? V>И питон? V>А почему С+ нельзя?
Можно, но С++ требует много файлов зависимостей.
V>Ты всерьёз считаешь, что для сборки С++ запрещено писать сборочные скрипты? ))
Не запрещено. Вопрос — в объёме.
V>У меня такое сложилось ощущение, что ты пока не определился, что именно ты пытаешься доказать.
Вот как раз наоборот. У вас то идёт бред про то, что одна команда npm install — это невыносимая боль; то про то, что написать 5 файлов зависимостей и десяток скриптов для сборки — это норм. V>Судя по всполохам мыслей — чисто потрындеть ни о чём.
V>С++ не обязывает тебя к этому — пиши такие же скрипты. V>Собсно, в большинстве С++ проектов есть готовые скрипты примерно под десяток платформ или больше. V>Но соберу проект и без них под любую платформу. V>Потому что хорошо работающий код бесценнен, а потраченное время нуба на "а как собрать этот проект???" ничего не стоит. V>Не умеешь — потерялся и не раздражаешь. V>Идёшь семечками торговать.
Вы другими словами изложили ровно мою точку зрения: С++ проектировался для того, чтобы люди страдали. Не для того, чтобы облегчить им работу, т.е. достижение их целей.
Для людей, время которых ничего не стоит.
V>Не имеет центрального реестра, поэтому не работает в ситуации, когда ты форкнул проект с github.
Можно пример проекта с github, который я не смогу собрать, форкнув?
V>Открой для себя TeamCity.
V>Всё-равно всё реально работающее написано на плюсах. V>И нода, и питон, и дотнет.
Ну и что?
V>На практике 5 платформ: DEB, RPM, Pacman, Zypper, Nuget. V>Остальное экзотика. V>И даже экзотики вряд ли наберётся более 10 вариантов к перечисленному.
15 платформ. Ну, ок, вы считаете это нормой. Мы — нет.
V>Только моск не выносите своим нытьём.
V>А по банальной причине — универсального ответа на любой вопрос нет.
У всех есть, и только у С++ вместо него "а что вы имеете в виду???".
Детский сад.
V>На уровне исходников проблем нет.
Вот лучше даже не начинайте.
V>Главное что? — предоставить соотв. ср-ва для написания максимально-эффективного кода для данной платформы.
Вы опять пересказываете мои же высказывания своими словами. Да, совершенно верно — если я пишу на машине X код для сборки на машине X и исполнения на машине X, то всё хорошо.
Наверное, на заре С++ это была штатная ситуация; оттого никто вообще не заморачивался вопросами "а как мне собрать мой код вместе с библиотекой, которую разрабатывали на машине Y". V>Все ср-ва сборки и конфигурирования тоже есть, иначе было бы невозможно включать эти проекты (а их многие-многие тысячи) в дистрибутивы Linux.
Ну это не означает, что эти средства чем-то хороши.
V>Это потому что сама Windows не имеет. V>Отсылаю твои претензии к MS.
Ну, ноду вроде же проектировали вовсе не для винды, не так ли? Тем не менее, в неё сразу вставили npm. Буквально у всех современных языков или платформ есть свои средства управления пакетами.
Для них куда претензию отправлять? Торвальдсу?
V>И как же оно отстаёт, если использует тот же NuGet? V>А как, по-твоему, вообще возможно собирать эти многие тысячи пакетов в сборке Linux, если там всё так плохо?
Как-как, известно — через ежедневный, тупой, монотонный труд.
V>Ты это сейчас всёрьез? V>Большинство проектов в *никсах собираются так: V>
V>make configure
V>
V>потом: V>
V>make
V>
V>потом: V>
V>make install
V>
V>И это норма еще с 1985-го.
Отлично. Дайте мне такой проект, я соберу его на своём ноуте.
V>Я помню наши споры про соционику. Да, вы тогда фееричненько зажгли.
V>Помню твои восклицания, мол, прочитал о Есенине — да, это я. V>Это как раз нормально. V>Ненормально, когда ДонКихот говорит, да, я Есенин. V>Потому что ты не Дн-Кихот.
V>Это или безотцовщина или отец твоим воспитанием не занимался.
Вот ведь неизбежный же переход на личности. Самое смешное, что вы до сих пор не понимаете, что каждый такой переход — он ваши же комплексы высвечивает.
Такие рассуждения уместны в кружках психологической взаимопомощи, типа анонимных алкоголиков.
В технических форумах — это симптом тяжёлых неврозов. Я так-то и сам телепат со стажем, могу даже диагноз поставить. Но это — оффтоп, так что воздержусь. Чего и вам советую, а то опять до бана доведёте.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>В последний раз, когда я трогал С++ проект (я уже и не помню, что это было), там было полторы страницы инструкций, что откуда скачать и что куда положить, чтобы оно начало собираться. S>Половина ссылок вела на мёртвые сайты, остальная половина — на устаревшие версии библиотек, которые уже не поддерживались.
Был у меня похожий опыт. Нашел на гитхабе Си код для одной игрухи. Около 300кб плотного упоротого по самые нидерланды сишного кода, в духе 80х лучшем случае. Собственно, код не самой игры, а результат реверс-инжинринга выполненного каким то маньяком Как собрать — не ясно. Старая версия либ более недоступна, новая — несовместима.
12 лет лет код протухал на гитхабе.
Написал автору — никакого ответа.
Потыкался, помыкался, а потом взял и портировал на TypeScript 0.9, 1 в 1. Ужаснулся, конечно, много раз, по дороге. Но игруха завелась, т.е. скомпилировалась.
Далее, прикрутил к ней рендериг(Canvas), клавиатуру, джойстик и загрузку-сохранение. И это оказалось еще проще, чем в тех либах.
И вот сижу я, поигрываю, и вижу, что появилась оригинальная игра вместе с эмулятором. Полез я сравнивать и выяснил, что в моем коде воспроизводятся многие баги той игры, включая рендеринг.
Re[29]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Ресолвинг в С++ — это поиск и конфигурирование путей к заголовкам и библиотекам. S> Изобретение своих трактовок для общепринятых терминов — ну, так.
S>Нет. Даже если мы наймём команду из десяти человек, то через пять лет у нас будет 115й способ собирать проекты на С++, с околонулевым комьюнити.
Это ты и на работе так технические решения принимаешь?
Кошмар... ))
Взять тот же MSBuild и допилить его до интеграции с Nuget и для C++ проектов.
А потом портировать эти изменения в Linux, в которых и MSBuild и NuGet тоже присутствуют после установки .Net Core.
При этом для нейтивных проектов поле TargetFramework можно было бы использовать для ID платформы, например "Ubuntu 18.04".
Или добавить специальное поле — не принципиально.
А что ты там себе вообразил — я ХЗ.
S>Мы только увеличим фрагментацию, которой и так достаточно.
Остапа понесло...
V>>Чем дальше, тем больше поддиректорий в поддиректории build. S>Вот именно это наращивание поддиректорий и есть семидесятые.
Наоборот, в 70-е практически не было кросс-платформенных проектов, готовых изкаробки к сборке и деплою.
Это всё современные веяния, кучно пошли где-то в нулевых и только расширяются со временем.
V>>С вероятностью успеха примерно 50%. S>С чего это?
С того, что это эвристическая хрень.
У питона нет описания проектов и их зависимостей.
Зачастую "продукт" на Питоне — просто файл скрипта.
В самом файле питоновского скрипта зависимости ищутся через путь, настроенный для машинки питона, который (путь) можно изменять прямо из скрипта через вычисляемые в процессе работы скрипта строки.
Зависимости — не обязательно "пакеты", это просто просто еще один такой же файл, который ты скачал откуда-то из интернета и положил рядом или где-то в пути, который же и настроишь в процессе работы скрипта.
Импорт может быть вычислимым через exec:
aa="import bb"# здесь не обязательно константное выражениеexec(aa)
и т.д. и т.п. до бесконечности.
В общем, в Питоне тебе никто ничего не гарантирует, потому что язык такой.
V>>Для каждой сборки Linux свой файл. V>>Спасает то, что многие сборки являются как бы ответвлениями от "материнкой" сборки. V>>Например, чуть ли не половина сборок базируются на DEB-Linux. S>Ну вот это и есть ужас.
Что ужас, что есть несколько пакетных менеджеров?
Это как раз ерунда — за 10 мин пишется скрипт-хелпер, который из списка зависимостей сделает список их для локального родного пакетного менеджера и вызовет того для установки пакетов из списка. В 99% случаев это будет просто текстовый файл с перечислением имен/версий пакетов, который (файл) не потребуется как-либо изменять, а надо будет просто подать в аргументы вызова.
Если бы дело было только в разнообразии пакетных менеджеров, этот вопрос был бы решен давным давно.
Зоопарк в линухах не из-за наличия нескольких пакетных менеджеров, а из-за наличия большого числа независимых сборок, со своим составом пакетов и даже со своим именованием пакетов.
V>>Откуда именно? S>Откуда наконфигурили, оттуда и устанавливаются.
Ты просил скачать с гитхаба и чтобы само собралось, автоматом скачав зависимости.
Для джавы этого изкаробки нет.
А специально ручками уникально описать эту процедуру для некоего выделенного проекта можно для любого языка, бо закат солнца вручную еще никто не отменял.
Но оно не будет ответом на твой вопрос.
V>>Этого в Джава нет. S>И maven и gradle умеют качать зависимости.
А толку, если качать неоткуда, бо нет дефолтного репозитория, как есть у дотнета nuget.org?
что там происходит — если каких-либо зависимостей нет, то в процессе билда они загружаются в виде исходников и собираются на месте.
Это в разы круче, чем ты показал для Джавы.
Но это не является ответом на первоначальный вопрос.
Ты мне покажи проект на Джаве с лохматыми зависимостями, в котором оные указаны списком, не важно, плоским тектовым или в XML, типа requirements.txt или packages.config.
И чтобы "само" всё работало.
Найдёшь — приходи. ))
V>>А так-то, если поднапрячься, то в любой технологии можно впендюрить подобное. V>>Будет ли это что-то доказывать? — да аж ничего. V>>Незначительные флуктуации вакуума... S>Всё наоборот. Флуктуации вакуума — это C++ проекты,
Ты мне приводил в точности такие же флуктуации вакуума для Джавы.
Или это другое, нельзя сравнивать?
S>которые можно собрать где-то, кроме заботливо подготовленного енвайронмента.
Ну, CMake и git предварительно поставить придётся, не без этого.
(че-та ржу уже)
S>Потому что нет общестандартного решения. И никто его не ищет.
Как и в Джаве, во всех твоих примерах.
Ты ведь так и не привёл ни одного адекватного примера и никогда не приведёшь, потому что их для Джавы нет, в отсутствии единого репозитория пакетов.
И потому что у джавы слишком дохрена платформенно-зависимых этих пакетов, которые предназначены, скажем, для Linux, но не для Windows/MacOS и наборот.
И потому эти собранные пакеты в частных репозиториях могут бинарно отличаться друг от друга, т.к. собраны с различными опциями, где через опции можно выкинуть целые куски проекта, не нужные для данной платформы.
Но это другое, нельзя сравнивать.
V>>Была бы у тебя совесть, ты бы точно так же подобрал наоборот. S>У вас был шанс подобрать наоборот.
У тебя тоже был шанс, но ты не справился.
Я же не ожидал, что ты мне начнёшь приводить закаты солнца вручную.
А что, так можно было?
Если бы ситуация была наоборот, т.е. я тебя просил бы привести примеры, а ты бы привёл что привёл — я только поржал бы в лицо, как грится.
S>Но вместо примера репозитория, который честно стягивает зависимости и строится на более-менее любой платформе, мы имеем рассуждения о том, как круто было бы написать такой движок.
Потому что я рассуждаю о проблемах, а ты мне приводишь примеры, эти проблемы лишь демонстрирующие.
Тебе полегчало, что я тебе аналогичные примеры привёл?
Что-то это дало обсуждению?
Здравствуйте, lpd, Вы писали:
lpd>Они так действительно собираются в ходовых конфигурациях, но только если версии библиотек дистрибутива те же, что нужны пакету. И чтобы это работало стабильно, нужны большие усилия авторов проектов для написания конфигов autoconf и разруливания всевозможных вариантов опций и зависимостей. Все библиотеки при этом устанавливаются вручную, разумеется.
Почему "разумеется"?
Это у тебя такие представления?
Здравствуйте, Ikemefula, Вы писали:
V>>В своей конторе мы распространяем внутренние либы С++ на виндах через NuGet через artifactory. V>>Для линухов — родными пакетными менеджерами этих систем. I>Именно. Т.е. нет инструмента чисто для разработки на плюсах
Мде...
Сами *nix-системы — это исторически инструменты для разработки на Си.
Оттуда язык и пошёл.
И всё в этих операционках ему подчинено.
И все исходники, включая ядро, дрова, основные bin-utils, делающие никсы никсами, скрипт-машинки баша, питона, перла и т.д. — всё там сишное.
V>>А зачем NuGet "эмулировать"? I>Ты мне объясни, это ж ты эмулируешь при помощи nuget "мы распространяем внутренние либы С++ на виндах через NuGet через artifactory"
Я не вижу эмуляции.
Распространение сишных либ через NuGet в виндах — давно устоявшаяся практика.
Зайти на nuget.org, поищи по тегу native, там овердохрена пакетов.
Похоже, ты просто был не в курсе.
I>То есть, ты буквально написал, что для с++ в винде у вас родного инструмента нет
Здравствуйте, Ikemefula, Вы писали:
V>>А в чём проблема? V>>Мы же будем сравнивать современные возможности IDEA для поддержки JS, с возможностями IDEA из середины нулевых для поддержки Джавы. V>>Вот и посмотрим, достигла ли сегодня поддержка JS хотя бы того уровня 16-тилетней давности. I> А если например, назову Chrome Dev Tools
Т.е. насчёт IDEA ты слился?
ОК.
I>ты тоже будешь утверждать, что в середине нулевых такое было вообще везде? Ну, скажем, подключился к любой приложухе и сразу видишь вообще всё изнутри?
Если рядом лежит PDB-файл, то именно так.
V>>Пустой трёп. V>>Если бы ты знал такие примеры, где библиотеки JS используются в других языках, ты бы обязательно кинул в меня этими ссылками, со всей этой своей пролетарской ненавистью, тебе так характерной. )) I>Снова телепатия.
Т.е. ты не можешь привести примеры, когда JS экспортирует в остальную отрасль компетенцию.
Т.е. слился и по этому вопросу.
ОК.
I>Ты, похоже, и зп мою знаешь
Я знаю ЗП фронт-енд разработчиков.
V>>В этой реальности всё наоборот — нода импортирует в себя библиотеки из других языков. I>Какой смысл мне тебя разубеждать?
Чтобы показать, что ты не беспомощен в этом споре.
Но ты беспомощен — слился по всем своим утверждениям.
Сорри, это слишком скучно...
Re[7]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Mr.Delphist, Вы писали:
N>>Хм, я периодически читаю, как на винде делается настройка рабочей обстановки (куда и как записывать какие переменные, что в них вписывать), и сразу забываю, потому что понять этот продукт паука-наркомана невозможно. По сравнению с этим, методы в Unix банальны, просты и работают.
MD>Поэтому разные софтины кладут свои настройки и логи кто в /var, кто в /usr, а кто-то — в /etc
Есть FHS, который описывает, как различать разные виды данных и куда их складывать.
Фантастику типа "логи в /etc" вы явно сами придумали.
N>>Боюсь, с авторами Python периодически случается то же самое. Возможно, они выбирают добровольца, который одновременно применяет LSD и амфетамины, он в приходе лечит работу под Windows, потом он уезжает восстанавливаться и затем они ждут следующего камикадзе.
MD>А можно было бы просто нанять Win-программиста, чтобы сделал как положено на этой платформе.
У авторов Python нет недостатка в Win-программистах. Не-Win программисты, как я, даже пробовать не будут. А про Win-программистов я и написал выше свои прикидки о характере процесса.
MD> Ведь если я буду разрабатывать под Linux, вряд ли будет осмысленным переизобретать там RegEdit и системный реестр? И это вызовет праведный гнев "открытого" сообщества как alien-технология, верно? MD>Однако для "открытых" кроссплатформенных решений почему-то в норме вещей требовать ставить на винду эмуляцию package manager, воссоздавать структуру системных папок на пингвиний лад и т.п. Прямо по "демократическим методичкам" работают товарищи, не особо скрывая двойных стандартов.
Что-то я такого в полном виде не наблюдал. Package manager нужен везде, и если его под Windows нет, то это не "чужой устав", это отсутствие всякого устава. Никто вменяемый не требует, чтобы это был RPM или DEB, но нужен чёткий минимальный набор требований, которым тот должен удовлетворять. Вроде в этом году MS разродилась какой-то бетой такого менеджера, мне помнится?
The God is real, unless declared integer.
Re[30]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали: V>Ресолвинг зависимостей — это просто рекурсивное составление списка таких зависимостей.
По вашей же ссылке можно прочитать, что частью dependency resolution является скачивание файлов.
V>Это ты и на работе так технические решения принимаешь?
Это не техническое решение, а продуктовое. Above your pay grade, увы.
V>Взять тот же MSBuild и допилить его до интеграции с Nuget и для C++ проектов. V>А потом портировать эти изменения в Linux, в которых и MSBuild и NuGet тоже присутствуют после установки .Net Core. V>При этом для нейтивных проектов поле TargetFramework можно было бы использовать для ID платформы, например "Ubuntu 18.04". V>Или добавить специальное поле — не принципиально.
Ну, и?
Всё, что вы получили — ещё один способ собирать C++ проекты на линуксе.
Если, конечно, вы освоите вот этот вот простой момент "портировать изменения в Linux".
У меня есть некоторый опыт сборки С++ на линуксе при помощи msbuild. Это совсем не так просто, как вам кажется.
V>Импорт может быть вычислимым через exec: V>
V>aa="import bb"# здесь не обязательно константное выражение
V>exec(aa)
V>
V>и т.д. и т.п. до бесконечности.
На практике такого очень мало. 99.9% питонового кода просто пишет в начале import bb, и всё.
V>Что ужас, что есть несколько пакетных менеджеров?
Что кроссплатформенная сборка требует поддерживать N файлов зависимостей. V>Это как раз ерунда — за 10 мин пишется скрипт-хелпер, который из списка зависимостей сделает список их для локального родного пакетного менеджера и вызовет того для установки пакетов из списка. В 99% случаев это будет просто текстовый файл с перечислением имен/версий пакетов, который (файл) не потребуется как-либо изменять, а надо будет просто подать в аргументы вызова. V>Зоопарк в линухах не из-за наличия нескольких пакетных менеджеров, а из-за наличия большого числа независимых сборок, со своим составом пакетов и даже со своим именованием пакетов.
Та же проблема — вид сбоку.
V>Ты просил скачать с гитхаба и чтобы само собралось, автоматом скачав зависимости. V>Для джавы этого изкаробки нет.
Я на джаве не писал лет 15, но первые пара случайно ткнутых репозиториев на гитхабе устроены именно так. Качаешь JDK, чекаут, билд. Всё.
V>А толку, если качать неоткуда, бо нет дефолтного репозитория, как есть у дотнета nuget.org?
Дефолтный репозиторий, конечно же, есть. https://repo1.maven.org/maven2/
В данный момент в нём ~7 миллионов JAR-ов.
V>Смотрите сюда: V>https://github.com/Anuken/Mindustry/blob/master/build.gradle V>Это закат солнца вручную на пол-тыщи строк.
V>Такое можно для любого языка сделать. V>Вот тебе аналогичное для CMake: V>https://github.com/Slicer/Slicer/blob/master/SuperBuild.cmake#L226
V>что там происходит — если каких-либо зависимостей нет, то в процессе билда они загружаются в виде исходников и собираются на месте. V>Это в разы круче, чем ты показал для Джавы.
Не вижу ничего крутого — для джавы нет никакого смысла тащить исходники, т.к. формат JAR одинаков для всех платформ.
V>Ты мне покажи проект на Джаве с лохматыми зависимостями, в котором оные указаны списком, не важно, плоским тектовым или в XML, типа requirements.txt или packages.config. V>И чтобы "само" всё работало. V>Найдёшь — приходи. )) https://github.com/apache/pinot/blob/master/pom.xml
V>Ты мне приводил в точности такие же флуктуации вакуума для Джавы. V>Или это другое, нельзя сравнивать?
V>Дурдом.
А то.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[29]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Незначительные флуктуации вакуума... S>Всё наоборот. Флуктуации вакуума — это C++ проекты, которые можно собрать где-то, кроме заботливо подготовленного енвайронмента. Потому что нет общестандартного решения. И никто его не ищет.
Справедливости ради, С++ постепенно эволюционирует в сторону CMake для стандартной системы сборки. Пакетная система пока ещё находится на стадии флюктуаций, но Conan больше всего похож на лидера.
Так что возможно, что лет через 5 в С++ будет де-факто стандартный стек в Conan + CMake.
Sapienti sat!
Re[31]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Ресолвинг зависимостей — это просто рекурсивное составление списка таких зависимостей. S>По вашей же ссылке можно прочитать, что частью dependency resolution является скачивание файлов.
Ну, в дотнете отродясь не являлось, это было именно нахождение и рекурсивное построение зависимостей.
V>>Это ты и на работе так технические решения принимаешь? S>Это не техническое решение, а продуктовое.
ОМГ, "продуктовое". ))
"Техническое решение" в целом есть "Описание в заданной форме объекта проектирования/разработки или его части, необходимое и достаточное для достижения поставленных целей/решения поставленных задач по созданию АС"
В общем, если речь о способе реализации той или иной функциональности, озвученной в виде ТЗ, это именно техническое решение.
И предложенное тобой — изобретение нового способа собирать С++ проекты, расцениваю как неудовлетворительное. ))
Проекты С++ уже давно собираются MSBuild на Windows.
MSBuild уже есть на линухах.
Его просто надо доработать, например, дописать к нему плагины плюс файлы-конфигурации targets в поставке для конкретной платформы.
V>>Взять тот же MSBuild и допилить его до интеграции с Nuget и для C++ проектов. V>>А потом портировать эти изменения в Linux, в которых и MSBuild и NuGet тоже присутствуют после установки .Net Core. V>>При этом для нейтивных проектов поле TargetFramework можно было бы использовать для ID платформы, например "Ubuntu 18.04". V>>Или добавить специальное поле — не принципиально. S>Ну, и?
Э-э-э, не понял вопроса?
Разве ты был не в курсе, зачем потребовалось интегрировать Nuget в MSBuild?
Ликбез:
Package references, using the PackageReference node, manage NuGet dependencies directly within project files (as opposed to a separate packages.config file). Using PackageReference, as it's called, doesn't affect other aspects of NuGet; for example, settings in NuGet.Config files (including package sources) are still applied as explained in Common NuGet configurations.
With PackageReference, you can also use MSBuild conditions to choose package references per target framework, or other groupings. It also allows for fine-grained control over dependencies and content flow.
S>Всё, что вы получили — ещё один способ собирать C++ проекты на линуксе.
Я получу способ не просто доставлять зависимости в проект, а возможность тонко управлять этим процессом.
И не обязательно "всё переделывать" в уже имеющихся проектах.
(опять тебе неуд)
Озвученную функциональность можно было бы для начала использовать для настройки той самой автоматической доставки зависимостей.
А собирать можно именно так, как проект уже собирается, например, через CMake.
Напомню, что MS Build — это просто платформа определения целей и их св-в, зависимостей м/у целями, а так же т.н. "элементов".
Это что-то типа NAnt (если ты в курсе, что из себя представляет NAnt).
Конкретные цели и элементы есть как встроенные в MSBuild, так и существующие в виде внешних плагинов.
Не думаю, что плагин для запуска CMake прям такой уже был бы сложный.
И есть полезные тонкости — CMake может вызываться с кучей прикладных опций — переменных билд-проекта.
Например, я вызывают его с разными аргументами под разными платформами.
Дык, через MSBuild можно было бы автоматизировать наполнение этих опций.
Всё-таки, MSBuild, как и весь .Net Core — это платформенная весчь, которая может и должна брать на себя некие уникальные моменты текущей платформы, давая возможность разработчику абстрагироваться от них.
S>Если, конечно, вы освоите вот этот вот простой момент "портировать изменения в Linux".
Я этим последние 20+ лет и занимаюсь, собсно.
В последние годы еще портирование в MacOS.
Т.е., более-менее ориентируюсь в том, что и как потребуется делать.
S>У меня есть некоторый опыт сборки С++ на линуксе при помощи msbuild. Это совсем не так просто, как вам кажется.
Дык, MSBuild всё еще сырой, не зря его версии скачут чуть ли не в два раза быстрее версий Студии.
Его еще дорабатывать и дорабатывать.
Но он движется в правильном направлении.
Разумеется, рано или поздно он покроет и C++ проекты, причём, кроссплатформенно.
Но нужна будет в какой-то момент готовая инфраструктура, а именно — наполнение многими тысячами нетивных пакетов под разные платформы репозитория nuget.
В общем, речь просто шла о том, чтобы лучше всё это сделать раньше, чем позже.
Потому что прямо сейчас основная работа в .Net Core идёт над самим языком и над самой пожарной прикладной функциональностью — над тем же GUI, webasm/Blazor и т.д.
Остальное идёт по остаточному принципу.
V>>Импорт может быть вычислимым через exec: S>На практике такого очень мало. 99.9% питонового кода просто пишет в начале import bb, и всё.
Ну да.
И как назло мне однажды пришлось долго пинать нужный скрипт, потому что зависимости вычислялись динамически в зависимости от конкретной версии питона и версий других библиотек.
Т.е., выполнялись все те задачи, которые выше были процитированы для PackageReference в MSBuild.
В итоге пришлось аж лезть на сайт билд-машины ActiveState Python и там формировать образ специфичной инсталляхи Питона с конкретно-прописанными зависимостями библиотек, бо в дефолтной инсталляхе это всё не взлетало из-за конфликтов версий зависимостей других модулей.
Огромное спасибо разработчикам ActiveState Python за саму онлайн-возможность создавать уникальную инсталляху Питона, конечно...
С другой стороны, такая сложнейшая автоматизированная функциональность только и могла появиться по причине описанного бардака, т.е. недостатка питоновского пакетного менеджера, который не справляется с возникающими сценариями.
И опять скучно понимать, что собеседник не понимает и половины того, что ему пишут.
Не понимает даже — зачем. ))
Предлагаю вернуться немного назад в обсуждении и перечитать с новыми знаниями.
V>>Что ужас, что есть несколько пакетных менеджеров? S>Что кроссплатформенная сборка требует поддерживать N файлов зависимостей.
Иначе бы она не называлась cross. ))
Это была бы разработка под одну некую абстрактную платформу, коей уже 26 лет стремится стать Джава или почти 20 лет дотнет. ))
Но что-то хреново пока и там, и там.
В С++ с кроссплатформенностью в разы лучше.
Собсно, это пока единственное mature кроссплатформенное решение.
V>>Зоопарк в линухах не из-за наличия нескольких пакетных менеджеров, а из-за наличия большого числа независимых сборок, со своим составом пакетов и даже со своим именованием пакетов. S>Та же проблема — вид сбоку.
Это основная и единственная проблема.
Nuget работает как он работает лишь потому, что есть центральный репозиторий.
Было бы их десятки несовместимых (в т.ч. несовместимых по именованиям пакетов в них) — была бы такая же точно каша.
V>>А толку, если качать неоткуда, бо нет дефолтного репозитория, как есть у дотнета nuget.org? S>Дефолтный репозиторий, конечно же, есть. https://repo1.maven.org/maven2/ S>В данный момент в нём ~7 миллионов JAR-ов.
Но по твоей ссылке настраивается еще несколько репозиториев.
V>>что там происходит — если каких-либо зависимостей нет, то в процессе билда они загружаются в виде исходников и собираются на месте. V>>Это в разы круче, чем ты показал для Джавы. S>Не вижу ничего крутого — для джавы нет никакого смысла тащить исходники, т.к. формат JAR одинаков для всех платформ.
Ловко ты решил сменить фокус вопроса, зачётная демагогия.
Но и тут не прокатило — когда абстракции над железом/архитектурой станут бесплатными, тогда я приму этот аргумент.
Особенно в контексте этого спора — сравнения с С++.
И да, по одной из приведённых тобой ссылок, таки, некоторые зависимости для джава-проекта загружались в исходниках, просто ты невнимательно смотрел, что там по твоим ссылкам написано. ))
Re[30]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Cyberax, Вы писали:
C>Справедливости ради, С++ постепенно эволюционирует в сторону CMake для стандартной системы сборки. Пакетная система пока ещё находится на стадии флюктуаций, но Conan больше всего похож на лидера.
MS выкатила vcpkg, тот активно работает с git, т.е., они явно максимально будут использовать то, что купили гитхаб.
Re[32]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>Ну, в дотнете отродясь не являлось, это было именно нахождение и рекурсивное построение зависимостей.
Предлагаю закрыть бессмысленный технологический спор. Речь о том, что у всех не-динозавров есть решения типа
gem install
pip install
npm install
go get
и т.д. И в С++ неизбежно появится что-то вроде этого.
V>ОМГ, "продуктовое". )) V>
V>"Техническое решение" в целом есть "Описание в заданной форме объекта проектирования/разработки или его части, необходимое и достаточное для достижения поставленных целей/решения поставленных задач по созданию АС"
ТV>В общем, если речь о способе реализации той или иной функциональности, озвученной в виде ТЗ, это именно техническое решение.
Всё верно. V>И предложенное тобой — изобретение нового способа собирать С++ проекты, расцениваю как неудовлетворительное. ))
Вы опять спорите с голосами в голове. Техническое решение предложили вы, я вообще ничего не писал о "способе реализации".
V>Проекты С++ уже давно собираются MSBuild на Windows. V>MSBuild уже есть на линухах. V>Его просто надо доработать, например, дописать к нему плагины плюс файлы-конфигурации targets в поставке для конкретной платформы.
Совершенно неважно, доработаете ли вы мсбилд или у вас там будет какой-нибудь cpp restore.
Вы всё ещё барахтаетесь на детсадовском уровне — "как мне сделать xxx".
Чтобы из него выйти, надо научиться задаваться вопросами типа "зачем", а не "как".
С точки зрения современного С++ разработчика, вы предлагаете новый способ собирать проекты на линуксе. Потому что сейчас никто в здравом уме не собирает С++ на линуксе через msbuild, так что его наличие для линукса нерелевантно.
V>Э-э-э, не понял вопроса?
Оно и видно. S>>Всё, что вы получили — ещё один способ собирать C++ проекты на линуксе. V>Я получу способ не просто доставлять зависимости в проект, а возможность тонко управлять этим процессом.
Что-то мне подсказывает, что это не будет сильно тоньше, чем в CMake.
V>И не обязательно "всё переделывать" в уже имеющихся проектах. V>(опять тебе неуд)
V>Озвученную функциональность можно было бы для начала использовать для настройки той самой автоматической доставки зависимостей. V>А собирать можно именно так, как проект уже собирается, например, через CMake.
V>Напомню, что MS Build — это просто платформа определения целей и их св-в, зависимостей м/у целями, а так же т.н. "элементов". V>Это что-то типа NAnt (если ты в курсе, что из себя представляет NAnt).
V>Конкретные цели и элементы есть как встроенные в MSBuild, так и существующие в виде внешних плагинов. V>Не думаю, что плагин для запуска CMake прям такой уже был бы сложный.
Ага. То есть у нас msbuild запустит CMake, тот построит нужные файлы, и запустит msbuild...
Что-то не ладится. Главный вопрос: вот существующие проекты как перевести на вашу будущую технологию? Кто это будет делать, и зачем?
V>Т.е., более-менее ориентируюсь в том, что и как потребуется делать.
Поверю вам на слово.
V>Дык, MSBuild всё еще сырой, не зря его версии скачут чуть ли не в два раза быстрее версий Студии.
Дело не в MSBuild, а в том, как реализовать на нём кроссплатформенную сборку. Всё упирается в то, что под виндой уже написаны targets и props, рассчитанные на vc.
А для того, чтобы собирать, допустим, на линуксе те же самые проекты, таргетящие винду, придётся упасть и отжаться.
V>Но он движется в правильном направлении. V>Разумеется, рано или поздно он покроет и C++ проекты, причём, кроссплатформенно.
Насчёт "разумеется" я вовсе не уверен. Потому что ни Микрософт, ни Линукс комьюнити это не интересно.
V>Но нужна будет в какой-то момент готовая инфраструктура, а именно — наполнение многими тысячами нетивных пакетов под разные платформы репозитория nuget.
Воот, вы уже начинаете потихоньку понимать, что проблема — вовсе не в том, чтобы написать .targets, который использует для сборки gcc вместо vc. Кто будет делать это наполнение? Как вы их собираетесь мотивировать? Вот это — продуктовые вопросы, и на них удовлетворительных ответов нет.
Если бы комитет взялся продвигать какое-то одно решение — неважно, msbuild, nuget, или что-то особенное — то был бы шанс на консолидацию усилий.
А без этого над вами просто посмеются и всё.
Это как написать новый мессенджер — можно до хрипоты спорить, какой там брать протокол, на чём писать гуй, и какой язык программирования взять.
Но эти технические проблемы — ничто перед вопросом "а как сделать так, чтобы в мире, заполненном телегой, вайбером, ватсаппом и вконтактом, вашим мессенджером пользовался хоть кто-то".
V>В итоге пришлось аж лезть на сайт билд-машины ActiveState Python и там формировать образ специфичной инсталляхи Питона с конкретно-прописанными зависимостями библиотек, бо в дефолтной инсталляхе это всё не взлетало из-за конфликтов версий зависимостей других модулей.
Ужас какой.
V>Иначе бы она не называлась cross. )) V>Но что-то хреново пока и там, и там.
V>В С++ с кроссплатформенностью в разы лучше. V>Собсно, это пока единственное mature кроссплатформенное решение.
V>Но по твоей ссылке настраивается еще несколько репозиториев.
Вы так говорите, как будто это плохо. Кто-то из вендоров выбирает публикацию через свой репозиторий — это совершенно нормально. Вот вы же сами мне рассказываете о том, что в ваших проектах используются дополнительные репозитории nuget.
V>Но и тут не прокатило — когда абстракции над железом/архитектурой станут бесплатными, тогда я приму этот аргумент. V>Особенно в контексте этого спора — сравнения с С++.
Всё наоборот — это вы пытаетесь съехать с темы сборки на тему сравнения байт-кода с нативом. На голубом глазу делая вид, что не приводили только что LLVM как аргумент кроссплатформенности C++.
V>И да, по одной из приведённых тобой ссылок, таки, некоторые зависимости для джава-проекта загружались в исходниках, просто ты невнимательно смотрел, что там по твоим ссылкам написано. ))
Ну и отлично — вы сами же опровергли свой собственный аргумент. Только что загрузка исходников в С++ проекте была "в разы круче, чем в java", и тут же оказывается, что джава может делать то же самое — просто я невнимательно смотрел.
Прикольно с вами спорить — можно просто хмыкать, а вы сами себя закопаете.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, netch80, Вы писали:
N>Что-то я такого в полном виде не наблюдал. Package manager нужен везде, и если его под Windows нет, то это не "чужой устав", это отсутствие всякого устава. Никто вменяемый не требует, чтобы это был RPM или DEB, но нужен чёткий минимальный набор требований, которым тот должен удовлетворять.
Кому нужен? Почему нужен? Потому что "у нас так принято"?
Я ещё раз напомню про системный реестр и его "полное наличие" на линуксах. Похоже, пора начинать проповедовать туземцам что у них устава нету — кровавому режиму пингвинов осталось недолго
Прямо по "демократическим методичкам" работают товарищи, не особо скрывая двойных стандартов.
Re[26]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>>>Мы же будем сравнивать современные возможности IDEA для поддержки JS, с возможностями IDEA из середины нулевых для поддержки Джавы. V>>>Вот и посмотрим, достигла ли сегодня поддержка JS хотя бы того уровня 16-тилетней давности. I>> А если например, назову Chrome Dev Tools
V>Т.е. насчёт IDEA ты слился?
Я привожу тебе примеры.
I>>ты тоже будешь утверждать, что в середине нулевых такое было вообще везде? Ну, скажем, подключился к любой приложухе и сразу видишь вообще всё изнутри?
V>Если рядом лежит PDB-файл, то именно так.
Надо бы без "если".
V>Т.е. ты не можешь привести примеры, когда JS экспортирует в остальную отрасль компетенцию. V>Т.е. слился и по этому вопросу. V>ОК.
Похоже, ты старательно избегаешь эти примеры
I>>Ты, похоже, и зп мою знаешь V>Я знаю ЗП фронт-енд разработчиков.
Т.е. ты скромно берешь свои слова обратно
Я напомню, некто vdimas утверждал следующее:
"У нейтивного программиста твоего стажа ЗП примерно в три-пять раз выше твоей"
Раз так, то тебе известна моя зп.
Вобщем, как ни крути, даже если отталкиваться от фронтов, hh с тобой не согласен. Не видна разница в 3-5 раз между фронтами и нативными.
I>>Какой смысл мне тебя разубеждать? V>Чтобы показать, что ты не беспомощен в этом споре.
"в интернете ктото не прав" @ vdimas
Re[9]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Mr.Delphist, Вы писали:
N>>Что-то я такого в полном виде не наблюдал. Package manager нужен везде, и если его под Windows нет, то это не "чужой устав", это отсутствие всякого устава. Никто вменяемый не требует, чтобы это был RPM или DEB, но нужен чёткий минимальный набор требований, которым тот должен удовлетворять.
MD>Кому нужен? Почему нужен? Потому что "у нас так принято"?
Потому что без него получается очевидный полнейший бардак, который подтверждают как раз коллеги с винды.
MD>Я ещё раз напомню про системный реестр и его "полное наличие" на линуксах.
Плохая аналогия подобна котёнку с дверцей (tm).
Везде есть конфиги, а будут они файлами в /etc или в реестре — особенности местного стиля (у них свои преимущества и недостатки, но это уже второй уровень).
Я не предлагаю конкретно RPM или DEB. Я говорю про необходимость пакетного менеджера.
MD> Похоже, пора начинать проповедовать туземцам что у них устава нету — кровавому режиму пингвинов осталось недолго
Смотри, как бы эти "туземцы" тебя сами не "цивилизовали". Что-то винда за пределами десктопа чем дальше тем незаметнее.
MD>
MD>Прямо по "демократическим методичкам" работают товарищи, не особо скрывая двойных стандартов.
Двойные стандарты тут только в твоём воображении.
The God is real, unless declared integer.
Re[3]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, SkyKnight, Вы писали:
SK>На питоне много библиотек особенно для Data Science. SK>Если надо какой-то прототип чего-то накидать, то можно очень быстро на нем сделать.
Это следствие "переопределяемости" синтаксиса питона.
Ну и плюс несложная интеграция C/C++ (СPython) и простоты языка для пользователей.
Best regards, Буравчик
Re[27]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ikemefula, Вы писали:
V>>Т.е. насчёт IDEA ты слился? I>Я привожу тебе примеры.
Ты бегаешь от сути проблемы языка JS.
И мне жаль неплохой, в общем-то, язык TS из-за его вынужденной совместимости с JS.
Но эта гиря, походу, навечно.
I>>>ты тоже будешь утверждать, что в середине нулевых такое было вообще везде? Ну, скажем, подключился к любой приложухе и сразу видишь вообще всё изнутри? V>>Если рядом лежит PDB-файл, то именно так. I>Надо бы без "если".
Если речь об отладке, то надо как я написал.
V>>Т.е. ты не можешь привести примеры, когда JS экспортирует в остальную отрасль компетенцию. V>>Т.е. слился и по этому вопросу. I>Похоже, ты старательно избегаешь эти примеры
Я могу о них не знать — это же было твоё утверждение.
Просто ты не можешь его подтвердить.
I>>>Ты, похоже, и зп мою знаешь V>>Я знаю ЗП фронт-енд разработчиков. I>Т.е. ты скромно берешь свои слова обратно
Какие именно? Что я решил, что ты фронтенд разработчик?
И ты всё-равно меня не поправил пока, в какой области работаешь.
I>Я напомню, некто vdimas утверждал следующее: I>"У нейтивного программиста твоего стажа ЗП примерно в три-пять раз выше твоей" I>Раз так, то тебе известна моя зп.
Я дал тебе ссылки на ЗП+бонусы для нейтивных тимлидов, там примерно твоего стажа обычно достаточно, кто-то же должен упорядочивать основную массу более молодых разработчиков...
Еще я знаю ситуацию в Белоруссии, что там редко работают на заграничного работодателя напрямую, чаще оформлены в местной же конторе, примерные ЗП в которых я тоже знаю.
Мои оценки близки к истине, даже если ты занят не во фронтенде, а на бэкенде на JS.
Практически единственный для тебя выход в вашей реальности — самому создать подобное предприятие, т.е. быть его владельцем.
Набрать команду и проекты.
Тогда ты сможешь сократить разрыв в доходах примерно до 2-х раз.
И если ты до сих пор этого не сделал, со своими демонстрируемыми амбициями, то ты еще более странный тип, чем пытаешься казаться.
I>Вобщем, как ни крути, даже если отталкиваться от фронтов, hh с тобой не согласен. Не видна разница в 3-5 раз между фронтами и нативными.
Ну, для требуемого опыта 1-3 года разница не видна, конечно.
Там всегда будет колебания около минимума, за который люди вообще согласятся работать.
Ну и, хорошо известно, что в направлениях с "низкой планкой входа" ЗП в первые несколько лет может расти даже быстрее, особенно хорошо это было видно на примере Java-программистов в нулевые и десятые.
Но затем этот рост быстро входит в насыщение, и для дальнейшего роста доходов необходимо предпринимать "что-то еще" — например, уходить из игроков в тренера. ))
Такова неумолимая се ля ви.
I>>>Какой смысл мне тебя разубеждать? V>>Чтобы показать, что ты не беспомощен в этом споре. I> "в интернете ктото не прав" @ vdimas
Дык, назвался груздем, поступай далее по тексту.
Re[28]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>Ты бегаешь от сути проблемы языка JS.
Это как раз бенефит, для разработки простых вещей тебе кроме dev tools даже редактор не нужен. А для отладки-профилирования, анализа сетевых запросов, вообще ничего не надо.
V>И мне жаль неплохой, в общем-то, язык TS из-за его вынужденной совместимости с JS. V>Но эта гиря, походу, навечно.
Это целенаправленное решение, сделать его надмножеством JS. Именно отсюда растет его польза и как следствие, популярность.
Проверяется легко — многочисленные супер-мега-языки, которые 'улучшали' JS, давным давно испарились.
I>>Надо бы без "если". V>Если речь об отладке, то надо как я написал.
Я и говорю — надо без "если". В силу нативности плюсов такое принципиально невозможно. Глупо с этим спорить.
I>>Похоже, ты старательно избегаешь эти примеры V>Я могу о них не знать — это же было твоё утверждение. V>Просто ты не можешь его подтвердить.
Очевидно, что ты старательно пропустил все примеры
I>>Т.е. ты скромно берешь свои слова обратно
V>Какие именно? Что я решил, что ты фронтенд разработчик? V>И ты всё-равно меня не поправил пока, в какой области работаешь.
Какой смысл что либо тебе доказывать? Это же ты решил, что знаешь, где я работаю, какая у меня ЗП, и даже эмоциональное состояние.
Раз ты решил, сам и ищи аргументы..
V>Я дал тебе ссылки на ЗП+бонусы для нейтивных тимлидов, там примерно твоего стажа обычно достаточно, кто-то же должен упорядочивать основную массу более молодых разработчиков...
Единичный пример это не статистика.
V>Еще я знаю ситуацию в Белоруссии, что там редко работают на заграничного работодателя напрямую, чаще оформлены в местной же конторе, примерные ЗП в которых я тоже знаю. V>Мои оценки близки к истине, даже если ты занят не во фронтенде, а на бэкенде на JS.
Ну да, разброс ЗП всего от 100$ до 8000$ судя по hh
V>Практически единственный для тебя выход в вашей реальности — самому создать подобное предприятие, т.е. быть его владельцем.
И снова телепатия.
V>Тогда ты сможешь сократить разрыв в доходах примерно до 2-х раз.
2х раз относительно какой именно цифры? hh утверждает, что С++ в лучшем случае идет 1 к 1 с фронтом или хуже.
V>И если ты до сих пор этого не сделал, со своими демонстрируемыми амбициями, то ты еще более странный тип, чем пытаешься казаться.
А на кой ляд мне это делать? Похоже, у тебя снова приступ телепатии.
V>>>Чтобы показать, что ты не беспомощен в этом споре. I>> "в интернете ктото не прав" @ vdimas
V>Дык, назвался груздем, поступай далее по тексту.
На секундочку — это ты пытаешься приписать мне какие то мысли, эмоции, и тд.
А если например, назову Chrome Dev Tools, ты тоже будешь утверждать, что в середине нулевых такое было вообще везде? Ну, скажем, подключился к любой приложухе и сразу видишь вообще всё изнутри?
