Тогда много народу перейдет на linux. При нашем размахе пиратства subj появится на рынке очень скоро. Я неоднократно слышал фразы типа "linux - это круто. Только жалко что дельфей там нет..."
С моей точки зрения это не так хорошо. Сразу появится большое количество программ с низким качеством. И инструментарий вряд-ли будет свободным.
Отрадно только, что M$ не переносит под linux свой VB :)
И все эти прикладухи будут non-free. Да хоть и free, - что с того толку ? Сам-то Delphi будет commercial. А это означает, что прикладухи либо автоматически станут пиратскими, либо non-free.
Ведь в чем пиратство заключается ? Дома можно делать что угодно и на чем угодно - это как с совестью договоришься. Но если ты это что угодно выпускаешь наружу, у тебя сразу спросят: "А инструментарий ты откуда взял ?"
Это очень хорошо. В корпоративном мире накопилось море прилад на дельфи, теперь люди смогут их крутить под linux. По той же причине, если появится VB под linux, это тоже хорошо. Чем больше возможностей, тем лучше. Вот что осталось непонятным, так это совместимость. Можно ли будет просто перекомпилировать, или придется докручивать ? Кто-нибудь знает, насколько глубоко библиотеки в delphi привязаны к ОС ?
Дожили! Визуальное програмирование под Линухой!
Мало было на наши головы монструозного НетШкафа, так теперь как
последние виндозники будем клепать глюкалы размером от мега и
вверх?
Странный Вы человек. Иметь возможность не значит всех обязать/принудить ей пользоваться. Есть куча софта, нарисованного на VB. Переписывать его никто не будет (в основном). Если появиться возможность этоот софт крутить под linux, это приведет к тому, что можно будет в некоторых случаях отказаться от MS платформы. А Вам это, похоже, не нравится.
вообще, этому анонсу стоит порадоваться. кто пробовал писать, к примеру, на GTK+, тот поймет. delphi, при всех своих недостатках, позволяет сосредоточиться на задаче.
проблема non-free --- это уже другой разговор.
Билдер Си++ был бы лучше для системы, написанной на Си. И с переменой платформы, наверное не было бы больших проблем. А дельфы - это средство для быстрой разработки не очень хороших программ. Я в ней довольно долго работал, и чем больше работал, тем меньше она мне нравилась. Си намного лучше.
Билдер Си++ был бы лучше для системы, написанной на Си. И с переменой платформы, наверное не было бы больших проблем. А дельфы - это средство для быстрой разработки не очень хороших программ. Я в ней довольно долго работал, и чем больше работал, тем меньше она мне нравилась. Си намного лучше. А дипломы на дельфи в нашем институте все пишут.
Ja i ochen' mnogie davno zhdali ety novost'. Ja dymau, eto to chto spaset
Linux ot verojatnogo kraha. O kkaom krahe ja govoru? V kratce eto mozhno
sformylirovat' tak: Linux eto OS dlja program, bol'shenstvy ludej s nej
tjazhelo; Win eto OS ldja ludej, bol'shenstvo programm tam vobsche ne zhivyt.
Chtobi Linux stala yniversal'noj OS ej neobhodimo zavoevat' desktop, toest'
obichnogo pol'zovatelja i estestvenno programmistov dlja nih pishyschih.
Soglasen, Delphi, da i vobsche Pascal ne svojstvenni unix-like OS. Odnako
yniversal'nogo jazika net i vrjadli bydet. Po povody C++ Buildera... hmm,
naskol'ko ja pomnu versija 4 vishla posle takojzhe Delphi, da i vobsche y
menja takoe vpechatlenie chto i to i drygoe delaut sovmesno. Po vidimomy
Delphi pod Linux - naschypivanie pochvi, esli experiment ydastsja, to i
Builder for Linux skoree vsego tozhe skoro pojavitsja/bydet razrabativat'sja.
Ny, a naschet license dymau eto vopros k GNU - bydyt li i oni delat' nechto
podobnoe, no pod GPL ili tak i ostanytsja lish s GCC/EGCS perevodja vse
drygie jaziki pod nego (GPC naprimer).
Ламера!
Дельфей захотелось?
Или мало вам багов на вашу голову?
А слабо разобраться в имеющихся toolkit-ах?
Возьмите к примеру JX и Code Crusader - Delphi даже рядом не стояла по удобству, скорости разработки и качеству кода.
Хотя.... пусть живет...
Чем больше выбор, тем лучше...
http://www.cco.caltech.edu/~jafl/jcc/
Привет спорщикам!
Похоже здесь говорят про разные вещи.
Зачем людям которые пишут прикладной, к примеру бугалтерский
софт нужно знание тулкитов, зачем им тонкости системного
взаимодействия Иксов? Они специалисты в своей предметной
области и им нужен простой и удобный инструмент, который
кстати отлично взаимодествует с большими SQL серверами.
Насчет глючности и багов, так Pascal защищен от это в
большей степени благодаря строгой типизации данных.
Повтторюсь, для прикладных программистов прямое управление
ресурсами в большенстве своем не нужно.
Ну а для тех кому интересны свободные паскали, пожалуйста
ссылочки:
Free Pascal (Кстати поддерживает некоторые расширения Borland)
http://www.brain.uni-freiburg.de/~klaus/fpc/
GNU Pascal
http://agnes.dida.physik.uni-essen.de/~gnu-pascal
К сожалению мой опыт прогаммирования GUI как для Windows(VC++,MFC) так
и для UNIX (Solaris,egcs,Motif) невелик. Однако, VC++ мне ну никак
не показался простым и тем более удобным, думаю это справедливо и для
Delphi. Может кому и показалось что "морду" приложения очень просто
визуально нарисовать редактором диалогов, однако это просто до тех пор
пока "морда" состоит из одной кнопки. Как только ты хотишь, чтоб нормально
обрабатывалось ну например изменение размера главного окна - всей этой
визуальщине приходит конец. Приходится лезть в обработчик событий и
фактически переписывать всё заново, но уже ручками :-(( - уж проще
, не страдая фикнёй, сразу руками написать. А в Motif-е всё автоматом
- на то дан "geometry manager". Вобщем ну его нафик этот Delphi, буду
в Linux-е писать проги на gtk+ !
По поводу Gtk+! Которая по сути является оТчень неудобной( по моему мнению) библиотекой написаной с использованием всего
тяжкого наследия С. Другое дело Qt! Это действительно отличная
обьект-ориентированная библиотека и если бы для нее было бы
RAD-средство на уровне Delphi то не нужны были бы сабжы.
Да не пишут умные люди на С++! Умные пишут на С. А совсем умные
(которые международные лауреаты) пишут на FORTRANе, да и то с
трудом. Linux не для бухгалтерии. Если вам, бухгалтерам, не нравится
тяжкое наследие, если Вы сильно вумнее, то и напишите себе свою
собственную ОС, об'ектноориентированную, для которой С++ будет
родным. А Linux остав'те придуркам из университетов. Таким как
Торвальдс. Его наследие не тяготило.
Может быть я и не такой вумный но по-моему написание быстрого
ядра ОС это одно, а создание современного графического интерфейса в котором имеется сотни обьектов( для реализации
которых несомненно лучше всего подходит ООП ) - это другое.
И в последнем случае лучше уж обьектный Pascal чем старина С!.
А почему собственно Linux не для бугалтерии?
Обще признано что Linux является одним из самых лучьших сетевых
клиентов, к тому же имеет развитую систему разграничения доступа
к различным сервисам, а также надежна, устойчива и что самое
главное бесплатна. Последнее приобретает все большее значение,
правда пока приемущественно в России (BSA свирепствует!).
Так что и для бухгалтерии Linux очень хорошая платформа.
Так же хочу заметить что RAD (Rapid Application Development)
придумали не дураки, а очень даже умные люди.
У меня есть знакомая девченка, которая не имеет высшего образования,
не знает толком ни одного языка программирования сделала на
акссесе несколько прекрасно работающих бухгалтерских
программ, которые имели множество реляционно-связанных табличек
и справочников. Все это прекрасно работало и удовлетворяло заказчика.
Вот такая история про RAD!!!
Может кто-нибудь умный объяснит, почему С++ не подходит для програии под Х-ы ? Ведь большинство новых средств С++ (по сравнению с С) являются compile_time средствами.Интересно, а каким дебагером пользуются УМНЫЕ програмеры на С? Вот например DDD и CODE MEDIC писан на С++, и это не мешает им быть качественными продуктами.
А споры об оболочках и о ламерах, которые не могут разобраться в JCC очень похожы на пижонство.Да нет ничего сложного ни в настройках какой-бы то ни было операционной системы, ни в работе с оболочкой.Лучшим подтверждением этому является программа обучения в каком нибудь вузе.В любом серьезном вузе пичкают в основном математикой.А оболочка всего-лишь призвана бастрее писать код, который до тебя уже сто раз писали, и ты такой-же написал бы без оболочки. Ну а найти геморой себе на задницу и кричать на каждом шагу я его вылечил это в линуксе все умеют. Чего стоят хотя-бы крики о "ПОЛНОМ" преимуществе консоли над Х-ами. Прямо как в армянском комсомоле - сначала создаем трудности а потом их преодолеваем.Предчувствую, что на мой вопрос о дебагерах все ответят GDB :).
А как язык, на котором написана операционка может предопределять язык, на котором будут писать для нее приклады ? Ты может быть боишься, что системный вызов из С++ не скомпонуется с либой, которая обращается к ядру ? Или ты боишься, что либа из С++ кита не сможет обратиться по этому адресу ? Уверяю тебя, все пройдет просто отлично, и компоновка в этих случаях пройдет так-же как на С. Ты интересно на С++ когда нибудь писал ? А на С ? Про этапы сборки когда нибудь слышал ? Так вот - в этих этапах существенно отличается только этап компиляции, а относительно к С/С++ выход из компилятора практически одинаков по причине compile-time'ности всех нововведений С++, как это уже сказал товарищ ниже. Фактически приложение писанное на С и на С++ будет отличаться только компоновкой функций, т.к. на С++ в метод передается еще и указатель this, через который доступаются к свойствам, да и то это только без оптимизации, а релизный exe'шник будет таким-же. Почитай Страуструпа и попробуй придумать, как реализовать все эти средства с максимальной эффективностью, если у тебя есть уже реализованные средства С и попробуй прикидочно посчитать потерю эффективности в каком-нибудь приложении. Если придумаешь, вспомни что ты не самый вумный, а есть люди которые реализуют их еще эффективней тебя.Вот и получится, что для ОС эта потеря эффективности важна, а для большинства приложений ею можно пренебречь, зато скорость разработки,ООП увеличивает пропорционально величине проекта. В результате свой "гипер-хакер-сниффер" из трех строк ты напишешь на С, а большой проект будешь писать намного дольше програмиста на С++ с аналогичной квалификацией.
Да теперь я понимаю почему писатели на С++ не могут понять что прежде чем откомпилить их код gcc
сначало обработается препросесором и в программу внесуться множественые изменения которые невозможно прогнозировать
тоже касается любителей паскаля препроцесор серьезная штука!!!
Насчет гуи на ANSI C хороший образчик реализации объектного програмирования на структурном языке
какая красота конструкцияй возможна при использовании указателей на функции в структурах данных и использование
сигналов делает 'С' куда более уместным чем Дельфи (Пасквиля) при разработке любого API под Linux...
PS. Как говориться незванный гость хуже татарина а ламер в Линуксе армагедон работающей системы...
Такое ПО как DELPHI просто необходимо! Прибегает скажем к вам
заказчик(это в случае когда вы работаете а не клепаете
очередной "гипер-хакер-сниффер") и слезно умоляет написать ему
500$ софтину с защитой за три дня, в которой немеренно окошек и сложной логики как раз на неделю. Куда ручки тянутся? API, BC++ c OWL? Нет! Подайте Delphi!( C++ Builder )
P.S Кстати о дебугерах! GDB, DDD, CM это все круто, а есть ли дебугер работающий без исходных текстов и отладочной информации? или хотя бы дизассемблер?
ИМХУ интернет серверы Линух уже завоевала, пора и дальше двигаться, хоть ту же бухгалтерию воять.
Кстате оч обсуждаемая тема в RU.LINUX. А на вопрос что лучше Делфи или
Це, то многие ответят что фортран аль ишо шо поэкзотичней. Лично я пишу и на Це, и на Паскале, и на
Делфи, а при желании на Фортране, Форте, Ассэмблере. И выбор на чем писать у меня не вопрос религии, а вопрос
целесообразности. Единственный вопрос у меня, так это насчет подлиности сабжа.
2SICKE:
И чем же интересно отличается препроцессор С++-сный от препроцессора С-шного ? :).Я же говорил несколько этапов сборки.Из этих этапов я рассматривал только компиляцию.Препроцессор там АБСОЛЮТНО такой-же как и в С.Более того препроцессор это всего-лишь средство подмены текста, и он не изменит текст вообще если ты не включил какие нибудь хидеры и не добавил какое-нибудь предписание препроцессору.Я вообще не понимаю какое отношение имеет препроцессор к тому, что я писал ниже.Ну возьми ты и запусти препроцессор от С, если не веришь, что они одинаковые.Да хоть М4, хоть паскалевский.Тот-же GCC позволяет начать сборку с любой стадии, в том числе и минуя препроцессор.Кстати в GCC входит как компилятор С++, так и С, а препроцессор имим юзается один и тот-же. А вообще трудно спорить с людьми, которые С++ в глаза не видели, а только бросаются голословными утверждениями.
для 25. Раскажи мне сказку про GCC ( Gnu C Compiler ) и каким боком здесь бродит `/usr/bin/c++` вместе с `/usr/bin/cc`
похоже что даже разные концепции языков тебя не пугают... а насчет примера
использования объектно ориентированого подхода в написании програм
советую поюзать GTK+ реализация полностью на `С` исходники и посмотри на способы реализации...
ну если ты неможеш представить как на `C` реализовать множественное наследование
и реализацию обыектов то спецально для `C++` есть GTK--
И вообще асоциация ( С++ & Bilder = `глюкало` ), А чего ждать от Delpfi for Linux подумать страшно.
sicke(*)
Суть не в конкретной реализации.
Неужто не понятно, что borland пытается рализовать сам принцип RAD.
Думаю ты не будеш спорить что ЭТО хорошо?
А вот конкретный подход, он у всех разный.
Под виндой помоему нету лучшего инструмента чем Delphi.
Производительность кодов компиленых VC и Delphi, идентична.
Было проверено на туче алгоритмов обработки изображений.
Посему, не надо ломать копья по поводу языка за который это
зацеплено, главное прецедент.
Всегда найдутся те кто напишет лучше и удобней
(под виндой не нашлось, а жаль).
Dragon
gcc,cc,c++ это все драйвера (не путать с ядровыми драйверами).Драйвером в среде разработки называется программа, которую ты напускаешь на текст, и получаешь последовательность запусков различных компонент.В нашем случае это препроцессор, компилятор, линкер.Так вот у сс и у с++ различается компилер, но не препроцессор.
Теперь насчет реализации объектно ориентированного приложения на С :)
Всегда можно левой ногой правое ухо почесать, но непонятно зачем это делать.Я надеюсь ты знаешь что такое таблица виртуальных функций ?
Вот простейший пример:
Для того что-бы создать метод в С (а у объекта должны быть методы) тебе придется пихать в структуру указатель на функцию, что по сути представляет собой виртуальную функцию.В результате в конечном коде доступ в эту функцию будет через разыменованный указатель, тогда как в С++ простой метод линковщик напрямую свяжет.Это к вопросу о том, что С++ эффективнее для написания ОО программ.Ну а о том, что это просто удобнее и быстрее я думаю никто спорить не будет.А в униховом ядре из ООП используются только виртуальные методы (например метод mount'a в объекте, представляющем собой fs ).Такие методы реализуются что в С что в С++ с одинаковой эффективностью,за исключением дополнительного this'a в С++.
Но мы с тобой несколько отдалились от нашего спора. Я попытался описать ту область, в которой С++ применяется гораздо эффективнее С, а ты в ответ сказал мне что теперь понятно, почему я не знаю ничего про препроцессор.Поэтому я второй раз прошу тебя объяснить мне, при чем тут препроцессор, и из чего ты заключил, что программисты на С++ про него ничего не знают.Со своей стороны я обещаю объяснить тебе, почему именно ТЫ не понимаешь зачем нужен препроцессор и какого его место в сборке независимо от языка.
P.S. Кстати говоря С являет собой лишь подмножество языка С++, и за очень редким исключением (это касается в основном только синтаксиса объявлений и тому подобных не имеющих отношения к парадигме штучек)
программа на С прекрасно соберется С++ оболочкой. Может это тебя вразумит..
P.P.S. Огромный сорри за оффтопик.Я сам не люблю паскаль, и надо признаться все это не имеет никакого отношения к DELPHI под LINUX/ Просто меня покоробила эта уверенность, с котрой люди говорят о вещах, о которых имеют слабое представление.
Linux может развиваться только силами его пользователей. Количество
его пользователей за последнее время выросло очень сильно, но это
люди, воспитанные в Windows. К идеологии Linux/UNIX, его традициям,
его средствам разработки эти люди относятся с презрением ("тяжкое
наследие"). Смотрите раздел документации на этом сервере - за вычетом
CVS вся документация о том, как "юзать". Какое будущее ждет Linux в
ближайшее время, предположить нетрудно...
Линуху для того чтоб выжить таки нужны такие продукты иначе все
кончеться весьма плачевно,бум бумом но, он не может долго продолжаться
без серьезной поддержки со стороны производителей ПО вооще и без
производителей Виндовского ПО в часности, потому шо как тут верно
подметили большенство народу попало в Линух из Виндов и щас их
становится все больше хотя я лично считаю что IMHO такой подход
не верен надо жить по законам операционки а не подстраивать ее
под свои, часто не верные представления, что называется "в чужой
монастырь..." и прстой порт Виндозной Делфы в Линух не приведет ни
к чему хорошему здесь должен быть другой подход, нужны продукты для
которых Линух будет РОДНОЙ ОС то есть создавать их надоть с нуля не
заботясь о совместимости и похожести эт будет рулез тода у Линуха
будет свое лицо мож даже поприятней той козьей морды которую
показывает нам M$ :) но я повторяю эт лично мое мнение и прошу сильно
не пинать, если не согласны. А что касается вероятности превращения
Линуха в New Windows то конечно она существует и чем популярней Линух
будет тем больше будет эта вероятность. Но у Линуха в этом плане
есть огромный плюс у него много клонов так-что мне кажеться что
какой-то выбор будет всегда. В любом случае Линух уже сильно
подкаректировал представления многих на операционную систему,
гораздо меньше людей теперь смотрят на Вынь как на единсвенную
платформу и эт хорошо.
Уже 30 лет плачевно не кончается. AT&T сначала разрешали использовать
UNIX только для внутренних применений, потом передать в университеты
как non-profit. И ничего. Builderы есть и для Motif/Lesstif.
Хороший Delphi - мертвый Delphi. Кровосмешение с неполноценной расой
Windows - смерть для Linux. РАСОВАЯ ЧИСТОТА ИЛИ СМЕРТЬ!
