CBuilderX - Wenn das mal gut geht!
-
Hallo,
als Ex MS und schon des längeren überzeugter BCB-Entwickler kann ich mich leider auch nicht mit den CBX anfreunden.
Doch wie KlausB schon sagte, kann ich mir auch nicht vorstellen
das unser Anliegen, das der BCB weitergeführt wird
Borland's Management ansatzweise kratzt.Also ich wäre auch dabei Gegenwehr zu zeigen.
-
Ein Versuch sollte ja nicht schaden und vielleicht sind wir ja nicht die einzigen die so denken *hoff*.
-
Hi,
ich BIN AUCH DABEI!Alexander Sulfrian
*hoff*
-
Hallo
ich bin auch dabei.
Pronto451
-
Hallo Leute,
Ich habe mal einen kleinen Entwurf auf die Schnelle geschrieben, wie ich mir einen Brief vorstellen könnte (Achtet mal nicht unbedingt jetzt schon auf Kommas, Rechtschreibung und Formatierung). Ich würde gerne mal eure Meinung dazu hören:
Sehr geehrte Damen und Herren,
In ewig langen Stunden, in denen ich mich mit der Programmierung, speziell C++, auseinandergesetzt habe, habe ich schon viele C++- Entwicklungsumgebungen angetestet und auf deren Grenzen erprobt. Besonders der C++- Builder 1 hatte es mir mit seiner VCL damals besonders angetan. Ich bin nun soweit fortgeschritten, dass ich auf andere C++- Entwicklungsumgebungen vollständig verzichte und mich auf den C++ Builder spezialisiert habe. Derzeit arbeite ich mit ihrer sechsten Version des C++ Builders und bin weiterhin begeistert, mit welcher Leichtigkeit und mit welch geringem Zeitaufwand sich Software damit professionell entwickeln lässt. Leider musste ich nun erfahren, dass der C++ Builder in seiner jetzigen Art und Weise nicht mehr weiterentwickelt werden soll. Ferner habe ich von seinem Nachfolger C++ BuilderX Informationen gesammelt und finde die Idee, die hinter diesem Projekt steht nicht falsch. Dennoch musste ich erfahren, dass diese Version des C++ Builders keine VCL mehr unterstützen wird, sondern komplett auf wsWidgets basiert. Nun war jedoch gerade die VCL in der Vergangenheit der Grund, der mich und weltweit viele weitere Programmierer an die Firma Borland gefesselt hatten. wsWidgets wird viele Programmierer, darunter auch mich, verwirren und eventuell dazu zwingen, zu anderen Firmen überzulaufen. Weiter habe ich noch von vielen anderen bedeutenden Fehlern, die sowohl ihre neue Software, als auch ihre neuen Strategien betreffen gehört. Leider muss man sagen, dass die Firma Borland die Fehler anderer Großunternehmen begeht und unausgereifte Software auf den empfindlichen Markt wirft und bewehrte Entwicklungen vernachlässigt. Ich glaube in dem Namen vieler zu sprechen, wenn ich sage, dass sie den „Standart- C++ Builder“ nicht aufgeben sollten oder zumindest auch die zukünftigen Entwicklungssysteme an die beliebte VCL anpassen sollten. Mir ist bewusst, dass dieser Brief in einem Unternehmen wie Borland nicht viel ausrichten kann. Sie sollten dennoch nicht nur auf den Markt, sondern auch auf die Leute, die den Markt bestimmen und ihre Entwicklungsumgebungen nutzen, berücksichtigen. Sonst könnte das Großprojekt C++ BuilderX zu einem sehr großen Flop werden. Aus Insiderberichten und einigen anderen Quellen wissen sowohl sie, als auch ich und viele weitere Entwickler, dass die Firma Borland einen weiteren Flop und damit verbunden riesige Kosten nicht verkraften wird und sogar das Aus und der Bankrott droht. Ein Unternehmen, welches sich vollständig auf Entwicklungsumgebungen spezialisiert hat, kann nicht überleben, indem es andere Firmen, die zusätzliche Standbeine besitzt, kopiert, sondern muss seine Kunden durch besondere Eigenschaften und Fähigkeiten der Entwicklungsumgebungen gewinnen, begeistern und als zukünftige Kunden halten. Borland hat dies mit der VCL und einigen weiteren intelligenten Entwicklungen in der Vergangenheit erfolgreich bewiesen. Gerade aus diesem Grund ist es unverständlich warum das Unternehmen seine Strategie, meiner Meinung nach zum Negativen hin, ändert. Sie sollten ihre Strategie noch einmal überdenken und mit ihren amerikanischen Kollegen reden. Eine Möglichkeit, die meine Einschätzung als korrekt oder aber auch als falsch erweisen könnte, wäre eine breitgefächerte, aber einfache Umfrage auf den Borland- Internetseiten weltweit. Sie sollten ihre Kunden nicht verwirren, sondern klare Standpunkte präsentieren, die die Entscheidung ihrer Kunden, Borland treu zu bleiben, erleichtern könnten.
Hochachtungsvoll,
Absender
Meiner Meinung nach könnte jeder in der Richtung einen Brief basteln und dann in einer gemeinsamen Aktion an Borland senden.
Euer Entertainer
-
Ja, bin dabei
-
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
-
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
-
Nach unseren Erfahrungen nutzen mehr als 80% der BCB- Entwickler die Spracheigenschaften von C++ nicht
-
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
-
-
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
-
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