Цитата:
Андре
Быстродействие ? Это Вы про .Net ??? Поставьте себе какое-нибудь .Net приложение и понаблюдайте за его работой. За тем как хапает память и не думет ее возвращать garbage collector. Это не баг - это идеология там такая - память освобождается в тот момент,когда ее не осталось
Такое ощущение, что мы немножко недопоняли друг друга. Вы похоже говорите о Windows-приложениях я о Web-приложениях. Я думаю, что для мощного Web-сервера при большом количестве активных подключений дополнительные метры памяти будут не очень заметны (нужно будет подгрузить aspnet_wp.exe). Зато код больше не будет интерпретироваться как раньше.
В чем еще преимущество ASP.Net. Он постоянно висит в виде Web-сервиса и не открывается заново при каждом новом подключении. При этом dll с функциями висит в памяти, они не интерпретируются всякий раз.
Да согласен на слабом Web-сервере .Net приложение выполняется очень медленно, но на мощным серверах оно очень быстро, именно поэтому эта технология так широко сейчас распространена на Западе.
У нас же популярен PHP по двум причинам:
1. Он прост в освоении.
2. Не требует мощных серверов.
Но зато он очень медленный т.к. скриптовый и => требует высокой пропускной способности канала.
Цитата:
Андре
А вы не задумывались над тем, что скриптовые языки больше подходят для web-программирования.
Вопросом на вопрос: А вы на них писали? Я лучше напишу на C# код, компильну его в dll и функции будут вызываться из этой бибилиотеке. Чем они будут интерпретироваться всякий раз. Да кстати это еще одно причина более высокого быстродействия.
Цитата:
Андре
Но web интерфейс всегда менее удобен для пользователя, нежели GUI и никогда не станет основным интерфейсом ввода данных.
Он является менее удобным как раз по причине недостаточного количестива визуальных компонентов. И кроме того он просто незаменим для отдаленных пользователей (а это в современном мире становится все чаще и чаще). Как раз проблему с компонентами решает ASP.Net
Цитата:
http://localhost/quickstart/aspplus/ Introduce Web Forms
ASP.NET ships with 45 built-in server controls that can be used out of the box (for details, see Web Forms Controls Reference). In addition to using the built-in ASP.NET controls, developers also can use controls developed by third-party vendors.
The following sample shows a simple calendar control. The Calendar control is declared within the page using an <acme:calendar runat=server> tag. Note that the <% Register %> directive at the top of the page is responsible for registering the "Acme" XML tag prefix with the "Acme" code namespace of the control implementation. The ASP.NET page parser will then utilize this namespace to load the Calendar control class instance at run time.
The Calendar control in this sample has been designed to perform "uplevel-like" processing on Internet Explorer 5.5 or higher and "downlevel" processing on all other browsers. This browser sniffing is nowhere near as complex as that provided by the ASP.NET built-in server controls. For Internet Explorer 5.5 or higher browsers it generates DHTML output. This DHTML output does not require round trips back to the server when doing day selections and month navigations. For all other browsers the control generates standard HTML 3.2. This HTML 3.2 does require round trips back to the server to handle client-side user interactions.
Important: The code that a page developer writes is identical regardless of whether an "uplevel" or "downlevel" browser is used to access the page. The Calendar control itself encapsulates all of the logic required to handle the two scenarios.
Таким образом Web-приложения уже ни в чем не уступают обычным GUI.
Цитата:
Давно присутствует в таком скриптовом языке, как Perl.
С просто ужасной реализацией.
PHP и Perl не особо удобны для программирования.
Просто посмотрите на их синтаксис.