1) Порочная визуальность
Мешать в кучу непосредственно код и описание UI само по себе плохо. Ведь удобнее, чтобы эти две сущности были как можно больше разделены. Взять хотя бы тот же Qt: UI полностью отделен от кода и писать к нему код можно хоть на Ruby. На .NET тоже наблюдается поползновение в туже сторону - WPF. 

Мало того, большинство начинающих программистов на Delphi воспринимают эту среду как только визуальную и понятия не имеют об основах ООП! Именно такая практика имеет место в многочисленных учебниках. Показательна в этом плане "Библия Delphi". Кидаем кнопку на форму,  "клепаем" кусок кода (обработчик события) и баста! Ни к чему хорошему это не приводит. Но ведь такому стилю изложения в какой то мере способствует сам Delphi.

2) Отсутствие сборки мусора (Delphi for Win32)
При разработке более-менее крупных приложений это становится проблемой. А самой частой ошибкой становится Access Violation, причем не помагает даже самое тщательное тестирование. Это общеизвестно. Конечно, ходят слухи, что GC вот-вот появится. Но если вспомнить, сколько времени Borland "кормила завтраками" про перегрузку операторов, то ... "жить в эту пору прекрасную уж не придёться ни мне, ни тебе"

3) Непереносимость (некроссплатформенность)
На платформе Linux инструментарий Kylix заморожен.

4) Туманные маркетинговые перспективы
Borland стала по сути филиалом и кузницей кадров Microsoft. Как это случилось можно почитать здесь.

Вот как то так у меня получилось. Обсудим?


Это сообщение отредактировал(а) kemiisto - 2.8.2008, 10:21

Эх, как жеж я забыл то:
5) Отсутствие полной поддержки Unicode (в т.ч. и в VCL)

Будем надеятся что в 2009 будет

Согласен насчет того, что код и UI должны находится как можно дальше друг от друга.
С QT не работал, но в WPF это довольно удобно...




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




А лично для меня это +. Я лучше сам буду отлавливать AV, чем доверять это не понятно кому. Возможно, GC в некоторых случаях и для некоторых людей удобен. Я лично, уже привык без него. Это сейчас я с ним сталкиваюсь в том же C#, а раньше спокойно без него обходился.




Delphi создавался как средство под Windows. ИМХО, не нужна ему кроссплатформенность. Для этого есть другие средства.




Это все конечно интересно, но нет ли чего посвежее? Посмотреть что произошло за 3 года довольно интересно в этом плане.



Согласен. Это явный минус. Надеюсь, что это исправят в новой версии Delphi.


Мое мнение такое - пока люди будут использовать Delphi он будет жить.
Я в данный момент изучаю C#, да. Но Delphi я не брошу. Мне нравится сам язык Паскаль, я привык к нему, для меня он удобнее.



Ну и бред же я написал...

Думаешь, программисты Borland справятся с этой задачей хуже?


Вот тут на русском написано про появление CodeGear и его (в итоге) продажу (внизу там ссылочки).
Из последних Embarcadero and CodeGear CEOs Live Chat. Судя по всему Tiburon выйдет. Из языков приоритетными остаются (как в принципе и были) Delphi и С++. А с .NET, похоже, покончено... 


Это сообщение отредактировал(а) kemiisto - 3.8.2008, 13:57

Добавочка к первому пунктику:

Источник

Это сообщение отредактировал(а) kemiisto - 3.8.2008, 17:51

Сборка - вещь удобная. Введением в Delphi сборки было бы хорошем шагом. А пока его нет - Delphi программисты (а не только Delphi а также C++, etc) продолжают существовать. Хотя в крупных проектах это могло бы быть очень полезным. (ИМХО)


минус - щас довольно шустро развивается unix системы, так как они становятся более доступны для пользователей. Но! большинство фирм (а в первую очередь это интерисует компании где работают разработчики на любых языках) остаются на Win, и на Win'e сидеть еще будут очень долго. Так что это сомнительный минус - но все же он есть. Щас он не так влиятелен, в дальнейшем это может перерасти в толстый минус. Увидим.


Delphi (CodeGear) перешла в компанию которая занимается БД (как я понимаю) а (тоесть делает уклон на БД) => Delphi (имхо - как и был раньше) все больше перелезет вакансии "Программист БД" и все меньше останется "прикладных" проектов, хотя и щас их не много. Большинство проектов переносят на C# / Java, и это очевидно - перспективы (хотя мб это и не так (хотя больше похоже на правду...) - но так как припадают наши СМИ, новостные ленты и прочее информацию - дает некий толчек для руководителей проектов, так как естественно по "внешнему виду" .net, Java выглядит перспективнее Delphi) 


В 2008 Unicod'e вроде как реализован, судя по Delphilab.ru, да и обещания в to-do были.

ЗЫ. Сейчас изучаю C#, и мне он кажетьяс более приятным (приятный - не знаю како объяснить - но по он меня затянул... как наркотик ><) НО! Делфи не хочу не в чем ругать или говорить что "он умер" "он плохой" и прочее. Язык сам по себе сильный, и обозвать его "языком для написания калькуляторов" (как считают некторые C'шники (накидал компонентов и готово (хотя для некоторых "программистов" это и есть "программирование") - язык не поворачивается), на Delphi крутиться много проектов в том числе и коммерческих. Он будет развиваться. Но как ответил kemiisto, некторые существующие языки обходят его по используемым технологиям...

все было сказанное ИМХО и просто исложеные мысли и раздумья.

Это сообщение отредактировал(а) Exai1e - 8.8.2008, 23:29

Ошибался. Delphi .NET включен в новую RAD Studio. 

4 и 5 пункт можно вроде как вычеркнуть. Хотя на счёт 4 полной уверенности нет. Пока нет...


Ну так это по-майкрософтски! Подсадить побольше народу на "наркотик"! "Порошок" пока хороший, но со временем начнуть "бодяжить" мукой...   


Хм... А что значит "сильный"?

Внесу 5 копеек.
1. Система не совершенна, но она работает и довольно эффективна. При необходимости её можно будет улучшить.
Что касается начинающих, так сначала учиться нужно, а потом уже пытаться изображать из себя куллхакера.
Хотя, чем больше знаешь, тем больше понимаешь, что кулхацкеры по сути - гопота. И не становишься таковым.
А про "Библию" замечено справедливо. Аффтара убить, книгу сжечь. Любая оккультная литература действует негативно.

2. Сборка мусора. Суть не в споре о её необходимости. Сборка - понятие более высокого уровня абстракции.
Сборка мусора - привилегия языков более высокого уровня. Высокого не по крутости, а по далёкости от ассемблера.
Дельфи всё же более приблежён к процессору, как и С++. Отсюда и специфика.
Вы ещё посетуйте, что ассемблер мусор не собирает...
Выше уровень абстакции - легче кодинг - меньше свободы.
ИМХО, Дельфи на оптимальном уровне. Достаточно простой кодинг и, практически, максимум свободы.
Хотя при этом, некоторые элементы сборки мусора существуют с древнейших времён. (стринги, овнеры).

3. Да, кроссплатформ хромает. Но и мы должны понять. Люди тоже хотят кушать. А инструментарий под линукса хлебушка не приносит.
Отсюда и провал кайликса. Инструмент хороший. Но затраты на него меньше расходов.
Продвигать подобные инструменты можно только из благородной OpenSource цели.
Ну а за бесплатно есть то, что бесплатно. То есть продукты типа FreePascal и KDE Studio.
Имеют право на жизнь. Но по сути хрень в коричневых штанишках.
Не существует ни одного кроссплатформенного продукта уровня Дельфи.
А на меньшее мы не согласны - закушались...
Впрочем, будущее кроссплатформа зависит не от кодгира, а от линукса. Пока его GUI позиции хромают. А потому рапид девелопмент под него коммерчески невыгоден.
Вот, когда он поднимется, как коммерческая платформа, вот тогда и будет нам тотальный кроссплатформ.
А пока это только теория.

4. И обсуждать нечего. Такой культовый продукт не может умереть.
Да, были сложные времена. Вина в том Борландовская.
Ситуация пока только улучшается.
Сначала была ликвидирована Борландовская бюрократия. А теперь и вовсе влияние умирающего Борланда закончилось.
Так что впереди только дорога в светлое будущее.
We'll shell be happy   

5. Юникод. Тут что-то нужно сказать? Думаю, уже нет... На очереди х64.

Странно всё таки. Программирование (как впрочем и вся IT индустрия) на данный момент единственная область научной деятельности, в которой принято использовать несовершенные инструменты. Возьмём хоть тотже БАК (коли уж он на слуху). Представьте, что кто-либо из его разработчиков скажет "БАК не совершенен, но он работает ..."  Глупость же! А в IT работает...   


Неверно. Посмотрите хоть на тот же Oberon. Язык снабжён сборщиком мусора и на нём написана ОС.


К тому времени сердцами и умами завладеет какой-нибудь Q/Mono Develop. Трудно будет продвигать свой продукт.

Добавлено @ 11:57
Хех! Только увидел. В дополнении про БАК - Вот, пожалуйста! Где тонко - там и рвётся!  

Это сообщение отредактировал(а) kemiisto - 22.9.2008, 22:07

мне единственно что не особо понравилось, когда попалась задача по обработке видео с тв тюнера, вот я там страху натерпелся, один только vfw.pas нашел да dspack, а вот чтоб самому полностью с нуля что-то такое сделать, попробуй найди литературу... (именно риентированную на делфистов...) 

Меня лично Delphi полностью устраивает, хотя...
Из-за каких-то разногласий Borland и MS, последняя так и не выпускает ничего Pascal-е-образного.
А жаль. Было бы интересно посмотреть, что бы получилось.  Вполне возможно, что MS бы заткнула за пояс Borland, как это произошло с С++. И данная тема могла бы никогда не появиться.

Ещё хочу добавить два недостатка: 
1.    Синтаксис подобный паскалю встречается редко, а вот Си – подобный синтаксис почти у всех известных языков (не считая конечно VB   ). В результате с них переучиваться друг на друга проще.
2.    Отсутствие статических методов. Очень удобная штука.

Разве???

http://www.interface.ru/home.asp?artId=6763



А по-моему это плюс языка. А то были бы все на одну рожу. Да и удобнее паскалевский синтаксис чем сишный.

  Нет. Почти у всех известных тебе - так будет правильнее. Навскидку: Ada, Eiffel, Modula, Oberon, Simula. Ну и Delphi, конечно же.  


Это те, которые методы класса? Так они есть конечно же.  

н…да со статическими методами я конечно промахнулся. 

kemiisto, ты же не хочешь сказать, что эти языки настолько же часто используются как Java, C++, C#, PHP?

Добавлено через 6 минут и 2 секунды

Не факт – это вопрос привычки

Нет, конечно. Но ведь популярность никогда не была критерием качества.  

а как надо? написать класс, интерфейс...

Добавлено через 9 минут и 24 секунды
  

Для себя среди недостатков вижу глючность редактора кода: подчёркивает код, который фактически компилируется и работает без ошибок. Затем ещё визуальный редактор не запоминает положение и размеры редактора persistent полей наборов данных, а также редактора ActionList

Принципы ООП необходимо объяснять на примерах простых консольных программ. Как это и делается в книгах по Java, C#, Ruby, ... А Флёнов только мозги запудривает. Визуальный компонент = объект, а вот обратное не верно. Надо начинать с объектов вообще, а затем уже переходить к визуальным компонентам в частности.

Добавлено через 5 минут и 4 секунды

Кстати, попытки были.  

Это сообщение отредактировал(а) kemiisto - 26.12.2008, 23:05

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

Я по-прежнему придерживаюсь мнения, что если  Embarcadero (или кто там будет разрабатывать новые Дельфи) не будут выпускать новые бесплатные версии этого продукта типа Турбо (а еще желательно на сайтах Embarcadero выкладывать для бесплатного скачивания  хорошие книги по работе в последних версиях Дельфи, и уж совсем здорово - на нескольких языках) - плохи дела будут у Дельфи. Я не сторонник Майкрософта, но на своем опыте почувствовал, как удобно без всяких проблем (технических, юридических) установить любую из бесплатных MS Студий. MSDN тоже весьма помогает в освоении "студийных" языков. А это так важно для начинающих пацанов, которые хотят себя попробовать в программировании. И понятно, что они, эти ребята - будущее мира программирования. Чем проще и легче доступ к инструменту для разработки программ какой-то фирмы для подрастающего поколения - тем больше вероятность того, что в дальнейшем  продуктами именно этой фирмы будет пользоваться это самое поколение. Ведь в начале своего программистского пути очень трудно разобраться, в чем преимущества конкретного языка программирования (среды разработки, библиотек...). Что доступнее для опробывания, для написания первых программ - то и лучше, так решают многие начинающие (и не только начинающие).
Если учесть, что традиционно у Дельфи были сильны позиции в основном на постсоветском пространстве, а Майкрософт выпустил русифицированные версии Студий и MSDN - это еще один мощный удар по популярности Дельфи.
Боюсь, что без адекватных решений по популяризации и доступности Дельфи о преимуществах этого весьма достойного продукта в недалеком будущем будут знать только фанаты Дельфи. К сожалению...

Да это уже для совсем ленивых!   

Вроде как в Delphi 2009 нельзя просматривать содержимое модулей, которые поставляются вместе со средой? Если так, то это серьезный минус, по сравнению с другими версиями.

В Trialе нельзя. А вот в полной версии можно.

Зато, вроде как, самый быстрый компилятор!

Вообще-то макросы в Delphi есть. 

ms-help://embarcadero.rs2009/devcommon/recordmacro_xml.html (Эту ссылку можно открыть в Document explorere.)

Это сообщение отредактировал(а) Bose - 6.1.2009, 04:26

Надеюсь в полной версии и с UML редактором всё нормально?

Уже давно, только я не понимаю, зачем они нужны? По крайней мере я не нашёл им применения.

Добавлено через 41 секунду

UML только в Д2009 появился?

Добавлено через 5 минут и 16 секунд
Не вижу я UML редактора ни в D2009, ни в D2007

сегодня поставил 2009! счастлив как хомяк в буханке хлеба))


можно.


не заметил я такого чуда. по скорости компилятор обычный... как в D2007, но быстрее D7.

а вот на счет мутности планов и постоянных перекупок продукта туда-сюда... это проблема!
но, как говорится, в отношении дельфи - ситуация может только улучшиться   

1. На счет порочной визуальности не согласен. Только благодаря ей язык Pascal и приобрёл популярность. Другое дело, что при кривых руках... но при таком обстоятельстве любой наворот будет порочным. Ну и конечно тонны библий дэлфи, освой дэлфи за 3 часа и прочих, сослужили плохую службу.
 Лично мне нет. Графический интерфейс и так вынесен в отдельный файл dfm. Вообще вопрос спорный, во многом зависит от специфики работы и личных предпочтений. Во всяком случае ни кто не запрещает забить на всю визуальность и работать в стиле Turbo Pascal.
2.  Ну это опять же у кого как, у меня нет. Сборщик мусора создаёт другую проблему: произошло какое-то исключение, программу уже закрыли а какой-нибудь файл остаётся открытым и фиг ты с ним что-то сделаешь. Если AV хоть как-то сигнализирует о том, что что-то не так, то здесь ни каких ошибок тишь да гладь, а работать невозможно. Если ошибка и возникнет, то совершенно в другом месте, возможно даже где-нибудь у клиента в солнечном Магадане  

Вот мой список недостатков пару лет спустя   :
1. Глюкавость. Ну блин, нельзя впеньдюривать какую-нибудь модную фенечку так, что с ней невозможно работать. Потрачены ресурсы/время/деньги, а результат — только матюги от потребителя. К примеру Help Insight: то он вообще убирал IDE, вроде исправили, теперь всплывает фиг знает как, тэги ///<summary> только к 2010 версии более менее начали подцепляться и то не всегда. Удобного инструмента по добавлению тэгов, аналогичного ToDo нету. В результате Help Insight отключают сразу после установки, теперь даже если его исправят об этом мало кто узнает :( 3!!! года понадобилось для исправления русских букв в редакторе... Ну про сам Help я вообще молчу, ибо конадский боян. 
2. Отсутствие кроссплатформенности. Да, зря после Delphi7 отказались от неё и начали дрейфовать в сторону Net, сейчас вроде исправляются но много времени потеряно.
3. Отсутствие 64-битности, без комментариев.

при чём это длиться уже лет шесть, начиная с дельфи 7   

Однозначно.

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

 C Delphi 2005, если быть точным.
 Не знаю, не знаю. Может где-нибудь в левых компонентах не реализован...

Нем, именно в генокоде.

Добавлено @ 10:21
D2009. unit DBCommon.


 это обнаружено Сергеем Бузаджи, автором замечательных компонент Fib+ у них на форуме


Это сообщение отредактировал(а) Akella - 13.5.2010, 10:22

Может это в не обновленной D2009?. У меня стоят все обновления. Все в порядке.

Ну а теперь по теме. Последняя версия, в которой работаю, 2009. Поэтому замечания по ней.
- Глючная IDE. Прежде всего, это касается редакторов свойств и кода. В 10-ке вроде чуть лучше.
- Отсутствие кроссплатформенности, учитывая потребность писать под Linux и мобильные платформы (про прокладки типа Prism вообще молчу).
- Зависимость IDE и , в некоторых случаях, созданных в ней программ от .NET Framework. (А я и не догадывался, что пишу с использованием .NET.   шучу).
- Help становится ужасный. Вот с этого все и начинается, сначала .NET Framework и пошло, поехало.

В общем-то, перспективы не очень радужные, при всей моей любви к Delphi.

а мне не нравится, что TDBComboBox не имеет свойств вроде SourceTable и SourceField, по которым он брал бы данные для своих Items

или уже имеет?

И ещё очень большой недостаток - это отсутствие каких-то упрощённых лицензий типа, как была IDE D2006 Turbo за 300 долларов. Уж очень дорого 1000 для одинокого разработчика.

Ну если из Personal убрать половину, глядишь и будет так стоить.

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

да, почти самое важное -- дерьмовая индентация кода в редакторе

Это сообщение отредактировал(а) k0rvin - 29.5.2010, 02:52

это отступы или что?

да, отступы

Тогда поясни более конкретно, что не так? Что не нравится? Где лучше и как должно быть?

Добавлено через 12 секунд
меня лично всё устраивает

не нравится, что 
1) при нажатии ENTER после begin (а лучше после любой строки, заканчивающейся не ';' и не '.') редактор автоматически не ставит отсупы в два пробела (ну или как задано в опциях) относительно позиции первого символа строки, на которой нажимался ENTER;
2) при вводе end; автоматически не пододвигает его на те же два пробела влево;
3) при нажатии ENTER в строке, заканчивающейся ';', ставить курсор на позицию начала выражения, а не предыдущей строки, т.е. как есть (символом '|' обозначен курсор):


а вот так надо:



лучше сделано в vim'е: пункт 2 он не умеет, но зато с первым и третим вполне справляется.
emacs справляется со всеми тремя пунктами.

Добавлено через 12 минут и 37 секунд
еще не нравится, что кнопка tab "делает то, что обычно" -- вставляет символ табуляции, я уже привык, что она индентирует (выставляет правильные отступы) текущую строку или все строки выделенного куска кода. но поскольку такое не везде есть, согласен на опциональность =)

Редактор не только отступ выполняет в два пробела, да ещё и end добавляет (D2007)

Добавлено через 1 минуту и 44 секунды

не понял, зачем end на два пробела влево двигать?

Добавлено через 3 минуты и 40 секунд



да, есть такое

1) да, точно, забыл, в 2006 тоже есть такое (+ сразу if..., for..., etc вставляет), но мне такой подход совсем не нравится, еще с редакторов, вставлющих закрывающую скобку/кавычку.

2) затем, что иначе будет так:

а надо так:


вот еще кстати -- необязательность скобок после имени функции/процедуры без параметров при вызове.

Всем не угодишь ведь 

Добавлено через 24 секунды
Каждый др программирует, как хочет 

Тут дело не в том, угодишь или не угодишь, а в общепринятых правилах форматирования кода.
Кроме того, есть же CnPack, хотя и он не все делает правильно.
Еще мне непонятно, зачем при создании цикла for автоматом подставляется следующее:

По идеи, было бы правильно делать так:
- набираешь for, нажимаешь пробел, появляется конструкция вида:

[] - объекты табуляции (это уже реализовано)
[to] - клавишами вверх/вниз выбирается между to и downto

- после вода параметров цикла, опять же используя клавишу Tab, перемещаемся в позицию ввода тела цикла.

И таких примеров достаточно.

Еще очень раздражает расхождение между перечислением процедур и функций (в порядке создания) и фактическим их местонахождением среди прочего кода (в коде в алфавитном порядке).
В 7-е такого не было.
Не знаю, как другие, но я все процедуры и функции строго упорядочиваю и комментирую. Т.е. события формы в одном месте, события меню - в другом и т.д. Это позволяет повысить читабельность кода. ИХМО.



Это сообщение отредактировал(а) former - 3.6.2010, 12:57

  

честно говоря, я бы быстрее руками написал, чем бегать по табуляциям и стрелками что-то там выбирая.

В итоге всё доходит до этого: "По многочисленным запросам российских программистов в среду разработки добавили кнопку "сделать 3.14дато""  

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

А я уже где-то выкладывал такую IDE. 

Это сообщение отредактировал(а) former - 3.6.2010, 17:49

я вообще-то жаловался на отсутствие автоиндентации и индентации по TAB-у. а автовставка шаблона выражения мне только мешает.

Не забывайте что среда за вас еще и объявит переменную по которой выполняется цикл

это потому, что поцкаль (а также делфи) не предоставляет конструкции для создания локальной области видимости в произвольном месте, по типу let из других языков и сам for не умеет этого делать. т.е. хотя бы как в С++:



и не пришлось бы такой костыль делать.

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

это не так

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


и

где во втором примере хаос? наоборот, второй больше соответствует структурному подходу: кускам some code и some other code совершенно не нужно иметь доступ к i.

конкретно в этом случае (и ещё в некоторых) можно упростить до

не вижу никакого хаоса. =)

Что не так, у меня Delpi 2007 сама добавляет в раздел опсания переменных Var i:integer, если пишу цикл For i := 0 to...


k0rvin
В простых примерах это не мешает, однако, как мне кажется при чтение больших кусков чужого кода это может вызвать затруднение, с определением где объявлена и на какую область действует данная переменна. Достаточно много пришлось программировать на C++, и точно скажу, что для меня эта особенность Delphi в плюс.

Это сообщение отредактировал(а) cemick - 4.6.2010, 14:20

k0rvin, согласен 

ещё раз посмотрите мои примеры, я не призываю к коду типа


я имею в виду


области видимости вполне обозримы, даже более обозримы и "узки".

Это сообщение отредактировал(а) k0rvin - 4.6.2010, 14:49

Хорошо, а для каких целей вам надо ограничивать область видимости. Я не вижу разумных объяснений почему это может быть удобно и оправдано. Кроме того, если вам понадобиться использовать еще в 10 циклах ниже, каждый раз прийдеться объявлять переменную, и хорошо, если у нее короткое имя типа.

Это сообщение отредактировал(а) cemick - 4.6.2010, 15:54

1) это удобно и оправдано, потому что правильно.

для случая 10-ти циклов я и приводил выше вариант



+ можно добавить в for некоторый вывод тиов (тип счётчика выбирается как наиболее широкий из типов a и b), тогда получим возможность писать так:


т.е. возвращаемся к текущему состоянию, только переменная-счетчик видна только в теле for

2) я же не говорю, что использование let должно быть обязательным. кто не хочет -- юзает var в начале подпрограммы.

На самом деле удобно очень. Вписал for + Tab + i (переменную цикла) + Tab + Screen.Forms + Tab + пишешь тело цикла.

Во, вспомнил.
Я давно мечтаю, чтобы в дельфи все невизуальные компоненты выкладывались не на форму, а на какую-нибудь специальную панель в IDE. А то если много компонентом, то трудно проектировать форму.

Но!!! В одной из последних версий эксперта GExperts почти реализовали мою мечту. Они добавили команду "Hide/Show Non-Visual"         и теперь можно прятать невизуальные компоненты формы.

Добавлено через 1 минуту и 40 секунд
И ещё один большой недостаток среды в том, что она не запоминает положение всяких вспомогательных редакторов. Таких как редактор ActionManager`а, редактор persistent-полей набора данных. Частично GExpert тоже запоминает и восстанавливает размер этих окон и положение, но не всё.

согласен, как  в вижуал студии например. особенно фигово становится, если отключить выравнивание по сетке (я предпочитаю выравнивание относительно компонентов)

В принципе, все Non-Visual можно убирать в DataModul, но это лишний модуль, так что поддерживаю.

А обязательно невизуальные компоненты бросать на форму? Можно ведь с кода создавать...В визуал студии идеология заставляет так делать.

можно, но зачем загромождать исходник "бесполезным" кодом?

Да ладно, сколько там того кода    Или лучше загромождать форму?