Second Life, Second Chance for CodeGear

← →
oxffff © (2007-07-27 20:48) [0]

http://reddevnews.com/features/article.aspx?editorialsid=749

← →
Sdubaruhnul (2007-07-27 21:05) [1]

Ничего нового. Мечты... Мечты...

← →
Суслик © (2007-07-27 23:45) [2]

посмотрим, что с Д2008 будет.
может быть последний их шанс.

← →
Nic © (2007-07-28 00:35) [3]

Бегло проглядел. Полностью читать лень. Суббота-раннее-утро, как-никак :)
На самом деле Delphi находится в точке бифуркации, от качества новых версий зависит буквально всё. Не секрет, Delphi 8 и Delphi 2005 очень нестабильны. Не видел никого, кто бы разрабатывал что-то серьёзное на этих версиях Delphi. Хотя мазохисты наверняка есть, но их, скорее всего, меньшинство.

BDS 2006, Turbo Delphi - достаточно стабильны. И работать в них приятнее. О Delphi 2007 слышал только позитивные отзывы.

ИМХО, до такого состояния лучшую RAD-систему программирования под Windows привели метания с CLX + Kylix, а позже и создание версии Delphi for .Net. + Создание C# Builder.

Кстати, кто-нибудь работал с Delphi for .Net и C# Builder? Как оно, по сравнению с Visual C#?

← →
Nic © (2007-07-28 03:00) [4]

>
> Кстати, кто-нибудь работал с Delphi for .Net и C# Builder?
> Как оно, по сравнению с Visual C#?

Неужели никто не сравнивал?

← →
Alex Konshin © (2007-07-28 05:40) [5]

Как это ни прискорбно, но на сегодняшний день IDE Delphi - уже вчерашний день.
Они сильно отстают от Java IDE Eclipse и Netbeans, которые бесплатны, а тем более от платных IDE (Idea). Даже майкрософтовский Visual Studio уже более функционален. Если поработаешь в современных IDE, то Delphi IDE уже раздражает своей убогостью.
Вот над чем им надо работать в первую очередь. Кстати, решение Borland об отказе от Deplhi IDE в пользу Eclipse было вполне логичным. Только нужно было действительно делать, а не болтать. Заодно бы и с IBM подружились, так вместе и одолели бы супостатов из Redmond.
Да и без радикального обновления IDE у них масса задач, которые нужно было сделать еще вчера. VCL уже морально устарел. Когда будет полная поддержка UNICODE и других кодировок? В связи с появлением многоядерных процессоров в ближайщее время остро встанет вопрос о распараллеливании всего и вся. А существующая поддержка многопоточности убога. Уже несколько лет существуют 64-bit процессоры AMD/Intel и операционные системы для них. Когда наконец Delphi разродится поддержкой 64-bit? Уже даже бесплатные паскалевские компиляторы ее имеют(или в процессе доводки). Я знаю о планах, но планы были и раньше, но ничего не меняется или меняется непростительно медленно.

Короче, Delphi тихо и долго умирает в результате стратегических ошибок меджеров Borland. Пока даже не видно, каким образом они собираются выкарабкиваться из ямы.

← →
P_ (2007-07-28 06:13) [6]

> Alex Konshin © (28.07.07 05:40) [5]

Ну то что Java сейчас наступает на весь мир, особенно с последней реализацией SWING и новых компьютеров, которые не продаются с менее чем 512Мб ОЗУ, это понятно всем. Не зависеть от системы, железа, от СУБД и многих других мелочей довольно приятно.

Delphi был хорош, когда у него не было конкурентов, а сейчас уже поздно. Хотя еще лет 10-15 за счёт инерции продержится.

Я вот например UNICODE прикручиваю к решениям.

← →
P_ (2007-07-28 06:15) [7]

> Alex Konshin © (28.07.07 05:40) [5]

А в чем проблема с распараллеливанием в Delphi? Неужели для калькулятора обязательно нужно использовать два ядра?

← →
IMHO © (2007-07-28 06:22) [8]

> P_ (28.07.07 06:13) [6]
>
>
> Delphi был хорош, когда у него не было конкурентов, а сейчас
> уже поздно. Хотя еще лет 10-15 за счёт инерции продержится.
>

Мне вот крайне интересно, откуда берутся эти цифры - "лет 10-15"?
С какого потолка?

← →
Alex Konshin © (2007-07-28 09:51) [9]

> P_ (28.07.07 06:15) [7]
> > Alex Konshin © (28.07.07 05:40) [5]
> А в чем проблема с распараллеливанием в Delphi? Неужели
> для калькулятора обязательно нужно использовать два ядра?

Калькулятор на самом деле тоже должен быть многопоточным, чтобы UI не блокировался. И это только самый простой пример.
Я не говорю, что многопоточные приложения нельзя делать на Delphi, сам этим занимаюся уже более 10 лет, но за эти 10 лет ничего в этом плане так и не изменилось. А вот конкурирующие технологие на месте не стояли, да и новые появились. Вот об этом-то и речь.

> P_ (28.07.07 06:13) [6]
> > Alex Konshin © (28.07.07 05:40) [5]
> Я вот например UNICODE прикручиваю к решениям.

Ну и я тоже, но ведь какой ценой это дается! А вот в Java с этим никаких проблем.

← →
Nic © (2007-07-28 12:51) [10]

Почитал в википедии про Eclipse. Что-то захотелось найти этого зверя и поставить, чтобы распробовать :) Это можно где-то бесплатно скачать? Яндекс дал ссылки на какие-то mp3-файлы :)

Но всё же, чем Delphi отстаёт от той же Eclipse?

← →
Sdubaruhnul (2007-07-28 13:34) [11]

http://www.eclipse.org/

← →
Nic © (2007-07-28 13:41) [12]

> Sdubaruhnul (28.07.07 13:34) [11]

Спасибо ;)

← →
Alexis © (2007-07-28 14:19) [13]

> ...до такого состояния лучшую RAD-систему программирования
> под Windows привели

Когда в 2001 мы имели Delphi7 и VisualStudio6, это была правда. Сейчас я не представляю, кем надо быть, чтобы начинать разработку нового продукта на Delphi, который, к примеру, до сих пор не удосужился поддерживать UNICODE.

Тем кто утверждает, что Delphi2007, Turbo там всякие работают стабильно, я предлагаю посмотреть VS2005. Вот там действительно стабильно. Более того, я не понимаю, как Borland"у надо писать IDE, чтобы скорость загрузки среды и появление, к примеру, выпадающих подсказок в 3-4 раза отличалась от VS.

← →
oxffff © (2007-07-28 14:46) [14]

> Суслик © (27.07.07 23:45) [2]
> посмотрим, что с Д2008 будет.
> может быть последний их шанс.

Шанс он всегда есть.
Хейлсберг, Торп ушли.

Посмотрим, что сделает Allen Bauer.

← →
Nic © (2007-07-28 14:54) [15]

> Alexis © (28.07.07 14:19) [13]

VS 2005 не видел. Когда имел в виду стабильность, то сравнивал с D2005, D8. Однако среда не может похвастать такой же скоростью работы как D5-D7 и глюки в новых версиях имеются. Скажем при разработке сложного GUI среда порядком подтормаживает на неплохом компьютере. Тем не менее, новые версии хотя бы не падают постоянно и в них можно вести разработку.
Скажем, при разработке Dll вообще милое дело - всё работает отлично :) Однако примеры использования этой самой dll предпочитаю делать на седьмой версии, т.к. шустрее намного работает :)

← →
Nic © (2007-07-28 15:01) [16]

> Nic © (28.07.07 14:54) [15]

Видел MS студию 2003. Она, конечно, работает шустро как былые версии Delphi.

← →
имя (2007-07-28 15:06) [17]

Удалено модератором

← →
Nic © (2007-07-28 15:15) [18]

> это я (28.07.07 15:06) [17]

Ну и идите отсюда лесом :) Кто-то цепями за яйца привязал к нему Вас чтоли? :)

← →
это я (2007-07-28 15:20) [19]

привык к нему :)

← →
isasa © (2007-07-28 15:22) [20]

Alex Konshin © (28.07.07 09:51) [9]
Объясни, пожалуйста, тупому, зачем для компонентов GUI нужна многопоточность. Я исключаю ситуацию, когда времяемкая задача выполняется паралельно(это тупо просто организовать).
Остальное все равно, как ни крутись, а события по улавливанию мессаджей ты будешь писать руками, будь то COM+/.NET. Так плюс еще имеем гемморой с синхронизацией прорисовки, причем юзеру, в большинстве случаев на такие детали, плевать.

Alexis © (28.07.07 14:19) [13]
UNICODE на сегодняшний момент, самое больное место D ? :)

P_ (28.07.07 06:13) [6]

...это понятно всем. Не зависеть от системы, железа, от СУБД

Нереализуемо, по одной простой причине. Нет универсального лекарства.
Мы разрабатываем/поддерживаем проект клиент(D6)- сервер (MSSQL 7/2000\2005 ORACLE 8i/9i/10i) Все, в принципе просто. Есть разные куски в клиенте и сервере. Общее, попахивает дилетантством и кухонным программированием.

← →
Nic © (2007-07-28 15:23) [21]

> это я (28.07.07 15:20) [19]

Аналогично :)

← →
isasa © (2007-07-28 15:38) [22]

isasa © (28.07.07 15:22) [20]
+
Жена отвлекла "Мясо ей срочно перекрути ..."

Универсальность хорошо, но всегда найдется клиент, которому надо втащить пару миллионов записей. Причем как бі не убеждали меня наши(delphimaster) крутые разработчики, что это неправильно и оно нафиг не надо, все это убивается одной фразой клиента:
"Я аналитик. И хочу видеть всю картину ...". После этого хоть на голове стой ...

← →
Псалтырь (2007-07-28 16:08) [23]

> UNICODE на сегодняшний момент, самое больное место D ? :
> )

Да, Юникод это самое больное место. Китайцев и иже с ними без Юникода даже можно и не трогать. А их до черта

← →
DrPass © (2007-07-28 17:28) [24]

> Alexis © (28.07.07 14:19) [13]

> Тем кто утверждает, что Delphi2007, Turbo там всякие работают
> стабильно, я предлагаю посмотреть VS2005. Вот там действительно
> стабильно

Не хочу впадать в холивар, но именно в части стабильности к VS2005 у меня масса нареканий. Мы ее используем для разработки приложений под .NET CF, и тут уж она себя показывает "во всей красе", регулярно падая на пустом месте. Спасибо, хоть исходники при этом с собой в могилу не уносит, как это в свое время делала Delphi 6 до выхода апдейта.
Кстати, используемый у нас IBM"овский Rational Application Developer (основанный на Eclipse) ведет себя ничуть не лучше. Правда, он перед смертью сохраняет все файлы и десктоп, потом восстанавливаться проще :)

← →
GrayFace © (2007-07-28 17:39) [25]

P_ (28.07.07 6:15) [7]
А в чем проблема с распараллеливанием в Delphi? Неужели для калькулятора обязательно нужно использовать два ядра?
Нету такой штуки, как OpenMP. С ней легко, например, распараллелить циклы внутри множества процедур. Вручную это будет весьма трудоемко. А при 2-ядерных процессорах это актуально. На действиях типа заполнения массива дает почти 2-кратный прирост производительности.

Alexis © (28.07.07 14:19) [13]
Более того, я не понимаю, как Borland"у надо писать IDE, чтобы скорость загрузки среды и появление, к примеру, выпадающих подсказок в 3-4 раза отличалась от VS.
Чему же удивляться, если у Microsoft"а время появления менюшек "Пуск -> Программы" в 10-100 раз больше? :) Все равно, гораздо важнее скорость компилляции, и хотя бы по ней D вне конкуренции.

← →
Иа (2007-07-28 23:07) [26]

Интересно, я пропустил что они из Калифорнии переезжают в Техас.

← →
Alex Konshin © (2007-07-29 10:01) [27]

> isasa © (28.07.07 15:22) [20]
> Alex Konshin © (28.07.07 09:51) [9]
> Объясни, пожалуйста, тупому, зачем для компонентов GUI нужна
> многопоточность. Я исключаю ситуацию, когда времяемкая задача
> выполняется паралельно(это тупо просто организовать).
> Остальное все равно, как ни крутись, а события по улавливанию
> мессаджей ты будешь писать руками, будь то COM+/.NET. Так
> плюс еще имеем гемморой с синхронизацией прорисовки, причем
> юзеру, в большинстве случаев на такие детали, плевать.
>
Про многопоточность в UI говорил как пример (в пику на заявление, что она в калькуляторе не нужна). Хотя да, я считаю, что для UI обязана быть отдельная нить. Это нужно в первую очередь для удобства пользователя.

Для чего-нибудь более-менее серьезного без потоков уже не обойтись. И не важно, GUI приложение это или некий сервис (в последнем случае так вообще без потоков не обойтись). Да, для простеньких клиент-сервер или консольный приложений можно обойтись и без этого. Но вот на очереди четерехядерные процессоры, в ближайшее пару лет будут и восьмиядерные. И если не задействовать многопоточность, то ваши приложения будут отставать в разы от приложений конкурентов.

Да, можно и на Delphi делать многопоточные приложения. Но средства языка убоги (по сути их практически нет, кроме threadvar и синхронизации внутри массивов), библиотека мало что добавляет, более того, далеко не все в библиотеке расчитано на использование во многопоточной среде.

> Alexis © (28.07.07 14:19) [13]
> UNICODE на сегодняшний момент, самое больное место D ? :)

А вы зря иронизируете. Отсутствие поддержки UNICODE сильно усложняет разработку приложений, расчитанных на интернацинальные компании и на азиатские рынки. Или вы считаете, что Япония, Китай, Корея - это мало? Тогда вы заведомо лишаете себя львиной доли покупателей.

← →
isasa © (2007-07-29 11:09) [28]

Alex Konshin © (29.07.07 10:01) [27]
Отсутствие поддержки UNICODE сильно усложняет разработку приложений,...
Ни Боже мой. Я это неудобство поппробовал на собственной шкуре, т.к. доводилоси делать прилоржение на фарси.

Опять плохо выразился. :)
Т.е. тут я полностью с огласен. :)

> Да, можно и на Delphi делать многопоточные приложения. Но
> средства языка убоги (по сути их практически нет, кроме
> threadvar и синхронизации внутри массивов), библиотека мало
> что добавляет, более того, далеко не все в библиотеке расчитано
> на использование во многопоточной среде.

Поясните свою мысль о синхронизации массивов.

>средства языка убоги

А Win32?

> oxffff © (29.07.07 11:45) [30]
> > Да, можно и на Delphi делать многопоточные приложения. Но
> > средства языка убоги (по сути их практически нет, кроме
> > threadvar и синхронизации внутри массивов), библиотека мало
> > что добавляет, более того, далеко не все в библиотеке расчитано
> > на использование во многопоточной среде.
> Поясните свою мысль о синхронизации массивов.

А пояснять-то почти нечего. Где-то в Delphi 3 или даже позднее вставили lock при работе со String. Ну а потом аналогично сделали для динамических массивов.
То есть поддержка многопоточности практически отсутствует.

> >средства языка убоги
> А Win32?

А Win32 это средства языка?
Ладно, забудем о Java, развы так ее не любите. Но какая-то поддержка многозадачности была уже в Алгол 68. В Ада еще больше. А Delphi так на уровне Pascal и осталась.

> А пояснять-то почти нечего. Где-то в Delphi 3 или даже
> позднее вставили lock при работе со String. Ну а потом
> аналогично сделали для динамических массивов.
> То есть поддержка многопоточности практически отсутствует.
>

А вы про lock prefix для ref counting. Понял вас.

Тут вы слегка лукавите.

Еще есть готовая реализация Iunknown (class TinterfacedObject) все c тем же lock prefix.

Далее есть мощнейшее средство TCustomVariantType
Там вам cast, binary op , unary op, Clear,

И главное его
copy, Copy by ref (задайте нужную семантику вашему типу)

То есть все в ваших руках.

P.S. Соглашусь однако, что языковые средства нужно расширять.

Alex Konshin © (28.07.07 5:40) [5]
Как это ни прискорбно, но на сегодняшний день IDE Delphi - уже вчерашний день.
Они сильно отстают от Java IDE Eclipse и Netbeans, которые бесплатны, а тем более от платных IDE (Idea). Даже майкрософтовский Visual Studio уже более функционален. Если поработаешь в современных IDE, то Delphi IDE уже раздражает своей убогостью.
По-моему, Дельфийский IDE лучше Visual Studio. В чем он отстает?

← →
нефт (2007-08-01 01:44) [34]

> Alex Konshin © (28.07.07 05:40) [5]
>
> Как это ни прискорбно, но на сегодняшний день IDE Delphi
> - уже вчерашний день.
> Они сильно отстают от Java IDE Eclipse и Netbeans, которые
> бесплатны, а тем более от платных IDE (Idea). Даже майкрософтовский
> Visual Studio уже более функционален. Если поработаешь в
> современных IDE, то Delphi IDE уже раздражает своей убогостью.
>
> Вот над чем им надо работать в первую очередь. Кстати, решение
> Borland об отказе от Deplhi IDE в пользу Eclipse было вполне
> логичным. Только нужно было действительно делать, а не болтать.
> Заодно бы и с IBM подружились, так вместе и одолели бы
> супостатов из Redmond.
> Да и без радикального обновления IDE у них масса задач,
> которые нужно было сделать еще вчера. VCL уже морально устарел.
>

Ты много накидал понтов и наездов на Дельфи, а обосновать это ничем не смог.

← →
нефт (2007-08-01 01:50) [35]

> Alexis © (28.07.07 14:19) [13]
>
> > ...до такого состояния лучшую RAD-систему программирования
> > под Windows привели
>
> Когда в 2001 мы имели Delphi7 и VisualStudio6, это была
> правда.

Delphi 7 - это 2002 год.

Alex Konshin © (28.07.07 5:40) [5]
Если поработаешь в современных IDE, то Delphi IDE уже раздражает своей убогостью

а можно рассказать, чем убога Delphi IDE, кроме невозможности получить стек вызовов?

> а можно рассказать, чем убога Delphi IDE, кроме невозможности
> получить стек вызовов?

А что глюков мало? 2007 не смотрел, а в BDS2006 приходится отключать половину возможностей,
чтоб хоть как то работало.
Убогие возможности рефракторинга.

> а можно рассказать, чем убога Delphi IDE, кроме невозможности
> получить стек вызовов?

Это вроде уже дебаггеровская фишка. в Turbo Delphi "View-Debug Windows - Call Stack". Хотя только раз в жизни им пользовался....

> Хотя только раз в жизни им пользовался....

Хм. Странно. Постоянно использую, очень удобное средство при отладке.

> Хм. Странно. Постоянно использую, очень удобное средство
> при отладке.

У меня cпециальность другая - COM/OLE/Аппаратура, да и привычка всё в классы и try .. except. Да и при многопоточном приложении проще лог, чем callstack смотерть.

Second Life, Second Chance for CodeGear Найти похожие ветки