Соц. опрос

← →
Kerk © (2006-10-01 20:10) [80]

[44] Юрий Зотов © (01.10.06 00:35)
> исходники VCL показывают , что Delphi продумана настолько
> хорошо, что при необходимости может быть без принципиальных
> проблем портирована и на другие платформы.

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

← →
Юрий Зотов © (2006-10-01 20:39) [81]

Угу. Аж целый 31 файл сырцов общим размеров менее 3-х метров (D6). В то время, как вся VCL содержит более 600 файлов сырцов, которые занимают более 22 метров (D6). Ну просто са-а-авсем другая библиотека, что и говорить.

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

Ром, или ты полагаешь, что реализация SWT для всех платформ одна и та же? А ведь это тоже часть столь хвалимой переносимости Джавы.

← →
Petr V. Abramov © (2006-10-01 21:12) [82]

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

← →
Kerk © (2006-10-01 21:57) [83]

[81] Юрий Зотов © (01.10.06 20:39)
> Ром, или ты полагаешь, что реализация SWT для всех платформ
> одна и та же? А ведь это тоже часть столь хвалимой переносимости
> Джавы.

Я ничего не полагаю. С явой почти не пересекался, потому не знаю. Я про делфи говорю.

← →
Юрий Зотов © (2006-10-01 22:50) [84]

Угу. Про Delphi. Про Delphi 6, в частности (потому что именно в этой версии влияние перехода на кроссплатформенность сказалась наиболее сильно - она была первой).

И что же мы вмдим? А видим мы 31 файл против 600 с гаком (это менее 5 процентов). Еще видим неполных 2 метра против 22 с гаком (это менее 10 процентов). Ну просто са-а-авсем другая библиотека. В корне. Аж на целых 5-10 процентов.

Ром, чтобы вообще что-то говорить на тему переносимости, надо хотя бы понимать, что в любой среде под платформонезависимым слоем всегда и неизбежно существует слой платформозависимый. Который, собственно, и обеспечивает тот самый платформонезависимый интерфейс.

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

А еще надо понимать, что если такому переписыванию подлежат всего лишь 5-10 процентов кода, то это как раз и означает, что "Delphi продумана настолько хорошо, что при необходимости может быть без принципиальных проблем портирована и на другие платформы". Сорри за самоцитату.

Вот что мы вмдим. И о чем и было сказано.

← →
Kerk © (2006-10-01 23:03) [85]

> [84] Юрий Зотов © (01.10.06 22:50)

Это все понятно.
Мне замена визуальных контролов не понравилась. По сути контролы те же самые, в VCL интерфейс от их реализации плохо отделен, потому так.

← →
Джо © (2006-10-01 23:59) [86]

> [85] Kerk © (01.10.06 23:03)
> > [84] Юрий Зотов © (01.10.06 22:50)
>
> Это все понятно.
> Мне замена визуальных контролов не понравилась. По сути
> контролы те же самые, в VCL интерфейс от их реализации плохо
> отделен, потому так.

Как же они "те-же самые", если они (по крайней мере в Windows) используют native"ные контроллы OS?

← →
TUser © (2006-10-02 00:15) [87]

> Юрий Зотов

И все-таки как баран еще раз посторю. Переносимость не процентами меряется. А возможностью переноса. Delphi-код не будет у меня работать на маке, сане, а часто и на линуксе (даже если не использовать windows.pas и иже с ним). Да, очень неплохо помогает в плане переносимости FreePascal, Kylix. Но надо тпризнать факт - сегодня java-приложения лучше переносимы, чем те, которые на delphi. Очевидная вроде бы вещь хотя бы для тех, кто работает одновременно с платформами win и linux.

← →
Cyrax © (2006-10-02 00:25) [88]

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

← →
Cyrax © (2006-10-02 00:27) [89]

Часть 1

Ну уж даже каждое слово раскритиковали. Так и кажется, что ещё чуть-чуть и меня пинком с этого форума со всеми потрохами...

Юрий Зотов © (01.10.06 01:39) [61]
Вообще, мне множество раз доводилось слышать высказывания Сишников и других об убожестве Delphi, о том, что она хороша только для чайников и т.п.

В общем-то я (вспоминается чья-то фраза) "не паскалян, не шарпей и не приплюснутый", и не питонист. Да и не веду разговор об убожестве Delphi и о чайниках. Я всего лишь говорю о некоторых недостатках Delphi как IDE и языка Паскаль.

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

Неужели всё так гладко... Неужели все аргументы отличались полной несостоятельностью...

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

И такое мнение распространено. Но настораживает тот факт, что отсутствуют мнения (по крайней мере я таких не слышал), согласно которым Delphi лучше других сред. В то время как подобные мнения о превосходстве других сред - не редкость...

Причем вот ЭТО мнение ВСЕГДА высказывалось именно теми, кто ДЕЙСТВИТЕЛЬНО соображал и в Delphi, и в других средах. То есть, людьми ДЕЙСТВИТЕЛЬНО компетентными.

Хотелось бы побывать в шкуре таких "действительно соображающих в Delphi и других средах, т.е. компетентных". Но пока останусь тем же наглецом, любителем нарываться на неприятности...

Marser © (01.10.06 01:21) [57]
Я в диком ужОсе :-))

Такой вот я негодяй. Бить меня надо, бить...
(но предварительно лучше связать руки...
и ноги...)

← →
Cyrax © (2006-10-02 00:31) [90]

Часть 2

=============================================================
X9 © (30.09.06 18:12) [28]
Потому, что язык Pascal, от которого и происходит язык Delphi, очень приятен для обучения, от первого взгляда после Pascal на C/C++ тянет блевать.

Юрий Зотов, неплохо было бы прокомментировать эти слова... Я бы с ними не согласился (ну, мягко говоря)...

Юрий Зотов © (01.10.06 00:35) [44]
Неверно. Kylix. Кстати, этот пример, а также исходники VCL показывают , что Delphi продумана настолько хорошо, что при необходимости может быть без принципиальных проблем портирована и на другие платформы.

1. Под переносимым я понимаю проект, перенос которого на новые платформы требует минимальных затрат. Если в случае с Delphi такая ситуация имела бы место, то, во-первых, Kylix не был бы единственным представителем Delphi на других платформах (прошло уже более 10 лет) и, во-вторых, Kylix не имел бы проблем, которые ставят под сомнение его полноценность:
1.1. Стандартная библиотека VCL заточена под родные виндовые элементы, что влечёт за собой сложность выхода за пределы этой ОС (вот она "настолько хорошая продуманность", которая позволяет "без принципиальных проблем" портировать её на другие платформы). Borland, естественно, взяться за переделку VCL не посмела (проще написать новую библиотеку) и зацепилась за библиотеку Qt, которая уже изначально разрабатывалась с учётом переносимости (вот здесь уже действительно имеется продуманность). А для обращения к Qt как раз и была разработана CLX, которая, грубо говоря, является обёрткой (фантиком).
1.2. В целях переносимости кода Kylix, кроме Qt, базируется также (частично) на функциях Wine.
1.3. Одновременное использование промежуточных API и библиотек, отображающих системные вызовы ОС для обеспечения кроссплатформенности крайне неприлично...

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

> от версии к версии меняются библиотеки и модули
В сторону расширения. Что естественно, свидетельствует о развитии проекта, о его живости - и может только приветствоваться.

2. В том то и дело, что в основном только в сторону расширения функциональности. И это свидетельствует о развитии проекта только в одном направлении. Но ни слова не говорит о его качественном развитии...

Кстати, перешли тут с Eclipse 3.1 на 3.2; итог - 5 варнингов и 9 хинтов, а в 3.1 все было чисто. Это к вопросу о совместимости на уровне исходников (при изменении даже не версии, а всего лишь подверсии).

3. Eclipse тут причём - не совсем понятно. Не сам ведь он эти варнинги формирует.

Это лишь Ваше мнение и выражено оно весьма голословно.

4.1. Думаю, уже не голословно (п.1). Но здесь я не о костылях, а о продуманности и переносимости...

Мое же, например, мнение прямо противоположно - архитектура VCL как раз является ярким примером изначально великолепной продуманности. Доказательство - архитектура, существовавшая еще в Delphi 1, перекочевывает уже в 9-ю версию без малейших изменений.

4.2. Опять доказательство развития только в сторону расширения. О каком качественном развитии может идти речь, если за 10 лет не произошло никаких изменений...

За прошедшие 10 лет VCL расширена неимоверно - но только расширена, никаких изменений в ее ядре не потребовалось. Такое стало возможным именно благодаря потрясающей продуманности и гибкости изначальной структуры этого самого ядра.

5. Даже гениям такого не дано...
А что касается неимоверного расширения - то это уже чересчур. Давно уже было пора задуматься над качественными улучшениями этого комбайна. Например, множественное наследование. Но это невозможно из-за языка, лежащего в основе Delphi...

Что же касается "уродства архитектуры", то, может быть, поговорим, например, о работе с GUI в джаве? Мне приходилось слышать мнения знатоков джавы, что вот как раз эта штука сделана довольно уродливо, причем эта уродливость - не что иное, как следствие изначальных принципов мультиплатформенности и плагинности.

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

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

7. А вот насчёт рефакторинга пока воздержусь...

Итог: при ближайшем рассмотрении все до единого Ваши заявления оказались ложными и/или несостоятельными.

8. По-моему, уже нет...
(опять повторюсь, что ни о каких костылях и трупах я не говорю)

> как приходит время функционального наполнения нашего гербария, так
> уже начинаем почёсывать репку...
Если человек не умеет писать код - виновата среда разработки?
Логика потрясает... или отдыхает?

Логика отдыхает...
9. Конечно, опытным кодерам не составит проблем наполнить этот гербарий функциональным содержанием, но начинающим кодерам такая организация разработки программ только навредит. Но не только начинающим, но и опытным кодерам может навредить, поскольку в первую очередь (уже подсознательно) при разработке программ идёт ориентация на функциональность, поддерживаемую делфой на интуитивном уровне (щёлкнул туда, перетащил сюда, смазал здесь и т.д.). И только в случае крайней необходимости начинаем реализовывать функциональность, не поддерживаемую такими средствами. А ведь многие элементы (в частности, компоненты) можно было бы реализовать эффективнее будь Delphi более гибкой (в частности, система компонентов)...

← →
Cyrax © (2006-10-02 00:32) [91]

Часть 3

> Такой стиль программирования навязывают нам Delphi и Builder.
Они ничего не навязывают. Они просто избавляют от рутинной работы. Что позволяет во много раз сократить сроки разработки. Это недостаток?

10. Первоочередная ориентация на такую автоматизацию, избавляющую от рутинной работы, по-моему, как раз и позволяет говорить о навязывании подобного стиля программирования. Это оборотная сторона такой особенности Delphi и Builder"а.
Если говорить о недостатках, то при той же автоматизации процесса создания приложений можно было бы добиться меньшей зависимости от такого стиля программирования (собственно, не понимая, что происходит на уровне кода, а ведь с кодом в любом случае придётся иметь дело)...

> Все классы оформлены в виде разноцветных квадратиков
Утверждение, основанное на незнании. Не все, а только компонентские, да и то не все. Причем таких классов-квадратиков даже не большинство. Доказательство - дерево классов VCL.

11. Хорошо, не все. Согласен.
Я имел ввиду классы, которые не имеют визуального представления на форме. Такими классами Borland и злоупотребляет...
Не думаю, что для их использования в коде проще перетащить на форму квадратики, заполнить мышкой пару свойств и создать для них отдельную панель, чем написать собственноручно несколько строк кода, но с пониманием того, что ты делаешь...

> А что касается переносимости, то здесь настоящий УЖОС...
В самом деле? А я по наивности своей полагал, что для переносимости кода Delphi нужна версия его компилятора, а для переносимости кода Джавы нужна версия ее машины. Принципиальных различий не вижу.

12. Неверно. Если рассматривать самый распространённый способ обеспечения кроссплатформенности (промежуточный API), то для переносимости, кроме компилятора, нужно:
а) отсутствие вызовов функций API системы
б) наличие переносимой GUI-библиотеки (чего не скажешь о VCL)
> А вот преимущества Delphi и Builder"а действительно являются
> преимуществами в большинстве случаев только для новичков, для более
> опытных они оборачиваются недостатками...
Более чем голословно. Пожалуйста, приведите хотя бы один конкретный пример преимущества Delphi, которое для опытного программиста действительно становится недостатком.

13.1. Стиль программирования, о котором шла речь выше.
13.2. Наличие готовых отдельных компонентов, которые частично дублируют свои функции при отсутствии возможности создавать свои классы на основе двух и более имеющихся для расширения существующей функциональности или изменения имеющейся.

Юрий Зотов © (01.10.06 01:54) [62]
> TUser © (01.10.06 01:25) [59]
> Джава все-таки работает на множестве платформ
Ошибка. Не на множестве, а всего лишь на одной - на платформе Java.

14. Скорее, не ошибка, а разное понимание слова "платформа". Если под платформой понимать ОС, то действительно на множестве платформ, если же виртуальную машину, то, естественно, на единственной (своей) платформе.
Но когда речь идёт о кроссплатформенности, то во внимание принимают, естественно, первое значение, поскольку говорить о переносимости имеет смысл только в отношении ОС.

То есть: если Java-машина для данной ОС в природе существует, то код рабочий, не существует - нерабочий. И всех дел.

15. Что касается технологий .NET и Java (имеющих дело с виртуальными машиами), то здесь понятие кроссплатформенности прежде всего относится не к проекту, а к технологии, на которой основан проект, и подразумевает наличие соответствующих виртуальных машин под разные ОС.

> а delphi-программы - только в win.
Ошибка. Не только в win, а в любой ОС, для которой есть компилятор.

16. На настоящий момент только в Windows и Linux, про другие же ОС говорить не имеет смысла, поскольку Borland"у уже хватило проблем с Kylix"ом.
А что касается изначальной функциональности и качественной работы Delphi, то только в Windows.

Ошибка. Стоит лишь заменить компилятор интерпретатором, и никакая перекомпиляция становится не нужна. И всех дел.

17. Object Pascal - не интерпретируемый язык. Для него нужен компилятор. Технология Java - требует виртуальной машины. По-моему разница в понятиях кроссплатформенности здесь есть и немалая...

Угу. Аж целый 31 файл сырцов общим размеров менее 3-х метров (D6). В то время, как вся VCL содержит более 600 файлов сырцов, которые занимают более 22 метров (D6). Ну просто са-а-авсем другая библиотека, что и говорить.

18. Во-первых, в CLX НАМНОГО меньше классов, во-вторых, имеем дело с Qt и Wine.

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

19. Полностью переписать реализацию неасилили. Пришлось задействовать Qt и функции wine.

надо хотя бы понимать, что в любой среде под платформонезависимым слоем всегда и неизбежно существует слой платформозависимый...
Еще надо понимать, что именно этот слой и подлежит переписыванию при портации...
А еще надо понимать, что если такому переписыванию подлежат всего лишь 5-10 процентов кода, то это как раз и означает, что "Delphi продумана настолько хорошо, что при необходимости может быть без принципиальных проблем портирована и на другие платформы".

20. Не означает. Вот если бы сами переписали реализацию и уложились бы в 5-10% кода, то продумка действительно была бы хорошей. Но VCL не позволяет это сделать... Ну никак не позволяет...

← →
Cyrax © (2006-10-02 00:33) [92]

Часть 4

Джо © (01.10.06 01:02) [51]
Какие недостатки Делфи проявляются для более опытных пользователей, разрешите поинтересоваться?

См. п. 13.

TUser © (01.10.06 01:03) [52]
Я вот создаю проект в Delphi конпкой Shift+F4, а сохраняю его кнопкой F2.
При таком подходе мне не приходится ставить кнопочки,Ю галочки и цветочки.

А какой кнопкой ставишь на форму визуальные компоненты ?

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

Да, это так. Но я говорил о стиле программирования и его оборотной стороне (п. 10 и 11).

По поводу переносимости и GPL - ничто не мешает нарисовать проект, компилирующийся в D и FPC.

Мешают GUI-библиотеки.
А что касается языка Pascal, то он действительно имеет недостатки (C++ тоже имеет недостатки !).
Кроме того, тебя не настораживает тот факт, что язык Pascal не стандартизован и не включен в состав пакета GCC ?

Kolan © (01.10.06 01:06) [53]
Молодец. Ты с Delphi дружишь я смотрю. Нука запость "квадратик" для класса TObject.

Дружим. Частенько выпиваем вместе - пьяный Cyrax и пьяный дельфин - экзотика :)
А вот что касается квадратика, то это уже похоже на заказ на разработку нового проекта: To make the impossible 2: to cover the small square...
(Первый проект заказан default"ом и пока находится в стадии разработки)

> И вообще, начинаем "программировать" с интерфейса
Во-первых, так и надо. Только "интерфейс" другое значение имеет. Цитату из "паттернов" привести?

Другое значение - это уже другой разговор. Я же говорил о GUI.
А что касается API-интерфейса, то, конечно, начинать с него.

Во-вторых, если ты разрабатывал начиная с интерфейса пользователя то твой уровень понятен.

Разрабатывал. И выше уровня табуретки не поднялся...
... пока не заставил себя заглянуть внутрь Delphi и Builder"а...

А в-третьих, если в Delphi есть удобные вещи, которые ты неправильно используещь это еще не значит что другие делают так же.

Эти удобные вещи никак, кроме по назначению и не поиспользуешь. Но эти вещи не всегда реализованы максимально эффективно и не лишены недостатков...

Пусик © (01.10.06 03:52) [71]
...
А ведь такие люди начинают поносить все другие языки программирования, кроме своего C.

Конечно, их понос несерьёзен. Там нужных веществ не хватает...
Да и не думаю, что таких людей нельзя найти и на этом форуме (раздел "Начинающие").

Чапаев © (01.10.06 12:55) [78]
Ужжжжжжасно... А если б ты UML, к примеру, увидел, ничего, кроме как повеситься, не осталось бы...

UML я уже видел. Всё дело в принципиальном отличии Case-средств от RAD-средств...

Когда я ваял из-под турбо-паскаля окошки на чистом АПИ, а ещё раньше -- в турбо-вижн, то тоже обзывал делфистов ламерами и батонокидателями. Пока сам не убедился, что никому нафиг не надо мои извраты с CreateWindowEx()... ;-)

Я же не против дизайнеров форм...

======================================================
з.ы. Следующий такой постик смогу написать только в следующие выходные...

← →
Ketmar © (2006-10-02 00:51) [93]

>[90] Cyrax(c) 2-Oct-2006, 00:31
>первого взгляда после Pascal на C/C++ тянет
>блевать.
и после 21 тоже. проктокриптопаталогоанатомия.

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

>уже чересчур. Давно уже было пора задуматься над
>качественными улучшениями этого комбайна.
есть предложения? вот что там "качественно" нужно улучшать?

>Например, множественное наследование. Но это
нафига? кому уж очень сильно надо -- есть интерфейсы.

>невозможно из-за языка, лежащего в основе
>Delphi...
ерунда. бред.

>Итог: при ближайшем рассмотрении все до единого
>Ваши заявления оказались ложными и/или
>несостоятельными.
итог. при ближайшем рассмотрении мы выяснили: кое-кто напрочь не знаком ни с Delphi, ни с принципами проектирования подобных вещей.

>Логика отдыхает...
однозначно... %-(

>может навредить, поскольку в первую очередь (уже
>подсознательно) при разработке программ идёт
>ориентация на функциональность, поддерживаемую
>делфой на интуитивном уровне (щёлкнул туда,
да? в первую очередь идёт ориентация на ТЗ. и на грамотный проект. а если начинаем программу "от окошек" -- это, пардон, к профессионализму относится так же, как дельтапланы к освоению космоса.

>эффективнее будь Delphi более гибкой (в
>частности, система компонентов)...
чего-то не хватает? допиши. по-моему, гибче уже некуда...

на остальное отвечать лениво: цитат много, а смысла -- мало... %-(

зыж от этого пассажа я рыдал: "тебя не настораживает тот факт, что язык Pascal не стандартизован и не включен в состав проекта GCC". такого, пардон, мразма я давно не читал... %-(

← →
Cyrax © (2006-10-02 01:01) [94]

Почему так агрессивно ?

← →
Ketmar © (2006-10-02 01:03) [95]

>[94] Cyrax(c) 2-Oct-2006, 01:01
>Почему так агрессивно ?
потому что стиль у меня такой. если вижу ерунду, то пишу, что это ерунда, а не "автор не совсем прав". %-)

← →
Сало (2006-10-02 01:07) [96]

> 5. Даже гениям такого не дано...
> А что касается неимоверного расширения - то это уже чересчур.
> Давно уже было пора задуматься над качественными улучшениями
> этого комбайна. Например, множественное наследование. Но
> это невозможно из-за языка, лежащего в основе Delphi...

Собсно, по Петзольду 1985 года можно хоть сейчас писать win32 приложения, и они будут работать. С другой стороны, можно привести Linux.

← →
Cyrax © (2006-10-02 01:07) [97]

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

← →
Ketmar © (2006-10-02 01:12) [98]

>[97] Cyrax(c) 2-Oct-2006, 01:07
>Тогда запинай меня...
а зачем? умному достаточно того, что с ним, например, не согласен ЮЗ. а к словам Юрия стоит прислушиваться. ещё как стоит. если он что-то говорит, то делает это далеко не зря. и не на пустом месте. потому -- прислушайся. точнее, вчитайся. попробуй понять, почему он говорит именно так -- ведь на чём-то его речи основаны, нес па? лучше один раз понять самому, нежели сто раз прослушать пояснения.

← →
Ketmar © (2006-10-02 01:13) [99]

зыж я далёк от того, чтобы назначать ЮЗ (или кого-бы то ни было другого) в Вожди и Учители. %-)

← →
Cyrax © (2006-10-02 01:16) [100]

А на счёт VCL как ?
Бред - не бред ?
Впрочем, лучше выпить сначала - потом соображать приятнее...

← →
DrPass © (2006-10-02 01:25) [101]

> Cyrax © (02.10.06 01:07) [97]
> Тогда запинай меня...

Такой опус еще далеко не каждый дочитает до конца... а ты еще ответ на него адекватных хочешь...
Вкратце - причем тут кроссплатформенность в Delphi? Ее там как таковой нет, была лишь не слишком удачная попытка. Речь шла только о совершенстве VCL - и как пример приводилась возможность создания на ее основе кроссплатформенной среды без особых усилий. Это факт, причем неоспоримый. Но, увы, так пока и не реализованный.

Еще Delphi в пику ставится простота использования - дескать, эта визуальная среда плохо позволяет "развиваться". Это действительно так, более высокая начальная сложность той же MS VC выполняет роль некоего фильтра, отсеивающего откровенных бестолочей-от-программирования. Delphi такого фильтра не имеет, и это едва ли не самый большой ее недостаток, действительно влияющий на ее популярность. Потому что большое количество непрофессионалов действительно могут дискредитировать эту среду в кругах "начинающих" программистов. В то же время профессионалы с удовольствием используют мощный инструментарий Delphi... и глубоко плевали на этот действительно бестолковый аргумент. Нынешний профессионал - не программист, который пишет на "низком уровне", а программист, который использует RAD-среду (или другой высокоуровневый инструментарий), при этом знает, как она работает... ну и при желании может написать на "низком уровне". Есть, конечно, исключения из этого правила, но в целом картина такова.

← →
Другой © (2006-10-02 01:32) [102]

А 1С-ники, между тем, работают и не жжужат, что там где у кого.

← →
Юрий Зотов © (2006-10-02 01:37) [103]

Прочитал [98]. Гордо встал на табуретку.

Прочитал [99]. Грустно слез с табуретки.

Черт. Вот так всегда.

:о)

← →
Ketmar © (2006-10-02 01:57) [104]

>[103] Юрий Зотов(c) 2-Oct-2006, 01:37
>Прочитал [98]. Гордо встал на табуретку.
>Прочитал [99]. Грустно слез с табуретки.
>Черт. Вот так всегда.
Юрий, и не надейтесь. я всё жду, когда Вас можно будет поймать на явной ерунде. %-)

← →
Юрий Зотов © (2006-10-02 02:01) [105]

> Ketmar © (02.10.06 01:57) [104]

Никогда не используйте Sleep. Она тормозит систему. :о)

← →
Ketmar © (2006-10-02 02:02) [106]

>[105] Юрий Зотов(c) 2-Oct-2006, 02:01
>Никогда не используйте Sleep. Она тормозит
>систему. :о)
не проходит. аффтар цитаты известен. %-)

← →
Джо © (2006-10-02 02:04) [107]

Кстати, в сей ночной час, Юрий, прокомментируйте, если будет не сложно посты [29] и [30] из http://delphimaster.net/view/2-1159636497/. Я до сих пор маюсь — в калоше я или нет? :*)

← →
Юрий Зотов © (2006-10-02 02:11) [108]

> Джо © (02.10.06 02:04) [107]

Скорее, я.

Вообще-то, там наверняка можно как-то выпендриться и написать процедуру сохранения любого TPersistent (через TWriter.WriteProperties, или еще как-то - ведь среда это делает, значит, и мы можем), только код вряд ли получится короче, чем тот, что уже был приведен.

> Сатир (30.09.06 13:54)
> Назовите преимущества разработки программного обеспечения
> в среде Delphi.

Резюмирую.

1. Delphi-программисты "закапывают" свой талант в "формочки" и в используемые визуальные компоненты.

2. Приобретённый опыт частично базируется на:
- манипуляциях мышкой;
- последовательности кликов;
- заполнении полей о ObjectInspector и информации в dfm-файлах.

3. Код, написанный вручную, скорее всего неотделим от визуального представления, оформленного автоматом в виде RES- и DFM-файлов. А значит он не пригоден к переносу в другую среду, отличную от Delphi (а зачем? - философский вопрос).

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

Отвлечение.

Проекты из JBuilder всех версий, начиная с 1.0, например, легко переносятся в Eclipse, NetBeans, IDEA и другие среды, потому что исходники на Java переносимы даже независимо от своей "межплатформенности" (которая относится скорее к бинарной переносимости), а просто так спроектированы и устроены эти библиотеки.

Прежде всего: модифицированная программная модель "Модель-Отображение-Контроллёр" (образец проектирования MVC), когда логика отделена от визуального представления (можно лепить свои темы, а не довольствоваться системными, - look; можно по-разному отрабатывать нажатия на кнопки, на действия мышью и особенности поведения - feel). В исходниках библиотек Java довольно грамотно используются известные образцы проектирования.

Java проектировали архитекторы, а не хайлсберги. Хайлсберг спроектировал Java WindowsFoundationClasses, после чего Sun подала иск на Microsoft за неправильную (читай - неперносимую) MS JVM 1.1.4, хотя на тот момент у Sun ещё не было JFC/Swing. Это было начало войны не только за переносимость, но и за выживаемость Java как независимой от Microsoft платформы.

>[110] iZEN(c) 2-Oct-2006, 03:38
хихик.

> [111] Ketmar © (02.10.06 03:43)
> >[110] iZEN(c) 2-Oct-2006, 03:38

Неужели пост из CDM? Отчего он, подлец, у меня при запуске Connection failed выдает? :)

>[112] Джо(c) 2-Oct-2006, 03:48
>Неужели пост из CDM? Отчего он, подлец, у меня
>при запуске Connection failed выдает? :)
я уже давненько только ним и читаю/пишу. а у тебя -- может, файрвол не пущает. или прокси не настроен (нет, я не беру прокси из IE; пока надо исходник править, чтобы через проксь ходить; да и не тестил я, как оно с прокси дружит %-).

>> ...весьма голословно.

> 1. Delphi-программисты "закапывают" свой талант в "формочки" и в
> используемые визуальные компоненты.

> 2. Приобретённый опыт частично базируется на:
> - манипуляциях мышкой;
> - последовательности кликов;
> - заполнении полей о ObjectInspector и информации в dfm-файлах.

=======================

>> Утверждение, основанное на незнании.

> 3. Код, написанный вручную, скорее всего неотделим от визуального
> представления, оформленного автоматом в виде RES- и DFM-файлов

=======================

>> У меня до сих пор без всяких изменений работает код, писаный еще в
>> Delphi 1 (а некоторые куски были писаны еще даже в Turbo Pascal).

> 4. Пользовательские библиотеки кода стареют с выпуском каждой новой
> версии Delphi. Их приходится адаптировать, либо выбрасывать.

=======================

Я в восторге.

Заедание патефона смешило меня еще в детстве. Анекдот про чукчу-писателя тоже довольно мил.

К вопросу о неотделимости кода от RES и DFM - вот программа, вообще не использующая никаких RES и DFM:
program ProjectWithoutResources; uses Classes, Forms, StdCtrls, Dialogs; var Form: TForm; Method: TMethod; procedure ButtonClick(Self, Sender: TObject); var i: integer; begin TForm(Self).Caption := "Delphi rulezzz!"; for i := 0 to 5 do ShowMessage("Read the caption of form!"); Form.Close end; begin Application.Initialize; Application.Title := "Demo"; Application.CreateForm(TForm, Form); Form.Position := poScreenCenter; Method.Code := @ButtonClick; Method.Data := Form; with TButton.Create(Form) do begin Caption := "Click me!!!"; Parent := Form; SetBounds((Form.ClientWidth - Width) div 2, (Form.ClientHeight - Height) div 2, Width, Height); OnClick := TNotifyEvent(Method); end; Application.Run end.
И у меня к Вам большая просьба - пожалуйста, больше не говорите о том, в чем толком не разбираетесь.

> Юрий Зотов © (02.10.06 09:11) [115]
> >> У меня до сих пор без всяких изменений работает код,
> писаный еще в
> >> Delphi 1 (а некоторые куски были писаны еще даже в Turbo
> Pascal).
Как же этот "турбированный" код может работать, если со времён TP до наших дней изменению подверглись такие базовые механизмы как:
- число бит в целом (тип Integer 16 -> 32);
- способ возвращения результатов из функции/метода ("присваивание" -> Result -> следующее, наверное, return?);
- объектное представление (object -> class; указатели -> ссылки);
- механизм работы со строками;
- механизмы работы с памятью (оверлеи -> плоская модель 2ГБ; -> менеджер строк);
- названия библиотечных модулей;
- формат бинарных файлов библиотек (TPU -> DCU; TPL -> BPL -> DCL ->...)
Если только этот турбированный код будет переписан в исходниках и изначально представляет собой вариант использования исключительно простых конструкций языка Pascal.

Delphi в современном состоянии это сильно не поможет. Устаревшая библиотека вряд ли сможет составить ядро современного проекта (всё, конечно же, зависит от предназначения проекта).

> >> Утверждение, основанное на незнании.

6 лет практики 1998-2004гг. однако. Чукча писатель. ;)

> рий Зотов © (02.10.06 09:39) [116]
>
> К вопросу о неотделимости кода от RES и DFM - вот программа,
> вообще не использующая никаких RES и DFM:
<...>
> И у меня к Вам большая просьба - пожалуйста, больше не говорите
> о том, в чем толком не разбираетесь.

Это да. Этого не отнять. APPTYPECONSOLE - сильная весчь. Только вот Delphi для таких программок-простыней ничего другого кроме текстового редактора не предоставляет. :)

JBuilder2.0 в 1998 году уже мог полностью синхронизировать (в обе стороны) код текстового редактора с визуальным дизайнером: что нарисуете мышкой, то дублировалось в коде исходника. И наоборот: что напишите в методе jbinit(), то будет на форме в визуальном дизайнере. Без всяких RES- и DFM-файлов Очень удобно. Переносимость исходников из JBuilder в другие среды гарантированна. Почему такого не было на тот момент и спустя много лет в Delphi? Маркетинг.

Крылья... Лапы... Главное ХВОСТ!!!!

Соц. опрос Найти похожие ветки