Delphi ist unbeliebt...angeblich

[freimatz]

Zitat von Sherlock:

Man kann das Delphi Gebashe auch wirklich übertreiben. "Delphi gets the job done" was will man mehr?

Definiere bitte "the"? Ich bekomme "meinen" hier mit Delphi auch done. Aber mehrmals am Tag Delphi neustarten oder zu manchen Zeiten nach jedem Lauf des Unit-Tests - das ist teuer.
Hier gibt es etliche Entwickler die Delphi und C# machen. Alle machen lieber C# mit VS als Delphi.

[Sherlock]

Meine 10.2.1 IDE stürzt mittlerweile im Schnitt einmal die Woche ab. Und das obwohl ich mit FMX auf dem iOS Simulator oder gar einem iPad entwickele. Das ist enorm gegenüber noch dem letzten Jahr.

Sherlock

[Codehunter]

Zitat von Sherlock:

Meine 10.2.1 IDE stürzt mittlerweile im Schnitt einmal die Woche ab. Und das obwohl ich mit FMX auf dem iOS Simulator oder gar einem iPad entwickele. Das ist enorm gegenüber noch dem letzten Jahr.

Sherlock

Hatte ich auch schon mal nach dem Update von XE2 auf XE4. Hab damals geflucht wie ein Rohrspatz. Am Ende war es aber ein defekter RAM-Riegel, der sich zufällig gerade dann bemerkbar machte wo ich das Update installiert hab. Kann auch mal sowas banales sein.

[Der schöne Günther]

Alle die meckern sollen mal mit dem C++ Builder arbeiten. Danach weiß man wie gut man es als Delphi-Entwickler hat. Lieber würde ich Qualitätskontrolle für Rektal-Thermometer machen.

[Namenloser]

Zitat von Sherlock:

Zitat von Namenloser:

Diese Features ermöglichen aber nicht nur die komfortable Verwendung von Strings, sondern eröffnen darüber hinaus viel weitergehende Möglichkeiten, die in Pascal gar nicht möglich wären.

Zum Beispiel schwer zu findende Speicherlecks, Buffer Overflows, Type Mismatches und die allseits beliebten Runtime Errors.

Buffer Overflows sind typisch für C, aber für reines C++ eigentlich nicht. Speicherlecks gibt es auch keine, weil im Gegensatz zu Delphi Objekte am Ende des Scopes automatisch freigegeben werden (außer man erzeugt sie auf dem Heap, dann ist man aber selbst schuld). Die anderen beiden genannten Punkte kann ich auch nicht nachvollziehen.

Aber bitte deswegen nicht meinen, dass ich jetzt der totale C++-Fanboy und Delphihasser wäre. Das ist definitiv nicht der Fall. Sowohl C als auch C++ sind alles andere als perfekt und es gibt einige Dinge, die ich in Delphi nach wie vor besser gelöst finde, z.B. Event-Handler. Ich bin jedes mal am Fluchen, wenn ich in der C- oder C++-Welt eine Methode eines Objekts als Callback verwenden will. Oder die Tatsache, dass es kein Unit-System gibt. Oder Makefiles.

Ich denke aber gerade deshalb muss es gute Gründe geben, warum diese Sprachen sich eben doch durchgesetzt haben.

[Bernhard Geyer]

Zitat von freimatz:

... nach jedem Lauf des Unit-Tests - das ist teuer.

Unit-Tests auf dem Client-Rechner zu machen ist teuer.
Ich würde euch empfehlen ein Build-System wie Jenkins zuzulegen.
Bei uns laufen die Unit-Tests mittlerweile nach jedem Checkin.

[LTE5]

Bei kleineren Produkten sind Unit-Tests doch nicht notwendig. Da lässt man die Software einfach von zwei, drei Leuten auf Herz und Nieren prüfen und alles ist gut.

[Uwe Raabe]

Zitat von LTE5:

Bei kleineren Produkten sind Unit-Tests doch nicht notwendig. Da lässt man die Software einfach von zwei, drei Leuten auf Herz und Nieren prüfen und alles ist gut.

Du hast das Ironie-Tag vergessen

[mensch72]

UnitTests eignen sich sogar speziell für kleinere Projekte, denn da ist die Anzahl möglicher gültiger Zustände noch überschaubar und damit voll regelbasiert definierbar&prüfbar. Und da ist dann ein erfolgreicher Unittest auch meist ein Zeichen das "alles gut".

Bei größeren Sachen wo es letztendlich um irrsinnig viele mögliche Kombinationen aus verschiedensten Größen/Werten geht, welche teils gültig und teils ungültig sind, da scheitern im Livebetrieb "binäre" Unittetsts die da ja letztendlich nur ala "InRange/OutRange" prüfen können.
Da es leider auch manuell unmöglich ist vorab, alle möglichen gültigen Kombinationen regelbasiert binär zu beschreiben, setze ich da auf etwas BigData und Statistik per Klassifizierung durch SupportVectorMaschinen... da gibt man wie bei neuronalen Netzen alles aus der Vergangenheit und dem aktuellen samt Ergebnis rein, und das ermöglicht dann eine "vorab" Bewertung eines "neuen" Ergebnisses aus einem beliebigen Parametersatz, bevor dieser weiterverwendet wird.


Also Super: Unittests finden grobe Schnitzer vorab, reale Fehler durch zufällig mehrere ungünstige(aber einzeln gültige) Wertepaarungen verhindern all meine vorab bestandenen UnitTests aber leider nicht
=> Soll heißen: auch nach bestandenen UnitTests verzichte man im RealProgramm nie auf ständige Werte und Fehlerprüfungen

[LTE5]

Ich mach es immer so, dass ich neu hinzugefügte Funktionen sehr gründlich durchprüfe.
Ich brauche da keine Unitstests oder so. Alles Zeitverschwendung meiner Meinung nach.