2 devil ------ Может пан анонимус и предпочитает весь интерфейс творить собственными лапками(имеется ввиду на С/С++), я же как заправский ламер предпочитаю набросать интерфейс в каком-нибудь дизайнере, и не терять время на то что того не стоит. Куда более важные вещи скрываються за интерфейсом, в самих кишках проги. А сидеть и учить тот-же qt в деталях, а то и до Xlib :) добираться мне незачем, и без того проблем море. ------

Последняя фраза ИМХО нагляднейшим образом показывает почему качество софта под Линух неуклонно падает. Одно только широкое применение QT, не слишком то органичного (мягко выражаясь)тулкита для X уже наделало немало бед. Но Вы даже QT не хотите хорошенько изучить. Поэтому то и появляются медленные и монстроподобные программы, которые к тому же и элементарных операций выполнить не могут.

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

Sergos.

Лет эдак 8-10 назад, все кому не лень кинулись писать "программы" на FoxPro. Сбывали свои поделки налево и на право, мало того, как правило в договоре предполагалось "обслуживание ПО" и оговаривалось время этого обслуживания (0.5-1г), естественно за отдельную плату, которая выплачивалась ежемесячно, т.е. когда софт начинал глючить или просто не работал вызывали "программиста", приходил дядя (ну или тетя), смотрел с умным видом в монитор, стучал по клавишам, дня через два приносил подправленный софт и все начинало вроде как работать, плохо что недолго, через некоторое время ситуация повторялась. Когда проходил срок "обслуживания ПО" ничего не менялось, кроме того, что теперь оплачивался каждый приход "программиста". Самое интересное, что некоторые конторы до сих пор сидят на этом софте и считают нормальным по сей день платить за чьи-то недоделки и кривые руки. Правда некоторые конторы (из тех, что сидят за этим софтом) оказались умней, они просто ввели у себя штатную единицу "Программист" и взяли к себе на работу, кого бы вы думали, правильно - тех дядей (тетей), которые все это писали. Софт, конечно, все также глючит, но зато и исправляется быстро. IMHO сейчас примерно тоже самое происходит с Delphi, а далее будет происходить с Kylix. Разница в одном - если сейчас софта под Win хватает (можно найти и выбрать), то то что будет предлагаться сейчас под Linux - это, в основном, написанные на Kylix поделки, очень красивые, но с сомнительной функциональностью.

А у нас на работе, кофейный аппарат
каждые две недели выходит из строя,
приходят и ремонтируют.

Чем программы лучще ??

>Да нет, Дельфи (если кто еще непонял) - это конструктор такой, >для приложений. Паскаль там только "для связки слов" >(ну, примерно, как мат - в русском). >Все основное там вовсе не в Паскале.

Да там все остальное для связки слов, а все основное на Паскале

{:{|}

А вообще, все эти *Builderы фигня, в реальном проекте огромная масса времени тратится на анализ требований заказчика, затем уже дизайн проекта и реализация. Таким образом, можно сэкономить не так уж много времени на реализации интерфейса, бо не в интерфейсе, обычно, собаки зарыты ;-)

Да в том и дело, что собака зарыта не в ГУУЕ, а время тратится в основном на него ненаглядного.

{:{|}

Win хватает (можно найти и выбрать), то то что будет предлагаться сейчас под Linux - это, в основном, написанные на Kylix поделки, очень красивые, но с сомнительной функциональностью.

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

>Win хватает (можно найти и выбрать), то то что будет предлагаться сейчас под Linux - это, в основном, написанные на Kylix поделки, очень красивые, но с сомнительной функциональностью.

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

{:{|}

Единственное, что в Дельфи не очень хорошо (даже ИМХО плохо)- это сам Паскаль

{:{|}

Каанэчно! Паскаль плохоб все плохо - один он д'Артаньян. То то весь мир пользуется и ничего! И ничего не подозревает о "паршивости" Паскаля. Ты хоть пару денюжек заработай на софте а потом бей себя в грудь.

Самый Большой и Толстый Любитель ПАСКАЛЯ (СБиТП)

Да я не про деньги...

Мне паскаль не нравится не тем, что он плохой язык, а тем, что он очень хороший язык, но есть стандарт C/С++ и еще один язык с теми-же возможностями (говорю "с теми-же", чтобы не обсуждать "делегирование" и отсутсвие множественного наследования);-) - непонятно для чего.

Причем С/C++ по-моему специально не насаждался какой-либо фирмой

Просто можно не знать Паскаль и работать.

Но работать не зная C/C++ - невозможно!!!!!!!!

Не для спора, но для разъснения позиции. :-)

Может я и не прав. Время покажет.

{:{|}

стандарт С++ - это интересно.

>стандарт С++ - это интересно.

A chto takogo interesnogo? uzh dva goda kak s nim zhivem....

У С++ очень много преимуществ перед Паскалем но в то же время ОПаскаль во многом выигрывает. Для разных задач разные инструменты. Нынешний паскаль далекооооо ушел от языка разработанного Н.Виртом

AC (*) (2001-07-27 18:29:02.0)

Простите не знал (Да-а, вот это лажанулся)

Уж простите за то, что прерываю ваш спор.
Ежли кто ставил Kylix - ответте на вопрос: полноценный трёх-звенный доступ к БД появился в GPL-версии, или все так же как и в 1.0?

ЗЫ. У нас в орг-ции очень много софта, написанного на Делфях (доступ к БД). Софт этот нихитрый, программистов на Д у нас целый машинный зал набит. Так вот, наши партнеры (далеко не все пока) требуют кроспрлатформенное клиентское ПО (Win+Unix).
Так что нам эта штука очень кстати пришлась (Delphi+Kylix).
А кому не надо - мой совет: используйте то, что Вам больше нравиться.
Лишняя альтернатива никогда не мешала, зато сравнивать будет с чем.

ЗЗЫ. Как адимин я предпочитаю Perl и С.

Не, дорогая редакция, я фигею. Собралась, здесь стайка "крутых" программер, и причем, более крутым видимо считается тот кто пишет все прямо в машинных кодах. Не чесс-ло :) Умора. Очень многие высказывания этого треда, напоминают наших бывших вождей - "Мы пойдем другим путем". Пусть, хреновым, неудобным, напряжным - но Мы же круты... ЗЫ: как я понял, большшинство здесь админы, так? А простите на кой хрен админам действительно Kylix? А вот прикладним программистам, гораздо удобнее работать в RAD.

Лучший RAD всех времен и народов -- XEmacs! ;-)

zeroman (*) (2001-07-27 20:53:34.0)
Ну не все так однозначно. Крутой программер пишет, показывает. Работает.
А в процессе эксплуатации выскакивают разные 'нюансы'
Так вот я считаю, что некоторые проэкты требуют детальной проработки,
и здесь знания чем-больше тем лучше. А то и самолеты падают и криптография фиговая
-а виноват один человек и зовут его "крайний". И мне трудновато представить программу,
в которой ошибка - допустимое явление. Все говорят что все круто, а как ошибка - так "нельзя никогда исправить"
Вот почему то самую простую программу нельзя сломать а сложную можно.
Логика в чем ?
и ни кто не идет другим путем, просто люди дополняют обычный подход к програмированию, своеми знаниями из своей специфики.
А програмировать в машинных кодах - В чем проблема ?

Игорь.

Не надо гнать. Ручками на Tcl/Tk нарисовать гораздо быстрее, чем в гуйне. Мышой возить не надо, думать не надо, всё за тебя сделают.

> Странное у Вас, господа Антихристы и qwe, представление
> о программировании.

 А у тебя что, есть вообще хоть какое-то представление?
Сильно сомневаюсь...

> являются CASE-средствами

 Чаво? А поучиться немножко, прежде чем гнать? Rational Rose, 
Together, и т.п. - да, действительно CASE. Но уж никак не дельфя.

> с использованием технологии RAD

 RAD - не технология, а набор методик. Не шибко специфицированный,
но всё же налагающий на инструменты некие ограничения. Увы, но Дельфи
этим ограничениям не удовлетворяет - нет достаточно мощной системы
модулей, нет строго определённого механизма записи спецификации модулей
и автоматического документирования интерфейсов модулей. Так какой
же после этого дельфи RAD? Уж про CASE и говорить не стоит.

 И не ссылайся на ламерский CITFORUM, ок? Умные книги читай, а не говно
всякое.

> эта технология неприменима для разработки ОС, программ,
> работающих в области, где ошибка может
> обернуться человеческими жертвами (это потому,
> что там цикл разработки несколько специфичен)

 Опять гонишь. RAD этому делу эквипенисуален, ничто его применять
не мешает. 

 Вообще, удивляет меня, откуда здесь столько ламеров? Их что,
специально сюда толпами направляют, чтоб народ раздражали?

Я что, говорил, что в Qt нет layout manager-а? Его нет в Дельфи. А против Qt есть одно непрошибаемое возражение - это C++-only говнище.

В тех редких случаях, когда Tk не канает (не понимаю, в чём он убог? Всё есть, что надо) - есть и Guile/GTK, ML/GTK, и прочие GTK-биндинги, по концепции мало от Tcl/Tk отличающиеся.

> А вот прикладним программистам, гораздо удобнее работать в RAD. 

 А ты хоть знаешь, что такое RAD? Или тоже, как тот ламерюжка dendy,
просто ляпнуть захотелось? Ты уж не выступай, до тех пор, пока не
понимаешь, об чём базар. 

P.S. Интересно, почему половина "программистов" думает, что RAD -
рисовалка гуйни?

"это C++-only говнище."
тут пробигал пост.. кто то хотел попробовать python+qt....

"P.S. Интересно, почему половина "программистов" думает, что RAD -
рисовалка гуйни?"

может оно так и есть?
Не все то что написанно в умных книгах, бытует в жизни. Borland'у выгодно назвать RAD'ом gui-рисовалку потому, что это модно и это принесет денег (потому что модно ;-). Теперь все кто пользуется продуктами Borland знают, что RAD - это gui-рисовалка, и для них это истинна. И это правильно.

Сейчас спроси у самого крутого программера (реально крутого) "что такое unix".. в 95% случаях будет ответ - "это OS", а на самом деле это "worldwide Single UNIX Specification integrating X/Open Company's XPG4, IEEE's POSIX Standards and ISO C".

2против-крест: биндинги для Qt существуют для Python, Ruby и Perl(статус этого не знаю, помню только факт существования) как минимум, а это уже _не_ "c++ only". Все гуевые интерфейсы в той или иной форме объектные, тока в gtk+ эти объекты уродские, бо для Ц, а в языках с поддержкой объектов эти объекты более естественны. Да, на всякий случай повторю -- речь об гуйне. BTW, видел объектный Tcl? Вот урод-то... ;-)

2анонимус от VW: ваши VW и есть запоры, недавно стукнул чужую тачку, жаль, что не жука, а то носил бы гордое званине "debuger" ;-) Тачке херово пришлось, а у моей тока пластик на бампере поцарапался. А был бы там жук, так вообще бы раздавил его и не заметил.

От того, что биндинги существуют, жить не легче. Слишком уж сложно эти биндинги писать - сначала в голый Цэ заворачивать, а потом уж биндить. Криво это, через попу. Лучше уж сразу пользовать чисто сишный тулкит.

2Antichrist (*) (2001-07-29 16:43:02.0): биндинги используют часто. но не в этом фишка.. фишка в том, что qt не c++ only, как ты говорил. А как это реализовали другой разговор.

А _тебя_ не заставляют эти биндинги писать, есть добрые люди, пользуйся ;-)

Может это и неуместно, но ход обсуждения подталкивает напомнить:

Дельфи (как и Kylix, CBuilder и т.д.) не только RAD для GUI, хотя, как многие помнят и возник как развитие идеи Visual Basic. Но и Visual Basic не только RAD. RAD для GUI-это то, что легче всего показать.

В подобных системах развивается и обкатывается технлогия КОМПОНЕНТов. (В этом месте очень хочется произнести "умные" слова - COM/DCOM/COM+, Corba. JavaBeans)

Дельфи/Kylix, CBuilder (и даже Visual Basic) состоят не только из средств для программирования GUI (Как по-видимому TCL/TK - если ошибаюсь поправьте), но дают полноценный доступ к системе( к системным вызовам). Тем _самым_ они _превращаются_ в _ОПЕРАЦИОННУЮ_СРЕДУ_, не выходя из которой можно решить ЛЮБЫЕ задачи. (Кстати скорость комплятора здесь себя и проявляет-работает почти также быстро как и интерпретатор и на выходе очень эффективный код)

Здесь любопытно вот, что: только, что обсуждался вопрос о переносе технологии .NET на Linux/Open Source, и тут же Kylix, на который было затрачено некоторое (не знаю сколько) денег, вдруг под GPL.

Кроме того, любопытно вспомнить кто разрабатывал Delphi/vcl, а кто C#

В последнем предложении речь не о фирме, а о Фамилии :-)

{:{|}

lmd

To Antichrist Прошу простить за ламерство: что значит lmd?

{:{|}

lmd stands for "lammerz must die". Даже комментировать не смешно... В последний раз призываю всех, у кого язык чешется тут выступить, сначала почитайте, что такое RAD. Бред нужно нести потом, наобразовывавшись уже.

Thanks a lot.

If you will ever see {:{|}, be sure - it is not me.

Bye.

"will" must be erased :-(

Bye

{:{|}

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

DataForm:= TDataForm.Create(Application);

... Использование DataForm ...

DataForm:=nil;
DataForm.Free;

А вот если бы этот горе-программер начал изучать программирование не с поганых дельфей, а с ассемблера какой-нибудь DECовской машины или C,
маловероятно,чтобы он сделал такую ошибку.Сейчас прибежит тупой ламер
антицхрист и начнет вопить про GC, дескать не должен программер
заботится о таких вещах,только я ему сразу скажу - иди на х@#,глупый
ламер.Если ты имееш какое-то отношение к преподаванию,тебя и близко
нельзя к преподаванию подпускать,ибо ты из спеца сделаеш ламера,а из
ламера безнадежного идиота, каким и сам являешся.Работать надо, а не
витать в хаскелевых облаках.А дельфийцев очень много развелось.Пора
их с антицхристом отправлять достраивать Байкало-Амурскую Магистраль.
Пора заняться делом. Работы на всех хватит, граждане ламеры.

Antidelphi

wtf GC?
IuF

Garbage Collection.
Очень полезный подход к управлению ресурсами. 
Вкратце - отслеживается доступ к ресурсам, и если к данному
ресурсу больше нет доступа - то он удаляется из системы.

Существует 2 основных подхода к ГЦ - ГЦ реального времени и 
ГЦ не реального времени.

При реализации ГЦ реального времени объекты удаляются в момент 
потери последней точки доступа к объекту. Наиболее простой способ
реализации ГЦ реального времени - так называемый "Reference Counting"

При реализации ГЦ не реального времени объекты удаляются в 
произвольный момент - к примеру, при возникновении "Resource starvation"

Хорошо реализованный механизм GC сильно повышает производительность системы с большим количеством.

2omerm: "
Garbage Collection
skip"

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

Кстати, по русски это было бы СМ :)
IuF

А вам не кажется, уважаемые (и не очень) супер крутые (и не слишком)
программеры (и не только), что каждый инструмент создаётся для решения
определённого (вполне) класса задач?

А Delphi и Kylix - это даже не инструмент, это обкатка новых технологий.

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

Комп - это инструмент для решения ПОВСЕДНЕВНЫХ, (для особо продвинутых,
поясняю: повседневных - возникающих каждый день, возможно не однотипных)
задач.

Некоторые, конечно, гаркнут: "Геть отсюда, не в свои сани сел, зови
Большого Профи ламммммммерррррррррррр".

А мне проще не мучаться с разъяснениями такому крутому куул... и тд сути
вопроса, не разжёвывать ему алглритм решения проблемы, а сесть, и написать
самому. По деньгам, учитывая стоимость моего рабочего времени, это дешевле.
Да и обкатка будет быстрее, сам ваял...

А так как, в основном, написаным однажды - делись со всеми, кому это тоже
может пригодиться, и для кого придётся дорабатывать под его конкретные
нужды, такие технологии мне нужны как воздух!!! Ко всему, хочется дабы и
интерфейсная часть выглядела для другого пользователя приятно и привычно...

Кому нужен Kylix, JBuilder - мне. И таким, как я. Ну, не нужна мне, в
основном, оптимизация по времени выполнения... Если это критично - подключу
код на ассемблере. Самое медленное звено в системе - это оператор
(чаще всего - я сам). Требуется время хотя бы на осмысление начальных
результатов.

И не надо кричать, что что-то там заглючит. Грамотное и осмысленное
использование инструментария, (а это, по моему, и есть профессионализм )
всегда поможет сделать ПРАВИЛЬНУЮ программу.

А мат, персональные наезды и прочее, на LOR откровенно надоели. Я понимаю,
каждый ребёнок, не успеет молоко на губах обсохнуть - уже имеет единственно
правильное мнение и рецепт решения всех проблем. Но господа, если в научном
споре вместо аргумента будет применяться аперкот, если в беседе будет
применяться в качестве основного языка матерный - то я не знаю... Взрослейте
скорее!

С уважением, Valery_R

PS Основные языки программирования, используемые мною в работе - Prolog,
Pascal (Delphi), Java. Стаж программирования - 24 года, начинал с Fortran.
Сейчас, в основном, Java. Я НЕ ПИЩУ СИСТЕМНЫЕ ЗАДАЧИ И САМИ ОПЕРАЦИОННЫЕ
СИСТЕМЫ. ЭТО НЕ МОЁ. МНЕ НАДО РАБОТАТЬ В ОПЕРАЦИОННЫХ СРЕДАХ, НАПИСАНЫХ
ДРУГИМИ, НА ТЕХНИКЕ, СОЗДАННОЙ СПЕЦИАЛИСТАМИ НЕ МОЕГО ПРОФИЛЯ.

>все мы видим огромное количество глючного софта, включая
>писанное "профессионалами" - Netscape, XFree86, Linux kernel, gcc, и
>многое другое.

Глюки, конечно есть, но gcc ты совсем недавно хвалил и советовал
изучать его исходники.

Также, помню ты хвалил Fortran, а потом говорил, что хуже C может
быть только Fortran.

Ну, если честно, gcc - не то приложение, где лики страшны, однако бывают случаи, когда и там они жить мешают. Это я к тому, что даже очень аккуратные люди без ликов на Цэ/ЦэПэПэ написать просто не в состоянии. Это нисколько не умаляет остальных качеств GCC.

А про Fortran я говорил лишь, что он идеален для численных методов. Всё, что за пределами, на нём писать очень сложно и глупо. Каждой задаче - свой язык, и ничего тут не поделать...

Вот что мне ответили в Borland о С++ IDE:

It is estimated that we will be releasing Sylix in Q1 of 2002. Best Regards Bill Borland Customer Service

Так что недолго ждать осталось. Правда GPL версию выложат опять с полугодовым запазданием, наверное.

Билдерам в линуксе не место

Для тех, кто зарабатывает на линуксе это решение Борланда полезно.
Но для развития самого линукса это очень неприятная новость.
Для начала - компилятор должен быть один. Все необходимые фичи должны быть внесены в этот компилятор. И этот компилятор - GCC. Все остальное надо давить. Соответственно OPascal имеет право на существование только в одном виде - в виде frontend'а GCC.
Тем более, что сама технология разработки в Kylix отличается, если не сказать противоположна, принятой в GNU-world.
Вот если бы создали средство, позволяюшее удобно создавать логику программы _отдельно_ от интерфейса, причем интерфейс бы рисовался и его описание храниолсь бы в специфическом формате, который бы легко преобразовывался в код для X11R6, GTK, Qt как минимум, и чтобы для конфигурации этого интерфейса генерировался configure (дабы каждый пользователь мог без проблем использовать то, что ему удобнее), вот такая система действительно _нужна_. Мало того, ее вполне можно было бы продавать, причем за вполне приличные деньги.
В чужой монастырь со своим уставом не ходят, а всякие VisualAge C++ (IBM) и Kylix совершенно не к месту. При этом немного изменив политику, и вложив некоторую сумму в разработку они иогли бы легко завоевать рынок средств разработки под линуксом.
А так, кроме волны глюкавых г(х)уевых приложений это ничего не принесет линуксу.
Интересно, найдется ли в IBM умный человек, который доведет VisualAge C++ до ума, или нет?