4. borland c++builder 5.0, 18 jahre alt

borland c++builder 5.0, 18 jahre alt

  • A

    DocShoe schrieb:

    Ja, das war bei uns ähnlich und hat für eine mittelschwere Krise gesorgt 😉
    Ich habe ein Projekt, das mit dem clang out of the box knapp 4 Stunden zum Übersetzen braucht. Andererseits ist der klassische Compiler dabei immer wieder mit Internal Compiler Error ausgestiegen, da hatten wir die Wahl zwischen Pest und Cholera. Die Lösung hat dann TwineCompile auf einem 8+8 Core PC gebracht, damit bin ich jetzt bei ca. 30 Minuten Übersetzungszeit für das komplette Projekt. Der klassische Compiler hat dafür 45 Minuten gebraucht.

    Wir arbeiten auch mit dem TwineCompile, auf einen ähnlichen PC (Dual Xeon E5-2665; 8+8 Kerne [32 Threads], demnächst wohl Dual-Xeon mit jeweils 10+ Kernen). Der Versuch ist eine Weile her, damals war der Classic Compiler mit TC dennoch weit schneller fertig (nur der Linker braucht ewig im Vergleich). Aktuell sind wir bei etwa 5 min compilierung, und brauchen gefühlt fast genauso lange fürs linken.

    0
  • ?

    asc schrieb:

    Ich war selbst (bis eben zu der BCB 5.0-Zeit) ein Fan von dem BCB, inzwischen weiß ich warum ich den C++ Builder (selbst mit einer aktuellen Version, wie ich diesen noch beruflich nutzen muss) ablehne. Und keiner in unseren Team (selbst unser Chef, der lange den C++ Builder in Schutz genommen hat) will ihn noch nutzen - wir sind aber dazu derzeit noch gezwungen. Altcode lässt sich nicht einfach umstellen, gerade nicht wenn alle Entwicklerkapazitäten noch fleißig an der Umsetzung von Kundenwünschen gebunden sind. Aber wenn du davon so begeistert bist: wir suchen demnächst einen weiteren Entwickler, der a) meine Arbeit nach und nach übernimmt* und b) uns entlastet.

    Ich bin nur Hobby-Programmierer. Ich sehe Programmieren eher als künstlerische Tätigkeit an. Wenn ich programmieren müsste um Geld zu verdienen, fände ich das schrecklich.

    Mir ist klar, dass der alte BCB kein aktuelles C++ und STL kann. Aber das ist mir nicht so wichtig. Wenn ich das will, nehme ich irgendwas GCC-basiertes.

    Den BCB nehme ich, um auf die Schnelle kleinere Windows-Tools zusammenzuklicken. Ich habe viel selbst geschriebene Programme für den Textmodus, die werde ich mit dem BCB erstmal auf Klicki-Bunti aufpeppen.

    asc schrieb:

    Wer keine Ahnung hat und meint mit einem BCB5 glücklich zu werden...
    Es wurde ursprünglich mal mit dieser Intension gestartet, doch .NET und Java sind trotz Ähnlichkeiten durchaus sehr unterschiedlich (und das nicht erst seit kurzem).

    Ich bin da sehr eigen. Ich mag Programme, die nur aus einer EXE bestehen und die man von überall starten kann, ohne irgendwas installieren zu müssen. Sowas furchtbar Träges wie NET und Java, mit virtuellen Maschinen und riesigen Librarys, beleidigt mein ästhetisches Empfinden und meinen Hang zum Minimalismus.

    Du siehst, als Berufsprogrammierer bin schon deshalb denkbar ungeeignet. :p

    0
  • ?

    DocShoe schrieb:

    Ja, das war bei uns ähnlich und hat für eine mittelschwere Krise gesorgt 😉
    Ich habe ein Projekt, das mit dem clang out of the box knapp 4 Stunden zum Übersetzen braucht.

    Was ist denn das für ein riesiges Programm? Lässt sich das nicht modularisieren, so dass man nicht immer alles neu bauen muss?

    0

  • Ja natürlich ist das modularisiert 😉
    Aber vor einem Release macht man schon mal ein Build-All.

    Und da kommen wir zu den Macken des Builders: Er erkennt nicht immer, welche Subprojekte up-to-date sind, daher muss man schon mal wieder ein Build All machen.

    0
  • ?

    Schau dir mal CMake an. Das ist ein Build-System für große Projekte. Ich persönlich habe es noch nicht benutzt, aber dem Hörensagen nach soll es ganz gut sein. https://cmake.org/

    0
  • A

    RetroGuy schrieb:

    Ich bin da sehr eigen. Ich mag Programme, die nur aus einer EXE bestehen und die man von überall starten kann, ohne irgendwas installieren zu müssen. Sowas furchtbar Träges wie NET und Java, mit virtuellen Maschinen und riesigen Librarys, beleidigt mein ästhetisches Empfinden und meinen Hang zum Minimalismus.

    Zunächst zur "nur eine exe"-Mentalität:
    Diese Mentalität ist ein Grund für viele Probleme die wir hier haben. Zumal wir dies inzwischen ohnehin aufgeben mussten, das statische linken aller nötigen Komponenten macht der Linker nicht mehr mit.

    Wäre das Projekt rechtzeitig in Bibliotheken aufgeteilt wurden, wäre vermutlich sowohl die Schichtentrennung als auch die Compilezeiten für einzelne Bereiche besser (man ändert meist nur an wenigen, begrenzten Stellen; Wenn die Compilezeit reicht um sich gemütlich einen Kaffee zu kochen, lenkt dies bloss ab).

    Doch nachträglich das Projekt zu modularisieren, ist vielleicht zuviel aufwand, wenn man weiß, das man eh die Plattform wechseln muss. Den vorhandenen Code können wir ohnehin zumeist nicht verwenden, auch wenn mein Chef dies nicht einsehen will (trotz anderer Meinung der Entwickler). Ganz zu schweigen das einige grundlegende Basiskonzepte auf dem Prüfstand für eine Neuumsetzung ständen, dies also auch von logischen Aspekten nur eingeschränkt klappen könnte.

    Zur Trägheit:
    Ich habe inzwischen viele .Net- und zumindest einige Java-Programme erlebt. Dabei habe ich eins festgestellt: Bei größeren Geschäftsanwendungen macht es, bei guter Programmierung, kaum einen nennenswerten Unterschied ob man nativ oder mit Java oder .Net entwickelt. Anders mag es bei Anwendungen die sehr Rechen- oder Grafikintensiv sind aussehen. Aber eine "typische" Businessanwendung kann man auch in Java oder .Net so schreiben, das sie nicht träge erscheint.

    Zu VM:
    Die Konzepte haben sich selbst bei Java inzwischen geändert. Auch Java arbeitet im Grundsatz inzwischen mit einem JIT (JIT: Just in Time Compiler, es wird bei der ersten verwendung compiliert, anschließend das nativ compilierte verwendet; was .Net wohl seit Anfang macht).

    Rein von der Theorie her, kann ein JIT sogar schnelleren Code produzieren als ein nativer Compiler - da er den Code auf die konkrete Plattform kompilieren kann (bei einem nativen Compiler macht man das nur im seltenen Fall, normalerweise soll ein Programm ja ab einer bestimmten Rechnergeneration laufen). Das ist einer der Gründe (von mehreren) warum die "Trägheit" vor allem beim ersten Aufruf einer Programmfunktion merkbar ist. In der Praxis ist ein JIT aber nur dann auch im Endeffekt schneller, wenn die Compilezeit des JIT, zusammen mit der Anzahl der Aufrufe, durch den optimierteren Code tatsächlich eine Beschleunigung erzielt.

    Native Compilierbarkeit:
    Man kann übrigens schon seit vielen Jahren auch Java und .Net-Anwendungen nativ compilieren. Das hat aber gewisse Einschränkungen und sollte immer abgewägt werden. Es wird bei .Net Core gefühlt auch häufiger genutzt als noch bei klassischen .Net, auf gewissen Zielplattformen (z.B. über Xamarin auf iOS und Android) ist es schon Standard, da diese nur nativen Code erlauben oder es sich als praktikabler erwiesen hat.

    0

  • asc schrieb:

    Zunächst zur "nur eine exe"-Mentalität:
    Diese Mentalität ist ein Grund für viele Probleme die wir hier haben. Zumal wir dies inzwischen ohnehin aufgeben mussten, das statische linken aller nötigen Komponenten macht der Linker nicht mehr mit.

    Wäre das Projekt rechtzeitig in Bibliotheken aufgeteilt wurden, wäre vermutlich sowohl die Schichtentrennung als auch die Compilezeiten für einzelne Bereiche besser (man ändert meist nur an wenigen, begrenzten Stellen; Wenn die Compilezeit reicht um sich gemütlich einen Kaffee zu kochen, lenkt dies bloss ab).

    Doch nachträglich das Projekt zu modularisieren, ist vielleicht zuviel aufwand, wenn man weiß, das man eh die Plattform wechseln muss. Den vorhandenen Code können wir ohnehin zumeist nicht verwenden, auch wenn mein Chef dies nicht einsehen will (trotz anderer Meinung der Entwickler). Ganz zu schweigen das einige grundlegende Basiskonzepte auf dem Prüfstand für eine Neuumsetzung ständen, dies also auch von logischen Aspekten nur eingeschränkt klappen könnte.

    Ich hab´ da grade ein Deja Vue 😃

    0
  • A

    DocShoe schrieb:

    Ich hab´ da grade ein Deja Vue 😃

    Prima, jemanden mit Vorerfahrung könnten wir brauchen *duckundweg*... ;p

    0

  • Was zahlt ihr denn? 😃

    0
  • M

    Hi,

    Borlands C++-Compiler waren mal sehr gut, als sie noch Turbo C++ hießen.
    Damals waren sie absolut Spitze und auch noch sehr gut bezahlbar.
    Ich kann mich noch an die anderen Compiler erinnern, wie die gerödelt haben, und ehe bei denen der Präprozessor durch war war Turbo-C++ bereits fertig.

    Dazwischen hab ich dann einiges mit Delphi 1 und Delphi 3 gemacht, und als dann der C++Builder 1 raus kam war ich richtig happy. Nur die Begeisterung hielt nicht allzu lange. Die 1er Version war noch recht eingeschränkt, aber vermutlich damals ein Schritt in die richtige Richtung. Dann kam aber C++Builder 4 und der hat mich eigentlich davon weggebracht. Völlig unnachvollziehbare Komplettabstürze bei zum Teil an sich fehlerfreiem Code (lief in späteren Versionen)...

    Die VCL war an sich eine feine Sache, aber sie war eben in Delphi (Pascal).
    Irgendwie gibts da gewisse Klemmstellen zwischen den beiden Sprachen. Bestimmte Sachen, wie Mengen als Parameter an eine Funktion übergeben was in Delphi durch einfaches in ecklige Klammern setzen geht erfordern da umständliche Konstrukte.
    Zwischen Delphi und C++ gibt es unterschiedliche Programmierparadigmen, unterschiedliche Aufrufkonventionen... Irgendwie ist das ein bisschen so, als ob man mit überkreuzten Händen Auto fährt.

    Das ganze Programm ist auch von der Sache her immer noch kein normales C++-Programm, sondern ein Pascal-Programm bei dem aber die eigentliche Arbeit von C++-Quelltexten realisiert wird.

    Wer damit leben kann, der wird damit sicher recht gut klar kommen. Aber ich sehe es als etwas ne Querele an, dass der C++-Builder keine eigene von Grund auf C++-Basis hat.

    Ein großes Plus ist eindeutig die reich bestückte Komponentenpalette, und vor allem, dass man die so elegant und einfach problemlos durch eigene oder abgeleitete Komponenten erweitern kann. Wobei, komplett eigene sind da nicht ganz empfehlenswert, man sollte sie immer wenigstens von TOBject oder TComponent ableiten, damit sie natlos in die Komponentenpalette und die Abarbeitung der VCL integriert werden können.
    Wenn man eigene Komponenten erstellen will, tut man auf jeden Fall gut daran, dieses in Delphi zu tun. Da ist das ganze wie aus einem Guß und man kann sie auch genau so gut unter C++ verwenden.
    Klar kann man eigene Komponenten auch mit C++ erstellen, aber das ist ein bisschen, als ob man einen Automotor aus Teilen eines Benziners und Teilen eines Diesels zusammenbaut. Irgendwo knarzt es.

    Was auch ein großer Vorteil gegenüber z.B. Java ist, ist dass alles was mit der VCL zusammenhängt nicht mit Quelltext gemacht werden muss, sondern sich in einer von Delphi bzw. dem C++-Builder selbst erzeugten dfm-Datei befindet. Man klickt sich die einzelnen Teile zusammen, parametrisiert sie in den Eigenschaftseditoren und braucht dann nur noch für die eigentliche Arbeit Quelltext. Das vereinfacht vieles etwas.

    Wo es in C++Builder problematisch werden könnte ist die Verwendung von Design Patterns. Das zu verwendende Pattern ist im Prinzip die VCL.
    Man hat zum einen die ganze Oberfläche, die ein VCL-Gebäude ist, und zum anderen die Datenbankschnittstelle, die auch Teil der VCL ist. Die beiden sind sich eigentlich schon von vornherein einig, wie sie miteinander reden wollen und mögen da keinen der ihnen dazwischen Quatscht. Auf der einen Seite gibts die diversen DataSets, die praktisch den Zugriff auf die Daten repräsentieren und auf der anderen Seite die datensensitiven VCL-Objekte (Gitter, Eingabefelder...) und dazwischen gibts als Mittler die DataSources. Man kann es in verschiedenen Quelltextdateien unterbringen, oder bei kleineren auch in einer gemeinsamen, aber diese Grundstruktur wird immer bleiben.

    Irgendwo klemmt es daran, dass Borland (und Nachfolger - aktuell wohl IDERA) nicht so viel Ressourcen haben um beide Strecken völlig parallel zu entwickeln. Und sie haben sich auch zum Teil verzettelt. Da war zwischendurch Power-Basic, Turbo-Assembler, J-Builder, Java-Builder... und noch diverse Hunde aus verschiedenen Körben dabei.

    Wenn einem das Konzept der VCL gefällt (und es hat auf jeden Fall auch ne Menge für sich), dann ist es das beste, wenn man sich von C++ trennt und mit Delphi arbeitet. Dann ist alles aus einem Guss und alles passt perfekt zusammen. Manches ist nicht ganz so elegant wie mit C++, anderes einfacher. Und Delphi hält wesentlich weniger Fallstricke bereit als C++. Wärend man bei C++ noch an der Konzeption arbeitet, ist man bei Delpnhi schon beim Problauf. Vor allem sind auch die Compilierzeiten um Welten geringer, vergleichbar mit den alten Turbo-Sprachen.
    Lediglich bei sehr großen Projekten ist Delphi nicht erste Wahl, weil einfach die Abstraktionsmöglichkeiten bei C++ größer und leistungsfähiger sind.

    Was man bei den ganzen Borland-Nachfolgern auf jeden Fall positiv heruasheben muss ist die sehr bereitwillige Hilfe durch Matthias Eissing, den man bei Problemen jeder Art direkt kontaktieren kann und wo man sehr kompetente hilfe bekommt.

    Gruß Mümmel

    1
  • A

    muemmel schrieb:

    Was auch ein großer Vorteil gegenüber z.B. Java ist, ist dass alles was mit der VCL zusammenhängt nicht mit Quelltext gemacht werden muss, sondern sich in einer von Delphi bzw. dem C++-Builder selbst erzeugten dfm-Datei befindet.

    Wobei das auch wiederum ein Problem darstellt, die IDE verändert gerne von sich aus Werte in der dfm, oder entfernt diese ganz (ein Problem was ins Besondere bei der Verwendung von Frames sehr gerne geschieht). Wir haben regelmäßig Probleme mit Zerschossenen Oberflächen, wenn man mal wieder vergessen hat jede dfm-Änderung beim Eincheckvorgang nachzuprüfen.

    Man kann von Visual Studio in Kombination mit C# und WPF, UWP und Xamarin halten was man will, aber da werden nicht einfach mal die XAML-Dateien verändert nur weil man das Fenster in der IDE geöffnet hat, oder Einträge gelöscht weil man eine Property an einer ganz anderen Stelle ändert. Zudem ist das XAML zwar von der Lesbarkeit nicht perfekt (das gilt aber auch für dfm) aber kommt mir dennoch weit sauberer strukturiert vor.

    muemmel schrieb:

    Man klickt sich die einzelnen Teile zusammen, parametrisiert sie in den Eigenschaftseditoren und braucht dann nur noch für die eigentliche Arbeit Quelltext. Das vereinfacht vieles etwas.

    Kann aber genauso gut nach hinten losgehen, und führt vom Design gerne zu Codedesign ohne echte Schichtentrennung (Was du wohl auch unter Design Pattern zählst). Was bei kleinen Projekten durchaus nichts schlimmes ist, bei großen aber gerne nach hinten losgeht. Und wenn man das ganze noch mit Vererbung von Forms, intensiver Verwendung von Frames etc. kombiniert, kommen am Schluß mehr Probleme als Nutzen heraus.

    muemmel schrieb:

    Wenn einem das Konzept der VCL gefällt (und es hat auf jeden Fall auch ne Menge für sich)

    Ich würde dennoch niemanden heute mehr zur VCL raten. Die VCL ist, und das sieht man auch daran wie die Anzahl der Komponentenhersteller stark zusammengeschrumpt ist, und wie wenig diese noch bereit sind in Designänderungen zu investieren. Sie mögen noch Änderungen einbringen und Pflege betreiben, aber wirklich aktiv entwickeln tun sie kaum mehr. Möchte man mehr als nur die Standardcontrols nutzen ohne alles selbst schreiben zu müssen (was in großen Teams sicherlich vertretbar ist, für kleine aber zeitlich kaum machbar), ist man von Fremdkomponenten abhängig. Und wenn man zumindest eine einigermaßen aktuelle Codebasis aufrecht erhalten will, und auch die IDE aktuell hält, wird man früher oder später zwangsweise Komponenten tauschen müssen, weil Anbieter x dicht gemacht hat. Inzwischen haben wir unsere Komponenten weitgehend auf einen der größten noch verbleibenen Hersteller portiert (DevExpress), aber wie lange der das ganze noch pflegt ist auch eine gute Frage.

    muemmel schrieb:

    Lediglich bei sehr großen Projekten ist Delphi nicht erste Wahl, weil einfach die Abstraktionsmöglichkeiten bei C++ größer und leistungsfähiger sind.

    Wenn man Produkt-, nicht Projektentwicklung betreibt, tendiert jedes Programm im Laufe seines Lebenszyklus dazu sehr groß zu werden.

    0
  • M

    Hi Asc,

    asc schrieb:

    Wobei das auch wiederum ein Problem darstellt, die IDE verändert gerne von sich aus Werte in der dfm, oder entfernt diese ganz (ein Problem was ins Besondere bei der Verwendung von Frames sehr gerne geschieht). Wir haben regelmäßig Probleme mit Zerschossenen Oberflächen, wenn man mal wieder vergessen hat jede dfm-Änderung beim Eincheckvorgang nachzuprüfen.

    Stimmt, kann etwas kritisch sein. Elemente Fixieren kann eventuell helfen, und ansonste kritische Dinge selbst setzen.
    Kurioserweise ist das von Version zu Version unterschiedlich. Bei meiner derzeitigen Version 10.1 vergessen die Datensensitiven Elemente gerne mal die auf einem anderen Formular befindliche Datasource. Also ggf die Datasource mit zu den Eingabeelementen und beim Erstellen deren Datasets korrigieren.
    Vor allem aber nie die Formulare in der IDE öffnen ohne vorher die DataUnit offen zu haben... Mit Frames arbeite ich zum Glück nicht, so dass mir die Probleme erspart bleiben. Hatte ich am Anfang mal ausprobiert und entschieden das ist nict mein Ding. War vielleicht deshalb, weiß ich n icht mehr.

    Kann aber genauso gut nach hinten losgehen, und führt vom Design gerne zu Codedesign ohne echte Schichtentrennung (Was du wohl auch unter Design Pattern zählst). Was bei kleinen Projekten durchaus nichts schlimmes ist, bei großen aber gerne nach hinten losgeht. Und wenn man das ganze noch mit Vererbung von Forms, intensiver Verwendung von Frames etc. kombiniert, kommen am Schluß mehr Probleme als Nutzen heraus.

    Jo, echte Schichtentrennung ist in Delphi nicht so ganz einfach. Delphi gibt Dir vor, wie es das haben will, und Du ziehst den Handschuh an oder lässt es.

    Möchte man mehr als nur die Standardcontrols nutzen ohne alles selbst schreiben zu müssen (was in großen Teams sicherlich vertretbar ist, für kleine aber zeitlich kaum machbar), ist man von Fremdkomponenten abhängig. Und wenn man zumindest eine einigermaßen aktuelle Codebasis aufrecht erhalten will, und auch die IDE aktuell hält, wird man früher oder später zwangsweise Komponenten tauschen müssen, weil Anbieter x dicht gemacht hat. Inzwischen haben wir unsere Komponenten weitgehend auf einen der größten noch verbleibenen Hersteller portiert (DevExpress), aber wie lange der das ganze noch pflegt ist auch eine gute Frage.

    Die Erfahrung habe ich leider auch schon machen müssen. Zum einen mit dem von Delphi früher angebotenen FormulaOne (Miniexcel) das ich sehr gerne für Datenasgaben genommen habe, aber auch mit Reportgeneratoren und eben auch mit Kadao-Tools für den Zugriff auf Access-Dateien. Das Miniexcel machte als erstes Probleme, weil es ab einer bestimmten Version nicht mehr dabei war. Außerdem war das nachträgliche Installieren ein Problem.
    Bei den Reportgeneratoren hat Delphi auch ziemlich hin- und hergewechselt. Und mit den Kadao-Tools gabs bei Umstellen auf Widechar Probleme.
    Meine Lösung war "nur noch eigene Komponenten sind gute Komponenten". Nicht wiel sie besser sind, sondern weil ich den Quelltext da habe und selber anpassen kann und weiß wie sie intern funktionieren. (Bei komplizierteren Komponenten muss ich mich da aber auch erst mal gewaltig klemmen, wenn ich da nachträglich nach Jahren wieder was ändern will, aber es geht). Vorteil meiner Verfahrensweise, es existiert nur eine Exe, für die nichts installiert werden muss und die alles aus sich heraus kann. Nachteil, mann muss alles zu Fuß machen und z.B. beim Formulardruck erst mal eine eigenen Bibliothek aufbauen um effizient ansprechende Druckformulare gestalten zu können. Aber da es aus Betreuungsaufwandsgründen für mich sowieso nur noch installationslose Programme geben darf kann ich damit leben.

    Wenn man Produkt-, nicht Projektentwicklung betreibt, tendiert jedes Programm im Laufe seines Lebenszyklus dazu sehr groß zu werden.

    Wem sagst Du das... Hab selber ein paar Jahre an so einem Dinosaurier von Rucksackprogramm gearbeitet, wo immer ein Rucksack nach dem anderen draufgesattelt werden musste. Derzeit zum Glück einzelne in sich abgeschlossene Einzelprogramme, die nur von Jahr zu Jahr Weiterentwicklung bzw. Anpassung benötigen.
    Ich würde das Ende sinnvoller Programmentwicklung in Delphi bei 500.000 bis 1 Million Quellzeilen sehen. Eher noch wesentlich früher. kommt auf den Programmierstil an. Alles was man irgendwie benennen kann, da mache ich ganz gerne ne Komponente draus und vergesse es dann.

    Gruß Mümmel

    0
  • A

    muemmel schrieb:

    Meine Lösung war "nur noch eigene Komponenten sind gute Komponenten".

    Das ist in einer Firma mit derzeit 2 Entwicklern kaum leistbar (Und was alles komplexere in der Anwendung angeht bin ich im wesentlichen derzeit alleine), wenn gleichzeitig Kundenwünsche umgesetzt werden sollen. Bevor wir in eine solche Sache noch Zeit investieren, wäre eine Portierung jedenfalls langfristig der bessere Weg.

    Ich würde das Ende sinnvoller Programmentwicklung in Delphi bei 500.000 bis 1 Million Quellzeilen sehen. Eher noch wesentlich früher. kommt auf den Programmierstil an. Alles was man irgendwie benennen kann, da mache ich ganz gerne ne Komponente draus und vergesse es dann.

    Ich habe noch keine wirkliche Zeit gehabt mich mit den Bauen von Komponenten zu beschäftigen, zumal wir dann eher ganze Module aus der exe trennen würden. Von der Größe liegen wir jedenfalls bei 750k+ Codezeilen, die meisten überblicke überhaupt nur noch ich oder alternativ bei sehr alten Code mein Chef. Zwar setzt mein Chef darauf möglichst keinen echten Termindruck aufzubauen, für einen "Hauptentwickler" alleine, wie derzeit, ist es aber inzwischen Grenzwertig (Ein Grund warum wir demnächst einen neuen Suchen - zumal ich angekündigt habe langfristig die Firma zu wechseln; Nicht wegen dem Arbeitsklima, aber ich bin inzwischen fast 10 Jahre hier und brauche etwas Neues und Abwechslung).

    0
  • M

    Hi Asc,

    asc schrieb:

    muemmel schrieb:

    Meine Lösung war "nur noch eigene Komponenten sind gute Komponenten".

    Das ist in einer Firma mit derzeit 2 Entwicklern kaum leistbar (Und was alles komplexere in der Anwendung angeht bin ich im wesentlichen derzeit alleine), wenn gleichzeitig Kundenwünsche umgesetzt werden sollen. Bevor wir in eine solche Sache noch Zeit investieren, wäre eine Portierung jedenfalls langfristig der bessere Weg.

    Ist bei mir ein wenig anders, ich bin zwar auf meinem derzeitigen Job absoluter Einzelkämpfer, aber nebenbenei was selber entwickeln ist fast immer möglich, sind ja nur EHDA-Kosten, weil ich bin ja "eh da".
    Schwieriger ist es mit was erwerben, im öffentlichen Dinest ist es leichter ein großes Ding mit 5 Millionen durchzubringen als ein kleines Tool für 50 Euro.

    Den Anfang habe ich mir aber schon vor längerer Zeit gelegt. Auf der DOS-Ebene in c++ zu Wendezeiten, wo ich es später für meine Fachschul-Abschlussarbeit gebraucht habe (damals gabs da nichts zu kaufen) und die eigentlichen Delphi-Komponenten hab ich mir dann bei meinem ersten Job als Softwareentwickler auf ner Projektstelle entwickelt bzw. den DOS-Komponenten aus meiner Abschlussarbeit nachempfunden. Tagsüber hab ich meine normale Arbeit gemacht, und abends bzw. am Wochenende hab ich mich drangesetzt und mir die entsprechenden Hilfsmittel gebastelt. Muss ich aber heute nicht mehr haben, heute bin ich froh, wenn der Tag nur 8 Stunden hat und die rum sind. Aber es war eben mein Weg in den Job (bin ja absoluter Quereinsteiger) und er hat funktioniert. Etwas Doppelarbeit war ich damals noch vom 1. Studium her gewohnt (Leistungslöhner im 3-Schichtsystem und nebenbei Abendschule). Aber wie gesagt, muss ich nun nicht mehr unbedingt haben. Man wird ja älter und gesetzter.

    Gruß Mümmel

    0
Anmelden zum Antworten