Diskussion: Der BCB / BuilderX und die Zukunft von Borland (war:Builder 7 kommt raus)
-
AndreasW schrieb:
Wenn man eine andere Plattform gewählt hat muss man das Projekt natürlich neu kompilieren. Man muss aber nicht vorher auf die andere Plattform wechseln und dort den CBX installieren und dort compileren.
Eben doch.
Man muss zwar nicht unbedingt den CBX installieren, man kann auch die reinen Source-Dateien nehmen und den jeweiligen Compiler von Hand füttern. Das aber zwingend auf der jeweiligen Zielplattform.Wie gesagt kann man schön auf einer Windowsplattform bynaries für Linux oder Solaris erzeugen usw. Das wird übrigens auch schön im Flash- Demo gezeigt.
Eben nicht.
Zitat aus dem Demo (bei ca. 50%): "Using VPN, I open up the C++BuilderX IDE, running remotely on a Linux operating System. [...] To rebuild this application for Linux, I simply choose 'Linux' from the 'Platform' dropdown." Und später das Ganze nochmal auf einem ebenfalls ferngesteuerten Solaris-System.naja, dann schnapp dir mal den UltraEdit und leg los. Das Resultat hätte ich gern auch in einem Flash- Demo.
Ich bestreite ja nicht, dass der CBX eine IDE mit allem Komfort ist, den man üblicherweise von einer solchen erwartet (Projektverwaltung etc.). Was ich nicht verstehe ist deine Feststellung, dass man mit dem CBX eine besondere Unabhängigkeit vom IDE-Hersteller, hier Borland, erreichen würde.
Wenn es also Borland einmal nicht mehr geben sollte und somit keinen Support für den CBX mehr, du aber plötzlich einen schwerwiegenden Bug in der IDE entdeckst, aufgrund dessen sich deine Projekte nicht mehr kompilieren lassen, dann bleibt dir auch nur noch der blanke Sourcecode, denn mit den Projektdateien (*.cbx) kann kein Compiler etwas anfangen. Und in diesem Moment kannst du genauso mit einem Texteditor+Compiler weitermachen.
-
Eben nicht.
Zitat aus dem Demo (bei ca. 50%): "Using VPN, I open up the C++BuilderX IDE, running remotely on a Linux operating System. [...] To rebuild this application for Linux, I simply choose 'Linux' from the 'Platform' dropdown." Und später das Ganze nochmal auf einem ebenfalls ferngesteuerten Solaris-System.habs mir noch einmal angeschaut. Stimmt. Sagt er. *verwundert* Ich teste das morgen. Sieht aber so aus, als ich mich in diesem Punkt geirrt habe (Nicht nur ich).
Wenn es also Borland einmal nicht mehr geben sollte und somit keinen Support für den CBX mehr, du aber plötzlich einen schwerwiegenden Bug in der IDE entdeckst, aufgrund dessen sich deine Projekte nicht mehr kompilieren lassen, dann bleibt dir auch nur noch der blanke Sourcecode, denn mit den Projektdateien (*.cbx) kann kein Compiler etwas anfangen. Und in diesem Moment kannst du genauso mit einem Texteditor+Compiler weitermachen.
kompiliert wird meines Wissens immer noch mit einem Compiler und nicht mit einer IDE. Die Projektverwaltung würde natürlich ohne IDE wegfallen. Was aber nicht bedeutet, dass man den Quellcode nicht mehr compileren kann. Wenn eine IDE wegfällt sucht man sich eine andere. Ansonsten nimmt man sich den Trexteditor, wie du schon sagst, hervor wenn es keine Alternativen gibt, welche es aber immer geben wird.
Was ich nicht verstehe ist deine Feststellung, dass man mit dem CBX eine besondere Unabhängigkeit vom IDE-Hersteller, hier Borland, erreichen würde
Was würdes du machen wenn es den BCB7 geben würde und Borland 1 Jahr später pleite machen würde. Hättest du dann auch die Möglichkeit weiter zu entwickeln ohne auf eine tote Bibliothek aufzubauen? NEIN! Nein, weil niemand anderes die VCL unterstützt. Das versuche ich damit rüber zu bringen. Wie siehts mit MFC aus. Mit MFC kann das selbe passieren.
Schwarzmalerrei- ich weiss. Ich hab aber schon Pferde kotzen sehn.
-
AndreasW schrieb:
Was würdes du machen wenn es den BCB7 geben würde und Borland 1 Jahr später pleite machen würde. Hättest du dann auch die Möglichkeit weiter zu entwickeln ohne auf eine tote Bibliothek aufzubauen? NEIN! Nein, weil niemand anderes die VCL unterstützt. Das versuche ich damit rüber zu bringen. Wie siehts mit MFC aus. Mit MFC kann das selbe passieren.
Achso, statt "Hersteller der Entwicklungsumgebung" meintest du "Hersteller des Frameworks"!? Denn wie wir uns ja inszwischen einig sind ist man von der IDE nur begrenzt abhängig, vom eingesetzten Framework dagegen möglicherweise sehr. Insofern bringt also nicht die Möglichkeit des Einbindens verschiedener tool chains (Compiler, Debugger etc.) eine gewisse Unabhängigkeit vom Hersteller, sondern einzig der Wechsel zu einem quasi-offenen Framework.
Zu dumm, dass gerade dieses ja momentan noch der grosse Schwachpunkt des CBX ist.
-
vom eingesetzten Framework dagegen möglicherweise sehr
vom eingesetzten Framework bleibt man immer in irgend einer Art und Weise abhängig.
Wenn ich mich mal kurz selbst Zititern darf:
Alleine die Möglichkeit andere Compiler und Debugger einsetzten zu können bringt schon ein Stück weniger Abhängigkeit zu den Herstellern der Entwicklungsumgebungen.
Wie du siehst hab ich auch nicht geschrieben dass man völlig unabhängig wird. Ich hab geschrieben dass man "ein Stück weniger Abhängig" ist. Und das ist definitiv richtig.
Zu dumm, dass gerade dieses ja momentan noch der grosse Schwachpunkt des CBX ist.
wo siehst du den Schwachpunkt?
-
Eine gewisse "Abhängikeit" schafft an sich eher an eine bestimmte IDE wenn man sich nämlich daran gewöhnt zur Entwicklungszeit eine Form aufziehen und per Mausklick Steuerelemente darauf plazieren zu können und dann noch per Doppelklick Funktionsrümpfe für Events zu generieren. Zugegeben wollte ich so eine Möglichkeit auch nicht mehr missen, aber ein reiner g++ bietet das halt nicht. Wenn man nun nicht weiß wie man sowas manuell anstellt ist man in der Tat in eine (IDE-) Abhängigkeit geraten. Kompileren lässt sich so ein Code auch ohne IDE sprich BuilderX
-
AndreasW schrieb:
Jansen schrieb:
Zu dumm, dass gerade dieses ja momentan noch der grosse Schwachpunkt des CBX ist.
wo siehst du den Schwachpunkt?
Ich denke dies ist eine Anspielung auf die - mh - in meinen Augen etwas unglückliche Strategie ein unfertiges Produkt ohne irgendwelche klare Roadmap auf den Markt zu werfen.... (o:
-junix
-
in meinen Augen etwas unglückliche Strategie ein unfertiges Produkt ohne irgendwelche klare Roadmap auf den Markt zu werfen....
ja, ist mehr als unglücklich. Ist mir auch ein Rätsel warum Borland auf einmal so voreilig ist.
-
AndreasW schrieb:
in meinen Augen etwas unglückliche Strategie ein unfertiges Produkt ohne irgendwelche klare Roadmap auf den Markt zu werfen....
ja, ist mehr als unglücklich. Ist mir auch ein Rätsel warum Borland auf einmal so voreilig ist.
Ich denke sie waren im Zugszwang. Man hat (zu) lange nichtsmehr von Borland gehört. Ich denke da standen einige Marketing-fuzzies in der Tür bei den Entwicklern "Jungs wir müssen was zeigen"....
Eventuell wars auch ein strategischer Zug, noch nicht zu konkret zu werden, in der Hoffnung, dass sich in der nächsten Zeit die Richtung (ob nu .net oder SunOne oder sonst was) abzeichnet, und man so dann auf den sieger setzen kann ohne ein risiko einzugehen.
Je länger ich mir das ganze rund um CBX betrachte, desto länger habe ich das Gefühl, dass Borland hier aus der Not nicht zu wissen was die Zukunft bringt eine Tugend gemacht hat und deshalb die Tool Chain so suuuper flexibel ist. Leider allerdings auf Kosten von Roadmap etc.
Ich glaube du hast ja bereits geschrieben, dass bei Borland der weitere Weg auch noch nicht so klar ist. Ich denke das wäre ein weiteres Indiz für meine Theorie. Trotzdem glaube ich, dass sich borland mit der Aktion jetzt nur geschadet hat...die Desinformation scheint perfekt zu sein.
-junix
-
Danke allen, die hier interessante Sachen zum CBX geschrieben haben. Morgen bin ich in Berlin auf der Roadshow, da habe ich jetzt Dank Euch gleich noch ein paar neue Fragen für die BO-Leute. Bin ja mal gespannt.
mfG, Jens
-
AndreasW schrieb:
wo siehst du den Schwachpunkt?
Im Nicht-wirklich-Vorhandensein des wx-Frameworks!?
-
Hi.
AndreasW schrieb:
Ich denke sie waren im Zugszwang. Man hat (zu) lange nichtsmehr von Borland gehört. Ich denke da standen einige Marketing-fuzzies in der Tür bei den Entwicklern "Jungs wir müssen was zeigen"....
Ich weigere mich seit Jahren erfolgreich, von Microsofts Word 97 auf eine neuere Version umzusteigen und zwar deshalb, weil es dafür einfach keinen Grund gibt. So ähnlich geht es mir beim CBuilder. Ich arbeite immer noch mit dem CBuilder 4 und vermisse fast nichts. ADO fällt mir da als einzige Ausnahme ein, aber dafür gibt es ja dann den CB6.
Der CBuilder ist eben einfach ein hervorragendes Werkzeug für die Entwicklung von Windows-Software.
Diese Tatsache geht in dem ganzen Chaos etwas unter. Auch mein Eindruck ist, daß Borland nur krampfhaft versucht, ein neues Produkt auf den Markt zu bringen - die Leute werden es schon kaufen. Als Indiz für die Richtigkeit dieser Vermutung drängt sich das Fehlen von stichhaltigen Begründungen für diese unpopuläre Strategie auf.
Die ganze Debatte über Plattformunabhängigkeit bleibt imho letztlich am grafischen Interface hängen und ist daher für mich eine Phantom-Diskussion. Die GUI's der Betriebssysteme sind einfach zu verschieden, als daß man erwarten könnte, mit nur einem Quellcode Software für alle Betriebssysteme schreiben zu können. Was nach einer solchen Diskussion herauskommt, ist dann ein (langsames Java-)Programm mit einer hausbackenen Oberfläche. Und die läßt sich nicht verkaufen!! Ich sehe keinen Grund, warum das bei wxWindows anders werden sollte. Es ist doch so: Sagt man dem Kunden, das Programm könne eine Millionen Datensätze in 10 s verarbeiten, zuckt der bloß mit den Schultern - Hauptsache das sieht alles schön bunt aus, bewegt sich ab und zu und macht, wenn möglich, sogar Geräusche (-> übertriebene Darstellung).
Ich stimme letztlich der Empfehlung von AndreasW, zu: sauberes Klassen-Design, STL und MVC-Modell zum Abwarten und später klappt's dann vielleicht auch mit der Plattformunabhängigkeit ...
----------------------------------
AndreasW schrieb:
Schwarzmalerrei- ich weiss. Ich hab aber schon Pferde kotzen sehn
Irgend jemand hat mir letztens erzählt, daß Pferde (wegen dem langen Hals oder so ?)
überhaupt nicht kotzen können - das nur so nebenbei
-
junix schrieb:
Ich denke sie waren im Zugszwang. Man hat (zu) lange nichtsmehr von Borland gehört. Ich denke da standen einige Marketing-fuzzies in der Tür bei den Entwicklern "Jungs wir müssen was zeigen"....
Das denke ich auch. Ich persönlich nutze mehr Kylix(BCB) als das Windows-Pendant und habe da so meine lieben Probleme mit dem Tool. Ich wünsche mir seit Erscheinen der Version 3 'ne ganze Menge Sachen (vor allem Bug-Fixing) von Borland und weiß, daß das auch 'ne Menge anderer Kylix-User tun. Aber da passiert leider gar nichts und es gibt gerade in den Borland-Newsgroups manchmal ziemlich böse Worte.
In den letzten Jahren ist man ja von Borland nicht gerade verwöhnt worden, was Kontinuität betrifft. Erst VCL, dann CLX, davon drei verschiedene Versionen, jetzt alles ganz anders. Da wird ein Haufen Aufwand getrieben um QT zu kapseln, währenddessen ist QT selbst schon viel weiter. Jetzt gehts von QT weg zu wxwindows. Wer weiß denn, was als nächstes kommt.
Cross-Platform-Entwicklung ohne wirklich cross-platform-kompilieren zu können. Was soll das? Alles Sachen, die nicht dazu beutragen, die Käufer bei der Stange zu halten.
Unter Linux muss man sich schon überlegen, ob man alle Möglichkeiten des Systems ausschöpfen will, dann muss man nämlich auf Kylix verzichten, oder ob man lieber die doch gute RAD-Umgebung nutzen will und dafür halt um ein paar Klippen herumprogrammieren muss.
mfG, Jens
-
dschensky schrieb:
AndreasW schrieb:
Schwarzmalerrei- ich weiss. Ich hab aber schon Pferde kotzen sehn
Irgend jemand hat mir letztens erzählt, daß Pferde (wegen dem langen Hals oder so ?)
überhaupt nicht kotzen können - das nur so nebenbeiGratuliere! Du hast soeben den Witz der Redensart erkannt. Du darfst nun selber interpretieren was das bedeutet, wenn Pferde nicht kotzen können, AndreasW aber bestimmt schon welche gesehn hat.
Was die Plattformunabhängigkeit betrifft: Ich denke mit einem genügend abstrakten Framework (wies übrigens die VCL schon war) kann man die Betriebssystem API ziemlich schön kapseln. Natürlich auf Kosten der Geschwindigkeit der Oberfläche. Allerdings muss man da sagen, dass man sowieso keine grösseren Rechnungen innerhalb der Oberfläche machen sollte. Stichwort MVC bzw. Document/View.
-junix
-
Nix schrieb:
Cross-Platform-Entwicklung ohne wirklich cross-platform-kompilieren zu können.
Den erklär mir jetzt mal bitte...
-junix
-
Er meint vermutlich die Möglichkeit z.B. auf Windows zu entwickeln, beim Compilieren aber ein ausführbares Binary für z.B. Linux zu erzeugen
-
junix schrieb:
Den erklär mir jetzt mal bitte...
Peter schrieb:
Er meint vermutlich die Möglichkeit z.B. auf Windows zu entwickeln, beim Compilieren aber ein ausführbares Binary für z.B. Linux zu erzeugen
Besser hätte ich es nicht sagen können. Oder besser, ich hätte es gleich so schreiben sollen...
mfG, Jens
-
Naja, aber diesen Punkt kannst du ja mit der Auswahl der passenden Toolchain (Cross-Compiler) erschlagen? Ich seh den Einwand nicht?
-junix
-
Nix bemängelt, dass es den CBX zwar für verschiedene Plattformen gibt ("Cross-Platform-Entwicklung"), man aber nur Binaries für das jeweilige Betriebssystem erstellen kann, unter dem man gerade arbeitet ("ohne wirklich cross-platform-kompilieren zu können").
Im Prinzip also genau wie bei Kylix.
Borland selbst hat allerdings nichts anderes behauptet oder in Aussicht gestellt, und die Frage nach Cross-Platform-Binary-Generation (geiles Wort :)) bzw. Hoffnung darauf erscheint angesichts der technischen Probleme auch unrealistisch. CrossCompiler müssten Bestandteil der jeweiligen tool chain sein und würden somit im CBX-Konzept ohnehin nicht in die Verantwortung von Borland fallen (vom einem potentiellen Zusatz für Borlands eigenes bcc32-ilink32-Paket mal abgesehen).
-
junix schrieb:
dschensky schrieb:
AndreasW schrieb:
Schwarzmalerrei- ich weiss. Ich hab aber schon Pferde kotzen sehn
Irgend jemand hat mir letztens erzählt, daß Pferde (wegen dem langen Hals oder so ?)
überhaupt nicht kotzen können - das nur so nebenbeiGratuliere! Du hast soeben den Witz der Redensart erkannt.
Ich weiß. Und ich, als geborenes Gross-Stadt-Kind, wollte nur mit meinem neuen Grundlagenwissen aus der Landwirtschaft protzen.
-
dschensky schrieb:
Was nach einer solchen Diskussion herauskommt, ist dann ein (langsames Java-)Programm mit einer hausbackenen Oberfläche. Und die läßt sich nicht verkaufen!! Ich sehe keinen Grund, warum das bei wxWindows anders werden sollte.
naja, wxWindows mit Java zu vergleichen geht wohl ein bischen weit...
mach dir doch bitte erst ein Bild von wxWindows.