Comments 24
Щас тут набегут тролли с их модемным каналом и будут орать .net отстой даешь asm
Если по существу, ключевой вопрос для меня когда выбирал framework это кто ваш пользователь. Если это буржуй (Европа или штаты) у них там безлимитка стоит просто смешные деньги и тарифицированных пакетов почти нет — поэтому тут однозначно что вам удобнее и с чем у вас будут быстрее выпускаться версии.
Если это наш родной советский пользователь — то тут конечно проблема, ибо 50 метров это большая проблема (для жителей вне столиц)
Если по существу, ключевой вопрос для меня когда выбирал framework это кто ваш пользователь. Если это буржуй (Европа или штаты) у них там безлимитка стоит просто смешные деньги и тарифицированных пакетов почти нет — поэтому тут однозначно что вам удобнее и с чем у вас будут быстрее выпускаться версии.
Если это наш родной советский пользователь — то тут конечно проблема, ибо 50 метров это большая проблема (для жителей вне столиц)
Возьмем Тотал-Коммандер-подобную программу. Я лучше скачаю быстрый, мало-памяти-требующий и весящий пару мегабайт Total Commander, чем его воображаемый аналог весом в 58 Мб, который еще и тормозить будет. Зачем, спрашивается?
Ставьте свой .NET себе на многогигабайтный 8-ядерный сервер, если уж жить без него не можете, а пользователям сырые, кривые и неэффективнфые технологии не предлагайте. Что в нем такого, что оправдывает такую трату ресурсов?
p.s. Я хоть и провинциал (а не тролль с модемным каналом), но на скорость не жалуюсь — до нескольких мегабит в секунду, но памяти, диска и процессора мне на всякую .NET-ную фигню жалко. научитесь сначала писаьт эффективные программы.
К тому же неэффективному сборщиуку мусора, неэффективной CLR и JIT-у на моем компьютере делать нечего.
p.p.s. Вы бы еще тут на php + GTK предлагали писать — такая же фигня (хотя нет, .NET весит больше).
p.p.p.s Бесят дистрибутивы размером десятки и сотни мегабайт. такое ощущение, что платят зарплату программистам помегабайтно.
Ставьте свой .NET себе на многогигабайтный 8-ядерный сервер, если уж жить без него не можете, а пользователям сырые, кривые и неэффективнфые технологии не предлагайте. Что в нем такого, что оправдывает такую трату ресурсов?
p.s. Я хоть и провинциал (а не тролль с модемным каналом), но на скорость не жалуюсь — до нескольких мегабит в секунду, но памяти, диска и процессора мне на всякую .NET-ную фигню жалко. научитесь сначала писаьт эффективные программы.
К тому же неэффективному сборщиуку мусора, неэффективной CLR и JIT-у на моем компьютере делать нечего.
p.p.s. Вы бы еще тут на php + GTK предлагали писать — такая же фигня (хотя нет, .NET весит больше).
p.p.p.s Бесят дистрибутивы размером десятки и сотни мегабайт. такое ощущение, что платят зарплату программистам помегабайтно.
UFO just landed and posted this here
> Ты ограничен, у тебя нету фантазии.
Это к чему?)) Или .NET только для фантазеров? Далеких от рещения реальных задач?
> Кстати за счет GC код типа for (;;) new obj; delete obj; будет выполняться быстрей чем на твоем asm или ещё на чем ты там помешан.
И памяти потратит столько же? И где интересно нужен пустой цикл, создающий и удаляющий объекты? И зачем delete при использовании GC?
У GC есть вполне конкретные недостатки — подвисания в работе программы, большой расход памяти, кроме того с увеличением адресного пространства и количества объектов он становится не шибко эффективным.
В любом случае, .NET тормозной не только из-за GC.
>> Что в нем такого, что оправдывает такую трату ресурсов?
> Ты идиот.
Слив защитан?
Это к чему?)) Или .NET только для фантазеров? Далеких от рещения реальных задач?
> Кстати за счет GC код типа for (;;) new obj; delete obj; будет выполняться быстрей чем на твоем asm или ещё на чем ты там помешан.
И памяти потратит столько же? И где интересно нужен пустой цикл, создающий и удаляющий объекты? И зачем delete при использовании GC?
У GC есть вполне конкретные недостатки — подвисания в работе программы, большой расход памяти, кроме того с увеличением адресного пространства и количества объектов он становится не шибко эффективным.
В любом случае, .NET тормозной не только из-за GC.
>> Что в нем такого, что оправдывает такую трату ресурсов?
> Ты идиот.
Слив защитан?
UFO just landed and posted this here
Наверно ты уже сам догадался что твое «подтверждение» для меня ровным счетом ничего не значит. Иди лучше учи уроки, тролль.
UFO just landed and posted this here
Ого)) Стоило уперекнуть тролля в школинге — посыпались нормальные факты.
Уверен, что TC не зависит от «Qt, GTK, DirectX, виртуальная машина Java с базовыми библиотеками, .NET framework, Adobe Flash и множество множество других». Более того, кроме Qt/GTK вы забыли упомянуть еще и XUL — тоже дурацкую и тормозную библиотеку (или платформу?).
MFC/MSVCRT — входят в Windows с незапамятных времен, и не содержат пакостей вроде JIT или байт-кода (хотя и великоваты), так что не надо их трогать.
DirectX — нужен для прямого доступа к оборудованию, без него никак.
Остальное — уродливые монстроподобные библиотеки/рантаймы, создатели которых плевали на всякую оптимизацию (и на использование нативных контролов, вот это им точно простить нельзя!), и которые пытаются из C++ имитировать какой-то более высокоуровневый язык. Цели, преследуемые ими были другие. Кратко они называются RAD.
Во-первых, стоит заметить что программирование на C/C++ — сомнительное удовольствие в силу абсолютной невменяемости синтаксиса да и многих неудобств языка, нехватки автоматического управдения памятью, и т.д. Отладка программ на них довольно сложна, а ошибку допустить легко. Ручная работа с указателями, например, очень даже этому способствует.так же неопытный программист легко может оставить какое-нибудь переполнение буфера к примеру. Понятно, что для нормального программирования на них нужен большой опыт и знания. Это никак не может устроить современную индустрию разработки ПО. Да и думаю, самими программистам вряд ли нравится, вот они и убегают на Питон, Руби и прочие пакости.
Первая цель java/.NET — снижение требуемой квалификации для написания кода. Если язык устроен так, что не позволяет переполнить буфер, или создать утечку памяти без специальных намерений — значит зха программирование можно посадить индксов или студентов. Это очень хорошо. так как денег они просят намного меньше чем опытный программист.
Ну и второй фактор. Скорость разработки на яве и дотнете тоже (вроде как) выше. Опять же это не может не радовать разработчиков, ибо позволяет как можно быстрее выпустить (пусть сырой, пусть неэффективный) прототип/продукт и оставить конкурентов позади. Именно этому учат нас современные книги о разработке. Правда, там потом рекомендуется делать оптимизацию, рефакторинг, но если продукт уже продается — стоит ли с этим заморачиваться, тратить на это деньги? Наверно нет. тем более что рефакторинг «индусского» кода — сомнительное удовольствие.
Ну и третий фактор (зачем, зачем же нужен байт-код?) — возможность использовать при разработке 3rd-party closed-source компоненты. ведь на Си/Си++ тому, кто хочет продавать свой компонент, придется делать обфускауцию, или как то по другому защищать свои права (чтоб никто не узнал что их код писали студенты, ага), а в случае с java/.NET можно продавать/покупать компоненты, не получая исходников. Считается (видимо), что это развивает индустрию. Считается, что это одна из причин успеха java.
Ну и в случае с .NET думаю есть еще хитрый план очередного подсаживания программистов (и всех конечных пользователей) на Windows (+MSSQL +IIS +что они там еще накодили).
Нужен ли конечному пользователю ПО байт-код? Нафиг не нужен. ибо ему плевать кто там от кого прячет свой код. Нужен ли JIT? Нет байт-кода — нет компилятора. Нужно ли конечному пользователя 58 Мб библиотек на все случаи жизни? Тоже не нужно. Напишите уже пакетный менеджер и ставьте/распространяте с прграммой только непосредственно используемые библиотеки.
Нужно ли переходить с C++ на более удобный язык? Нужно ли упрощать отладку и разработку? Конечно нужно, я тоже за то чтобы отобрать возможность ручной работы с указателяим без особой надобности. Но нужно ли «более удобный» язык делать намного менее производительным, из-за всяких байт-кодов и многоэтажных фреймворков? Не уверен.
Кстати, фреймворк существует (вроде как) в 4 версиях: 1.0, 1.1, 2.0, 3.* — и новая версия *не замещает* старую (сам видел компьютеры с несколькими версиями фреймворка)! Значит количество хлама на диске пользователя будет только расти.
Еще один фактор, снижающий производительность — многоэтажные объекты, построенные друг на друге, фреймворк, содержащий кучу кода на все случаи жизни.
Ну и стремление к мультитредингу приводит к появлению тормозного кода, со всякими блокировками (в результате чего 2-поточная программа может работать на 2 ядрах медленнее однопоточной).
Есть ли среди целей создания java/.NET цель получения хорошимх/быстрых программ? Нет, нет и нет. Быстрой должна быть разработка, а то что программа получилась тормозной — не страшно, сейчас же у всех 4ядерные процессоры и 4 Гб памяти, разве нет?
Имхо, Этот подход приемлем к серверному ПО — ну написал индусский код, ну плати уж тогда за более мощный сервер, или купи 2 сервера там. Но почему платить должен конечный пользователь? — ума не приложу.
Я готов поверить, что в простых циклах выделения/удаления объектов Java/GC обгоняет ручное управление памятью (за счет более качественной оптимизации кода в первую очередь, ну и за счет того что там объекты тупо не удалются). Но посмотрите на реальный Java/.NET приложения.Я не видел ни одного, которое бы запускалось мгновенно (это при том что считается якобы java-компилатор+GC более эффективен чем C++). Отъесть по 100-200 Мб памяти у них считается нормльно. Видимо в представлении разработчиков пользователь работает исключительно с одной программой одновременно, и закрывает ее прежде чем запустимть другую. И еще этому гипотетическому пользователю доставляет удовольствие смортеть на сплеши.
Эффективный код, кроме отдельных пользователей, сегодня никому не нужен (да и никогда не был нужен видимо).
Win-Разработчики идут сейчас «путем Линукса» — цеплять даже к простому GUI-приложению по 100 Мб библиотек.
> Некоторые же недостатки по производительности из за сборщика мусора можно устранить если подойти к конкретной задаче с умом, так например подвисание при сборке можно убрать используя так называемый pooling, расход — вызовом сборщика в ручную в нужных местах.
Приложение — браузер. Когда можно вызывать сборщик так, чтобы не помешать пользователю? Объясните ка это товарищам-инвалидам из Оперы.
> Но учитывая развитие аппаратной составляющей, и развитие технологий в целом, большая часть прикладных и системных программ (если пишет не школьник) не требует этих специальных методов оптимизации при работе на среднем современном компьютере.
Какой компьютер вы считаете средним? На селероне с 512 Мб памяти тормоза есть. Увеличивать память (а память дешева как никогда this days) лениво, и кроме того есть подозрение что засыпание будет намного медленее с большим объемом.
> если вы себе не можете позволить купить лоу-енд более менее современный компьютер, вам наверно лучше вместо сидения на хабре, учится хорошо что бы потом найти работу (даже такой асоциальный элемент как я смог себе найти работу).
Пишите уж сразу прямо — .NET не для провинциалов-замкадышей-нищебродов. Хотя работа у меня есть (и слава богу она не требует использования ни java ни .NET приложений!) и я могу позволить себе регулярно апгредить железо — но зачем? лазать по форумам, отслеживать кто там какую видеокарту выпустил, путаться в аббревиатурах и каждые полгода обновлять все железо мне абсолютно неинтересно.
У дешевого железа еще одно преимущество — если что-то сломается, его просто можно выкинуть и не мучаться с гарантиями и прочей мутью.
> А там более если пишешь для удовольствие — можно взять любой язык или платформу которая вам нравиться. Главное только не нести чушь о том чего не знаете.
Только не надо называть эти технологии передовыми, и расписывать во всю, и так далее. хелловорлд на любом нормальном языке должен быть хелловорлдом, а не тянуть за собой тонну библиотек и запускаться по полминуты.
> Сам .NET версии 3.5 включает в себя огромнейшее количество готовых р�! �шений с хорошей документацией и выполненных в одном едином стиле,
придерживаясь концепций ООП. Такой функционал и возможности тотал командеру вашему и не снились, и это 50 мегабайт,
Зато «мой» тотал коммандер умеет хорошо работать с файлами, и не тормозит — вашему .NET такое и не снилось тем более. А используется ли там ООП (хотя он по моему во всех программах за последние лет 20 точно есть), и какой там стиль кода — мне по барабану.
> И сравнение объёма с объёмом готовой программы чёткой направленности является форменной спекуляцией и лицемерием.
Да просто халявщики из МС не могут нормально ничего сделать. Ну слинкуйте вы нужные библиотеки статически (если конечно ваш .NET это позволяет), если у вас небольшая программа — в чем проблема то?
> который в ближайшее время будут поставляться вместе с OS Win7 которую вы готовь поспорить первые побежите ставить как только выйдет релиз.
Нет. Лучше уж тогда сразу макось или линукс, чем пародию на них.
> Я могу вам например дать линк использования pooling при создании игр на XNA и .NET.
Бугога)) Сначала они придумывают GC, потом придумывают способ как им не пользоваться.
И вообще, все преимущества которые вы тут расписываете, я могу так же применить например к PHP или ruby. Множество библиотек, фреймворков (да-да, со стройными концепциями, вы rails например видели?), автоматическое управление памятью тоже имеется. Только если вы захотите что-то на них написать для десктопа — получится тормозная фигня, как ни оптимизируй. Десктоп — это вам не серверные приложнеия писать, тут свои особенности.
Уверен, что TC не зависит от «Qt, GTK, DirectX, виртуальная машина Java с базовыми библиотеками, .NET framework, Adobe Flash и множество множество других». Более того, кроме Qt/GTK вы забыли упомянуть еще и XUL — тоже дурацкую и тормозную библиотеку (или платформу?).
MFC/MSVCRT — входят в Windows с незапамятных времен, и не содержат пакостей вроде JIT или байт-кода (хотя и великоваты), так что не надо их трогать.
DirectX — нужен для прямого доступа к оборудованию, без него никак.
Остальное — уродливые монстроподобные библиотеки/рантаймы, создатели которых плевали на всякую оптимизацию (и на использование нативных контролов, вот это им точно простить нельзя!), и которые пытаются из C++ имитировать какой-то более высокоуровневый язык. Цели, преследуемые ими были другие. Кратко они называются RAD.
Во-первых, стоит заметить что программирование на C/C++ — сомнительное удовольствие в силу абсолютной невменяемости синтаксиса да и многих неудобств языка, нехватки автоматического управдения памятью, и т.д. Отладка программ на них довольно сложна, а ошибку допустить легко. Ручная работа с указателями, например, очень даже этому способствует.так же неопытный программист легко может оставить какое-нибудь переполнение буфера к примеру. Понятно, что для нормального программирования на них нужен большой опыт и знания. Это никак не может устроить современную индустрию разработки ПО. Да и думаю, самими программистам вряд ли нравится, вот они и убегают на Питон, Руби и прочие пакости.
Первая цель java/.NET — снижение требуемой квалификации для написания кода. Если язык устроен так, что не позволяет переполнить буфер, или создать утечку памяти без специальных намерений — значит зха программирование можно посадить индксов или студентов. Это очень хорошо. так как денег они просят намного меньше чем опытный программист.
Ну и второй фактор. Скорость разработки на яве и дотнете тоже (вроде как) выше. Опять же это не может не радовать разработчиков, ибо позволяет как можно быстрее выпустить (пусть сырой, пусть неэффективный) прототип/продукт и оставить конкурентов позади. Именно этому учат нас современные книги о разработке. Правда, там потом рекомендуется делать оптимизацию, рефакторинг, но если продукт уже продается — стоит ли с этим заморачиваться, тратить на это деньги? Наверно нет. тем более что рефакторинг «индусского» кода — сомнительное удовольствие.
Ну и третий фактор (зачем, зачем же нужен байт-код?) — возможность использовать при разработке 3rd-party closed-source компоненты. ведь на Си/Си++ тому, кто хочет продавать свой компонент, придется делать обфускауцию, или как то по другому защищать свои права (чтоб никто не узнал что их код писали студенты, ага), а в случае с java/.NET можно продавать/покупать компоненты, не получая исходников. Считается (видимо), что это развивает индустрию. Считается, что это одна из причин успеха java.
Ну и в случае с .NET думаю есть еще хитрый план очередного подсаживания программистов (и всех конечных пользователей) на Windows (+MSSQL +IIS +что они там еще накодили).
Нужен ли конечному пользователю ПО байт-код? Нафиг не нужен. ибо ему плевать кто там от кого прячет свой код. Нужен ли JIT? Нет байт-кода — нет компилятора. Нужно ли конечному пользователя 58 Мб библиотек на все случаи жизни? Тоже не нужно. Напишите уже пакетный менеджер и ставьте/распространяте с прграммой только непосредственно используемые библиотеки.
Нужно ли переходить с C++ на более удобный язык? Нужно ли упрощать отладку и разработку? Конечно нужно, я тоже за то чтобы отобрать возможность ручной работы с указателяим без особой надобности. Но нужно ли «более удобный» язык делать намного менее производительным, из-за всяких байт-кодов и многоэтажных фреймворков? Не уверен.
Кстати, фреймворк существует (вроде как) в 4 версиях: 1.0, 1.1, 2.0, 3.* — и новая версия *не замещает* старую (сам видел компьютеры с несколькими версиями фреймворка)! Значит количество хлама на диске пользователя будет только расти.
Еще один фактор, снижающий производительность — многоэтажные объекты, построенные друг на друге, фреймворк, содержащий кучу кода на все случаи жизни.
Ну и стремление к мультитредингу приводит к появлению тормозного кода, со всякими блокировками (в результате чего 2-поточная программа может работать на 2 ядрах медленнее однопоточной).
Есть ли среди целей создания java/.NET цель получения хорошимх/быстрых программ? Нет, нет и нет. Быстрой должна быть разработка, а то что программа получилась тормозной — не страшно, сейчас же у всех 4ядерные процессоры и 4 Гб памяти, разве нет?
Имхо, Этот подход приемлем к серверному ПО — ну написал индусский код, ну плати уж тогда за более мощный сервер, или купи 2 сервера там. Но почему платить должен конечный пользователь? — ума не приложу.
Я готов поверить, что в простых циклах выделения/удаления объектов Java/GC обгоняет ручное управление памятью (за счет более качественной оптимизации кода в первую очередь, ну и за счет того что там объекты тупо не удалются). Но посмотрите на реальный Java/.NET приложения.Я не видел ни одного, которое бы запускалось мгновенно (это при том что считается якобы java-компилатор+GC более эффективен чем C++). Отъесть по 100-200 Мб памяти у них считается нормльно. Видимо в представлении разработчиков пользователь работает исключительно с одной программой одновременно, и закрывает ее прежде чем запустимть другую. И еще этому гипотетическому пользователю доставляет удовольствие смортеть на сплеши.
Эффективный код, кроме отдельных пользователей, сегодня никому не нужен (да и никогда не был нужен видимо).
Win-Разработчики идут сейчас «путем Линукса» — цеплять даже к простому GUI-приложению по 100 Мб библиотек.
> Некоторые же недостатки по производительности из за сборщика мусора можно устранить если подойти к конкретной задаче с умом, так например подвисание при сборке можно убрать используя так называемый pooling, расход — вызовом сборщика в ручную в нужных местах.
Приложение — браузер. Когда можно вызывать сборщик так, чтобы не помешать пользователю? Объясните ка это товарищам-инвалидам из Оперы.
> Но учитывая развитие аппаратной составляющей, и развитие технологий в целом, большая часть прикладных и системных программ (если пишет не школьник) не требует этих специальных методов оптимизации при работе на среднем современном компьютере.
Какой компьютер вы считаете средним? На селероне с 512 Мб памяти тормоза есть. Увеличивать память (а память дешева как никогда this days) лениво, и кроме того есть подозрение что засыпание будет намного медленее с большим объемом.
> если вы себе не можете позволить купить лоу-енд более менее современный компьютер, вам наверно лучше вместо сидения на хабре, учится хорошо что бы потом найти работу (даже такой асоциальный элемент как я смог себе найти работу).
Пишите уж сразу прямо — .NET не для провинциалов-замкадышей-нищебродов. Хотя работа у меня есть (и слава богу она не требует использования ни java ни .NET приложений!) и я могу позволить себе регулярно апгредить железо — но зачем? лазать по форумам, отслеживать кто там какую видеокарту выпустил, путаться в аббревиатурах и каждые полгода обновлять все железо мне абсолютно неинтересно.
У дешевого железа еще одно преимущество — если что-то сломается, его просто можно выкинуть и не мучаться с гарантиями и прочей мутью.
> А там более если пишешь для удовольствие — можно взять любой язык или платформу которая вам нравиться. Главное только не нести чушь о том чего не знаете.
Только не надо называть эти технологии передовыми, и расписывать во всю, и так далее. хелловорлд на любом нормальном языке должен быть хелловорлдом, а не тянуть за собой тонну библиотек и запускаться по полминуты.
> Сам .NET версии 3.5 включает в себя огромнейшее количество готовых р�! �шений с хорошей документацией и выполненных в одном едином стиле,
придерживаясь концепций ООП. Такой функционал и возможности тотал командеру вашему и не снились, и это 50 мегабайт,
Зато «мой» тотал коммандер умеет хорошо работать с файлами, и не тормозит — вашему .NET такое и не снилось тем более. А используется ли там ООП (хотя он по моему во всех программах за последние лет 20 точно есть), и какой там стиль кода — мне по барабану.
> И сравнение объёма с объёмом готовой программы чёткой направленности является форменной спекуляцией и лицемерием.
Да просто халявщики из МС не могут нормально ничего сделать. Ну слинкуйте вы нужные библиотеки статически (если конечно ваш .NET это позволяет), если у вас небольшая программа — в чем проблема то?
> который в ближайшее время будут поставляться вместе с OS Win7 которую вы готовь поспорить первые побежите ставить как только выйдет релиз.
Нет. Лучше уж тогда сразу макось или линукс, чем пародию на них.
> Я могу вам например дать линк использования pooling при создании игр на XNA и .NET.
Бугога)) Сначала они придумывают GC, потом придумывают способ как им не пользоваться.
И вообще, все преимущества которые вы тут расписываете, я могу так же применить например к PHP или ruby. Множество библиотек, фреймворков (да-да, со стройными концепциями, вы rails например видели?), автоматическое управление памятью тоже имеется. Только если вы захотите что-то на них написать для десктопа — получится тормозная фигня, как ни оптимизируй. Десктоп — это вам не серверные приложнеия писать, тут свои особенности.
UFO just landed and posted this here
Ни один из аргументов (ну, кроме цифр может быть и тривиальных замечаний) не соответствует реальному положению вещей.
Вы тролль-популист?
К каждому вашему замечанию выше хочется заметить следующее — «пруфлинк или вы фейл»
Вы тролль-популист?
К каждому вашему замечанию выше хочется заметить следующее — «пруфлинк или вы фейл»
… ну в смысле:
>> Уверен, что TC не зависит от «Qt, GTK, DirectX, виртуальная машина Java с базовыми библиотеками, .NET framework, Adobe Flash и множество множество других».
Пруфлинк или вы — не разбираетесь
MFC/MSVCRT — входят в Windows с незапамятных времен, и не содержат пакостей вроде JIT или байт-кода (хотя и великоваты), так что не надо их трогать.
Пруфлинк или вы — не разбираетесь
DirectX — нужен для прямого доступа к оборудованию, без него никак
Пруфлинк или вы — не разбираетесь
… далее вы поняли, куда грести.
>> Уверен, что TC не зависит от «Qt, GTK, DirectX, виртуальная машина Java с базовыми библиотеками, .NET framework, Adobe Flash и множество множество других».
Пруфлинк или вы — не разбираетесь
MFC/MSVCRT — входят в Windows с незапамятных времен, и не содержат пакостей вроде JIT или байт-кода (хотя и великоваты), так что не надо их трогать.
Пруфлинк или вы — не разбираетесь
DirectX — нужен для прямого доступа к оборудованию, без него никак
Пруфлинк или вы — не разбираетесь
… далее вы поняли, куда грести.
>> Уверен, что TC не зависит от «Qt, GTK, DirectX, виртуальная машина Java с базовыми библиотеками, .NET framework, Adobe Flash и множество множество других».
> Пруфлинк или вы — не разбираетесь
Прежде чем это писать, я не поленился заглянуть в папку TC и посмотреть, какие там есть библиотеки. так же глянул с помощью PeID процесс TotalCmd.exe на предмет того, какие библиотеки в него подгружены (только виндовые станд. библиотеки из system32, довольно таки много, видимо они все тянут друг друга, и несколько плагинов из папки TC для работы с разными архивами, типа UNRAR.DLL и так далее).
По слухам, TC писан на Delphi, и довольно таки давно, соответственно Qt/GTK там быть не может (да и gtk под windows работает довольно таки плохо, я бы узнал))). Java/.NET он тоже для установки не требует, и Flash тем более. Да и работал бы он на них хуже и медленнее, трудно было бы не заметить)))
к тому же я запускал TC на компьютерах без .NET и Java.
Если бы мне очень-очень надо было, я бы мог еще ProcMon просмотреть все файлы, которые он открывает.
Какой я тут могу предоставить пруфлинк? Подойти с ножом к автору и грозно спросить, какие библиотеки он использовал? Это же не OpenSource.
Или вы мне подкините пруфлинк, что Total commander написан на Java? Но-но, интересно будет почитать.
Насчет MFC — там согласен, мутная ситуация, в каких-то версиях windows эти библиотеки есть, в каких-то нет. Тут проще включать dll с программой и не париться. Или как-то без них обойтись.
MSVCRT — входит в винду начиная с 98. Пруфы ищите тут: support.microsoft.com/servicedesks/fileversion/dllinfo.asp
То же и с остальными. Не вижу никакого смысла искать пруфлинк насчет того, что DirectX предоставляет доступ к видеокарте. Не верите — не надо.
По поводу производительности Java/.NET — я тут верю своим глазам а не результатам тестов на выделение объектов, или подсчета какой-нибудь простой функции. Ибо если я вижу что программа тормозит, или требует 30 мегабайтный инсталлятор, или ест 50 мегабайт памяти, или не хочет использовать нативные контролы — это и есть реальный показатель.
> Пруфлинк или вы — не разбираетесь
Прежде чем это писать, я не поленился заглянуть в папку TC и посмотреть, какие там есть библиотеки. так же глянул с помощью PeID процесс TotalCmd.exe на предмет того, какие библиотеки в него подгружены (только виндовые станд. библиотеки из system32, довольно таки много, видимо они все тянут друг друга, и несколько плагинов из папки TC для работы с разными архивами, типа UNRAR.DLL и так далее).
По слухам, TC писан на Delphi, и довольно таки давно, соответственно Qt/GTK там быть не может (да и gtk под windows работает довольно таки плохо, я бы узнал))). Java/.NET он тоже для установки не требует, и Flash тем более. Да и работал бы он на них хуже и медленнее, трудно было бы не заметить)))
к тому же я запускал TC на компьютерах без .NET и Java.
Если бы мне очень-очень надо было, я бы мог еще ProcMon просмотреть все файлы, которые он открывает.
Какой я тут могу предоставить пруфлинк? Подойти с ножом к автору и грозно спросить, какие библиотеки он использовал? Это же не OpenSource.
Или вы мне подкините пруфлинк, что Total commander написан на Java? Но-но, интересно будет почитать.
Насчет MFC — там согласен, мутная ситуация, в каких-то версиях windows эти библиотеки есть, в каких-то нет. Тут проще включать dll с программой и не париться. Или как-то без них обойтись.
MSVCRT — входит в винду начиная с 98. Пруфы ищите тут: support.microsoft.com/servicedesks/fileversion/dllinfo.asp
То же и с остальными. Не вижу никакого смысла искать пруфлинк насчет того, что DirectX предоставляет доступ к видеокарте. Не верите — не надо.
По поводу производительности Java/.NET — я тут верю своим глазам а не результатам тестов на выделение объектов, или подсчета какой-нибудь простой функции. Ибо если я вижу что программа тормозит, или требует 30 мегабайтный инсталлятор, или ест 50 мегабайт памяти, или не хочет использовать нативные контролы — это и есть реальный показатель.
>>Не вижу никакого смысла искать пруфлинк насчет того, что DirectX
предоставляет доступ к видеокарте. Не верите — не надо.
Речь шла (цитирую вас) «DirectX — нужен для прямого доступа к оборудованию, без него никак». Так вот, прямой доступ к оборудованию предоставляют абстракции HAL и драйвера. Сам DirectX — наоборот — изолирует вас от оборудования: для вас есть абстрактная графическая машина, и вы ею управляете. Все. Прямой доступ закончился со времен DirectX 5 (Когда он был еще DirectDraw).
>> или требует 30 мегабайтный инсталлятор
Вы внимательнее почитайте. Этот инсталлятор — для фреймворка, а не для программы. Будучи поставлен единожды, остальные программы (в инсталляторе) имеют характерный размер в 100 — 500 кб. С возможностями, сравнимыми с MS Office. Речь об этом и о том как упростить и уменьшить далее сам инсталлятор фреймворка.
>> MSVCRT — входит в винду начиная с 98
Вы забыли указать версию библиотеки. В винде она обычно 7.1 (Win XP SP). Для более новых программ (VS2005) нужно тащить эту библиотеку вместе с программой — к каждой программе. Немного, но неприятно.
>> По поводу производительности Java/.NET… []… или не хочет использовать нативные контролы…
Простите, не вижу связи между нативными контролами и производительностью. Вы про Java? Так она не использует нативные контролы, потому что работает на разных платформах без перекомпиляции. На разных платформах — разные нативные контролы, всех не отследишь. Поэтому используются свои, из JRE.
>> требует 30 мегабайтный инсталлятор…
Аналогично, отношения к производительности не имеет. Просто секрет в том, что в винду (XP, например) встроен рантаймы для c++ и mfc, а для .net — нет. Он появился позже. В следующих версиях винды — тоже будет встроен, так что ничего тащить не надо будет.
— Вывод мой, в общем-то прост. Вы чересчур импульсивно высказываете свое мнение, которое, к сожалению, опирается на факты, которые либо устарели, либо являются не фактами, а домыслами. Все попытки вам на это указать ни к чему не приводят. По поводу DirectX — вы неправы. По поводу MFC — уже сдались и признали неправоту.
Факт: в .net/java гораздо проще не допускать ошибки, а если случились — искать и отлавливать их. Гораздо проще, чем в с++. Я с ужасом вспоминаю многочасовые сессии в отладчике.
Реальность такова, что программирование — это не поиск дао и не процесс ради процесса — это удовлетворение нужд бизнеса прежде всего. И с точки зрения бизнеса технология, позволяющая упростить и ускорить разработку банально выигрывает. По простым показателям выгоды и окупаемости.
Я ясно выражаюсь? И есть ли смысл продолжать диалог?
предоставляет доступ к видеокарте. Не верите — не надо.
Речь шла (цитирую вас) «DirectX — нужен для прямого доступа к оборудованию, без него никак». Так вот, прямой доступ к оборудованию предоставляют абстракции HAL и драйвера. Сам DirectX — наоборот — изолирует вас от оборудования: для вас есть абстрактная графическая машина, и вы ею управляете. Все. Прямой доступ закончился со времен DirectX 5 (Когда он был еще DirectDraw).
>> или требует 30 мегабайтный инсталлятор
Вы внимательнее почитайте. Этот инсталлятор — для фреймворка, а не для программы. Будучи поставлен единожды, остальные программы (в инсталляторе) имеют характерный размер в 100 — 500 кб. С возможностями, сравнимыми с MS Office. Речь об этом и о том как упростить и уменьшить далее сам инсталлятор фреймворка.
>> MSVCRT — входит в винду начиная с 98
Вы забыли указать версию библиотеки. В винде она обычно 7.1 (Win XP SP). Для более новых программ (VS2005) нужно тащить эту библиотеку вместе с программой — к каждой программе. Немного, но неприятно.
>> По поводу производительности Java/.NET… []… или не хочет использовать нативные контролы…
Простите, не вижу связи между нативными контролами и производительностью. Вы про Java? Так она не использует нативные контролы, потому что работает на разных платформах без перекомпиляции. На разных платформах — разные нативные контролы, всех не отследишь. Поэтому используются свои, из JRE.
>> требует 30 мегабайтный инсталлятор…
Аналогично, отношения к производительности не имеет. Просто секрет в том, что в винду (XP, например) встроен рантаймы для c++ и mfc, а для .net — нет. Он появился позже. В следующих версиях винды — тоже будет встроен, так что ничего тащить не надо будет.
— Вывод мой, в общем-то прост. Вы чересчур импульсивно высказываете свое мнение, которое, к сожалению, опирается на факты, которые либо устарели, либо являются не фактами, а домыслами. Все попытки вам на это указать ни к чему не приводят. По поводу DirectX — вы неправы. По поводу MFC — уже сдались и признали неправоту.
Факт: в .net/java гораздо проще не допускать ошибки, а если случились — искать и отлавливать их. Гораздо проще, чем в с++. Я с ужасом вспоминаю многочасовые сессии в отладчике.
Реальность такова, что программирование — это не поиск дао и не процесс ради процесса — это удовлетворение нужд бизнеса прежде всего. И с точки зрения бизнеса технология, позволяющая упростить и ускорить разработку банально выигрывает. По простым показателям выгоды и окупаемости.
Я ясно выражаюсь? И есть ли смысл продолжать диалог?
Я охотно поверю, что с точки зрения бизнеса .NET/Java выгоднее (хотя тут еще конечно смотреть надо в каждой конкретной ситуации). Но «выгоднее с точки зрения бизнеса разработчика» != «выгоднее для конечного пользователя», согласитесь?
Все мои расуждения — рассуждения с точки зрения «выгодно ли это для меня». Нет, не выгодно. Я бы предпочел пользоваться компактными, не требующими инсталляции, быстрыми программами с удобным интерфейсом (и с нативными контролами), а предстоит (похоже) пользоваться тем что получится. Или не устанавливать новые версии программ — в принципе думаю года на 3 существующих еще хватит, а там может наконец какую-нибудь хорошую технологию придумают. Слава богу, сегодня нет ни 1 программы на .NET, которая была бы мне необходима.
Принцип RAD проталкивают уже не первый год, когда-то на роль среды для RAD MS пропихивала Visual Basic (видимо они посчитали что большинство программистов тупы и C++ не осилят). С одной стороны, повторюсь, я тоже за языки, где не надо руками вызывать delete, и возиться с указателями, конструкторами копирования и прочими ужасами. Но должен ли этот язык быть менее производителен? Не уверен. Должны ли к нему идти громоздкие библиотеки и фреймворки? Не знаю. Должен ли он использовать GC? Тоже не знаю. И почему компилятор выдает байт-код а не номальный машинный код? Что за фигня? И нужны ли вещи вроде RTTI, или Reflection в не-отладочном режиме? Мне как пользователю нафиг не нужны, уберите их из программы.
> Будучи поставлен единожды, остальные программы (в инсталляторе) имеют характерный размер в 100 — 500 кб.
Уверен, размер инсталлятора будет только расти, раньше стремились заполнить CD-диск, теперь на DVD замахнулись, а ведь есть еще Blue Ray((
> Для более новых программ (VS2005) нужно тащить эту библиотеку вместе с программой — к каждой программе.
Линкуйте против старой версии, в чем проблема?
> Простите, не вижу связи между нативными контролами и производительностью. Вы про Java?
Я не связывал падение производительности с ненативными контролами (хотя оно подозреваю должно быть). я написал, что мне не нравится как низкая производительность java-программ, так и неуважение к настройкам моего интерфейса. Идея сделать чтобы все программы имели одинаковый look&feel под разными платформами имхо дурацкая, так как всюду эти приложения выглядят не к месту, ими не так удобно пользоваться. Кроме того, дефолтные темы этой граф. библиотеки тоже довольно безвкусны (сан не может найти нормального дизайнера? или как часто бывает у них дизайн рисовали программисты?), что еще больше отталкивает от написанных с ее использованием программ.
> На разных платформах — разные нативные контролы, всех не отследишь. Поэтому используются свои, из JRE.
Там есть какая-то другая библиотека (JWT? не помню), которая как раз используе нативные контролы.
> Просто секрет в том, что в винду (XP, например) встроен рантаймы для c++ и mfc, а для .net — нет. Он появился позже. В следующих версиях винды — тоже будет встроен, так что ничего тащить не надо будет.
Ну вот когда у всех уже будет 5 лет стоять виста или семерка (и всюду будут 32-ядерные процессоры), тогда и отношение к .NET может быть у меня будет другое. Но вряд ли.
Сейчас такая ситуация, что разработать новую среду/платформу для разработки, может только очень крупная компания, вот и приходится безальтернативно выбирать лучшее из худшего. Либо .NET либо java, либо какой-нибудь с++/Qt (на который вообще наверно сейчас никого не заманишь).
вы рассуждаете с точки зрения бизнеса разработчика, я с точки зрения пользователя, вот и вся разница. Пользователю, от того, используете вы MVC и ООП ни жарко ни холодно, а вот если у вас кривой интерфейс, или программа тормозит — вот от этого уже холодно.
Все мои расуждения — рассуждения с точки зрения «выгодно ли это для меня». Нет, не выгодно. Я бы предпочел пользоваться компактными, не требующими инсталляции, быстрыми программами с удобным интерфейсом (и с нативными контролами), а предстоит (похоже) пользоваться тем что получится. Или не устанавливать новые версии программ — в принципе думаю года на 3 существующих еще хватит, а там может наконец какую-нибудь хорошую технологию придумают. Слава богу, сегодня нет ни 1 программы на .NET, которая была бы мне необходима.
Принцип RAD проталкивают уже не первый год, когда-то на роль среды для RAD MS пропихивала Visual Basic (видимо они посчитали что большинство программистов тупы и C++ не осилят). С одной стороны, повторюсь, я тоже за языки, где не надо руками вызывать delete, и возиться с указателями, конструкторами копирования и прочими ужасами. Но должен ли этот язык быть менее производителен? Не уверен. Должны ли к нему идти громоздкие библиотеки и фреймворки? Не знаю. Должен ли он использовать GC? Тоже не знаю. И почему компилятор выдает байт-код а не номальный машинный код? Что за фигня? И нужны ли вещи вроде RTTI, или Reflection в не-отладочном режиме? Мне как пользователю нафиг не нужны, уберите их из программы.
> Будучи поставлен единожды, остальные программы (в инсталляторе) имеют характерный размер в 100 — 500 кб.
Уверен, размер инсталлятора будет только расти, раньше стремились заполнить CD-диск, теперь на DVD замахнулись, а ведь есть еще Blue Ray((
> Для более новых программ (VS2005) нужно тащить эту библиотеку вместе с программой — к каждой программе.
Линкуйте против старой версии, в чем проблема?
> Простите, не вижу связи между нативными контролами и производительностью. Вы про Java?
Я не связывал падение производительности с ненативными контролами (хотя оно подозреваю должно быть). я написал, что мне не нравится как низкая производительность java-программ, так и неуважение к настройкам моего интерфейса. Идея сделать чтобы все программы имели одинаковый look&feel под разными платформами имхо дурацкая, так как всюду эти приложения выглядят не к месту, ими не так удобно пользоваться. Кроме того, дефолтные темы этой граф. библиотеки тоже довольно безвкусны (сан не может найти нормального дизайнера? или как часто бывает у них дизайн рисовали программисты?), что еще больше отталкивает от написанных с ее использованием программ.
> На разных платформах — разные нативные контролы, всех не отследишь. Поэтому используются свои, из JRE.
Там есть какая-то другая библиотека (JWT? не помню), которая как раз используе нативные контролы.
> Просто секрет в том, что в винду (XP, например) встроен рантаймы для c++ и mfc, а для .net — нет. Он появился позже. В следующих версиях винды — тоже будет встроен, так что ничего тащить не надо будет.
Ну вот когда у всех уже будет 5 лет стоять виста или семерка (и всюду будут 32-ядерные процессоры), тогда и отношение к .NET может быть у меня будет другое. Но вряд ли.
Сейчас такая ситуация, что разработать новую среду/платформу для разработки, может только очень крупная компания, вот и приходится безальтернативно выбирать лучшее из худшего. Либо .NET либо java, либо какой-нибудь с++/Qt (на который вообще наверно сейчас никого не заманишь).
вы рассуждаете с точки зрения бизнеса разработчика, я с точки зрения пользователя, вот и вся разница. Пользователю, от того, используете вы MVC и ООП ни жарко ни холодно, а вот если у вас кривой интерфейс, или программа тормозит — вот от этого уже холодно.
>> Но «выгоднее с точки зрения бизнеса разработчика» != «выгоднее для конечного пользователя», согласитесь?
Не соглашусь. весь сервис build/deploy/update гораздо проще вести в .net. Т.е. конечному пользователю гораздо проще и быстрее получить обновление, потому что я (грубо) это обновление быстрее выпущу.
>> Принцип RAD проталкивают уже не первый год, когда-то на роль среды для RAD MS пропихивала Visual Basic
Вы путаете RAD и .net. Родоначальник RAD — это Delphi, там .net и не «пахло». Microsoft пропихивала VB в основном по той причине, что он тесно связан с COM, который интегрирован в Windows.
>>Я бы предпочел пользоваться компактными, не требующими инсталляции, быстрыми программами с удобным интерфейсом (и с нативными контролами), а предстоит (похоже) пользоваться тем что получится
Именно это и несет с собой .net — компактные, удобные, быстрые, не требующие инсталляции программы. Беда не в платформе, а в быдлокодерах.
>> (и с нативными контролами)
В .net под windows нативные контролы (не все, правда), если что. Чуть раньше вы сказали, что вам, как пользователю, глубоко фиолетово, что там внутри. Вот. Я думаю, что глубоко фиолетово, нативные они или нет.
>> И почему компилятор выдает байт-код а не номальный машинный код? Что за фигня?
Читайте выше: он внутри, и вам на него чихать. Он вам его по почте шлет и спамит, что ли? =) В .net перед выполнением сборка компилируется в машинный код (причем оптимизируясь с учетом архитектуры вашего конкретного процессора, а не абстрактного x86, который внутри уже давно RISC over CISC). Эта компиляция занимает характерное время в 0.01 — 0.1 секунду для всего приложения целиком — это быстрее, чем дабл-кликнуть по иконке. Для наиболее частых запускаемых приложений специальный сервис windows хранит уже откомпилированные в машинный код сборки — так что даже на это время не тратится.
>> И нужны ли вещи вроде RTTI, или Reflection в не-отладочном режиме?
Поверьте, нужны. Часто их используют не только для интроспекции кода.
>>а вот если у вас кривой интерфейс, или программа тормозит — вот от этого уже холодно.
Немного про себя. У меня средний ноутбук, я разрабатываю на нем в .net (и в линуксе под mono тоже), приложения не тормозят. Что я делаю не так? :)
Вернее сказать так — у меня много приложений, которые не тормозят, несмотря на то, что написаны с использованием .net fw. Так что это не к технологии придирки, а кривым рукам программистов.
Не соглашусь. весь сервис build/deploy/update гораздо проще вести в .net. Т.е. конечному пользователю гораздо проще и быстрее получить обновление, потому что я (грубо) это обновление быстрее выпущу.
>> Принцип RAD проталкивают уже не первый год, когда-то на роль среды для RAD MS пропихивала Visual Basic
Вы путаете RAD и .net. Родоначальник RAD — это Delphi, там .net и не «пахло». Microsoft пропихивала VB в основном по той причине, что он тесно связан с COM, который интегрирован в Windows.
>>Я бы предпочел пользоваться компактными, не требующими инсталляции, быстрыми программами с удобным интерфейсом (и с нативными контролами), а предстоит (похоже) пользоваться тем что получится
Именно это и несет с собой .net — компактные, удобные, быстрые, не требующие инсталляции программы. Беда не в платформе, а в быдлокодерах.
>> (и с нативными контролами)
В .net под windows нативные контролы (не все, правда), если что. Чуть раньше вы сказали, что вам, как пользователю, глубоко фиолетово, что там внутри. Вот. Я думаю, что глубоко фиолетово, нативные они или нет.
>> И почему компилятор выдает байт-код а не номальный машинный код? Что за фигня?
Читайте выше: он внутри, и вам на него чихать. Он вам его по почте шлет и спамит, что ли? =) В .net перед выполнением сборка компилируется в машинный код (причем оптимизируясь с учетом архитектуры вашего конкретного процессора, а не абстрактного x86, который внутри уже давно RISC over CISC). Эта компиляция занимает характерное время в 0.01 — 0.1 секунду для всего приложения целиком — это быстрее, чем дабл-кликнуть по иконке. Для наиболее частых запускаемых приложений специальный сервис windows хранит уже откомпилированные в машинный код сборки — так что даже на это время не тратится.
>> И нужны ли вещи вроде RTTI, или Reflection в не-отладочном режиме?
Поверьте, нужны. Часто их используют не только для интроспекции кода.
>>а вот если у вас кривой интерфейс, или программа тормозит — вот от этого уже холодно.
Немного про себя. У меня средний ноутбук, я разрабатываю на нем в .net (и в линуксе под mono тоже), приложения не тормозят. Что я делаю не так? :)
Вернее сказать так — у меня много приложений, которые не тормозят, несмотря на то, что написаны с использованием .net fw. Так что это не к технологии придирки, а кривым рукам программистов.
> Не соглашусь. весь сервис build/deploy/update гораздо проще вести в .net. Т.е. конечному пользователю гораздо проще и быстрее получить обновление, потому что я (грубо) это обновление быстрее выпущу.
Какой еще build/deploy/update? Я про программы для нормальных пользователей, а не корпораций, мне не надо обновлять программу, зачем? скачал/распаковал и все, больше ничего не надо.
Вообще, если вы расписывали преимущества дотнета для всяких корпоративных программ. то фиг с ними, там действительно. забота админа ставить фреймворки, и прочее, да и не так жалко на рабочий компьютер все подряд ставить)) Да и корпоративным пользователям обычно не положено кучу программ запускать (обычно офис и какой-нибудь 1с), так что им по барабану сколько программа памяти ест, хоть даже она программа всю память съедает. А вот мне нет.
Я имел в виду прежде всего какие-то массовые программы, вроде: ворд, плеер, браузер, редактор кода, тотал коммандер и похожие. Ну кто будет апгрейдить плеер?
> Беда не в платформе, а в быдлокодерах.
Сделай язык, на котором сможет писать и идиот — идиоты в основном и будут на нем писать. Если дешевле нанять студента/индуса (в переностном смысле, ничего лично против индусов и студентов не имею), их и наймут. Хотя наверно дотнет тут не особо виноват.
> Чуть раньше вы сказали, что вам, как пользователю, глубоко фиолетово, что там внутри. Вот. Я думаю, что глубоко фиолетово, нативные они или нет.
Если программа из за него не жрет память мегабайтами, и если его поведение/вид не отличается от нативного то да, пофиг. правда думаю, что чем такое качественно реализовать, проще пользоваться нативными))
> Эта компиляция занимает характерное время в 0.01 — 0.1 секунду для всего приложения целиком — это быстрее, чем дабл-кликнуть по иконке.
К сожалению у меня нет возможности проверить, но что-то я плохо представляю компилятор, который обрабатывает код со скоростью несколько десятков мегабайт в секунду (500 Кб/ 0.01 сек = 50 Мб./сек.), и еще как-то при этом оптимизирует его. Правда, не верится.
Кроме того, непонятно какой смысл компилировать программу в момент запуска. Чушь какая то. Я хочу запустить программу, а не компилировать ее. Почему бы не скомпилировать ее разработчику? Или пусть так уж и быть она компилируется при первом запуске/установке, я не против подождать, если она действительно оптимизируется под мой процессор (опять-таки думаю МС просто лениво было бы делать все эти оптимизации в своем компиляторе).
Кроме того, подозреваю, что в то время как обычный exe файл не загружается целиком в память, а просто ммапится на область памяти, в схеме с JIT эта возможность теряется.
В общем ИМХО, байт-код и JIT — направлены не на благо пользователя, а на возможность нераскрываения исходников разработчиками.
> Поверьте, нужны. Часто их используют не только для интроспекции кода.
Даже если и нужны, наверняка можно сделать то же самое и без них, более эффективно? Ну неужели никак?
> Немного про себя. У меня средний ноутбук, я разрабатываю на нем в .net (и в линуксе под mono тоже), приложения не тормозят. Что я делаю не так? :)
Возможно, у вас другое понятие «не тормозят». Возможно, вы не спеша любите пофилософствовать пока компьютер «думает». Возможно вы не запускаете больше 1-2-3 программ одновременно. Возможно у вас 2-3 Гб памяти (и программы просто закешированы там, но только после первого запуска). Однако когда много памяти, компьютер будет долго «засыпать»/«просыпаться», а это меня не устраивает еще больше (поэтому у меня памяти мало).
У меня основные программы, плеер, редактор кода, запускаются за секунду, а если они закешированы в памяти то и быстрее. И именно столько времени они и должны запуcкаться а не больше. Смотрите: офис XP, Хром, ИЕ6 (хоть он и плохой, но стартует быстро) — все запускаются быстро, офис к тому же очень экономно относится к памяти (особенно в сравнении с опенофисом). Потому что у их разработчиков руки прямые.
А вот кривы руки у разработчиков Zend Studio (java, запускается до 30 сек.), Komodo (вроде как на XUL, тормозит страшно), FireFox3 (XUL), ну и вообще куча программ сделаны так, как будто для врага писались. Естественно, такие программы либо сносятся мной, либо сразу же запускаются как можно реже.
Еще кстати иногда я пользуюсь фотошопом, но так как он долго запускается (кривоваты руки у адоба видно), я его просто не закрываю, в свернутом состоянии он особо память не потребляет. Зато хоть при работе не тормозит.
Вообще имхо сегодня нет ни одной убедительной причины для не-сверх-сложных программ медленно запускаться или работать, на процессорах делающих миллиард операций (вдумайтесь в эту цифру!) в секунду. разве что игры — но там действительно все очень сложно, много графики, и т.д.
Я пока не видел аналогичных по ресурсам и возможностям программ на .NET или java. увижу — другое дело (но вряд ли это будет) А смотреть на сплеши — это извините возврат к временам Win95. Не для того лучшие умы улучшали 30 лет процессоры, не для того я оптимизировал винду, чтобы я ждал пока что то там запустится.
А возвращаясь к .NET Client Profile — неужели нельзя поставлять с программой только те библиотеки которые реально ей используются? Ну как dll-ки, кинул в папку с программой и не паришься. Или просто лень возиться, проще сразу все 30 мегабайт засунуть? Нафиг такой язык, на котором хелловорд весит 30 мегабайт.
Какой еще build/deploy/update? Я про программы для нормальных пользователей, а не корпораций, мне не надо обновлять программу, зачем? скачал/распаковал и все, больше ничего не надо.
Вообще, если вы расписывали преимущества дотнета для всяких корпоративных программ. то фиг с ними, там действительно. забота админа ставить фреймворки, и прочее, да и не так жалко на рабочий компьютер все подряд ставить)) Да и корпоративным пользователям обычно не положено кучу программ запускать (обычно офис и какой-нибудь 1с), так что им по барабану сколько программа памяти ест, хоть даже она программа всю память съедает. А вот мне нет.
Я имел в виду прежде всего какие-то массовые программы, вроде: ворд, плеер, браузер, редактор кода, тотал коммандер и похожие. Ну кто будет апгрейдить плеер?
> Беда не в платформе, а в быдлокодерах.
Сделай язык, на котором сможет писать и идиот — идиоты в основном и будут на нем писать. Если дешевле нанять студента/индуса (в переностном смысле, ничего лично против индусов и студентов не имею), их и наймут. Хотя наверно дотнет тут не особо виноват.
> Чуть раньше вы сказали, что вам, как пользователю, глубоко фиолетово, что там внутри. Вот. Я думаю, что глубоко фиолетово, нативные они или нет.
Если программа из за него не жрет память мегабайтами, и если его поведение/вид не отличается от нативного то да, пофиг. правда думаю, что чем такое качественно реализовать, проще пользоваться нативными))
> Эта компиляция занимает характерное время в 0.01 — 0.1 секунду для всего приложения целиком — это быстрее, чем дабл-кликнуть по иконке.
К сожалению у меня нет возможности проверить, но что-то я плохо представляю компилятор, который обрабатывает код со скоростью несколько десятков мегабайт в секунду (500 Кб/ 0.01 сек = 50 Мб./сек.), и еще как-то при этом оптимизирует его. Правда, не верится.
Кроме того, непонятно какой смысл компилировать программу в момент запуска. Чушь какая то. Я хочу запустить программу, а не компилировать ее. Почему бы не скомпилировать ее разработчику? Или пусть так уж и быть она компилируется при первом запуске/установке, я не против подождать, если она действительно оптимизируется под мой процессор (опять-таки думаю МС просто лениво было бы делать все эти оптимизации в своем компиляторе).
Кроме того, подозреваю, что в то время как обычный exe файл не загружается целиком в память, а просто ммапится на область памяти, в схеме с JIT эта возможность теряется.
В общем ИМХО, байт-код и JIT — направлены не на благо пользователя, а на возможность нераскрываения исходников разработчиками.
> Поверьте, нужны. Часто их используют не только для интроспекции кода.
Даже если и нужны, наверняка можно сделать то же самое и без них, более эффективно? Ну неужели никак?
> Немного про себя. У меня средний ноутбук, я разрабатываю на нем в .net (и в линуксе под mono тоже), приложения не тормозят. Что я делаю не так? :)
Возможно, у вас другое понятие «не тормозят». Возможно, вы не спеша любите пофилософствовать пока компьютер «думает». Возможно вы не запускаете больше 1-2-3 программ одновременно. Возможно у вас 2-3 Гб памяти (и программы просто закешированы там, но только после первого запуска). Однако когда много памяти, компьютер будет долго «засыпать»/«просыпаться», а это меня не устраивает еще больше (поэтому у меня памяти мало).
У меня основные программы, плеер, редактор кода, запускаются за секунду, а если они закешированы в памяти то и быстрее. И именно столько времени они и должны запуcкаться а не больше. Смотрите: офис XP, Хром, ИЕ6 (хоть он и плохой, но стартует быстро) — все запускаются быстро, офис к тому же очень экономно относится к памяти (особенно в сравнении с опенофисом). Потому что у их разработчиков руки прямые.
А вот кривы руки у разработчиков Zend Studio (java, запускается до 30 сек.), Komodo (вроде как на XUL, тормозит страшно), FireFox3 (XUL), ну и вообще куча программ сделаны так, как будто для врага писались. Естественно, такие программы либо сносятся мной, либо сразу же запускаются как можно реже.
Еще кстати иногда я пользуюсь фотошопом, но так как он долго запускается (кривоваты руки у адоба видно), я его просто не закрываю, в свернутом состоянии он особо память не потребляет. Зато хоть при работе не тормозит.
Вообще имхо сегодня нет ни одной убедительной причины для не-сверх-сложных программ медленно запускаться или работать, на процессорах делающих миллиард операций (вдумайтесь в эту цифру!) в секунду. разве что игры — но там действительно все очень сложно, много графики, и т.д.
Я пока не видел аналогичных по ресурсам и возможностям программ на .NET или java. увижу — другое дело (но вряд ли это будет) А смотреть на сплеши — это извините возврат к временам Win95. Не для того лучшие умы улучшали 30 лет процессоры, не для того я оптимизировал винду, чтобы я ждал пока что то там запустится.
А возвращаясь к .NET Client Profile — неужели нельзя поставлять с программой только те библиотеки которые реально ей используются? Ну как dll-ки, кинул в папку с программой и не паришься. Или просто лень возиться, проще сразу все 30 мегабайт засунуть? Нафиг такой язык, на котором хелловорд весит 30 мегабайт.
Вы ей-б=гу тролль :)
>> Почему бы не скомпилировать ее разработчику?
Читайте выше про оптимизацию
>> Кроме того, подозреваю, что в то время как обычный exe файл не загружается целиком в память, а просто ммапится на область памяти, в схеме с JIT эта возможность теряется.
Эта возможность позволяла вам стартануть приложение сразу, а не ждать его загрузки; однако, в системе с размером страницы в 4кб (win32) и производительностью диска в несколько МБ (старые винты 3-5 летней давности) это перестало давать преимущество. Можете на нем не фиксироваться. Тем не менее, она не теряется — jitter работает этапами и компилирует только «горячий» код, тот, который нужен.
>> я плохо представляю компилятор, который обрабатывает код со скоростью несколько десятков мегабайт в секунду (500 Кб/ 0.01 сек = 50 Мб./сек.), и еще как-то при этом оптимизирует его
Простота абстрактной машины CLR позволяет иметь скорость достаточно оптимизированной компиляции под x86 в 10-20 МБ/с (это подтвержденные цифры библиотеки libjit, родная от МС выдает и больше). 500 кб / 10 МБ/сек = 0,05 сек. Достаточно быстро, не находите?
>> байт-код и JIT — направлены не на благо пользователя, а на возможность нераскрываения исходников разработчиками.
Здесь я вас расстрою. Байткод java и IL с легкостью превращается во вполне читаемые исходники. Так что программы в байт-коде гораздо легче реверсить, чем либы нативного с++. Вы проиграли :)
>> думаю МС просто лениво было бы
Это отличный аргумент в споре, продолжайте в том же духе :)
-+-
Вообще мы начали разговор про размер фреймворка, так что давайте завязывать спорить про производительность. В сети полно данных про сравнение компиляторов и программ — не абстрактных циклов и функций, а вполне законченных решений.
Мое мнение — на вкус и цвет фломастеры разные. Вы хотите иметь все и сразу. В жизни все доступно только через компромиссы.
P.S. Ваши посты одинаково читаются как сверху вниз, так и наоборот. Это говорит о том, что вы пишете, не думая, что вы писали раньше. Не вижу смысла спорить далее.
>> Почему бы не скомпилировать ее разработчику?
Читайте выше про оптимизацию
>> Кроме того, подозреваю, что в то время как обычный exe файл не загружается целиком в память, а просто ммапится на область памяти, в схеме с JIT эта возможность теряется.
Эта возможность позволяла вам стартануть приложение сразу, а не ждать его загрузки; однако, в системе с размером страницы в 4кб (win32) и производительностью диска в несколько МБ (старые винты 3-5 летней давности) это перестало давать преимущество. Можете на нем не фиксироваться. Тем не менее, она не теряется — jitter работает этапами и компилирует только «горячий» код, тот, который нужен.
>> я плохо представляю компилятор, который обрабатывает код со скоростью несколько десятков мегабайт в секунду (500 Кб/ 0.01 сек = 50 Мб./сек.), и еще как-то при этом оптимизирует его
Простота абстрактной машины CLR позволяет иметь скорость достаточно оптимизированной компиляции под x86 в 10-20 МБ/с (это подтвержденные цифры библиотеки libjit, родная от МС выдает и больше). 500 кб / 10 МБ/сек = 0,05 сек. Достаточно быстро, не находите?
>> байт-код и JIT — направлены не на благо пользователя, а на возможность нераскрываения исходников разработчиками.
Здесь я вас расстрою. Байткод java и IL с легкостью превращается во вполне читаемые исходники. Так что программы в байт-коде гораздо легче реверсить, чем либы нативного с++. Вы проиграли :)
>> думаю МС просто лениво было бы
Это отличный аргумент в споре, продолжайте в том же духе :)
-+-
Вообще мы начали разговор про размер фреймворка, так что давайте завязывать спорить про производительность. В сети полно данных про сравнение компиляторов и программ — не абстрактных циклов и функций, а вполне законченных решений.
Мое мнение — на вкус и цвет фломастеры разные. Вы хотите иметь все и сразу. В жизни все доступно только через компромиссы.
P.S. Ваши посты одинаково читаются как сверху вниз, так и наоборот. Это говорит о том, что вы пишете, не думая, что вы писали раньше. Не вижу смысла спорить далее.
UFO just landed and posted this here
Зачем мне писать что-то? Сам ты школьник. Посмотри на то что написалим другие: Total Commander, Foobar2000 — вот тщательно написанные программы. Ты можешь такое же на своем дотнете написать? Сомневаюсь.
.NET — сегодня годится только на сервер.
Кстати в твоем комментарии, кроме общих слов типа «бредни» ничего нету — наверно потому что просто сказать нечего по теме.
.NET — сегодня годится только на сервер.
Кстати в твоем комментарии, кроме общих слов типа «бредни» ничего нету — наверно потому что просто сказать нечего по теме.
В своё время я видел софтину которая позволяла заменять/отцеплять вызовы .Net платформы. Вобщем принцип работы не помню, но она позволяла избавитсья от необходимости поставки .Net платформы вместе с продуктом. Вроде — Salamander .NET Linker and Mini-Deployment Tool. Только она платная.
Xenocode. но стоит она порядочно, и ключиков мне найти не удалось. но есть evaluation.
Sign up to leave a comment.
.NET Framework Client Profile