На моей рабочей машине VS2010 стартует 12 секунд. WTF? К тому же при установке этот подлец поставил себя как viewer С++ файлов.
Это какой-то эксперимент на живых людях. Кто-нибудь может внятно объяснить преимущества использования .NET для Visual Studio и в частности на кой там упал этот WTF (в смысле WPF)?
Я понимаю что нужен некий клеевой язык для того чтобы кучу добра склеить вместе. Но оно же бувально не едет в том виде что сделан.
Скажем я сравниваю со своим ScIDE (sciter based IDE: html/css/script + scintilla) — загрузка примерно того же UI по объему 200-400ms.
Я серьёзно не понимаю смысл этого безобразия. Типа надо же хотя бы куда-то это пристроить?
Ну есть же у них команда делающая тот же Office... Который в плане UI даже покруче-то будет.
Ну не понимаю я. Меня как и всех остальных пользователей авторы Visual Studio явно не уважают.
CS>На моей рабочей машине VS2010 стартует 12 секунд. WTF? К тому же при установке этот подлец поставил себя как viewer С++ файлов. CS>Это какой-то эксперимент на живых людях. Кто-нибудь может внятно объяснить преимущества использования .NET для Visual Studio и в частности на кой там упал этот WTF (в смысле WPF)? CS>Я понимаю что нужен некий клеевой язык для того чтобы кучу добра склеить вместе. Но оно же бувально не едет в том виде что сделан.
CS>Скажем я сравниваю со своим ScIDE (sciter based IDE: html/css/script + scintilla) — загрузка примерно того же UI по объему 200-400ms.
Вообще-то, насколько я понимаю, там далеко не только UI загружается
M>>Вообще-то, насколько я понимаю, там далеко не только UI загружается
N>Возможно. Но для просмотра одного единственного cpp или xml могли бы сделать что-нибудь побыстрее.
Даже для одного файла требуется много всего — то же подсветка или автодополнятель тэгов. Плю не факт, что, открыв один файл, ты не захочешь потом открыть и солюшн какой-нить
Здравствуйте, Mamut, Вы писали:
M>Даже для одного файла требуется много всего — то же подсветка или автодополнятель тэгов. Плю не факт, что, открыв один файл, ты не захочешь потом открыть и солюшн какой-нить
VAX на более старой студии умеет это всё и грузится не в пример быстрее.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Jack128, Вы писали:
N>>Но для просмотра одного единственного cpp или xml могли бы сделать что-нибудь побыстрее.
J>А зачем ты используешь для просмотра одного cpp или xml файла VS?? Чем Notepad++/IE не устраивает??
Notepad++ у меня даже не установлен. Scintilla есть, но студию для этого использовать как-то логичней.
IE не устраивает, так как xml надо иногда и поправить, а в студии делать это удобней. Плюс в ней есть автоформатирование xml. Мне она нравится почти всем, но вот тормоза...
Здравствуйте, c-smile, Вы писали:
CS>На моей рабочей машине VS2010 стартует 12 секунд. WTF? К тому же при установке этот подлец поставил себя как viewer С++ файлов.
Не нравится — удали.
CS>Это какой-то эксперимент на живых людях. Кто-нибудь может внятно объяснить преимущества использования .NET для Visual Studio и в частности на кой там упал этот WTF (в смысле WPF)?
Не можете спокойно жить в мире, где программисты использует .Net там, где он удачно подходит? Постоянно меряетесь пиписьками с аргументами "какого MS не использует свои технологии"? Ну так получайте и наслаждайтесь.
CS>Скажем я сравниваю со своим ScIDE (sciter based IDE: html/css/script + scintilla) — загрузка примерно того же UI по объему 200-400ms.
Ах, ну да. Что не постинг от c-smile — жди рекламы.
M>>Вообще-то, насколько я понимаю, там далеко не только UI загружается
CS>А зачем это "далеко не только" грузить когда я не просил? CS>Это явная ошибка дизайна. Непонятно чья толко — самой платформы или самих разарботчиков VS.
CS>Как бы Java умеет грузить классы on-demand. Я уже не говорю про скрипты.... CS>Почему здесь нельзя сделать то же?
Потому что основной юз-кейс — это именно работа в солюшене.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, c-smile, Вы писали:
CS>>На моей рабочей машине VS2010 стартует 12 секунд. WTF? К тому же при установке этот подлец поставил себя как viewer С++ файлов. MM>Не нравится — удали.
Я разве где-то что-то сказал про "нравится"?
Задал простой вопрос: зачем такая технология нужна на desktop если в ней нельзя сделать загрузку меньше этих 12 секунд.
Я пытаюсь определить на будущее источник этого epic failure чтобы не вступить еще где.
CS>>Это какой-то эксперимент на живых людях. Кто-нибудь может внятно объяснить преимущества использования .NET для Visual Studio и в частности на кой там упал этот WTF (в смысле WPF)? MM>Не можете спокойно жить в мире, где программисты использует .Net там, где он удачно подходит? Постоянно меряетесь пиписьками с аргументами "какого MS не использует свои технологии"? Ну так получайте и наслаждайтесь.
Я не могу? Очень даже могу и живу.
К ASP.NET по большому счету претензий нет. По всей видимости это то что доктор прописал для .NET.
Я просто пытаюсь разобраться.
CS>>Скажем я сравниваю со своим ScIDE (sciter based IDE: html/css/script + scintilla) — загрузка примерно того же UI по объему 200-400ms. MM>Ах, ну да. Что не постинг от c-smile — жди рекламы.
Рекламы чего в данном случае? Я ни Sciter (free) ни ScIDE (open source) не продаю. Это во-первых.
Во вторых. Я говорю про то что знаю достоверно. ScIDE я знаю по определению как устроена.
ScIDE максимально близка к VS — та же структура экрана и количество UI элементов.
В принципе идентичный способ описания UI — markup в обоих случаях.
Я не понимаю почему такая разница. В десятки раз прошу заметить. Это очень много.
Здравствуйте, c-smile, Вы писали:
CS>>>На моей рабочей машине VS2010 стартует 12 секунд. WTF? К тому же при установке этот подлец поставил себя как viewer С++ файлов. MM>>Не нравится — удали. CS>Я разве где-то что-то сказал про "нравится"?
Ну как же... Подлец... WTF...
CS>Задал простой вопрос: зачем такая технология нужна на desktop если в ней нельзя сделать загрузку меньше этих 12 секунд. CS>Я пытаюсь определить на будущее источник этого epic failure чтобы не вступить еще где.
Уж извини, но изначальный пост на попытку узнать, что не так, вообще не тянет. Подлец... WTF...
CS>>>Это какой-то эксперимент на живых людях. Кто-нибудь может внятно объяснить преимущества использования .NET для Visual Studio и в частности на кой там упал этот WTF (в смысле WPF)? MM>>Не можете спокойно жить в мире, где программисты использует .Net там, где он удачно подходит? Постоянно меряетесь пиписьками с аргументами "какого MS не использует свои технологии"? Ну так получайте и наслаждайтесь. CS>Я не могу? Очень даже могу и живу. CS>К ASP.NET по большому счету претензий нет. По всей видимости это то что доктор прописал для .NET.
Я специально обратился на "вы", потому что это не персонально тебе, а скорее к сообществу тех программеров, которые и месяца не могут прожить, не пройдясь по .Net.
CS>Я просто пытаюсь разобраться.
Хорошо. Наверное, стоит взяться за Рефлектор.
CS>>>Скажем я сравниваю со своим ScIDE (sciter based IDE: html/css/script + scintilla) — загрузка примерно того же UI по объему 200-400ms. MM>>Ах, ну да. Что не постинг от c-smile — жди рекламы. CS>Рекламы чего в данном случае? Я ни Sciter (free) ни ScIDE (open source) не продаю. Это во-первых.
Рекламы своих разработок. Ты постоянно их упоминаешь.
CS>Во вторых. Я говорю про то что знаю достоверно. ScIDE я знаю по определению как устроена. CS>ScIDE максимально близка к VS — та же структура экрана и количество UI элементов. CS>В принципе идентичный способ описания UI — markup в обоих случаях. CS>Я не понимаю почему такая разница. В десятки раз прошу заметить. Это очень много.
У меня только что Студия 2010 стартанула за 3.5 секунды. Core 2 Duo, 4 Gb, Win 7 64 HP.
А вообще это круто: сравнивать проги по "структуре экрана и количеству UI элементов", подсчитанных на глаз
M>Потому что основной юз-кейс — это именно работа в солюшене.
И что? Во времена когда наши ракеты бороздят просторы нельзя сделать загрузку этого solution хотя бы за секунду?
Чем в принципе загрузка C++ solution в VS6 скажем и в VS2010 отличаются? Время загрузки выросло в 20 раз.
Выросло ли количество приятствий в IDE пропорционально?
Я к тому что выбор неадекватных средств/технологий для решения задачь есть базовая ошибка проектирования.
Скажем взять тот-же silverlight — там lightweight .NET VM оправдана ибо managed код фактически занимается
управлением эффективных non-managed компонент. Выбор silverlight для WP7 тоже наверное оправдан ибо WP7 это фактически
моно процесс в котором работают не отдельные приложения а applets которые используют managed code для
свзяки различных native functions в единую среду. Т.е. WP7 это просто одна программа в которой работают всяко разные plug-ins. И это правильно.
То же — и про Android. Т.е. в mobile это оправдано.
M>>Потому что основной юз-кейс — это именно работа в солюшене.
CS>И что? Во времена когда наши ракеты бороздят просторы нельзя сделать загрузку этого solution хотя бы за секунду? CS>Чем в принципе загрузка C++ solution в VS6 скажем и в VS2010 отличаются? Время загрузки выросло в 20 раз. CS>Выросло ли количество приятствий в IDE пропорционально?
Если считать препятствием Windows, то да. Оно тормозит независимо от роста мощности процессора и объема памяти.
CS>Я к тому что выбор неадекватных средств/технологий для решения задачь есть базовая ошибка проектирования.
Ваше мнение относительно задач и решений может не совпадать с мнением Microsoft, загрузка системы или программы это однократное действие.
Непринципиально сколько оно занимает. Я вообще студию утром открыл, вечером закрыл. Иногда виснет, но редко.
Здравствуйте, c-smile, Вы писали:
CS>Задал простой вопрос: зачем такая технология нужна на desktop если в ней нельзя сделать загрузку меньше этих 12 секунд. CS>Я пытаюсь определить на будущее источник этого epic failure чтобы не вступить еще где.
Видимо аура HTMLlayout не позволяет, вот у меня к примеру секунды за 3 стартует.
CS>Рекламы чего в данном случае? Я ни Sciter (free) ни ScIDE (open source) не продаю. Это во-первых.
Себя любимого.
CS>Во вторых. Я говорю про то что знаю достоверно. ScIDE я знаю по определению как устроена. CS>ScIDE максимально близка к VS — та же структура экрана и количество UI элементов.
Запорожец максимально близок к болиду Формулы 1 — те же четыре колеса, руль, двигатель внутреннего сгорания.
Здравствуйте, Ytz, Вы писали:
Ytz> CS>Задал простой вопрос: зачем такая технология нужна на desktop если в ней нельзя сделать загрузку меньше этих 12 секунд. Ytz> CS>Я пытаюсь определить на будущее источник этого epic failure чтобы не вступить еще где.
Ytz> Видимо аура HTMLlayout не позволяет, вот у меня к примеру секунды за 3 стартует.
Здравствуйте, henson, Вы писали:
h> M>>Потому что основной юз-кейс — это именно работа в солюшене.
h> CS>И что? Во времена когда наши ракеты бороздят просторы нельзя сделать загрузку этого solution хотя бы за секунду? h> CS>Чем в принципе загрузка C++ solution в VS6 скажем и в VS2010 отличаются? Время загрузки выросло в 20 раз. h> CS>Выросло ли количество приятствий в IDE пропорционально?
h> Если считать препятствием Windows, то да. Оно тормозит независимо от роста мощности процессора и объема памяти.
Читаем внимательно. Речь не о препятствиях
h> Ваше мнение относительно задач и решений может не совпадать с мнением Microsoft, загрузка системы или программы это однократное действие. h> Непринципиально сколько оно занимает. Я вообще студию утром открыл, вечером закрыл. Иногда виснет, но редко.
Лично меня тоже бесит долгая загрузка прилаг, поэтому без хибернейта жизни нет. Delphi тоже долго грузится, если из нее .NET кишки не выкинуть. Для этих целей даже специальные утили появились, народу не нравится долгая загрузка.
Здравствуйте, c-smile, Вы писали:
CS>Скажем я сравниваю со своим ScIDE (sciter based IDE: html/css/script + scintilla) — загрузка примерно того же UI по объему 200-400ms.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, Mamut, Вы писали:
M>>Вообще-то, насколько я понимаю, там далеко не только UI загружается
CS>А зачем это "далеко не только" грузить когда я не просил? CS>Это явная ошибка дизайна. Непонятно чья толко — самой платформы или самих разарботчиков VS.
CS>Как бы Java умеет грузить классы on-demand. Я уже не говорю про скрипты.... CS>Почему здесь нельзя сделать то же?
Загрузка сборок и jit компиляция и так on-demand происходят.
Здравствуйте, c-smile, Вы писали:
CS>Задал простой вопрос: зачем такая технология нужна на desktop если в ней нельзя сделать загрузку меньше этих 12 секунд.
Вообще такая технология не нужна. Но при чем тут .NET? С чего ты взял, что на нем нельзя сделать загрузку быстрее 12 секунд?
Здравствуйте, mrTwister, Вы писали:
T> CS>Задал простой вопрос: зачем такая технология нужна на desktop если в ней нельзя сделать загрузку меньше этих 12 секунд.
T> Вообще такая технология не нужна. Но при чем тут .NET? С чего ты взял, что на нем нельзя сделать загрузку быстрее 12 секунд?
Power Shell ISE (.NET и морда на WPF) грузится 8 секунд Долбаный редактор с подсветкой и автокомплитом, грузится 8 секунд... афуеть...
Здравствуйте, c-smile, Вы писали:
CS>Я не понимаю почему такая разница. В десятки раз прошу заметить. Это очень много.
Ради честности стоит сказать, что инициализация UI в Студии — это далеко не основная часть работы.
Здравствуйте, c-smile, Вы писали:
CS>На моей рабочей машине VS2010 стартует 12 секунд. WTF? К тому же при установке этот подлец поставил себя как viewer С++ файлов.
Отсутствие рынка или сговор монополистов. Такую лажу в ином случае не делали бы.
Здравствуйте, Ytz, Вы писали:
Ytz> Ytz>> Видимо аура HTMLlayout не позволяет, вот у меня к примеру секунды за 3 стартует.
Ytz> H>Первый раз? Не верю.
Ytz> Приезжай ко мне — покажу. Если так, с тебя бутылка виски, если нет — с меня. Мыло в профиле есть.
Даже дохлятина Windows PowerShell ISE грузится первый раз 8 секунд, а ты мне предлагаешь поверить, что студия 2010 взлетает за 3. Конфиг: Phenom II X4 3.3GHz, 8Gb RAM, RAID0 ~180Mb/s. К слову, ты не думай, у меня стояла 2010 студия, время я не замерял, но уж точно не 3 секунды.
Здравствуйте, c-smile, Вы писали:
CS>На моей рабочей машине VS2010 стартует 12 секунд. WTF? К тому же при установке этот подлец поставил себя как viewer С++ файлов. CS>Это какой-то эксперимент на живых людях.
Отсутствие конкуренции или сговор производителей, в противном случае такой лажи бы не выпустили.
Здравствуйте, ua1zcl, Вы писали:
u> CS>На моей рабочей машине VS2010 стартует 12 секунд. WTF? К тому же при установке этот подлец поставил себя как viewer С++ файлов. u> CS>Это какой-то эксперимент на живых людях.
u> Отсутствие конкуренции или сговор производителей, в противном случае такой лажи бы не выпустили.
Ну дык блин... Кто на поле .NET/C# (а С++, насколько я понимаю, в студии внимания уделяется совсем мало) будет конкурировать с МС? Борланд рыпнулся, в результате загнулся сам и чуть не загнул свою линейку успешных продуктов. Слава ембаркадере, откачали вовремя
Здравствуйте, hattab, Вы писали:
H>Ну дык блин... Кто на поле .NET/C# (а С++, насколько я понимаю, в студии внимания уделяется совсем мало) будет конкурировать с МС? Борланд рыпнулся, в результате загнулся сам и чуть не загнул свою линейку успешных продуктов. Слава ембаркадере, откачали вовремя
В свое время Delphi часто страдала от нападок "профессионалов" от С++, лажавших ее ради ощущения собственной значимости. Прикольно, что сейчас фаны Delphi превратились в таких же гоблинов, только лажающих .Net.
Здравствуйте, hattab, Вы писали:
H>Power Shell ISE (.NET и морда на WPF) грузится 8 секунд Долбаный редактор с подсветкой и автокомплитом, грузится 8 секунд... афуеть...
Вот я прихожу на работу и просто запускаю программы. Я и дома также — просто запускаю программы. А некоторые оказывается с секундомером сидят и меряют, какая программа сколько стартует. Очуметь
M>>Потому что основной юз-кейс — это именно работа в солюшене.
CS>И что? Во времена когда наши ракеты бороздят просторы нельзя сделать загрузку этого solution хотя бы за секунду? CS>Чем в принципе загрузка C++ solution в VS6 скажем и в VS2010 отличаются? Время загрузки выросло в 20 раз. CS>Выросло ли количество приятствий в IDE пропорционально?
CS>Я к тому что выбор неадекватных средств/технологий для решения задачь есть базовая ошибка проектирования.
Основная ошибка в проектировании — это пытаться учесть все экстремальные случаи, навроде клиентов, которые открывают .cpp или какие-там файлы поштучно, смотрят, и закрывают студии. Так что нормально всё сделано.
Здравствуйте, MxMsk, Вы писали:
MM> H>Power Shell ISE (.NET и морда на WPF) грузится 8 секунд Долбаный редактор с подсветкой и автокомплитом, грузится 8 секунд... афуеть...
MM> Вот я прихожу на работу и просто запускаю программы. Я и дома также — просто запускаю программы. А некоторые оказывается с секундомером сидят и меряют, какая программа сколько стартует. Очуметь
Я запустил и желаю видеть результат сию секунду! Я зря что ли потратился на мощное железо? Когда я возмущался тормозами .NET софта на моей бутявке с 512Mb, "знатоки" делали оскорбленное лицо и со словами "ты бы еще на калькуляторе запустил", самоустранялись. Сейчас говорю о тормозах на мощном железе... а оказывается нужно просто подождать.
Здравствуйте, MxMsk, Вы писали:
MM> H>Ну дык блин... Кто на поле .NET/C# (а С++, насколько я понимаю, в студии внимания уделяется совсем мало) будет конкурировать с МС? Борланд рыпнулся, в результате загнулся сам и чуть не загнул свою линейку успешных продуктов. Слава ембаркадере, откачали вовремя
MM> В свое время Delphi часто страдала от нападок "профессионалов" от С++, лажавших ее ради ощущения собственной значимости. Прикольно, что сейчас фаны Delphi превратились в таких же гоблинов, только лажающих .Net.
Это ты меня зря в "нелюбови" к нету уличаешь Я лишь говорю, что вижу Понимаешь, не может быть так, что среди доступного для ощупывания .NET-софта попадается сплошь жрущий и весьма неспешный софт, а где-то там, в стране эльфов видимо, есть чудо софт о котором знают только просвещенные. Про Evernote на хабре читал? Тоже, небось, злые дельфисто-сишники опускают чудесный .NET. (MxKazan, это ты? Что-то мне постинги по стилю уж очень знакомы )
Здравствуйте, hattab, Вы писали:
H>MxKazan, это ты? Что-то мне постинги по стилю уж очень знакомы
Дык, я вроде и не скрываю. Решил как-то, что раз уж переехал в Москву, то надо бы и ник подкорректировать.
Здравствуйте, MxMsk, Вы писали:
MM>Вот я прихожу на работу и просто запускаю программы. Я и дома также — просто запускаю программы. А некоторые оказывается с секундомером сидят и меряют, какая программа сколько стартует. Очуметь
Здравствуйте, Sharowarsheg, Вы писали:
CS>>И что? Во времена когда наши ракеты бороздят просторы нельзя сделать загрузку этого solution хотя бы за секунду? CS>>Чем в принципе загрузка C++ solution в VS6 скажем и в VS2010 отличаются? Время загрузки выросло в 20 раз. CS>>Выросло ли количество приятствий в IDE пропорционально?
Честно говоря на этот вот свой вопрос я ответа так и не получил.
Будем считать его риторическим.
CS>>Я к тому что выбор неадекватных средств/технологий для решения задачь есть базовая ошибка проектирования.
S>Основная ошибка в проектировании — это пытаться учесть все экстремальные случаи, навроде клиентов, которые открывают .cpp или какие-там файлы поштучно, смотрят, и закрывают студии. Так что нормально всё сделано.
Гражданин Sharowarsheg, вот ответь мне на такой вопрос.
Если у тебя есть шароварный продукт А который сделан на WPF.
И тут появляется на рынке некий другой продукт Б который "навроде" как А но нативный.
Кто победит? Ты можешь до посинения объяснять юзерам что "у нея душа красивая". Денег у тебя больше не будет от этого.
Здравствуйте, c-smile, Вы писали:
CS>Гражданин Sharowarsheg, вот ответь мне на такой вопрос. CS>Если у тебя есть шароварный продукт А который сделан на WPF. CS>И тут появляется на рынке некий другой продукт Б который "навроде" как А но нативный. CS>Кто победит?
Я. У меня продукт работает, а у конкурента access violation. Только у меня не WPF, а WinForms, а в остальном всё так и есть.
Здравствуйте, Don Reba, Вы писали:
DR>Рико Мариани давно в своём блоге предупреждал, что студия будет работать быстрее, но загружаться дольше.
И в результате сдержал обещание на половину: загружается действительно медленнее, но и в работе еле ползает
Продукты от МС давно стали мало юзабельным г-ном.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, c-smile, Вы писали:
CS>>На моей рабочей машине VS2010 стартует 12 секунд. WTF?
DM>Я еще не видел продукта на WPF, который бы быстро стартовал. Подозреваю, дело в нем.
Собственно в этом и был мой вопрос: зачем VS сделана на WPF? Какую именно проблему решило переписывание IDE на WPF?
Или просто эксперимент? Или надо было сделать что-то реальное на WPF чтобы по ходу отладить оный framework?
M>>Потому что основной юз-кейс — это именно работа в солюшене.
CS>И что? Во времена когда наши ракеты бороздят просторы нельзя сделать загрузку этого solution хотя бы за секунду? CS>Чем в принципе загрузка C++ solution в VS6 скажем и в VS2010 отличаются? Время загрузки выросло в 20 раз. CS>Выросло ли количество приятствий в IDE пропорционально?
Честно — хз По идее, да Тут и новые языки/платформы, и поддержка множества языков в одном проекте, и всякая хренотень типа рефакторинга и т.п. Но честно — не знаю
CS>Я к тому что выбор неадекватных средств/технологий для решения задачь есть базовая ошибка проектирования.
Не факт, что для VS 2010 выбраны неадекватные средства
Здравствуйте, c-smile, Вы писали:
DM>>Я еще не видел продукта на WPF, который бы быстро стартовал. Подозреваю, дело в нем.
В случае студии — слегка неправда. Тынц и по тегам.
CS>Собственно в этом и был мой вопрос: зачем VS сделана на WPF? Какую именно проблему решило переписывание IDE на WPF? http://blogs.msdn.com/b/visualstudio/archive/2010/02/15/wpf-in-visual-studio-2010-part-1.aspx
1) Dogfooding. В результате 4й wpf почти перешёл из стадии фичастого сфероконя в стадию ready-to-use.
2) Архитектурная.
The Visual Studio long term road map calls for some features which will stretch the product into new areas that the current architecture cannot support. The architectural initiative in VS 2010 was not to move to WPF specifically, but to install a presentation neutral architecture which would allow us to decouple the core business logic from the presentation layer and give us the agility we need for future versions. As a technology, WPF leads naturally to this “separated presentation” architecture, often called “Model, View, Controller” or “Model, View, Presenter”.
3) Расширяемость и extension manager. Не только WPF, но однозначно epic win.
По производительности 2010я на голову выше 2008й, особенно при дебаге (без intellitrace), database projects тож весьма шустры. Пока переползали, стояли рядом обе. Насравнивался по горло.
Здравствуйте, Sharowarsheg, Вы писали:
S>Я. У меня продукт работает, а у конкурента access violation.
А почему не наоборот?
У конкурента всё работает а у тебя null pointer exception?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, c-smile, Вы писали:
CS>Собственно в этом и был мой вопрос: зачем VS сделана на WPF? Какую именно проблему решило переписывание IDE на WPF? CS>Или просто эксперимент? Или надо было сделать что-то реальное на WPF чтобы по ходу отладить оный framework?
Может чтоб в следующей студии его выкинуть и сказать: "Смотрите как мы всё ускорили! Новая MSVS2011 гораздо быстрее MSVS2010!!!"
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
S>>Я. У меня продукт работает, а у конкурента access violation. CC>А почему не наоборот? CC>У конкурента всё работает а у тебя null pointer exception?
Да хрен его знает. Как-то получилось, что дотнет способствует работоспособности программ, которые мы пишем. По сравнению с Delphi и C результат радикально работоспособнее.
Здравствуйте, c-smile, Вы писали:
CS>На моей рабочей машине VS2010 стартует 12 секунд.
Так быстро ?
Сейчас ради интереса замерил время запуска, только на 2008-ой студии.
Результат — 24 сек (правда, установлен Visual Assist, Devpartner, WIX и др.).
Так что все познается в сравнении...
Здравствуйте, Sharowarsheg, Вы писали:
S> S>>Я. У меня продукт работает, а у конкурента access violation.
S> CC>А почему не наоборот? S> CC>У конкурента всё работает а у тебя null pointer exception?
S> Да хрен его знает. Как-то получилось, что дотнет способствует работоспособности программ, которые мы пишем. По сравнению с Delphi и C результат радикально работоспособнее.
А я всегда говорил, что любимый аргумент "неосиляторов" это Access violation
Здравствуйте, hattab, Вы писали:
S>> S>>Я. У меня продукт работает, а у конкурента access violation.
S>> CC>А почему не наоборот? S>> CC>У конкурента всё работает а у тебя null pointer exception?
S>> Да хрен его знает. Как-то получилось, что дотнет способствует работоспособности программ, которые мы пишем. По сравнению с Delphi и C результат радикально работоспособнее.
H>А я всегда говорил, что любимый аргумент "неосиляторов" это Access violation
Это время разработки, а не частности вроде access violation. А время разработки — это деньги. Отладка есть везде, но в managed она проще и быстрее.
Здравствуйте, hattab, Вы писали:
H>Я запустил и желаю видеть результат сию секунду! Я зря что ли потратился на мощное железо? Когда я возмущался тормозами .NET софта на моей бутявке с 512Mb, "знатоки" делали оскорбленное лицо и со словами "ты бы еще на калькуляторе запустил", самоустранялись. Сейчас говорю о тормозах на мощном железе... а оказывается нужно просто подождать.
Я уже приводил когда-то в пример Adobe Photoshop Elements 8. В стандартной установке на моем компе он стартует гораздо дольше 2010-й Студии. Какие я должен сделать выводы? Что С++ говно? Или может снести Photoshop? Лично мне ехать, а кому шашечки, минусуйте себе дальше.
Здравствуйте, MxMsk, Вы писали:
MM> H>Я запустил и желаю видеть результат сию секунду! Я зря что ли потратился на мощное железо? Когда я возмущался тормозами .NET софта на моей бутявке с 512Mb, "знатоки" делали оскорбленное лицо и со словами "ты бы еще на калькуляторе запустил", самоустранялись. Сейчас говорю о тормозах на мощном железе... а оказывается нужно просто подождать.
MM> Я уже приводил когда-то в пример Adobe Photoshop Elements 8. В стандартной установке на моем компе он стартует гораздо дольше 2010-й Студии. Какие я должен сделать выводы? Что С++ говно? Или может снести Photoshop? Лично мне ехать, а кому шашечки, минусуйте себе дальше.
А я уже говорил когда-то, что готов простить относительно медленный запуск тяжелому софту. Той же студии, тем же дельфям или джимпу. Но не нужно переводить стрелки с банального редактора с подсветкой на монстров вроде фотошопа. Что позволено Юпитеру, то быкам не засияет.
Здравствуйте, Sharowarsheg, Вы писали:
S> H>А я всегда говорил, что любимый аргумент "неосиляторов" это Access violation
S> Это время разработки, а не частности вроде access violation. А время разработки — это деньги. Отладка есть везде, но в managed она проще и быстрее.
Ох, не рассказывай пожалуйста, что на дельфях разрабатывать софт медленнее нежели на шарпе.
Здравствуйте, hattab, Вы писали:
H>Ох, не рассказывай пожалуйста, что на дельфях разрабатывать софт медленнее нежели на шарпе.
Медленней было чем на VB.
А с шарпом уже сравнить сложно, ввиду фактической смерти дельфей. Да и используется шарп для других задач, где нет гуев. И в тех задачах — нет дельфей.
Но, общая тенденция такова — разработка на ЯП с автоматическим распределением памяти быстрее чем с ручным.
Такова мировая практика разработки.
И только там где автоматические распределение памяти накладно остались, и останутся С и С++
Здравствуйте, hattab, Вы писали:
S>> H>А я всегда говорил, что любимый аргумент "неосиляторов" это Access violation
S>> Это время разработки, а не частности вроде access violation. А время разработки — это деньги. Отладка есть везде, но в managed она проще и быстрее.
H>Ох, не рассказывай пожалуйста, что на дельфях разрабатывать софт медленнее нежели на шарпе.
Здравствуйте, Sharowarsheg, Вы писали:
S>>>Я. У меня продукт работает, а у конкурента access violation. CC>>А почему не наоборот? CC>>У конкурента всё работает а у тебя null pointer exception?
S>Да хрен его знает. Как-то получилось, что дотнет способствует работоспособности программ, которые мы пишем. По сравнению с Delphi и C результат радикально работоспособнее.
Так может дело не в С а в вас?
Потому как у нас с С/С++ проблем нет. Работоспособность на уровне. При этом цена ошибки в моём текущем таске: BSOD.
Кстати кто там бухтел про "на С++ драйвера писать низя".
Пишу как часть большого проекта SCSI StorPort на С++, всё прекрасно работает. Правда сама по себе работа со Storage в винде малость вывихнутая.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
S>>>>Я. У меня продукт работает, а у конкурента access violation. CC>>>А почему не наоборот? CC>>>У конкурента всё работает а у тебя null pointer exception?
S>>Да хрен его знает. Как-то получилось, что дотнет способствует работоспособности программ, которые мы пишем. По сравнению с Delphi и C результат радикально работоспособнее. CC>Так может дело не в С а в вас?
Практика показывает, что нет. Писать можно на чем хочешь, но на managed получается писать быстрее, чем без managed.
Здравствуйте, Skynin, Вы писали:
S> H>Ох, не рассказывай пожалуйста, что на дельфях разрабатывать софт медленнее нежели на шарпе.
S> Медленней было чем на VB.
S> А с шарпом уже сравнить сложно, ввиду фактической смерти дельфей.
Ты свои фантазии за факты-то не выдавай
S> Да и используется шарп для других задач, где нет гуев. И в тех задачах — нет дельфей.
У меня софт на дельфях без гуя Распределенные вычисления, если что.
S> Но, общая тенденция такова — разработка на ЯП с автоматическим распределением памяти быстрее чем с ручным.
S> Такова мировая практика разработки.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, Jack128, Вы писали:
N>>>Но для просмотра одного единственного cpp или xml могли бы сделать что-нибудь побыстрее.
J>>А зачем ты используешь для просмотра одного cpp или xml файла VS?? Чем Notepad++/IE не устраивает??
N>Notepad++ у меня даже не установлен. Scintilla есть, но студию для этого использовать как-то логичней.
Студия не просто показывает текст, её нужно загрузить и инициализировать кучу всякой всячины (например авто дополнение) вот она и призадумывается .
N>IE не устраивает, так как xml надо иногда и поправить, а в студии делать это удобней. Плюс в ней есть автоформатирование xml. Мне она нравится почти всем, но вот тормоза...
Здравствуйте, Sharowarsheg, Вы писали:
S>>>>>Я. У меня продукт работает, а у конкурента access violation. CC>>>>А почему не наоборот? CC>>>>У конкурента всё работает а у тебя null pointer exception?
S>>>Да хрен его знает. Как-то получилось, что дотнет способствует работоспособности программ, которые мы пишем. По сравнению с Delphi и C результат радикально работоспособнее. CC>>Так может дело не в С а в вас?
S>Практика показывает, что нет. Писать можно на чем хочешь, но на managed получается писать быстрее, чем без managed.
Ты определись: "на дотнет получается писать быстрее" или "дотнет способствует работоспособности".
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, hattab, Вы писали:
S>> А с шарпом уже сравнить сложно, ввиду фактической смерти дельфей. H> Ты свои фантазии за факты-то не выдавай
Мои фантазии разделяет большинство. А твои — маргинальные дельфисты
Да все более редкие — сопровождающие проекты начатые давно, и которые переписывать нерентабельно.
S>> Да и используется шарп для других задач, где нет гуев. И в тех задачах — нет дельфей. H>У меня софт на дельфях без гуя Распределенные вычисления, если что.
И что с того? Это говорит о скорости и качестве разработки? А если кто на ассемблере напишет — тоже зачтется что нет разницы?
S>> Но, общая тенденция такова — разработка на ЯП с автоматическим распределением памяти быстрее чем с ручным. S>> Такова мировая практика разработки. H>Пруфы или небыло
TIOBE Programming Community Index и всякое подобное.
Списки вакансий и требуемых знаний, как следствие выбора технологий разработки.
Здравствуйте, CreatorCray, Вы писали:
CC>Так может дело не в С а в вас? CC>Потому как у нас с С/С++ проблем нет. Работоспособность на уровне. При этом цена ошибки в моём текущем таске: BSOD.
Только С++-программисты вымирают, как класс, из-за постоянно уменьшающейся востребованности. Потому что менеджеры проектов и вкладывающие деньги знают что дело то как раз в технологии, и одного уровня квалификации программисты пишут с разной скоростью, в зависимости от нее.
[...]
S>>Практика показывает, что нет. Писать можно на чем хочешь, но на managed получается писать быстрее, чем без managed. CC>Ты определись: "на дотнет получается писать быстрее" или "дотнет способствует работоспособности".
Я бы даже еще уточнил в чем нужно определиться: "у меня на дотнет получается писать быстрее" или "дотнет способствует работоспособности"
Здравствуйте, hattab, Вы писали:
S>> А с шарпом уже сравнить сложно, ввиду фактической смерти дельфей. H> Ты свои фантазии за факты-то не выдавай
У меня на компе нет ни одной проги, написанной на Delphi. Надеюсь, аналогия ясна
Здравствуйте, CreatorCray, Вы писали:
S>>Да хрен его знает. Как-то получилось, что дотнет способствует работоспособности программ, которые мы пишем. По сравнению с Delphi и C результат радикально работоспособнее. CC>Так может дело не в С а в вас? CC>Потому как у нас с С/С++ проблем нет. Работоспособность на уровне. При этом цена ошибки в моём текущем таске: BSOD.
BSOD, кстати, не цена ошибки. Цена ошибки меряется в долларах (ну и в редких случаях в жизнях), а не в BSOD-ах. На BSOD сам по себе клиенту плевать.
Здравствуйте, hattab, Вы писали:
H>А я уже говорил когда-то, что готов простить относительно медленный запуск тяжелому софту. Той же студии, тем же дельфям или джимпу. Но не нужно переводить стрелки с банального редактора с подсветкой на монстров вроде фотошопа. Что позволено Юпитеру, то быкам не засияет.
Ах, прелестно. Было бы в Фотошопе хоть что-нибудь дотНетовского, фиг бы ты написал подобное.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, hattab, Вы писали:
S>>> А с шарпом уже сравнить сложно, ввиду фактической смерти дельфей. H>> Ты свои фантазии за факты-то не выдавай MM>У меня на компе нет ни одной проги, написанной на Delphi. Надеюсь, аналогия ясна
На моем компе нет ни одной программы написанной на .NET =)
Здравствуйте, Klikujiskaaan, Вы писали:
MM>>У меня на компе нет ни одной проги, написанной на Delphi. Надеюсь, аналогия ясна K>На моем компе нет ни одной программы написанной на .NET =)
Ты либо не в теме, либо одно из двух
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, Klikujiskaaan, Вы писали:
MM>>>У меня на компе нет ни одной проги, написанной на Delphi. Надеюсь, аналогия ясна K>>На моем компе нет ни одной программы написанной на .NET =) MM>Ты либо не в теме, либо одно из двух
Да я так, к слову. Кстати, делфёвых прог тоже нету =)
Хотяя... может еще сохранились лабораторные работы с первого курса 0О
Здравствуйте, Skynin, Вы писали:
CC>>Так может дело не в С а в вас? CC>>Потому как у нас с С/С++ проблем нет. Работоспособность на уровне. При этом цена ошибки в моём текущем таске: BSOD. S>Только С++-программисты вымирают, как класс, из-за постоянно уменьшающейся востребованности. Потому что менеджеры проектов и вкладывающие деньги знают что дело то как раз в технологии, и одного уровня квалификации программисты пишут с разной скоростью, в зависимости от нее.
Это с твоей колокольни такие виды интересные?
Все серьёзные С++-ники кого знаю — нарасхват.
Без работы никто не сидит.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Sharowarsheg, Вы писали:
S>BSOD, кстати, не цена ошибки. Цена ошибки меряется в долларах (ну и в редких случаях в жизнях), а не в BSOD-ах. На BSOD сам по себе клиенту плевать.
Как ты думаешь, что в пересчёте на деньги выйдет дороже: когда на облачном сервере в одной из VM умрёт одна программа или когда исдохнет весь сервер со всеми VM и той требухой, что в них крутится?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, MxMsk, Вы писали:
S>>> А с шарпом уже сравнить сложно, ввиду фактической смерти дельфей. H>> Ты свои фантазии за факты-то не выдавай MM>У меня на компе нет ни одной проги, написанной на Delphi. Надеюсь, аналогия ясна
Зато просто море написаных на C/C++
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
MM>>У меня на компе нет ни одной проги, написанной на Delphi. Надеюсь, аналогия ясна CC>Зато просто море написаных на C/C++
Да пожалуйста. Хоть на чем, лишь бы я получал от ПО то, что мне нужно.
Гы, а ведь есть одна прога на Делфи! TrainStore для Microsoft Train Simulator.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Sharowarsheg, Вы писали:
S>>BSOD, кстати, не цена ошибки. Цена ошибки меряется в долларах (ну и в редких случаях в жизнях), а не в BSOD-ах. На BSOD сам по себе клиенту плевать.
CC>Как ты думаешь, что в пересчёте на деньги выйдет дороже: когда на облачном сервере в одной из VM умрёт одна программа или когда исдохнет весь сервер со всеми VM и той требухой, что в них крутится?
Кому дороже? Кто продал что и кому в этом примере?
Если вы продали драйвер диска в датацентр, конечно, вам выйдет дороже отказ в том месте, с кем у вас контракт на большую сумму.
Если речь про хостера, то неизвестно, кому дороже что выйдет. В реальности, скорее всего, оба варианта ничего не стоят.
Здравствуйте, CreatorCray, Вы писали:
CC>Все серьёзные С++-ники кого знаю — нарасхват.
1Cники — тоже.
Вакансий на Ruby on Rails — тоже хватает.
Слышал, что и на Cobolе в америке работу найти не проблема.
Вопрос в другом — в начале 90ых, когда я начинал профессиональную карьеру, писал на плайн Си. Из других программистов встречались только на FoxBase. С каждым годом, доля программистов на Си вокруг меня падала и падала. Хотя даже сейчас могу назвать пару мест где ищут сишника. Но кому оно интересно, если я знаю об этих местах от ушедших оттуда, один на 1С и двое на Java? Не мальчики, работали там свыше 5ти лет.
Задачи для С++ не исчезнут в ближайшем будущем. И замены ему — не предвидится. Другое дело что если 10 лет тому ему замены не было для задачи, то теперь — есть выбор. И стараются выбирать — не С++. Разработка на С++ дорогая, и могут позволить только крупные компании, либо если в силу требований — никакой другой инструмент не подходит.
А серьезным специалистам — работа найдется.
Недавно видел вакансию, с командировками в США для программиста на Rebol.
Вопрос — сколько ждал такой работы программист на Rebol.
Здравствуйте, CreatorCray, Вы писали: MM>>У меня на компе нет ни одной проги, написанной на Delphi. Надеюсь, аналогия ясна CC>Зато просто море написаных на C/C++
а у меня преимущественно дельфовый софт
skipe,qip,hfs,kmplayer,aimp,spybot,faststone, EMS-овский софт
так что я похоже фанат дельфи
остальное видимо сишное, есть смартгит, это ява
дотнета нету
Здравствуйте, Quadri, Вы писали:
Q> H>Delphi тоже долго грузится, если из нее .NET кишки не выкинуть. Для этих целей даже специальные утили появились,
Q> Не подскажите что за утилиты? чет найти сходу не получилось
DelphiDistiller, в первых инкарнациях и в последующей для XE.
Здравствуйте, Skynin, Вы писали:
S> H> Ты свои фантазии за факты-то не выдавай
S> Мои фантазии разделяет большинство. А твои — маргинальные дельфисты
Мне пофиг с кем ты там свои фантазии разделяешь, с большинством или со своим хомячком. Фантазиями от этого они быть не перестают
S> Да все более редкие — сопровождающие проекты начатые давно, и которые переписывать нерентабельно.
Эту жевачку жует уже не первое поколение шарпеев Все еще вкусная?
S> S>> Да и используется шарп для других задач, где нет гуев. И в тех задачах — нет дельфей.
S> H>У меня софт на дельфях без гуя Распределенные вычисления, если что.
S> И что с того? Это говорит о скорости и качестве разработки? А если кто на ассемблере напишет — тоже зачтется что нет разницы?
Ты даже не осилил понять, на что был ответ...
S> S>> Но, общая тенденция такова — разработка на ЯП с автоматическим распределением памяти быстрее чем с ручным. S> S>> Такова мировая практика разработки.
S> H>Пруфы или небыло
S> TIOBE Programming Community Index и всякое подобное.
Здравствуйте, MxMsk, Вы писали:
MM> S>> А с шарпом уже сравнить сложно, ввиду фактической смерти дельфей.
MM> H> Ты свои фантазии за факты-то не выдавай
MM> У меня на компе нет ни одной проги, написанной на Delphi. Надеюсь, аналогия ясна
Нет, не ясна У меня вот твоего софта нет, это уже означает, что ты труп? Аналогия то с твоим бредом прямая
Здравствуйте, MxMsk, Вы писали:
MM> H>А я уже говорил когда-то, что готов простить относительно медленный запуск тяжелому софту. Той же студии, тем же дельфям или джимпу. Но не нужно переводить стрелки с банального редактора с подсветкой на монстров вроде фотошопа. Что позволено Юпитеру, то быкам не засияет.
MM> Ах, прелестно. Было бы в Фотошопе хоть что-нибудь дотНетовского, фиг бы ты написал подобное.
Здравствуйте, hattab, Вы писали:
MM>> H> Ты свои фантазии за факты-то не выдавай MM>> У меня на компе нет ни одной проги, написанной на Delphi. Надеюсь, аналогия ясна H>Нет, не ясна У меня вот твоего софта нет, это уже означает, что ты труп? Аналогия то с твоим бредом прямая
Это не мой бред, а бред, который применяют к .Net, рассказывая что на их компе нет ни одной .Net программы. Удивляюсь, что тот мой стёб еще надо объяснять. С другой стороны, мне кажется стоит признать, что живучесть Delphi обеспечивается только тем, что на запрограммированным когда-то в VCL API еще удается создавать адекватные проги для Windows. Как только API Винды начнет стремительно меняться (не факт, конечно), вот тогда Delphi вполне может оказаться неудел. Потому что ресурсы уже не те, потому что голова Хейльсберга уже работает на другую компанию.
Здравствуйте, MxMsk, Вы писали:
MM> H>Нет, не ясна У меня вот твоего софта нет, это уже означает, что ты труп? Аналогия то с твоим бредом прямая
MM> Это не мой бред, а бред, который применяют к .Net, рассказывая что на их компе нет ни одной .Net программы.
Не видел, чтоб говоря об отсутствии .NET софта на своих машинах, говорили о смерти дотнета Но ведь десктопного .NET-софта действительно очень мало. И это факт Из того, чем чаще всего размахивают сторонники, это Paint.NET да Атишная панель управления. А исход евернотовцев с дотнета так и вообще показателен, как нельзя лучше.
MM> Удивляюсь, что тот мой стёб еще надо объяснять. С другой стороны, мне кажется стоит признать, что живучесть Delphi обеспечивается только тем, что на запрограммированным когда-то в VCL API еще удается создавать адекватные проги для Windows. Как только API Винды начнет стремительно меняться (не факт, конечно), вот тогда Delphi вполне может оказаться неудел. Потому что ресурсы уже не те, потому что голова Хейльсберга уже работает на другую компанию.
Виндовое апи не начнет стремительно меняться никогда (разве что, выпустят какую-нибудь сингулярити в продакшен, хотя сильно сомнительно). Иначе это будет смертью всего софта, а там и самой винды. Лысый так рисковать не будет (не зря же он назвал выпуск следующей версии виндов самым рискованным делом). Теперь о дельфях. Ембаркадеровцы молодцы, и наконец-то работают над кроссплатформенной дельфей (к сожалению они не успели ее выпустить в этом году, хотя планы такие были). MacOS + Linux + Windows это лучше чем одна только Windows. В общем, и спустя много лет дельфя все еще остается очень привлекательным инструментом разработки.
Здравствуйте, c-smile, Вы писали:
CS>Задал простой вопрос: зачем такая технология нужна на desktop если в ней нельзя сделать загрузку меньше этих 12 секунд. CS>Я пытаюсь определить на будущее источник этого epic failure чтобы не вступить еще где.
Какая именно технология? .NET, WPF? Каким образом ты определяешь, что тормоза при загрузке студии связаны именно с WPF? Она и раньше грузилась не быстро. Кстати, как я понимаю, она все равно до сих пор не 100% .NET (собственно, скорее даже далеко не 100%, раз ее на 64 бита до сих пор перевести не могут). Так что не исключено, что "долго работает" там как раз код, написанный на С++.
Я вот, к примеру, долго думал, что Опен Офис написал целиком на Джава, потому-то и ГУЙ там такой тормозной. Оказалось, нет, на С++.
Здравствуйте, hattab, Вы писали:
H>Не видел, чтоб говоря об отсутствии .NET софта на своих машинах, говорили о смерти дотнета Но ведь десктопного .NET-софта действительно очень мало. И это факт Из того, чем чаще всего размахивают сторонники, это Paint.NET да Атишная панель управления. А исход евернотовцев с дотнета так и вообще показателен, как нельзя лучше.
Уход "Евернотовцев" говорит только о том, что у них на .Net не вышло создать хороший софт. Это вовсе не означает, что этого не получается у других.
H> Виндовое апи не начнет стремительно меняться никогда (разве что, выпустят какую-нибудь сингулярити в продакшен, хотя сильно сомнительно). Иначе это будет смертью всего софта, а там и самой винды. Лысый так рисковать не будет (не зря же он назвал выпуск следующей версии виндов самым рискованным делом). Теперь о дельфях. Ембаркадеровцы молодцы, и наконец-то работают над кроссплатформенной дельфей (к сожалению они не успели ее выпустить в этом году, хотя планы такие были). MacOS + Linux + Windows это лучше чем одна только Windows. В общем, и спустя много лет дельфя все еще остается очень привлекательным инструментом разработки.
Ну, это замечательно. Если получиться сделать действительно кроссплатформенную Delphi, то это хорошо. Kylix так и не взлетел — посмотрим, что выйдет на этот раз.
Здравствуйте, c-smile, Вы писали:
CS>А зачем это "далеко не только" грузить когда я не просил? CS>Это явная ошибка дизайна. Непонятно чья толко — самой платформы или самих разарботчиков VS.
Здравствуйте, MxMsk, Вы писали:
MM> Уход "Евернотовцев" говорит только о том, что у них на .Net не вышло создать хороший софт. Это вовсе не означает, что этого не получается у других.
Посмотреть бы на этих других...
MM> Ну, это замечательно. Если получиться сделать действительно кроссплатформенную Delphi, то это хорошо. Kylix так и не взлетел — посмотрим, что выйдет на этот раз.
Здравствуйте, hattab, Вы писали:
H>Не видел, чтоб говоря об отсутствии .NET софта на своих машинах, говорили о смерти дотнета Но ведь десктопного .NET-софта действительно очень мало. И это факт Из того, чем чаще всего размахивают сторонники, это Paint.NET да Атишная панель управления. А исход евернотовцев с дотнета так и вообще показателен, как нельзя лучше.
А что там показательного ? Эвернот имеет ценность как веб-сервис. UI у них был не ахти — назад в двадцатый век.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, LR, Вы писали:
LR> H>Не видел, чтоб говоря об отсутствии .NET софта на своих машинах, говорили о смерти дотнета Но ведь десктопного .NET-софта действительно очень мало. И это факт Из того, чем чаще всего размахивают сторонники, это Paint.NET да Атишная панель управления. А исход евернотовцев с дотнета так и вообще показателен, как нельзя лучше.
LR> А что там показательного ? Эвернот имеет ценность как веб-сервис. UI у них был не ахти — назад в двадцатый век.
Ну ты читал статью на хабре? Почитай. И комментарии почитай от благодарных юзеров.
Здравствуйте, iHateLogins, Вы писали:
HL>Нытьём на RSDN ты скорость VS2010 не увеличишь. Купи SSD — почувствуй почти мгновенный cold start студии.
Ну как бы я себя уважаю. Т.е. SSD стоит. И вообще Windows Experience Index 6.8 из 7.9 возможных. VS2008 с нуля открывает .cpp файл за 2.5 секунды. Что ИМХО на грани допустимого тоже. VS2010 как я уже сказал существенно больше.
Здравствуйте, hattab, Вы писали:
LR>> А что там показательного ? Эвернот имеет ценность как веб-сервис. UI у них был не ахти — назад в двадцатый век.
H>Ну ты читал статью на хабре? Почитай. И комментарии почитай от благодарных юзеров.
UI не ахти и при этом тормозит и долго запускается. Конечно же юзеры будут рады избавиться хотя бы от части проблем. И похоже у них и на с++ та же проблема что и на дотнете — не могут побороть баги. В течении 5 минут использоваться эвернот упал
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, LR, Вы писали:
LR> UI не ахти и при этом тормозит и долго запускается. Конечно же юзеры будут рады избавиться хотя бы от части проблем. И похоже у них и на с++ та же проблема что и на дотнете — не могут побороть баги. В течении 5 минут использоваться эвернот упал
UI вполне себе Или UI без свистящих пердулин с видео во вращающемся поле ввода сегодня не котируется? По времени запуска народ пишет ровно противоположное твоему. В 3.5 запуск тормозил (еще бы, ведь там был WPF), в 4.0 выпрыгивает после клика
Здравствуйте, hattab, Вы писали:
H>UI вполне себе Или UI без свистящих пердулин с видео во вращающемся поле ввода сегодня не котируется? По времени запуска народ пишет ровно противоположное твоему. В 3.5 запуск тормозил (еще бы, ведь там был WPF), в 4.0 выпрыгивает после клика
UI годится для использования. Он не провальный, но и хорошим его назвать нельзя.
"UI не ахти и при этом тормозит и долго запускается. " — это было про 3.5.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, c-smile, Вы писали:
CS>На моей рабочей машине VS2010 стартует 12 секунд. WTF?
Очень большая часть VS (и в частности то, что тормозит при стартапе, это я тебе как эксперт в этой области говорю) написана совсем не на .NET.
CS>Это какой-то эксперимент на живых людях. Кто-нибудь может внятно объяснить преимущества использования .NET для Visual Studio и в частности на кой там упал этот WTF (в смысле WPF)?
Осталось доказать, что в тормозах студии виноват WPF. Вот VS2008 — там никакого WPF нет, а тормозит еще больше. Парадокс?
CS>Я понимаю что нужен некий клеевой язык для того чтобы кучу добра склеить вместе.
В студии нет никакого клеевого языка (если не считать таковым VB в макросах) и он там, вобщем то, не нужен.
CS>Скажем я сравниваю со своим ScIDE (sciter based IDE: html/css/script + scintilla) — загрузка примерно того же UI по объему 200-400ms.
Очень странно слышать от умного человека подобные сравнения. Тормозит в VS совсем не UI.
CS>Я серьёзно не понимаю смысл этого безобразия.
Так ты и не пытался понять.
CS>Ну не понимаю я. Меня как и всех остальных пользователей авторы Visual Studio явно не уважают.
Здравствуйте, Don Reba, Вы писали:
DR>Рико Мариани давно в своём блоге предупреждал, что студия будет работать быстрее, но загружаться дольше.
По факту 2010 студия загружается быстрее. Это я не про "на глаз", это реальные замеры. Разумеется, речь о загрузке больших проектов. Загрузка пустой студии лично меня мало волнует.
Здравствуйте, Sinix, Вы писали:
S>По производительности 2010я на голову выше 2008й, особенно при дебаге (без intellitrace), database projects тож весьма шустры. Пока переползали, стояли рядом обе. Насравнивался по горло.
А я и сейчас продолжаю — production среда у нас до сих пор под 2008.
Здравствуйте, c-smile, Вы писали:
CS>Задал простой вопрос: зачем такая технология нужна на desktop если в ней нельзя сделать загрузку меньше этих 12 секунд. CS>Я пытаюсь определить на будущее источник этого epic failure чтобы не вступить еще где.
Источник очень прост — юзкейс открытия отдельного файла в новой студии не был основным. Соотв. почти все оптимизации заточены под долгую работу с большим проектом.
Здравствуйте, Nuzhny, Вы писали:
N>Возможно. Но для просмотра одного единственного cpp или xml могли бы сделать что-нибудь побыстрее.
Нужна подгрузка приличного количества пакетов, каждый из которых содержит приличный объем кода инициализации. Ну не заточена студия на быстрое открытие одиночных файлов. Если тебе очень хочется — приделай собственный пакет к VSShell и будет тебе счастье. Или воспользуйся чем нибудь готовым, например SCITe.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нужна подгрузка приличного количества пакетов, каждый из которых содержит приличный объем кода инициализации. Ну не заточена студия на быстрое открытие одиночных файлов.
Я знаю, что не заточена, это очевидно. Но я не вижу особых технических проблем для решения этого вопроса. Даже так: я уверен, что в Майкрософте не хотят это делать или не считают важным.
НС>Если тебе очень хочется — приделай собственный пакет к VSShell и будет тебе счастье. Или воспользуйся чем нибудь готовым, например SCITe.
Мне хочется, чтобы продукт, который я покупаю, работал более эффективно. Это ненормально?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нужна подгрузка приличного количества пакетов, каждый из которых содержит приличный объем кода инициализации. Ну не заточена студия на быстрое открытие одиночных файлов. Если тебе очень хочется — приделай собственный пакет к VSShell и будет тебе счастье. Или воспользуйся чем нибудь готовым, например SCITe.
Я скажу даже больше: при установке студия регистрирует себя как просмотрщик и редактор .cpp файлов. То есть она позиционируется в этом качестве, но выполняет данный функционал неэффективно. Следовательно, претензии к ней справедливы.
Здравствуйте, Nuzhny, Вы писали:
N>Я знаю, что не заточена, это очевидно. Но я не вижу особых технических проблем для решения этого вопроса.
Это потому что ты совсем ничего не знаешь о внутреннем устройстве студии.
N> Даже так: я уверен, что в Майкрософте не хотят это делать или не считают важным.
Не считают важным.
N>Мне хочется, чтобы продукт, который я покупаю, работал более эффективно. Это ненормально?
Здравствуйте, Nuzhny, Вы писали:
N>Я скажу даже больше: при установке студия регистрирует себя как просмотрщик и редактор .cpp файлов. То есть она позиционируется в этом качестве, но выполняет данный функционал неэффективно. Следовательно, претензии к ней справедливы.
Вот чем меня радуют программисты, так это тем, что надуманные формальные признаки в их голове становятся неопровержимым доказательством.
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>Я скажу даже больше: при установке студия регистрирует себя как просмотрщик и редактор .cpp файлов. То есть она позиционируется в этом качестве, но выполняет данный функционал неэффективно. Следовательно, претензии к ней справедливы.
НС>Вот чем меня радуют программисты, так это тем, что надуманные формальные признаки в их голове становятся неопровержимым доказательством.
Смотри: есть у меня стандартный Windows media player, который по-умолчанию проигрывает .avi файлы. Я устанавливаю k-lite codec pack вместе с media player classic. Он мне по-умолчанию НЕ предлагает проигрывать .avi. Если же расширение свободно, то предлагает. Это правильно.
Студия же при установке всегда сама хочет открывать все знакомые ей типы файлов.
Все признаки не надуманны, они реальны и раздражают. Это, конечно, мелочи, но когда их много, то происходит отказ от продукта. Например, я, начиная с Висты, отказался от Эксплорера в пользу Far'а. Тот стал жутко неудобным и раздражающим. Многое можно исправить, но мне лень его настраивать. Мне не нравятся типы столбцов в папках с мультимедиа файлами в табличном виде. Не нравится, что нельзя перейти в папку на уровень выше по backspace. И т.п.
.cpp файлы я также стал просматривать через Far. Это быстрей и удобней.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, c-smile, Вы писали:
CS>>На моей рабочей машине VS2010 стартует 12 секунд. WTF?
НС>Очень большая часть VS (и в частности то, что тормозит при стартапе, это я тебе как эксперт в этой области говорю) написана совсем не на .NET.
А я как эксперт в UI вообще говорю тебе что 500-700ms на загрузку такого UI — за глаза.
Т.е. я как и здесь присутствющие умеем это делать, а команда Visual Studio этого сделать не в состоянии?
CS>>Это какой-то эксперимент на живых людях. Кто-нибудь может внятно объяснить преимущества использования .NET для Visual Studio и в частности на кой там упал этот WTF (в смысле WPF)?
НС>Осталось доказать, что в тормозах студии виноват WPF. Вот VS2008 — там никакого WPF нет, а тормозит еще больше. Парадокс?
У меня стоят четыре студии: VS6, 2005, 2008, 2010.
График загрузки строго прямая линия VS6 самая быстрая — моментально и 2010 самая медленная — 4-12 сек — как карта ляжет.
Меня как пользователя по большому счету мало интересует что конкретно тормозит и почему.
Просто судя по графику — чем больше всяких кунштюк.NET в VS — тем хуже.
CS>>Я понимаю что нужен некий клеевой язык для того чтобы кучу добра склеить вместе.
НС>В студии нет никакого клеевого языка (если не считать таковым VB в макросах) и он там, вобщем то, не нужен.
VS6 это голый C++ и тот же самый VBS. Будем считать что VS2008 это VS6 + .NET. Дельта — это .NET.
Я делаю простой вывод — тормозит .NET.
CS>>Скажем я сравниваю со своим ScIDE (sciter based IDE: html/css/script + scintilla) — загрузка примерно того же UI по объему 200-400ms.
НС>Очень странно слышать от умного человека подобные сравнения. Тормозит в VS совсем не UI.
Напомню ScIDE это загрузка HTML/CSS и исполнение инициализирующих скриптов.
То что можно делать лениво при загрузке — делается лениво.
Или команда VS не слышала про ленивые вычисления или они просто не умеют .NET готовить или сам .NET просто фактом
своего наличия в процессе вешает всё. Я не знаю.
CS>>Я серьёзно не понимаю смысл этого безобразия.
НС>Так ты и не пытался понять.
Если честно я бы очень хотел знать что конкретно нужно прицепить к такому UI чтобы он так тормозил.
Дело в том что для меня VS это средство производсвта — работаю каждый день. И каждый день — frustration.
Я честно хотел бы в глаза VS иделогу (Borland.AndersHejlsberg ?) посмотреть и задать пару вопросов.
Это ж позорище какое-то. Как собственно стиль этого UI где авторы просто "забили" на предпочтения пользователя попирая все UI рекомендации самой MS. Так и скорость работы всего этого безобразия.
CS>>Ну не понимаю я. Меня как и всех остальных пользователей авторы Visual Studio явно не уважают.
НС>Они просто не могут.
Здравствуйте, BluntBlind, Вы писали:
BB> Не то чтобы это ответ, но некоторое разъяснение: BB> Мифы и заблуждения насчёт CLR и .NET
BB> Хорошая статья и по делу, и с юмором.
Здравствуйте, c-smile, Вы писали:
CS>На моей рабочей машине VS2010 стартует 12 секунд. WTF? К тому же при установке этот подлец поставил себя как viewer С++ файлов.
На моей приблизительно тоже самое. VS2008 стартует где-то 9 секунд. Надо признать, что разница не существенная.
Вот далее VS2010 во многом по медленнее, да и ошибок многовато пока что.
Но не заметить прогресс трудно. В прочем, возможно (что не мудрено) прогресс есть для дотнет-продуктов, а для плюсов нет.
CS>Это какой-то эксперимент на живых людях. Кто-нибудь может внятно объяснить преимущества использования .NET для Visual Studio и в частности на кой там упал этот WTF (в смысле WPF)?
За WPF будущее. Многослойный ренедеринг, 3D-акселерация и туча других фенек. Со временем железо дорастет, плюс софт подточят и будет летать.
Со всеми новыми студиями было так. Каждая студия на фоне предыдущей казалось тормозом. Скажем, разве можно сравнить скорость загрузки и работы VS 6 и VS .Net (2002)? Но со временем она стала весьма приемлемой.
CS>Я понимаю что нужен некий клеевой язык для того чтобы кучу добра склеить вместе. Но оно же бувально не едет в том виде что сделан.
Причем тут язык?
CS>Скажем я сравниваю со своим ScIDE (sciter based IDE: html/css/script + scintilla) — загрузка примерно того же UI по объему 200-400ms.
Назвать scintill-у "примерно таким же UI" можно только если совсем не вдаваться в подробности. Это продукты даже не разного класса, а разного поколения. Это все равно что сравнить Word 95 и Word 6 для доста.
CS>Я серьёзно не понимаю смысл этого безобразия. Типа надо же хотя бы куда-то это пристроить?
А ты попробуй пописать на шарпе. Тогда поймешь. За одно погляди на плагины (которые уже имеются в не малом количестве). В завершении скачай VS SDK (он теперь совсем мелким стал) и погляди примеры расширяемости. Думаю — это тебе все объяснит.
CS>Ну есть же у них команда делающая тот же Office... Который в плане UI даже покруче-то будет.
Нет, спасибо. На Word 2007+ я так и не перешел, и переходить не буду видимо. Скорость его ГУЯ мне безразлична, так как он изменен до безобразия. А вот студия, не смотря на то что гуй и редактор кода переписаны на 100%, все же сохранил традиционный интерфейс и мне не нужно переучиваться. При этом функциональность и удобство расширелись. Так что рано или поздно я перейду на VS2010 (она уже стоит и иногда используется, но пока редко).
CS>Ну не понимаю я. Меня как и всех остальных пользователей авторы Visual Studio явно не уважают.
Они как раз уважают. Вот те кто делал Офис — своих старых пользователей не в грош не ставят. Им важнее нюбы. Ну, и хер с ними.
ЗЫ
А вьюером студия всегда не разумно было использовать. И потом у тебя что нет Тотал Командера или Фара? Им никакие ОС-овские файловые ассоциации никогда не мешали.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>Как бы Java умеет грузить классы on-demand. Я уже не говорю про скрипты.... CS>Почему здесь нельзя сделать то же?
Здесь тоже делается. Из-за того и многие тормоза при работе (уже после загрузки).
Но в дотнете единицей загрузки является сборка, а они могут быть большими и требовать инициализации. К тому же WPF тоже требует инициализации и является очень большой сборкой. Но после кэширования в памяти все работает вполне приемлемо. Повторная загрузка студии занимает на моей машине не более 2 секунд. Старая (2008-я) студия даже похоже что медленнее повторно грузится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>И что? Во времена когда наши ракеты бороздят просторы нельзя сделать загрузку этого solution хотя бы за секунду? CS>Чем в принципе загрузка C++ solution в VS6 скажем и в VS2010 отличаются? Время загрузки выросло в 20 раз.
Хотябы качеством интеллисенса. В 6-е оно было на уровне плинтуса.
Да... на той технике 6-ка тоже грузилась не моментально.
CS>Я к тому что выбор неадекватных средств/технологий для решения задачь есть базовая ошибка проектирования.
Тут скорее неадекватное использование. На самом деле ребят надо похвалить за то что они силами кучи индусов заставили взлететь такой проект.
CS>...То же — и про Android. Т.е. в mobile это оправдано.
Причем тут мобильники?
И вообще, ты уже немного достал своим предубездением о том, что дотнет — это медленно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>Если у тебя есть шароварный продукт А который сделан на WPF. CS>И тут появляется на рынке некий другой продукт Б который "навроде" как А но нативный. CS>Кто победит? Ты можешь до посинения объяснять юзерам что "у нея душа красивая". Денег у тебя больше не будет от этого.
Хороший подход! Теперь назови конкурентные продукты. Кто там побеждает? Студия? Ну, а тогда не фига напраслину гнать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, MxMsk, Вы писали:
MM>Я специально обратился на "вы", потому что это не персонально тебе, а скорее к сообществу тех программеров, которые и месяца не могут прожить, не пройдясь по .Net.
Кстати, это хорошо что такие есть и их много. Пусть люди из МС слушают и матают на ус. Дотнет конечно не так страшен как его малюет Ц-смайл, но все же его еще оптимизировать и оптимизировать.
И очень хорошо, что на дотнете стали писать реальный десктопный софт, так как это тоже поможет сделать дотнет (и его библиотеки) быстрее и лучше.
Все это вместе работает на качество дотента. В 4-е и WPF реально улучшили, и скорость дотнета повысили.
Главное чтобы не останавливались!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ytz, Вы писали:
Ytz>Видимо аура HTMLlayout не позволяет, вот у меня к примеру секунды за 3 стартует.
Все очень просто. Вы называете время горячей загрузки, а он холодной. У меня тоже холодная загрузка 12 секунд, а горячая около двух.
Просто уважаемый Ц-смайл забывает сказать, что холодная загрузка 2008-ой студии ~9 секунд, а горячая тоже около двух.
CS>>ScIDE максимально близка к VS — та же структура экрана и количество UI элементов. Ytz>Запорожец максимально близок к болиду Формулы 1 — те же четыре колеса, руль, двигатель внутреннего сгорания.
+1
Сравнить перередактов/не-IDE с одной из самый современных IDE — это было сильно!
Кстати, о более честных сравнениях. Сколько в горячую и в холодную грузится, скажем, Эклипс? А сколько Идея?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hattab, Вы писали:
H>А я уже говорил когда-то, что готов простить относительно медленный запуск тяжелому софту. Той же студии, тем же дельфям или джимпу. Но не нужно переводить стрелки с банального редактора с подсветкой на монстров вроде фотошопа. Что позволено Юпитеру, то быкам не засияет.
Вообще-то этот "монстр" в 99% случаев используется как MS Paint++. Так что как раз ему-то было бы логично грузиться и по бытрее.
Потом странная логика. Сначала речь о том что тормозит именно дотент, а потом резкий переход на монстров. Так может кое что зависит от объемов кода в продукте, а не только от того на дотнете он или нет?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hattab, Вы писали:
MM>> Ах, прелестно. Было бы в Фотошопе хоть что-нибудь дотНетовского, фиг бы ты написал подобное.
H>В студии есть, однако же написал
Ну, а где логика то? А то вот продукт, сравнимый с фотошопом по возможностям (фотошоп конечно круче в деталях, но большинству они безразличный) — Paint.NET запускается неимоверно быстрее! Он даже быстрее Пэинта грузится!
Та что обсудим недостатки нэйтив кода для десктопа?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Какая именно технология? .NET, WPF? Каким образом ты определяешь, что тормоза при загрузке студии связаны именно с WPF? Она и раньше грузилась не быстро. Кстати, как я понимаю, она все равно до сих пор не 100% .NET (собственно, скорее даже далеко не 100%, раз ее на 64 бита до сих пор перевести не могут). Так что не исключено, что "долго работает" там как раз код, написанный на С++.
Я думаю, нет я уверен, что конечно же .NET и WPF вносят свою лепту в скорость загрузки. Они не могут не вносить хотя бы потому, что и то, и другое это ДЛЛ-и весьма не малого размера и не в немалом количестве.
Но согласен, что конечно же время загрузки складывается из общего времени загрузки всех минимально необходимых модулей. И некоторые из них конечно же не менеджед.
Кстати, проблему с временем загрузки на машинах где студию надо грузить часто можно решить написав небольшую резидентную программу которая будет тупо проецировать основные модули студии в память и удерживать занятую память путем ее сканирования раз в несколько секунд.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD> MM>> Ах, прелестно. Было бы в Фотошопе хоть что-нибудь дотНетовского, фиг бы ты написал подобное.
VD> H>В студии есть, однако же написал
VD> Ну, а где логика то?
Логика проста: тяжелому софту я прощу долгий запуск вне зависимости о того, с использованием какой технологии он разработан. Так понятно?
VD> А то вот продукт, сравнимый с фотошопом по возможностям (фотошоп конечно круче в деталях, но большинству они безразличный) — Paint.NET запускается неимоверно быстрее! Он даже быстрее Пэинта грузится!
Еще один догадался сравнивать Paint.NET с фотошопом Влад, вот от тебя то я никак не ожидал. Касаемо Paint'а, он стартует сильно быстрее Paint.NET'а, раза этак в 4 (у обоих запуск холодный. Win 7 x64 8Gb)
VD> Та что обсудим недостатки нэйтив кода для десктопа?
Дык обсуждать нечего Сравнимые продукты уделывают дотнет в пух и прах. Я как-то тут тесты скорости работы фильтра Gaussian Blur приводил, для Paint.NET и GIMP. Paint.NET сливает со свистом, даже на 4-головом проце, все ядра которого, он, в отличии от GIMP'а, использует.
Здравствуйте, VladD2, Вы писали:
VD> H>А я уже говорил когда-то, что готов простить относительно медленный запуск тяжелому софту. Той же студии, тем же дельфям или джимпу. Но не нужно переводить стрелки с банального редактора с подсветкой на монстров вроде фотошопа. Что позволено Юпитеру, то быкам не засияет.
VD> Вообще-то этот "монстр" в 99% случаев используется как MS Paint++. Так что как раз ему-то было бы логично грузиться и по бытрее.
Это ведь проблемы тех кто использует кузнечный молот для забивания гвоздиков, не так ли?
VD> Потом странная логика. Сначала речь о том что тормозит именно дотент, а потом резкий переход на монстров. Так может кое что зависит от объемов кода в продукте, а не только от того на дотнете он или нет?
Здравствуйте, VladD2, Вы писали:
VD>Я думаю, нет я уверен, что конечно же .NET и WPF вносят свою лепту в скорость загрузки. Они не могут не вносить хотя бы потому, что и то, и другое это ДЛЛ-и весьма не малого размера и не в немалом количестве. VD>Но согласен, что конечно же время загрузки складывается из общего времени загрузки всех минимально необходимых модулей. И некоторые из них конечно же не менеджед.
Я тут рядом писал, что #Develop 4, который 100% managed и вроде как тоже на WPF, у меня загружается вместе с проектом за ~1 сек. на процессоре среднего сегмента. Здесь речь идет о 12. Во-первых, даже на древнючем целероне у меня 2010-я студия не грузится за такое время. Во-вторых,
VD>Кстати, проблему с временем загрузки на машинах где студию надо грузить часто можно решить написав небольшую резидентную программу которая будет тупо проецировать основные модули студии в память и удерживать занятую память путем ее сканирования раз в несколько секунд.
Да нет такой проблемы, ее придумал c-smile с целью раздуть очередной бессмысленный флейм.
Здравствуйте, VladD2, Вы писали:
VD> И очень хорошо, что на дотнете стали писать реальный десктопный софт, так как это тоже поможет сделать дотнет (и его библиотеки) быстрее и лучше.
VD> Все это вместе работает на качество дотента. В 4-е и WPF реально улучшили, и скорость дотнета повысили.
Ага, то-то Evernote ломанулись с дотнета обратно на C++ Это в тысячу раз показательнее нескольких бесплатных софтин и гуя автокада.
Здравствуйте, hattab, Вы писали:
H>Логика проста: тяжелому софту я прощу долгий запуск вне зависимости о того, с использованием какой технологии он разработан. Так понятно?
Не понятна логика по которой софт делится на "тяжелый" и "легкий".
Мне кажется критерии должны быть другими. Медленная загрузка — это несомненный минус для любого продукта (даже сервера приложений этерпрайз-уровня). Но у любого продукта есть как минусы, так и плюсы. Если бы плсюсом студии было только то, что она может показать и отредактирвовать С++-файл, то конечно такой продукт был бы мало кому интересен. Но это все же IDE в чьи функции входит, главным образом, возможность облегчить развитие больших проектов. И тут мы готовы терпеть 12 секунд на первую загрузку даже на шустрой технике.
Тот же Фотожоп — это такой же продукт. И его тормоза очень огорчают. Если я занимаюсь версткой, подготовкой обложе и т.п., то я готов терпеть даже такие неадекватные тормоза. Но если я какой-нить веб-дизайнер, или еще прикольнее — программист которому нужно нарисовать png с прозрачностью, то конечно такое поведение будет очень неприятным и скорее всего я выберу тот самый Paint.Net, так как он загружается в сотни раз быстрее, но при этом выполняет нужные мне функции (о цене я скромно умолчу, так как мы живем в стране победившего коммунизма).
VD>> А то вот продукт, сравнимый с фотошопом по возможностям (фотошоп конечно круче в деталях, но большинству они безразличный) — Paint.NET запускается неимоверно быстрее! Он даже быстрее Пэинта грузится!
H>Еще один догадался сравнивать Paint.NET с фотошопом
Я тебе больше скажу, я в не давнем прошлом проффесиональный пользователь фотошопа. Он и сейчас у меня стоит. Только пользуюсь я действительно Paint.NET-ом. Мой коллега, пользуется Фотошопом, но он отнюдь не рад его тормозам.
H>Влад, вот от тебя то я никак не ожидал. Касаемо Paint'а, он стартует сильно быстрее Paint.NET'а, раза этак в 4 (у обоих запуск холодный. Win 7 x64 8Gb)
Да нифига. В горячую они стартуют (у меня) одинаково. А в холодную Paint.NET стартует быстрее. Причем это не фокус. Просто сборки дотнета у меня закэшированы другими приложениями.
Иной раз я запускал Paint.NET для сохранения каждого скриншота. И делать это в нем сильно удобнее чем в Paint-е.
VD>> Та что обсудим недостатки нэйтив кода для десктопа?
H>Дык обсуждать нечего Сравнимые продукты уделывают дотнет в пух и прах.
Только в твоем воображении. А на практике Paint.NET намного чаще использую Paint.NET нежели Фотошоп, хотя он стоит на машине.
H>Я как-то тут тесты скорости работы фильтра Gaussian Blur приводил, для Paint.NET и GIMP. Paint.NET сливает со свистом, даже на 4-головом проце, все ядра которого, он, в отличии от GIMP'а, использует.
А мне огромные файлы без надобности. Я обложки не верстаю. Да и обложки по нашим временам не являются очень уж большими. Вот только что попробовал гаусово рамытие на картикне из примеров (не маленькая такая, как раз на А4 при печати потянет). И что я вижу? А вижу практически реалтайм. Превью дольше отрабатывает чем сам фильр.
Так что не надо "ля-ля".
К тому же такие вещи как фильты просто глупо тупо на ЦП выполнять. Тут ни С++, ни Дельфи, ни дотнет ничего хорошего не дадут. Тут надо использовать грубую силу. И их есть у меня. Даже для немрела есть две библиотеки позволяющие перекладывать подобные вычисления на видюху. Возможно так и сделано в пэинт.нэт. А у тебя просто слабая видеокарта .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hattab, Вы писали:
VD>> Вообще-то этот "монстр" в 99% случаев используется как MS Paint++. Так что как раз ему-то было бы логично грузиться и по бытрее.
H>Это ведь проблемы тех кто использует кузнечный молот для забивания гвоздиков, не так ли?
В общем, да. Тоже самое справидливо и для VS sv. Сцинтила. Я тоже не использую VS 2010 (да никакую не использую) для просмотра файлов на диске. Для этого у меня на F4 (в ТоталКомандире) повешена та самая Сцинтила. И, кстати, сцинтилой я недоволен. Как редактор она намного хуже студийного.
VD>> Потом странная логика. Сначала речь о том что тормозит именно дотент, а потом резкий переход на монстров. Так может кое что зависит от объемов кода в продукте, а не только от того на дотнете он или нет?
H>Ну так стрелки-то перевел не я
Это не важно. Но стрелки как раз переведены правильно. Потому как дело все же не в дотнете и его непригодности для чего-то. А в продуктах. Мой редактор кода тоже стартовал молниеносно, не смотря на то что был написан на дотнете. Но я прекрасно понимаю, что он и VS — это продукты разного класса и для разных задач.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, VladD2, Вы писали:
VD>>Я думаю, нет я уверен, что конечно же .NET и WPF вносят свою лепту в скорость загрузки. Они не могут не вносить хотя бы потому, что и то, и другое это ДЛЛ-и весьма не малого размера и не в немалом количестве. VD>>Но согласен, что конечно же время загрузки складывается из общего времени загрузки всех минимально необходимых модулей. И некоторые из них конечно же не менеджед.
ВВ>Я тут рядом писал, что #Develop 4, который 100% managed и вроде как тоже на WPF, у меня загружается вместе с проектом за ~1 сек. на процессоре среднего сегмента. Здесь речь идет о 12. Во-первых, даже на древнючем целероне у меня 2010-я студия не грузится за такое время. Во-вторых,
Ну, это ты откровенно выдумываешь. У меня есть мелкая утилитка (без ВПФ и других шлюх) на дотнете. Так вот она даже будучи прекомпилированной все равно в холодную может грузиться по 3-4 секунды. Тут уж ничего не поделашь, кучу библиотек нужно загрузить в память.
VD>>Кстати, проблему с временем загрузки на машинах где студию надо грузить часто можно решить написав небольшую резидентную программу которая будет тупо проецировать основные модули студии в память и удерживать занятую память путем ее сканирования раз в несколько секунд.
ВВ>Да нет такой проблемы, ее придумал c-smile с целью раздуть очередной бессмысленный флейм.
Вообще-то есть. И проблема выгрузки VS 2010 из памяти тоже есть. Просто чем больше у тебя памяти, тем менее она заметна.
ЗЫ
Кстати, я ее попользовал и сразу же обнаружил ряд багов. Не фатальных, но все же. А совсем недавно кто-то с пеной у рта доказывал обратное. Так что верить людям надо с осторожностью. Предвзятость заставляет одного раздуть из мухи слона, а другого не замечать очевидного.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hattab, Вы писали:
H>Ага, то-то Evernote ломанулись с дотнета обратно на C++ Это в тысячу раз показательнее нескольких бесплатных софтин и гуя автокада.
У меня другая проблема — я не знаю кто такой Evernote.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, это ты откровенно выдумываешь. У меня есть мелкая утилитка (без ВПФ и других шлюх) на дотнете. Так вот она даже будучи прекомпилированной все равно в холодную может грузиться по 3-4 секунды. Тут уж ничего не поделашь, кучу библиотек нужно загрузить в память.
Что выдумываю? Я проверял, с целью эксперимента скачал #Develop 4. С не очень большим по размеру проектом загружается за секунду на Core i5 750. И студия 2010-я у меня тоже 12 секунд не грузится, где бы я ни работал. Может, конечно, у человека проект гигантских размеров и на С++, у которого интеллисенс вроде как прокачали, и он может при загрузке проекта какую-нибудь базу строить. Тут не знаю. Но тогда опять же получается, что С++ виноват, а никак не WPF
VD>>>Кстати, проблему с временем загрузки на машинах где студию надо грузить часто можно решить написав небольшую резидентную программу которая будет тупо проецировать основные модули студии в память и удерживать занятую память путем ее сканирования раз в несколько секунд.
ВВ>>Да нет такой проблемы, ее придумал c-smile с целью раздуть очередной бессмысленный флейм. VD>Вообще-то есть. И проблема выгрузки VS 2010 из памяти тоже есть. Просто чем больше у тебя памяти, тем менее она заметна.
Ну меня не очень парит подождать пару лишних секунд, пока она загружается. На рабочем компе, кстати, 2ГБ — тоже не сказать, что сильно страдаю.
VD>Кстати, я ее попользовал и сразу же обнаружил ряд багов. Не фатальных, но все же. А совсем недавно кто-то с пеной у рта доказывал обратное. Так что верить людям надо с осторожностью. Предвзятость заставляет одного раздуть из мухи слона, а другого не замечать очевидного.
Здравствуйте, VladD2, Вы писали:
VD> H>Логика проста: тяжелому софту я прощу долгий запуск вне зависимости о того, с использованием какой технологии он разработан. Так понятно?
VD> Не понятна логика по которой софт делится на "тяжелый" и "легкий".
Я тебе расскажу Тяжелый софт это тот, который рассчитан на профессиональное использование и покрывает если не все, то большую часть требований его профессиональных пользователей. Это если формально. Как программист ты прекрасно должен понимать, что при инициализации "тяжелого", оный может выполнять некоторую работу заблаговременно. Например, он может грузить сотню-другую плагинов, компилировать скрипты, кешировать миниатюры изображений и вообще как угодно подготавливать себя к продолжительному сеансу работы. И это для тяжелого софта нормально. Касаемо студии, к ней у меня лично претензий нет, мне не требуется запускать ее по нескольку раз в день, а однократный запуск я переживу.
VD> Тот же Фотожоп — это такой же продукт. И его тормоза очень огорчают. Если я занимаюсь версткой, подготовкой обложе и т.п., то я готов терпеть даже такие неадекватные тормоза. Но если я какой-нить веб-дизайнер, или еще прикольнее — программист которому нужно нарисовать png с прозрачностью, то конечно такое поведение будет очень неприятным и скорее всего я выберу тот самый Paint.Net, так как он загружается в сотни раз быстрее, но при этом выполняет нужные мне функции (о цене я скромно умолчу, так как мы живем в стране победившего коммунизма).
Ну так ты правильно говоришь, если тебе нужно отрисовать png с прозрачность, нафига тебе брать фотошоп Все верно. Бери Paint.NET, только не сравнивай его с фотошопом со своей png-с-прозрачностью колокольни.
VD> H>Еще один догадался сравнивать Paint.NET с фотошопом
VD> Я тебе больше скажу, я в не давнем прошлом проффесиональный пользователь фотошопа. Он и сейчас у меня стоит. Только пользуюсь я действительно Paint.NET-ом. Мой коллега, пользуется Фотошопом, но он отнюдь не рад его тормозам.
И ты, как профессиональный в прошлом пользователь фотошопа, хочешь сказать, что Paint.NET обеспечивает тот же уровень решения профессиональных задач, что и фотошоп? Я тебе просто не поверю.
VD> H>Влад, вот от тебя то я никак не ожидал. Касаемо Paint'а, он стартует сильно быстрее Paint.NET'а, раза этак в 4 (у обоих запуск холодный. Win 7 x64 8Gb)
VD> Да нифига. В горячую они стартуют (у меня) одинаково. А в холодную Paint.NET стартует быстрее. Причем это не фокус. Просто сборки дотнета у меня закэшированы другими приложениями.
Хм, предлагаешь мне глазам своим не верить? У меня тоже запущены .NET прилаги, ATI облагодетельствовала. Проверил на горячий — Paint.NET (3.5.1) медленне стартует, и это видно на глаз
VD> H>Дык обсуждать нечего Сравнимые продукты уделывают дотнет в пух и прах.
VD> Только в твоем воображении. А на практике Paint.NET намного чаще использую Paint.NET нежели Фотошоп, хотя он стоит на машине.
Я понимаю, что для png-с-прозрачностью ты можешь использовать хоть утиль самописную, которая отработает раньше, чем фотошоп запустится. Однако, это ни как не указывает на скорость дотнета, увы.
VD> H>Я как-то тут тесты скорости работы фильтра Gaussian Blur приводил, для Paint.NET и GIMP. Paint.NET сливает со свистом, даже на 4-головом проце, все ядра которого, он, в отличии от GIMP'а, использует.
VD> А мне огромные файлы без надобности. Я обложки не верстаю. Да и обложки по нашим временам не являются очень уж большими. Вот только что попробовал гаусово рамытие на картикне из примеров (не маленькая такая, как раз на А4 при печати потянет). И что я вижу? А вижу практически реалтайм. Превью дольше отрабатывает чем сам фильр.
И я огромные файлы не использовал 1920x1200 всего-то. Просто радиус размытия был 200px.
VD> Так что не надо "ля-ля".
Да никакого ля-ля. Все подтверждалось цифрами Любой проверить мог.
VD> К тому же такие вещи как фильты просто глупо тупо на ЦП выполнять. Тут ни С++, ни Дельфи, ни дотнет ничего хорошего не дадут. Тут надо использовать грубую силу. И их есть у меня. Даже для немрела есть две библиотеки позволяющие перекладывать подобные вычисления на видюху. Возможно так и сделано в пэинт.нэт. А у тебя просто слабая видеокарта .
Производительность Paint.NET масштабируется по количеству ядер проца. У меня не 4 видюхи стояло
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Что выдумываю? Я проверял, с целью эксперимента скачал #Develop 4. С не очень большим по размеру проектом загружается за секунду на Core i5 750. И студия 2010-я у меня тоже 12 секунд не грузится, где бы я ни работал.
Речь идет о холодной загрузке. Если у тебя нет SSD, то по другому быть не может.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD> H>Ага, то-то Evernote ломанулись с дотнета обратно на C++ Это в тысячу раз показательнее нескольких бесплатных софтин и гуя автокада.
VD> У меня другая проблема — я не знаю кто такой Evernote.
Здравствуйте, VladD2, Вы писали:
VD> VD>> Потом странная логика. Сначала речь о том что тормозит именно дотент, а потом резкий переход на монстров. Так может кое что зависит от объемов кода в продукте, а не только от того на дотнете он или нет?
VD> H>Ну так стрелки-то перевел не я
VD> Это не важно. Но стрелки как раз переведены правильно.
Вот и пойми тебя, то логика странная, то теперь стрелки правильно переведены
VD> Потому как дело все же не в дотнете и его непригодности для чего-то. А в продуктах. Мой редактор кода тоже стартовал молниеносно, не смотря на то что был написан на дотнете. Но я прекрасно понимаю, что он и VS — это продукты разного класса и для разных задач.
Ну вот Windows PowerShell ISE (не сильно сложнее редактора с подстветкой) не стартует молниеносно, она вообще кое как выкарабкивается. Снапины MMC'шные вообще кое как шевелятся, особенно шедалер. Показательно, весьма и весьма.
Здравствуйте, hattab, Вы писали:
H>Я тебе расскажу Тяжелый софт это тот, который рассчитан на профессиональное использование и покрывает если не все, то большую часть требований его профессиональных пользователей.
Обосновал отрок, но припохабно... (с) анекдот.
H>Это если формально.
Что уж тут формального? Это наукообразно оформленные домыслы.
По мне так все просто. Тяжелый софт — это софт который много весит. Тормозной софт — это тот что много тормозит. А профессиональный — это тот что работу позволяет выполнять.
H>Как программист ты прекрасно должен понимать, что при инициализации "тяжелого", оный может выполнять некоторую работу заблаговременно.
Как программист я понимаю, что это отмазки.
H>Например, он может грузить сотню-другую плагинов,
Которые с вероятностью 99% не понадобятся даже очень крутому проффесионалу все в одной сессии.
H>компилировать скрипты,
Это вообще какой-то оксюморон. Или они скрипты или их компилируют. Но даже если что-то надо компилировать, то есть технолгии позволяющие сделать это один раз и не мучить пользователя при каждой загрузке.
H>кешировать миниатюры изображений
Тот же аргумент.
H>и вообще как угодно подготавливать себя к продолжительному сеансу работы.
Лучше не как удобно, а быстро.
H>И это для тяжелого софта нормально. Касаемо студии, к ней у меня лично претензий нет, мне не требуется запускать ее по нескольку раз в день, а однократный запуск я переживу.
А они тяжелый софт? Ну, вроде как она тоже может и сктипты компилирвоать, и сотню плагинов (она же контейнер!) грузить?
Так давай объясним это Ц-смайлу. Ведь вся суть этой тему в том что студия грузится в холодную на на 15 процентов медленнее старой версии.
VD>> Тот же Фотожоп — это такой же продукт. И его тормоза очень огорчают. Если я занимаюсь версткой, подготовкой обложе и т.п., то я готов терпеть даже такие неадекватные тормоза. Но если я какой-нить веб-дизайнер, или еще прикольнее — программист которому нужно нарисовать png с прозрачностью, то конечно такое поведение будет очень неприятным и скорее всего я выберу тот самый Paint.Net, так как он загружается в сотни раз быстрее, но при этом выполняет нужные мне функции (о цене я скромно умолчу, так как мы живем в стране победившего коммунизма).
H>Ну так ты правильно говоришь, если тебе нужно отрисовать png с прозрачность, нафига тебе брать фотошоп
Дык это 99% задач что им решают (ежики колются, плачут, но продолжают жрать кактус).
H>Все верно. Бери Paint.NET, только не сравнивай его с фотошопом со своей png-с-прозрачностью колокольни.
Беру. И со студией так же поступлю, если ее преимущества превысят ее недостатки. И кстати, я пока что 2010 использую редко. Но не потому что она уж так медленна, а потому что для моего любимого языка к ней нет интеграции. Сделаем интеграцию и буду ее использовать.
H>И ты, как профессиональный в прошлом пользователь фотошопа, хочешь сказать, что Paint.NET обеспечивает тот же уровень решения профессиональных задач, что и фотошоп? Я тебе просто не поверю.
Нет конечно. Если говорить о допечатной подготовке, то Фотошоп имеет ряд функций (прямо в поставке, без плагинов) которые тупо отсутсвтуют в Пэйнт-нетах и Гимпах. Например, в нем есть качественное управление цветами, перевод из разных РЖБ в ЦМИК и т.п. Но это очень узкоспециализированные штуки и именно из-за них в основном мы и терпим тормоза Фотошопа.
Но, как ты верно заметил, я действительно программист и это дает мне понять, что те самые тысячи плагинов можно было бы не грузить при старте приложения, а загружать тогда кода пользователь хочет воспользоваться этим плагином. Те же фильтры — отличный пример.
Кстати, в студии так и сделано. Даже больше. Там прямо части студии подгружаются по трбовнию, что иногда даже является перебором. Но в разумных пределах — это отличный подход.
H>Хм, предлагаешь мне глазам своим не верить? У меня тоже запущены .NET прилаги, ATI облагодетельствовала. Проверил на горячий — Paint.NET (3.5.1) медленне стартует, и это видно на глаз
Я верю своим глазам. Зачем мне верить или не верить чужим? Лично я чихнуть не успеваю как Paint.NET (3.55) уже открыт.
H>Я понимаю, что для png-с-прозрачностью ты можешь использовать хоть утиль самописную, которая отработает раньше, чем фотошоп запустится. Однако, это ни как не указывает на скорость дотнета, увы.
Ну, дык я же не создаю темы "Нэйтив — отстой, так как Фотошоп медленно грузится". Правда?
Ты бы такую тему точно посчитал неадекватной. А данндую тему ты почему-то таковой не признаешь. Хотя разницы никакой. Мощную, профессиональную IDE сравнивают с редактором кода к которому прикручен список файлов. Это ничем не отличается от сравнения Paint.NET-а с Фотошопом. Даже более того. Все же Paint.NET воспроизводит очень многое что умеет Фотошоп. А о Сцинтиле такого не скажешь.
H>И я огромные файлы не использовал 1920x1200 всего-то. Просто радиус размытия был 200px.
А зачем так сложно получать грязные пятна?
В прочем, сейчас попробовал, получилось 6 секунд. Причем работа шла уже в превью и в это же время можно было изменять значения. Так что когда я нажал ОК, то изображение изменилось моментально. Этого более чем достаточно для удобной работы. А уже если сравнить цены пакетов...
H>Да никакого ля-ля. Все подтверждалось цифрами Любой проверить мог.
Ну. вот я цифрами и проверил. Разумное размытие (до 20%) происходит в реалтайме. А то что граничный случий чуть медленнее — это никого не трогает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hattab, Вы писали:
H>Ну вот Windows PowerShell ISE (не сильно сложнее редактора с подстветкой) не стартует молниеносно, она вообще кое как выкарабкивается. Снапины MMC'шные вообще кое как шевелятся, особенно шедалер. Показательно, весьма и весьма.
Казалось бы причем тут дотнет? Ну, написана софтина так. А Paint.Net молниеносно стартует не смотря на свою дотнетность. И что?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
CS>>Это какой-то эксперимент на живых людях. Кто-нибудь может внятно объяснить преимущества использования .NET для Visual Studio и в частности на кой там упал этот WTF (в смысле WPF)?
VD>За WPF будущее. Многослойный ренедеринг, 3D-акселерация и туча других фенек. Со временем железо дорастет, плюс софт подточят и будет летать.
Ах будущее... ну да ... наверное. Когда-то и память не будет ресурсом ... но всё как-то ресурс пока. Даже если размер самой памяти еще растет то скорости CPU нужные для того чтобы забить эту память как-то не сильно растут.
А по поводу многослйного ренедеринг и акселерации — ну есть же Direct2D.
Я правда не понимаю этот велосипед он до или после WPF был сделан ...
VD>Со всеми новыми студиями было так. Каждая студия на фоне предыдущей казалось тормозом. Скажем, разве можно сравнить скорость загрузки и работы VS 6 и VS .Net (2002)? Но со временем она стала весьма приемлемой.
Ну вот хоть тресни но я не понимаю почему следующая должна быть тормозом.
Я лично пытаюсь чтобы сдедующие версии моих продуктов были быстрее предыдущих. Вроде как получается.
Я что-то пропустил в принципе?
CS>>Я понимаю что нужен некий клеевой язык для того чтобы кучу добра склеить вместе. Но оно же бувально не едет в том виде что сделан.
VD>Причем тут язык?
"Оно" здесь это не язык а метафоричекское название этого программного продукта в целом.
CS>>Скажем я сравниваю со своим ScIDE (sciter based IDE: html/css/script + scintilla) — загрузка примерно того же UI по объему 200-400ms.
VD>Назвать scintill-у "примерно таким же UI" можно только если совсем не вдаваться в подробности. Это продукты даже не разного класса, а разного поколения. Это все равно что сравнить Word 95 и Word 6 для доста.
Там кроме Scintilla еще много чего грузится. Например строится code outline документа — т.е. парсинг в темпе валься исполняется. Да и весь UI в ScIDE это HTML/CSS и скрипты.
Т.е при загрузке я успеваю распарсить HTML, стили и скрипты, а они восемь секунд загружают откомпилирванный код? Это как я понимаю называется современный дизайн?
И кстати Scintilla не сильно отличается от редактора VS2010 по фичам. Да и шрифты она (через GDI) рисует гуманнее чем WPF.
VD>ЗЫ VD>А вьюером студия всегда не разумно было использовать. И потом у тебя что нет Тотал Командера или Фара? Им никакие ОС-овские файловые ассоциации никогда не мешали.
Да? а почему тогда оно себя на .h/.cpp/.cs файлы ставит? Кто-то забыл галку убрать?
Здравствуйте, VladD2, Вы писали:
VD> H>Например, он может грузить сотню-другую плагинов,
VD> Которые с вероятностью 99% не понадобятся даже очень крутому проффесионалу все в одной сессии.
Во-первых совсем не факт, во-вторых это избавляет от задержек при загрузках on demand.
VD> H>компилировать скрипты,
VD> Это вообще какой-то оксюморон. Или они скрипты или их компилируют. Но даже если что-то надо компилировать, то есть технолгии позволяющие сделать это один раз и не мучить пользователя при каждой загрузке.
Влад, ты не в курсе, что скрипты компилируют Хранить байткод не всегда оправданно, и не всегда возможно.
VD> H>кешировать миниатюры изображений
VD> Тот же аргумент.
А что тебе не нравится? Скажем в GIMP'е миниатюры шрифтов и кистей формируются on demand, но лучше бы он их кешировал на старте.
VD> H>и вообще как угодно подготавливать себя к продолжительному сеансу работы.
VD> Лучше не как удобно, а быстро.
Лучше, чтоб работать в дальнейшем было удобно, а не втупляться на задержки.
VD> H>И это для тяжелого софта нормально. Касаемо студии, к ней у меня лично претензий нет, мне не требуется запускать ее по нескольку раз в день, а однократный запуск я переживу.
VD> А они тяжелый софт? Ну, вроде как она тоже может и сктипты компилирвоать, и сотню плагинов (она же контейнер!) грузить?
Студия несомненно тяжелый софт. Я это неоднократно написал
VD> H>Ну так ты правильно говоришь, если тебе нужно отрисовать png с прозрачность, нафига тебе брать фотошоп
VD> Дык это 99% задач что им решают (ежики колются, плачут, но продолжают жрать кактус).
Мне жаль ежиков, но это не мои проблемы
VD> Но, как ты верно заметил, я действительно программист и это дает мне понять, что те самые тысячи плагинов можно было бы не грузить при старте приложения, а загружать тогда кода пользователь хочет воспользоваться этим плагином. Те же фильтры — отличный пример.
Задержки в процессе работы сильно хуже задержек на старте. Я один раз запустил весь тяжелый софт, а потом только hibernate.
VD> Кстати, в студии так и сделано. Даже больше. Там прямо части студии подгружаются по трбовнию, что иногда даже является перебором. Но в разумных пределах — это отличный подход.
Да, я помню, как ждал, пока откроется диалог с настройками, чуть не помрэ
VD> Ну, дык я же не создаю темы "Нэйтив — отстой, так как Фотошоп медленно грузится". Правда? VD> Ты бы такую тему точно посчитал неадекватной. А данндую тему ты почему-то таковой не признаешь. Хотя разницы никакой. Мощную, профессиональную IDE сравнивают с редактором кода к которому прикручен список файлов. Это ничем не отличается от сравнения Paint.NET-а с Фотошопом. Даже более того. Все же Paint.NET воспроизводит очень многое что умеет Фотошоп. А о Сцинтиле такого не скажешь.
Я тут сравнением студии с прочим не занимался Я тут говорил и говорю о времени загрузки мелочевки, которое сравнимо с тяжелым софтом (в основном, отвечая авторам на слова "при чем тут .NET").
VD> H>И я огромные файлы не использовал 1920x1200 всего-то. Просто радиус размытия был 200px.
VD> А зачем так сложно получать грязные пятна?
Для фонов весьма полезно и удобно
VD> В прочем, сейчас попробовал, получилось 6 секунд. Причем работа шла уже в превью и в это же время можно было изменять значения. Так что когда я нажал ОК, то изображение изменилось моментально. Этого более чем достаточно для удобной работы. А уже если сравнить цены пакетов...
Цены пакетов... Влад, как ты читаешь? Я же написал, что сравнивал Paint.NET и GIMP. Кстати, вот само сравнение
.
VD> H>Да никакого ля-ля. Все подтверждалось цифрами Любой проверить мог.
VD> Ну. вот я цифрами и проверил. Разумное размытие (до 20%) происходит в реалтайме. А то что граничный случий чуть медленнее — это никого не трогает.
Тест весьма показателен, когда разговор заходит о быстродействии дотнета.
Здравствуйте, VladD2, Вы писали:
VD> H>Ну вот Windows PowerShell ISE (не сильно сложнее редактора с подстветкой) не стартует молниеносно, она вообще кое как выкарабкивается. Снапины MMC'шные вообще кое как шевелятся, особенно шедалер. Показательно, весьма и весьма.
VD> Казалось бы причем тут дотнет? Ну, написана софтина так. А Paint.Net молниеносно стартует не смотря на свою дотнетность. И что?
PowerShell ISE так тупит из-за WPF-морды. Вот при чем тут дотнет?
Здравствуйте, c-smile, Вы писали:
CS>На моей рабочей машине VS2010 стартует 12 секунд. WTF? К тому же при установке этот подлец поставил себя как viewer С++ файлов. CS>Это какой-то эксперимент на живых людях. Кто-нибудь может внятно объяснить преимущества использования .NET для Visual Studio и в частности на кой там упал этот WTF (в смысле WPF)? CS>Я понимаю что нужен некий клеевой язык для того чтобы кучу добра склеить вместе. Но оно же бувально не едет в том виде что сделан.
Ничего ты не понимаешь!
Память-то растет. Скорость работы процессора тоже. Да еще многоядерность появилась.
Это чем-то занимать надо или нет ?
Вот представь себе — вместо всей этой прелести 2003-2005-2008-2010 взяла бы MS и улучшила VS6. Она тогда у меня на машине то ли с 64, то ли со 128 Мб работала вполне успешно, и отнюдь всю эту память не занимала. Ну заняла бы сейчас наполовину больше.
И аська, к примеру, тогда пару Мб занимала, а сейчас под сотню, как пишут.
И что бы было, если бы мы остались при тех же потребностях в памяти ?
Представляешь себе — 90% памяти все время свободно ? Представляешь себе — загрузка процессора все время близка к нулю ? Приложения просто летают.
Представил ?
Юзеры начинают недоуменные вопросы задавать. Зачем я эту память купил, если 90% ее не используется ? Зачем мне эти ядра, если и одно загрузить не удается ?
Где, черт вас возьми, программы, которые умеют эти мощности с толком использовать ? Хочу их!
А их нет.
Потому что, чтобы их написать — надо силы потратить не на заботу о memory leak и не на борьбу с access violation. А придется эти силы бросить на разработку новых алгоритмов, новых идей и т.п. А для этого специалисты нужны. а не "специалисты".
А когда юзер видит, что программа стартует 10 секунд и ест 500 Мб, он проникается благоговением к ее неизмеримой сложности и идет в магазин покупать новую память и процессор.
Раз уж КСВ...
Давно интересует вопрос: зачем в платформах NET и Java сделана JIT компиляция? Есть, допустим, есть какой-нибудь нотепад на .NET, который я запускаю каждый день по несколько раз. И каждый день по несколько раз происходит компиляция программы. Путь не из исходников, а из специального двоичного формата, но все равно — каждый день ресурсы компа расходуются по сути на ОДНО И ТО ЖЕ.
Преимущества "виртуального" двоичного кода понятны — можно запускать софт на разных платформах, под разными ОС и т.д.
Но что, товарищи из Microsoft предполагают, что у меня сегодня 32-битная Винда, за ночь она сама самомодифицировалась в 64-битную (да, вместе с аппаратной платформой:) ), а еще через день переписала себя в Linux???
Очевидно, система одна и та же в течение месяцев и даже лет, и результат JIT компиляции изо дня в день будет получаться один и тот же.
В общем — почему этап JIT компиляции не вынести за скобки и не осуществлять один раз на этапе инсталляции софта?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Память-то растет. Скорость работы процессора тоже. Да еще многоядерность появилась. PD>Это чем-то занимать надо или нет ? PD>А когда юзер видит, что программа стартует 10 секунд и ест 500 Мб, он проникается благоговением к ее неизмеримой сложности и идет в магазин покупать новую память и процессор.
Здравствуйте, VladD2, Вы писали:
VD>А мне огромные файлы без надобности. Я обложки не верстаю. Да и обложки по нашим временам не являются очень уж большими. Вот только что попробовал гаусово рамытие на картикне из примеров (не маленькая такая, как раз на А4 при печати потянет). И что я вижу? А вижу практически реалтайм. Превью дольше отрабатывает чем сам фильр.
Выделенное заставляет заподозрить что preview на самом деле выполняет полную обработку картинки, а нажатие OK просто коммитит готовый результат.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, x-code, Вы писали:
XC>Раз уж КСВ... XC>Давно интересует вопрос: зачем в платформах NET и Java сделана JIT компиляция? Есть, допустим, есть какой-нибудь нотепад на .NET, который я запускаю каждый день по несколько раз. И каждый день по несколько раз происходит компиляция программы. Путь не из исходников, а из специального двоичного формата, но все равно — каждый день ресурсы компа расходуются по сути на ОДНО И ТО ЖЕ.
XC>Преимущества "виртуального" двоичного кода понятны — можно запускать софт на разных платформах, под разными ОС и т.д. XC>Но что, товарищи из Microsoft предполагают, что у меня сегодня 32-битная Винда, за ночь она сама самомодифицировалась в 64-битную (да, вместе с аппаратной платформой ), а еще через день переписала себя в Linux??? XC>Очевидно, система одна и та же в течение месяцев и даже лет, и результат JIT компиляции изо дня в день будет получаться один и тот же.
XC>В общем — почему этап JIT компиляции не вынести за скобки и не осуществлять один раз на этапе инсталляции софта?
Настоящие джедаи так и делают, см NGen.
Но! JIT позволяет инлайнить тела методов\свойств из других модулей, получая гораздо большую оптимизацию.
Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Память-то растет. Скорость работы процессора тоже. Да еще многоядерность появилась. PD>>Это чем-то занимать надо или нет ? PD>>А когда юзер видит, что программа стартует 10 секунд и ест 500 Мб, он проникается благоговением к ее неизмеримой сложности и идет в магазин покупать новую память и процессор.
YKU>Теория заговора в чистом виде.
Здравствуйте, CreatorCray, Вы писали:
CC> VD>А мне огромные файлы без надобности. Я обложки не верстаю. Да и обложки по нашим временам не являются очень уж большими. Вот только что попробовал гаусово рамытие на картикне из примеров (не маленькая такая, как раз на А4 при печати потянет). И что я вижу? А вижу практически реалтайм. Превью дольше отрабатывает чем сам фильр.
CC> Выделенное заставляет заподозрить что preview на самом деле выполняет полную обработку картинки, а нажатие OK просто коммитит готовый результат.
Именно так и есть. Я, для чистоты эксперимента, после указания радиуса сразу Enter нажимал, чтоб превьюха не начала рассчитываться и отрабатывал только сам фильтр.
Здравствуйте, hattab, Вы писали:
x>> В общем — почему этап JIT компиляции не вынести за скобки и не осуществлять один раз на этапе инсталляции софта? H>Вообще, именно так и делают :) Только .NET софту это не сильно помогает :))
Тогда в чем проблема? Сборка мусора время отъедает? Или просто плохая оптимизация? Других принципиальных отличий от С/С++ (если считать что .NET-программа обработана ngen-ом) вроде нету?
MM>>>У меня на компе нет ни одной проги, написанной на Delphi. Надеюсь, аналогия ясна CC>>Зато просто море написаных на C/C++ ФА>а у меня преимущественно дельфовый софт ФА>skipe,
PD>А когда юзер видит, что программа стартует 10 секунд и ест 500 Мб, он проникается благоговением к ее неизмеримой сложности и идет в магазин покупать новую память и процессор.
PD>Да здравствует прогресс!
Только фигня, что там, где он мог запустить 2-3 программы, которые якобы были сверхкомпактными и нересурсоемкими, он может запустить 40-50 программ которые якобы жрут память и процессор.
Да, у меня 4 гига памяти почти полностью забиты, но при этом я боюсь жать Alt-Tab или смотреть на dock и menubar — я там тупо теряюсь в количестве иконок. Не говоря, что в части из этих приложений могут спокойно быть открыты далеко не самые легкий документы (PDF'ы, проекты на PHP/Java, десятки табов в бразуерах — не одном! — и т.п.).
M>Да, у меня 4 гига памяти почти полностью забиты, но при этом я боюсь жать Alt-Tab или смотреть на dock и menubar — я там тупо теряюсь в количестве иконок.
Смею тебя заверить, что если бы это было бы проблемой, то придумали бы какой-нибудь способ эти иконки группировать, чтобы ты смог разобраться
>Не говоря, что в части из этих приложений могут спокойно быть открыты далеко не самые легкий документы (PDF'ы, проекты на PHP/Java, десятки табов в бразуерах — не одном! — и т.п.).
Вот если действительно десятки табов в Хроме, и правда, что писал о них Владимир Кочетков — тогда да
M>>Да, у меня 4 гига памяти почти полностью забиты, но при этом я боюсь жать Alt-Tab или смотреть на dock и menubar — я там тупо теряюсь в количестве иконок.
PD>Смею тебя заверить, что если бы это было бы проблемой, то придумали бы какой-нибудь способ эти иконки группировать, чтобы ты смог разобраться
Я, как бы, совсем не об этом.
>>Не говоря, что в части из этих приложений могут спокойно быть открыты далеко не самые легкий документы (PDF'ы, проекты на PHP/Java, десятки табов в бразуерах — не одном! — и т.п.).
PD>Вот если действительно десятки табов в Хроме, и правда, что писал о них Владимир Кочетков — тогда да
Я, как бы совсем не об этом.
Ты тут плачешься о том, что все начало жрать память и т.п. Но при этом я работаю с гораздо бОльшим количеством открытых приложений, чем 10 лет тому назад, и многие из них выполняют намного более сложные функции или манипулируют гораздо бОльшими объемами данных. Парадокс? Никакого парадокса.
Здравствуйте, Mamut, Вы писали:
M>>>Да, у меня 4 гига памяти почти полностью забиты, но при этом я боюсь жать Alt-Tab или смотреть на dock и menubar — я там тупо теряюсь в количестве иконок.
PD>>Смею тебя заверить, что если бы это было бы проблемой, то придумали бы какой-нибудь способ эти иконки группировать, чтобы ты смог разобраться
M>Я, как бы, совсем не об этом.
А о чем ? То ты тупо в них теряешься и плачешь об этом, то вдруг выясняется, что ты не об этом. Я не гадалка.
>>>Не говоря, что в части из этих приложений могут спокойно быть открыты далеко не самые легкий документы (PDF'ы, проекты на PHP/Java, десятки табов в бразуерах — не одном! — и т.п.).
PD>>Вот если действительно десятки табов в Хроме, и правда, что писал о них Владимир Кочетков — тогда да
M>Я, как бы совсем не об этом.
А я вот тут именно об этом.
M>Ты тут плачешься о том, что все начало жрать память и т.п. Но при этом я работаю с гораздо бОльшим количеством открытых приложений, чем 10 лет тому назад, и многие из них выполняют намного более сложные функции или манипулируют гораздо бОльшими объемами данных. Парадокс? Никакого парадокса.
Слушай, ты что, ваньку валять начал ? У него, видите ли, гораздо больше открытых приложений, чем 10 лет назад, когда памяти было в 16 раз меньше. У него видите ли, приложения выполняют больше функций, чем 10 лет назад. Счастье-то какое! Интересно было бы, если бы все было наоборот! Я объясняю, что расходы памяти и процессорного времени явно непропорциональны вновь появившимся возможностям, что при таком росте ОП и тактовой все должно было бы пропорционально увеличиться, что VS та же должна была бы летать, коль скорость процессора в 10 раз увеличилась и 4 ядра появились вместо одного, а не загружаться 10 секунд, а мне в отвт — ну чего тебе надо, стало же лучше!
Здравствуйте, x-code, Вы писали:
x> x>> В общем — почему этап JIT компиляции не вынести за скобки и не осуществлять один раз на этапе инсталляции софта?
x> H>Вообще, именно так и делают Только .NET софту это не сильно помогает
x> Тогда в чем проблема? Сборка мусора время отъедает? Или просто плохая оптимизация? Других принципиальных отличий от С/С++ (если считать что .NET-программа обработана ngen-ом) вроде нету?
Никогда не пытался исследовать этот вопрос. Есть несколько предположений, но я их при себе оставляю, дабы не навлекать на себя гнев дотнетовцев
Здравствуйте, c-smile, Вы писали:
CS>А по поводу многослйного ренедеринг и акселерации — ну есть же Direct2D. CS>Я правда не понимаю этот велосипед он до или после WPF был сделан ...
Я все никак не пойму, нафига средство создания GUI сравнивают со средством рисования?
CS>И кстати Scintilla не сильно отличается от редактора VS2010 по фичам. Да и шрифты она (через GDI) рисует гуманнее чем WPF.
Что значит "гуманнее"? Во-первых, для страждущих WPF уже научилась рисовать а-ля GDI, во-вторых, "мягкий" текст WPF на самом деле гораздо круче и приятнее, но требует привыкания.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я объясняю, что расходы памяти и процессорного времени явно непропорциональны вновь появившимся возможностям, что при таком росте ОП и тактовой все должно было бы пропорционально увеличиться
это из каких соображений???
Здравствуйте, VladD2, Вы писали:
VD> H>PowerShell ISE так тупит из-за WPF-морды. Вот при чем тут дотнет?
VD> Ты в курсе, что у WPF бэкэнд нэйтивный? Он и тупит. Но в 2010-ой студии это вроде бы побороли.
Ага, DirectX у него в бэкэнде тормозит Кстати, долгий старт студии тоже наверняка многим обязан WPF'у.
With the exception of some cases where we found that remoting WPF primitives over terminal server connections was slow, generally the WPF system is more than capable of keeping up with the editor. If you are seeing sluggish typing WPF is almost certainly not to blame.
... COM interop cases sometimes made this even trickier with CCW/RCW objects being created destroyed far too aggressively. In some cases moving a nicer chunk of the work to the managed side helped a lot – kind of like writing stored procs for your database – good procedures mean fewer round trips and less data to move.
Здравствуйте, hattab, Вы писали:
H>Ага, DirectX у него в бэкэнде тормозит
Старый WPF тормозил в основном из-за кэширования шрифтов, как не странно.
H>Кстати, долгий старт студии тоже наверняка многим обязан WPF'у.
Я уже говорил о том, что разница между загрузкой 2008-ой и 2010-ой студией не так уж и велика? "В холодную" (т.е. первый запуска, пока сборки не закэшированы) 9 секунд 2008, и 12 2010-я. "В теплую" они обе грузятся примерно одинаков (3-4 секунды).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
S> With the exception of some cases where we found that remoting WPF primitives over terminal server connections was slow, generally the WPF system is more than capable of keeping up with the editor. If you are seeing sluggish typing WPF is almost certainly not to blame.
Я всего лишь о времени запуска говорю, а не об отзывчивости гуя
S> А вот интероп с легаси накладывает свои ограничения: S>
S> ... COM interop cases sometimes made this even trickier with CCW/RCW objects being created destroyed far too aggressively. In some cases moving a nicer chunk of the work to the managed side helped a lot – kind of like writing stored procs for your database – good procedures mean fewer round trips and less data to move.
Не-не-не... Что, интероп будет быстрее работать после прогрева файлухи (кеширования сборок)? Второй запуск студии проходит сильно быстрее первого.
Здравствуйте, VladD2, Вы писали:
VD> H>Ага, DirectX у него в бэкэнде тормозит
VD> Старый WPF тормозил в основном из-за кэширования шрифтов, как не странно.
Хм... Как запустить эту PowerShell ISE чтоб она четвертый фреймвок использовала? Я бы проверил скорость запуска с новым WPF...
VD> H>Кстати, долгий старт студии тоже наверняка многим обязан WPF'у.
VD> Я уже говорил о том, что разница между загрузкой 2008-ой и 2010-ой студией не так уж и велика? "В холодную" (т.е. первый запуска, пока сборки не закэшированы) 9 секунд 2008, и 12 2010-я. "В теплую" они обе грузятся примерно одинаков (3-4 секунды).
После прогрева то оно понятно, речь о холодном старте.
Здравствуйте, hattab, Вы писали:
h> После прогрева то оно понятно, речь о холодном старте.
и как часто так долго (целых 10 секунд!) ждать приходится? один?? ну и какая вообще разница сколько холодный старт занимает, по-моему наименее актуальная штука.
Здравствуйте, squid, Вы писали:
s> h> После прогрева то оно понятно, речь о холодном старте.
s> и как часто так долго (целых 10 секунд!) ждать приходится? один?? ну и какая вообще разница сколько холодный старт занимает, по-моему наименее актуальная штука.
Для студий и прочего тяжелого софта пофиг, а вот для мелкого софта критично. Evernote'овцам не понравилось.
Здравствуйте, hattab, Вы писали:
s>> и как часто так долго (целых 10 секунд!) ждать приходится? один?? ну и какая вообще разница сколько холодный старт занимает, по-моему наименее актуальная штука.
H>Для студий и прочего тяжелого софта пофиг, а вот для мелкого софта критично. Evernote'овцам не понравилось.
Вообще говоря эвернотовцы просто недовольны Эвернотом вот и ноют.
А долгий запуск это просто первое за что цепляется глаз.
Будь Эвернот крут как Фотошоп, никто бы и не вспоминал, что долго стартует.
В этом сегменте конкУрентов вобщем то достаточно много, но ни у одного нет толкового УИ, кроме OneNote а он вобщем по факту только для вындоуса.
Вобщем эвернот хорош только на фоне убогих конкурентов.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот представь себе — вместо всей этой прелести 2003-2005-2008-2010 взяла бы MS и улучшила VS6. Она тогда у меня на машине то ли с 64, то ли со 128 Мб работала вполне успешно, и отнюдь всю эту память не занимала. Ну заняла бы сейчас наполовину больше.
Получилось бы Эмбаркадеро, которое работает шустро и ничего толком не умеет, да еще и глюкает на каждый чих.
Кстати, BC твой про который ты пел песни, редкое говно, ни ошибок показать не умеет, ни специализацию толком оформить, возникает ощущение, что чуть не любой код скомпилить может.
PD>И аська, к примеру, тогда пару Мб занимала, а сейчас под сотню, как пишут.
Врут. Щас вот проверил — меньше 20мб.
А вот твой любимый нешкап занял у меня в памяти больше 50мб ни под что — ни JS толком не умеет, ни CSS, ни флеша, ни сильверлайта, чуть не голый html — а хочет ажно 50 мб.
4.79 нарыл, так он еще меньше умеет, но и памяти захотел всего 20мб.
Так что я сильно думаю, пусть прога жрет 500мб, но умеет много, чем 20, но ничего.
PD>И что бы было, если бы мы остались при тех же потребностях в памяти ?
Прогресс бы замедлился, считали бы битики, многие задачи человечества оказались бы нерешенными. Постепенно начали бы деградировать.
Здравствуйте, squid, Вы писали:
S>Здравствуйте, hattab, Вы писали:
h>> После прогрева то оно понятно, речь о холодном старте.
S>и как часто так долго (целых 10 секунд!) ждать приходится? один?? ну и какая вообще разница сколько холодный старт занимает, по-моему наименее актуальная штука.
Если у тебя есть 3 серьёзных конкурента то ты будешь считать всё.
А для Evernote это например OneNote от уважаемой фирмы. Которая к слову сама не стала это дело на .NET писать.
Я не знаю цифр вообще но косвенным данным предпологаю что много клиентов ушло с EN 3.5 к конкурентам.
Здравствуйте, squid, Вы писали:
s> h> Для студий и прочего тяжелого софта пофиг, а вот для мелкого софта критично. Evernote'овцам не понравилось.
s> Это их беда если они софт на .Net не в состоянии написать. 5 секунд для хомячков — нормальное время.
Так ты почитал бы, что эти самые хомячки на хабре в коментах писали... Понял бы, что они думают о "достаточности"
Здравствуйте, squid, Вы писали:
s> c> А для Evernote это например OneNote от уважаемой фирмы. Которая к слову сама не стала это дело на .NET писать.
s> MS вообще ничего не переписывает если это не является крайней необходимостью, давно известный подход.
Ага, Paint и WordPad переписать с новым риббоном видимо капец какая необходимость была
s>> MS вообще ничего не переписывает если это не является крайней необходимостью, давно известный подход.
H>Ага, Paint и WordPad переписать с новым риббоном видимо капец какая необходимость была
Ты все больше на генератор бреда походишь. Паинт и Вордпад в винде до сих пор нативные, эмфэцэ + гэдэи плюс.
Никто их не переписывал, просто рибборн добавили.
Просто есть дотнетовские аналоги, их писали возможно как демки, может для сравнения, а может для тестирования
Здравствуйте, c-smile, Вы писали:
CS>Если у тебя есть 3 серьёзных конкурента то ты будешь считать всё. CS>А для Evernote это например OneNote от уважаемой фирмы. Которая к слову сама не стала это дело на .NET писать.
Двигло офисное нативное, никто его в своем уме ради нового продукта не будет переписывать с нуля на дотнете.
Таким только борланды да нетскейпы занимались
CS>Я не знаю цифр вообще но косвенным данным предпологаю что много клиентов ушло с EN 3.5 к конкурентам.
У Евернота основная фишка это работа считай на всех гаджетах а UI там сильно посредственный. Покажи хоть одного конкурента более менее достойного ?
Здравствуйте, Sinix, Вы писали:
S> H>Ага, Paint и WordPad переписать с новым риббоном видимо капец какая необходимость была
S> Да, копец какая — это был dogfooding для самого риббона. Чорд, как меня умиляют "здравые суждения" без малейшего знания предмета
Ой-ой, а почему бы им не сделать того же самого для .NET? Что-то они все больше языком. Взяли бы да и написали новый IE9 (ведь один хрен переписывали) под .NET. Ан нет, все по прежнему нативное. Впрочем удивляться нечему, хватило видимо и того, что MMC снапины превратили в тормозное говно переписав оные под .NET.
Здравствуйте, Ikemefula, Вы писали:
I> Двигло офисное нативное, никто его в своем уме ради нового продукта не будет переписывать с нуля на дотнете.
I> Таким только борланды да нетскейпы занимались
Здравствуйте, Ikemefula, Вы писали:
I> s>> MS вообще ничего не переписывает если это не является крайней необходимостью, давно известный подход.
I> H>Ага, Paint и WordPad переписать с новым риббоном видимо капец какая необходимость была
I> Ты все больше на генератор бреда походишь. Паинт и Вордпад в винде до сих пор нативные, эмфэцэ + гэдэи плюс.
I> Никто их не переписывал, просто рибборн добавили.
Ну ты и балда Я именно про риббон и сказал. В такой мелочевке замена гуя приравнивается к переписыванию
Здравствуйте, squid, Вы писали:
s> h> Так ты почитал бы, что эти самые хомячки на хабре в коментах писали... Понял бы, что они думают о "достаточности"
s> хомячки на хабре? ну-ну.
Здравствуйте, hattab, Вы писали:
I>> Никто их не переписывал, просто рибборн добавили.
H>Ну ты и балда Я именно про риббон и сказал. В такой мелочевке замена гуя приравнивается к переписыванию
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Ikemefula, Вы писали:
I>> Двигло офисное нативное, никто его в своем уме ради нового продукта не будет переписывать с нуля на дотнете.
I>> Таким только борланды да нетскейпы занимались
H>Чего борланды переписывали на дотнет?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Sinix, Вы писали:
S>> H>Ага, Paint и WordPad переписать с новым риббоном видимо капец какая необходимость была
S>> Да, копец какая — это был dogfooding для самого риббона. Чорд, как меня умиляют "здравые суждения" без малейшего знания предмета
H>Ой-ой, а почему бы им не сделать того же самого для .NET? Что-то они все больше языком. Взяли бы да и написали новый IE9 (ведь один хрен переписывали) под .NET. Ан нет, все по прежнему нативное. Впрочем удивляться нечему, хватило видимо и того, что MMC снапины превратили в тормозное говно переписав оные под .NET.
Зачем?
Не, точнее так — что бы им это дало? Если включить на пару секунд мозги (пардон за неприличное в КСВ предложение) и соотнести потребный объём работы с полученным выхлопом — таких вопросов не будет. Для начала, прикиньте затраты на _полное_ дублирование предыдущего поведения в режиме совместимости и сохранение работоспособности over 9k софта, прямо или непрямо использующего browser control. С новой командой: старая справедливо пошлёт нафиг за такие выверты — МС опять будет виновата — они не удерживают ценных специалистов, вендекапец!
Если коротко — там где есть смысл и есть опытные девы под .NET — переписывают, как переводят сейчас media center, студию и SSMS. Там где нет — нет.
Здравствуйте, squid, Вы писали:
S>Для меня очевидно что это не так. Не знаю ни одного не айтишника который о нем вообще знает.
Открою страшную тайну: айтишники тоже страдают от стадного инстинкта и сектантства
Зачастую, дискуссии на хабре по содержательности не сильно от ЛОРовских отличаются. Да и местные тоже
Здравствуйте, Sinix, Вы писали:
S> H>Ой-ой, а почему бы им не сделать того же самого для .NET? Что-то они все больше языком. Взяли бы да и написали новый IE9 (ведь один хрен переписывали) под .NET. Ан нет, все по прежнему нативное. Впрочем удивляться нечему, хватило видимо и того, что MMC снапины превратили в тормозное говно переписав оные под .NET.
S> Зачем? S> Не, точнее так — что бы им это дало? Если включить на пару секунд мозги (пардон за неприличное в КСВ предложение) и соотнести потребный объём работы с полученным выхлопом — таких вопросов не будет. Для начала, прикиньте затраты на _полное_ дублирование предыдущего поведения в режиме совместимости и сохранение работоспособности over 9k софта, прямо или непрямо использующего browser control. С новой командой: старая справедливо пошлёт нафиг за такие выверты — МС опять будет виновата — они не удерживают ценных специалистов, вендекапец!
Ну как же, профиты наипрямые (по мотивам КСВ): управляемый код не уступает в скорости нативному (тут об этом каждый нетер знает), управляемый код легче писать и проще поддерживать т.к. нет множественных граблей с мемори-ликами, указателями и прочим нативным непотребством (тут об этом знает каждый второй нетер), а следовательно новая версия браузера выйдет раньше конкурентов и будет быстрее обрастать новыми фичами (это ли не профит, ё-мое). Наконец, управляемый код не подвержен ошибкам buffer overflow, что автоматом закрывает некислую дырку в безопасности. Что касается совместимости, то ее легко обеспечить неким аналогом прокси-объектов, в общем ничего сверхестественного в этом нет Кстати, читал интервью, правда о IE8, с господином Могилевским, так он говорил, что браузер переписывают практически с нуля, видимо не все так страшно, как ты рисуешь
S> Если коротко — там где есть смысл и есть опытные девы под .NET — переписывают, как переводят сейчас media center, студию и SSMS. Там где нет — нет.
Скажи, какой был смысл превращать EventViewer в тормозное это-самое?
Здравствуйте, squid, Вы писали:
s> Для меня очевидно что это не так. Не знаю ни одного не айтишника который о нем вообще знает.
Ой, прости господи, там в каментах иногда такого напишут, что страшно становится если предположить, что это айтишники. Кроме того, если ты думаешь, что айтишник не может быть типичным хомячком то глубоко заблуждаешься.
Здравствуйте, Ikemefula, Вы писали:
I> I>> Никто их не переписывал, просто рибборн добавили.
I> H>Ну ты и балда Я именно про риббон и сказал. В такой мелочевке замена гуя приравнивается к переписыванию
I> Да не гони, ладно ?
Да ты сам подумай, что умеет тот паинт... Палочки да кружочки рисовать (о его способности ко встраиваемости мы умолчим ибо не суть). А тот WordPad... Ну юзает он ричедит виндовый, большое понимаешь дело В общем, в подобном софте собственного функционала кот наплакал, посему гуй там самая сложная часть. Так что не гони ка ты сам.
Здравствуйте, hattab, Вы писали:
H>Да ты сам подумай, что умеет тот паинт... Палочки да кружочки рисовать (о его способности ко встраиваемости мы умолчим ибо не суть).
Значит можно говорить только про те фичи, которые тебе интересны ?
>А тот WordPad... Ну юзает он ричедит виндовый, большое понимаешь дело В общем, в подобном софте собственного функционала кот наплакал, посему гуй там самая сложная часть. Так что не гони ка ты сам.
Есть вроде как исходники для этих двух софтин, можешь посмотреть если хочешь
Здравствуйте, Ikemefula, Вы писали:
I> H>Да ты сам подумай, что умеет тот паинт... Палочки да кружочки рисовать (о его способности ко встраиваемости мы умолчим ибо не суть).
I> Значит можно говорить только про те фичи, которые тебе интересны ?
Реализация нескольких интерфейсов не ахти какая сложная задача, смысл на ней заострять внимание?
Кроме JIT есть еще один момент — в библитеках .Net имеется большое количество различных проверок, которые влияют на скорость работы. Например, довольо часто (особенно в WPF) происходит проверка, в каком потоке вызван метод. Можно сказать, что (в терминах Visual C++) программа всегда работает с DEBUG версиеий библиотеки (только вместо ASSERT получаем Exception). И эти проверки имеют место не только в библиотеках, но и в самом скомпилированном коде (проверки границ массивов и т.п.).
Но особенно сильных тормозов в .Net, я, увы, не наблюдаю.
Здравствуйте, hattab, Вы писали:
H>Ну как же, профиты наипрямые (по мотивам КСВ): управляемый код не уступает в скорости нативному (тут об этом каждый нетер знает), управляемый код легче писать и проще поддерживать т.к. нет множественных граблей с мемори-ликами, указателями и прочим нативным непотребством (тут об этом знает каждый второй нетер),
Ну, в теории — да. Вопрос по производительности деликатно опустим.
H> а следовательно новая версия браузера выйдет раньше конкурентов и будет быстрее обрастать новыми фичами (это ли не профит, ё-мое).
А теперь грубо шмякаемся об реальность. МС всего-то что и придётся: переписать на другую платформу без малейшего код-реюза. Очевидно, это прям на порядки быстрее, чем выпуск новой версии по устоявшемуся процессу.
Итак, что МС получит по сравнению с текущей ситуацией?
H>Что касается совместимости, то ее легко обеспечить неким аналогом прокси-объектов, в общем ничего сверхестественного в этом нет
Спасибо, день сделан!
H> Кстати, читал интервью, правда о IE8, с господином Могилевским, так он говорил, что браузер переписывают практически с нуля, видимо не все так страшно, как ты рисуешь
Увы, к реальности это утверждение имеет очень малое отношение. Для совместимости там фактически полноценный render engine от ie7.
H>Скажи, какой был смысл превращать EventViewer в тормозное это-самое?
А это — как раз пример софта, на которое у них не было ни спецов по юзабилити, ни UI-дизайнеров, ни грамотных девелоперов. Одно то, что UI заморожен пока не прочтётся _весь_ лог говорит очень о многом.
Здравствуйте, Sinix, Вы писали:
S> H> а следовательно новая версия браузера выйдет раньше конкурентов и будет быстрее обрастать новыми фичами (это ли не профит, ё-мое).
S> А теперь грубо шмякаемся об реальность. МС всего-то что и придётся: переписать на другую платформу без малейшего код-реюза. Очевидно, это прям на порядки быстрее, чем выпуск новой версии по устоявшемуся процессу.
А C++/CLI как же? Реюзь нехочу
S> Итак, что МС получит по сравнению с текущей ситуацией?
Рекламу .NET'у сделает такую, что самый последний ненавистник повесится в туалете (хотя я то точно знаю, что окромя тормозов фиг она там чего получит )
S> H>Что касается совместимости, то ее легко обеспечить неким аналогом прокси-объектов, в общем ничего сверхестественного в этом нет
S> S> Спасибо, день сделан!
А чему ты удивляешься? Это стандартная практика, когда делается что-то новое, то для обеспечения совместимости (коли есть задача такая) со старым кодом делается специальная прослойка (как хочешь ее называй, я прокси назвал) обеспечивающая бесшовную работу старого кода с новым. Причем, даже архитектурные вопросы данным способом улаживаются вполне
S> H> Кстати, читал интервью, правда о IE8, с господином Могилевским, так он говорил, что браузер переписывают практически с нуля, видимо не все так страшно, как ты рисуешь
S> Увы, к реальности это утверждение имеет очень малое отношение. Для совместимости там фактически полноценный render engine от ie7.
Ну и пусть для совместимости так и будет, что нет механизмов взаимодействия управляемого кода с нативом что ли Пусть совместимое будет чуть более тормозным, зато новье будет летать ( )
S> H>Скажи, какой был смысл превращать EventViewer в тормозное это-самое?
S> А это — как раз пример софта, на которое у них не было ни спецов по юзабилити, ни UI-дизайнеров, ни грамотных девелоперов. Одно то, что UI заморожен пока не прочтётся _весь_ лог говорит очень о многом.
Ну а вот Task Scheduler, нафиг там .NET потребовался, какой от него профит (кроме меньших затрат на стадо индусов)? Гуй не замерзает в моменты чтения, но тормоза зверские.
Здравствуйте, hattab, Вы писали:
S>> А теперь грубо шмякаемся об реальность. МС всего-то что и придётся: переписать на другую платформу без малейшего код-реюза. Очевидно, это прям на порядки быстрее, чем выпуск новой версии по устоявшемуся процессу.
H>А C++/CLI как же? Реюзь нехочу
Эдакий франкенштейн тут же убьёт все бонусы от managed-кода.
H>Рекламу .NET'у сделает такую, что самый последний ненавистник повесится в туалете (хотя я то точно знаю, что окромя тормозов фиг она там чего получит )
Гмм... ну и нафига МС, чтобы их обвиняли в геноциде ненавистников? Нащщёт тормозов — вся из себя managed vs2010 у меня на машине работала значительно шустрее 2008й (пока переползали). Увы, тормоза не зависят от используемой платформы.
H>А чему ты удивляешься? Это стандартная практика, когда делается что-то новое, то для обеспечения совместимости (коли есть задача такая) со старым кодом делается специальная прослойка (как хочешь ее называй, я прокси назвал) обеспечивающая бесшовную работу старого кода с новым. Причем, даже архитектурные вопросы данным способом улаживаются вполне
Тем, что это "лехко" для кода, который никем не используется, а если что и поломалося — клиенты ССЗБ, сами как нить поправят. IE — эт сволочь такая платформа, что аж завидно. Множество корпоративов даже на Висту никак не переползёт в том числе и из-за кривых веб-клиентов, а тут вы кавалерийским наскоком надеетесь перетащить все багофичи на новую платформу.
H>Ну и пусть для совместимости так и будет, что нет механизмов взаимодействия управляемого кода с нативом что ли Пусть совместимое будет чуть более тормозным, зато новье будет летать
Я ещё раз вам намекну, что масштабы потребной работы и выхлоп — удовлетворение вас, любимого — ну никак не соотносятся. И, пожалуй из этой темы уползу. Приятного вам холивара.
Здравствуйте, Sinix, Вы писали:
S> H>А C++/CLI как же? Реюзь нехочу
S> Эдакий франкенштейн тут же убьёт все бонусы от managed-кода.
Ой да ладно, он позволит быстренько выпустить продукт, а потом потихоньку переписывать на православный шарп
S>Нащщёт тормозов — вся из себя managed vs2010 у меня на машине работала значительно шустрее 2008й (пока переползали). Увы, тормоза не зависят от используемой платформы.
Гы. Когда говорят о тормозах 2010, говорят, что там тормозит нативный код. Когда рассказывают о том, что 2010 работает значительно шустрее, выясняется, что она вся из себя managed Доставляет
S> H>А чему ты удивляешься? Это стандартная практика, когда делается что-то новое, то для обеспечения совместимости (коли есть задача такая) со старым кодом делается специальная прослойка (как хочешь ее называй, я прокси назвал) обеспечивающая бесшовную работу старого кода с новым. Причем, даже архитектурные вопросы данным способом улаживаются вполне
S> Тем, что это "лехко" для кода, который никем не используется, а если что и поломалося — клиенты ССЗБ, сами как нить поправят. IE — эт сволочь такая платформа, что аж завидно. Множество корпоративов даже на Висту никак не переползёт в том числе и из-за кривых веб-клиентов, а тут вы кавалерийским наскоком надеетесь перетащить все багофичи на новую платформу.
Мозиловцам (есть/был у них контрол заменяющий IWebBrowser) это по плечу, а МС'у, владельцу кода, нет... Ниверю.
Здравствуйте, hattab, Вы писали:
H>Ой да ладно, он позволит быстренько выпустить продукт, а потом потихоньку переписывать на православный шарп
Быстренько не получится. Слишком много работы вложено в имеющиеся версии.
H> Гы. Когда говорят о тормозах 2010, говорят, что там тормозит нативный код. Когда рассказывают о том, что 2010 работает значительно шустрее, выясняется, что она вся из себя managed Доставляет
Вобщето с ней чтото странное есть. Но ноуте этой весной она почему то работала быстрее, чем на более мощном полноценном компе. Щас комп другой замерить не могу.
S>> Тем, что это "лехко" для кода, который никем не используется, а если что и поломалося — клиенты ССЗБ, сами как нить поправят. IE — эт сволочь такая платформа, что аж завидно. Множество корпоративов даже на Висту никак не переползёт в том числе и из-за кривых веб-клиентов, а тут вы кавалерийским наскоком надеетесь перетащить все багофичи на новую платформу.
H>Мозиловцам (есть/был у них контрол заменяющий IWebBrowser) это по плечу, а МС'у, владельцу кода, нет... Ниверю.
У них был такой контрол, он он заменял только если прога не завязывалась ан всю DOM-модель и АПИ бровзера.
Т.е. если только навигацию осуществлять, то я сам тебе могу написать такой контрол
Здравствуйте, Ikemefula, Вы писали:
I> H>Ой да ладно, он позволит быстренько выпустить продукт, а потом потихоньку переписывать на православный шарп
I> Быстренько не получится. Слишком много работы вложено в имеющиеся версии.
Дык код-реюз же
I> H>Мозиловцам (есть/был у них контрол заменяющий IWebBrowser) это по плечу, а МС'у, владельцу кода, нет... Ниверю.
I> У них был такой контрол, он он заменял только если прога не завязывалась ан всю DOM-модель и АПИ бровзера.
Судя по этому документу, на тот момент совместимость была очень хорошая. И это, заметь, без доступа к исходникам вообще. А то тут сказочки начинаются о сложности воспроизведения поведения прошлых версий.
I> Т.е. если только навигацию осуществлять, то я сам тебе могу написать такой контрол
Здравствуйте, hattab, Вы писали:
I>> Быстренько не получится. Слишком много работы вложено в имеющиеся версии.
H>Дык код-реюз же
Проще по чуть чуть добавлять, как с MMC
I>> У них был такой контрол, он он заменял только если прога не завязывалась ан всю DOM-модель и АПИ бровзера.
H>Судя по этому документу, на тот момент совместимость была очень хорошая. И это, заметь, без доступа к исходникам вообще. А то тут сказочки начинаются о сложности воспроизведения поведения прошлых версий.
А ты свои ссылки читаешь ?
'It is important to note that the Mozilla control will not have a complete implementation of the DOM since it is extremely complex'
Это вобщем то основная проблема с совместимостями линейке IE и она же является препятствием для наращивания функционала и перформанса.
Здравствуйте, Ikemefula, Вы писали:
I> Проще по чуть чуть добавлять, как с MMC
Дык даже по чуть-чуть не решаются. А MMC уже превратили в говно
I> I>> У них был такой контрол, он он заменял только если прога не завязывалась ан всю DOM-модель и АПИ бровзера.
I> H>Судя по этому документу, на тот момент совместимость была очень хорошая. И это, заметь, без доступа к исходникам вообще. А то тут сказочки начинаются о сложности воспроизведения поведения прошлых версий.
I> А ты свои ссылки читаешь ?
I> 'It is important to note that the Mozilla control will not have a complete implementation of the DOM since it is extremely complex'
Ага. Ты аккуратно не процитировал дальше:
Here is what you can expect:
Implementation of most common element types
Retrieve element info such as class name, id etc.
Traversal functions. Parse the DOM using methods such as get_children, get_all, get_parent etc.
Attribute setting and getting, e.g. setAttribute, getAttribute etc.
Simple modifications, for instance to be able to set or get text from text elements
Integration with the ActiveX Plug-in support (if present) so that ActiveX objects in the HTML are available to clients.
What you shouldn't expect:
Exact DOM mapping between IE and Mozilla. The IE wrapper control uses the Mozilla (and therefore W3C DOM level 1 standard) for its element hierarchy and not the IE one.
Implementation of complicated methods. By complicated I mean ones where there is no direct mapping between the IE method and the Mozilla equivalent.
I> Это вобщем то основная проблема с совместимостями линейке IE и она же является препятствием для наращивания функционала и перформанса.
Это делали люди имея на руках готовый движок (Gecko), который по внутренней структуре мог сильно отличаться от трайдента. Разумеется, полного соответствия никто не мог гарантировать. Тут же мы говорим о МС, которая, и кодом владеет, и вообще всей информацией о собственном движке. Более того, что им мешало написав новый IE под .NET продолжать поставлять нативный трайдент? Пускай, те кому нужна совместимость, пользуются старой версией (т.е. для них все будет совершенно прозрачно), а кто хочет новую то вот она и уж тут сами проверяйте на совместимость Просто существовало бы два движка, один для легаси, другой весь из себя передовой. Развивать только новый движек, а старый просто заморозить, почему нет?
Здравствуйте, hattab, Вы писали:
I>> Проще по чуть чуть добавлять, как с MMC
H>Дык даже по чуть-чуть не решаются. А MMC уже превратили в говно
По чуть-чуть таки решаются. Они кое какие плагины на дотнете пишут, например NodeXL
I>> I>> У них был такой контрол, он он заменял только если прога не завязывалась ан всю DOM-модель и АПИ бровзера.
I>> H>Судя по этому документу, на тот момент совместимость была очень хорошая. И это, заметь, без доступа к исходникам вообще. А то тут сказочки начинаются о сложности воспроизведения поведения прошлых версий.
I>> А ты свои ссылки читаешь ?
I>> 'It is important to note that the Mozilla control will not have a complete implementation of the DOM since it is extremely complex'
H>Ага. Ты аккуратно не процитировал дальше:
Читай сам:
H>
H>What you shouldn't expect:
H>Exact DOM mapping between IE and Mozilla. The IE wrapper control uses the Mozilla (and therefore W3C DOM level 1 standard) for its element hierarchy and not the IE one.
H>Implementation of complicated methods. By complicated I mean ones where there is no direct mapping between the IE method and the Mozilla equivalent.
I>> Это вобщем то основная проблема с совместимостями линейке IE и она же является препятствием для наращивания функционала и перформанса.
H>Это делали люди имея на руках готовый движок (Gecko), который по внутренней структуре мог сильно отличаться от трайдента. Разумеется, полного соответствия никто не мог гарантировать. Тут же мы говорим о МС, которая, и кодом владеет, и вообще всей информацией о собственном движке. Более того, что им мешало написав новый IE под .NET продолжать поставлять нативный трайдент? Пускай, те кому нужна совместимость, пользуются старой версией (т.е. для них все будет совершенно прозрачно), а кто хочет новую то вот она и уж тут сами проверяйте на совместимость Просто существовало бы два движка, один для легаси, другой весь из себя передовой. Развивать только новый движек, а старый просто заморозить, почему нет?
Потому что два продукта будут конкурировать между собой, внутривидовая борьба так сказать.
Здравствуйте, Ikemefula, Вы писали:
I> I>> Проще по чуть чуть добавлять, как с MMC
I> H>Дык даже по чуть-чуть не решаются. А MMC уже превратили в говно
I> По чуть-чуть таки решаются. Они кое какие плагины на дотнете пишут, например NodeXL
Плагины это не то Одно дело MMC, где они решают, и совсем другое дело браузер.
I> Читай сам:
I> H>
H>What you shouldn't expect:
I> H>Exact DOM mapping between IE and Mozilla. The IE wrapper control uses the Mozilla (and therefore W3C DOM level 1 standard) for its element hierarchy and not the IE one.
I> H>Implementation of complicated methods. By complicated I mean ones where there is no direct mapping between the IE method and the Mozilla equivalent.
Дык я это читал, потому и говорю:
Разумеется, полного соответствия никто не мог гарантировать. Тут же мы говорим о МС, которая, и кодом владеет, и вообще всей информацией о собственном движке.
I> Потому что два продукта будут конкурировать между собой, внутривидовая борьба так сказать.
Так не будет никаких двух продуктов Будет новый, передовой IE и оставленный для совместимости, замороженный, старый трайдент.
Здравствуйте, Antikrot, Вы писали:
A>это из каких соображений???
за павла не скажу, но, по моему, соображения два: скорость и простота разработки. да, о пользователях не подумали, но такой стиль приносит деньги в индустрии софта и железа. а это означает их развитие.
Здравствуйте, _Raz_, Вы писали:
A>>это из каких соображений??? _R_>за павла не скажу, но, по моему, соображения два: скорость и простота разработки. да, о пользователях не подумали, но такой стиль приносит деньги в индустрии софта и железа. а это означает их развитие.
да это понятно, но Павел-то, говоря что "должно увеличиваться пропорционально", имеет в виду что сейчас потребности программ растут быстрее чем мощность железа, а не "как должно быть"
Здравствуйте, Antikrot, Вы писали:
A>да это понятно, но Павел-то, говоря что "должно увеличиваться пропорционально", имеет в виду что сейчас потребности программ растут быстрее чем мощность железа, а не "как должно быть"
и говорит это с ужасом
не сейчас. всегда так было, иначе откуда устойчивое выражение "xxx тормозит"? из тех самых времен за которые он ратует. еще вспоминается прикол, что производители железа доплачивали гейтсу/производителю игрушки (по вкусу).
а вот сейчас ситуация изменилась. правильно он говорит, что видимый функционал не далеко шагнул, но ведь и бсод уже не притча все языцех?
Здравствуйте, _Raz_, Вы писали:
A>>да это понятно, но Павел-то, говоря что "должно увеличиваться пропорционально", имеет в виду что сейчас потребности программ растут быстрее чем мощность железа, а не "как должно быть" _R_>и говорит это с ужасом
я бы сказал "с полным непониманием о чём говорит", да вот Кочетков тут недовольство проявляет
_R_>а вот сейчас ситуация изменилась. правильно он говорит, что видимый функционал не далеко шагнул, но ведь и бсод уже не притча все языцех?
и ты туда же? расскажи, что ты считаешь "видимым" функционалом для компилятора и прочей коммандлайнщины
а вот это — "Я (как пользователь) их на экране вижу" — простите, несерьёзно
Здравствуйте, Antikrot, Вы писали:
A>я бы сказал "с полным непониманием о чём говорит", да вот Кочетков тут недовольство проявляет
Ну он добрый папа
A>и ты туда же? расскажи, что ты считаешь "видимым" функционалом для компилятора и прочей коммандлайнщины
Я говорил про фичалист, а не про гуй. По сути ведь не далеко ушли от тех времен. Всего то 3.2 -> 4. Но я не склонен драматизировать ситуацию — в стандартах бардак полный, да, но вот память и гигагерцы меня мало волнуют. Павел, похоже, за идею, а меня и так устраивает.
A>а вот это — "Я (как пользователь) их на экране вижу" — простите, несерьёзно
А вот это самое серьезное и есть. Именно по тому какой отклик того что на экране и складывается впечатление о продукте.
Здравствуйте, _Raz_, Вы писали:
A>>и ты туда же? расскажи, что ты считаешь "видимым" функционалом для компилятора и прочей коммандлайнщины _R_>Я говорил про фичалист, а не про гуй. По сути ведь не далеко ушли от тех времен.
о как. вообще-то, фич добавилось чуть более чем дофига, просто было объявлено что все фичи что не были в 96ом — идут лесом. с таким подходом конечно недалеко
A>>а вот это — "Я (как пользователь) их на экране вижу" — простите, несерьёзно _R_>А вот это самое серьезное и есть. Именно по тому какой отклик того что на экране и складывается впечатление о продукте.
какие пользователи, какой отклик, на каком экране. вовсю обсуждаются компиляторы и IDE, на которые пользователям покласть, а для разработки экономить на спичках просто нечестно хотя бы по отношению к тому же пользователю.
Здравствуйте, Antikrot, Вы писали:
A>о как. вообще-то, фич добавилось чуть более чем дофига, просто было объявлено что все фичи что не были в 96ом — идут лесом. с таким подходом конечно недалеко
да не фичи это, а юзабилити. прорывов не припомню.
A>какие пользователи, какой отклик, на каком экране. вовсю обсуждаются компиляторы и IDE, на которые пользователям покласть, а для разработки экономить на спичках просто нечестно хотя бы по отношению к тому же пользователю.
Здравствуйте, _Raz_, Вы писали:
A>>о как. вообще-то, фич добавилось чуть более чем дофига, просто было объявлено что все фичи что не были в 96ом — идут лесом. с таким подходом конечно недалеко _R_>да не фичи это, а юзабилити. прорывов не припомню.
юзабилити использования компиляторов? очень интересно, расскажи как улучшить
Здравствуйте, kaa.python, Вы писали:
KP>И в результате сдержал обещание на половину: загружается действительно медленнее, но и в работе еле ползает KP>Продукты от МС давно стали мало юзабельным г-ном.
Пока ещё не стали, но дело к тому идёт.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, c-smile, Вы писали:
CS>>На моей рабочей машине VS2010 стартует 12 секунд. WTF? К тому же при установке этот подлец поставил себя как viewer С++ файлов. CS>>Это какой-то эксперимент на живых людях. Кто-нибудь может внятно объяснить преимущества использования .NET для Visual Studio и в частности на кой там упал этот WTF (в смысле WPF)? CS>>Я понимаю что нужен некий клеевой язык для того чтобы кучу добра склеить вместе. Но оно же бувально не едет в том виде что сделан.
PD>Ничего ты не понимаешь!
PD>Память-то растет. Скорость работы процессора тоже. Да еще многоядерность появилась.
Вырос уже процессор. Вплотную к теоретическому пределу подошли тактовые частоты.
Всё сказанное выше — личное мнение, если не указано обратное.
Поэтому надо использовать Qt в разработке UI приложений. Qt и быстр, и гибок, и места при инсталляции где-то 10 Мб занимает, и кроссплатформен. Ну что еще надо?
Здравствуйте, shrecher, Вы писали:
S>Поэтому надо использовать Qt в разработке UI приложений. Qt и быстр, и гибок, и места при инсталляции где-то 10 Мб занимает, и кроссплатформен. Ну что еще надо?
Надо DevExpress.com под QT (XtraGrid, XAF) и т.д и т.п.
Здравствуйте, sanyock, Вы писали:
S>Здравствуйте, shrecher, Вы писали:
S>>Поэтому надо использовать Qt в разработке UI приложений. Qt и быстр, и гибок, и места при инсталляции где-то 10 Мб занимает, и кроссплатформен. Ну что еще надо?
S>Надо DevExpress.com под QT (XtraGrid, XAF) и т.д и т.п.
Дык, а че не хватает-то? Вроде бы в Qt встроенных контролов и возможностей даже больше чем надо.
Здравствуйте, c-smile, Вы писали:
CS>А я как эксперт в UI вообще говорю тебе что 500-700ms на загрузку такого UI — за глаза. CS>Т.е. я как и здесь присутствющие умеем это делать, а команда Visual Studio этого сделать не в состоянии?
Какая связь с темой топика?
НС>>Осталось доказать, что в тормозах студии виноват WPF. Вот VS2008 — там никакого WPF нет, а тормозит еще больше. Парадокс?
CS>У меня стоят четыре студии: VS6, 2005, 2008, 2010. CS>График загрузки строго прямая линия VS6 самая быстрая — моментально и 2010 самая медленная — 4-12 сек — как карта ляжет.
Результаты измерений в студию.
CS>Просто судя по графику
График в студию.
CS>VS6 это голый C++ и тот же самый VBS. Будем считать что VS2008 это VS6 + .NET. Дельта — это .NET. CS>Я делаю простой вывод — тормозит .NET.
Простой и неверный. VS.NET + имеет принципиально иную архитектуру. После этого списывать все тормоза только на используемые технологии — признак не очень большого ума.
НС>>Так ты и не пытался понять.
CS>Если честно я бы очень хотел знать что конкретно нужно прицепить к такому UI чтобы он так тормозил.
Тормозит не UI.
CS>Я честно хотел бы в глаза VS иделогу (Borland.AndersHejlsberg ?)
Здравствуйте, c-smile, Вы писали:
CS>У меня стоят четыре студии: VS6, 2005, 2008, 2010. CS>График загрузки строго прямая линия VS6 самая быстрая — моментально и 2010 самая медленная — 4-12 сек — как карта ляжет.
Это ты Дворкину свой аккаунт отдал что ли ?
В 98м году я даже не пытался запустить VС6 и пользовался VS5, чисто из за перформанса.
А некоторые, у кого комп был еще мощне моего, считали что даже и VC5 это тормоз и пользовались VC4
Долбаный редактор с подсветкой и автокомплитом, грузится 8 секунд... афуеть...
.jpg)
