Здравствуйте, e.thrash, Вы писали:
ET>Что-то всё меньше новых проектов пишут на шарпе. ET>Тенденция или я не туда смотрю?
Вот интересно куда ты смотришь? ET>Кто занял долю проектов которые были на asp.net (mvc, core etc)?
Да как раз .Net Core активно развивается ибо есть потребность в облаках под линуксом.
И MS гребет деньги на облаках https://www.cnews.ru/news/top/2022-01-26_microsoft_na_konevse_segmenty
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, e.thrash, Вы писали:
ET>Что-то всё меньше новых проектов пишут на шарпе.
А на чем пишут новые проекты сейчас? И о каких проектах вы говорите?
Мне сложно об этом судить — я работал только в компаниях, где превалирующим был .Net.
Мои наблюдения (т.е. очень субъективная оценка) таковы:
— в компаниях, о которых я знаю, где был свой продукт (правда, сразу замечу — я знаю про исключительно Web-решения) на .Net ничего особо не менялось. Да, появились, я уже в паре мест видел, что некоторая часть делается на чем-то ином (например, в продукт добавляется некая аналитика, AI, ... — и эти ребята используют Python), но это именно часть и не самая критическая. В остальных местах никто даже не думает о замене .Net на что-то иное. Основные вопросы — нужно ли переезжать на новую версию и когда это делать (чаще просто второе).
— огромное количество вакансий для .Net backend. Несмотря на то, что у меня везде, где есть профиль/резюме, указано, что я не ищу работу, хотя бы раз в неделю или 2, прилетают вакансии. Очень много аутсорсинга, но далеко не он один.
— десктопные проекты да, на .Net если и появляются, то скорее в следовых количествах. С другой стороны, их и в принципе появляется всё меньше...
— Xamarin кажется, что так и не набрал сколько-нибудь заметную популярность. Хотя и у других универсальных мобильных фреймворков (типа React Native), как я понимаю, успехи не сильно лучше. Но я не специалист по мобильной разработке — могу банально заблуждается.
ET>Кто занял долю проектов которые были на asp.net (mvc, core etc)?
Исходя из вышенаписанного — особо никто.
ET>Что-то всё меньше новых проектов пишут на шарпе. ET>Тенденция или я не туда смотрю?
Открыл пулл-реквесты в гитхабе, для языка у которого зрелая стандартная библиотека — у C# всё очень хорошо. А вот javascript походу хромая лошадка.
По сути в мире есть два языка, а скорей даже экосистемы, которые жёстко конкурируют между собой и это Java/JVM и C#/.NET. Как мне кажется, Java постепенно выиграет, поэтому когда-нибудь C# уйдёт. Но это такое, вилами по воде.
Здравствуйте, Sharov, Вы писали:
vsb>>Как мне кажется, Java постепенно выиграет, поэтому когда-нибудь C# уйдёт. Но это такое, вилами по воде.
S>Java уже лет 20 постепенно выигрывает.
В том-то и дело. И если раньше у C# было естественное преимущество в виде десктопных приложений, то сейчас эта ниша исчезла. C# пытается влезть на рынок серверных линуксовых приложений, но его там особо никто не ждёт.
Здравствуйте, Klikujiskaaan, Вы писали:
K>Здравствуйте, vsb, Вы писали:
vsb>>C# пытается влезть на рынок серверных линуксовых приложений, но его там особо никто не ждёт.
K>Судя по кол-ву вакансий это, мягко говоря, не так.
5285 вакансий «Java»
2459 вакансий «C#»
(c) hh.ru
Что получается на уровне "умирающего" C++ c 2323 вакансии. Таки что-то в предположении vsb есть
Какая участь? Непонятно. https://delphi.embarcadero.com/
Участь быть продуктом который изменит мир разработки навсегда как дельфи?
Ну тут заслуга не только языка, но прежде всего IDE.
Так что еще вопрос: что все таки сравниваем? Языки, технологии, инструменты?
Чтобы предсказать нужно моделировать развитие.
Если учесть, что C# и дельфи разрабатывал Anders Hejlsberg возможно.
Если случится чудо и возникнут квантовые ПК возможно.
Это работа для теории динамической информации.
Здравствуйте, vsb, Вы писали:
vsb>По сути в мире есть два языка, а скорей даже экосистемы, которые жёстко конкурируют между собой и это Java/JVM и C#/.NET. Как мне кажется, Java постепенно выиграет, поэтому когда-нибудь C# уйдёт. Но это такое, вилами по воде.
C# канет в Лету при выполнении хотя бы одного из двух условий:
1. фатальные недостатки в самом .NET,
2. наличие конкурентов, которые на порядок лучше.
Но ни того, ни другого пока не заметно. Так что, будем жить, пехота.
Здравствуйте, Буравчик, Вы писали:
vsb>>C# пытается влезть на рынок серверных линуксовых приложений, но его там особо никто не ждёт.
Б>Немного не в тему: Б>.net core исходники открыты? Где посмотреть?
Здравствуйте, Serginio1, Вы писали:
K>>>Судя по кол-ву вакансий это, мягко говоря, не так.
KP>>
KP>>5285 вакансий «Java»
KP>>2459 вакансий «C#»
KP>>(c) hh.ru
KP>>Что получается на уровне "умирающего" C++ c 2323 вакансии. Таки что-то в предположении vsb есть
S> Интересно, а сколько из этих вакансий под убогий «Java» для Android?
Я думаю что грубо можно посчитать вакансии для "не убогой Java" как "вакансий «Java»" — "вакансий «kotlin»". Так как есть 1411 вакансий «kotlin», то выходит что ~3800, что всё еще на 50% больше чем на C#.
KP>Я думаю что грубо можно посчитать вакансии для "не убогой Java" как "вакансий «Java»" — "вакансий «kotlin»". Так как есть 1411 вакансий «kotlin», то выходит что ~3800, что всё еще на 50% больше чем на C#.
Угу при этом многие не используют пока котлин.
Но это не суть. Много Java из анахронизмов legacy которое нужно поддерживать.
А вот новые проекты .Net удобнее ибо и язык и среда (IDE)мощнее. Да и скорость выполнения от версии к версии растет Performance improvements in ASP.NET Core 6
Плюс плюшки в виде Блазора, UNO, Xamarin итд
и солнце б утром не вставало, когда бы не было меня
ET>Что-то всё меньше новых проектов пишут на шарпе. ET>Тенденция или я не туда смотрю?
ET>Кто занял долю проектов которые были на asp.net (mvc, core etc)?
Ну, по сути C# для новых проектов используется в
а) веб-разработке (включая всякие лямбды), серверная часть
б) собственно, всё, только а).
Учитывая, что там конкуренция зашкаливает (более простые питон, ява-скрипт теснят только так + очень мощный задел у явы), то предсказывать что-либо сложно, но думаю, что из-за сложности языка молодёжь (и новые проекты) пойдут в питон и яву-скрипт.
В>Ну, по сути C# для новых проектов используется в В>а) веб-разработке (включая всякие лямбды), серверная часть В>б) собственно, всё, только а).
Ну вообще то есть Unity, Xamarin, десктоп.
Да и фронт включая Blazor,Uno и прочие SPA
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Но это не суть. Много Java из анахронизмов legacy которое нужно поддерживать.
А на C# их нет? Как так вышло?
S>А вот новые проекты .Net удобнее ибо и язык и среда (IDE)мощнее. Да и скорость выполнения от версии к версии растет
Какая IDE мощнее? Если мы говорим про бэкенд, то разработчики обычно на macOS или Linux сидят, а там VScode и IDEA работает так же как и на венде.
S>Performance improvements in ASP.NET Core 6 S>Плюс плюшки в виде Блазора, UNO, Xamarin итд
У JVM несколько реализаций и всегда можно выбрать ту, что лучше подходит для задачи.
И даже если предположить что C# удобнее по ряду причин, количество вакансий на нём идёт в низ. И, моё мнение, и дальше будет падать.
В>>Ну, по сути C# для новых проектов используется в В>>а) веб-разработке (включая всякие лямбды), серверная часть В>>б) собственно, всё, только а). S>Ну вообще то есть Unity, Xamarin, десктоп. S>Да и фронт включая Blazor,Uno и прочие SPA
Есть дофига непонятных слов, но что это меняет? Для рабочих станций новых проектов почти нет. Для мобилок — нет. Игры? Ха-ха. Встроенные системы? Ха-за три раза.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Serginio1, Вы писали:
S>> Но это не суть. Много Java из анахронизмов legacy которое нужно поддерживать.
KP>А на C# их нет? Как так вышло?
Ну сейчас .Net Core в основном под линукс. А до этого под линукс не было S>>А вот новые проекты .Net удобнее ибо и язык и среда (IDE)мощнее. Да и скорость выполнения от версии к версии растет
KP>Какая IDE мощнее? Если мы говорим про бэкенд, то разработчики обычно на macOS или Linux сидят, а там VScode и IDEA работает так же как и на венде.
А зачем сидеть под macOS или Linux если код то кроссплатформенный. Удобно отлаживать по Windows. Код то один и тот же!
А вот VS то помощнее всяких VScode и IDEA.
Ну мы говорим не только про бэк но и фронт итд итп.
S>>Performance improvements in ASP.NET Core 6 S>>Плюс плюшки в виде Блазора, UNO, Xamarin итд
KP>У JVM несколько реализаций и всегда можно выбрать ту, что лучше подходит для задачи.
То есть есть аналоги Блазора, UNO? KP>И даже если предположить что C# удобнее по ряду причин, количество вакансий на нём идёт в низ. И, моё мнение, и дальше будет падать.
Твое мнение нкак не согласуется с действительностью. Ибо развитие .Net Core обусловлено сообществом которым нужно больше, и то что не может дать Java.
Просто потребность в вэбе растет прежде всего за счет облаков!
Ну и популярность языков и фреймворков можно посмотреть здесь популярность языков и фреймворков
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ватакуси, Вы писали:
S>>Ну вообще то есть Unity, Xamarin, десктоп. S>>Да и фронт включая Blazor,Uno и прочие SPA
В>Есть дофига непонятных слов, но что это меняет? Для рабочих станций новых проектов почти нет. Для мобилок — нет. Игры? Ха-ха. Встроенные системы? Ха-за три раза.
Суслика видишь? А он есть!
Ну и популярность языков и фреймворков можно посмотреть здесь популярность языков и фреймворков
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> А зачем сидеть под macOS или Linux если код то кроссплатформенный. Удобно отлаживать по Windows. Код то один и тот же!
Что бы ОС была удобная, а не вот это вот всё безобразие.
S>А вот VS то помощнее всяких VScode и IDEA.
Я вообще не видел ни одного бэкендера кто бы сидел на венде, да и то что VS мощнее штука спорная.
S>Ну мы говорим не только про бэк но и фронт итд итп.
А там зачем нужна венда?
S> То есть есть аналоги Блазора, UNO?
Я вообще в первый раз эти термины вижу, видимо это какое-то крайне популярные технологии.
S> Твое мнение нкак не согласуется с действительностью. Ибо развитие .Net Core обусловлено сообществом которым нужно больше, и то что не может дать Java.
Видимо поэтому на .NET поэтому вакансий в два паза меньше чем на JVM. Кстати, в Сингапуре на одну вакансию на .NET приходится около 10 на JVM. В Долине ты .NET вообще не увидишь. Видимо по причине чрезвычайной мощи, бояццо.
S>Просто потребность в вэбе растет прежде всего за счет облаков! S> Ну и популярность языков и фреймворков можно посмотреть здесь популярность языков и фреймворков
Я в курсе про облака и веб. И вижу там JVM, Python, Go; а .NET не вижу, потому как его там крайне мало. МС поздно поняла что язык для одной платформы — это путь в никуда.
В>Для рабочих станций новых проектов почти нет.
Как ты это определил?
Внутренняя автоматизация, бесконечные доделки GUI самописных корпоративных ERP — чем в этом смысле отличаются от "новых" проектов?
Здравствуйте, kaa.python, Вы писали:
k> Я в курсе про облака и веб. И вижу там JVM, Python, Go; а .NET не вижу, потому как его там крайне мало. МС поздно поняла что язык для одной платформы — это путь в никуда.
Думаю, МС всегда это понимала. Более того, удобный фреймворк должен был увеличивать привлекательность платформы для разработчиков. Только вот сейчас эта платформа нужна все меньше, даже самой МС.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Serginio1, Вы писали:
S>> А зачем сидеть под macOS или Linux если код то кроссплатформенный. Удобно отлаживать по Windows. Код то один и тот же!
KP>Что бы ОС была удобная, а не вот это вот всё безобразие.
А чем виндовс для отладки хуже линукса? Вот VScode как раз огрызок! S>>А вот VS то помощнее всяких VScode и IDEA.
KP>Я вообще не видел ни одного бэкендера кто бы сидел на венде, да и то что VS мощнее штука спорная.
S>>Ну мы говорим не только про бэк но и фронт итд итп.
KP>А там зачем нужна венда?
Удобно использовать VS. Зачем эти линуксы для отладки?
S>> То есть есть аналоги Блазора, UNO?
KP>Я вообще в первый раз эти термины вижу, видимо это какое-то крайне популярные технологии.
Да блазор ооочень удобен, UNO кроссплатформенный UI S>> Твое мнение нкак не согласуется с действительностью. Ибо развитие .Net Core обусловлено сообществом которым нужно больше, и то что не может дать Java.
KP>Видимо поэтому на .NET поэтому вакансий в два паза меньше чем на JVM. Кстати, в Сингапуре на одну вакансию на .NET приходится около 10 на JVM. В Долине ты .NET вообще не увидишь. Видимо по причине чрезвычайной мощи, бояццо.
Здравствуйте, Ватакуси, Вы писали:
В>Ну, по сути C# для новых проектов используется в В>а) веб-разработке (включая всякие лямбды), серверная часть В>б) собственно, всё, только а).
Учитывая, что
а) Десктоп умирает
б) Мобилки стагнируют
в) собственно, все, больше сколько нибудь крупных секторов больше нет, остался бэк.
Здравствуйте, vsb, Вы писали:
S>>Java уже лет 20 постепенно выигрывает. vsb>В том-то и дело. И если раньше у C# было естественное преимущество в виде десктопных приложений, то сейчас эта ниша исчезла.
Зато появилась ниша числомолотилок и софта где критичен оверхед по памяти.
vsb>C# пытается влезть на рынок серверных линуксовых приложений, но его там особо никто не ждёт.
Blazor WebAssembly поддерживает Blazor, в котором код .NET можно скомпилировать непосредственно в WebAssembly. Компиляция AOT позволяет повысить производительность среды выполнения за счет увеличения размера приложения.
Без включения компиляции AOT приложения Blazor WebAssembly выполняются в браузере с использованием интерпретатора промежуточного языка .NET, реализованного в WebAssembly. Поскольку код .NET интерпретируется, приложения обычно выполняются медленнее, чем на стороне сервера среды выполнения JIT .NET. Компиляция AOT позволяет решить эту проблему с производительностью, выполняя компиляцию кода .NET приложения непосредственно в WebAssembly для выполнения собственной сборки через браузер. Повышение производительности AOT может привести к значительному улучшению приложений, выполняющих ресурсоемкие задачи. Недостаток использования компиляции AOT заключается в том, что приложения, скомпилированные с помощью AOT, обычно больше их аналогов, интерпретируемых с помощью IL, поэтому загрузка клиента при первом запросе обычно занимает больше времени.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
KP>>Что бы ОС была удобная, а не вот это вот всё безобразие. S> А чем виндовс для отладки хуже линукса? Вот VScode как раз огрызок!
Отладка везде одинакова. Винда плоха тем, что консоль и файловая система там не *nix, a учить powershell-ы никому нафиг не надо — киллер фич нет.
S> Удобно использовать VS. Зачем эти линуксы для отладки?
Ты отладку понимаешь исключительно как трассировку кода, которая в той же IDEA/Java не факт, что и уступает VS/C#. Есть много другой отладки — логи, микроскрипты, tensorboard и т.д. и все это сильно хуже в винде. Даже может уже и не "хуже", а по другому и поэтому никому нафиг не надо.
Здравствуйте, novitk, Вы писали:
N>Здравствуйте, Serginio1, Вы писали:
KP>>>Что бы ОС была удобная, а не вот это вот всё безобразие. S>> А чем виндовс для отладки хуже линукса? Вот VScode как раз огрызок! N>Отладка везде одинакова. Винда плоха тем, что консоль и файловая система там не *nix, a учить powershell-ы никому нафиг не надо — киллер фич нет.
А зачем тебе для .фронта файловая система. Все хранится в БД. Нахрена powershell то для отладки? S>> Удобно использовать VS. Зачем эти линуксы для отладки? N>Ты отладку понимаешь исключительно как трассировку кода, которая в той же IDEA/Java не факт, что и уступает VS/C#. Есть много другой отладки — логи, микроскрипты, tensorboard и т.д. и все это сильно хуже в винде. Даже может уже и не "хуже", а по другому и поэтому никому нафиг не надо.
Уступает как язык так и среда. Логи это больше для выявления ошибок у клиентов. А вот для обычной отладки нужна IDE.
Интересно чем логи под линукс лучше чем под Винду? В той же VS прекрасно performance profiler работают итд.
Здесь конечно я не знаток. Для большинства линукс нужен только для выполнения. Отладил на винде, собрал доккер под линукс
Например тот же Xamarin в большинстве монописуально для какой ОС пишется код. Тоже и бэк.
Начиная с Visual Studio 2017 можно присоединяться к процессам .NET Core, запущенным в локальном или удаленном развертывании Linux, по протоколу SSH. В этой статье описывается настройка и выполнение процесса отладки. Сценарии отладки с использованием контейнеров Docker см. в статьях Присоединение к процессу, выполняющемуся в контейнере Docker и об инструментах для работы с контейнерами. Сведения об отладке Linux в WSL 2 из Visual Studio (без присоединения к процессу) см. в этой статье.
Вы можете легко запускать и отлаживать свои .NET-приложения в Linux, не выходя из Visual Studio, посредством использования WSL. Если вы разрабатываете кросс-платформенные приложения, этот метод предоставляет простой способ тестировать большинство целевых сред.
Для пользователей Windows .NET, разрабатывающих приложения для Linux, WSL 2 — это оптимальное сочетание реалистичной рабочей среды и высокой производительности. В Visual Studio вы уже можете выполнять отладку в удаленной среде Linux, используя удаленный отладчик или контейнеры с помощью соответствующих средств. Эти варианты подойдут, если больше всего необходимо достичь реалистичных условий. Когда более важен простой и быстрый внутренний цикл, WSL является отличным вариантом.
и солнце б утром не вставало, когда бы не было меня
В>>Для рабочих станций новых проектов почти нет. O>Как ты это определил? O>Внутренняя автоматизация, бесконечные доделки GUI самописных корпоративных ERP — чем в этом смысле отличаются от "новых" проектов?
Здравствуйте, Serginio1, Вы писали:
S> А зачем тебе для .фронта файловая система. Все хранится в БД. Нахрена powershell то для отладки?
Для какого еще фронта? Например мне, не претендуя на всеобщность, для отладки того же питона нужен в основном jupyter. Работа в PyCharm, который уровня VS/C# с трассирующим отладчик и прочими шлюхами, на порядок медленнее.
S> Уступает как язык так и среда.
Я использую и то и другое. Где именно IDEA/java уступает VS?
S> Логи это больше для выявления ошибок у клиентов. А вот для обычной отладки нужна IDE.
Чушь. У клиента кроме лога просто вообще нифига нет, но это не делает их бесполезным и при разработке.
S>Интересно чем логи под линукс лучше чем под Винду?
Тем что в линуксе/маcos кошерный консольный userspace, который сидит в пальцах и позволят эти логи анализировать за секунды. А в винде тот же git запускается в убогом терминале под мингом с дырявой эмуляцией над файлсистемой. Кому такое нафиг нужно?
S>Здесь конечно я не знаток. Для большинства линукс нужен только для выполнения.
Иметь разные среды для выполнения и отладки — костыль, который пытаются избежать. Раньше на Linux было плохо с IDE, но это не про Java, a про плюсы. VS был кому-то сильно удобней емакса. Как сейчас с CLion не знаю.
S> Например тот же Xamarin в большинстве монописуально для какой ОС пишется код. Тоже и бэк.
Для кода может и монописуально, а для разраба нет.
Здравствуйте, novitk, Вы писали:
S>> Логи это больше для выявления ошибок у клиентов. А вот для обычной отладки нужна IDE. N>Чушь. У клиента кроме лога просто вообще нифига нет, но это не делает их бесполезным и при разработке.
Не стоит выдавать нужду за добродетель.
S>>Интересно чем логи под линукс лучше чем под Винду? N>Тем что в линуксе/маcos кошерный консольный userspace, который сидит в пальцах и позволят эти логи анализировать за секунды.
grep и printf-debugging ваше всио, да Ничего другого не умеете.
N> А в винде тот же git запускается в убогом терминале под мингом с дырявой эмуляцией над файлсистемой. Кому такое нафиг нужно?
Да потому что гит это говно с кусочками фруктов скриптота с парой бинарей. Эта куча спагетти написана просто ужасно, потому никто его даже не пытается портировать — запускают через эмулятор.
Здравствуйте, CreatorCray, Вы писали:
N>>Тем что в линуксе/маcos кошерный консольный userspace, который сидит в пальцах и позволят эти логи анализировать за секунды. CC>grep и printf-debugging ваше всио, да Ничего другого не умеете.
дАартаньян Бензинович Бумеров, идите обратно в авто к Темочке!
N>> А в винде тот же git запускается в убогом терминале под мингом с дырявой эмуляцией над файлсистемой. Кому такое нафиг нужно? CC>Да потому что гит это говно с кусочками фруктов скриптота с парой бинарей. Эта куча спагетти написана просто ужасно, потому никто его даже не пытается портировать — запускают через эмулятор.
А это не суть важно, он победил и по факту его на порядок удобней использовать на линух.
Здравствуйте, Serginio1, Вы писали:
S> А чем виндовс для отладки хуже линукса? Вот VScode как раз огрызок!
Всем хуже, но особенно отсутствием нормальной консоли и соответствующих команд.
S> Удобно использовать VS. Зачем эти линуксы для отладки?
А что ты собрался в бэкенде (ты же тут за облака топишь, где NET дескать растёт) отлаживать? Юнит тесты? Ну их обычно не надо отлаживать, всё остальное всяко многопоточное/асинхронное и отладкой отладчиком не поддаётся. Linux нужен именно что для разработки нужен.
S> Да блазор ооочень удобен, UNO кроссплатформенный UI
А почему тогда для этой цели обычно Электрон используют? Ну, всякие Слэки, Спотифаи и т.д.?
S>Еще раз общий Java включает в себя еще и андроид. И при этом по stackoverflow никакого в 2 раза не вижу!
Ну ты, конечно, можешь и дальше говорить халва-халва, а можешь посмотреть по сторонам и освоить какие-то нормальные платформы которые не дохнут прям на глазах.
S>Blazor WebAssembly поддерживает Blazor, в котором код .NET можно скомпилировать непосредственно в WebAssembly. Компиляция AOT позволяет повысить производительность среды выполнения за счет увеличения размера приложения.
S>Без включения компиляции AOT приложения Blazor WebAssembly выполняются в браузере с использованием интерпретатора промежуточного языка .NET, реализованного в WebAssembly. Поскольку код .NET интерпретируется, приложения обычно выполняются медленнее, чем на стороне сервера среды выполнения JIT .NET. Компиляция AOT позволяет решить эту проблему с производительностью, выполняя компиляцию кода .NET приложения непосредственно в WebAssembly для выполнения собственной сборки через браузер. Повышение производительности AOT может привести к значительному улучшению приложений, выполняющих ресурсоемкие задачи. Недостаток использования компиляции AOT заключается в том, что приложения, скомпилированные с помощью AOT, обычно больше их аналогов, интерпретируемых с помощью IL, поэтому загрузка клиента при первом запросе обычно занимает больше времени.
итого. AOT это что-то странное. файлов на 60% больше, поведение может изменится. компилится реально минут 10 маленький проект.
А смысл? blazor нужен как замена реакту — UI рисовать, там скорость не особо нужна.
А вообще все это еще раз подтверждает что ВМ не нужны, нужен только ГЦ.
Хотя вот у жавы вроде рантайм поменьше, нет?
vaa>итого. AOT это что-то странное. файлов на 60% больше, поведение может изменится. компилится реально минут 10 маленький проект. vaa>А смысл? blazor нужен как замена реакту — UI рисовать, там скорость не особо нужна. vaa>А вообще все это еще раз подтверждает что ВМ не нужны, нужен только ГЦ. vaa>Хотя вот у жавы вроде рантайм поменьше, нет?
Там же не только UI но и вычисления на клиенте. В некоторых случаях это может быть долго.
Вообще для блазора нужен гибридный вариант, часть на клиенте, часть на сервере.
Но передача данных на сервер и возврат результата может быть дороже чем вычисления на клиенте
А вот реально нужна компиляция только критичных по скорости мест. Тот же JS так и поступает.
На самом то деле главное, что движуха то есть и реально многое оптимизируется. Просто пока далеко до идеала.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Лось Чтостряслось, Вы писали:
МР>>- Xamarin кажется, что так и не набрал сколько-нибудь заметную популярность. ЛЧ>потому что есть лютое говно
А в чем это проявляется?
Здравствуйте, Лось Чтостряслось, Вы писали:
ЛЧ>Здравствуйте, Михаил Романов, Вы писали:
МР>>- Xamarin кажется, что так и не набрал сколько-нибудь заметную популярность. ЛЧ>потому что есть лютое говно
Я работаю с Xamarin Android и могу сказать, что он сделал значительные успехи по сравнению с первыми версиями
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, novitk, Вы писали:
S>>Интересно чем логи под линукс лучше чем под Винду? N>Тем что в линуксе/маcos кошерный консольный userspace, который сидит в пальцах
Т.е. это ты не имеешь навыков работы на винде, но выводы сделал глобальные?
Здравствуйте, Лось Чтостряслось, Вы писали:
ЛЧ>Здравствуйте, Serginio1, Вы писали:
S>>Я работаю с Xamarin Android и могу сказать, что он сделал значительные успехи по сравнению с первыми версиями
ЛЧ>я работаю со стороны ios, и по сравнению с прошлыми версиями вижу значительные ухудшения
Ну вот Xamarin то разный! Нужно уточнять!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Лось Чтостряслось, Вы писали:
ЛЧ>Здравствуйте, Serginio1, Вы писали:
S>>Я работаю с Xamarin Android и могу сказать, что он сделал значительные успехи по сравнению с первыми версиями
ЛЧ>я работаю со стороны ios, и по сравнению с прошлыми версиями вижу значительные ухудшения
Кстати на заре за нативную компиляцию отвечал Mono. Затем они его вроде как объединили с .Net Native.
А в чем проблемы не уточнишь?
Испрользуете Xamarin.Forms или нативный Xamarin.iOS
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Т.е. это ты не имеешь навыков работы на винде, но выводы сделал глобальные?
Я как раз до сих пор на винде, так как работую со штуками типа excel или bloomberg api, которых на линухе нет или дорого держать для разработки. Я не очень понимаю с чем вы тут спорите, тренд вроде очевиден.
Здравствуйте, Лось Чтостряслось, Вы писали:
ЛЧ>я работаю со стороны ios, и по сравнению с прошлыми версиями вижу значительные ухудшения
Если не сложно, то можете чуть подробнее рассказать?
Ну и сразу же спрошу — вы работает с Xamarin.Forms или именно с Xamarin.iOS? И как вы смотрите на идею (и реализацию) Forms, если опыт работы с ними есть?
Здравствуйте, Михаил Романов, Вы писали:
ЛЧ>>я работаю со стороны ios, и по сравнению с прошлыми версиями вижу значительные ухудшения МР>Если не сложно, то можете чуть подробнее рассказать? МР>Ну и сразу же спрошу — вы работает с Xamarin.Forms или именно с Xamarin.iOS? И как вы смотрите на идею (и реализацию) Forms, если опыт работы с ними есть?
Ну сейчас уже Maui нужно дождаться. А так изредка для тестов беру Forms и вижу очевидный прогресс. https://devblogs.microsoft.com/dotnet/announcing-net-maui-preview-12/
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, kaa.python, Вы писали:
S>> А чем виндовс для отладки хуже линукса? Вот VScode как раз огрызок!
KP>Всем хуже, но особенно отсутствием нормальной консоли и соответствующих команд.
Это довольно устаревшая информация. Консоль в винде сейчас точно такая же как и на маке/линуксе.
Здравствуйте, TG, Вы писали:
TG>1. фатальные недостатки в самом .NET,
Виндовс его фатальный недостаток. Фактически, линукс означает жава. Венда означает пончик.
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, TG, Вы писали:
TG>>1. фатальные недостатки в самом .NET, Тё>Виндовс его фатальный недостаток. Фактически, линукс означает жава. Венда означает пончик.
Даа. Уже давно .Net core под линукс активно используется! Прежде всего для облаков! Разработка и развертывание на различных платформах Для какой ОС использовать контейнеры .NET
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Константин Б., Вы писали:
КБ>Это довольно устаревшая информация. Консоль в винде сейчас точно такая же как и на маке/линуксе.
Это за последние пару лет что-то нормально работающее добавили? Я пару лет назад попробовал Венду, но в ней консоль на столько кривая, что даже для домашних проектов не годится. Ты или полностью сидишь в WLS, который тоже глючит изрядно (но тогда зачем вообще венда?), либо страдаешь от PowerShell, который явно под тяжёлыми веществами проектировали.
TG>>>1. фатальные недостатки в самом .NET, Тё>>Виндовс его фатальный недостаток. Фактически, линукс означает жава. Венда означает пончик. S> Даа. Уже давно .Net core под линукс активно используется! Прежде всего для облаков!
Ты, видимо, хотел сказать "Майкрософт хочет что бы .Net core под линукс активно использовали", но описался
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, vaa, Вы писали:
vaa>>итого. AOT это что-то странное. файлов на 60% больше, поведение может изменится. компилится реально минут 10 маленький проект. vaa>>А смысл? blazor нужен как замена реакту — UI рисовать, там скорость не особо нужна. vaa>>А вообще все это еще раз подтверждает что ВМ не нужны, нужен только ГЦ. vaa>>Хотя вот у жавы вроде рантайм поменьше, нет? S>Там же не только UI но и вычисления на клиенте. В некоторых случаях это может быть долго. S>Вообще для блазора нужен гибридный вариант, часть на клиенте, часть на сервере. S>Но передача данных на сервер и возврат результата может быть дороже чем вычисления на клиенте S>А вот реально нужна компиляция только критичных по скорости мест. Тот же JS так и поступает. S>На самом то деле главное, что движуха то есть и реально многое оптимизируется. Просто пока далеко до идеала.
По мне блазор это замена именно UI части, полноценной заменой декстоп-приложений ему не стать.
Главная цель блазор писать весь код приложения на одном языке.
А скорость ну может только для какой-то браузерной игры критична.
js все таки на клиенте компилится, а тут прекомпиляция, хотя даже неизвестно на каком железе это будет работать.
Здравствуйте, Serginio1, Вы писали:
S> давно .Net core под линукс активно используется! Прежде всего для облаков!
Кем используется? Например, компания исторически сидела на опен сорсе, линукс, жава монолит. Переходит в облака на AWS- какой смысл заменить жаву на шарп? Даже если и шарп что-то может на линуксе. Исторически, шарп там был с середины 2000-х, криво поддерживался, на что-то MS забило. В е понимали- хочешь понлоценный пончик, дорога в венду.
Здравствуйте, Тёмчик, Вы писали:
Тё>Кем используется? Например, компания исторически сидела на опен сорсе, линукс, жава монолит. Переходит в облака на AWS- какой смысл заменить жаву на шарп? Даже если и шарп что-то может на линуксе. Исторически, шарп там был с середины 2000-х, криво поддерживался, на что-то MS забило. В е понимали- хочешь понлоценный пончик, дорога в венду.
Ну вот в противоположной ситуации и используется. У тебя есть старый монолит на .NET, а душа требует микросервисов и облаков. В пылу попила ты же не будешь на Java переписывать? Не будешь, значит надо тащить на облака с .NET. Другое дело что надо быть довольно специфичным человеком, что бы начать с нуля проект на .NET для облаков, когда есть столько куда более подходящих инструментов
Здравствуйте, vaa, Вы писали: S>>Там же не только UI но и вычисления на клиенте. В некоторых случаях это может быть долго. S>>Вообще для блазора нужен гибридный вариант, часть на клиенте, часть на сервере. S>>Но передача данных на сервер и возврат результата может быть дороже чем вычисления на клиенте S>>А вот реально нужна компиляция только критичных по скорости мест. Тот же JS так и поступает. S>>На самом то деле главное, что движуха то есть и реально многое оптимизируется. Просто пока далеко до идеала.
vaa>По мне блазор это замена именно UI части, полноценной заменой декстоп-приложений ему не стать.
Ну почему же. Cross platform Blazor Desktop example
vaa>Главная цель блазор писать весь код приложения на одном языке. vaa>А скорость ну может только для какой-то браузерной игры критична. vaa>js все таки на клиенте компилится, а тут прекомпиляция, хотя даже неизвестно на каком железе это будет работать.
JS может компилиться или интерпретироваться.
AOT должен быть только для проблемных частей. Перекомпиляции то в AOT нет в отличие от Jit. Проблема в размере
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, Serginio1, Вы писали:
S>> давно .Net core под линукс активно используется! Прежде всего для облаков!
Тё>Кем используется? Например, компания исторически сидела на опен сорсе, линукс, жава монолит. Переходит в облака на AWS- какой смысл заменить жаву на шарп? Даже если и шарп что-то может на линуксе. Исторически, шарп там был с середины 2000-х, криво поддерживался, на что-то MS забило. В е понимали- хочешь понлоценный пончик, дорога в венду.
Отдельно следует отметить, что по итогам III квартала 2021 г. Microsoft закрепилась на втором месте в рейтинге владельцев крупнейших облачных сервисов. Ее Azure удерживал 21% рынка против 32% у Amazon Web Services и 8% у Google Cloud (статистика Statista.com).
А ведь совсем недавно AWS был безоговорочным лидером!
При этом показатели AWS тоже растут. А значи все это происходит за счет новых проектов!
И .Net и Java и питона итд. И вот соотношение использования .Net и Java на том же StackOverflow
Здравствуйте, Serginio1, Вы писали:
vaa>>По мне блазор это замена именно UI части, полноценной заменой декстоп-приложений ему не стать. S>Ну почему же. Cross platform Blazor Desktop example
пока еще браузер очень сильно ограничивает клиента в правах.
Навскидку: запрос делается через интероп fetch api — если потребуется выполнить запрос к https://rsdn.org/forum/rss/dotnet
из блазора придется обратится к прокси-серверу.
Тоже самое с шифрованием. вообщем, блазор хоть и удобен, он остается лишь частью веб-технологий.
Его возможности определяются возможностями браузера.
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, Serginio1, Вы писали:
vaa>>>По мне блазор это замена именно UI части, полноценной заменой декстоп-приложений ему не стать. S>>Ну почему же. Cross platform Blazor Desktop example vaa>пока еще браузер очень сильно ограничивает клиента в правах. vaa>Навскидку: запрос делается через интероп fetch api — если потребуется выполнить запрос к https://rsdn.org/forum/rss/dotnet vaa>из блазора придется обратится к прокси-серверу. vaa>Тоже самое с шифрованием. вообщем, блазор хоть и удобен, он остается лишь частью веб-технологий.
vaa>Его возможности определяются возможностями браузера.
Здравствуйте, vaa, Вы писали:
vaa>пока еще браузер очень сильно ограничивает клиента в правах.
На самом деле уже давно нет. А если сравнивать скажем с мобильным (а не десктопным) приложением, то считай вообще почти одинаковый уровень возможностей (ну кроме некоторых достаточно специфических вещей).
vaa>Навскидку: запрос делается через интероп fetch api — если потребуется выполнить запрос к https://rsdn.org/forum/rss/dotnet vaa>из блазора придется обратится к прокси-серверу.
Не знаю что там в блазорах эти ваших. Но в браузере уже много лет как живёт websocket, который решает все эти проблемы.
И да, пока реально не хватает доступа к UDP (например для поиска устройств в сети), но над этим тоже работают и думаю ещё добавят (как добавили USB, GPU и ещё много чего ещё в последнее время).
vaa>Его возможности определяются возможностями браузера.
АПИ браузера сейчас уже не сильно отличается от АПИ операционной системы. Да, ещё есть пробелы в некоторых специфических областях, но для большинства стандартных задач уже давно всё есть.
Здравствуйте, kaa.python, Вы писали:
KP>WLS, который тоже глючит изрядно,
А можно раскрыть подробнее оч ем именно речь? И сразу же — речь о какой версии WLS — первой или второй
KP>PowerShell, который явно под тяжёлыми веществами проектировали
И здесь тоже можно подробнее — что именно там не так?
Вот коллегу
Здравствуйте, Михаил Романов, Вы писали:
МР>А можно раскрыть подробнее оч ем именно речь? И сразу же — речь о какой версии WLS — первой или второй
Посмотрел свои заметки — дело было в 2019, какой там был WSL я не уверен, но вроде было был первый и бета второго. Проблемы следующие, дико тормозной I/O по сравнению с реальной системой, особенно на мелких файлах. Глючные терминалы, ошибки с перерисовкой, падения, зависания. То есть полноценно работать в WSL было не возможно, разве что попробовать что-то запустить по быстрому, своего роде встроенный Докер.
KP>>PowerShell, который явно под тяжёлыми веществами проектировали МР>И здесь тоже можно подробнее — что именно там не так?
Не так вообще всё. Я не хочу учить еще один шелл и писать один и тот же скрип для двух разных шеллов. Посему это или что-то реально SH-совместимое, или в лес. Тут просто такой момент есть — сервера и всё скриптование, обычно, это мир *NIX и там везде (Linux, BSD, macOS) один и тот же SH с небольшими отличиями в ключах. Как следствие PS должен был бы не предлагать новое прочтение того же самого, а по уму сделать возможным максимально бесшовную работу. А этого как раз и нет, но есть типично майкрософтовское "все переходите на венду".
Здравствуйте, Ночной Смотрящий, Вы писали:
KP>>Проблемы следующие, дико тормозной I/O по сравнению с реальной системой, особенно на мелких файлах. НС>В WSL 2 вылечено
Это не убирает главного — если ты обычно работаешь в Linux и консоли, то вообще зачем ставить Windows и сидеть в WSL?
KP>Это не убирает главного — если ты обычно работаешь в Linux и консоли, то вообще зачем ставить Windows и сидеть в WSL?
Незачем. Но речь-то, вроде бы, о сценарии "работаю в windows и нужно собирать/отлаживать приложения под Linux"
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Ночной Смотрящий, Вы писали:
KP>>>Проблемы следующие, дико тормозной I/O по сравнению с реальной системой, особенно на мелких файлах. НС>>В WSL 2 вылечено
KP>Это не убирает главного — если ты обычно работаешь в Linux и консоли, то вообще зачем ставить Windows и сидеть в WSL?
Но если ты работаешь в VS то нахрена тебе эта консоль?
Это вообще какой то анахронизм! Это как в С++ без IDE пишут в блокнотике!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Константин Б., Вы писали:
КБ>Это довольно устаревшая информация. Консоль в винде сейчас точно такая же как и на маке/линуксе.
Это про новый терминал? Нет не такая. То есть прогресс есть, но абстракции текут: https://github.com/microsoft/terminal/issues/1256
Зарисовка:
У меня тут есть чувак под 30 лет, математик с PhD от UC Berkley, толковый, плюсы/скала без проблем. Ему потребовалось питончик на винде погонять, до этого он это делал только на линухе.
Зашел он значит в cmd.exe и сделал "cd Y:\blah\blah" и говорит "a почему оно по прежнему на "c:\Users\blah\blah". Удивил. Говорит в школе он особо не программировал, в универе все было на *nix, а сейчас для дома Мак.
Здравствуйте, kaa.python, Вы писали:
KP>Это не убирает главного — если ты обычно работаешь в Linux и консоли, то вообще зачем ставить Windows и сидеть в WSL?
Потому что по сю пору десктопная ОС из Линуха как из говна пуля, и далеко не всем интересно два ноутбука держать. Есть, опять же, люди, предпочитающие VS, коя есть только под винду.
Здравствуйте, Михаил Романов, Вы писали:
МР>Незачем. Но речь-то, вроде бы, о сценарии "работаю в windows и нужно собирать/отлаживать приложения под Linux"
Здравствуйте, Serginio1, Вы писали:
S> Но если ты работаешь в VS то нахрена тебе эта консоль?
У меня есть предположение что ты в основном под Windows пишешь. Потому как если ты под Linux что-то делаешь, то без консоли что-то сложнее Пиивет Мир сделать сложно.
S>Это вообще какой то анахронизм! Это как в С++ без IDE пишут в блокнотике!
Давай для начала проясним что такое IDE в твоём понимании. Это обязательно GUI приложение с меню и кнопками, или навигация, автодополнение, рефакторинг и т.д.? Потому как если второе, то у меня в Vim такое очень давно есть.
Ну и ещё раз, серьёзный не-Windows проект ты просто не откроешь в VS. Скорее всего это будет монорепозиторий с Bazel, или CMake + Conan.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Потому что по сю пору десктопная ОС из Линуха как из говна пуля, и далеко не всем интересно два ноутбука держать. Есть, опять же, люди, предпочитающие VS, коя есть только под винду.
А что не так с Убунтой? И я и жена на ней, хуже macOS, но на голову удобнее Windows. Одна установка и обновление всего софта из репозитория чего стоит в плане удобства.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Serginio1, Вы писали:
S>> Но если ты работаешь в VS то нахрена тебе эта консоль?
KP>У меня есть предположение что ты в основном под Windows пишешь. Потому как если ты под Linux что-то делаешь, то без консоли что-то сложнее Пиивет Мир сделать сложно.
Да но я не понимаю людей которые отказываются от VS в пользу консоли?
S>>Это вообще какой то анахронизм! Это как в С++ без IDE пишут в блокнотике!
KP>Давай для начала проясним что такое IDE в твоём понимании. Это обязательно GUI приложение с меню и кнопками, или навигация, автодополнение, рефакторинг и т.д.? Потому как если второе, то у меня в Vim такое очень давно есть.
Это прежде всего отладка с кучей окон для мониторинга. KP>Ну и ещё раз, серьёзный не-Windows проект ты просто не откроешь в VS. Скорее всего это будет монорепозиторий с Bazel, или CMake + Conan.
Я пишу на C#. Это кроссплатформенный проект. И тема то как раз про него.
Но ты смотришь на перспективы C# со своей колокольни. Только вот колокольни то разные.
как я уже писал отлаживать кроссплатформенный код проще в винде, а для уже отлаженного кода уже применять плюшки для линукса
Кроме того Отладка .NET Core в Linux с помощью SSH путем присоединения к процессу
Начиная с Visual Studio 2017 можно присоединяться к процессам .NET Core, запущенным в локальном или удаленном развертывании Linux, по протоколу SSH. В этой статье описывается настройка и выполнение процесса отладки. Сценарии отладки с использованием контейнеров Docker см. в статьях Присоединение к процессу, выполняющемуся в контейнере Docker и об инструментах для работы с контейнерами. Сведения об отладке Linux в WSL 2 из Visual Studio (без присоединения к процессу) см. в этой статье.
Вы можете легко запускать и отлаживать свои .NET-приложения в Linux, не выходя из Visual Studio, посредством использования WSL. Если вы разрабатываете кросс-платформенные приложения, этот метод предоставляет простой способ тестировать большинство целевых сред.
Для пользователей Windows .NET, разрабатывающих приложения для Linux, WSL 2 — это оптимальное сочетание реалистичной рабочей среды и высокой производительности. В Visual Studio вы уже можете выполнять отладку в удаленной среде Linux, используя удаленный отладчик или контейнеры с помощью соответствующих средств. Эти варианты подойдут, если больше всего необходимо достичь реалистичных условий. Когда более важен простой и быстрый внутренний цикл, WSL является отличным вариантом.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, kaa.python, Вы писали:
KP>А что не так с Убунтой?
Во-первых железо. Если я ставлю более менее свежую винду на более менее свежее железо с более менее свежей периферией, то есть почти 100% гарантия того что все заработает с минимумом усилий. На линухе это до сих пор лотерея. В лучшем случае ты потратишь несколько дней на поиск драйверов, ядра и прочего стаффа, в худшем останешься без части железок.
Во-вторых софт. Из того что последние полгода было нужно — Иллюстратор, Фотошоп, Лайтрум, Архикад, Ворд/Эксель/Поверпоинт. Что из этого легко поставить на Убунту? И это я еще не игроман, с играми все намного смешнее выходит.
В-третьих юзабилити. МС подрезал бюджет винды сравнительно недавно, и народ уже пищит. А в линухах никакого особого бюджета на UX никогда и не было. UX любого линуха по прежнему навевает вселенскую скуку и образы столлманов, жрущих мозоли, своей кустарщиной.
KP>на голову удобнее Windows.
Здравствуйте, kaa.python, Вы писали:
KP>Ну и ещё раз, серьёзный не-Windows проект ты просто не откроешь в VS. Скорее всего это будет монорепозиторий с Bazel, или CMake + Conan.
Здравствуйте, alex_public, Вы писали:
vaa>>пока еще браузер очень сильно ограничивает клиента в правах.
_>На самом деле уже давно нет. А если сравнивать скажем с мобильным (а не десктопным) приложением, то считай вообще почти одинаковый уровень возможностей (ну кроме некоторых достаточно специфических вещей).
Большая проблема браузера в том, что он на каждый чих запрашивает у пользователя разрешение и не запоминает их между сеансами. Это делает его намного неудобней обычных и мобильных приложений. Конечно это лучше, чем не иметь вообще АПИ, но всё равно недостаточно хорошо.
Здравствуйте, Serginio1, Вы писали:
S> Да но я не понимаю людей которые отказываются от VS в пользу консоли?
Так VS бесполезна (ну IDE как IDE, их как грязи сейчас), а консоль дает прямой доступ к разрабатываемой системе.
S> Это прежде всего отладка с кучей окон для мониторинга.
Это если тебе есть чего отлаживать отладчиком. Очень часто отлаживать под отладчиком можно разве что модульные тесты, в то время как отладка системы базируется на логах и модульных/интеграционных тестах.
S> Я пишу на C#. Это кроссплатформенный проект. И тема то как раз про него.
Могу только предположить что проект не взаимодействует достаточно много для того, что бы сделать отладку не возможной как класс.
S>как я уже писал отлаживать кроссплатформенный код проще в винде, а для уже отлаженного кода уже применять плюшки для линукса
Ну это прекрасно когда есть что отлаживать, а когда у тебя система распределённая, с несколькими потоками и еще и события постоянно генерируются внешние, ты просто не можешь поставить точки останова, т.к. она в корне меняет логику. Зачастую добавление одной лишней строки лога может сделать ошибку почти неуловимой, какой уж тут отладчик.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Во-первых железо. Если я ставлю более менее свежую винду на более менее свежее железо с более менее свежей периферией, то есть почти 100% гарантия того что все заработает с минимумом усилий. На линухе это до сих пор лотерея. В лучшем случае ты потратишь несколько дней на поиск драйверов, ядра и прочего стаффа, в худшем останешься без части железок.
Современная Убунта из коробки подхватывает вообще всё железо что есть. У меня на ноуте Убунта все сразу находит, а для Венды надо еще драйвера КАЧАТЬ и ставить В РУЧНУЮ. И это в 2022 году!
НС>Во-вторых софт. Из того что последние полгода было нужно — Иллюстратор, Фотошоп, Лайтрум, Архикад, Ворд/Эксель/Поверпоинт. Что из этого легко поставить на Убунту? И это я еще не игроман, с играми все намного смешнее выходит.
О, вот про это мне есть что сказать, как минимум про PS и C1 (ну или LR) Так вот, что на Windows, что на Ubuntu нормально работать с графикой очень геморно. Если хочешь делать что-то с графикой, то тебе без вариантов нужен macOS.
НС>В-третьих юзабилити. МС подрезал бюджет винды сравнительно недавно, и народ уже пищит. А в линухах никакого особого бюджета на UX никогда и не было. UX любого линуха по прежнему навевает вселенскую скуку и образы столлманов, жрущих мозоли, своей кустарщиной.
Так бубунтоделы особо и не думают про юзабилити, они просто из macOS тащат. А в macOS очень даже думают!
НС>Ага, главное себя в этом убедить.
Тут ты прав, я долго пытался себя убедить что "залезть на сайт производителя ПО, скачать инсталлятор, накликать ему кучу Ок, а потом не забывать периодически обновлять" это не хуже чем "sudo apt-get install bla-bla", но не смог.
Здравствуйте, Ночной Смотрящий, Вы писали:
KP>>Ну и ещё раз, серьёзный не-Windows проект ты просто не откроешь в VS. Скорее всего это будет монорепозиторий с Bazel, или CMake + Conan.
НС>А, опять чисто плюсовая боль.
Почему плюсовый? У меня сейчас проект несколько КК линий кода (там и C++, и Python, и Go и еще по мелочи), работа в монорепозитории. Как с этим в VS вообще совладать?
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Serginio1, Вы писали:
S>> Да но я не понимаю людей которые отказываются от VS в пользу консоли?
KP>Так VS бесполезна (ну IDE как IDE, их как грязи сейчас), а консоль дает прямой доступ к разрабатываемой системе.
Отладка в консоли это анахронизм! S>> Это прежде всего отладка с кучей окон для мониторинга.
KP>Это если тебе есть чего отлаживать отладчиком. Очень часто отлаживать под отладчиком можно разве что модульные тесты, в то время как отладка системы базируется на логах и модульных/интеграционных тестах.
Угу какой то сложный алгоритм нужно отладить в студии. Никто не пишет без ошибок.
И что бы понять где ошибка нужен стек вызова, значения переменных в каждом методе, список потоков итд
Нахрена мне консоль. Я выводом консоль даже в консольном приложении не пользуюсь.
Логи только для получения ошибок у клиентов.
S>> Я пишу на C#. Это кроссплатформенный проект. И тема то как раз про него.
KP>Могу только предположить что проект не взаимодействует достаточно много для того, что бы сделать отладку не возможной как класс.
Ну основное это облака. Там особо то нет специфики файловой системы итд. То ест базы данных,
S>>как я уже писал отлаживать кроссплатформенный код проще в винде, а для уже отлаженного кода уже применять плюшки для линукса
KP>Ну это прекрасно когда есть что отлаживать, а когда у тебя система распределённая, с несколькими потоками и еще и события постоянно генерируются внешние, ты просто не можешь поставить точки останова, т.к. она в корне меняет логику. Зачастую добавление одной лишней строки лога может сделать ошибку почти неуловимой, какой уж тут отладчик.
Почему не можешь? Переключаешься между потоками или их фризишь, точки останова с условием итд.
Еще раз конечно есть логи (в том числе бд) и есть программы для их анализа, но они нужны для отлова редко воспроизводимых ошибок. Для обычной отладки точек останова и стека вызова вполне достаточно.
А вот постоянно сидеть в консоли это анахронизм!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
KP>>Так VS бесполезна (ну IDE как IDE, их как грязи сейчас), а консоль дает прямой доступ к разрабатываемой системе. S> Отладка в консоли это анахронизм!
S> Угу какой то сложный алгоритм нужно отладить в студии. Никто не пишет без ошибок. S>И что бы понять где ошибка нужен стек вызова, значения переменных в каждом методе, список потоков итд S> Нахрена мне консоль. Я выводом консоль даже в консольном приложении не пользуюсь.
Вот как по мне, то что ты написал тут и есть анахронизм, я так в конце 2000-х писал
В современном мире, ты делишь сложный алгоритм на простые куски и для каждого простого куска пишешь юнит-тест. Потом собираешь куски в кучу, и пишешь еще один тест. Причем если сделать именно так, ты даже ни разу не откроешь отладчика, т.к. он просто не нужен.
S>Логи только для получения ошибок у клиентов.
Логи — это для отладки сложной, распределенной системы, поведение которой зависит от потоков данных.
S>>>как я уже писал отлаживать кроссплатформенный код проще в винде, а для уже отлаженного кода уже применять плюшки для линукса
Код хорошо покрытый тестами и логами в отладке не нуждается.
S> Еще раз конечно есть логи (в том числе бд) и есть программы для их анализа, но они нужны для отлова редко воспроизводимых ошибок. Для обычной отладки точек останова и стека вызова вполне достаточно.
А откуда взяться в коде просто воспроизводимым ошибкам, если он тестами покрыт? Ради интереса, у вашего проекта хотя бы 80% покрытие юнит-тестами есть?
KP>В современном мире, ты делишь сложный алгоритм на простые куски и для каждого простого куска пишешь юнит-тест. Потом собираешь куски в кучу, и пишешь еще один тест. Причем если сделать именно так, ты даже ни разу не откроешь отладчика, т.к. он просто не нужен.
Даа уж. Я так буду доолго писать! S>>Логи только для получения ошибок у клиентов.
KP>Логи — это для отладки сложной, распределенной системы, поведение которой зависит от потоков данных.
Не только. Прежде всего от кучи параметров и их сочетания. Это из NP-полная задача которую просто невозможно покрыть тестами.
S>>>>как я уже писал отлаживать кроссплатформенный код проще в винде, а для уже отлаженного кода уже применять плюшки для линукса
KP>Код хорошо покрытый тестами и логами в отладке не нуждается.
Напомню про NP-полная задача. Да и как ты собираешься покрывать например печать? отрисовку итд.
Как ты в тестах поймешь, что нарисовано, напечатано правильно? S>> Еще раз конечно есть логи (в том числе бд) и есть программы для их анализа, но они нужны для отлова редко воспроизводимых ошибок. Для обычной отладки точек останова и стека вызова вполне достаточно.
KP>А откуда взяться в коде просто воспроизводимым ошибкам, если он тестами покрыт? Ради интереса, у вашего проекта хотя бы 80% покрытие юнит-тестами есть?
Еще раз напомню про NP-полная задача. А на самом то деле они практически все такие. Слишком много параметров.
И на написание тестов уйдет больше времени, чем на написание программы!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
KP>>В современном мире, ты делишь сложный алгоритм на простые куски и для каждого простого куска пишешь юнит-тест. Потом собираешь куски в кучу, и пишешь еще один тест. Причем если сделать именно так, ты даже ни разу не откроешь отладчика, т.к. он просто не нужен. S> Даа уж. Я так буду доолго писать!
Зато цена поддержки сильно ниже и регрессии сразу отслеживаются, а не уже в проде. Что за хуяк-хуяк и в продакшн?
KP>>Логи — это для отладки сложной, распределенной системы, поведение которой зависит от потоков данных. S> Не только. Прежде всего от кучи параметров и их сочетания. Это из NP-полная задача которую просто невозможно покрыть тестами.
Всё можно покрыть тестами в достаточном объеме для предотвращения регрессий.
KP>>Код хорошо покрытый тестами и логами в отладке не нуждается. S> Напомню про NP-полная задача. Да и как ты собираешься покрывать например печать? отрисовку итд.
С печатью не уверен, но я бы попробовал печатать в PDF и сравнивать с ожидаемым образцом. Отрисовка — тут ничего не скажу, я вообще не спец по UI.
Подумал немного. Если говорить про печать, то сама фактическая печать это вызов 1-2 внешний API не имеющих отношения к твоей системе. В то время как подготовка данных для печати — это как раз логика работы твоего приложения. Если ты покроешь тестами подготовку данных, то саму печать (те самый 1-2 строчки кода) можно в тесте и проигнорировать. Всяко для UI приложения будет делаться минимальная регрессия в ручном режиме.
S>Как ты в тестах поймешь, что нарисовано, напечатано правильно?
В ряде случаев поможет сопоставление с образцом. В других случая — стоит спросить того кто и в современных методологиях разработки и в UI хорошо разбирается. Я ничего не могу про UI сказать.
S> Еще раз напомню про NP-полная задача. А на самом то деле они практически все такие. Слишком много параметров. S>И на написание тестов уйдет больше времени, чем на написание программы!
Нет, на написание тестов уйдет столько же времени, сколько и на написание программы, не больше, и это нормально. Так же не забываем про фаззинг, как раз для хитрой логики, которая может упасть на неожиданной комбинации входных данных.
Пока у меня ощущение, что если подход к разработке "хуяк-хуяк и в продакшн", то без отладчика никуда. Но так нельзя, так не возможно написать надежное и поддерживаемое приложение. И чсх, это делает утверждение "без VS не возможно разрабатывать" довольно забавным, я бы это переписал как "VS помогает говнокодить".
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Serginio1, Вы писали:
KP>>>В современном мире, ты делишь сложный алгоритм на простые куски и для каждого простого куска пишешь юнит-тест. Потом собираешь куски в кучу, и пишешь еще один тест. Причем если сделать именно так, ты даже ни разу не откроешь отладчика, т.к. он просто не нужен. S>> Даа уж. Я так буду доолго писать!
KP>Зато цена поддержки сильно ниже и регрессии сразу отслеживаются, а не уже в проде. Что за хуяк-хуяк и в продакшн?
KP>>>Логи — это для отладки сложной, распределенной системы, поведение которой зависит от потоков данных. S>> Не только. Прежде всего от кучи параметров и их сочетания. Это из NP-полная задача которую просто невозможно покрыть тестами.
KP>Всё можно покрыть тестами в достаточном объеме для предотвращения регрессий.
Не сможешь. На то они и NP-полная задача https://ru.wikipedia.org/wiki/NP-%D0%BF%D0%BE%D0%BB%D0%BD%D0%B0%D1%8F_%D0%B7%D0%B0%D0%B4%D0%B0%D1%87%D0%B0
KP>>>Код хорошо покрытый тестами и логами в отладке не нуждается. S>> Напомню про NP-полная задача. Да и как ты собираешься покрывать например печать? отрисовку итд.
KP>С печатью не уверен, но я бы попробовал печатать в PDF и сравнивать с ожидаемым образцом. Отрисовка — тут ничего не скажу, я вообще не спец по UI.
Угу нужно нарисовать все возможные образцы. Затем обучить нейронную сеть на сравнение картинок итд.
KP>Подумал немного. Если говорить про печать, то сама фактическая печать это вызов 1-2 внешний API не имеющих отношения к твоей системе. В то время как подготовка данных для печати — это как раз логика работы твоего приложения. Если ты покроешь тестами подготовку данных, то саму печать (те самый 1-2 строчки кода) можно в тесте и проигнорировать. Всяко для UI приложения будет делаться минимальная регрессия в ручном режиме.
Угу ну покрою я тестами и получу, что не так отрисовывает. И дальше в отладчик смотреть почему неправильно отрисовывает.
А это зависит от сотни, а то и тысячи параметров и алгоритмов. Библиотеки бывают ооочень сложными.
Иногда даже приходится лезть в чужой отдекомпилированный код, что бы понять почему и что не так.
S>>Как ты в тестах поймешь, что нарисовано, напечатано правильно?
KP>В ряде случаев поможет сопоставление с образцом. В других случая — стоит спросить того кто и в современных методологиях разработки и в UI хорошо разбирается. Я ничего не могу про UI сказать.
Проще посмотреть глазами и понять, что и как без юнит тестов. S>> Еще раз напомню про NP-полная задача. А на самом то деле они практически все такие. Слишком много параметров. S>>И на написание тестов уйдет больше времени, чем на написание программы!
KP>Нет, на написание тестов уйдет столько же времени, сколько и на написание программы, не больше, и это нормально. Так же не забываем про фаззинг, как раз для хитрой логики, которая может упасть на неожиданной комбинации входных данных.
Нет в сложных алгоримах ты не сможешь все покрыть. Это нереально. Там даже сочетание 2x интов может выдавать ошибку а если говорить о сотни то физически не сможешь даже дождаться окончания теста.
KP>Пока у меня ощущение, что если подход к разработке "хуяк-хуяк и в продакшн", то без отладчика никуда. Но так нельзя, так не возможно написать надежное и поддерживаемое приложение. И чсх, это делает утверждение "без VS не возможно разрабатывать" довольно забавным, я бы это переписал как "VS помогает говнокодить".
Я уже тебе написал, что многое просто невозможно покрыть тестами.
Ну и в итоге нашел ты ошибку, а дальше то надо понять почему она возникла. И здесь без отладки нужно анализировать, что и почему пошло не так.
Юнит тестами ты только найдешь входные параметры, а дальше уже идет перемалывание этих параметров кучей алгоритмов с кучей ветвлений итд.
Вот здесь то VS впереди планеты всей!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Ну и в итоге нашел ты ошибку, а дальше то надо понять почему она возникла. И здесь без отладки нужно анализировать, что и почему пошло не так. S>Юнит тестами ты только найдешь входные параметры, а дальше уже идет перемалывание этих параметров кучей алгоритмов с кучей ветвлений итд. S> Вот здесь то VS впереди планеты всей!
Я вот подумал, и ужаснулся. Ты ВООБЩЕ тесты не пишешь?!
Здравствуйте, kaa.python, Вы писали:
KP>Пока у меня ощущение, что если подход к разработке "хуяк-хуяк и в продакшн", то без отладчика никуда. Но так нельзя, так не возможно написать надежное и поддерживаемое приложение. И чсх, это делает утверждение "без VS не возможно разрабатывать" довольно забавным, я бы это переписал как "VS помогает говнокодить".
обычно, сколько вижу "здесь не покрыть тестами! здесь слишком сложный мок получается! здесь проще вх*ть шаблон БД с данными вручную и под дебагером тык-тык, разберемся быстро!" — это просто нежелание сесть, покурить примеры действительно сложных систем с изоляцией внешних сервисов в виде моков или стабов. Конечно, если система написана как-то так: procedure Button1Click(Sender: TObject); begin doSomeJob(false, false, 0, false, true, true, 0xDEADBEEF); if( state > 1 ) then doPrint(); end; то очень неохото привести в порядок. Ни в коем случае не утверждаю что у Serginio1 так и может и правда, в его системе вполне возможно прогнать все под отладчиком, но это только больше укрепляет веру в отладчик-всемогутор, до тех пор, пока его же система внезапно не будет встроена как микросервис в цепочке вызовов других сервисов и уже отладка если и будет возможна, то явно сложнее, чем почитать логи или тренироваться на моках
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Serginio1, Вы писали:
S>>Ну и в итоге нашел ты ошибку, а дальше то надо понять почему она возникла. И здесь без отладки нужно анализировать, что и почему пошло не так. S>>Юнит тестами ты только найдешь входные параметры, а дальше уже идет перемалывание этих параметров кучей алгоритмов с кучей ветвлений итд. S>> Вот здесь то VS впереди планеты всей!
KP>Я вот подумал, и ужаснулся. Ты ВООБЩЕ тесты не пишешь?!
Конечно пишу. Но просто невозможно покрыть все тестами. Кроме входных параметров нужно еще учитывать все состояние системы которые влияют на обработку этих параметров.
Ты вот полностью игнорируешь NP полные задачи.
Поделись опытом, как ты их тестируешь.
Еще раз ошибки есть в сторонних библиотеках. Как ты находишь ошибки в них?
Толку то, что ты нашел ошибку. Нужно понять почему она возникла. И входных параметров мало! Нужно еще и дамп памяти итд!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Отладка в консоли это анахронизм! S> А вот постоянно сидеть в консоли это анахронизм!
*facepalm*
Вместо того, чтобы упорно называть стандартную практику разработки в современном мире, лучше потратить немного времени, чтобы выглянуть из своего очень ограниченного мира Windows/VS программирования в весь остальной мир и посмотреть, как другие это делают. Думаю, пользы от такого занятия будет больше, ибо сможешь подсмотреть какие-то best practices и перенять их для себя.
Здравствуйте, Serginio1, Вы писали:
S> Ты вот полностью игнорируешь NP полные задачи. S> Поделись опытом, как ты их тестируешь. S> Еще раз ошибки есть в сторонних библиотеках. Как ты находишь ошибки в них?
kaa.python все правильно тут сказал, стоит прислушаться к его словам и подучить/подтянуть свои знания на тему как писать юнит тесты.
Здравствуйте, kaa.python, Вы писали:
KP>проще
Не соглашусь — это очень индивидуально.
У меня было несколько эпизодических задач, где требовалось написать небольшую утилитку, с условием, что она должна запускаться и работать в том числе под Linux.
Так как ничего платформ-специфичного не требовалось, я вполне успешно отлаживал всё под своей основной ОС (Windows) и, по сути, просто убеждался в работоспособности под Linux.
В такой ситуации поддерживать полноценную Linux-среду, разбираться в её инструментарии, переключаться (даже если это просто виртуальная машина), ... — ну вот никак у меня это не ассоциируется со словом проще.
KP>и надёжнее
Вот это — возможно, но опять же, если присутствует некая специфика платформы.
На сколько я понимаю, текущий WSL, это не просто хитрый промежуточный слой — это полноценная виртуальная среда с полноценным Linux (правда, своё, слегка допиленное ядро). Если не стоит каких-то сверх низкоуровневых задач, то отличия будут просто ничтожными.
Ну и я, с какой-то нестабильностью не сталкивался. Возможно, просто мало работал.
Здравствуйте, Serginio1, Вы писали:
S>Конечно пишу. Но просто невозможно покрыть все тестами. Кроме входных параметров нужно еще учитывать все состояние системы которые влияют на обработку этих параметров. S> Ты вот полностью игнорируешь NP полные задачи.
У меня нет таких задач (обычно, кажется...), а если бы и были, то всегда можно выделить достаточные для тестирования сценарии. И то что у тебя там нарисовано в веб сервере и напечатано тоже на такие задачи никак не тянет, так что мне не понятно зачем ты их тут вообще приплетаешь.
S> Еще раз ошибки есть в сторонних библиотеках. Как ты находишь ошибки в них? S>Толку то, что ты нашел ошибку. Нужно понять почему она возникла. И входных параметров мало! Нужно еще и дамп памяти итд!
Будут тесты которые покажут где конкретно падает и при каких входных данных. Будет лог который четко покажет как всё пошло не так. Почти всегда этого достаточно, в те редкие (меньше 1%, т.е. не каждый месяц даже) случае когда этого не достаточно, возьму корку со стеком вызовов в тесте, да погляжу что там пошло не так в одном маленьком, изолированном сценарии. В чем сложность? Не надо на всю систему глядеть, достаточно на очень небольшой сценарий. Мне думается, тебе и в правду было бы полезно заняться самообразованием, там всякие TDD и прочее. Ну нельзя же так работать, прогресс далеко шагнул, сильно дальше кропотливого изучения падения приложения в отладчике.
Здравствуйте, blacktea, Вы писали:
B>Здравствуйте, Serginio1, Вы писали:
S>> Отладка в консоли это анахронизм! S>> А вот постоянно сидеть в консоли это анахронизм!
B>*facepalm* B>Вместо того, чтобы упорно называть стандартную практику разработки в современном мире, лучше потратить немного времени, чтобы выглянуть из своего очень ограниченного мира Windows/VS программирования в весь остальной мир и посмотреть, как другие это делают. Думаю, пользы от такого занятия будет больше, ибо сможешь подсмотреть какие-то best practices и перенять их для себя.
У нас в студии есть окно вывода и куча других окон, что позволяет мониторить события.
Но главное это точки останова в критических местах, стек вызова и значения переменных.
Вот вопрос почему ты считаешь, что VS это отстой, а те кто не пользуются VS самые крутые перцы?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Serginio1, Вы писали:
S>>Конечно пишу. Но просто невозможно покрыть все тестами. Кроме входных параметров нужно еще учитывать все состояние системы которые влияют на обработку этих параметров. S>> Ты вот полностью игнорируешь NP полные задачи.
KP>У меня нет таких задач (обычно, кажется...), а если бы и были, то всегда можно выделить достаточные для тестирования сценарии. И то что у тебя там нарисовано в веб сервере и напечатано тоже на такие задачи никак не тянет, так что мне не понятно зачем ты их тут вообще приплетаешь.
Ну значит тебе вполне хватает консоли. На самом то деле многое зависит не от входных параметров, а от состояния системы.
Поэтому важнее дамп памяти. А что касается вэб сервера, то он занимается в том числе и печатью и еще кучей всего. Так сервис может состоять из сотни методов дергаемых клиентами.
И все это взаимосвязано. При этом есть взаимосвязь с кучей сторонних сервисов. И все это покрыть тестами невозможно!
Да создаются нагрузочные тесты, но можно упереться в сторонний сервис итд.
S>> Еще раз ошибки есть в сторонних библиотеках. Как ты находишь ошибки в них? S>>Толку то, что ты нашел ошибку. Нужно понять почему она возникла. И входных параметров мало! Нужно еще и дамп памяти итд!
KP>Будут тесты которые покажут где конкретно падает и при каких входных данных. Будет лог который четко покажет как всё пошло не так. Почти всегда этого достаточно, в те редкие (меньше 1%, т.е. не каждый месяц даже) случае когда этого не достаточно, возьму корку со стеком вызовов в тесте, да погляжу что там пошло не так в одном маленьком, изолированном сценарии. В чем сложность? Не надо на всю систему глядеть, достаточно на очень небольшой сценарий. Мне думается, тебе и в правду было бы полезно заняться самообразованием, там всякие TDD и прочее. Ну нельзя же так работать, прогресс далеко шагнул, сильно дальше кропотливого изучения падения приложения в отладчике.
Ну вот в итоге то тебе нужна отладка с точками останова, стеком вызова, оком потоков итд. Что и составляет основную задачу программиста!
А VS прекрасно для этого подходит!
А насчет образования поверь, я постоянно учусь невзирая на мои 58 лет. Если бы было все так просто, как ты пишешь, то ошибок не было бы ни у одной крупной компании. Однако чем больше проект, тем куча ошибок и куча обновлений с исправлениями ошибок.
А вот вам отвергающие студию явно нужно подучить её.
и солнце б утром не вставало, когда бы не было меня
RW>обычно, сколько вижу "здесь не покрыть тестами! здесь слишком сложный мок получается! здесь проще вх*ть шаблон БД с данными вручную и под дебагером тык-тык, разберемся быстро!" — это просто нежелание сесть, покурить примеры действительно сложных систем с изоляцией внешних сервисов в виде моков или стабов. Конечно, если система написана как-то так: procedure Button1Click(Sender: TObject); begin doSomeJob(false, false, 0, false, true, true, 0xDEADBEEF); if( state > 1 ) then doPrint(); end; то очень неохото привести в порядок. Ни в коем случае не утверждаю что у Serginio1 так и может и правда, в его системе вполне возможно прогнать все под отладчиком, но это только больше укрепляет веру в отладчик-всемогутор, до тех пор, пока его же система внезапно не будет встроена как микросервис в цепочке вызовов других сервисов и уже отладка если и будет возможна, то явно сложнее, чем почитать логи или тренироваться на моках
Ну логи то конечно есть и они анализируются. Куда же без них. Нашли ошибку решаем если возможно в студии. Или анализируя данные предполагаем решение,
если есть дамп памяти и без отладки можно решать кучу проблем. Вернее опять же в студии анализировать дамп памяти!
Опять же проще сначала отдельно оттестировать микросервис (не тратя время на запуск всей системы), а уж потом встраивается в систему с логами.
БбОльшая часть работы это точки останова, стек вызовов, окно вывода, потоки итд
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>У нас в студии есть окно вывода и куча других окон, что позволяет мониторить события. S>Но главное это точки останова в критических местах, стек вызова и значения переменных. S>Вот вопрос почему ты считаешь, что VS это отстой, а те кто не пользуются VS самые крутые перцы?
Начнем с того, что я нигде не утверждал, что VS отстой, это ты сам додумал. Во вторых, я нигде не говорил, что те, кто не пользуются VS самые крутые перцы. Мое утверждение было очень простым, что кроме отладки с использованием VS есть отдельный целый мир полный разных техник и методик отладки, часть из которых стали практически стандартом в крупных компаниях.
Здравствуйте, blacktea, Вы писали:
B>Здравствуйте, Serginio1, Вы писали:
S>>У нас в студии есть окно вывода и куча других окон, что позволяет мониторить события. S>>Но главное это точки останова в критических местах, стек вызова и значения переменных. S>>Вот вопрос почему ты считаешь, что VS это отстой, а те кто не пользуются VS самые крутые перцы?
B>Начнем с того, что я нигде не утверждал, что VS отстой, это ты сам додумал. Во вторых, я нигде не говорил, что те, кто не пользуются VS самые крутые перцы. Мое утверждение было очень простым, что кроме отладки с использованием VS есть отдельный целый мир полный разных техник и методик отладки, часть из которых стали практически стандартом в крупных компаниях.
Ну консоль то уж точно не является основной. Консоль один из множества инструментов.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, kaa.python, Вы писали:
KP>Современная Убунта из коробки подхватывает вообще всё железо что есть.
Практика показывает обратное, постоянно какие то проблемы.
KP>У меня на ноуте Убунта все сразу находит
Ну раз у тебя на ноуте, который, поди, специально под Убунту брался, значит у всех так, да?
KP>Так вот, что на Windows, что на Ubuntu нормально работать с графикой очень геморно.
Меня вполне устраивает и мои потребности покрывает на 100%.
KP> Если хочешь делать что-то с графикой, то тебе без вариантов нужен macOS.
Я изредка бываю в конторах, основной род деятельности которых — полиграфия и рекламная продукция. Везде винда. И, кстати, наблюдал как то мучения чувака, который пытался подружить макос и лазерный гравер. Но да, только макос, без вариантов.
KP>Так бубунтоделы особо и не думают про юзабилити, они просто из macOS тащат.
Здравствуйте, kaa.python, Вы писали:
KP>В современном мире, ты делишь сложный алгоритм на простые куски и для каждого простого куска пишешь юнит-тест. Потом собираешь куски в кучу, и пишешь еще один тест. Причем если сделать именно так, ты даже ни разу не откроешь отладчика, т.к. он просто не нужен.на п
20 лет назад, что характерно, были те же самые разговоры. Опять ищем серебряную пулю, один в отладчике, другой в логах. При том что совершенно очевидно, что бывают ситуации когда отладчик неудобен (на проде особо отладчиком не потыкаешь), бывают когда из логов не удается быстро понять что пошло не так (это не говоря о том, что в логике формирования логов тоже бывают ошибки). Поэтому хороший специалист умеет в нужной ситуации применять и анализ логов (и не только логов, а еще трейсов и метрик), и отладчик, выбирая наиболее эффективный в данной ситуации инструмент.
Еще вопрос — как из ненужности отладчика следует обязательная необходимость консоли? Ты логи исключительно в консоли грепом анализируешь?
Здравствуйте, vsb, Вы писали:
_>>На самом деле уже давно нет. А если сравнивать скажем с мобильным (а не десктопным) приложением, то считай вообще почти одинаковый уровень возможностей (ну кроме некоторых достаточно специфических вещей). vsb>Большая проблема браузера в том, что он на каждый чих запрашивает у пользователя разрешение и не запоминает их между сеансами. Это делает его намного неудобней обычных и мобильных приложений. Конечно это лучше, чем не иметь вообще АПИ, но всё равно недостаточно хорошо.
То, что запрашивает разрешения — это верно (хотя у мобильных приложений всё в точности так же, тут полное равенство).
А вот то, что не запоминает — это у тебя какие-то странные данные. У меня Firefox (да и Chrome, насколько я помню, ведёт себя точно так же) отлично хранит все настройки безопасности для каждого сайта отдельно. И никогда не требуется давать разрешения более одного раза. Так что ты тут что-то странное пишешь.
Здравствуйте, alex_public, Вы писали:
_>А вот то, что не запоминает — это у тебя какие-то странные данные. У меня Firefox (да и Chrome, насколько я помню, ведёт себя точно так же) отлично хранит все настройки безопасности для каждого сайта отдельно. И никогда не требуется давать разрешения более одного раза. Так что ты тут что-то странное пишешь.
Может что-то напутал... Сейчас проверил для web serial — вроде между перезапусками действительно запомнил разрешенный порт, хотя был уверен, что проверял это.
The web app can continue to save changes to the file without prompting until all tabs for that origin are closed. Once a tab is closed, the site loses all access. The next time the user uses the web app, they will be re-prompted for access to the files.
Т.е. у меня, скажем, есть юз-кейс. Мне надо мониторить определённую папку и при появлении в ней новых файлов что-то с ними делать. Сейчас для этого пользователю придётся при каждом открытии браузера выбирать эту папку заново. Это мягко говоря неудобно.
Здравствуйте, vsb, Вы писали:
vsb>Но вот например file api: https://web.dev/file-system-access/ vsb>The web app can continue to save changes to the file without prompting until all tabs for that origin are closed. Once a tab is closed, the site loses all access. The next time the user uses the web app, they will be re-prompted for access to the files. vsb>Т.е. у меня, скажем, есть юз-кейс. Мне надо мониторить определённую папку и при появлении в ней новых файлов что-то с ними делать. Сейчас для этого пользователю придётся при каждом открытии браузера выбирать эту папку заново. Это мягко говоря неудобно.
То, что ты процитировал — это описание пока ещё отсутствующего в стандарте API и соответственно оно реализовано не во всех браузерах. Так что применять эту штуку для коммерческого ПО в данное время невозможно, так что пока я даже и не в курсе деталей реализации этого дела.
Но при этом во всех современных браузерах уже много лет как есть другой (входящий в стандарт) способ работы с файлами, работающий без всяких проблем. Вот прямо сейчас у меня приложение (кстати целиком реализованное как один WebAssembly модуль) без проблем пишет и читает любые файлы из браузера, в том числе и из мобильных.
Однако ты прав, что на данный момент этот работающий метод требует от пользователя указывать файл для чтения/записи при каждой операции. Т.е. нельзя сохранить куда-то на сервер (или в куки) имя файла и потом прочитать его в следующей сессии — пользователь будет обязан выбрать его руками (в стандартном диалоге браузера) каждый раз заново. Это очевидно сделано по соображениям безопасности, и я сомневаюсь, что можно найти какое-то более разумное решение. Ну разве что сделать по аналогии с сайтами (типа сохранение разрешения на каждый уникальный путь в файловой системе) и то может какие-то уязвимости проскочат (например из-за ссылок).
И да, ты прав, что эта ситуация делает невозможным реализацию некоторых типов ПО. Но это очень узкая разновидность (типа файловых менеджеров или каких-то мониторов). Не говоря уже о том, что на некоторых современных операционках (iOS например) вообще можно сказать что нет файловой системы (для конечного пользователя естественно, а не внутри), но пользователям нормально... )))
Здравствуйте, e.thrash, Вы писали:
ET>Что-то всё меньше новых проектов пишут на шарпе. ET>Тенденция или я не туда смотрю?
ET>Кто занял долю проектов которые были на asp.net (mvc, core etc)?
ASP.NET MVC (вместе с рельсами и джангой) полностью вытеснена микросервисами на бэке и SPA (Angular, React, Vue и др.) на фронте.
У C# были 2 ниши:
1. Desktop, где он заменял Delphi и Visual Basic. В эпоху мобилильников и соцсетей больше неактуально. Там, где еще нужно — используют Qt (когда нужно сделать правильно) или Electron (когда надо лишь по-быстрому накидать толстый клиент).
2. Enterprise, где он предлагал новые фичи по сравнению с Java и поддержку технологий Microsoft (Office, SharePoint, SQL Server и т.д.). Второе сейчас не особенно нужно, везде сервера на Linux. А для первого придумали Kotlin, да и Java сейчас активно развивается (местами даже слишком).
Вакансии пока еще есть. Много дотнетчиков с опытом. Я бы сравнил положение скорее с Delphi начала 2010-х, когда оно еще бодро шевелилось. Вот лет через 7, наверно, можно будет хоронить.
Для новых проектов C# не дает никаких плюсов, чтобы предпочесть его другим языкам и платформам. Для высоконагруженных систем с Kubernetes, Kafka, Hadoop, ZooKeeper и прочим — однозначно рулит Java.
Может, мы обидели кого-то зря, cбросив пару сотен мегатонн.
А теперь горит и плавится земля — там, где был когда-то Пентагон.
WX>Для новых проектов C# не дает никаких плюсов, чтобы предпочесть его другим языкам и платформам. Для высоконагруженных систем с Kubernetes, Kafka, Hadoop, ZooKeeper и прочим — однозначно рулит Java.
Как раз в этом у C# есть преимущество https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharp.html
хотя говорят компилятор F# еще более оптимизирован за счет inline инструкции на уровне кода
но в целом, как яп конечно выиграет тот кто более гибок. например на F# есть такое https://sutil.dev/
новый уровень абстракции не в ущерб оптимизации. svelte js наиболее мощный во всеех смыслах фрэйворк, а F# позволяет
повесить на это строготипизированный DSL, C# пытается тянуться но его Razor template engine совсем не то же самое помножить если еще на размер бандлов blazor wasm.
действительно C# затачивался под winapi с их winforms и совсем не развивался.
А ведь когда-то MS спонсировало nemerle когда еще небыло scala kotlin clojure и прочего.
WX>Вакансии пока еще есть. Много дотнетчиков с опытом. Я бы сравнил положение скорее с Delphi начала 2010-х, когда оно еще бодро шевелилось. Вот лет через 7, наверно, можно будет хоронить.
Ну в отличии от Delphi .Net и C# активно развивается. Значительно активнее чем та же Java.
Это и компиляторы и более оптимального взаимодействия с нативным кодом.
Тот же блазор, когда надо писать только на одном языке как фронт так и энд.
Тот же Linq с деревьями выражений. Сейчас еще аналог макросов для генерации кода Генераторы источников
Delphi после того как борланд его продал сначала хотел зайти в .Net, но там не выдержал конкуренцию с C#. Заметь не выдержал конкуренцию и бейсик.
А в нативной части там конкурировать с С++ в связке с питоном тяжело.
C# не ждет участь Delphi по одной причине. За ним стоит крупнейшая компания. Так, что никуда он не денется
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Ну в отличии от Delphi .Net и C# активно развивается. Значительно активнее чем та же Java.
Fire-fire-fire!
S> Delphi после того как борланд его продал сначала хотел зайти в .Net, но там не выдержал конкуренцию с C#.
Как раз при Борланде они полезли в дотнет выпустив Delphi 8 for .NET. И это была самая провальная версия Delphi. После продажи, через пару лет, дотнет вообще выкинули из поставки т.к. нафик он не нужен был никому.
S> А в нативной части там конкурировать с С++ в связке с питоном тяжело.
S> C# не ждет участь Delphi по одной причине. За ним стоит крупнейшая компания. Так, что никуда он не денется
Шарп уже становится монстром похлеще крестов, куда ради сиюминутных выгод пытаются затянуть всего и побольше. Эта груда его и похоронит. Аминь.
Здравствуйте, rudzuk, Вы писали:
S>> C# не ждет участь Delphi по одной причине. За ним стоит крупнейшая компания. Так, что никуда он не денется R>Шарп уже становится монстром похлеще крестов, куда ради сиюминутных выгод пытаются затянуть всего и побольше. Эта груда его и похоронит. Аминь.
Ну так же говорили и по поводу Linq. Но народ перевернул свои мозги. Правда многие и не стали переворачивать, но прекрасно обходятся и без Linq.
Молодежь прекрасно учится и может понимать не только питон. А старикам типа меня очень полезно тренировать мозги.
А вот насчет мощности, то хочется еще больше! А кому сложно, для них есть питон!
Тут как говорится Каждому своё
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, scf, Вы писали:
vsb>>В том-то и дело. И если раньше у C# было естественное преимущество в виде десктопных приложений, то сейчас эта ниша исчезла.
scf>Я что-то пропустил и нативные приложения под винду теперь пишут не на шарпе?
scf>>Я что-то пропустил и нативные приложения под винду теперь пишут не на шарпе?
vsb>Да. Их не пишут.
Пишут. Просто под облака пишут значительно больше!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Worminator X, Вы писали:
WX>ASP.NET MVC (вместе с рельсами и джангой) полностью вытеснена микросервисами на бэке и SPA (Angular, React, Vue и др.) на фронте.
Абсолютно бессмысленная фраза. Можно сказать бредовая.
Здравствуйте, kaa.python, Вы писали:
KP>Ну вот в противоположной ситуации и используется. У тебя есть старый монолит на .NET, а душа требует микросервисов и облаков. В пылу попила ты же не будешь на Java переписывать?
А всё равно что я наблюдаю- монолит на жаве не пытаются распилить в смысле переиспользования кода, а переписывают куски с нуля на жаве. К примеру, в монолите Guice, а в микросервисах Spring Boot. Решение перейти на другой стек (с гугла на нетфликс)- не моё.
Здравствуйте, kaa.python, Вы писали:
KP>Код хорошо покрытый тестами и логами в отладке не нуждается.
Не всё можно хорошо покрыть юнит тестами. Бек можно. Алгоритмы в гуе можно. Но для гуя нужны ещё интеграционные тесты, и отладка очень даже нужна, чтоб понять, в каком состоянии оно не проходит тест / бросает ошибку.
Здравствуйте, e.thrash, Вы писали:
ET>Что-то всё меньше новых проектов пишут на шарпе. ET>Тенденция или я не туда смотрю?
ET>Кто занял долю проектов которые были на asp.net (mvc, core etc)?
наоборот, кол-во библиотек и фрейворков растет, правда все еще беднее чем в джаве(я про опенсорс).
ну и язык(C#) и среда(дельфи) разные вещи, C# это же прежде всего платформа.
Здравствуйте, Grizzli, Вы писали:
G>Здравствуйте, Михаил Романов, Вы писали:
МР>>- десктопные проекты да, на .Net если и появляются, то скорее в следовых количествах.
G>Потому что нет нормальной библиотеки кроссплатформенной от микрософта. чтобы и микрософт, и линукс был из коробки.
Здравствуйте, Grizzli, Вы писали:
G>Потому что нет нормальной библиотеки кроссплатформенной от микрософта. чтобы и микрософт, и линукс был из коробки.
Думаю, что проблема скорее в том, что ниша десктоп-приложений схлопывается в целом, а .Net здесь только повторяет общий тренд.
Здравствуйте, Михаил Романов, Вы писали:
МР>Думаю, что проблема скорее в том, что ниша десктоп-приложений схлопывается в целом, а .Net здесь только повторяет общий тренд.
Куда она схлопывается? речь не о игрушках же, а о рабочих приложениях.
Здравствуйте, Grizzli, Вы писали:
G>Это все сторонние поделки. В серьез в них вкладываться мало кто будет.
Подожди, но GtkSharp — это часть Mono, которое принадлежит и развивается Майкрософтом. Разве нет?
Кроме того, Avalonia — это очень популярный фреймворк, а не поделка. На нём пишется куча программ, оно развивается даже получше чем, как мы выяснили ранее уже майкрософтовский, GtkSharp.
Так что я бы не был столь категоричен.
Здравствуйте, Nuzhny, Вы писали:
N>Подожди, но GtkSharp — это часть Mono, которое принадлежит и развивается Майкрософтом. Разве нет?
Принадлежит да, а точно развивается?
N>Кроме того, Avalonia — это очень популярный фреймворк, а не поделка. На нём пишется куча программ, оно развивается даже получше чем, как мы выяснили ранее уже майкрософтовский, GtkSharp. N> Так что я бы не был столь категоричен.
Я это знаю. Но принят ли он общество как стандарт? Сторонние конторы аля defExpress клепают ли для него наборы своих контролов?
Ну и есть ли там хардварное ускорение отрисовки хотя бы на win и linux десктопе?
Здравствуйте, Grizzli, Вы писали:
N>>Подожди, но GtkSharp — это часть Mono, которое принадлежит и развивается Майкрософтом. Разве нет? G>Принадлежит да, а точно развивается?
Видимо, развивается со скоростью смены API в GTK. Ну и самое главное — это не сторонняя поделка, работает в том числе на Астра Линуксе. Что уже показатель.
G>Я это знаю. Но принят ли он общество как стандарт? Сторонние конторы аля defExpress клепают ли для него наборы своих контролов?
Для меня в основном С++ (ну и немного Питон) программиста очень странно звучат данные вопросы. Правильно ли я понимаю, что у себя в проектах ты используешь исключительно библиотеки, разработанные Майкрософтом? И ничего другого, даже популярного и всемирно известного, не допускается в проект?
Очень странно. А devExpress — это часть Майкрософта или исключение, сторонняя компания, софтом которой пользоваться можно?
G>Ну и есть ли там хардварное ускорение отрисовки хотя бы на win и linux десктопе?
Насколько я в курсе — да. Оно использует Skia от Гугла, а тот, в свою очередь, умеет GPU acceleration на туевой хуче платформ. Поэтому Avalonia даже на raspberry будет работать с ускорением.
N>Для меня в основном С++ (ну и немного Питон) программиста очень странно звучат данные вопросы. Правильно ли я понимаю, что у себя в проектах ты используешь исключительно библиотеки, разработанные Майкрософтом? И ничего другого, даже популярного и всемирно известного, не допускается в проект? N>Очень странно. А devExpress — это часть Майкрософта или исключение, сторонняя компания, софтом которой пользоваться можно?
ты не правильно понимаешь. есть некая технология. ну пускай, язык питон, коли ты его используешь. я спрашиваю, признан ли питон индустриальным стандартом? выпускают ли для питона серьезные сторонние производители наборы библиотек? Вот что я спрашиваю, но в контексте всех этих GUI библиотек для .net.
N>Насколько я в курсе — да. Оно использует Skia от Гугла, а тот, в свою очередь, умеет GPU acceleration на туевой хуче платформ. Поэтому Avalonia даже на raspberry будет работать с ускорением.
если так — то это хорошо. Графики будет быстро рисовать.
Здравствуйте, Grizzli, Вы писали:
G>ты не правильно понимаешь. есть некая технология. ну пускай, язык питон, коли ты его используешь. я спрашиваю, признан ли питон индустриальным стандартом? выпускают ли для питона серьезные сторонние производители наборы библиотек? Вот что я спрашиваю, но в контексте всех этих GUI библиотек для .net.
Так стандарта на GUI библиотеки нет. Они не даже не часть .Net Core (или уже есть такое?).
Есть более или менее стандартизированные средства разработки (язык + компилятор/интерпретатор + стандартная библиотека).
Далее куча народа пишет разные GUI библиотеки на самом языке или делает биндинги для сторонних библиотек. На Питоне я использую PyQt, например, оно ни разу не стандартное, но очень популярное, открытое, с хорошей документацией. Всё, этого мне достаточно.
И также с другими библиотеками. Например, для Питона есть scipy, numpy, pandas etc — это всё делается не теми людьми, которые развивают тот же CPython и сам язык, они имеют альтернативы (оооочень слабенькие). Но эти библиотеки популярны и открыты — все пользуются.
Что ещё надо? Я правда не понимаю.
Здравствуйте, Grizzli, Вы писали:
G> МР>- десктопные проекты да, на .Net если и появляются, то скорее в следовых количествах.
G> Потому что нет нормальной библиотеки кроссплатформенной от микрософта. чтобы и микрософт, и линукс был из коробки.
Да не по этому... Мне недавно потребовалось образ диска iso конвертировать в wim. Скачал первое попавшееся — filestar. Оказалось, что это чудо написано под .NET (не FW) с гуем на авалонии (там того гуя — прости господи — одно окошко). И весит вся эта радость в районе 160Mb (очень приблизительно) и стартует по-дотнетовски неспешно При таких раскладах, нужно быть совсем отбитым, чтобы под десктоп писать на этом...
Здравствуйте, Grizzli, Вы писали:
G>Здравствуйте, vaa, Вы писали:
vaa>>А смысл? blazor нужен как замена реакту — UI рисовать, там скорость не особо нужна.
G>Ну как сказать, графики, таблицы по большим выборкам данных.
вроде бы движок js хрома умеет jit, не уверен, что в ВМ, которая работает внутри браузера как плагин
обгонит js на родном для браузере движке.
да и таблицы пока еще сильно шустрее и богаче на js https://www.datatables.net/
Здравствуйте, vaa, Вы писали:
vaa>хотя говорят компилятор F# еще более оптимизирован за счет inline инструкции на уровне кода vaa>но в целом, как яп конечно выиграет тот кто более гибок. например на F# есть такое https://sutil.dev/
Ни один вменяемый архитектор никогда не станет использовать F# в продакшене.
Кровавый энтерпрайз пишется толпами индусов-макак, легко взаимозаменямых.
Код с монадами и каррированием в принципе не поддается рефакторингу и с архитектурной точки зрения является УГ.
Может, мы обидели кого-то зря, cбросив пару сотен мегатонн.
А теперь горит и плавится земля — там, где был когда-то Пентагон.
Здравствуйте, Serginio1, Вы писали:
S>C# не ждет участь Delphi по одной причине. За ним стоит крупнейшая компания. Так, что никуда он не денется
Этой крупной компании свойственно хоронить свои же устаревшие технологии. Где сейчас FoxPro? Где COM/DCOM/AvtiveX? А SOAP и MFC насколько активно развиваются? Вот и .NET похоронят. Не сразу, конечно.
Может, мы обидели кого-то зря, cбросив пару сотен мегатонн.
А теперь горит и плавится земля — там, где был когда-то Пентагон.
Здравствуйте, Worminator X, Вы писали:
WX>Очень аргументированно. На HH.RU и смотрим, сколько вакансий с микросервисами и сколько с монолитами на ASP.NET MVC, RoR и др.
И вот еще одна .
Здравствуйте, e.thrash, Вы писали:
ET>Тенденция или я не туда смотрю?
Что меня удивляет, так это Python. Это хороший язык, но и педаль тормоза хорошая, проги на нем зачастую никуда не спешат. Почему тогда его использование растет? Получается, что большая часть открытых проектов на GitHub сделана в стиле "периодического подкручивания небыстрых костылей" на питоне во благо ненапряга?
Здравствуйте, Aquilaware, Вы писали:
A>Что меня удивляет, так это Python. Это хороший язык, но и педаль тормоза хорошая, проги на нем зачастую никуда не спешат. Почему тогда его использование растет? Получается, что большая часть открытых проектов на GitHub сделана в стиле "периодического подкручивания небыстрых костылей" на питоне во благо ненапряга?
Здравствуйте, Grizzli, Вы писали:
G>Здравствуйте, Михаил Романов, Вы писали:
МР>>- десктопные проекты да, на .Net если и появляются, то скорее в следовых количествах.
G>Потому что нет нормальной библиотеки кроссплатформенной от микрософта. чтобы и микрософт, и линукс был из коробки.
Никому нафиг этот "кроссплатформ" не упал! Пара красноглазиков бегает по форумам, ждут халявы, которую MS напишет им забесплатно. ШАЗ!
У адекватных коммерческих разрабов есть WinForms, WPF + куча сторонних библиотек. Вот они и пишут весь нормальный софт.
Здравствуйте, Baiker, Вы писали:
B>Никому нафиг этот "кроссплатформ" не упал! Пара красноглазиков бегает по форумам, ждут халявы, которую MS напишет им забесплатно. ШАЗ! B>У адекватных коммерческих разрабов есть WinForms, WPF + куча сторонних библиотек. Вот они и пишут весь нормальный софт.
Фотошоп относится к нормальному коммерческому софту? Он есть и на MacOS, и на iOS. Или думаешь, что эти две версии убыточны?
Здравствуйте, Михаил Романов, Вы писали:
МР>Здравствуйте, Лось Чтостряслось, Вы писали:
МР>>>- Xamarin кажется, что так и не набрал сколько-нибудь заметную популярность. ЛЧ>>потому что есть лютое говно МР>А в чем это проявляется?
Я б сказал, что у Xamarin на какое-то время мог б быть шанс, если б судьба windows phone была б другой. Ибо три ОСи больше заставили б задуматься о межплатформенности, чем две, и при этом совместимость со стандартным SDK для windows phone. Я б даже заинтересовался хоть малость ходовой межплатформенный средой с java/kotlin под iOS или swift под android. Но про второй вариант я вообще ни разу не слышал, про первый — что-то слышал, но тот, похоже, распространённым не стал даже в самой малейшей степени.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, kaa.python, Вы писали:
KP>>В современном мире, ты делишь сложный алгоритм на простые куски и для каждого простого куска пишешь юнит-тест. Потом собираешь куски в кучу, и пишешь еще один тест. Причем если сделать именно так, ты даже ни разу не откроешь отладчика, т.к. он просто не нужен.на п
... НС>Еще вопрос — как из ненужности отладчика следует обязательная необходимость консоли? Ты логи исключительно в консоли грепом анализируешь?
А это прямо удивительный вопрос — если размер файла превышает 20-30% от количества оперативной памяти, я б даже пробовать не стал б открывать его в GUI-редаторе, по крайней мере, польностю. Ну разве что объём RAM лишь немногим меньше терабайта, тогда да, 100-гигабайтный log редко бывает нужно смотреть, но если комп с меньшими возможностями, то из редакторов — только vim, и для поиска всяке из командной строки. Разве чт кусок можно посмотреть в GUI-редкаторе, к примеру, в macOS можно написать так: sed -n <from>,<to>p | pbcopy.
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, e.thrash, Вы писали:
vaa>Какая участь? Непонятно. vaa>https://delphi.embarcadero.com/ vaa>Участь быть продуктом который изменит мир разработки навсегда как дельфи? vaa>Ну тут заслуга не только языка, но прежде всего IDE. vaa>Так что еще вопрос: что все таки сравниваем? Языки, технологии, инструменты?
vaa>Чтобы предсказать нужно моделировать развитие.
vaa>Если учесть, что C# и дельфи разрабатывал Anders Hejlsberg возможно. vaa>Если случится чудо и возникнут квантовые ПК возможно. vaa>Это работа для теории динамической информации.
Delphi, я сшылал, и врямпь возрождаться стал. Но вот в чём он изменил мир разработки, я не в курсе. Если, конечно, подразумевается что-то сопоставимое с git или хотя б docker по значимости.
Здравствуйте, Ватакуси, Вы писали:
ET>>Что-то всё меньше новых проектов пишут на шарпе.
...
В>... предсказывать что-либо сложно, но думаю, что из-за сложности языка молодёжь (и новые проекты) пойдут в питон и яву-скрипт.
Вот эта тенденция мне очень хорошо видна. А соотношение C#/Java по моим наблюдениям, сколько помню, в основном колеблется около какой-то средней величины с примерно постоянной дисперсией.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, rudzuk, Вы писали:
S>>> C# не ждет участь Delphi по одной причине. За ним стоит крупнейшая компания. Так, что никуда он не денется R>>Шарп уже становится монстром похлеще крестов, куда ради сиюминутных выгод пытаются затянуть всего и побольше. Эта груда его и похоронит. Аминь. S> Ну так же говорили и по поводу Linq. Но народ перевернул свои мозги. Правда многие и не стали переворачивать, но прекрасно обходятся и без Linq. S>Молодежь прекрасно учится и может понимать не только питон. А старикам типа меня очень полезно тренировать мозги. S> А вот насчет мощности, то хочется еще больше! А кому сложно, для них есть питон! S> Тут как говорится Каждому своё
Linq-то появился во времена, когда в C# реально появлялись передовые новшества. Но с версии 4.5, т. е. через 10 лет, появилось лишь где-то полтора полезных новшества — нечто, именуемое pattern matching, не знаю точно, что всё-таки было действительно реализовано, а не осталось в далёких планах где-то на горизонте из раздела сложного в реализации; ну и использование non-nullable references наконец-то появилось. В остальном новые версии дополнялись лишь огромным набором синтаксических извращений, для сравнения п мне basic, особенно, ранний больше подойдёт, в котором с унификацией синтаксиса, видать, не заморачивались.
Хотя, на обсуждаемую тему не очень похоже, чтоб это хоть малость влияло, ибо — а где иначе — может, могло б быть в D, о котором, видать, скоро уже почти все забудут, а в java вроде так и нет non-nullable references, их optional в первоначальном виде не считается? А в самом полярном я вообще достоинств не вижу, в таком сравнении и ранний Delphi был б ничего, уж ни по этой ли причине теперь оный возрождаться стал.
Здравствуйте, Ilya81, Вы писали:
I>А это прямо удивительный вопрос — если размер файла превышает 20-30% от количества оперативной памяти, я б даже пробовать не стал б открывать его в GUI-редаторе, по крайней мере, польностю.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Ilya81, Вы писали:
I>>А это прямо удивительный вопрос — если размер файла превышает 20-30% от количества оперативной памяти, я б даже пробовать не стал б открывать его в GUI-редаторе, по крайней мере, польностю.
НС>Ты тоже никогда кибану не видел?
Это нечто с у'web'щным интерфейсом? Если оно, то по мне vim лучше.
Здравствуйте, Ilya81, Вы писали:
I>Это нечто с у'web'щным интерфейсом? Если оно, то по мне vim лучше.
Ты только что жаловался, что с большими логами проблема. Я уж не говорю про такие "мелочи" как то, что при наличии HA тебе даже для одного сервиса придется логи по немкольким машинам собирать, я уж не говорю про сквозной анализ по всем сервисам. Так что удачи тебе с vim.
При таких раскладах, нужно быть совсем отбитым, чтобы под десктоп писать на этом...
