Здравствуйте, 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# это же прежде всего платформа.
