Здравствуйте, Serginio1, Вы писали:
S>JS на первом месте, затем Питон, Java и C#, PHP и TS!!!
А складываешь проценты и получаешь сотни процентов вместо одной сотни.
Фуфел это.
Опрашивать необходимо было по основному языку или просить присваивать веса, если языков более одного.
Потому что который пишет в основном на TS, он укажет так же и JS.
Я тоже, помимо C++, укажу еще несколько языков, в ответе на вопрос "какие языки используете", в т.ч. JS и Питон.
Но статистика будет фуфел, бо скриптовые языки повсеместно используются в кач-ве языков для написания вспомогательных утилит.
V>>Смотрю как много Rust и TS вызывает вопросов на SO. )) S>TS это замена самому популярному языку. Вопросов много потому что активно развивается и куча нововведений!
Потому что ты не посмотрел на возрастную диаграмму — основному кол-ву участвующих в опросе 25-29 лет.
Собирающим статистику стоило бы присваивать веса и согласно возрастному распределению, чтобы выровнять статистику.
Иначе получается фуфел.
V>>Простое ветвление прямо в коде намного органичней смотрится, чем ветвление в JS, где или согласно условиям рендерят текст HTML, или ручками напихивают DOM, или переключают стили/классы видимые/невидимый. S> То же самое можно делать и напрямую создание компонентов в коде.
В коде выглядит еще более убого.
S>Кстати на Xamarin сначала вообще не было редактора и все описывалось в коде аналогично Dart,
В Dart выглядит неплохо, в отличие от Xamarin.
Язык специально затачивали под этот сценарий, чтобы описания GUI на Dart не уступало декларативному, но в итоге оно превосходит.
У тебя же интернет работает, чувство прекрасного должно быть — посмотри сам примеры описания GUI на Dart, что ты к этому XAML прицепился?
Твоя производительность на XAML заведомо будет в разы ниже, чем производительность на Dart (при сравнимом опыте в двух технологиях), а только это и имеет смысл, остальное бабушкины сказки.
S>но декларативно описывать проще
Если низлежащий язык не предназначен для декларативного описания.
Кстате, в С++ добавили именованные параметры, т.е. я ожидаю появления либ с описанием GUI в Dart-стиле.
S>Но при этом альтернативы, которая вытеснила HTML то и нет.
Пока в стандарте W3C будет только JS — и не будет.
Но это не означает, что JS клёвый.
S>Вот TS активно вытесняет JS, но он и компилируется в JS.
Одна поправочка — TS активно вытесняет JS где угодно, кроме фронтенда.
Во фронтенде весьма неактивно.
Я бы сказал даже — никак не вытесняет.
V>>С Unity ты не разбирался, посему твоё упорство выглядело странным. V>>Особенно когда ты не мог поверить, что в нейтивном релизе есть GC, но нет "среды". S>Угу чего мне не верить если в .Net Native есть GC но нет среды?
Это ты сам придумал.
S>Я говорил про отладку в среде и то, что для андроида она опциональна.
Ты много чего говорил, но цель этого мне плохо понятна.
Особенно твоя упоротость в плане "среда", "не среда".
Да пофик.
Назови хоть абракадаброй, главное ориентироваться, что эта абракадабра может, а чего нет.
S>И присутствует моно. Ты же отрицал моно и среду. Типа все в С++
Потому что возьми Unity, возьми какой-нить пример, собери релиз, убедись — никакого Mono, никакой среды, промежуточные файлы компиляции на плюсах.
Какие проблемы?
V>>Точный GC не может работать без метаинформации, поэтому, там и метаинформации овердофига. V>>Можно сравнивать у разных объектов результат вызова GetType(), работает is и as, работает проверка на отношение base/derived и т.д. и т.п. S>Ну во первых ты говоришь про CoreRT
Не я, я ссылки привёл, где CoreRT называли "средой".
S>который возможно и будет использовать JIT компилятор в рантайме.
Сам придумал?
Или почитал "новость" из 2016-го?
S>Но во всех твоих ссылках нет ссылок на JIT в рантайме!!!
Потому что AOT антагонист JIT.
S>is и as прекрасно работают в Delphi ибо есть информация в VMT по отрицательным смещениям.
Но нет остальной метаинформации.
А в CoreRT ты можешь взять список мемберов ссылочного типа в рантайм и взять значения этих мемберов.
В плюсах тоже есть кое-какая RTTI, но её можно отключить, если не используется.
V>>А насчёт докомпиляции — по ссылке для особо понятливых несколько раз повторяется, что это AOT-технология, но при этом используется тот же самый RuiJIT. S>Опять же речь про CoreRT. Опять проблема не AOT, а в рантайме.
Проблема в твоём вольном жонглировании терминами.
S>Для .Net Native нет JIT компиляции в рантайме, а значит и нет среды в нормальном понимантт.
А откуда ты взял своё "нормальное понимание"? ))
S>Под понятием среда в .Net Native это GC, без JIT компиляции в рантайме!
И что смущает?
V>>А тебя послушаешь, так даже в случае обычного дотнета, после того как JIT перевёл в нейтив весь наличествующий байткод, сразу "среда" перестаёт быть "средой". V>>Ведь происходящее далее не сильно будет отличаться от происходящего в .Net Native UWP. S> Нет я как раз приводил ссылку на различие NGEN и .Net Native! передергиваешь S>https://stackoverflow.com/questions/68114109/using-system-reflection-emit-in-uwp-with-net-native-tool-chain
Да нет, я сказал именно то, что сказал.
И мне плевать, что кто-то в рантайм что-то там генерит.
Это отдельная задача, требущая наличия соотв. средств.
Вот зачем ты мне дал ссылку на какого-то идиота, который хочет JIT и не хочет JIT одновременно? ))
Даже если всё остальное приложение требует именно сурового нейтивного исполнения, этому дятлу не пришло в голову взять какую-нить готовую скриптовую встраиваемую технологию, типа Lua или Питон: https://docs.python.org/3/extending/embedding.html
S>Образы IL Fallback — NGEN содержат как машинный код, так и MSIL для сборки (среди других структур данных). Если во время выполнения происходит что-то, что заставляет CLR нуждаться в машинном коде, который он не может найти в образе NGEN, он может вернуться к JITing.
Вооот!
Наконец-то ты показал суть своего непонимания. ))
NGEN предназначен для библиотек, ему обязательно нужен IL для возможности оптимизации кода, использующего библиотеку.
В отличие от NGEN, .Net Native запекает код проекта в один самодостаточный образ.
S>В текущем предварительном просмотре разработчика .NET Native в нативном образе присутствует только нативный код. Это означает, что если код отсутствует в изображении, он никогда не будет выполняться во время выполнения.
И это прекрасно! ))
S> Что по твоему должен компилировать JIT если не IL кода? S>>>Подтверди свои утверждения ссылками. Опять голословный треп. V>>А в сад тебе не прогуляться, к остальным двоечникам? )) S> Вот за что мне нравится с тобой общаться! Подымаешь настроение.
Нет, не поэтому тебе нравится со мной общаться.
А потому что у меня бесконечное терпение и так жизненно-необходимая тебе дотошность со стороны оппонента.
Остальные быстро от тебя отваливаются. ))
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
S>>JS на первом месте, затем Питон, Java и C#, PHP и TS!!!
V>А складываешь проценты и получаешь сотни процентов вместо одной сотни. V>Фуфел это.
V>Опрашивать необходимо было по основному языку или просить присваивать веса, если языков более одного. V>Потому что который пишет в основном на TS, он укажет так же и JS.
Ну ты напиши это в стэковерфлоу. Что для тебя не фуфел?
Даже из этого опроса не видно дарта. V>Я тоже, помимо C++, укажу еще несколько языков, в ответе на вопрос "какие языки используете", в т.ч. JS и Питон. V>Но статистика будет фуфел, бо скриптовые языки повсеместно используются в кач-ве языков для написания вспомогательных утилит.
Я например не использую. Значит TS и дарт ты не используешь?
V>>>Смотрю как много Rust и TS вызывает вопросов на SO. )) S>>TS это замена самому популярному языку. Вопросов много потому что активно развивается и куча нововведений!
V>Потому что ты не посмотрел на возрастную диаграмму — основному кол-ву участвующих в опросе 25-29 лет. V>Собирающим статистику стоило бы присваивать веса и согласно возрастному распределению, чтобы выровнять статистику. V>Иначе получается фуфел.
Ну для тебя все фуфел. Мы то говорили про дарт и ТС. ТС прет, дарта не видно!
V>>>Простое ветвление прямо в коде намного органичней смотрится, чем ветвление в JS, где или согласно условиям рендерят текст HTML, или ручками напихивают DOM, или переключают стили/классы видимые/невидимый. S>> То же самое можно делать и напрямую создание компонентов в коде.
V>В коде выглядит еще более убого.
Нет. То же само, что и в дарте. Но декларативно в XML или Json удобнее
S>>Кстати на Xamarin сначала вообще не было редактора и все описывалось в коде аналогично Dart,
V>В Dart выглядит неплохо, в отличие от Xamarin. V>Язык специально затачивали под этот сценарий, чтобы описания GUI на Dart не уступало декларативному, но в итоге оно превосходит.
Только почему то его активно не используют V>У тебя же интернет работает, чувство прекрасного должно быть — посмотри сам примеры описания GUI на Dart, что ты к этому XAML прицепился? V>Твоя производительность на XAML заведомо будет в разы ниже, чем производительность на Dart (при сравнимом опыте в двух технологиях), а только это и имеет смысл, остальное бабушкины сказки.
Потому, что декларативно многие вещи проще описываются. Ссылки плиз. На Xaml программируют куча народа.
Кстати про популярность фреймворков
Твой хваленый флутер совсем на немного опережает Xamarin
S>>но декларативно описывать проще
V>Если низлежащий язык не предназначен для декларативного описания. V>Кстате, в С++ добавили именованные параметры, т.е. я ожидаю появления либ с описанием GUI в Dart-стиле.
В C# давно именованные параметры, а в котлине еще проще
S>>Но при этом альтернативы, которая вытеснила HTML то и нет.
V>Пока в стандарте W3C будет только JS — и не будет. V>Но это не означает, что JS клёвый.
Нет, это означает, что дарт еще долго не будет востребован
S>>Вот TS активно вытесняет JS, но он и компилируется в JS.
V>Одна поправочка — TS активно вытесняет JS где угодно, кроме фронтенда. V>Во фронтенде весьма неактивно. V>Я бы сказал даже — никак не вытесняет.
Ну я не знаю почему всякие там электроны не используют TS, но TS только за счет интеллисенса выгодней, не говоря уже об проверки ошибок.
V>>>С Unity ты не разбирался, посему твоё упорство выглядело странным. V>>>Особенно когда ты не мог поверить, что в нейтивном релизе есть GC, но нет "среды". S>>Угу чего мне не верить если в .Net Native есть GC но нет среды?
V>Это ты сам придумал.
Ссылку сестра, на то, что используется il и Jit в рантайме
S>>Я говорил про отладку в среде и то, что для андроида она опциональна.
V>Ты много чего говорил, но цель этого мне плохо понятна. V>Особенно твоя упоротость в плане "среда", "не среда". V>Да пофик. V>Назови хоть абракадаброй, главное ориентироваться, что эта абракадабра может, а чего нет.
Возьмем твое утверждение
С Unity ты не разбирался, посему твоё упорство выглядело странным.
Особенно когда ты не мог поверить, что в нейтивном релизе есть GC, но нет "среды".
Jit это среда!!
Но когда я говорю, про .Net Native, что там только GC, ты утверждаешь, что там есть среда. S>>И присутствует моно. Ты же отрицал моно и среду. Типа все в С++
V>Потому что возьми Unity, возьми какой-нить пример, собери релиз, убедись — никакого Mono, никакой среды, промежуточные файлы компиляции на плюсах. V>Какие проблемы?
Угу тебе привели пример, что полно Il кода. Зачем он нужен без JIT?
И кто по твоему джитит код?
V>>>Точный GC не может работать без метаинформации, поэтому, там и метаинформации овердофига. V>>>Можно сравнивать у разных объектов результат вызова GetType(), работает is и as, работает проверка на отношение base/derived и т.д. и т.п. S>>Ну во первых ты говоришь про CoreRT
V>Не я, я ссылки привёл, где CoreRT называли "средой".
Да называют средой из-за сборки мусора. Но ты относительно юнити называл это чистым нативом.
Среда это JIT
S>>который возможно и будет использовать JIT компилятор в рантайме.
V>Сам придумал? V>Или почитал "новость" из 2016-го?
S>>Но во всех твоих ссылках нет ссылок на JIT в рантайме!!!
V>Потому что AOT антагонист JIT.
Мы говорим про среду. А среда это JIT. При чем тут AOT. NGEN это тоже AOT.
S>>is и as прекрасно работают в Delphi ибо есть информация в VMT по отрицательным смещениям.
V>Но нет остальной метаинформации. V>А в CoreRT ты можешь взять список мемберов ссылочного типа в рантайм и взять значения этих мемберов.
Для этого ты должен отдельно прописать какие типы ты будешь ипользовать. Можно указать все типы. Но информация о тип это не IL!
V>В плюсах тоже есть кое-какая RTTI, но её можно отключить, если не используется.
Ииии. Значит ты не можешь использовать is/
Как бы там ни было но для GC нужна для типа информация о размере выделяемой памяти и список смещений поле ссылочного типа. Но это не много.
V>>>А насчёт докомпиляции — по ссылке для особо понятливых несколько раз повторяется, что это AOT-технология, но при этом используется тот же самый RuiJIT. S>>Опять же речь про CoreRT. Опять проблема не AOT, а в рантайме.
V>Проблема в твоём вольном жонглировании терминами.
Неее мы говорим о среде. А среда это JIT!!!
S>>Для .Net Native нет JIT компиляции в рантайме, а значит и нет среды в нормальном понимантт.
V>А откуда ты взял своё "нормальное понимание"? ))
Пото му что ты говоря о IL2CPP говорил, что там нет нета, хотя и есть GC, при этом сборка идес по графу достижимых объектов!
Ссылки я тебе давал.
S>>Под понятием среда в .Net Native это GC, без JIT компиляции в рантайме!
V>И что смущает?
А то, что я тебе про это в самом начале говорил относительно IL2CPP. Но ты упорно называл это полным нативом причем с компиляцией C#.
Я сразу тебе написал и дал ссылку, что среда в .Net Native это GC, но ты упорно не считал это средой. А тут вдруг согласился
V>>>А тебя послушаешь, так даже в случае обычного дотнета, после того как JIT перевёл в нейтив весь наличествующий байткод, сразу "среда" перестаёт быть "средой". V>>>Ведь происходящее далее не сильно будет отличаться от происходящего в .Net Native UWP. S>> Нет я как раз приводил ссылку на различие NGEN и .Net Native! передергиваешь S>>https://stackoverflow.com/questions/68114109/using-system-reflection-emit-in-uwp-with-net-native-tool-chain
V>Да нет, я сказал именно то, что сказал. V>И мне плевать, что кто-то в рантайм что-то там генерит. V>Это отдельная задача, требущая наличия соотв. средств.
Да что там в рантайме то можно городить без Il кода??
Только сборка мусора, ну и аналог RTTI.
V>Вот зачем ты мне дал ссылку на какого-то идиота, который хочет JIT и не хочет JIT одновременно? ))
Я тебе привел ссылку на то почему нет JIT в .Net Native ибо просто нет Il кода который нужно компилировать!
V>Даже если всё остальное приложение требует именно сурового нейтивного исполнения, этому дятлу не пришло в голову взять какую-нить готовую скриптовую встраиваемую технологию, типа Lua или Питон: V>https://docs.python.org/3/extending/embedding.html
S>>Образы IL Fallback — NGEN содержат как машинный код, так и MSIL для сборки (среди других структур данных). Если во время выполнения происходит что-то, что заставляет CLR нуждаться в машинном коде, который он не может найти в образе NGEN, он может вернуться к JITing.
V>Вооот! V>Наконец-то ты показал суть своего непонимания. ))
V>NGEN предназначен для библиотек, ему обязательно нужен IL для возможности оптимизации кода, использующего библиотеку. V>В отличие от NGEN, .Net Native запекает код проекта в один самодостаточный образ.
S>>В текущем предварительном просмотре разработчика .NET Native в нативном образе присутствует только нативный код. Это означает, что если код отсутствует в изображении, он никогда не будет выполняться во время выполнения.
V>И это прекрасно! ))
S>> Что по твоему должен компилировать JIT если не IL кода? S>>>>Подтверди свои утверждения ссылками. Опять голословный треп. V>>>А в сад тебе не прогуляться, к остальным двоечникам? )) S>> Вот за что мне нравится с тобой общаться! Подымаешь настроение.
V>Нет, не поэтому тебе нравится со мной общаться. V>А потому что у меня бесконечное терпение и так жизненно-необходимая тебе дотошность со стороны оппонента. V>Остальные быстро от тебя отваливаются. ))
Ну в итоге ты наконец то согласился что среда в .Net Native это GC без JIT.
Так в итоге чем Юнити с IL2CPP отличается от .Net Native??
То, что у них допотопный GC это проблемы Unity. Но суть то там одна сборка идет по графу достижимых объектов, пусть и без уплотнения.
И приводи ссылки на свои утверждения. Поверь я рад ошибиться, но главное понять в чем я ошибаюсь
и солнце б утром не вставало, когда бы не было меня
A>>И управляемый код библиотек Unity работает в "родном" дотнете.
V>И что?
V>А в Unity не работает, потому что там не дотнет, там от IL-кода не остаётся даже следа.
Опятьже в дальнейшем я пишу S>И присутствует моно. Ты же отрицал моно и среду. Типа все в С++
Но ты пишешь
Потому что возьми Unity, возьми какой-нить пример, собери релиз, убедись — никакого Mono, никакой среды, промежуточные файлы компиляции на плюсах.
Какие проблемы?
Но при этом alexzzzz тебе пишет
На iOS нет IL, потому что политика платформы, и на WebGL нет IL, потому что так проще. На других платформах IL2CPP — альтернатива. Хочешь — пользуйся, если польза превышает вред. Не хочешь — не пользуйся, будет привычная цепочка: C# -> IL -> Mono JIT. Можно скачать игрушку, которая не использует IL2CPP, покопаться в ней обычным dnSpy, посмотреть как устроена и/или пропатчить как душе угодно. В процессе разработки в самом редакторе Unity весь управляемый код, пользовательский и Unity, работает на Mono JIT, никакого IL2CPP.
Мало того я тебе приводил ссылки на ссылки на Моно разработчиками Юнити
Моно на начальном этапе был и в Xamarin при этом на айфонах тоже компиляция в нейтив. Все та же технология .Net Native по аналогии с iL2CPP
При этом на андроиде все тот же Jit. И там тоже есть проблемы с рефлексией для создания объектов ибо компилятор режет Il код для минимизации сборок. Приходится явно указывать
используемые типы.
Ну и опять же про зазличие Юнити и .Net Native, когда утверждал что в .Net Native есть среда
С Unity ты не разбирался, посему твоё упорство выглядело странным.
Особенно когда ты не мог поверить, что в нейтивном релизе есть GC, но нет "среды".
V>>И среда там есть аж бегом, без ней .Net Native не живёт. S> Ну вот нет там среды!
Мои ссылки ты проигнорировал, но в итоге средой в .Net Native оказался все тот же GC. Да немного другой, но основанный на графе достижимых объектах
Так как нет Il кода, а значит и Jit. Но разве .Net Native это не дотнет?
Ладно вот завожусь я, а надо плюнуть и забить.
Ну и диалог это прежде всего познание того, че7го не знал Я почитал про юнити, надеюсь и наш диалог, тебе что то дал
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
V>>Но статистика будет фуфел, бо скриптовые языки повсеместно используются в кач-ве языков для написания вспомогательных утилит. S> Я например не использую. Значит TS и дарт ты не используешь?
Эти для утилит не использую.
V>>Потому что ты не посмотрел на возрастную диаграмму — основному кол-ву участвующих в опросе 25-29 лет. V>>Собирающим статистику стоило бы присваивать веса и согласно возрастному распределению, чтобы выровнять статистику. V>>Иначе получается фуфел. S> Ну для тебя все фуфел.
Не всё.
Но про SO раз в год вам приходится объяснять, почему эта статистика — фуфел.
Например, я и такие как я редко активно участвуют на этом сайте.
S>Мы то говорили про дарт и ТС. ТС прет, дарта не видно!
А почему не предположить, учитывая специфику SO, что Dart вызывает меньше вопросов?
И причин может быть несколько — и что сам язык и дока к нему более понятные, и библиотеки грамотные, а не россыпь зоопарка как для JS/TS, и сами разработчики обычно более опытные, бо кто выбирает Dart — это можно делать лишь осознанно, по факту сравнения технологий, а не по причине хайпа, как оно есть в TS/JS. ))
V>>В коде выглядит еще более убого. S> Нет. То же само, что и в дарте.
агащаз
S>Но декларативно в XML или Json удобнее
В XML — одноразово.
в Json нет стандартной разметки, каждая такая либа-хелпер трактует его уникально.
S>>>Кстати на Xamarin сначала вообще не было редактора и все описывалось в коде аналогично Dart,
V>>В Dart выглядит неплохо, в отличие от Xamarin. V>>Язык специально затачивали под этот сценарий, чтобы описания GUI на Dart не уступало декларативному, но в итоге оно превосходит. S> Только почему то его активно не используют
Достаточно активно даже согласно твоим ссылкам, особенно в мобильном сегменте.
Но в вебе да, не активно.
Насчёт веба смотреть надо не раньше, чем вызреет webasm, т.е. чтобы JS перестал быть навязываемой обязаловкой.
А пока делать выводы рано.
V>>У тебя же интернет работает, чувство прекрасного должно быть — посмотри сам примеры описания GUI на Dart, что ты к этому XAML прицепился? V>>Твоя производительность на XAML заведомо будет в разы ниже, чем производительность на Dart (при сравнимом опыте в двух технологиях), а только это и имеет смысл, остальное бабушкины сказки. S>Потому, что декларативно многие вещи проще описываются.
Вот поэтому и Dart, что прямо в коде выглядит декларативно, а код выполняется императивно.
S>Кстати про популярность фреймворков S>Image: wap6kvseu0i_5-ig9phx9iwosb4.jpeg S>Твой хваленый флутер совсем на немного опережает Xamarin
Вот именно.
И опережает Cordova, а это уже ого.
Смотрю, её опережает даже ReactNative, а тот не использует HTML в кач-ве рендер-движка приложения.
И да, на картинке намешаны различные фреймворки различных уровней (очередной фуфел).
Если оставить лишь имеющие отношение к GUI, то Flutter будет на 4-м месте.
Т.е. WPF, GTK, QT и прочие отстают от Flutter далеко, что аж не попали в топ на картинке, а ведь это всё еще важные фреймворки GUI в современном IT.
Но недавно вылупившийся Flutter сделал их как стоячих.
Еще вопросы?
V>>Если низлежащий язык не предназначен для декларативного описания. V>>Кстате, в С++ добавили именованные параметры, т.е. я ожидаю появления либ с описанием GUI в Dart-стиле. S>В C# давно именованные параметры, а в котлине еще проще
В C# перед каждым идентификатором стоял бы new.
Синтаксис массивов и лямбд тоже многословней.
V>>Пока в стандарте W3C будет только JS — и не будет. V>>Но это не означает, что JS клёвый. S> Нет, это означает, что дарт еще долго не будет востребован
Здравствуйте, Serginio1, Вы писали:
S> Но при этом alexzzzz тебе пишет S>
S>На iOS нет IL, потому что политика платформы, и на WebGL нет IL, потому что так проще. На других платформах IL2CPP — альтернатива. Хочешь — пользуйся, если польза превышает вред. Не хочешь — не пользуйся, будет привычная цепочка: C# -> IL -> Mono JIT. Можно скачать игрушку, которая не использует IL2CPP, покопаться в ней обычным dnSpy, посмотреть как устроена и/или пропатчить как душе угодно. В процессе разработки в самом редакторе Unity весь управляемый код, пользовательский и Unity, работает на Mono JIT, никакого IL2CPP.
Во-первых, не "альтернатива", а дефолт.
Альтернативой будет mono и то, требует проверки как оно в релизе.
S>Мало того я тебе приводил ссылки на ссылки на Моно разработчиками Юнити
Да пофик, ведь известно, что Unity использует код Mono (который код тоже в С++ перевёл).
Т.е. простое совместное упоминание Mono и Unity ни о чём не говорит.
S>Моно на начальном этапе был и в Xamarin при этом на айфонах тоже компиляция в нейтив. Все та же технология .Net Native по аналогии с iL2CPP S>При этом на андроиде все тот же Jit.
Да пофик на аналогии.
Чтобы из Mono использовать Unity, весь интерфейс надо организовать через Interop (через COM или DllImport), а чтобы использовать IL2CPP, никакого интеропа не нужно.
Re[38]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>Компиляция в модули — двоякоострая технология. V>Экономя на повторной компиляции файлов (хотя, и с этим сейчас эффективно борются через pch), она требовательна к объёму оперативки, т.е. как в нулевых на линухах с 500MB юзер-спейса не взлетит.
Что за бред?
Компиляция в модули известна полсотни лет. Я лично ей пользовался ещё в начале девяностых, на машинках с 500K b юзер-спейса.
V>Она требует компиллируемости всего и сразу, что не всегда удобно в случае лохматых зависимостей м/у проектами одной разработки, т.к. не позволяет работать независимо над отдельными cpp-файлами, как это принято сейчас — в процессе разработки разработчик периодически вызывает компиляцию только тех cpp-файлов, над которыми в данный момент работает.
Конечно же нет. V>То бишь, в нынешней схеме запросто можно иметь зависимости от некомпилябельных проектов — главное, чтобы интерфейсные h-файлы описывали что требуется, а наполнить "тела" можно и в процессе, что позволяет на плюсах достичь намного лучшего разделения труда, чем в C# и Джаве.
Это речь уже не о модульности, а об особенностях конкретного ЯП.
V>В этих технологиях аналогичное традиционно достигается через натурально перебарщивание с интерфейсами.
Во-первых, откуда "перебарщивание"? Вам так хочется, чтобы модуль А зависел от конкретного типа, определённого в модуле Б?
Похоже, у вас какая-то проблема с архитектурой и дизайном. Нет, я не спорю — такие случаи бывают; но в них обычно идёт речь об основополагающих типах, работа над которыми заканчивается до того, как нам потребуется распараллеливание разработки. То есть это очень странно, что вы не можете просто писать код, работающий с IFoo; вам очень-очень нужно писать код, прибитый к классу Foo, но при этом сам класс Foo всё ещё существует только в виде публичного контракта. V>Т.е. даже если в архитектуре конечного продукта половина из них и нафик не упёрлась, но без них невозможно эффективно распараллеливать разработку. ))
Непонятно, что вам мешает объявить класс абстрактным на первых порах. Как будет готов — уберёте abstract и всё заработает.
Не говоря уже о том, что в C#/Java — прекрасный рефакторинг, и никто вам не запретит избавиться от интерфейса в финальной версии кода. Это займёт пару минут работы. V>Это удобно, но это ловушка, бо интерфейсы многих базовых вещей порой заставляют обильно рассыпать в наследниках "Not implemented.." вовсе не по причине забывчивости.
В чём именно "ловушка"? V>В плюсах в этом сценарии будет ошибка линковки, т.е. будет хорошо видно, что именно еще не реализовано.
Вот именно — проект по-прежнему не работает. Вы же не собираетесь коммитить в общую ветку код, который не прошёл хотя бы базовые тесты? Не говоря уже о том, что он просто не линкуется. V>Платформа настолько тебя уважает, что пакетный менеджер Nuget вышел на боевую готовность спустя ~15 лет после выхода дотнета.
История не важна — важна текущая ситуация и её производная. Они полностью определяют динамику системы на будущее
S>>В которой заранее потрачены усилия на то, чтобы новичок мог быстро начать приносить пользу V>ПХП!
Да, кстати, при всей его убогости, ПХП объехал очень многие "передовые" на первый взгляд платформы. Это повод изучить его опыт и перенять полезную часть.
V>До этого задаче "кроссплатформенность" порой выдавали не просто низкий приоритет, а строго отрицательный, — многие проекты разрабатывались с полным игнором возможности собирать их под виндой. )) V>И вот ты из 2021-го пытаешься взять проект нулевых и удивляешься, а что это у нас с кроссплатформанностью???
Это опять какие-то рассуждения о постороннем.
Кроссплатформенность — штука, известная с шестидесятых. Решения для неё тоже известны с тех же пор; и никак не зависят от доброй воли хейтеров чего бы то ни было.
Просто ситуация, предоставленная сама себе, имеет тенденцию развиваться от плохого к худшему. Подход комитета по стандартизации прямо-таки разжигал разобщённость на ровном месте — начиная от стандарта на name mangling (отсутствие которого является главной причиной отсутствия ABI, и заканчивая зоопарком из CString/QString/std::string. То, что мы наблюдаем — результат старательно выпестованной атмосферы взаимной ненависти.
Глупо делать вид, что это "само так получилось".
В той же Java система JCP обеспечила значительно более низкую разобщённость платформы — несмотря на очевидные провалы в разных областях. Несмотря на то, что бегает Java на ровно тех же платформах "красных", "синих", и "зелёных".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[46]: MS забило на дотнет. Питону - да, сишарпу - нет?
S>>В C# давно именованные параметры, а в котлине еще проще
V>В C# перед каждым идентификатором стоял бы new. V>Синтаксис массивов и лямбд тоже многословней.
Здравствуйте, Sinclair, Вы писали:
S>Что за бред? S>Компиляция в модули известна полсотни лет. Я лично ей пользовался ещё в начале девяностых, на машинках с 500K b юзер-спейса.
Угу, на паскале.
С общим объемом зависимостей в конкретной программе в несколько десятков символов.
Уже после этого стоило бы завязывать с тобой общение. ))
V>>То бишь, в нынешней схеме запросто можно иметь зависимости от некомпилябельных проектов — главное, чтобы интерфейсные h-файлы описывали что требуется, а наполнить "тела" можно и в процессе, что позволяет на плюсах достичь намного лучшего разделения труда, чем в C# и Джаве. S>Это речь уже не о модульности, а об особенностях конкретного ЯП.
Да ни хрена ты как обычно не понимаешь, что именно тебе говорят и зачем именно, поглотитель чужого терпения.
С тобой всегда чувствуешь себя нелепо, бо непонятно как объяснить дикарю полезность микроскопа...
От особенностей ЯП растут растут уникальные для ЯП доступные практики.
Например, крупные проекты на C# меня раздражают именно озвученным — всё должно быть одновременно компилябельным, чтобы я мог хоть как-то работать с привычной для себя скоростью.
В итоге, на этапе бурного кодирования мне приходится разбивать целевой проект на десятки их, потом склеивая обратно, когда нужный функционал более-менее отлажен, т.е. перетекает в стадию использования и поддержки.
Уверен, тебе бы и в голову такого не пришло, т.к. тебе не с чем сравнить.
Но там есть за чем понаблюдать — как именно большинство С# программистов решают задачи.))
Они решают их натурально "пошагово", причём, довольно малюсенькими шажочками: сделают кусочек — проверят, еще небольшой кусочек — опять проверят.
Да и ты так работаешь, скорее всего, по крайней мере именно так рассуждаешь над своим кодом на этом сайте.
Я называю такой подход "методом слепого котёнка".
Это один из самых медленных способов решения задач, бо требует постоянного переключения внимания и постоянного прекращения кодирования с целью проверки каждого чиха.
На плюсах более устоялся чуть другой подход — сначала достаточно "вольное" описание домена/доменов на текущем слое или куче слоёв (смотря, насколько "вглубину" задача), затем решение задач в терминах домена.
В каждый момент времени разработчик сфокусирован на определённом слое из общего решения задачи, что позволяет меньше тыкать мышкой по IDE, а больше клавиатурой в редакторе.
Да и вообще, способствует более глубокому сосредоточению и пониманию собственного кода.
А ты думаешь, как мне удаётся с полутыка находить косяки в ваших решениях — твоих и любых других известных гуру даже из MS?
Потому что находить оные у слепых котят, не имеющих навыков независимого сосредоточения на различных слоях собственного "решения", несложно, в общем-то.
V>>В этих технологиях аналогичное традиционно достигается через натурально перебарщивание с интерфейсами. S>Во-первых, откуда "перебарщивание"? Вам так хочется, чтобы модуль А зависел от конкретного типа, определённого в модуле Б?
Как от кислого лимона у меня реакция на подобные вопросы...
Я, конечно, не упоротый фанат DDD-подхода, но отлично им владею и использую, среди прочих других.
Но фанаты именно DDD прямо сейчас подняли бы тебя на вилы за демонстрируемую нелепость...
(а да, вопрос на засыпку — почему DDD в этой теме? осилишь?)
Твой якобы "вопрос-уточнение" вообще перпендикулярен проблематике.
Хоть бы в вики заглянул, приличия ради, прежде чем рассуждать о зависимостях.
В общем, суть твоего косяка — ты просишь ответа на вопрос, который даже не стоял.
Плюс, само вот построение вопроса, т.е. озвучивание якобы плохо скрываемого за вопросом "хорошо известного подразумеваемого" (С) (от чего и плющит как от лимона) продемонстрировало совсем уж бескайнюю пустыню с одиноко гуляющими в ней шарами перекати-поля обрывков услышанного, увиденного и собственных впечатлений, без увязки в систему...
На этом я точно пока остановлюсь, остальное после.
Жду работу над ошибками — что не так в твоём вопросе?
(там несложно)
Здравствуйте, vdimas, Вы писали:
V>Угу, на паскале. V>С общим объемом зависимостей в конкретной программе в несколько десятков символов. V>Уже после этого стоило бы завязывать с тобой общение. ))
Да я и не настаиваю. Не обязательно писать бред именно мне.
Но вы же, наверное, понимаете, что если машинке хватает памяти вычитать X тысяч символов из .h файлов и держать их "в уме", то ей будет ничуть не сложнее вычитать эти же символы из модулей?
А скорее даже проще, потому как можно держать готовые символы, а не AST в ожидании того, что же у нас там такое окажется в .cpp файле после всех рекурсивных инклюдов.
V>От особенностей ЯП растут растут уникальные для ЯП доступные практики. V>Например, крупные проекты на C# меня раздражают именно озвученным — всё должно быть одновременно компилябельным, чтобы я мог хоть как-то работать с привычной для себя скоростью. V>В итоге, на этапе бурного кодирования мне приходится разбивать целевой проект на десятки их, потом склеивая обратно, когда нужный функционал более-менее отлажен, т.е. перетекает в стадию использования и поддержки.
Вы просто не умеете пользоваться C#. Ничего в этом стыдного нет — нужно просто освоиться, перестать страдать, и начать наслаждаться.
Нет никакой нужды ничего разбивать на проекты — ни на единицы, ни на десятки. И склеивать потом не надо. Я пробовал так делать — лишняя боль и страдания на ровном месте. Модули имеет смысл выделять тогда, когда уже видны их логические границы — ни раньше, ни позже. Если у вас сразу продумана вся архитектура (у меня так бывает редко), то можете сразу напилить нужное количество проектов. Если логические границы становятся понятны только после того, как написано много кода — ну вот тогда и выделяйте. Это всё делается в несколько движений мышкой.
А вот это вот напиливание избыточного количества проектов — зачем оно? Тем более, что С# всё равно не даст вам собрать проект, который ссылается на разобранные проекты. В любом случае вам придётся либо делать метод-заглушку, либо интерфейс, либо абстрактный класс.
Поэтому я так думаю, что вы сейчас рассказываете про воображаемый опыт в воображаемом программировании.
V>Уверен, тебе бы и в голову такого не пришло, т.к. тебе не с чем сравнить.
Что с чем вы предлагаете сравнить?
V>Они решают их натурально "пошагово", причём, довольно малюсенькими шажочками: сделают кусочек — проверят, еще небольшой кусочек — опять проверят.
Вы так говорите, как будто это плохо.
Если я хочу двигаться пошагово — я двигаюсь пошагово.
V>Это один из самых медленных способов решения задач, бо требует постоянного переключения внимания и постоянного прекращения кодирования с целью проверки каждого чиха.
Если я хочу бурно поиграть с кодом — я так и делаю. И мне никак не мешает то, что полпроекта "красные". Как думаете, почему?
V>На плюсах более устоялся чуть другой подход — сначала достаточно "вольное" описание домена/доменов на текущем слое или куче слоёв (смотря, насколько "вглубину" задача), затем решение задач в терминах домена.
Точно также всё работает в C#. Вот ровно также. Я пишу вызов foo.SomeMethod() c сигнатурой, и автопорождаю этот метод.
Потом, когда (и если) дойдёт до реализации, я заменю все эти NotImplemented на реальный код. Что мешает вам делать также?
V>А ты думаешь, как мне удаётся с полутыка находить косяки в ваших решениях — твоих и любых других известных гуру даже из MS?
Пока вам это удаётся только языком. V>Потому что находить оные у слепых котят, не имеющих навыков независимого сосредоточения на различных слоях собственного "решения", несложно, в общем-то.
V>Я, конечно, не упоротый фанат DDD-подхода, но отлично им владею и использую, среди прочих других. V>Но фанаты именно DDD прямо сейчас подняли бы тебя на вилы за демонстрируемую нелепость...
Фанаты DDD идут мимо, хоть строем, хоть в разбивку. У них вилы не отросли меня куда-то поднимать.
V>Твой якобы "вопрос-уточнение" вообще перпендикулярен проблематике.
Нет никакой "проблематики", есть невладение языком и средствами разработки. А недостатки C++, в виде возможности иметь заголовки от несуществующих методов, выдаются за его преимущества.
V>Разберешься — приходи.
В сад.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[48]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
S>>Пока Xaml удобнее, во всяком случае для меня
V>Что означает, что у тебя долгий цикл изучения технологий. V>И отчасти объясняет твоё упортсво.
Ну мне и Xamarin хватает. А про упорство это к тебе. Я хочу докопаться до истины. Но к сожалению, ты не источник.
Все достаточно лаконично https://docs.microsoft.com/ru-ru/xamarin/xamarin-forms/xaml/xaml-basics/xaml-markup-extensions
Я то как раз кучю технологий использую от Windows.Forms до xamarin forms и AXML
Флуттер пока не пришел на Xamarin, поэтому и мало интересен.
Возможно придет в виде декларативного языка или типа Source Generator по Dart коду. Посмотрим.
Жалко, что нельзя в студии совмещать одновременно 2 языка.
Ну и на носу MAUI. Есть чему обучаться! https://visualstudiomagazine.com/articles/2021/07/15/net-maui-updates.aspx
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
V>>Что означает, что у тебя долгий цикл изучения технологий. V>>И отчасти объясняет твоё упортсво. S> Ну мне и Xamarin хватает. А про упорство это к тебе. Я хочу докопаться до истины.
Не нужна тебе никакая истина.
Была бы нужна — сам бы всё проверял, своими ручками.
А так выходит, что ты ищешь подтверждения собственным поступкам.
Тебе почему-то крайне важно знать, что ты "не зря потратил своё время, изучая то-то и то-то".
Подобную "экономию" категорически не приветствую, поэтому, передо-мной тебе отмазываться бесполезно — не прокатит.
S>Я то как раз кучю технологий использую от Windows.Forms до xamarin forms и AXML
Да пофик, сколько технологий.
От тебя, как разработчика, требуется лишь производительность твоего труда.
На XAML высокой производительности не будет by design.
И чем больше одновременных диалектов XAML входу, тем хуже с потенциальной производительностью программистов.
Здравствуйте, Sinclair, Вы писали:
V>>Угу, на паскале. V>>С общим объемом зависимостей в конкретной программе в несколько десятков символов. V>>Уже после этого стоило бы завязывать с тобой общение. )) S>Да я и не настаиваю. Не обязательно писать бред именно мне.
Так остановись, не пиши.
S>Но вы же, наверное, понимаете, что если машинке хватает памяти вычитать X тысяч символов из .h файлов и держать их "в уме", то ей будет ничуть не сложнее вычитать эти же символы из модулей?
Насчёт "эти же символы" — опять было некогда думать? ))
Или хотя бы немного погуглить?
Исторически набор h-файлов обычно шёл уникальный и минимально-необходимый для конкретного С++ файла.
В случае модулей на практике всегда будет максимальный набор символов, а не минимально-необходимый.
Например, вся немаленькая современная стандартная библиотека С++ подключается одним модулем.
Еще пример — в нулевых, да и в десятых, в линухах не очень пользовалась успехом технология предкомпиляции общих заголовков, когда в некий stdafx.h/pch.hpp и т.д. как в мусорное ведро пихают максимум зависимостей, а на виндах это было чуть ли не стандартом.
А дело в том, что у виндов зависимостей обычно кот наплакал: одна на всех WinAPI, сверху тоненький в публичном АПИ MFC, ну и всё, собсно.
А в Линухах обычно шли кучерявые бесконечные зависимости, т.е. это всегда была сборная солянка отовсюду.
Там средний вшивости пакет может вытянуть за собой еще 20-50 пакетов.
А если не вытянул — это потому что их уже притянули ранее.
В общем, у самого много раз компиляция под линухами молча подвисала при нехватке памяти в те года, если злоупотреблял предкомпляцией.
S>А скорее даже проще, потому как можно держать готовые символы, а не AST в ожидании того, что же у нас там такое окажется в .cpp файле после всех рекурсивных инклюдов.
Разумеется, можно считывать модули и в lazy-режиме, т.е. изначально читать просто список символов, а определения конкретных шаблонов, инлайн-функций и макросов — лишь по мере их задействования в компиляции.
Но не об этом ведь шла речь, бо, разумеется, это всё не проблема для современных размеров памяти.
Я делал замечание на твою очередную наивность в духе "надо было так сделать сразу!"
Мол, "в нормальных технологиях так давно".
Это значит, что ты никогда не писал достаточно больших проектов на том же Турбо-Паскале, т.е. не в курсе проблематики.
V>>В итоге, на этапе бурного кодирования мне приходится разбивать целевой проект на десятки их, потом склеивая обратно, когда нужный функционал более-менее отлажен, т.е. перетекает в стадию использования и поддержки. S>Вы просто не умеете пользоваться C#.
У меня другая версия — тебе кажется странной сама задача активного манипулирования описанием билда.
(но таким мнением хвастаться не принято в современном мире)
S>Ничего в этом стыдного нет — нужно просто освоиться, перестать страдать, и начать наслаждаться.
Да ради бога, кто на что учился, как грится.
А то, судя по одному из обсуждений, ты выбрал расслабуху на работе, а реал пошёл по остаточному принципу.
S>Нет никакой нужды ничего разбивать на проекты — ни на единицы, ни на десятки. И склеивать потом не надо. Я пробовал так делать — лишняя боль и страдания на ровном месте.
Эээ, простите, "склеивать"? ))
Т.е. ты в 2021-м не в курсе, что MSBuild уже скоро 20 лет как умеет включать описания проектов друг в друга?
И что удобнее всего описывать проекты небольшими сниппетами, где целевой проект получается как иерархичное их включение, т.е. типа обычная программа на основе библиотек, но на уровне MSBuild.
В Ant аналогично, кстате, ты же из джавы пришёл, неужели не пользовался такой фичей? ))
Но да, в самом конце "быстрой" первоначальной итерации разработки все-равно придётся код описания проектов переписать начисто, увы.
И стараться не править его из GUI Студии, а то там каша получается, а не исходник.
S>Модули имеет смысл выделять тогда, когда уже видны их логические границы — ни раньше, ни позже.
За одно это утверждение тебя уже можно смело увольнять.
(ниже объяснюсь, это уже не первое подобное заявление и не последнее в ряду их)
S>Если у вас сразу продумана вся архитектура (у меня так бывает редко), то можете сразу напилить нужное количество проектов. Если логические границы становятся понятны только после того, как написано много кода — ну вот тогда и выделяйте.
Художник-абстракционист рассуждает о том, как инженеру лучше чертить. ))
"Логические границы"...
Это в таких категориях ПО разрабатываешь?
S>А вот это вот напиливание избыточного количества проектов — зачем оно?
Почему "избыточного"? ))
См. определение этого слова.
Цель каждого отдельного проекта — быть независимой единицей компиляции.
Поэтому, такой проект может и включает обычно одну некую функциональность.
Низкая связанность/высокое зацепление — это общий принцип, в основе DDD лежит в том числе одним из первых.
Заодно такой подход развязывает руки в экспериментировании, т.е. не надо создавать ветки в гите — это банально лишее, удобней все варианты/эксперименты держать перед глазами одновременно.
В общем, отдельные проекты позволяют такие шалости, не ругая за конфликты имен.
И потому что через систему include MSBuild-описаний, т.е. повторного их использования, можно задешево покрыть относительно большую комбинаторику сочетаний вариантов кода для целей проведения экспериментов.
S>Тем более, что С# всё равно не даст вам собрать проект, который ссылается на разобранные проекты.
Судя по изрекаемому тобой, у тебя малость поверхностное представление насчёт того, куда и как может ссылаться проект C#.
Я ведь могу сделать проект лишь частично разобранным за нулевую трудоёмкость.
Опиши себе один мета-проект, ссылающийся на другие проекты, через один коммент включай-отключай запчасти, комбинируй, пробуй варианты и т.д. и т.п.
Для сравнения, "выключить" в исходнике класс — это нужно бегать, выключать все зависимости от него.
Разбил по проектам (которые на деле всегда подпроекты) — получил изоляцию и управляемость.
В общем, я уже понял, что отношение к задаче описания проекта именно как к задаче, являющейся неотъемлимой частью разработки, лично тебя шокирует.
Слушать это забавно, однако, особенно при рассуждении об интерфейсах и о том, что в какие сборки включать.
Ты опять пытаешься рассуждать о предметной области не погружаясь в неё.
В общем, границы проектов в конце стадии "быстрого роста" дизайна зависят от границ предметных областей и слоёв иерархии доменной модели, и ни от чего более.
Т.е., единицы деплоя, конечно, формируются по-вкусу, в меру испорченности, т.к. не запрещается в одну единицу деплоя пихать несколько элементов дизайна, групп их и т.д., но граница всё-равно проходит по границам элементов доменов (или доменов целиком), а значит и по границам слоёв дизайна (т.к. на каждом слое своя доменная модель).
S>Поэтому я так думаю, что вы сейчас рассказываете про воображаемый опыт в воображаемом программировании.
Это, типа, чего ты не видел лично, того не существует?
Как пакетных менеджеров в С++?
V>>Уверен, тебе бы и в голову такого не пришло, т.к. тебе не с чем сравнить. S>Что с чем вы предлагаете сравнить?
Наличие всей описанной возни с её отсутствием, ес-но.
V>>Они решают их натурально "пошагово", причём, довольно малюсенькими шажочками: сделают кусочек — проверят, еще небольшой кусочек — опять проверят. S>Вы так говорите, как будто это плохо.
Это самая низкая производительность программиста из всех возможных.
S>Если я хочу двигаться пошагово — я двигаюсь пошагово.
Акцент был не на пошаговости как таковой, а на размерах итераций.
Когда итерация разработки-проверки колеблется на уровне единиц строк (как во всех твоих "примерах в развитии", что ты давал от своего имени) — это примерно нулевая производительность.
V>>Это один из самых медленных способов решения задач, бо требует постоянного переключения внимания и постоянного прекращения кодирования с целью проверки каждого чиха. S>Если я хочу бурно поиграть с кодом — я так и делаю. И мне никак не мешает то, что полпроекта "красные". Как думаете, почему?
Потому что ты не планируешь довести текущую итерацию до конца?
Т.е. раздать роли и ответственности сущностям дизайна, прописать и обкатать основные сценарии на каждом слое системы?
Даже не любопытно хотя бы просто посмотреть, как это примерно будет выглядеть? ))
V>>На плюсах более устоялся чуть другой подход — сначала достаточно "вольное" описание домена/доменов на текущем слое или куче слоёв (смотря, насколько "вглубину" задача), затем решение задач в терминах домена. S>Точно также всё работает в C#. Вот ровно также.
Но не прижилось на практике.
Достаточно посмотреть на дизай станартных либ и систему "рекомендаций" от MS (половину из которых уже выкинули нафик к сегодняшнему дню, слава богу).
S>Я пишу вызов foo.SomeMethod() c сигнатурой, и автопорождаю этот метод. S>Потом, когда (и если) дойдёт до реализации, я заменю все эти NotImplemented на реальный код. Что мешает вам делать также?
Мне мешает то, что это несъедобно.
Ты как раз описываешь одну из причин, почему Джава и C#-программисты позволяют себе злоупотреблять интерфейсами.
По-сути, в Джава и C# интерфейсы выродились более в инструмент развязки зависимостей, чем в инструмент описания абстрактной модели происходящего.
Т.е. я высмеивал то де-факто положение вещей, где задача развязки зависимостей зачастую не диктуется причинами технического плана, но диктуется причинами организационного, сугубо для целей совместной разработки.
V>>А ты думаешь, как мне удаётся с полутыка находить косяки в ваших решениях — твоих и любых других известных гуру даже из MS? S>Пока вам это удаётся только языком.
Причём, русским.
Причём, обычно после прибегания тобой к чему-то как к якобы доказательству. ))
Одна из последних твоих отсылок к примеру с порождением кучи независимых потоков vs тасков дотнета, и всё это в привычной менторской манере.
А по ссылке тихий бред от какого-то то ли MS MVP, то ли с должности на MS, что я валяюсь с вашего непуганного заповедника...
С умной рожей приводить более молодым коллегам ошибочные примеры, проявлять строгость и непокобелимость!
Это похлеще маразматического КПСС последней стадии.
Исправленную версию примера я там же в обсуждении приводил, но такое ощущение, что ты участвуешь в обсуждениях не для выяснения истины...
Ты даже не извинился перед тем коллегой, кому дал ссылку на бред.
V>>Я, конечно, не упоротый фанат DDD-подхода, но отлично им владею и использую, среди прочих других. V>>Но фанаты именно DDD прямо сейчас подняли бы тебя на вилы за демонстрируемую нелепость... S>Фанаты DDD идут мимо, хоть строем, хоть в разбивку. У них вилы не отросли меня куда-то поднимать.
Фанаты DDD пишут крупнейшие современные проекты.
Я занят не в крупнейших, но в которых, наверно, сильнейшие во всей отрасли технические требования.
А да, твоё "выросло" или "не выросло"...
Ты ведь всё-равно понятия не имеешь, о чём речь.
V>>Твой якобы "вопрос-уточнение" вообще перпендикулярен проблематике. S>Нет никакой "проблематики", есть невладение языком и средствами разработки.
Ну вот за это и уволить, как и за вопрос выше, где я тоже рекомендовал.
Твой очередной косяк тут:
Вам так хочется, чтобы модуль А зависел от конкретного типа, определённого в модуле Б?
Вопрос, заданный именно таким образом (в виде упрёка и заламывания рук одновременно) в публичной переписке своему коллеге, способен в любой конторе породить во внутренних чатах-переписке бесконечнейшие срачи.
Потому что вопрос неполон, и его можно привести как к корректному, так и к глупому.
По-форме в любом случае требует письменного публичного извинения и клятвенного обещания больше так не делать.
В любом случае, в такой форме и с таким содержанием вопрос заведомо провокационный, а посему заведомо бестолковый.
Автору подобных манер обычно пару раз делают замечание, если не доходит — тупо увольняют.
Это нормальная, обычная практика.
И если тебя не уволили до сих пор, это означает, что ты, на самом деле, знаешь как необходимо себя вести.
Получается, именно сюда ты ходишь отвести душу, бо общепринятое тебе противоестественно, давит и утомляет. ))
А здесь можно безнаказанно гадить, можно не стараться думать, можно даже строить из себя домохозяйку со стажем.
S>А недостатки C++, в виде возможности иметь заголовки от несуществующих методов, выдаются за его преимущества.
Что позволяло компиллировать большие программы на маленьких машинах.
В 94-м году довольно большое приложение на Паскале и Turbo Vision достигло у нас c товарищами почти полумегабайта (IDE для разработки на различных ассемблерах) и было неспособно компиллироваться в обычном DOS-режиме.
Портировали на Си (многое автоматом через глобальную замену, а многое и так было на Си — целевые парсеры/лексеры ассемблеров) — и всё прекрасно компиллировалось еще долго.
Хотя и дольше по времени. ))
V>>Разберешься — приходи. S>В сад.
Приходи из сада. ))
Синклер, у вас опять обнаруживаются вопиющие провалы, не соответствующие объему надувания боковых поверхностей лица...
Слушай, а вообще есть в IT хотя бы одна область, в которой ты более-менее разбираешься?
Просто любопытно...
ОК, понятно, что не учился на программера, осваивал самостоятельно.
Но за 25+ лет...
Неужели за этот срок вообще ни одной областью IT ты так и не овладел?
(не, я помню твои круглые глаза когда ты узнал о кеше браузеров и кодах ответов веб-серваков, но это было не на уровне "овладел", это было наполнение эрудиции, там инфы примерно на три первых дня работы современного фронтендера)
Здравствуйте, vdimas, Вы писали:
V>Исторически набор h-файлов обычно шёл уникальный и минимально-необходимый для конкретного С++ файла. V>В случае модулей на практике всегда будет максимальный набор символов, а не минимально-необходимый.
Опять-таки, вы всё трактуете задом наперёд. Практика в случае модулей такая не потому, что единственно возможная, а потому, что так удобнее.
Были бы проблемы с расходом памяти — резали бы модули по более мелким границам, 1 .h файл = 1 модуль. V>Например, вся немаленькая современная стандартная библиотека С++ подключается одним модулем.
Всё зависит от того, как именно модули реализовывать.
V>В общем, у самого много раз компиляция под линухами молча подвисала при нехватке памяти в те года, если злоупотреблял предкомпляцией.
Предкомпиляция в С++ вообще штука крайне сложная. У самого она адски глючила и падала под виндой — и вовсе не из-за нехватки памяти.
Сожрать модулями слишком много памяти — это какой-то феерический факап реализации системы модулей. V>Разумеется, можно считывать модули и в lazy-режиме, т.е. изначально читать просто список символов, а определения конкретных шаблонов, инлайн-функций и макросов — лишь по мере их задействования в компиляции. V>Но не об этом ведь шла речь, бо, разумеется, это всё не проблема для современных размеров памяти.
Ну, вот видите. А только что это была неразрешимая проблема.
V>Мол, "в нормальных технологиях так давно". V>Это значит, что ты никогда не писал достаточно больших проектов на том же Турбо-Паскале, т.е. не в курсе проблематики. Этой проблематики не существует. Повторюсь: Турбо-Паскаль прекрасно работал на объёмах памяти, в тысячу раз меньше тех, которые вы считаете маленькими.
V>>>В итоге, на этапе бурного кодирования мне приходится разбивать целевой проект на десятки их, потом склеивая обратно, когда нужный функционал более-менее отлажен, т.е. перетекает в стадию использования и поддержки. S>>Вы просто не умеете пользоваться C#. V>Эээ, простите, "склеивать"? ))
У вас потеря кратковременной памяти? Это же ваша цитата про "склеивать" — поднимите глазки на две строчки выше. V>Но да, в самом конце "быстрой" первоначальной итерации разработки все-равно придётся код описания проектов переписать начисто, увы.
Повторю вопрос: зачем вы это делаете? Вы утверждаете, что вам приходится пилить проект на десятки разных, а потом склеивать.
Я вам говорю, что такой нужды нет. V>И стараться не править его из GUI Студии, а то там каша получается, а не исходник.
Да можно как угодно — хоть студией, хоть руками. Речь о том, что C# вас ни к чему не принуждает.
V>За одно это утверждение тебя уже можно смело увольнять.
Как хорошо, что такие решения принимаете не вы.
V>Это в таких категориях ПО разрабатываешь?
А то.
S>>А вот это вот напиливание избыточного количества проектов — зачем оно?
V>Почему "избыточного"? ))
Ну, потому что потом вы вынуждены обратно их склеивать.
V>Цель каждого отдельного проекта — быть независимой единицей компиляции. V>Поэтому, такой проект может и включает обычно одну некую функциональность. V>Низкая связанность/высокое зацепление — это общий принцип, в основе DDD лежит в том числе одним из первых.
Отлично. В чём тогда ваша проблема?
V>Заодно такой подход развязывает руки в экспериментировании, т.е. не надо создавать ветки в гите — это банально лишее, удобней все варианты/эксперименты держать перед глазами одновременно. V>В общем, отдельные проекты позволяют такие шалости, не ругая за конфликты имен.
V>И потому что через систему include MSBuild-описаний, т.е. повторного их использования, можно задешево покрыть относительно большую комбинаторику сочетаний вариантов кода для целей проведения экспериментов.
Можно и без такой системы.
V>Я ведь могу сделать проект лишь частично разобранным за нулевую трудоёмкость.
V>Опиши себе один мета-проект, ссылающийся на другие проекты, через один коммент включай-отключай запчасти, комбинируй, пробуй варианты и т.д. и т.п. V>Для сравнения, "выключить" в исходнике класс — это нужно бегать, выключать все зависимости от него. V>Разбил по проектам (которые на деле всегда подпроекты) — получил изоляцию и управляемость.
Отлично. Пока что всё, что вы рассказываете, вполне укладывается в нормальную практику. Откуда тогда страдания про то, что C# вас вынуждает делить проект на мелкие части? V>В общем, границы проектов в конце стадии "быстрого роста" дизайна зависят от границ предметных областей и слоёв иерархии доменной модели, и ни от чего более.
Ну и отлично. Зачем тогда их потом "склеивать"?
V>>>Уверен, тебе бы и в голову такого не пришло, т.к. тебе не с чем сравнить. S>>Что с чем вы предлагаете сравнить?
V>Наличие всей описанной возни с её отсутствием, ес-но.
Продолжаю не понимать. Вы только что превозносили эту возню как что-то прекрасное, и обвиняли меня в том, что мне оно недоступно. И тут вдруг опять — надо сравнивать описанную возню с её отсутствием. Так вот эти ваши десятки проектов — это хорошо или плохо?
В общем, вы очень путано объясняете. Ложка огурцы банка майонез 500мб DDD склеивать резать предкомпиляция включение.
V>Это самая низкая производительность программиста из всех возможных.
Производительность измеряется результатами, а не строчками.
V>Когда итерация разработки-проверки колеблется на уровне единиц строк (как во всех твоих "примерах в развитии", что ты давал от своего имени) — это примерно нулевая производительность. V>Потому что ты не планируешь довести текущую итерацию до конца?
Неверно. V>Т.е. раздать роли и ответственности сущностям дизайна, прописать и обкатать основные сценарии на каждом слое системы? V>Даже не любопытно хотя бы просто посмотреть, как это примерно будет выглядеть? ))
Если я хочу прописать и обкатать основные сценарии, то у меня проект собирается, проходит тесты и бенчмарки.
А у вас что?
V>>>На плюсах более устоялся чуть другой подход — сначала достаточно "вольное" описание домена/доменов на текущем слое или куче слоёв (смотря, насколько "вглубину" задача), затем решение задач в терминах домена. S>>Точно также всё работает в C#. Вот ровно также.
V>Достаточно посмотреть на дизай станартных либ и систему "рекомендаций" от MS (половину из которых уже выкинули нафик к сегодняшнему дню, слава богу).
Недостаточно. V>Мне мешает то, что это несъедобно.
Что именно "несъедобно"? V>Ты как раз описываешь одну из причин, почему Джава и C#-программисты позволяют себе злоупотреблять интерфейсами.
Давайте в студию пример злоупотребления интерфейсами. V>По-сути, в Джава и C# интерфейсы выродились более в инструмент развязки зависимостей, чем в инструмент описания абстрактной модели происходящего. V>Т.е. я высмеивал то де-факто положение вещей, где задача развязки зависимостей зачастую не диктуется причинами технического плана, но диктуется причинами организационного, сугубо для целей совместной разработки.
По-моему, это у вас какие-то фобии. Если у вас модуль А таки зависит от конкретного типа в модуле Б, то есть как минимум два способа временно разрешить эту зависимость, не дописывая до конца реализацию модуля Б, и не переходя к интерфейсу.
Оба стоят чуть меньше, чем ничего, в терминах дополнительных затрат.
V>Причём, русским. V>Причём, обычно после прибегания тобой к чему-то как к якобы доказательству. ))
Да ну. Вы постоянно приводите какие-то смехотворные затруднения в качестве неразрешимых проблем; зато то, что реально требует больших затрат вам кажется чем-то несущественным.
V>Одна из последних твоих отсылок к примеру с порождением кучи независимых потоков vs тасков дотнета, и всё это в привычной менторской манере. V>А по ссылке тихий бред от какого-то то ли MS MVP, то ли с должности на MS, что я валяюсь с вашего непуганного заповедника... V>Исправленную версию примера я там же в обсуждении приводил, но такое ощущение, что ты участвуешь в обсуждениях не для выяснения истины...
Это тот тред, где вы обещали привести легендарную версию локов, которая на треть быстрее стоковых? Или какой-то другой. Ссылка была бы уместна.
V>Фанаты DDD пишут крупнейшие современные проекты. V>Я занят не в крупнейших, но в которых, наверно, сильнейшие во всей отрасли технические требования.
А то. Как же без вас-то.
V>Ну вот за это и уволить, как и за вопрос выше, где я тоже рекомендовал. V>Твой очередной косяк тут: V>
V>Вам так хочется, чтобы модуль А зависел от конкретного типа, определённого в модуле Б?
V>По-форме в любом случае требует письменного публичного извинения и клятвенного обещания больше так не делать. V>В любом случае, в такой форме и с таким содержанием вопрос заведомо провокационный, а посему заведомо бестолковый.
Вот прямо любо-дорого посмотреть, как вы начинаете вилять ужом по сковородке, чтобы не отвечать на вопрос. V>Автору подобных манер обычно пару раз делают замечание, если не доходит — тупо увольняют. V>Это нормальная, обычная практика. V>И если тебя не уволили до сих пор, это означает, что ты, на самом деле, знаешь как необходимо себя вести.
В жизни я значительно более резкий V>Получается, именно сюда ты ходишь отвести душу, бо общепринятое тебе противоестественно, давит и утомляет. )) V>А здесь можно безнаказанно гадить, можно не стараться думать, можно даже строить из себя домохозяйку со стажем.
Здесь я пишу преувеличенно вежливо и аккуратно.
V>Что позволяло компиллировать большие программы на маленьких машинах. V>В 94-м году довольно большое приложение на Паскале и Turbo Vision достигло у нас c товарищами почти полумегабайта (IDE для разработки на различных ассемблерах) и было неспособно компиллироваться в обычном DOS-режиме.
V>Портировали на Си (многое автоматом через глобальную замену, а многое и так было на Си — целевые парсеры/лексеры ассемблеров) — и всё прекрасно компиллировалось еще долго.
Отож. Каким компилятором компилировали?
V>Синклер, у вас опять обнаруживаются вопиющие провалы, не соответствующие объему надувания боковых поверхностей лица...
Да я вообще не программист. Это вы тут светоч знаний и опора системной архитектуры.
V>(не, я помню твои круглые глаза когда ты узнал о кеше браузеров и кодах ответов веб-серваков, но это было не на уровне "овладел", это было наполнение эрудиции, там инфы примерно на три первых дня работы современного фронтендера)
Как интересно. Напомните мне мои круглые глаза? А то я сам уже не помню, когда узнал о кэше браузера и кодах ответов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[50]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>На XAML высокой производительности не будет by design. V>И чем больше одновременных диалектов XAML входу, тем хуже с потенциальной производительностью программистов.
И почему же? Вон и горячую перезагрузку прикрутили. Тот же XAML в реалии то в код и переводится.
Только вот он значительно декларативнее кода и главное значительно читабельнее.
Еще раз можно и в WPF и Xamarin.Forms писать все в коде. Я и сам пишу иногда. Но Xaml реально удобнее.
Плюс редактор. Ты же как С++ все в текстовом редакторе норовишь!
и солнце б утром не вставало, когда бы не было меня
Re[43]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Исторически набор h-файлов обычно шёл уникальный и минимально-необходимый для конкретного С++ файла. V>>В случае модулей на практике всегда будет максимальный набор символов, а не минимально-необходимый. S>Опять-таки, вы всё трактуете задом наперёд. Практика в случае модулей такая не потому, что единственно возможная, а потому, что так удобнее.
"Трактуешь" и вообще выкручиваешься тут ты, я говорю как оно есть и как непременно будет.
Т.е. объясняю одному недостаточно зрелому коллеге, почему он здесь ошибается:
то ей будет ничуть не сложнее вычитать эти же символы из модулей
V>>Например, вся немаленькая современная стандартная библиотека С++ подключается одним модулем. S>Всё зависит от того, как именно модули реализовывать.
Если уж ты решил именно спорить (хотя я ХЗ зачем было именно спорить, а не спрашивать подробности), то надо уметь не косячить в рассуждениях, особенно в очевидном.
А вот это бесполезное бла-бла-бла...
Зачем оно?
V>>В общем, у самого много раз компиляция под линухами молча подвисала при нехватке памяти в те года, если злоупотреблял предкомпляцией. S>Предкомпиляция в С++ вообще штука крайне сложная. У самого она адски глючила и падала под виндой — и вовсе не из-за нехватки памяти.
А из-за сваливания в кучу всего и вся.
И из-за глючной одно время технологии инкрементной компиляции, но это поправили ближе к концу 90-х.
S>Сожрать модулями слишком много памяти — это какой-то феерический факап реализации системы модулей.
Дык, готовое бинарное описание ничего не экономит в сравнении с исходным текстовым после зачитки тех и тех, там в лучшем случае требуется та же память, в худшем чуть большая — ввиду дополнительного мета-описания символов с т.з. расположения тех в модулях.
V>>Разумеется, можно считывать модули и в lazy-режиме, т.е. изначально читать просто список символов, а определения конкретных шаблонов, инлайн-функций и макросов — лишь по мере их задействования в компиляции. V>>Но не об этом ведь шла речь, бо, разумеется, это всё не проблема для современных размеров памяти. S>Ну, вот видите. А только что это была неразрешимая проблема.
Неразрешимой проблему никто не называл (очередной тебе минус за враньё), я пояснял, почему технология не обязательно вызовет экономию ресурсов и ускорение процессов.
Чаще будет ровно наоборот, бо зачитка текстового кода происходит не сильно медленней и текстовый код может быть порой компактней бинарного описания, а скорость компиляции сейчас часто зависит от скорости чтения с диска, т.е. от размеров исходников.
Удобство модулей — это уменьшение вероятности потенциальных конфликтов имён промежуточных сущностей, фигурирующих сейчас в открытом виде в h-файлах.
Т.е. сами те сущности из модулей никуда не денутся, ес-но, но теперь их имена не будут вызывать конфликтов.
Но основное ожидаемое удобство — легкость разворачивания, поддержка версионности.
Зависимости м/у модулями можно описывать в явном виде, это перекликается с задачами пакетных менеджеров, поэтому в подветке про пакетные менеджеры я их и упомянул.
V>>Мол, "в нормальных технологиях так давно". V>>Это значит, что ты никогда не писал достаточно больших проектов на том же Турбо-Паскале, т.е. не в курсе проблематики. S> Этой проблематики не существует. Повторюсь: Турбо-Паскаль прекрасно работал на объёмах памяти, в тысячу раз меньше тех, которые вы считаете маленькими.
Я же говорю — ты не писал больших проектов на Турбо Паскале.
V>>Эээ, простите, "склеивать"? )) S>У вас потеря кратковременной памяти? Это же ваша цитата про "склеивать" — поднимите глазки на две строчки выше.
Пфф, я и повторялся в сообщении, на которое отвечаешь, насчёт переписывания описания проекта с 0-ля по окончании работ, но ты высказывался про сам процесс, как мне показалось.
Иначе бы откуда было про "боль", когда речь об однократных операциях, выполняемых раз в несколько недель или даже единиц месяцев?
Использование тех же слов не обязательно означает тот же смысл.
V>>Но да, в самом конце "быстрой" первоначальной итерации разработки все-равно придётся код описания проектов переписать начисто, увы. S>Повторю вопрос: зачем вы это делаете?
Потому что будучи окончательно сгруппированным по конечным единицам деплоймента, описание проекта в виде единого файла будет минимальным по объёму, ведь в "чистовом" варианте даже исходники перечислять не требуется, по-умолчанию подхватывается вся директория от текущей и рекурсивно ниже.
(При этом такой "исходник" описания наименее управляем, но им на этой стадии уже особо управлять и не требуется)
S>Вы утверждаете, что вам приходится пилить проект на десятки разных, а потом склеивать. S>Я вам говорю, что такой нужды нет.
Уметь говорить мало, надо уметь говорить аргументированно.
И хотя бы понимать, о чём вообще речь.
V>>И стараться не править его из GUI Студии, а то там каша получается, а не исходник. S>Да можно как угодно — хоть студией, хоть руками. Речь о том, что C# вас ни к чему не принуждает.
Принуждает своей моделью сборки (походу ты зациклился в рассуждениях).
Ладно, ничего внятного от тебя по этой теме мы уже не услышим, бо это заход на 3-й круг, а ты пока всё еще пытаешься сообразить, зачем это вообще может быть нужно.
Почему бы тебе в аналогичных случаях не писать своё "мнение" прямой речью: "раз мне это не надо, то и никому не надо" — оно бы сэкономило бы кучу времени тебе и оппонентам.
V>>За одно это утверждение тебя уже можно смело увольнять. S>Как хорошо, что такие решения принимаете не вы.
Да пофик кто принимает решения, хосподя, речь всё-равно не обо мне.
За злоупотребление такими вещами, которые ты себе позволяешь, увольняют откуда угодно.
V>>Это в таких категориях ПО разрабатываешь? S>А то.
То, что ревью делать некому, походу. ))
Т.е. из твоего положения тебе вообще выступать не следовало бы, бо ты в некотором смысле в вакууме работаешь, судя по высказываемому тобой, общаясь с коллегами через публичное АПИ их и своих поделий.
V>>Почему "избыточного"? )) S>Ну, потому что потом вы вынуждены обратно их склеивать.
(утомляешь уже упоротостью...)
См. определение "избыточность" в IT.
Способ группировки информации обычно не влияет на степень её избыточности.
V>>Низкая связанность/высокое зацепление — это общий принцип, в основе DDD лежит в том числе одним из первых. S>Отлично. В чём тогда ваша проблема?
Такие вещи обычно называются не "проблемами", а "задачами".
Проблемой задача становится, когда плохо понятно как её решать или её решение слишком дорогое.
Забавный у нас вышел обмен мнениями — я тебе рассказываю как решать те задачи, которые ты не в состоянии даже просто сформулировать. ))
Че-та ржу уже...
Хотя... если основная сегодняшняя методология разработки сложных систем идёт со слов оппонента лесом, то удивляться нечему.
V>>И потому что через систему include MSBuild-описаний, т.е. повторного их использования, можно задешево покрыть относительно большую комбинаторику сочетаний вариантов кода для целей проведения экспериментов. S>Можно и без такой системы.
Я озвучил как можно без дублирования, с дешевым управлением на уровне исходников описания проектов.
В технологии MSBuild дешевле никак.
Альтернативой идёт дублирование уникальных описаний проектов и всё это в плохо управляемом на уровне исходников виде.
На всякий случай ликбез — "плохо управляемыми" называются те исходники, в которые для внесения небольшого "логического" изменения необходимо вносить "физические" изменения (т.е. править исходники) во многих местах.
V>>Опиши себе один мета-проект, ссылающийся на другие проекты, через один коммент включай-отключай запчасти, комбинируй, пробуй варианты и т.д. и т.п. V>>Для сравнения, "выключить" в исходнике класс — это нужно бегать, выключать все зависимости от него. V>>Разбил по проектам (которые на деле всегда подпроекты) — получил изоляцию и управляемость. S>Отлично. Пока что всё, что вы рассказываете, вполне укладывается в нормальную практику.
Но я такую практику редко вижу на гитхаб.
И для меня это один из многих признаков/показателей класса разработчиков.
Ну да, в C# не только нубы обитают, бывают и вполне грамотные ребята, а что?
Например, посмотри на Авалонию.
И посмотри на исходники своих MSBuild-описаний.
S>Откуда тогда страдания про то, что C# вас вынуждает делить проект на мелкие части?
Декомпозиция — это вроде как стандартный способ борьбы со сложностью. ))
У меня сотни библиотечных типов одновременно было в разработке/портировании с С++, без оперативного оперирования зависимостями там можно было бы застрять надолго, т.е. выполнять работы "пошагово" можно было бы бесконечно.
Кароч, чё-та я уже зеваю от твоих рассуждений.
Когда-то давно, 15-20 лет назад я имел обыкновения коллегам озвучивать, что профессионализм проявляется, в первую очередь, в умении "организовать своё рабочее место", с т.з. программера — это организовать себе ориентированную на решение конкретной задачи наиболее подходящую инфраструктуру.
Коллеги с тех пор заметно подросли, в подобных советах не нуждаются.
Но по-интернету уникальные кадры еще пробегают и даже преднамеренно привлекают к своей необычности внимание! ))
V>>В общем, границы проектов в конце стадии "быстрого роста" дизайна зависят от границ предметных областей и слоёв иерархии доменной модели, и ни от чего более. S>Ну и отлично. Зачем тогда их потом "склеивать"?
Чтобы убрать явную декомпозицию времени разработки.
V>>Наличие всей описанной возни с её отсутствием, ес-но. S>Продолжаю не понимать. Вы только что превозносили эту возню как что-то прекрасное, и обвиняли меня в том, что мне оно недоступно.
Да там вышло два непонимания с твоей стороны — это непонимание самой задачи и доступных способов её решения для C# с использованием трюков MSBuild.
А это уже третье непонимание того, что непониманий в прошлый раз у тебя было два. ))
S>И тут вдруг опять — надо сравнивать описанную возню с её отсутствием. Так вот эти ваши десятки проектов — это хорошо или плохо?
Да я уже понял, что ты совсем запутался.
Медленно еще раз:
— в плюсах у меня единицы компиляции независимы (т.е. независим каждый cpp-файл);
— поэтому я могу работать над конкретным cpp-файлом независимо от компилябельности других cpp-файлов, т.е. хотя бы проверять на компиллябельность;
— если мне компиляции недостаточно, я могу линковаться в произвольных сочетаниях с отдельными obj-файлами, которые получаются из отдельных cpp-файлов.
— или могу сложить те obj-файлы, которые считаются рабочими, в одну либу одной командой и добавлять очередные obj-файлы в эту либу по мере готовности и т.д. и т.п.
То бишь, в плюсах изкаробки доступна произвольная декомпозиция зависимостей до одного файла.
Вплоть до того, что можно все методы одного объекта раскидать по разным файлам.
Или создать в разных cpp-файлах разные варианты реализации одного и того же метода, и выбирать нужный вариант на этапе линковки.
(просто сделай паузу и помедитируй в этом месте, бо мне уже надоело ждать, когда ты включишь соображалку)
S>В общем, вы очень путано объясняете. Ложка огурцы банка майонез 500мб DDD склеивать резать предкомпиляция включение.
Наверное, это побочный эффект вашего регулярного надувания.
Мне всё-время кажется, что вы обладаете достаточной эрудицией, что мне нет надобности с 0-ля всё разжёвывать.
Но дело не в этом, ХЗ.
Я совершенно уверен в том, что ты хорошо в курсе про описанные в пред. абзаце подробности относительно декомпозиции единиц трансляции в С++.
Ты всё это знал, но тебе это не помогло.
А вот это уже необъяснимо.
Т.е., я хорошо понимаю что происходит, я не понимаю — почему.
Когда-то, когда ты познавал новое, проявлял любопытство, лично мне было интересно тебя читать.
Свежий, нестандартный взгляд от непрофессионала IT на всю эту скукатень, которой мы занимаемся...
Ты познавал новое и делился впечатлениями в интересной манере.
Умение заинтересовать — это уважаемый мною талант.
Несомненно, это приносило пользу более молодым коллегам — пополняло эрудицию в виде нескучного чтива.
Но стоит тебе отказаться от познания нового, экспериментаторства и т.д. и начать пропихивать куда надо и куда не надо свой старый опыт — туши свет, кидай гранату. ))
Недалёк в рассуждениях, несносен в манерах.
Здравствуйте, Serginio1, Вы писали:
S>Ты же как С++ все в текстовом редакторе норовишь!
В C++, как раз, за счёт возможностей переопределения всего и вся, доступно делать описания в самом декларативном виде.
Только полёт фантазии ограничивает удобство описания. ))
V>XAML в плане удобства ни разу не чемпион. V>И вообще, набика поприятней, чем в XAML, смотри примерно с 5-й минуты:
Ну это уже вкусовщина. Суть XAML прежде всего это декларативность и разделения труда дизайнеров и программистов.
Для меня мука, что то рисовать. Пусть рисуют дизайнеры или подправляют, что я накидал
и солнце б утром не вставало, когда бы не было меня
Re[43]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Одна из последних твоих отсылок к примеру с порождением кучи независимых потоков vs тасков дотнета, и всё это в привычной менторской манере. V>>А по ссылке тихий бред от какого-то то ли MS MVP, то ли с должности на MS, что я валяюсь с вашего непуганного заповедника... V>>Исправленную версию примера я там же в обсуждении приводил, но такое ощущение, что ты участвуешь в обсуждениях не для выяснения истины... S>Это тот тред, где вы обещали привести легендарную версию локов, которая на треть быстрее стоковых? Или какой-то другой. Ссылка была бы уместна.
Только не лока, а семафора.
Да, критиковал реализацию асихронного имеющегося семафора и утверждал, что если требуется только асинхронная часть его функциональности, то можно сделать намного легковеснее (слишком очевидно).
И если это было в этом же обсуждении, то там лишь одна твоя отсылка к примеру создания потоков vs тасков и тебе найти эту ссылку не сложнее, чем мне.
Вернее, ссылка от НС, ты дал ссылку на пост НС в кач-ве "доказательства", кароч, вы оба облажались.
И всё бы ничего, повторюсь, если бы не менторская позиция... Ну мало ли кто где ошибся?
Под ссылкой НС я привёл свою версию без лажи исходного лажового примера от того MS MVP (или кто он там в этом обезъяннике?), а так же на порядок отличающиеся результаты измерений.
Т.е., не согласен — претензии мне можно запросто оформить в виде претензии к моему показанному коду.
Свои претензии к исходному варианту я там же доступно раскрыл.
Но, судя по отсутствию реакции, ты и НС были согласны. ))
V>>Фанаты DDD пишут крупнейшие современные проекты. V>>Я занят не в крупнейших, но в которых, наверно, сильнейшие во всей отрасли технические требования. S>А то. Как же без вас-то.
Без нейтива в этом мире никуда, ес-но.
Но почему у тебя от этого НАСТОЛЬКО пригорает?
Меня же не типает от дотнета или питона, нормальные технологии в своих нишах...
Вы с НС очень странные ребята в этом смысле.
Наверно, единственные остались "непримиримые борцуны" на этом сайте, остальные давно забили на этот нелепый спор.
Даже взять Ikemefula — его на самом деле больше интересуют преимущества и недостатки используемых им технологий, чем чьих-то других.
А вот вам постоянно хочется сунуть нос именно к соседям и найти хоть что-нибудь, до чего можно докопаться.
НС вон порвало от простого факта, что сегодня рефакторинг в плюсах практически не уступает рефакторингу в C# и Джава.
Казалось бы — ну вот какая ему хрен разница, откуда столь живая "реакция"-то?
Я за любую соседнюю технологию только порадуюсь, буде там чего нового-продвинутого, а от вас сплошная какая-то попоболь.
Как ни крути, это НЕ нормально, что бы ты там ни придумывал в тысячный раз в кач-ве "объяснений"...
Здравствуйте, Sinclair, Вы писали:
S>На этом дискуссию можно заканчивать — то, что я хотел узнать, я узнал.
Не собираюсь влезать в вашу увлекательную беседу, но просто не могу не отметить ужасный уровень знаний по обсуждаемому вопросу (что кстати забавно коррелирует с твоей цитатой выше). Причём для данного вывода мне не потребовалось читать весь это огромный и страшный поток мыслей, а было достаточно поиска по ключевым словам и твоим кривым выводам (а какие они ещё могут быть на основание неверных данных?).
И так, показываю истинное состояние индустрии.
Запрашиваемый тобой (правда подозреваю исключительно с целью гордо сказать "ага, нет такого!") инструмент для C++ прекрасно себе существует. Более того, он на порядок превосходит по своим возможностям все эти maven'ы, nuget'ы и прочие. И да, он делает прямо в точности то, что ты хотел. Т.е. скачиваешь проект с гитхаба, запускаешь сборку и он автоматически подтянет с гитхаба (и не только естественно, а откуда угодно, как настроено в проекте) все зависимости нужных версий. Да, и помимо этого могут быть ещё подтянуты нужные тулчейны (опять же нужных версий), и естественно это всё вне зависимости от используемой для сборки ОС (кстати их может быть и много, т.к. сборка может быть распределённой между множества узлов).
Данный инструмент называется bazel. Он совсем не новый (лично я писал о его применение прямо на этом форуме ещё пару лет назад) и совсем не маргинальный (его разработку ведёт Google и использует для всех своих внутренних процессов). Так что нельзя свалить не знание этого на какую-то необычность инструмента. Особенно для того, кто с таким знающим видом делает такие громкие заявления по данному вопросу.
P.S. Небольшая заметочка для местных троллей, давно считающих меня яростным адептом C++. Не стоит путать хорошее знание вопроса и неадекватную фанатскую "любовь" к инструментам (как у многих моих старых оппонентов тут). Если что, моя компания уже год как занята миграцией всех продуктов с C++ на Rust. Только вот данное решение было принято совсем не в связи с лучшими инструментами разработки (cargo намного слабее bazel) и даже не в связи с мифом о вроде как большей безопасности Rust'а (на самом деле для профессионала в C++ программирование на Rust вообще ничем не отличается — просто все правила хорошего тона C++ там прошиты в компилятор и всё), а в связи с другим, совершенно неожиданным вопросом, даже никогда не всплывавшем с подобных обсуждениях на этом (да и на многих других) форуме.
Вот за что мне нравится с тобой общаться! Подымаешь настроение.
