CBuilderX - Wenn das mal gut geht!

Ja, bin dabei

tuxman

ich auch

Hallo Zusammen,

ich finde die Idee der Postaktion an Borland sehr gut! Allerdings wäre es nicht schlecht, wenn diese Aktion koordiniert würde. Zunächst sollte dieser Beitrag ebenso wie die Infos zum Builder X immer an der vordersten Stelle im Forum stehen. Weiterhin wäre es nicht schlecht wenn dort ein Voting vorhanden wäre, bei dem jeder eine Stimme abgibt, der sich an der Aktion beteiligt.

Wenn genug 'Teilnehmer' vorhanden sind, dann sollten die Briefe abgesandt werden. Wobei ich der Auffassung bin, dass jeder selbst ein Schreiben verfassen sollte.

Wäre dies mit der Platzierung möglich?

Gruß Torsten

VolkerH

Hallo,
ich möchte Euch ja nicht den Mut und Elan nehmen, aber glaubt Ihr den wirklich, wenn hier in Europa ein paar Programmierer meinen, irgendwelche Briefaktionen zu starten, wird das in Amerika, und nur da wird die Borland- Politik gemacht, irgendetwas bewirken. Als Anhänger der Chaos- Theorie glaube ich zwar, dass es in New York regnen kann, wenn in Singapur ein Schmetterling mit den Flügeln schlägt, aber da geht es um Naturgesetze.

Völlig unbemerkt ist übrigens die Version 1.5 des C++ Builder X erschienen, allerdings, und das ist bestimmt für viele enttäuschend, nur in der "Mobile Edition". Dort allerdings mit RAD. Wenn man dieses positiv beleuchten möchte, dann nehmen wir es doch als Beleg dafür, dass die Entwicklung weitergeht. Das hat auch nichts mit Nadelstreifen oder echten Programmierern zu tun. Das gerade hier der "Zukunftsmarkt" liegt, ist ja, wenn man Studien von Gardner oder IDC liest, kein Geheimnis. Ich bin sicher, es wird auch bald die CBX- Version 2 geben, dann mit RAD- Features und einem neuen Compiler für die Intel- Plattform. Aber da sind wir beim Thema, das wirkliche Problem von Borland ist doch die schlechte Informationspoltik. Als Entwickler müssen wir planen und Investionen rechtfertigen, wenn wir aber keine Roadmap für den Compiler haben, kann man die Verantwortlichen schlecht überzeugen. Und das ist das ärgerliche. Und die fehlenden Informationen sind auch der Nährboden für Gerüchte, wie der Spruch mit Nadelstreifen und Programmierern. Wenn der jetzige CEO nicht die vielen Fehlentscheidungen der Inprise- Zeit koorigieren würde, gebe es Borland heute nicht mehr, und zu diesen Entscheidungen gehörte auch die Einstellung der eigenen C++ Entwicklung und die Verbindung von C++ mit dem Verkaufsschlager Delphi.

Die Diskussion gab es ja schon oft, aber trotzdem noch einmal einige nüchterne Fakten. Die Programmiersprache C++ hat 2001 einen Marktanteil an Programmiersprachen von über 30%, bei der Anzahl der vielen Sprachen, beachtlich. Damit ist es auch die mit Abstand größte Entwicklergruppe. Zwar scheinen C# und Java dieses anzugreifen, aber selbst Microsoft oder SUN entwickeln Betriebssysteme und Office- Produkte wohl kaum mit C# und JAVA, durch Marketing versucht man nur die Kunden dazu zu "überreden". Aber zurück zu C++, der Windows- Entwicklermarkt macht hier ungefähr 25% aus, daran wird sich strategisch auch in den nächsten 3 Jahren nicht viel ändern. Fast die Hälfte des kommerziellen Marktes ist im Unix/Linux- Umfeld, wobei man hier eine Verschiebung in Richtung Linux beobachten kann. Im Windows- Bereich hat Borland schätzungsweise einen Anteil von 30%, allerdings nutzen davon noch einige die alten C++ Compiler, aber auch hier sind GNU- Compiler auf dem Vormarsch. Der BCB erzeugt eine Abhängigkeit von Windows, die Experimente rund um Kylix haben sich nicht durchsetzen können. Außerdem gibt es hier auch noch die Unsicherheit .net, die schwer zu kalkulieren ist. Durch den Builder hat man sich vor 6 Jahren strategisch (und das war bestimmt keine durchdachte Entscheidung von Entwicklern, sondern eher von Nadelstreifen) aus dem allgemeinen Fahrwasser herausbegeben, und sich an Delphi gehängt. Das heisst, man konnte nie aus dem Fahrwasser von Delphi herauskommen. Dummerweise hat aber C++ gerade Mitte der neunziger wichtige Weiterentwicklungen gemacht, die so nur schwierig nachzuvollziehen waren. Damit stellen sich doch aber eine Reihe von Fragen. Welche Rechtfertigung hat C++ in einem VCL- Umfeld, kann es nicht in einem reinen C++ Framework auch RAD geben? Ich denke ja, und es gibt Klassenbibliotheken, die mit der VCL nicht nur mithalten, sondern leistungsfähiger sind. Und ich bin überzeugt, wenn Borland das KnowHow in die Weiterentwicklung von C++- Komponenten steckt, dann gibt es auch eine Zukunft für den Builder X. Wäre es für Nadelstreifen nicht besser gewesen, einfach weiter mit dem BCB geldzuverdienen? Stattdessen investiert man, geht Imagerisiken ein, um ein neuen Produkt zu schaffen, gibt indirekt strategische Fehler zu. Ich denke, die diese Entscheidungen gefällt haben, wussten ganz genau, was sie machen. Nur sind wir da auch wieder bei dem Thema Informationspolitik, warum gibt es keine Roadmap, keine White Papers, ....

Vielleicht wird Borland den BCB6 weiterentwickeln, vielleicht nicht. Aber seit vielen Jahren wird gelehrt, sich nicht von einem Hersteller abhängig zu machen (und auch nicht von einer Plattform). Wenn es dann doch passiert ist, dann haben die Entwickler einen Fehler gemacht, die Sprache C++ bietet alle Möglichkeiten, dieses bei einer geschickten Architektur zu verhindern. Nur geht das nicht mit "click and dirty", man muss sich vorher hinsetzen. Es ist auch kein Geheimnis, dass C++ die höchsten Anforderungen an die Qualifikation der Entwickler stellt, es ist eben keine Sprache wie Visual Basic oder auch Delphi, auch wenn viele BCB- Entwickler es so sehen. Nach unseren Erfahrungen nutzen mehr als 80% der BCB- Entwickler die Spracheigenschaften von C++ nicht, könnten also problemlos auf Delphi umsteigen. Also denke ich, dieser Sturm geht in die falsche Richtung, jeder muss sich an die eigene Nase fassen. Die Programmierung entwickelt sich stetig weiter, und man sollte immer zusehen, sich nicht zu sehr an einen Rand zu begeben. Wenn man dann doch auf dem Trockenen liegt, weil es eine Veränderung gegeben hat, sollten sich doch alle Bemühungen darauf richten, wieder ins tiefere Fahrwasser zu kommen, anstatt zu schimpfen, warum sich die Bedingungen geändert haben, die man nicht beeinflussen kann, und darauf zu warten, dass das Wasser vielleicht doch wieder zurückkommt. Vielleicht sollte man eher einen Thread aufmachen, indem Erfahrungen ausgetauscht werden, wie man Code vom BCB zum CBX portiert, wo Neuigkeiten und Erfahrungen ausgetauscht werden, und nicht, in dem Unzufriedensheitsbekundungen gestreut werden.

Schöne Grüße aus Berlin

Volker

Peter

Nach unseren Erfahrungen nutzen mehr als 80% der BCB- Entwickler die Spracheigenschaften von C++ nicht

dschensky

VolkerH schrieb:

Vielleicht sollte man eher einen Thread aufmachen, indem Erfahrungen ausgetauscht werden, wie man Code vom BCB zum CBX portiert, wo Neuigkeiten und Erfahrungen ausgetauscht werden

... womit wir wieder beim Thema Informations-Politik währen, denn genau das sollte ein renomiertes Unternehmen wie Borland nicht einer im dunkeln tappenden Community aufbürden.
Aber trotzdem ist der Versuch, etwas Konstruktives in die Diskussion zu bringen, lobenswert.

(Apropos "konstruktiv": Wir könnten irgend einen bescheuerten Flash-Mob vor der Borland-Zentrale initiieren. Das schreckt mehr auf, als eine müde Unterschriften-Aktion ... naja, vielleicht auch nicht ... )

Das Problem ist nur, dass nicht jeder einfach mal eben zur Borland- Zentrale kommen kann, um einen Flash-Mob durchführen zu können.

Entertainer

KlausB

Hallo

@VolkerH
laut Borland soll CBX 2.0 im Herbst rauskommen

MfG
Klaus

Wir wollen jetzt in eine C++ Entwicklungsumgebung investieren, mit der auch ab Mitte des Jahres kommerzielle Programme (Industrielle Bildverarbeitung) unter Windows entwickelt bzw. von DOS portiert werden sollen.
Eigentlich war klar, dass die neueste BCB Version gekauft wird. Aber jetzt ist auf einmal der CBX da und BCB "läuft aus". In welchen sauren Apfel sollen wir denn jetzt beißen: BCB6 kaufen und mit einem ausgereiften System entwickeln und dann in 2-3 Jahren wieder portieren oder mit dem jetzt verfügbaren CBX 1.0 einsteigen und uns mit all den Kinderkrankheiten rumschlagen ?
Was raten einem die Leute, die tiefer in der Materie stecken ?
Auf was wäre zu achten, wenn jetzt noch der BCB6 zum Einsatz kommt in Hinblick auf eine zwangsläufige Portierung, wenn der CBX als 2.0 oder 3.0 ausgereifter ist.
Würde mich über hilfreiche Antworten freuen.

Jürgen

VolkerH

Hallo Klaus,
ich habe auch Gerüchte gehört, dass es im September den neuen CBX 2 geben soll, aber ich bin mir nicht sicher, wie verläßlich diese Quellen sind, außerdem ist es noch weit bis September, da kann einiges passieren. Klaus, wenn Du eine sichere Quelle hast, wäre ich Dir dankbar. Jedenfalls denke ich, wir können alle gespannt sein, und wenn es wirklich den 64-bit Compiler gibt, über den seit Monaten getuschelt wird, wäre das ein gigantischer Schritt nach vorne.

Hall beridoxus,
die Entscheidung ist immer noch schwierig, und hängt sicherlich vom Einzelfall ab. Ich würde zum jetzigen Zeitpunkt in einem normalen Entwicklungsprojekt nicht unbedingt den CBX empfehlen, allerdings können gerade im Bereich der Bildverarbeitung die bisherigen Nachteile des CBX nicht so gravierend sein. Wir haben mal ein sehr grafisch, oberflächenlastiges Programmbeispiel für einen Kunden implementiert, in dem erst die VCL verwendet wurde, im anderen Fall dann direkt die Windows- API. Dabei haben wir die Methoden 1:1 umgesetzt, damit das ganze vergleichbar bleibt. Der Unterschied war gewaltig, gerade wenn mit normalen Zeichnungsobjekten gearbeitet wird, ist die VCL ein Nachteil. Hier wird eine, wie auch immer geartete Lösung (sei es nun wxWindows oder API) sicher besser sein.

Aber eigentlich ist die Entscheidung nicht so schwerwiegend, wie sie sich in diesen Diskussionen darstellt. Er trifft sogar den Kern, des Problems, inwieweit mache ich mich vom Framework, und damit von einem Hersteller abhängig. Wir empfehlen unseren Kunden auch bei neuen Projekten noch den BCB6 einzusetzen, aber durch eine saubere Anwendungsarchitektur sicherzustellen, dass der Portierungsaufwand auf jedes andere Framework unter 20% liegt und das geht. Allerdings ist der Aufwand am Anfang etwas höher. Dann habe ich auch in einigen Monaten noch die Freiheit, strategische Entscheidung bezüglich des Compilers und der Plattform zu treffen.

Hier ist der Quelltext einer unserer Funktionen, die ein Listview bestückt, dabei ist es für die Bearbeitungsfunktion uninteressant, ob dahinter die VCL steckt. Genauso gut kann es sich aber auch um eine Implementierung eines StringGrids handeln, für die Business- Prozess ist das unwichtig.

void TDDProzesse::LoadAttributesList(int iTableID, TListData& data) {
   AttributeIntMap attributes;
   Reader()->Read(iTableID, attributes);

   // Lesen  der Typen
   DatabaseTypesMap theTypes;
   Reader()->Read(theTypes);

   // Aufbau der Headers
   data.ClearRows();
   data.ClearHeader();

   data.ListType(TListData::report);
   data << THeaderField("Number", TListData::Right, 50)
        << THeaderField("Database", TListData::Left, 120)
        << THeaderField("Source", TListData::Left, 120)
        << THeaderField("IsKey", TListData::Left, 50)
        << THeaderField("Type", TListData::Left, 70)
        << THeaderField("Len", TListData::Right, 50)
        << THeaderField("Scale", TListData::Right, 50)
        << THeaderField("Nullable", TListData::Right, 50);

   AttributeIntMapIterator iter = attributes.begin();
   while(iter != attributes.end()) {
      TAttribute& theAttribute = ((*iter).second);
      TDatabaseTypes const& theType =
                  TCommonTools::FindKey<TDatabaseTypes, DatabaseTypesMap, int>
                                             (theTypes, theAttribute.DbTypeID(true));

      data.Image(-1);
      data << theAttribute.AttributeNumber(true)
           << theAttribute.DbName(true)
           << theAttribute.ProgName(true)
           << (theAttribute.IsKey(true) ? "yes" : "no")
           << theType.TypeName(true)
           << theAttribute.Len(false)
           << theAttribute.Scale(false)
           << (theAttribute.IsNullable(true) ? "yes" : "no");
      data.AddRow();
      iter++;
      }
   return;
   }

Und einen C++- Programmierer zu finden, der damit Listen füllt, dürfte einfach sein, er benötigt keine Kenntnisse der VCL mehr. Und ich kann die Stream- Operatoren für alle notwendigen Datentypen definieren. Und die Implementierung gegen die VCL kann ich dann schließlich einem VCL- Freak überlassen, wenn sich etwas ändert, dann profitieren alle Programmbereiche davon. Und wenn ein Kunde jetzt sagt, er möchte das ganze für XWindows und das GTK, dann hole ich mir einen entsprechenden Experten, der mir die Ankopplung implementiert, der Aufwand ist wie bereits gesagt, gering.

Und wenn jetzt jemand kommt, und sagt, mit der VCL geht das aber einfacher, dann frage ich mich, wie das gehen soll. Und wenn jetzt der CBX zum Einsatz kommen soll, wird nur eine einzige Klasse umgeschrieben ;).

Und das ist doch das Entscheidene, man nutzt die Möglichkeiten von C++ aus, macht sich nicht abhängig und kann sich doch der Magie des Borland Builders bedienen. Und auch da gibt es nichts gegen zu sagen, die RAD- Fähigkeiten des C++ Builders sind ausgezeichnet, also warum sollte ich mich dieser nicht bedienen. Also ist es auch nicht schlimm, mit dem BCB6 zu starten, vorausgesetzt, man programmiert mit diesem auch C++ und nicht VCL.

Schöne Grüße aus Berlin

Volker