Kylix

po moyemu viydet ne c++ a klon c++ buildera i delphi kotoriy budet nazivatsya (mojet byt) kylix.

Вот еще один стандарт :)

А оно это нужно, чтобы появился еще один компилятор для С и еще со своими библиотеками. Хотя борландовские продукты обычно довольно качественные. Хорошо только то, что крупная корпорация сможет свои же стандарты поддерживать хорошо.

А мне нравится Borland C++,А на Delphi/C++Builder удобно писать GUI. Так что это хорошая новость. Плохая новость - всё это будет стоить $, а воровать я уже отвык.

Багланд как был отстоем, так и в линухе отстоем останется. Так что ничего хорошего в этой новости нет - только грустно, что сразу после появления этого глюкала наплодят ламухи непортабельного дерьма, а другие ламухи его натолкают в дистрибутивы. И все, Linux Is Not UniX...

А разве можно предположить другое после покупки Corel'om Inprise'a. И Delphi тоже будет, без сомнений. А потом выйдет Сorel Linux и Word Perfect Office, и Delphi, собранные на Borland C/C++.

To vsl: Зря ты так. Под линух не хватает GUI. А Borland предоставит возможность писать без особых затрат, пусть не всегда качественный, но нужный софт! Поддерживаю эту идею!

######!!!!!!
Borland никогда не был отстоем!!! Это один из немногочисленных продуктов, которые были написаны под мелкомягкого!
До сих пор иногда запускаю bcpp 2.0, чтобы написать нужную утилитку, если они приживутся под linux- я всеми конечностями ЗА!!!
_____________________________
Все проблемы от кривости рук!!!

А кто вам говорит про средство разработки интерфейсов ? Это компилятор, а не оболочка. Такой же, как и gcc. И это хорошо, потому, как кроме gcc + libc + stdc++ под линухом больше ничего нету (по крайней мере фришного, а этот судя по статье будет фришный).

C++Builder - eto (v osnovnom) lish sreda razrabotki, toest' tam mozhno pisat' C/C++ kod, risovat' knopochki, okoshki i drygie pribambasiki, no real'no vse eto zatem kompiliryetsja kompiljatorom i ja ne ponimau o chem tyt vobsche razgovor? Esli vas ne ystraivaet gcc, eto odno, a esli sreda razrabotki, to eto sovsem drygoe. Konechno bcc i gcc - ne polnost'u sovmestimi, no ved' na yrovne ANSI standartov na C/C++ oni prakticheski identichni i bcc daleko ne lider, kak eto bilo v DOS. No kto vam skazal, chto borland bydet rasprostranjat' svou prodykciu bez ogranichenij na ee ispol'zovanie? Osobenno interesna licenzija na biblioteki. Mne kak-to ne ochen' ponjaten ves' etot azhiotazh vokryg vse esche pishyschejsja, prakticheski s nylja, sistemi. Chto mi o nej vobsche znaem, krome togo, chto pishyt eto bravie rebjata iz Borland? Esche interesno, kto chego znaet pro analogichnie, no pod GPL sistemi razrabotki? I vobsche, davajte po syte, a to odin flame, a nikakih razgovorov o samom bcc ja poka ne videl. Kto-to tyt ego yzhe proboval, s GNU analogami sravnival?

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

Да ну? Я видел, и даже иногда пользовал все их продукты, начиная с Turbo Pascal 1.0 под MSX-1. Собственно, этот турбопаскаль и был последним их относительно качественным продуктом (и то - на Ямахе не было альтернатив). А все остальное было писано явно не руками, и думали они при этом, очевидно, не головой. И тащить эту муть в приближенный к Юниксам мир - просто преступление. Там и так уже, благодаря излишней популярности линюха, слишком много глюкалок расплодилось.

Так я не понял - вам еще один компилятор, еще более глючный, чем GCC, да еще и одноплатформенный нужен, или же так называемая "среда разработки", которую лицемеры из Багланда еще имеют наглость называть словом RAD? Или все же лучше забыть о своих досячьих привычках (которые лучше было и не приобретать), и использовать настоящие RAD?

А что такое "настоящий RAD"(с URL,please - действительно интересно). Вообще же насчёт Borland C++ 5 с библиотеками - видимо, там будет OWL(lib такая для GUI) а потом всё это войдет в kylix - порт Delphi/C++Builder'а на Linux. А вообще хорошо бы увидеть действительно free(или GPL,на худой конец) RAD над С++(gcc) типа С++Builder'а

Вообще, никаких проблем - чем больше soft'а, тем лучше - а люди уж потом сами выберут. Да и то сказать - чем больше такого soft'a, тем легче Linux использовать как desktop OS, тем лучше нам - программерам.

Блин - Corel купил Inprise ????? Это откуда, кто сказал???

Покопайся в архивах новостей-узнаешь кто сказал.

Настоящий RAD? Будешь смеяться, но на http://www.scriptics.com/ Или же на http://cristal.inria.fr/ или в Inferno, или эти IBM-ерские Smalltalk-среды. Но только не багланд с такими непредназначенными для RAD языками, как C++ и Object Pascal. Так как настоящ RAD должен иметь систему модулей (жесткую, на уровне языка), систему документирования интерфейсов модулей, и, крайне желательно, систему литературного документирования кода. Это все - минимальные требования, на самом деле есть еще много других. А вообще - Самого Настоящего RAD в природе и не существует ;)

Чем больше софта "второй свежести", тем ниже становится уровень самой ОС, тем ниже становятся запросы жвачных потребителей, и тем ленивее и безмозглее становятся программеры. Так что ничгео хорошего нет, один только вред.

Зря ты так: чем больше софта, тем лучше для ОС (тем популярней она станет). И ОС дерьмовым софтом не испортишь. Дерьмовый софт должен отсеить Рынок (когда в данном сегменте рынка появятся конкуренты). А насчет того, что у них выйдет - я тоже сильно сомневаюсь - нет в borland'e таких хороших архитекторов, хотя программеры вроде более менее (на фоне остальных из мира окон). Да и вообще, направление borland спорно - они свою delphi позиционировали 5 лет назад, когда она только выходила на рынок, как быструю (по скорости выполнения кода) альтернативу скриптам типа VB. C сегодняшними камнями это не актуально - надо использовать скрипты (только проблема с пиратами и конкурентами, которые подсмотрят/возьмут код скрипта). Чего-то и здесь флеймом запахло (с твоей помощью, однако).

Не люблю я писать в такие обсуждеения, но тут всецело за vsl ... И так у нас GNOME/Motiff/QT/FLTK - выбор конечно есть ... а что нельзя нечто лучшее и межплатформенное сделать ? А этот Builder если он будет - будет только для Linux/Win32 и все ... к тому же C++ Builder 4.0 на 486 точно не пашет, а возможностей по сравнению с Builder 1.0 - кот наплакал ... А то, что написанные на нем приложения и больше и медленнее и глюки имеют вы сами знаете ... Вот bcc компилятор может быть и нужен для альтернативы ... Главное что хочу сказать - боюсь, что с появлением этого так называемого RAD под Linux-ом исчезнут качественные, быстрые, небольшие, переносимые (хотя бы на другие Unix) программы !!! И тогда Linux Is Not UniX !!! Подумайте над этим ...

"А вообще хорошо бы увидеть действительно free(или GPL,на худой конец) RAD над С++(gcc) типа С++Builder'а" - krepkaja fraza, srazy viden yroven' sporjaschego :-)))))

MS, похоже, окончательно выдавил Borland с рынка. Вот и цепляются несчастные за что попало. Под DOS и частично под Windows BC был неплох - однако здесь у него нет шансов, в особеннлсти с такой дрянью как Delphi и Builder. Прощай Borland :((

Как уже говорили здесь ранее - C++ Builder для Linux это хорошо, с одной точки зрения - можно будет не переучиваться с Windows и делать нормальные, законченные приложения для предприятия, узкого назначения. Естественно, с переносимостью будут проблемы, и ой какие. Но для УЗКИХ задач - Builder всегда был намного лучше и удобнее, чем VCPP, да и скорость разработки, для такого круга задач очень высока. (Кто скажет что это не правда?) Т.е. даешь бесплатную корпоративную среду бесплатно с быстрыми средствами разработки. А с другой стороны, для Linux в целом это действительно опасно, может вполне сложится ситуация, когда Linux will not be Linux, а это очень плохо.

А что, неужели невозможно написать RAD над ANSI C++ (+Xlib,естественно) ? Ведь большинство языковых изменений в ВС++Builder сделаны для совместимости с Object Pascal (т.е. с VCL). Как-нибудь сделать аналог properties через,например, template ; вместо Билдеровских "параметров-методов в неизвестно каком классе"-closure-какой нибудь хитрый способ обработки событий, библиотеку попроще - и,пожалуй, все что надо для этого? А что я не то сказал про free или GPL RAD - так и не понял.

Вообще-то этот Builder давно ожидаем. Ведь ни в одном нынешнем СДК нет даже примитивного генератора отчетов...

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

А насчет GUI - так что, ничего более нет?
Мне вот например gtk нравится, а с его контейнерами никакой RAD
не нужен..

Ну насчет генератора - perl+tex вполне сойдет, (правда, и то, и другое изучить придется) - я их в своем коммерческом софте использую. А насчет RAD - для gtk есть glade (+libglade), GIDE (не пробовал); для QT есть KDevelop (не пробовал) - но для QT надо брать лицензию за 1500$ для неGNUшного софта. Если до портабельного софта - то WxWindos (или что-то начинающееся с Wx), да и gtk скоро хорошо будет идти под Win32 и Beos. Но для внутреннего пользования внутри конторы (т.е. не для продажи) tk или gtkperl - вроде как лучше всего. Короче, использование Builder для linux для чего-нибудь отличного от портирования бессмысленно так как есть дохрена ide/widgetsets которые более продуманы, мощны и портабельны.

На Ansi C++ RAD быть не может в принципе. Достало уже это повторять. Для RAD нужна мощная система МОДУЛЕЙ, а не эти дурацкие объекты.

2hvv: RAD это не рисовалка ГУЙни!!! Так что я не понял, к чему все эти базары про виджеты.

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

Заявление от невозможности существования RAD для ANSI C++ голословно (равно как и о возможности). Вы не привели свои аргументы. Что же такое RAD если это не рисовалка GUI? Это что, рисование мышкой алгоритма программы? В любом случае, для unix'а есть все в этом отношении (в смысле, продукты). Даже если этого нет для linux, это там скоро будет. Ну а на худой конец - этот софт есть для соляриса, берем солярис (который будет бесплатным через несколько недель) и пишем для него.

Да я к тому, что это будет работать на других Linux'ax с огромным гемороем. Если вообще будет.

Мне приходят мысли, что этой единственной платформой будет Corel Linux ...

RAD = Rapid Application Development. То есть, построение прототипа прикладухи из набора тяжелых готовых реюзабельных компонент, коих надо наготовить на все случаи жизни. Рисование ГУЙни - самая мелкая и простенькая задачка, и как правило от RAD этого и не требуется. От RAD требуется хорошей модульности (для организации действительно реюзабельных компонент), назязанного единого средства документирования (и, желательно, автодокументирования) интерфейсов модуля. В Дельфях и тем более в Билдере модульность просто омерзительна, и компоненты деляются абы как, и обычно через Альпы. Так что не RAD это. Для RAD особые языки нужны. Вот Оберон подошел бы, или Smalltalk. С натяжкой Java...

vsl! Вообще говоря,объектное программирование, исторически, развивалось как следующий шаг - логическое продолжение - модульного. По идее,модуль предоставляет средства для надежного и легко осуществляемого разделения интерфейса и реализации. Объекты дают все это и,кроме того,наследование/полиморфизм и т.п. Так что любой объектный язык имеет модули(точнее,модульность!) "по умолчанию" ! А то,что Delphi объектный, а С++ один из лучших в этом отношении языков - Я думаю, Вам известно. (конечно *.сс + *.h для модуля неудобно, но это ведь непринципиально!)

Не как дальнейшее развитие, а как безмозглое извращение. Смысла в объектных средствах этих дурацких императивных недоязычков (Object Pascal и C++) - просто ни на копейку нет. Нормальные модули тоже имеют всякие там наследования, полиморфизм, и т.д. Попробуй, изобрази на механизме классов функторы? Слабо? То то же. А в нормальных модульных функциональных языках - запросто.

P.S. ООП - вообще религия, а ООПники - сектанты. Я давно уже понял, что их ни в чем невозможно убедить - они уперлись, как бараны, и на Бучей своих молятся истово. Достали, блин....

To vsl: помнишь, как ты тут сознался, что ты не программист? Ты бы хоть для приличия "IMO" прибавлял ко всем своим речам - а то они очень смешно выглядят.

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

P.S. И еще - про функторы слабо ответить, или как? Если сможешь изобразить нечто подобное на C++ или Дельфи - возьму свои слова про ублюдочность механизма классов по сравнению с нормальной модульностью обратно.

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

Короче, функтор - это функция, параметром которой является модуль, и возвращает она тоже модуль. Это позволяет определять общего вида модули, и производить из них конкретные реализации. В C++ жалкое подобие этого механизма называется template. Механизм наследования классов - это малость не то, так как позволяет сильно извратить первоначальный интерфейс.

Ну а про то, что математики больших систем не пишут - лучше не надо гнать. Достаточно вспомнить TeX, CERNlib, gsl, Objectivity, LHC++, всяческие там CAD-ы в огромном количестве, CAE к ним же. Никакой "профессиональный программист" этого не напишет.

Для затравки рекомендую почитать замечательные лекции по этому адресу: http://www.cl.cam.ac.uk/Teaching/Lectures/funprog-jrh-1996/index.html Так, чисто для общего развития, дабы не было желания слишком сильно хвалить идиотские ООПные императивные язычки.

Ты сам сказал, что наследование может помочь реализации функторов. Ты сам дал ответ. А что значат твои слова о "малость не то, так как позволяет сильно извратить первоначальный интерфейс" - я не понял (но очень похоже на чушь). А насчет математиков и дворников - так ты спрашивай тех, которые пишут софт такого размера, а не простых математиков. И кстати, в новостях ссылка на интервью с Bjarne Stroutstrup'ом- полезно почитать. Там он пишет о примении С++ для разработки ОС в частности; про ООП и его применимость. А ты, vsl, законченный идеалист - ты видишь либо черное, либо белое, и решение, на 1% хуже идеального ты считаешь тоже дерьмом.

Правильно, я идеалист. Так как информационные технологии - единственная прикладная область, где идеалы достижимы ;) Ну а про наследование: функтор можно применить к _ЛЮБОМУ_ модулю, лишь бы тип совпадал. А наследование идет только от одного конкретного типа. И это портит всю малину.

А у Страуса мне весьма понравилось: "Well. It was obvious to me 20-some years ago that OOP wasn't a panacea". Ему бы еще дальше пойти, и понять, что это вообще не метод, а просто игрушка, путь и популярная/разрекламированная. Серьезных дел на этом не наворотить.

Не надо путать профессиональных программистов с фундаментальным математическим образованием и математиков. Ты бы еще физиков спросил, ведь любой профессиональный программер еще и физику учит в институте. А как ты пишешь про это статьи, если ты не программер ? Насколько я понимаю, вопрос тут идет о скорости разработки, легкости сопровождения и других практичных вещах. Ведь вы тут не об алгоритмах спорите. О каких математиках идет речь ? Помочь здесь может только практический программер. А то получается пришел математик и впаривает людям, которые пишут программы свою концепцию их написания со словами "Вы тут все дебилы. Вот так надо !". По моему естественный отбор сделает/сделал свое дело. То, что удобно программистам, то и пользуется популярностью. Ну а отдельные индивидумы, у которых мозги не так устроены в любой области найдутся. А насчет функторов (слово-то какое математическое)... чем же вам шаблоны не угодили ? Чье это жалкое подобие ? Теоретического определения "функтора" ? И почему жалкое ? Только пожалуйста ответь - очень хочется узнать про недостатки "ООПных императивных язычков".

Насколько я понял из написанного определения, функторы можно написать на какой-нибудь вещи, поддерживающей динамические интерфейсы, что-то вроде есть в COM и в Corba(хотя я не уверен) а еще проще это сделать на каких-нибудь развитых интерпретаторах. А вообще, не стоит путать мысль условно говоря "научную" и "инженерную" : как организовать программу - задача, аналогичная "как построить дом". Я думаю, любой архитектор поймёт объектное программирование, хотя применить,может, и не получится. А интересно, как построена сама математика - "объектно или модульно или третье" - я и сам "почти математик", но сразу придумать не могу,может у вас есть мысли? Но, как бы там ни было, интерпретаторы - а они и только они фигурировали в вашем списке "подходящих языков"(исключая, и то с бооольшой натяжкой,Java) - ясный пень, в принципе гибче, но за это приходится и платить!(скорость и т.п.) Класс языковых задач, решение которых невозможно разбить на Compile time/Run time , а приходится оставять все на Run time как раз идеально ложится на интерпретаторы, но так ли этот класс велик? На моей практики, их !очень! мало, остальные же задачи замечательно пишутся на С/С++, и если нужно написать большую программу(построить дом), то как правило, оптимальная структура программы - как раз объектная. PS Sorry за многословность - моя сестра сегодня,кажется, в загуле.

Естественный отбор породил Дельфи и Визуал Бейсик, и легионы "программистов", пишущих на означенном отстое. Так что стыдно приводить этот отбор в пример. Подробный ответ про функторы и т.д. будет в моей статье.

P.S. Я не программист по образованию, но работаю именно как программист, так что и практические соображения имею, не только теоретические.

К дискуссии о функторах: по моему, примеры написания функторов на C++ есть в книге Джефа Элджера "C++" (библиотека программиста). Это не есть так сложно, как утверждается.

Вот спорите спорите, а про Objective C забыли... Вот где самый что ни на есть rulezz

Никаких рулезов там нет. Тот же кривой C, та же гнилая императивщина, тот же религиозно-идиотский ООП. Грустно, господа...

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

А что еще можно ответить на "XXX" rulez, кроме как "не, XXX sucks!". Уровень аргументации тот же. Сказанул человек что-то про Objective C, должно быть, просто так ляпнул, ничем кроме "рулез" не аргументировав, и получил свое. Надо было сначала прочитать, о чем речь идет, что тема "FP vs. imperative OOP", и в этом плане всякие там обжектив си абсолютно идентичны всяким там C++.