
![]() |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[216.73.216.76] |
![]() |
|
Страницы: (15) « Первая ... 6 7 [8] 9 10 ... 14 15 все ( Перейти к последнему сообщению ) |
Сообщ.
#106
,
|
|
|
Цитата Гость Andr,2.08.04, 08:44 Ну, во первых библиотека классов (FCL) .NET очень и очень богата (более 7000 классов!) - богаче, чем WinAPI, VCL, etc. вместе взятые. Так что ищущий да найдет. Я не говорю о 100%-х аналогах - платформы-то принципиально разные - относятся к различным поколениям. Ищущий найдет в FCL средства решения всех возникающих при программировании задач. вот именно это и есть полное дерьмо, в которое мы должны вляпаться. 7000 классов. Я представляю сколько там ошибок! Кому-нибудь надо 7000 классов? Опять же система расчитанная на гипотетический худший случай |
Сообщ.
#107
,
|
|
|
Цитата 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 и впихнуть туда как можно больше спецэффектов, если же заниматься серьёзными программами для бизнеса, а не утилитами, то применение третьесторонних библиотек, классов, уже готовых решений и т.п. насущная необходимость, а не блаж |
Сообщ.
#108
,
|
|
|
to Vit
Цитата Мне платят деньги за написанные программы, если есть класс который реализует нужную функциональность то мне выгоднее потратить 2 минуты на его включение в код, чем 2 дня писать самому. Несомненно! H.Iglesias II вот именно это и есть полное дерьмо, в которое мы должны вляпаться. 7000 классов. Я представляю сколько там ошибок! Кому-нибудь надо 7000 классов? Vit правильно считает, что сторонние компоненты нужны... И гораздо логичнее, если эти компоннеты имеют единую структуру, идеологию. Это .NET! Гораздо хуже, когда мы имеем WinAPI, надстройку VCl над WinAPI, сетевые компоненты в Delphi сторонние (Indy) и множество других библиотек, несовместымых между собой и имеющих разную идеологию! Общее количество классов там будет тоже 7000. Вот где ошибок, как говна! Уж лучше единая библиотека .NET, имеющая единую идеологию. А если будут ошибки там... Библитека классов .NET - это еще не среда выполнения. Ошибки в библитеке легче исправлять, если она единая, бабай! |
Сообщ.
#109
,
|
|
|
Цитата Гость Andr,2.08.04, 18:20 to Vit Цитата Мне платят деньги за написанные программы, если есть класс который реализует нужную функциональность то мне выгоднее потратить 2 минуты на его включение в код, чем 2 дня писать самому. Несомненно! не надо передергивать. Я совсем не то имел в виду. Я не призываю писать библиотеки самому. Я не вижу смысла в том универсализме, который мне обещают. |
Сообщ.
#110
,
|
|
|
Цитата H.Iglesias II, 2.08.04, 14:05 Я не вижу смысла в том универсализме, который мне обещают. Смысл есть... Например VCL высвобождает огромное количество времени при разработки приложений, вместо рисования кнопок можно сосредоточится на алгоритме... Ничего плохого в том что подобная библиотека сделана на системном уровне не вижу, хотя реализация мне и не очень нравится. Ещё этот универсализм позволит выполнять один и тот же исполняемый файл и в Win и в Lin и в Mac и на больших машинах, тоже ничего плохого в этом нет... Да для написания системных утилит и драйверов такая библиотека на фиг не нужна, но 95% программирования это не утилиты и драйвера, а клиент-серверные приложения для баз данных и разработка Web приложений и сервисов, и как раз их написание при использовании .net облегчается |
Сообщ.
#111
,
|
|
|
Я вижу, что насчет .NET каждый остается пока при своем мнении.
Подведем резюме: 1. Тема о Delphi 8 for .NET свелась к обсуждению .NET. 2. Из этого следует одно из преимуществ .NET - независимость разрабатываемых программ от среды разработки. И это правильно! 3. D8 нужна для: 3.1. поддержки старых проектов; 3.2. создания новых разработчиками, которые не хотят переучиваться на новый язык; 3.3. для использования в новых проектах Borland'овских разработок (ECO, BDP.NET, ETM, etc.) Модераторам: наверное, пора закрывать тему... |
Сообщ.
#112
,
|
|
|
Значит так, "СТРАШНО" ужаснувшись что "WinAPI умрет" начал изучать это самое .Net ...
Впечатление не очень хочу сказать. Там действительно ( в книге ) говориться, что тепереь С программисты и VB программисты смогут объединиться не переучиваясь писать совместные проекты благодаря... Ну мы отвлеклись. Насчет структуры языка и вообще чтот можно при программировании использовать было сказано следующее: (основной упор давался на VB, т. к. там такого раньше не было) появились стуктуры (по паскалевски - записи), перечисления и прочее... Смотрю и думаю, действительно VB программистам (коим я сам был 4 года назад) придется подзадуматься над этой самой структурой языка, НО В DELPHI, а точнее в Паскале все это было уже давным давно, все эти клссы, с наследованием, полиморфизмом и инкапсуляцией, и т. д. и т. п. В общем из этой области я ничего нового не узнал. Поехали далее: простанство имен. Вот эти самые 7000 классов и с одной стороны попугивают чутка. Хотя многое из них (если не всё) есть в WinAPI. Получается, что это просто старый пирог, завернутый в новую оболочку. И какой из этого + ??? Другая сторона медали. Я понимаю, что теперь я могу например с С прогаммером писать один проект... Может быть и плюс... Но вот быстродействие, как уже было сказано выше, не ухти. В общем мое сугубо личное, ни кого никуда не втаптывающее, мнение таково: на каком языке писали, на том и продолжайте писать. Действительно WinAPI не умрет, а эти новые технологии .Net еще надо подумать новые ли они... Про D8 я временно забываю, возвращаясь к D7... Всем удачи!!! |
Сообщ.
#113
,
|
|
|
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, что это самая лучшая настройка (это действительно так)... В Мелкософте подумали над этим и фактически создали платформу разработки и выполнения программ, не требующую надстройки от сторонних производителей. На мой взгляд, в это нет ничего прохого, наоборот, это хорошо! |
Сообщ.
#114
,
|
|
|
Цитата Гость Andr, 4.08.04, 21:39 Цитата перегрузка операторов (!); Возможно + даже большой! Хотя Паскаль такой как он есть такового не видывал, хотя если это надо бы было для него это могло появиться еще с незапямятных времен, т. к. в с++, это есть стандард, ну так чего ж тогда этого не было раньше!? - строной С попахивает Цитата записи со свойствами и методами (!); И на кой ... они появились, чем теперь Record отличается от Object и Class? ---------------- То что .Net объектно-ориентированная - немного радует, поддержка Exception - вроде тоже, но все же изучать заново, то что уже есть... |
Сообщ.
#115
,
|
|
|
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 в ближайшие годы станет основной платформой разработки и выполнения ПО. |
Сообщ.
#116
,
|
|
|
Цитата Если я буду писать сам то получится быстрее? компактнее? - несомненно, но современные системы не требуют быстродействия! Основные задержки времени - это ожидание выполнения запроса в базе данных, ожидание ответа от удалённых серверов, лимиты сетевого трафика и т.д. Я тестировал свою систему, получилось что ~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, так что ничего нового здесь нет. Короче, как сказали выше, Макдональдс сплошной. Просто ещё одна большая библиотека. |
Сообщ.
#117
,
|
|
|
to Sanek
Цитата какая разница, как развивался язык? Непонятно, чем С# логичнее Delphi. Что такого в C# очень стройного и логичного? Если посмотреть с другой стороны - так это на самом деле урезанный С++ Чтобы с исчерпывающей ответить на эти вопросы, не хватить места здесь. Надо научную статью писать. Почитай лучше литературу и другие источники (лучше побольше - для возможности сравнивать). Замечу только, что C# - это не урезанный C++. По синтаксису C# на 60% - C++, на 35% - Java, на 5% - Pascal. Но это синтаксис. Важна же структура языка. И с этой точки зрения C# - новый язык, строектированый с учетом всего опыта и свободный от негативного груза обратной совместимости. Цитата Во-первых, WinAPI развивалось не по принципу латания дыр, а по принципу добавления новых возможностей в систему. Добавление новых возможностей - это само собой... WinAPI проектировалась не очень структурированно и без учета того, что возможно, будет добавлено в нее после. В итоге в результате развития слишком много ерунды в угоду обратной совместимости (как и в Delphi language, кстати). Цитата Во-вторых, "с нуля" библиотеку проектировать просто не могли, так как опирается она на тот же WinAPI, что заметно по присутствию классов-оберток системных объектов. .NET проектировали с нуля в архитектурном плане. .NET предусматривает реализацию не только под Windows, а во многих системах. Поэтому мнения, что .NET - ООП-обертка для WinAPI - безосновательны. |
Сообщ.
#118
,
|
|
|
Цитата Гость Andr @ 10.08.04, 12:44 to Sanek Цитата .NET предусматривает реализацию не только под Windows, а во многих системах. В каких ? |
Сообщ.
#119
,
|
|
|
to andrey_pst
Цитата Цитата В каких?NET предусматривает реализацию не только под Windows, а во многих системах. Например, уже есть .NET под Linux - mono называется. А вообще реализовать ее можно под любой системой, которая это позволяет реализовать спецификации .NET. В будущем MS на целена на выпуск Pure .NET-операционок. Вообще MS планировала открыть полную спецификацию на .NET после окончательной доработки и передать все права широкой общественности. Не знаю произошло ли это уже. Скорее всего это произойдет после выхода .NET 2.0. |
Сообщ.
#120
,
|
|
|
ссылку на "mono" можете дать ?
|