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

Цитата Гость Andr,2.08.04, 08:44

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

вот именно это и есть полное дерьмо, в которое мы должны вляпаться. 7000 классов. Я представляю сколько там ошибок!
Кому-нибудь надо 7000 классов? Опять же система расчитанная на гипотетический худший случай

Цитата

H.Iglesias II, 2.08.04, 07:46
вот именно это и есть полное дерьмо, в которое мы должны вляпаться. 7000 классов. Я представляю сколько там ошибок!
Кому-нибудь надо 7000 классов?

Помнится был у меня калькулятор Б3-21 - 30 комманд, 4 регистра, стек на 6 комманд и память в 64 полубайт... И никаких ошибок! И на фиг нужны эти новомодные навороты начиная с Z80 с офигенным количеством регистров и комманд...

Да, надо! Мне платят деньги за написанные программы, если есть класс который реализует нужную функциональность то мне выгоднее потратить 2 минуты на его включение в код, чем 2 дня писать самому. Если я буду писать сам то получится быстрее? компактнее? - несомненно, но современные системы не требуют быстродействия! Основные задержки времени - это ожидание выполнения запроса в базе данных, ожидание ответа от удалённых серверов, лимиты сетевого трафика и т.д. Я тестировал свою систему, получилось что ~50% времени тратится на SQL запросы, ~50% времени тратится на ожидание трансфера данных с удалённых (в других городах и странах) серверов, только 1% времени тратится на выполнение моих сотен тысяч строк кода... На фиг мне его оптимизировать, ну перепишу я всё на ассемблере, потрачу не один год и получу выигрыш в быстродействии в пол процента? Добавление нужного индекса к таблице или небольшое кэширование запросов может дать сразу выигрышь в 10%-20%... А вот если будут готовые классы для реализации той или иной функциональности, то я готов их применять в ущерб быстродействию дабы увеличить скоторость разработки, читабельность кода и т.п. "Кому это надо" говорят обычно люди которые считают высшим пилотажем программирования написать бесполезную демку в 64K и впихнуть туда как можно больше спецэффектов, если же заниматься серьёзными программами для бизнеса, а не утилитами, то применение третьесторонних библиотек, классов, уже готовых решений и т.п. насущная необходимость, а не блаж

Сообщение отредактировано: Vit - 02.08.04, 14:33

to Vit

Цитата

Мне платят деньги за написанные программы, если есть класс который реализует нужную функциональность то мне выгоднее потратить 2 минуты на его включение в код, чем 2 дня писать самому.

Несомненно!

H.Iglesias II
вот именно это и есть полное дерьмо, в которое мы должны вляпаться. 7000 классов. Я представляю сколько там ошибок!
Кому-нибудь надо 7000 классов?
Vit правильно считает, что сторонние компоненты нужны...
И гораздо логичнее, если эти компоннеты имеют единую структуру, идеологию. Это .NET!
Гораздо хуже, когда мы имеем WinAPI, надстройку VCl над WinAPI, сетевые компоненты в Delphi сторонние (Indy) и множество других библиотек, несовместымых между собой и имеющих разную идеологию! Общее количество классов там будет тоже 7000. Вот где ошибок, как говна!
Уж лучше единая библиотека .NET, имеющая единую идеологию.
А если будут ошибки там... Библитека классов .NET - это еще не среда выполнения. Ошибки в библитеке легче исправлять, если она единая, бабай!

Цитата Гость Andr,2.08.04, 18:20

to Vit

Цитата

Мне платят деньги за написанные программы, если есть класс который реализует нужную функциональность то мне выгоднее потратить 2 минуты на его включение в код, чем 2 дня писать самому.

Несомненно!

не надо передергивать. Я совсем не то имел в виду. Я не призываю писать библиотеки самому.

Я не вижу смысла в том универсализме, который мне обещают.

Цитата

H.Iglesias II, 2.08.04, 14:05
Я не вижу смысла в том универсализме, который мне обещают.

Смысл есть... Например VCL высвобождает огромное количество времени при разработки приложений, вместо рисования кнопок можно сосредоточится на алгоритме... Ничего плохого в том что подобная библиотека сделана на системном уровне не вижу, хотя реализация мне и не очень нравится. Ещё этот универсализм позволит выполнять один и тот же исполняемый файл и в Win и в Lin и в Mac и на больших машинах, тоже ничего плохого в этом нет... Да для написания системных утилит и драйверов такая библиотека на фиг не нужна, но 95% программирования это не утилиты и драйвера, а клиент-серверные приложения для баз данных и разработка Web приложений и сервисов, и как раз их написание при использовании .net облегчается

Я вижу, что насчет .NET каждый остается пока при своем мнении.

Подведем резюме:

1. Тема о Delphi 8 for .NET свелась к обсуждению .NET.

2. Из этого следует одно из преимуществ .NET - независимость разрабатываемых программ от среды разработки. И это правильно!

3. D8 нужна для:
3.1. поддержки старых проектов;
3.2. создания новых разработчиками, которые не хотят переучиваться на новый язык;
3.3. для использования в новых проектах Borland'овских разработок (ECO, BDP.NET, ETM, etc.)

Модераторам: наверное, пора закрывать тему...

Значит так, "СТРАШНО" ужаснувшись что "WinAPI умрет" начал изучать это самое .Net ...
Впечатление не очень хочу сказать. Там действительно ( в книге ) говориться, что тепереь С программисты и VB программисты смогут объединиться не переучиваясь писать совместные проекты благодаря... Ну мы отвлеклись. Насчет структуры языка и вообще чтот можно при программировании использовать было сказано следующее: (основной упор давался на VB, т. к. там такого раньше не было) появились стуктуры (по паскалевски - записи), перечисления и прочее... Смотрю и думаю, действительно VB программистам (коим я сам был 4 года назад) придется подзадуматься над этой самой структурой языка, НО В DELPHI, а точнее в Паскале все это было уже давным давно, все эти клссы, с наследованием, полиморфизмом и инкапсуляцией, и т. д. и т. п. В общем из этой области я ничего нового не узнал. Поехали далее: простанство имен. Вот эти самые 7000 классов и с одной стороны попугивают чутка. Хотя многое из них (если не всё) есть в WinAPI. Получается, что это просто старый пирог, завернутый в новую оболочку. И какой из этого + ???
Другая сторона медали. Я понимаю, что теперь я могу например с С прогаммером писать один проект... Может быть и плюс... Но вот быстродействие, как уже было сказано выше, не ухти.
В общем мое сугубо личное, ни кого никуда не втаптывающее, мнение таково:

на каком языке писали, на том и продолжайте писать. Действительно WinAPI не умрет, а эти новые технологии .Net еще надо подумать новые ли они...
Про D8 я временно забываю, возвращаясь к D7...
Всем удачи!!!

SPrograMMer

Хотелось бы пополемизировать по поводу последнего поста.

Понятно, что и раньше было в природе ООП, записи и т.д.
Дело не в этом, а в том, что в существующие языки эти прогрессивные штуки вписывались с теченеим времени, зачастую нарушая логику языка.
А в C# все это объединено очень и очень логично и стройно.

Цитата

на каком языке писали, на том и продолжайте писать.

в Delphi 8, например, в соответствиями CRL поянвились такие штуки, как:
- перегрузка операторов (!);
- записи со свойствами и методами (!);
- секции strict private и strict protected в классах (традиционные секции private и protected в Object Pascal не соответствуют принципам ООП в том смысле, что доступ к их элементам может получат кто угодно, находящийся в том же модуле);
- многое другое.

Вывод: на мой взгляд, лучше изучать спроектированный с учетом всего опыта программирования новый язык C#, чем изучать все нововведения в Delphi language, VB, etc...

Цитата

Поехали далее: простанство имен. Вот эти самые 7000 классов и с одной стороны попугивают чутка.

Понятие пространства имен - это одно (модульность), а 7000 классов - это другое (библиотека типов платформы).

Цитата

Хотя многое из них (если не всё) есть в WinAPI. Получается, что это просто старый пирог, завернутый в новую оболочку. И какой из этого + ???

+ в том, что библиотека типов (FCL) в отличие от WinAPI, развивавшейся по принципу латания дыр, спроектирована с нуля, с учетом накопившегося опыта. И она объекно-ориетированная.
И еще: в платформу включено понятие исключительных ситуаций (exception).

Теперь не будет неестественных ситуаций, когда, программируя на Delphi, надо обрабатывать exception при использовании VCL, и обрабатывать код ошибки при использовании API-функций.

Цитата

а эти новые технологии .Net еще надо подумать новые ли они...

Действительно, стоит подумать... Что такое Delphi 2-7? Не совсем естественная объекно-ориентированная (в том числе визуальная) надстройка над уродливой WinAPI.
Этим-то и прославилась Delphi, что это самая лучшая настройка (это действительно так)...
В Мелкософте подумали над этим и фактически создали платформу разработки и выполнения программ, не требующую надстройки от сторонних производителей.
На мой взгляд, в это нет ничего прохого, наоборот, это хорошо!

Цитата

Гость Andr, 4.08.04, 21:39

Цитата

перегрузка операторов (!);

Возможно + даже большой! Хотя Паскаль такой как он есть такового не видывал, хотя если это надо бы было для него это могло появиться еще с незапямятных времен, т. к. в с++, это есть стандард, ну так чего ж тогда этого не было раньше!? - строной С попахивает

Цитата

записи со свойствами и методами (!);

И на кой ... они появились, чем теперь Record отличается от Object и Class?
----------------
То что .Net объектно-ориентированная - немного радует, поддержка Exception - вроде тоже, но все же изучать заново, то что уже есть...

To SPrograMMer

Цитата

Цитата

записи со свойствами и методами (!);

И на кой ... они появились, чем теперь Record отличается от Object и Class?

Паскаль, как и большинство языков программирования претерпевал изменения, добавление новых возможностей, и т.д.

И сейчас то же самое, только в случае с D8 нововведения надо рассматиривать не с точки зрения необходимости добавить что-либо в Паскаль, а с точки зрения приведения Паскаля к требованиям общеязыковой исполняющей среды .NET.

В .NET все данные - объекты (в качестве первоначального предка выступает System.Object). По крупному все типы объектов делятся на 3 группы:
1. Фундаментальные типы данных (целые и вещественные числа, булевы переменые, строки и т.д.). Они определены в пространстве имен System разработчиками .NET.
2. Классы. Тут все понятно - ООП в классическом виде.
3. Если есть необходимость иметь "статический" объект без необходимости наследования, можно использовать структуры (struct и record в терминологиях C-подобных языков и Pascal соответственно). Так у структур (записей) появились свойства, методы, секции private и public.

И все это очень логично... если использовать специально разработанный под это дело язык C#. Или VB.NET (это на самом деле не Basic и даже не VB, а урезанный C# с синтаксисом VB).

В случае с Delphi действительно возникает много вопросов из-за неестественного объединения идеологий Delphi и .NET в одном флаконе.
Из этого следует:
1. Если планируется писать программы под .NET, то сначала надо изучать .NET, и только потом - конкретные среды разработки и языки программирования.
2.

Цитата

D8 нужна для:
- поддержки старых проектов;
- создания новых разработчиками, которые не хотят переучиваться на новый язык (но, как видим, переучиваться придется!);
- для использования в новых проектах Borland'овских разработок (ECO, BDP.NET, ETM, etc.)

Другое дело, насколько перспективна сама .NET. На мой взгляд, есть основания считать, что .NET в ближайшие годы станет основной платформой разработки и выполнения ПО.

Цитата

Если я буду писать сам то получится быстрее? компактнее? - несомненно, но современные системы не требуют быстродействия! Основные задержки времени - это ожидание выполнения запроса в базе данных, ожидание ответа от удалённых серверов, лимиты сетевого трафика и т.д. Я тестировал свою систему, получилось что ~50% времени тратится на SQL запросы, ~50% времени тратится на ожидание трансфера данных с удалённых (в других городах и странах) серверов, только 1% времени тратится на выполнение моих сотен тысяч строк кода...

Несомненно в этом случае на быстродействие надо обращать мало внимания. А ты не задумывался, что за теми 50% тоже прячется код, от которого как раз требуется быстродействие и пренебрегать этим не стоит. Как говориться, по задаче свой инструмент.

2 Гость Andr: какая разница, как развивался язык? Непонятно, чем С# логичнее Delphi. Что такого в C# очень стройного и логичного? Если посмотреть с другой стороны - так это на самом деле урезанный С++)

Кстати, я порылся в библиотеке, и нашел порт завершения i/o: System.Threading.ThreadPool.
Вот функция:

 
public static bool BindHandle(
   IntPtr osHandle
);

Цитата

osHandle - An IntPtr that holds the handle. The handle must have been opened for overlapped I/O on the unmanaged side.

Что бы это значило: "must have been opened on the unmanaged side"? И где нам создавать этот хэндл?

Цитата

+ в том, что библиотека типов (FCL) в отличие от WinAPI, развивавшейся по принципу латания дыр, спроектирована с нуля, с учетом накопившегося опыта. И она объекно-ориетированная.
И еще: в платформу включено понятие исключительных ситуаций (exception).

Во-первых, WinAPI развивалось не по принципу латания дыр, а по принципу добавления новых возможностей в систему. И ЛЮБАЯ система будет так развиваться (если вообще будет). Пройдет время, добавятся новые классы в FCL. И что, библиотека станет хуже? Во-вторых, "с нуля" библиотеку проектировать просто не могли, так как опирается она на тот же WinAPI, что заметно по присутствию классов-оберток системных объектов. В-третьих, исключения в Windows существуют давно. SEH, по-моему, был в Windows 95, так что ничего нового здесь нет.
Короче, как сказали выше, Макдональдс сплошной. Просто ещё одна большая библиотека.

to Sanek

Цитата

какая разница, как развивался язык? Непонятно, чем С# логичнее Delphi. Что такого в C# очень стройного и логичного? Если посмотреть с другой стороны - так это на самом деле урезанный С++

Чтобы с исчерпывающей ответить на эти вопросы, не хватить места здесь. Надо научную статью писать. Почитай лучше литературу и другие источники (лучше побольше - для возможности сравнивать).
Замечу только, что C# - это не урезанный C++. По синтаксису C# на 60% - C++, на 35% - Java, на 5% - Pascal.
Но это синтаксис. Важна же структура языка. И с этой точки зрения C# - новый язык, строектированый с учетом всего опыта и свободный от негативного груза обратной совместимости.

Цитата

Во-первых, WinAPI развивалось не по принципу латания дыр, а по принципу добавления новых возможностей в систему.

Добавление новых возможностей - это само собой...
WinAPI проектировалась не очень структурированно и без учета того, что возможно, будет добавлено в нее после.
В итоге в результате развития слишком много ерунды в угоду обратной совместимости (как и в Delphi language, кстати).

Цитата

Во-вторых, "с нуля" библиотеку проектировать просто не могли, так как опирается она на тот же WinAPI, что заметно по присутствию классов-оберток системных объектов.

.NET проектировали с нуля в архитектурном плане. .NET предусматривает реализацию не только под Windows, а во многих системах.
Поэтому мнения, что .NET - ООП-обертка для WinAPI - безосновательны.

Цитата Гость Andr @ 10.08.04, 12:44

to Sanek

Цитата

.NET предусматривает реализацию не только под Windows, а во многих системах.

В каких ?

to andrey_pst

Цитата

Цитата

NET предусматривает реализацию не только под Windows, а во многих системах.

В каких?

Например, уже есть .NET под Linux - mono называется. А вообще реализовать ее можно под любой системой, которая это позволяет реализовать спецификации .NET.

В будущем MS на целена на выпуск Pure .NET-операционок.

Вообще MS планировала открыть полную спецификацию на .NET после окончательной доработки и передать все права широкой общественности. Не знаю произошло ли это уже. Скорее всего это произойдет после выхода .NET 2.0.

ссылку на "mono" можете дать ?