Отмечу, что этот "идиотизм" многократно повторен по спирали, и сейчас его менее продвинутые версии (которыми еще только все это предстоит) известны как protobuf, thrift, и прочие RPC.
K>Да и так, в целом, откуда пишутся такие монструё****бища, которым мало 4ГБ в проекте? Ну не засовывают же они в один солюшен сотни проектов! (это у меня теплится последняя надежда на интеллект разрабов) K>Сколько приложений ни пишу, ну никак не получается заструячить в солюшен больше 3 проектов! (остальные подцепляются чисто как DLLки)
Чтоб два раза не вставать. Во всех больших конторах solution'ы столь велики, что содержал заведомо больше "проектов" чем их даже возможно просто скачать на компьютер разработчика.
И занимаются разработкой не один, а тысячи.
Здравствуйте, Nuzhny, Вы писали:
N>По факту, это совсем разный уровень. Например, тогдашняя база для проверки качества OCR — MNIS уже много лет считается слишком простой для алгоритмов. И если выходит алгоритм, протестированный только на ней, то его критикуют. Уже давно качество на MNIST 99.999%. Так что не стоит сравнивать. N>Так и во всем: по факту объем исходников вырос на порядок, сложность компиляции сильно выросла из-за шаблонов, подсказки стали на порядок умнее. Но нет, ресурсов на все это нам жалко.
А главное, для распознавания подавай сканы в высоком разрешении, т.к. с низким, как в 90-е, софт не справится. Ой.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, bnk, Вы писали:
K>>Да и так, в целом, откуда пишутся такие монструё****бища, которым мало 4ГБ в проекте? Ну не засовывают же они в один солюшен сотни проектов! (это у меня теплится последняя надежда на интеллект разрабов)
bnk>Я сам четыре года собирал солюшен в котором было 70 проектов.
Я вот про такие "гиперсолюшены" и говрю — нахрена?? Неужели ты правишь все 70 проектов, что тебе нужны все их исходники?
Очевидно, что из 70 проектов, лично ты ответственнен только за часть. И даже из этой части, некоторые проекты уже допилены или по кр. мере не требуют вмешательства — их выносим в простые DLLки и референсим.
И повторюсь, даже просто как человек, ты не в состоянии править 10 проектов сразу. Тогда зачем держать их в виде сорсов? Если возникнет ошибка, студия всё равно откроет тебе их сорсы.
Здравствуйте, SkyDance, Вы писали:
K>> Надеюсь, идиотизм типа 'COM' таки выпилен?
SD>Отмечу, что этот "идиотизм" многократно повторен по спирали, и сейчас его менее продвинутые версии (которыми еще только все это предстоит) известны как protobuf, thrift, и прочие RPC.
COM вообще не про RPC, ты ничего не напутал??
K>>Да и так, в целом, откуда пишутся такие монструё****бища, которым мало 4ГБ в проекте? Ну не засовывают же они в один солюшен сотни проектов! (это у меня теплится последняя надежда на интеллект разрабов) K>>Сколько приложений ни пишу, ну никак не получается заструячить в солюшен больше 3 проектов! (остальные подцепляются чисто как DLLки)
SD>Чтоб два раза не вставать. Во всех больших конторах solution'ы столь велики, что содержал заведомо больше "проектов" чем их даже возможно просто скачать на компьютер разработчика. SD>И занимаются разработкой не один, а тысячи.
Ерунда. Проектов на ТЫСЯЧИ разрабов — едва ли не десяток на весь мир. Я именно про разрабов, а не околопроектную шушару. И очевидно, любой (правильно спроектированный!) проект разделяется на подмодули, где никакими "тысячами разрабов" и не пахнет. Каждый пилит свой модуль, который при правильном интерфейсе с системой, не нуждается в десятках других проектов. Чем лучше разделяешь функции модулей, тем более они независимы и реюзабельны. И снова мы приходим к тому, что разрабу вообще нафиг не упёрлись "десятки проектов в солюшене" — достаточно иметь несколько своих проектов (опять же, не все в виде сорсов!) + интеграционные.
Ну и?? Снова вопрос про безалаберные солюшены с сотнями проектов — ЗАЧЕМ??
Здравствуйте, Евгений Музыченко, Вы писали:
N>>подсказки стали на порядок умнее.
ЕМ>Где можно увидеть тот порядок? Я много сравнивал VS 2019 с VS 2008, но качественной разницы в IntelliSense и подсказках не увидел.
Подтверждаю. Мелкомягкие за 20(!) лет студии чем только не занимались, но только не качеством подсказок! Как был тупой список всего, что только можно вкорячить, таким и остался.
Контекст? Не, не слышали! Локальные переменные? Да нафиг ты нам упёрся со своими сложностями — ищи их в общем списке!
Сами мелкомягкие сознались (в одном из моих issues), что текущий механизм — плохой и его будут переделывать (включая абсолютно идиотскую идею контекстного меню "только на расширение").
Собственно, я потому и взялся однажды заменить этот бардак собственным механизмом — не тут-то было! Оказывается, ты можешь только ДОПОЛНЯТЬ интеллисенс, но не заменять!! Как до такого вообще можно было додуматься?????
Бестолковый механизм интеллисенса + такой же бестолковый метод его наполнения = "современная IDE, помогающая разработчику". Позорники!
Здравствуйте, Kolesiki, Вы писали:
K>>>Да и так, в целом, откуда пишутся такие монструё****бища, которым мало 4ГБ в проекте? Ну не засовывают же они в один солюшен сотни проектов! (это у меня теплится последняя надежда на интеллект разрабов)
bnk>>Я сам четыре года собирал солюшен в котором было 70 проектов.
K>Неужели ты правишь все 70 проектов, что тебе нужны все их исходники?
Нет конечно
Просто "здесь так принято". Исторически сложилось. Никто уже и не вспомнит зачем там все эти проекты и что они вообще делают.
Но наверное зачем-то нужны. К тому же вся эта хрень завязана на систему сборки и деплоя. Которой занимается другой отдел.
Да, речь не про плюсы, если что.
COM это и есть RPC (а если добавить D, чтоб получился DCOM, так это еще и out-of-process, и даже как бы cross-machine RPC).
K>Ерунда. Проектов на ТЫСЯЧИ разрабов — едва ли не десяток на весь мир.
Во-первых, намного больше.
Во-вторых, именно эти проекты и тащат за собой больше всего денег.
K>Ну и?? Снова вопрос про безалаберные солюшены с сотнями проектов — ЗАЧЕМ??
Потому что сделать хорошую модульную архитектуру, решение с multi-repo (а не mono-repo на десятки и сотни гигабайт исходников) намного _СЛОЖНЕЕ_ чем научить IDE работать с огромными помойками на тысячи и десятки тысяч проектов.
Здравствуйте, Nuzhny, Вы писали:
N>Тебя же не удивляет, что, например, тепловыделение процессоров зависит от их частоты в кубе? Почему такого не может быть в софте? Небольшие усложнения вполне могут требовать ресурсов на порядки больших.
Зависимость тепловыделения от частоты — объективный закон природы, не людьми придуманный. А программирование — дисциплина, полностью созданная людьми, поэтому рост требований к ресурсам на порядки из-за небольших усложнений — это либо лень, либо криворукость, третьего не дано.
Здравствуйте, RonWilson, Вы писали: KP>>О, изменение в иконках второе по важности после перевода на 64 бита. Да я смотрю МС все забавнее и забавнее RW>К черту x64, иконки — вот что важно, лучше бы они еще и были не просто битмапы, а прямо вот каждая кнопка — отдельное виндовой окошко с OpenGL поверхностью и чтобы иконки медленно врощались при наведении курсора. Ну или хотя бы мигали:
Вот вы смеётесь, а в интерфейсе можно бесконечно скруглять и раскруглять углы, и каждый раз про это писать анонс. MS сейчас только этим и занимается. Как оно при этом умудряется ломать очередные апдейты операционки — йанипанимаю.... И это нифига не смешно.
Я 2019 уже не ставлю, потому что нет вменяемой возможности установить и зарегаться в ней офф-лайн. И как я понимаю, лучше не стало, с учётом упоминаний team-а.
Скрытый текст
Не, я конечно поставлю 2022 посмотреть, что нового для простого юзера, но особых надежд не питаю. У меня есть небольшой пользовательский опыт, я сам (недо)писал редактор кода, плотно использовал VS и Idea, замучив всех друзей-пользователей того и другого вокруг на тему юзабилити, сам маньячно истыкал мышкой обе IDE, и у меня пока грустные выводы. Был бы я умным и не рукожопым, я бы доделал свой редактор и сделал свою IDE. Проблема для меня в навигации по проекту. Когда проект/файлы разрастаются, даже при хорошем порядке в коде и голове, часто приходится долго позиционироваться в нужные места.
Здравствуйте, CEMb, Вы писали:
CEM>Вот вы смеётесь, а в интерфейсе можно бесконечно скруглять и раскруглять углы, и каждый раз про это писать анонс. MS сейчас только этим и занимается. Как оно при этом умудряется ломать очередные апдейты операционки — йанипанимаю.... И это нифига не смешно.
Операционки еще ладно, подумаешь — машина вообще перестала загружаться на этот случай как раз их храню актуальный Windows Image Backup, чтобы за минут пять откатить на работающую, а не мучаться с профанацией restore point. Вот когда ломают в своих обновлениях компилятор, это уже точно не смешно.
Здравствуйте, SkyDance, Вы писали:
SD>Отмечу, что этот "идиотизм" многократно повторен по спирали, и сейчас его менее продвинутые версии (которыми еще только все это предстоит) известны как protobuf, thrift, и прочие RPC.
А в чем там проблема-то?
Вот есть protobuf, открытая технология, позвлояет сохранять сложные структуры в бинароном виде и пересылать их.
В чем тут "идиотизм" и какая здоровая альтернатива?
Здравствуйте, Nuzhny, Вы писали:
N>О, я легко замечаю. Раньше подсказки путались в простейших шаблонах, сейчас они более в контексте и вывозят везде, вообще везде. Шаблоны, auto — легко. Вот я пишу код и реально радуюсь подсказкам. Для сравнения у меня проекты кроссплатформенные и пишутся параллельно на Линуксе в Qt Creator — у него заметно хуже с этим, но при этом он заметно легче и работает быстрее.
clang backend попробуй. Медленее, но разбирает всё.
Здравствуйте, SkyDance, Вы писали:
SD>Потому что сделать хорошую модульную архитектуру, решение с multi-repo (а не mono-repo на десятки и сотни гигабайт исходников) намного _СЛОЖНЕЕ_ чем научить IDE работать с огромными помойками на тысячи и десятки тысяч проектов.
Поменять сложившуюся архитектуру большого проекта в энерпрайзе нужны стальные яйца, политический вес и железная воля. Далеко не всегда все это есть в одном месте. Поэтому да, проще докупить железа и допилить IDE.
S>Поменять сложившуюся архитектуру большого проекта в энерпрайзе нужны стальные яйца, политический вес и железная воля. Далеко не всегда все это есть в одном месте. Поэтому да, проще докупить железа и допилить IDE.
Здравствуйте, SkyDance, Вы писали:
K>>COM вообще не про RPC, ты ничего не напутал??
SD>COM это и есть RPC (а если добавить D, чтоб получился DCOM, так это еще и out-of-process, и даже как бы cross-machine RPC).
С таким же успехом и овёс можно считать чем-то относящимся ко скачкам.
Ключевой момент COM — модульные приложения, где каждый модуль — чёрный ящик, у которого можно спросить интерфейсы. Remote там никаким боком, там ключевое — Component.
K>>Ну и?? Снова вопрос про безалаберные солюшены с сотнями проектов — ЗАЧЕМ??
SD>Потому что сделать хорошую модульную архитектуру, решение с multi-repo (а не mono-repo на десятки и сотни гигабайт исходников) намного _СЛОЖНЕЕ_ чем научить IDE работать с огромными помойками на тысячи и десятки тысяч проектов.
Вообще не понимаю, к чему ты это приплёл.
Когда у тебя есть громадный проект, он всё равно ДАЖЕ ФИЗИЧЕСКИ состоит из кучи независимых вещей. Та же IDE — кажется большой, но на деле остоит из ядра и плагинов. Ну и накой тысячу проектов лепить в один солюшен, если ты всё равно пишешь ОДИН плагин и пару связанных проектов рядом?? Никто и никогда не работает с сотней проектов, просто мозгов не хватит. А если они ещё и взаимозависимы, то это вообще жопа, а не архитектура.
Здравствуйте, StatujaLeha, Вы писали:
SL>Вот есть protobuf, открытая технология, позвлояет сохранять сложные структуры в бинароном виде и пересылать их. SL>В чем тут "идиотизм" и какая здоровая альтернатива?
Протобуф придумали гугловские долбоклюи. Для начала, это БИНАРНАЯ хрень. Т.е. сразу отсекаем вменяемый дебаг, логи и т.п. Затем, сама идея: отдельным инструментом генерить сериализатор и потом тщательно следить за его актуальностью.
Альтернатива? JSON, конечно! Несмотря на избыточность с т.з. процессора или сети, даёт гигантскую интероперабельность! Не нужно изобретать никаких Corba, DCOM, REST и прочую ересь, да ещё и оглядываться на совместимость little/big-endian. Просто юзаешь JSON-RPC и имеешь все благá мира.
Здравствуйте, licedey, Вы писали:
L>Ожидается, что 64-разрядная версия Visual Studio 2022 Preview 1 появится летом 2021-го. Финальный релиз планируется выпустить ближе к концу года.
Здравствуйте, Kolesiki, Вы писали:
K>Протобуф придумали гугловские долбоклюи. Для начала, это БИНАРНАЯ хрень. Т.е. сразу отсекаем вменяемый дебаг, логи и т.п. Затем, сама идея: отдельным инструментом генерить сериализатор и потом тщательно следить за его актуальностью.
K>Альтернатива? JSON, конечно! Несмотря на избыточность с т.з. процессора или сети, даёт гигантскую интероперабельность! Не нужно изобретать никаких Corba, DCOM, REST и прочую ересь, да ещё и оглядываться на совместимость little/big-endian. Просто юзаешь JSON-RPC и имеешь все благá мира.
Так плюс protobuf — это эффективность: т.е. минимальные дополнительные издержки на передачу структурированного объекта из одного места в другое.
А у JSON-а будет в этом плане дикий оверхед: как в плане объема данных, так и по производительности(разбор полученной структуры сложнее, чем десериализация).
Пока мне видится, что оба решения найдут свою нишу.
Если у Вас появится необходимость слать много сообщений с одного компьютера(скажем, 100к/сек), то разве Вы сходу возьмете JSON, не взглянув на protobuf?
Как до такого вообще можно было додуматься????? 
Позорники!
почему-то шрифт стал каким-то пухлым:
