Перейти к содержимому

Фото
- - - - -

[.NET] рассуждения


  • Вы не можете создать новую тему
  • Please log in to reply
20 ответов в этой теме

#1 Доктор Зло

Доктор Зло
  • Пользователь
  • 847 сообщений

Отправлено 01 августа 2004 - 14:53

В IT индустрии наблюдается интересная цикличность. Средства и платформы разработки меняются раз в семь-восемь лет. Не так давно пришла Java. Приход сопровождался криками о том, что скоро весь код в мире будет на ней переписан. Теперь пришел .NET и C#. Нет никаких сомнений в том, что эта платформа завоюет большую долю рынка, но в чем причины ее появления?

Порассуждаем вместе об этом
:)
  • 0

#2 Denis

Denis
  • Пользователь
  • 405 сообщений

Отправлено 19 августа 2004 - 22:43

Ява - красивый язык, но мертво рожденный, скорости выполнения кода не устраивает не 1 серьезного заказчика, нет не у кого желания сидеть в кресле и плевать в потолок, пока твое приложение обработает запрос ;)
время деньги ;)
  • 0

#3 Sergio

Sergio
  • Постоялец
  • 3 051 сообщений

Отправлено 19 августа 2004 - 23:10

Ява - красивый язык, но мертво рожденный, скорости выполнения кода не устраивает не 1 серьезного заказчика, нет не у кого желания сидеть в кресле и плевать в потолок, пока твое приложение обработает запрос ;)
время деньги ;)

Просмотреть сообщение

Верно. Но скорость не всегда критична. И использование явы или даже интерпретируемых языков (хотя яву пожалуй тоже можно к ним отнести) часто оправдано.
  • 0

#4 archi

archi
  • Пользователь
  • 84 сообщений
  • Откуда:Таллин

Отправлено 20 августа 2004 - 00:42

Ява - красивый язык, но мертво рожденный, скорости выполнения кода не устраивает не 1 серьезного заказчика, нет не у кого желания сидеть в кресле и плевать в потолок, пока твое приложение обработает запрос ;)
время деньги ;)

Просмотреть сообщение

неправильно... скорость и качество разработки - тоже деньги... я знаю очень серьезные проекты, написанные на Java, которые устраивают СЕРЬЕЗНЫХ заказчиков...
  • 0

#5 tomatensaft

tomatensaft

    Samurai Jack

  • Пользователь
  • 449 сообщений
  • Откуда:Tallinn

Отправлено 20 августа 2004 - 02:02

Все, думаю, знают серьезные фирмы, которые эту Java широко используют -- Sun, IBM, Oracle...

Производительность Java вполне устраивает заказчиков, у которых есть деньги на покупку харда чуть ли не любой конфигурации... :) Java работает довольно-таки шустро на мощном железе...

Да и успех языков Perl, PHP, Python говорит о том, что сверхпроизводительность приложений не так уж важна (при сравнительно низкой стоимости вычислительной мощи) -- сейчас важнее скорость разработки, на которую уходит львиная доля затрат в ИТ интдустрии, AFAIK. Или скажем так -- важен идеальный баланс между скростью работы и скоростью разработки.
  • 0
"This is all I want'd t' say 'bout dat..." © Forest Gump

#6 Zeppelin

Zeppelin

    Китайский Чай

  • Пользователь
  • 210 сообщений
  • Откуда:Таллин

Отправлено 20 августа 2004 - 20:48

но мертво рожденный


Denis, Специально для тебя цитата:

Further, if you are going to compare programming languages, please note "Nebbe's rule":

If you can't think of a least one area where a language is better than your preferred language then you probably aren't competent to comment on it.


скорости выполнения кода не устраивает не 1 серьезного заказчика


И не надо судить о чем либо наслушавшись дешевой (анти-)рекламы. А тем более кричать о том, о чем *сам* не имеешь понятия. Язык Java уже очень давно не имеет проблем с производительностью. Она вполне сопоставима с аналогичными программами, скажем, на С++. На некоторых задачах немного ниже, на некоторых даже немного выше. В обоих случаях она не настолько существенна, чтобы волновать заказчика.
  • 0
Лучший чай из Китая, провожу чайные церемонии, обращайтесь!

#7 úlfurinn

úlfurinn

    забавная зверушка

  • Пользователь
  • 178 сообщений

Отправлено 21 августа 2004 - 19:10

но в чем причины ее появления?

В том, что Java придумали не в Microsoft, конечно же :)
  • 0
Насильник и убийца, положительный персонаж.

#8 Sergio

Sergio
  • Постоялец
  • 3 051 сообщений

Отправлено 21 августа 2004 - 23:33

Язык Java уже очень давно не имеет проблем с производительностью. Она вполне сопоставима с аналогичными программами, скажем, на С++. На некоторых задачах немного ниже, на некоторых даже немного выше. В обоих случаях она не настолько существенна, чтобы волновать заказчика.

Просмотреть сообщение

Вот тут ты пожалуй переборщил. До c++ довольно далеко по скорости, причем практически во всех задачах.
  • 0

#9 archi

archi
  • Пользователь
  • 84 сообщений
  • Откуда:Таллин

Отправлено 22 августа 2004 - 00:49

Вот тут ты пожалуй переборщил. До c++ довольно далеко по скорости, причем практически во всех задачах.

Просмотреть сообщение

ты не совсем прав... в старом форуме была очень хорошая ссылка, там было сравнение скорости выполнения различного кода на C++, Java и C#.NET...
была примерно та же ситуация что и Intel vs. AMD, ATI vs. nVidia... кто-то где-то сделал кого-то, кто-то лучше для чего-то... но говорить, что что-то быстрее чего-то - в корне не верно... все уже давно работает примерно одинаково... 10% скорости туда-сюда для разных задач... Ява проигрывает в операциях по работе с памятью, из-за мусорщика, но сколько сил это экономит программистам - ты просто не представляешь... поэтому, когда стоит вопрос, увеличить ли время разработки программы в 2 раза и заплатить группе программистов из 10 человек за все это время или просто купить сервер с процессором в полтора раза мощнее - обычно выбирают мощный сервер...
уже не говоря про стоимость поддержки...
и потом, споры C++ vs. Java напоминают Assembler vs. C++... в итоге все пришли к выводу, что на ассемблере программы чуток побыстрее получаются, но писать на нем - удавиться можно... Я не говорю, что писать на C++ - удавиться... но Java - посовременнее и поприятнее...
А я вообще C# люблю...
  • 0

#10 tomatensaft

tomatensaft

    Samurai Jack

  • Пользователь
  • 449 сообщений
  • Откуда:Tallinn

Отправлено 22 августа 2004 - 11:18

Развитие ситуации с долей рынка зависит от многого. В первую очередь, от политики развития стандартных библиотек и виртуальных машин этих двух языков (C# и Java).

Если Java будет открыта, реализация стандартного JIT-компилятора или возможности компилировать нативный машинный код, если требуется, думаю, не составит труда. То же касается и нативного графического интерфейса для библиотеки GUI (считается одним из недостатков Java). Движение в этом направлении уже видно (в IBM, например, этим занимаются).

С++ никуда не уйдет. Потеряет долю на рынке -- вполне определенно, но не более того (I.M.H.O.).
  • 0
"This is all I want'd t' say 'bout dat..." © Forest Gump

#11 Sergio

Sergio
  • Постоялец
  • 3 051 сообщений

Отправлено 22 августа 2004 - 22:56

ты не совсем прав...

Просмотреть сообщение

Я ничего против явы не имею. Как и против любого другого языка. И знаю, что время программистов обходится дороже машинного времени. Но просто на сегодняшний день ява медленнее c++(я говорю о скорости выполнения программы и только). Сам часто пользуюсь программами написанными на яве (напр. azureus).
  • 0

#12 Zeppelin

Zeppelin

    Китайский Чай

  • Пользователь
  • 210 сообщений
  • Откуда:Таллин

Отправлено 23 августа 2004 - 00:02

Но просто на сегодняшний день ява медленнее c++.

Ты как минимум отстал от прогресса на несколько лет. Советую ознакомиться с бенчмарками современных JVM в сравнении с аналогичными бенчмарками C++.

Сам часто пользуюсь программами написанными на яве (напр. azureus).

Просмотреть сообщение

Тормознутость тех программ, что ты используешь, говорит только о качестве работы программистов при написании этих конкретных программ. Неважно, на чем они написаны.

PS. Как уже было отмечено ранее, разница в производительности Java и C++ складывается, в основном, из различий в работе с памятью (сборка мусора vs явное освобождение памяти). В зависимости от количества, размера и времени жизни объектов может выигрывать либо один, либо другой метод. В простейшем приближении, явное освобождение памяти отлично работает при малом количестве больших и долгоживущих объектов, тогда как *современный* сборщик мусора показывает лучшие сравнительные результаты для большого количества маленьких короткоживущих объектов.
  • 0
Лучший чай из Китая, провожу чайные церемонии, обращайтесь!

#13 tomatensaft

tomatensaft

    Samurai Jack

  • Пользователь
  • 449 сообщений
  • Откуда:Tallinn

Отправлено 23 августа 2004 - 10:31

PS. Как уже было отмечено ранее, разница в производительности Java и C++ складывается, в основном, из различий в работе с памятью (сборка мусора vs явное освобождение памяти). В зависимости от количества, размера и времени жизни объектов может выигрывать либо один, либо другой метод. В простейшем приближении, явное освобождение памяти отлично работает при малом количестве больших и долгоживущих объектов, тогда как *современный* сборщик мусора показывает лучшие сравнительные результаты для большого количества маленьких короткоживущих объектов.

Просмотреть сообщение


И это при том, что объекты GUI как раз довольно большие и, в основном, долгоживущие...
  • 0
"This is all I want'd t' say 'bout dat..." © Forest Gump

#14 archi

archi
  • Пользователь
  • 84 сообщений
  • Откуда:Таллин

Отправлено 23 августа 2004 - 11:24

И это при том, что объекты GUI как раз довольно большие и, в основном, долгоживущие...

Просмотреть сообщение

думаешь? мне как-раз кажется наоборот - много мелких объектов... каждая кнопочка, каждый лэйбл, а внутри них стринги и разные другие мемберы, типа фонта или иконки, а потом еще рамки окна, скролбары, статус-панель, а у статус-панели - несколько статус-баров... а у каждого статусбара те же самые стринги и иконки с фонтами...
насчет долгой жизни - это уж как юзер прикажет 8)
  • 0

#15 tomatensaft

tomatensaft

    Samurai Jack

  • Пользователь
  • 449 сообщений
  • Откуда:Tallinn

Отправлено 24 августа 2004 - 17:30

думаешь? мне как-раз кажется наоборот - много мелких объектов... каждая кнопочка, каждый лэйбл, а внутри них стринги и разные другие мемберы, типа фонта или иконки, а потом еще рамки окна, скролбары, статус-панель, а у статус-панели - несколько статус-баров... а у каждого статусбара те же самые стринги и иконки с фонтами...
насчет долгой жизни - это уж как юзер прикажет 8)

Просмотреть сообщение


А теперь взгляни на класс основного фрейма или основного класса приложения (входной точки приложения GUI) -- все панели, кнопки, меню и другие его элементы обычно являются его членами... Так что, учитывая количество этих элементов и их подэлементов, по крайней мере, панели и фреймы являются довольно крупными и сложными объектами в объектно-ориентированных программах GUI...

Безусловно, все зависит от программиста, реализующего программу (можно создавать диалоги прямо перед их показом и использованием, а можно создавать каждый из них один раз и использовать их много раз на протяжении работы программы). Однако, я не представляю как сделать основную рабочую панель какой-нибудь программы-клиента локальной внутри какого-нибудь метода. Обычно такая штука реализуется членом основного фрейма, а значит, живет покуда живет сам фрейм, то есть *обычно* в течение всей работы программы.

Короче, вот, о чем я говорю (на простеньком С++, чтоб понятно было):

class MyFrame : public wxFrame {
  wxButton button; // Lives until MyFrame is destructed
public:
  MyFrame() : wxFrame() { 
     button.Create(/* Some args */);
  }

};

class MyApp : public wxApp {

   MyFrame frame; // Lives until MyApp is destructed (on app exit)

 public: 

   void OnInit(){
      frame.Create(/* here go some arguments */);
      frame.Show();
   }
};

Сообщение изменено: tomatensaft (24 августа 2004 - 17:45 )

  • 0
"This is all I want'd t' say 'bout dat..." © Forest Gump

#16 archi

archi
  • Пользователь
  • 84 сообщений
  • Откуда:Таллин

Отправлено 24 августа 2004 - 18:38

так как ты написал - выглядит только очень простой UI, совершенно не динамический, типа диалога сообщения об ошибке... код настоящего UI, такого как Word или Excel, выглядит совершенно иначе... Так что твой пример совершенно не из этой жизни... может так и писали 20 лет назад... но сейчас так писать не получится...
А вот так это выглядит в реальной программе на C#... практически точно так же он выглядит на Java с использованием AWT или SWT...

	public class FormMain : System.Windows.Forms.Form
	{
    private System.Windows.Forms.MainMenu mainMenu;
    private System.Windows.Forms.MenuItem menuItemFile;
    private System.Windows.Forms.MenuItem menuItemExit;
    private System.Windows.Forms.MenuItem menuItemOptions;
    private System.Windows.Forms.StatusBar statusBar;
    public System.Windows.Forms.StatusBarPanel statusBarPanelCount;
    private System.Windows.Forms.MenuItem menuItemViews;
    private System.Windows.Forms.MenuItem menuItemBooksView;
    private WeifenLuo.WinFormsUI.DockManager dockManager;
    private System.Windows.Forms.MenuItem menuItemLibraryView;
    private System.Windows.Forms.MenuItem menuItemProperties;
    private System.Windows.Forms.MenuItem menuItemLibrary;
    private System.Windows.Forms.MenuItem menuItemDatabaseScan;
    private System.Windows.Forms.MenuItem menuItemLibrarySettings;
    private System.Windows.Forms.MenuItem menuItemFolderView;
    private System.Windows.Forms.MenuItem menuItemHelp;
    private System.Windows.Forms.MenuItem menuItemAbout;
.
}
      this.mainMenu = new System.Windows.Forms.MainMenu();
      this.menuItemFile = new System.Windows.Forms.MenuItem();
      this.menuItemOptions = new System.Windows.Forms.MenuItem();
      this.menuItemExit = new System.Windows.Forms.MenuItem();
      this.menuItemViews = new System.Windows.Forms.MenuItem();
      this.menuItemFolderView = new System.Windows.Forms.MenuItem();
      this.menuItemBooksView = new System.Windows.Forms.MenuItem();
      this.menuItemLibraryView = new System.Windows.Forms.MenuItem();
      this.menuItemProperties = new System.Windows.Forms.MenuItem();
      this.menuItemLibrary = new System.Windows.Forms.MenuItem();
      this.menuItemDatabaseScan = new System.Windows.Forms.MenuItem();
      this.menuItemLibrarySettings = new System.Windows.Forms.MenuItem();
      this.menuItemHelp = new System.Windows.Forms.MenuItem();
      this.menuItemAbout = new System.Windows.Forms.MenuItem();
      this.statusBar = new System.Windows.Forms.StatusBar();
      this.statusBarPanelCount = new System.Windows.Forms.StatusBarPanel();
      this.dockManager = new WeifenLuo.WinFormsUI.DockManager();
...
this.menuItemFolderView.Click += new System.EventHandler(this.menuItemFileView_Click);
this.menuItemBooksView.Click += new System.EventHandler(this.menuItemBooksView_Click);
...
      this.AutoScaleBaseSize = new System.Drawing.Size(5, 13);
      this.ClientSize = new System.Drawing.Size(760, 513);
... и так далее, там еще раз в 10 больше...

Сообщение изменено: archi (24 августа 2004 - 19:04 )

  • 0

#17 tomatensaft

tomatensaft

    Samurai Jack

  • Пользователь
  • 449 сообщений
  • Откуда:Tallinn

Отправлено 24 августа 2004 - 23:09

так как ты написал - выглядит только очень простой UI, совершенно не динамический, типа диалога сообщения об ошибке... код настоящего UI, такого как Word или Excel, выглядит совершенно иначе... Так что твой пример совершенно не из этой жизни... может так и писали 20 лет назад... но сейчас так писать не получится...
А вот так это выглядит в реальной программе на C#... практически точно так же он выглядит на Java с использованием AWT или SWT...


Может, я не понял, но какая принципиальная разница между твоим примером и моим? В количестве элементов? Целью-то было не это... Да и не показывает ли твой пример то, что класс FormMain является большим и "долгоживущим" (точнее, таковыми будут его объекты)? Я говорил именно о таких классах, говоря о классах GUI (уточним: пользовательских классах)...

Ты поспешил с определением моего кода-примера как простого и примитивного... Я специально его таким сделал. :) Целью было показать наглядно, что элементы основного окна приложения "живут" на протяжении всего времени работы программы и иначе это не делается (это просто неудобно, IMHO).

Вот после этого и кажется мне, что говорим мы на разных языках... :( И отчасти поэтому получается, что все перерастает обычно в банальный спор "кто правее"...

Сообщение изменено: tomatensaft (24 августа 2004 - 23:19 )

  • 0
"This is all I want'd t' say 'bout dat..." © Forest Gump

#18 archi

archi
  • Пользователь
  • 84 сообщений
  • Откуда:Таллин

Отправлено 24 августа 2004 - 23:55

Может, я не понял, но какая принципиальная разница между твоим примером и моим? В количестве элементов? Целью-то было не это... Да и не показывает ли твой пример то, что класс FormMain является большим и "долгоживущим" (точнее, таковыми будут его объекты)? Я говорил именно о таких классах, говоря о классах GUI (уточним: пользовательских классах)...

Ты поспешил с определением моего кода-примера как простого и примитивного... Я специально его таким сделал. :) Целью было показать наглядно, что элементы основного окна приложения "живут" на протяжении всего времени работы программы и иначе это не делается (это просто неудобно, IMHO).

Вот после этого и кажется мне, что говорим мы на разных языках... :( И отчасти поэтому получается, что все перерастает обычно в банальный спор "кто правее"...

Просмотреть сообщение

просто ты сказал, что объектов UI мало и они большие... а я сказал, что объектов очень много и они маленькие... время жизни я не оспаривал, потому как оно зависит от пользователя и программиста (который, как правило, не склонен создавать все возможные диалоги при старте, а создает их по мере надобности, а потом разрушает, как и многие другие объекты), но это не важно, на самом деле... потому как для мусорщика имеет значение не время жизни, а количество... А FormMain не является большим... это малюсенький классец, который просто служит контейнером для сотни других объектов, создаваемых независимо от контейнера, в котором хранятся лишь указатели на них...
а насчет разных языков - может быть... у нас опыт разный... ты иногда ошибаешься в очевидных вещах или приводишь какие-то гипотетические примеры, которые хороши, чтобы иллюстрировать какую-то абстрактную концепцию, но совершенно неприменимы к реальной жизни... а я даже и объяснить толком не могу, ведь для меня многие вещи являются самими собой разумеющимися... в чем-то и я могу запросто ошибаться, поскольку специализируюсь несколько в иной отрасли...
я часто сталкиваюсь с такими вещами и вижу разницу, говоря с людьми, которые программируют 10 лет и теми, которые только-только институт закончили... первые понимают все на ходу, вторым приходится объяснять аксиомы, как надо делать, как принято и почему некоторые вещи просто не стоит делать...
это не в обиду, серьезно... просто констатация факта...
опять же, я предлагаю обдумать тебе свое видение предмета текущей дискуссии... Ты склонен видеть все как конгломерат некоторого количества объектов, по твоему мнению являющимся одним большим объектом... логически оно может и так... но физически это - муравейник, состоящий из большого количества мелких объектов, объединенных одной лишь идеей и больше ничем...
второе, что я хотел добавить, говоря о большом количестве объектов, пусть даже и входящих в состав другого в качестве его мемберов, я подразумевал как само собой разумеещееся, что именно количество этих объектов аффектит производительность, а вовсе не время их жизни... поэтому время жизни я особо и не затрагивал, как не относящийся к делу параметр...
  • 0

#19 Zeppelin

Zeppelin

    Китайский Чай

  • Пользователь
  • 210 сообщений
  • Откуда:Таллин

Отправлено 25 августа 2004 - 00:46

Ребят, вы не о том спорите. Я же сказал, что критерий _приблизительный_. А вариант с GUI вообще разговор отдельный. Там дело даже не в GC, потому как объект интерфейса - это не ресурс памяти, и тут начинают играть совсем другие законы, это раз. Во вторых те Java объекты, которые являются врапперами для объектов OS - собственно те, о которых GC знает - их настолько мало по сравнению с остальными объектами программы, и они настолько долго живут, что с успехом попадают в старое поколение, где спокойно себе отлёживаются никому не мешая. А вот в обработчиках событий обычно и создается то множество крохотных объектов, крайне недолго живущих (абсолютное большинство умирает еще до окончания обработки события).

Действительно, AWT/Swing имеют проблемы. И одна из них именно производительность. Но причина этому совсем другая. Не секрет, что SUN хотел скорее выпустить Java в свет, и первая версия AWT была сделана студентами университета (не помню уже какого) за несколько недель. Естественно, они не имели того опыта, который требовался для выполнения данной задачи, а времени у них было еще меньше. В отличие скажем от IBM (а точнее OTI), создавших SWT. Который, кстати, тоже не идеален, но уже в другом плане - недостает в нем 2D рендеринга.
  • 0
Лучший чай из Китая, провожу чайные церемонии, обращайтесь!

#20 dronius

dronius
  • Пользователь
  • 153 сообщений

Отправлено 15 октября 2004 - 15:02

Joel on Software. Please May I Have A Linker.

Пожалуйста, сэр, могу ли я получить компоновщик? Уже не столь актуально, но немалая доля здравого смысла тут есть :)
Грубо говоря, "динамическое линкование" - беда всех языков вырабатывающих "неродной" код.

Автор: Джоэл Сполски
Переводчик: Анар Мустафаев
28 января 2004


По неизвестной причине, превосходная и супер современная среда разработки .NET компании Microsoft пропустила один их ключевых инструментов… инструмент который был обычным делом в средах разработки программного обеспечения с, ну, примерно 1950 года, и настолько очевидным, что кажется невероятно странным, что никто не обратил внимание на тот факт, что в .NET, на самом деле, его нет.



О каком инструменте идет речь? О компоновщике (linker). Вот что он делает: собирает откомпилированную версию вашей программы с откомпилированными версиями библиотечных функций, которые ваша программа использует. Затем, он удаляет те библиотечные функции, которые ваша программа не использует. И в конце концов, компоновщик создает один бинарный выполняемый файл, который люди могут запустить на своих компьютерах.



Вместо этого, в .NET реализована идея «среды времени выполнения» (runtime)… большая, 22 мегабайтная, парообразная куча кода, которая динамически компонуется и которую каждый обязан записать на свой компьютер перед тем как использовать .NET приложения.



Среды выполнения - это проблема очень похожая на проблему с DLL, потому что если приложение 1 было разработано для среды выполнения 1, и выходит среда выполнения версии 2, то, внезапно, по какой-то непредсказуемой причине приложение 1 перестает правильно работать. Например, сейчас, после обновления среды выполнения с версии 1.0 до 1.1, наша внутренняя корпоративная контрольная панель округляет количество продаж до четвертого десятичного знака. А обычно несовместимости бывают еще хуже.



Фактически .NET включает в себя обширную технологическую систему называемую «явности» (manifests), которые явно сложны и задуманы для того чтобы каким-то образом только правильная среда выполнения могла быть использована с данным приложением, но я не знаю никого, кто может разгадать как их использовать.



Все это требует рассказать одну историю. На вечеринке в Fog Creek, в канун Нового Года, мы хотели чтобы в главной комнате несколько компьютеров показывали обратный отсчет времени до полуночи. Майкл написал приложение на C# с WinForms за 60 секунд. Это отличная среда разработки.



Моя работа заключалось в том что бы записать программу countdown.exe на три компьютера и запустить ее. Это звучит просто.



Как бы ни так. Двойной щелчок на EXE и я получаю смешное недружелюбное сообщение об ошибке где-то в mscoree.dll или что-то такое, с неуместным дампом моего пути. Естественно, нет сомнения в том что среда выполнения .NET просто не была проинсталированна. К счастью я программист и сразу определил в чем проблема.



Как я инсталлирую среду выполнения? “Простейший” путь через Windows Update. Но Windows Update сначала заставляет меня проинсталлировать все критические обновления, а только потом среду выполнения. Это, разумно, да? Два из “критических” обновлений – это Windows service pack и новая версия Internet Explorer, и оба требуют перезагрузить компьютер.



Как я уже говорил, для запуска этого маленького .NET приложения мне нужно загрузить 70 или 80 мегабайт (хорошо, что у нас скоростной доступ в Интернет) и перезагрузиться три или четыре раза. И это в софтверной компании! Я знаю как долго это длится, потому что когда загрузка началась в первый раз, я включил «Office Space» на большом экране, и к тому времени когда фильм закончился, инсталляция почти завершилась. Каждые десять минут во время просмотра фильма я должен был вскакивать, бежать к компьютеру, чтобы нажать ОК в каком-нибудь дурацком диалоговом окне.



Этого достаточно чтобы вызвать разочарование от использования доморощенных программ. Но подумайте о нашем продукте CityDesk. Практически все наши пользователи загружают бесплатную пробную версию перед тем как купить этот продукт. Им надо загрузить около 9 Мб и не предъявляется никаких дополнительных требований. И, практически, пока никто их этих пользователей не имеет среды выполнения .NET.



А если мы попросим пользователей из небольших организаций и домашних пользователей, сначала пройти через весь ад инсталляции среды выполнения длительностью с целый фильм, то, я думаю, мы потерям 95% из них. Они пока не клиенты, они потенциальные клиенты, и я не могу позволить себе отказаться от 95% моих потенциальных клиентов только ради использования более удобной среды разработки.



“Но, Джоэл”, могут мне сказать, “это же ясно, что скоро у достаточного количества пользователей будет эта среда выполнения и тогда проблема исчезнет.”



Я тоже так думал, а потом обнаружил что Microsoft поставляет новую версию среды выполнения каждые шесть или двенадцать месяцев. Понемногу увеличивающееся количество людей имеющих ее опять падает до нуля. И будь я проклят, если я буду тестировать мое приложение на трех различных версиях среды выполнения только для того чтобы получить прирост клиентов на 1,2% на одну из трех версий.



Я просто хочу все скомпоновать в один статический EXE файл, который для запуска не предъявляет никаких особых требований. Мне не важно, что он несколько больше. Все что мне было бы необходимо - это функции которые я действительно использую, интерпретатор байт кода и немного от среды выполнения. Мне не нужен целый компилятор C# который является частью среды выполнения. Я уверяю что код CityDesk не нуждается в компиляции какого-то ни было программного кода на C#. Мне не нужны целых 22 МБайт. Самое большее что мне нужно это 5 или 6 МБайт.



Я знаю компании, которые обладают технологией сделать это, но им нужно разрешение от Microsoft чтобы распространять части среды выполнения, такие как интерпретатор байт-кода. Эй, Microsoft, проснись, дай нам замечательный кусочек технологий 1950-х годов, и позволь мне сделать один EXE файл, который запускается на любом компьютере с ОС Win 98 или более поздней без всяких дополнительных требований. Но нет, .NET фатально не дружелюбна к пользователю, который скачивает софт.
  • 0

#21 archi

archi
  • Пользователь
  • 84 сообщений
  • Откуда:Таллин

Отправлено 16 октября 2004 - 00:29

В этих своих высказываниях Джоэл прав, если рассматривать эту проблему с точки зрения отдельного программиста, имеющего маленькую фирмочку и зарабатывающего себе масло на хлеб. Но он совершенно не прав, если посмотреть на это как на индустрию.
Правда в том, что очень трудно придумать что-то на десятилетия, особенно в таком динамичном мире, как IT-технологии... вчера всем нужно было просто рисовать окошки, сегодня - связывать сотни компьютеров. Вчера была эра HTML, сегодня - PHP и Flash. Microsoft (и другие фирмы) выпускают продукты, которые нужны сегодня. Не вчера и не завтра, а сегодня. Потому что никому не нужно то, что было вчера... Все только догадываются, что миру нужно будет завтра. Наиболее простой путь - инкрементальное развитие того, что было вчера в то, что нужно сегодня, закладывая фундамент в наше видение завтра.
Вчера был один EXE файл, во времена DOS - был один COM-файл... почему Джоэл не хочет, чтобы все было как позавчера, когда все было на трех перфокартах?
Он слегка динозавр... у него есть налаженый бизнес и он боится новых идей. Он не хочет платить за прогресс.
Потому что использование новейших технологий и плата за переход на них - это и есть плата за прогресс. Microsoft инкрементально увеличило возможности своей среды разработки, не сделав при это никакого особенного скачка в будущее, они просто сделали то, что нужно людям сейчас и будет нужно в ближайшие пару лет.
Если мы будем использовать то, что они сделали, это даст им возможность увидеть слабые и сильные стороны текущей имплементации, чтобы сделать следующую более хорошей... и так до бесконечности... и без нас эта бесконечность и светлое будущее не получится...
То, чего боится Джоэл - это просто плата за прогресс. Он динозавр, нашедший свой уголок с деревом и он не хочет пойти в лес... потому что боится, что не дойдет и потерят свое дерево.
Так выпьем же за тех, кто не боится "идти с лес", изобретать и пробовать новое, делать сегодня и заглядывать в будущее, а не делать вчера и смотреть в позавчера.
Самое смешное во всей этой статье - это неустановленный сервис пак и критические обновления... Way To Go, Joel! А почему бы ему не поставить себе Windows 3.11 for Workgroups?
  • 0