Delphi 8 - Первые впечатления , Шаг вперёд - два шага назад?

Гость Andr

Ну, если система ещё будет в реалтайме компилировать код перед его вызовом...
Это будет компиляция наспех и без должной оптимизации. К тому же сам язык IL вряд ли поможет процессу оптимизации, т.к. дополнительно наложит свои ограничения. Наверное, Вы слышали, что в новых 64-битных Интеловских процессорах, (которые вот-вот должны заменить современные 32-битные) вся работа по ускорению обработки потока инструкций снята с железа (процессора, то есть) и целиком возложена на компилятор. Я думаю, Вы не будете оспаривать факт, что классический вариант (с исходника Delphi-программы в инструкции процессора при значительном запасе времени на компиляцию) даст заметно более быстрый код, нежели компиляция в реалтайме (изначально имея исходник, искажённый синтаксисом IL, да ещё с добавлением времени компиляции к времени исполнения кода).

А насчёт C++, Asm и машинных кодов - Вы в корне не правы.
Во-первых, всё равно на чём из перечисленного программировать - всё равно программа сводится к вызовам WinAPI-функций, а язык исходника - дело вкуса и удобства.
Во-вторых, Delphi(version <= 7), например, никак не ограничивает возможности программирования на ассемблере. Хочешь - пиши хоть всю программу внутри оператора asm..end. Правда, реально прибегать к ассемблеру есть смысл лишь при написании "узких мест" (обычно - написание своих элементарных графических операций или процедур работы с большими числами). И машинные коды тоже приходилось применять (помню, Delphi 3 неправильно кодировал инструкцию cmpxchg для 32-битных аргументов).

to CD_Eater

Цитата

Ну, если система ещё будет в реалтайме компилировать код перед его вызовом...
Это будет компиляция наспех и без должной оптимизации. К тому же сам язык IL вряд ли поможет процессу оптимизации, т.к. дополнительно наложит свои ограничения.

Это не так. Смысл как раз в том, чтобы каждый метод перед его первым вызовом компилировать один раз, и компилировать именно в оптимальнейший код для конкрентного процессора.
Не берусь утверждать, что на данный момент это все так хорошо релизовано. Но если разработчики .NET задумали такую схему, значит на то были основания.

Цитата

А насчёт C++, Asm и машинных кодов - Вы в корне не правы.
Во-первых, всё равно на чём из перечисленного программировать - всё равно программа сводится к вызовам WinAPI-функций, а язык исходника - дело вкуса и удобства.

Видимо, Вы не поняли меня. Я хотел сказать, что .NET - это следущая ступень эволюции программирования на лестнице "машинные коды->ассебблер->структурные языки высокого уровня->объектно-ориентированные языки высокого уровня".
Если же мы пишем на ассебблере, то вызывать функции WinAPI мы уж никак не будем (какой смысл вызывать с помощью асм-ра функции, написанные на структурном языке C?). А вот прерывания вызывать - будем. И это будет быстрее, чем C+WinAPI.
Но это ж не повод отказываться от С+WinAPI!
Поэтому логично предположить, что только ради экономии ресурсов не стоит отказываться от .NET в пользую устаревшей платформы WinAPI.

P.S. IL-язык особых ограничений не наложит - в нем не более 30 типичных ассемблерных иснтрукций. Такой код как раз проще оптимизировать под конкрентный процессор.
Кстати, когда мы компилируем модуль в D<=7, то ведь он сначала компилится в промежуточный объекный код (думается, что он весьма похож на IL), и только потом - в x86.

А эти бесконечные Warnings: Unit 'Borland.Vcl.Forms' is specific to a platform...
Ну понимаю я что Borland.Vcl.Forms специфична... Но если надо! разрабатывать приложения VCL так что ж мне постоянно в Uses`ах писать

 
{$WARNINGS OFF}
uses ...;
{$WARNINGS ON}?

И тот пример со стороками от Aleksandr`а...

И есчо много чего непонятного на первый взглад, особенно в файле .dpr, когда все "+" раскрутить на "-"...

Да и вообще платформа .net - диковинный, на мой взгляд, зверь, который еще покажет свои острые коготки, когда начнешь её изучать...

to SPrograMMer
VCL. NET создана только для того, чтобы в среду .NET можно было переносить созданные ранее приложения.
А новые приложения надо создавать на базе чистой .NET и, Windows Forms для GUI-приложений, в частности.

И не будет никаких specific to platform...

to SPrograMMer
P.S.
Попробуй {$WARN UNIT_PLATFORM OFF}
А юзать без надобности VCL.NET не надо - она построена, как и прежде на чистом WinAPI.
Это уже не настоящее .NET-приложение, когда вся его библиотека, в том числе и визуальная, постронена на WinAPI...

Delphi, где твои крылья, которые так нравились мне...

В своё время Borland сделала невозможное. Она создала приятную и удобную оболочку для WinAPI. VCL. Она была куда удобней в использовании и надстройке, чем MFC.

Теперь на смену WinAPI пришла .NET. Хотя пришла ли? Спорный вопрос. Не знаю, чем .NET удобней, чем та жа WinAPI+VCL и почему надо ей пользоватся. Меня лично в этом надо ещё убедить.

Но в любом случае D8 ничего нового в .NET не привнесла. И зачем она тогда нужна --- непонятно. RIP. Хотя я думаю надо подождать D9. Как-то так повелось, что нечётные версии у них гораздо приятней и удобней. А на чётных я вообще ничего серъёзного писать не мог.

По поводу .NET. Года три назад к нам в университет приходил Дон Бокс читать лекцию ко концепции .NET. Мне тогда с одной стороны, конечно, понравилось, с другой стороны я понял, что .NET --- одно большое шоу. Это КРАСИВО и ничего больше. На той лекции он всё скакал и сравнивал концепцию .NET с концепцией фильма "Матрица". И у меня сложилось впечатление, что вся .NET спроектирована по мотивам и как дань уважения этому фильму (это не так конечно, но что-то в этом было), чего стоят одни только названия, GarbageCollector там и т.п. Кстати, он тогда недвусмысленно намекнул, что VB --- для дураков, а настоящие индейцы пишут на C#, C++ в крайнем случае.

Так вот, среди всего, что он обещал было быстродействие, которое достигалось как раз JIT-компилятором с MSIL'а. И когда я поработал на VS.NET я понял какая это брехня. Да и всю эту .NET туда же:
Сначала о железе:
Мой AXP-1700+ c 512 метрами памяти за секунду решает довольно сложные м/задачи: может построить интерполяцию куб. сплайнами по 1000 контрольных точек. По крайней мере в секунду это точно укладывается. Проверено. Винчестер за две-три минуты перекидывает фильм с одного своего куска на другой.
Так вот:
Почему, когда я в VS.NET добавляю, например, новую форму в проект, у меня это происходит в течении двух секунд. Что этот мегаоптимизированный-под-мой-процессор код делает?

To BackSlash

Цитата

Delphi, где твои крылья, которые так нравились мне...
В своё время Borland сделала невозможное. Она создала приятную и удобную оболочку для WinAPI. VCL. Она была куда удобней в использовании и надстройке, чем MFC

Да, Дельфи прославилась тем, что сделала самую удобную оболочку для WinAPI.

Цитата

Но в любом случае D8 ничего нового в .NET не привнесла.

И не могла привнести ничего - по определению самой платформы .NET.
D8 нужна только для поддержки старых Delphi-проектов (VCL.NET) и для создания новых теми разработчиками, которые не хотят переучиваться на C#. Правда, они не понимают, что переучиваться все равно придется - т.к. Object Pascal 8 изменен в соответствии с требованиями общеязыковой исполняюшей среды...
Так что уж лучше последовать примеру крутых перцев и программировать на C#.

Цитата

По поводу .NET. Года три назад к нам в университет приходил Дон Бокс читать лекцию ко концепции .NET. Мне тогда с одной стороны, конечно, понравилось, с другой стороны я понял, что .NET --- одно большое шоу.

Ну презентации-лекции у MS всегда попсовые...
Если есть желание действительно изучить .NET и понять, чем же она круче связки WinAPI+VCL, советую почитать следующие книги:
1. Рихтер Дж. Программирование на платформе Microsoft .NET Framework (2-е издание). – «Русская Редакция», 2003. – 512 с.
2. Просиз Дж. Прогрраммирования для платформы .NET . - "Русская редакция", 2003. - 700 с.

P.S. Если напрягает, что в исполняемых .NET-файлах получается промежуточный код, можно скомпилировать их в машинный утилитой NGen.exe из состава .NET Framework SDK (!).

А кто выигрывает при таком развитии событий?

Новая технология!
Завтрашний день!

Кому это нужно?

Не надо сравнивать переход DOS = Win с этой таксказать борьбой WinAPI-.Net

В первом случае- это всетаки шаг вперед, а во втором замена одного другим, причину которой на мой взгляд никто толком не знает. Главная причина, вроде, "Win32Api стал старый и скоро умрет" поэтомы Вы должны купить новую ОС и новый компьютер. Я не могу, МакДональдс какой-то...

Сообщение отредактировано: H.Iglesias II - 28.07.04, 14:44

Цитата Гость Andr @ 28.07.04, 19:32

D8 нужна только для поддержки старых Delphi-проектов (VCL.NET) и для создания новых теми разработчиками, которые не хотят переучиваться на C#. Правда, они не понимают, что переучиваться все равно придется - т.к. Object Pascal 8 изменен в соответствии с требованиями общеязыковой исполняюшей среды...
Так что уж лучше последовать примеру крутых перцев и программировать на C#.

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

to andrey_pst
Действительно, одно из преимуществ .NET - то, что общая языковая среда (CRL) выдвигает требования к структуре языка, а не к синтаксису, и тогда модули одной и той же программы модно писать на разных языках, и эти модули наконец-то смогут общаться объектно-ориентированно без посредников в лице COM+. То же самое касается и общения различным программ между собой.

Но: C# изначально спроектирован под CRL, а также учитывает всесь негативный и положительный опыт развития остальных языков программирования. Поэтому он концептуально строен.
А другие языки (Delphi, C++, VB, etc.) были изменены в соотвествии с требованиями CRL, а все негативное наследение, связанное с обеспечением обратной совместимости, в них осталось.

Поэтому, на мой взгляд, под .NET оптимальнее программировать на C#.

to H.Iglesias II

Цитата

Не надо сравнивать переход DOS => Win с этой так сказать борьбой WinAPI-.Net
В первом случае - это все-таки шаг вперед, а во втором замена одного другим, причину которой на мой взгляд никто толком не знает.

Переход DOS => Win шагом вперед считают потому, что это очевидно - радикально изменился пользовательский интерфейс.

При переходе WinAPI => .NET принцип организации пользовательского интерфейса остался прежним, но этот переход еще бОльший шаг вперед, т.к. теперь радикально изменена в лучшую сторону внутренняя струтура среды выполнения (аналог ОС) и программного обеспечения.

Цитата

а во втором замена одного другим, причину которой на мой взгляд никто толком не знает

Повторюсь: читайте литературу и документацию, прежде чем делать скоропалительные выводы.

Цитата Гость Andr @ 29.07.04, 11:59

При переходе WinAPI => .NET принцип организации пользовательского интерфейса остался прежним, но этот переход еще бОльший шаг вперед, т.к. теперь радикально изменена в лучшую сторону внутренняя струтура среды выполнения (аналог ОС) и программного обеспечения.

Цитата

а во втором замена одного другим, причину которой на мой взгляд никто толком не знает

Повторюсь: читайте литературу и документацию, прежде чем делать скоропалительные выводы.

Вот это и напрягает.

Программы разве работают плохо, чтобы им выполняться лучше?

Что значит ЛУЧШЕ? Фильмы можно будет смотреть быстрее? Больше расходовать ресурсов будут?

Зачем программы должны теперь исполняться в аналоге ОС, а не ОС?

Согласен, что кому-то из разработчиков это очень даже и клево, здесь даже упоминались конкретно, но большинство кроме геморра очередного не получат ничего. Крупные воротилы от IT срубят бабки,





А ПРОГРАММЫ К СО-ЖА-ЛЕ-НИ-Ю СТАНУТ ХУУУУУУЖЕ!!!!!!!!!!!!!



Я, наверно, ламер в этом вопросе. НО.
А докумментацию пишут по .NET кто?
А продвигает NET кто?
А продает NET кто?
Или ШТО?

Совершенно понятно, что в документации меня будут убеждать, что ЭТО просто СУПЕР-ПУПЕР.

Кто-нибудь в докумментации по MFC встречал описание неправильности этой библиотеки?

Согласен.
Всё это нужно только что бы срубить побольше бабок с конечных пользователей.
Ресурсов всё будет требовать больше --- факт.
Скорость работы не увеличится, ибо никакой JITCer не знает лучше меня как оптимизировать мою программу под конкретный процессор, а при переводе на MSIL теряется куча информации для этого необходимой (имхо).

Кому-то от этого будет лучше, но не мне.
Сложные программы связанные со сложной оптимизацией всё-равно будут кусками писаться на ассемблере, как это делается и сейчас.

Программировать на .NET надо уметь. Правильно это делать --- сложно. Зато будет полно всяких умников, которые будут считать, что это они делать умеют. => программы действительно станут хуже.

Сообщение отредактировано: BackSlash - 29.07.04, 11:33

Странно слышать заявления типа "WinAPI умрет".
Скажите мне аналог функции WinAPI CreateIoCompletionPort на Net или вообще аналог порта. Или ReadFileEx.
Или AllocateUserPhysicalPages

Моё мнение, где место Net. В России очень распространен продукт 1С Предприятие. Посмотришь на него и задумываешься, зачем он вообще нужен. Вот Net как раз и будет заменять такие продукты. Может быть.

P.S По идее WinAPI должно было умереть, когда изобрели визуальную среду программирования. Сколько лет прошло?

Да и вообще как WinAPI может умереть? Без WinAPI не будет Windows. В WIndows XP/Server 2003 включено приличное количество ноых функций. ЗАявления типа "WinAPI умрет" бессмыслены.

Сообщение отредактировано: Sanek - 31.07.04, 18:35

to H.Iglesias II

Цитата

Я, наверно, ламер в этом вопросе. НО.
А докумментацию пишут по .NET кто?
А продвигает NET кто?
А продает NET кто?
Или ШТО?

Беседуя таким образом, мы можем зациклиться на чистых эмоциях. И ни WinAPI, ни .NET здесь уже будут ни при чем...

to BackSlash

Цитата

Скорость работы не увеличится, ибо никакой JITCer не знает лучше меня как оптимизировать мою программу под конкретный процессор, а при переводе на MSIL теряется куча информации для этого необходимой (имхо).

По этому поводу я опять же советую почитать официальную документацию и хорошие книги по этой теме. Утверждается, что, наоборот, это должно повысить производительность. Хотя на практике это бывает не всегда.
Ну, а если не убедил, то повторюсь (опять зацикливаемся!):

Цитата

to BackSlash
P.S. Если напрягает, что в исполняемых .NET-файлах получается промежуточный код, можно скомпилировать их в машинный утилитой NGen.exe из состава .NET Framework SDK (!)

Цитата

Программировать на .NET надо уметь. Правильно это делать --- сложно. Зато будет полно всяких умников, которые будут считать, что это они делать умеют. => программы действительно станут хуже.

Под какую бы платформу ни программировать, действительно, это надо уметь. Сейчас есть много умников, которы считают, что они умеют программировать под Windows (в частности, полно умников, которые умеют кидать кнопки на формы - и считают, что больше ничего не надо).
Под Windows программировать сложно.
А .NET создан для того, чтобы облегчить программирование! Писать под него программы проще. Но, конечно, придется перед этим напрячься - почитать новые книги, документацию... Ничего совсем уж лего не бывает!

to Sanek

Цитата

Скажите мне аналог функции WinAPI CreateIoCompletionPort на Net или вообще аналог порта. Или ReadFileEx.
Или AllocateUserPhysicalPages

Ну, во первых библиотека классов (FCL) .NET очень и очень богата (более 7000 классов!) - богаче, чем WinAPI, VCL, etc. вместе взятые.
Так что ищущий да найдет. Я не говорю о 100%-х аналогах - платформы-то принципиально разные - относятся к различным поколениям.
Ищущий найдет в FCL средства решения всех возникающих при программировании задач.

Цитата

По идее WinAPI должно было умереть, когда изобрели визуальную среду программирования. Сколько лет прошло?

Визуальное программирование-то изобрели, но оно было не очень естественной надстройкой над WinAPI (VCl, MFC).
Теперь (.NET) визуальное программирование является неотъемлемой частью платформы, и это правильно!:))

Цитата

Моё мнение, где место Net. В России очень распространен продукт 1С Предприятие. Посмотришь на него и задумываешься, зачем он вообще нужен. Вот Net как раз и будет заменять такие продукты. Может быть.

Ну, 1С вообще-то нужен, как и любые другие ERP-системы, для управления предприятием...Другое дело, что такие продукты (как и большинство остальных) лучше делать на .NET'е...