У Delphi и PB вообще то разные принципы работы. Delphi - компонентно ориентированный язык - кидаем кучу компонент, связываем их и по всей форме размазываем бизнес-логику приложения в перемешку с логикой интерфейса. У PB есть DataWindow, который собой заменяет вкладки Delphi по доступу к данным, гридам, DBAware компонентам, отчетам и графикам. Плюс PowerScript и поддержка наследования в PB гораздо мощнее и удобнее ObjectPascal, в Delphi наследуются только формы, в PB все что угодно, в Delphi идет прямая работа с памятью с любимыми Access Violation и потерей памяти при неграммотном программировании, в PB есть сборщик мусора, готовый взять на себя все заботы по освобождению обьектов. Наконец в PB есть поддержка SQL в PowerScript, красивая событийная модель и поддержка очереди сообщений и функций. Все это реализуется на Delphi, но только при условии его хорошего знания и затрат на кодирование. Но как тут уже было правильно замечено - самый небольшой недостаток PB - это отсутствие русскоязычной документации по нему. Но и в Delphi, даже при наличие множества книг без изучения основ ObjectPascal и VCL каши не сваришь - иначе получится нагромождение формочек, компонент и разбросанной логики, в которой потом будет ой как сложно разобраться. Так что тут все зависит от Ваших знаний и поставленной задачи, если она маленькая, то вообще можно Access взять и быстро ее слепить без дополнительных усилий.

авторС этим соглашусь, а все остальное у тебя исходит из малого знания Delphi.
Я на PB работаю с весны 2003 года. До этого я с 1995 года сидел на Delphi, VCL назубок знаю, пакеты порядка 50 собственных визуальных компонент и черти скока классов :) Так что стоит мой совет с большого опыта работы на Delphi рассматривать.

авторНу на сколько я знаю, ASCRUS на Delphi программировал дольше, чем та PB. Но он является фанатом Sybase (наверное у них на пол ставки подрабатывает :) ).
Нет, не подрабатываю :) Мы просто помогаем друг другу - меня интересуют хорошие технологии, им специалисты тоже не помешают.

авторА вот на счет размазывания и перемешивания бизнес-логики и интерфейса я что-то не понял. Почему она размазывается в Delphi, и почему тогда она не размазывается в PB?
Потому что получение набора данных, правила его сохранения, фильтрация, сортировка, группировка и любое его визуальное отображение находится в одном флаконе: DataWindow. Теперь представьте себе Delphi: под все это придется как минимум вешать TDataSet, TDataSource, TUpdateSQL, TDBGrid (или нормальный коммерческий аналог), TDBEdit, плюс какой нибудь отчетник. Далее начнется катавасия - поля и различные правила на них описывать в событиях TDataSet и TField, контролировать изменение состояния редактирования легче в событиях TDataSource, чтобы раскрасить тот же самый грид придеться на его события вешаться и т.д. и т.п. Причем для каждого компонента нужно знать не только его архитектуру и какое свойство/событие за что отвечает, но и его принципы работы, с кем и как он связан, что и когда у него вызывается. Ну и т.д. В общем старый добрый ООП, который в принципе и не плох, и на нем много чего удобно можно писать (я например люблю на нем чего нибудь под себя делать: парсеры, макроязыки, какой нибудь визульный тулз), но который в моем понимании уступает специально заточенным под это дело средствам, таким как DataWindow. Это конечно же мое мнение, но я вот программируя год на PB и уже перенеся кучу своих различных решений с Delphi, которые считаю удачными для построения клиентских приложений, заметил одну особенность: кода и ошибок на PB меньше получается :)

Локшин Марк
Я не спорю, что на Delphi при достаточном желании/упорстве/времени можно написать полный аналог DataWindow, а заодно и сам PB, причем с более качественным, навороченным и устойчивым IDE. Остается только любезно узнать, где же взять это желание/упорство/время. Вы рассуждаете как опытный программист, поэтому Вам ближе средство, не ограничивающее Вас ни в чем. Я же рассуждаю как руководитель проектов. На PB я могу пересаживать людей реально работать после небольшой предварительной подготовки и демонстрации уже отработанной иерархии визуальных и невизуальных обьектов. Поначалу для начинающего кодера будет достаточно начать рисовать формочки и отчеты DataWindow, что уже для проекта будет большим делом. В Delphi мне для проектов придеться искать квалифицированных и более дорогостоящих программистов, которые все таки разбираются в ООП, наследовании, VCL, куче сторонних компонент и могут хотя бы внятно рассказать, зачем обьект создается, как он живет, оповещает другие обьекты и удаляется, иначе вместо кода мне будут рисовать лабуду на формочках. Все это выйдет мне дороже, не факт что качественнее по коду (я бы сказал даже наоборот), и главное с "бурной фантазией" в коде, которая отличает многих дельфийцев от переизбытка возможностей или недостатка опыта. Частенько мне их приходилось контролировать на предмет усложнения кода, что не прибавляло скорости и надежности проектам. Лично мне это для построения клиентской части только мешалось и послужило одной из главных причин перехода на PB, так как я всегда поддерживал девиз "Чем проще, тем лучше".

авторПросто это версия 2.0 :)
И кстати я работал начиная с Delphi 2.0 и начиная с него прошел все версии включительно 7-ой, на которой до сих пор и работаю, в числе моих последних работ парсер TSQL с MSSQL2000 и на его основе конвертор баз данных с MSSQL2000 на ASA9 (причем все на чистых классах VCL по желанию заказчика). Так что намеки на то, что я "давненько" не видел Delphi абсолютно безосновательны. Хотя не скажу, что я с удовольствием этот конвертор писал на Delphi - на Java или C# было бы гораздо меньше геммороя и больше толку, но клиент к сожалению всегда прав.

Ну а супер-пупер движков на Delphi с собственными парсерами, Run-Time дизайнерами форм и инспекторами обьектов и т.д. и т.п. я за свою жизнь насмотрелся выше крыши (одно время даже помогал в исправлении ошибок и доработке классов FastReport, когда на нем работал). Видел я и отличные движки, видел и ужасные. Но это все равно по большему счету кустарные подделки, какие бы они хорошие или плохие не были. Лично я считаю, что потеря времени и ничего больше. Когда нам заказчик заказывает автоматизировать его работу, он вообще то ждет программу, а не универсальный супер-пупер инструмент, который чтобы еще хоть как то заработал, придеться долго и нудно расширять, отлавливая ошибки. Я уже молчу о его зависимости от приемственности версий Delphi, ни разу не было, чтобы при смене ее версии не пришлось бы ручками править свои пакеты, каждый раз Borland умудрялась корежить иерархию VCL, впихиваю туда нужную для маркетинговой раскрутки функциональность, и кстати игнорируя существующие баги из версии в версию (я уже молчу про доступ к данным аля собственный движок BDE, далее кривой в 5-ой версии ADO и в дальнейшем работающий для избранных DBExpress, резвый прыжок на Линукс и тут же обратный на Windows и т.д. и т.п.). Все эти навороты в виде супер-движков, приколы Borland и баги VCL по любому увеличивают время разработки проектов, что с точки зрения финансового благополучия довольно печально отражается на самих нас (если конечно мы не на окладе и нам готовы "простить" сто лет писать один проект).

Кстати я так и не понял, почему большим недостатком в PB является отсутствие возможности регистрации собственных классов редактирования компонент и свойств. Я так думал только первый месяц после перехода с Delphi на PB, весь в пылу написать иерархию всего чего нужно, причем чтобы было круто. И даже написал кучу всего - вплоть до коллекций, стэков, джавовской событийной модели, наследования всех визуальных компонент для вешания на них Align и подписки на события других обьектов, и т.д. (что в принципе простительно, так как писалось это исключительно в целях самообразования). Далее уже, как в голове все утряслось и прояснилось по поводу что и как в PB, я так аккуратненько почти все поудалял, добавил малость того, что действительно показалось удобным и все стало простым и легким, и редактор свойств действительно оказался в PB не нужным и еще через пару месяцев я стал смотреть на разработку клиентских приложений на Delphi очень и очень косо, так как скорость написания проектов на PB заметно увеличилась к примерно аналогичным по затратам проектам, параллейно реализующихся на Delphi, ну а уж к вопросу построения собственной супер-иерархии на PB я даже больше и не возвращался, тем самым сэкономив себе кучу нервов в неравной борьбе по "глюкоопасному" изменению предков больших иерархий в PB, лишних проблем со сборщиком мусора и т.д. Если уж сильно мне не будет функциональности хватать, так PFC никто не отменял, там во всяком случае уже классы отработаны с прошлого века :) Возникает закономерный вопрос - а Вам то зачем редакторы свойств в PB сдались, случайно не по той же причине ?

авторК слову, специалисты, кто программирует на Delphi, насколько я помню, не рекомендуют использовать компоненты, подобные TDBEdit вообще...
Ну это вообще No Comments. Читал я их забавный топик в форуме Delphi. Все дружно сошлись во мнении, что DBAWARE компонентами пользоваться не стоит и нужно ручками переносить все в TEdit, потом после редактирования ручками же все переносить в TDataSet и тогда сохранять. Первым сильным аргументом в пользу TEdit перед TDBEdit была фраза "А мне ручками прикольнее писать". И куча других не менее забавных аргументов, которые честно говоря я слабо очень понял. Наверное Borland зря придумал TDataSet, TDataSource и TDBEdit, TDBMaskEdit, TDBChechbox, TDBListBox и т.д., так как настоящие специалисты предпочитают все делать сами и для них главное не какое то время разработки или кол-во допущенных ошибок, а глубокое моральное удовлетворение от собственно разработанных решений, пусть и выглядящих немножко кособоко.