Delphi ist unbeliebt...angeblich

[freimatz]

Zitat:

Zitat von Sherlock (Beitrag 1387666)

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:

Zitat von Sherlock (Beitrag 1387737)

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:

Zitat von Sherlock (Beitrag 1387666)

Zitat:

Zitat von Namenloser (Beitrag 1387652)

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:

Zitat von freimatz (Beitrag 1387735)

... 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:

Zitat von LTE5 (Beitrag 1387780)

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 :lol:

[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üfungen8-)

[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.

[Daniel]

Unit-Tests sind nicht das Thema hier.

[p80286]

Zitat:

Zitat von freimatz (Beitrag 1387735)

Aber mehrmals am Tag Delphi neustarten oder zu manchen Zeiten nach jedem Lauf des Unit-Tests - das ist teuer.

Um was geht's denn hier? Eine nicht ganz ausgereifte IDE oder die Sprache?

Gruß
K-H

[Der schöne Günther]

"Delphi" ist das verkaufte Produkt. Das beinhaltet doch die IDE, die Sprache und alles was im Alltag dazu gehört. Wenn wir nur die Sprache "Object Pascal" betrachten sind wir gleich wieder bei begin/end oder so einem Pillepalle.

[freimatz]

Zitat:

Zitat von p80286 (Beitrag 1387845)

Zitat:

Zitat von freimatz (Beitrag 1387735)

Aber mehrmals am Tag Delphi neustarten oder zu manchen Zeiten nach jedem Lauf des Unit-Tests - das ist teuer.

Um was geht's denn hier? Eine nicht ganz ausgereifte IDE oder die Sprache?

Hm, um die Spache selber wohl weniger. Das Problem könnte man zur IDE rechnen.
Mit Delphi muss ich ausführbare Programme machen können. Ob das Windows-Apps sind oder für Console, Programme für Anwender oder Testprogramme darf keine Rolle spielen.
Das Argument man bräuchte doch keine unit-tests ist ... nicht zielführend.
Bei dem Problem läuft der unit-test mit GUI ganz normal durch und wird beendet. In Delphi kann man dann weiterarbeiten, der Test wird nicht mehr als "Running" angezeigt. Wenn man versucht den Test dann wieder zu compilieren meint Delphi die exe sei gesperrt (Could not create output file). Nach dem Processexplorer sitzt Delphi selber drauf. Wenn man Delphi dann beendet erscheinen Schutzverletzungen in dcc32230.dll. Irgendwann ist Delphi dann beendet und nach einen Neustart von Delphi geht es dann wieder - oft nur einmal.
Um aufs Thema zurückzukommen: dann ist Delphi bei mir unbeliebt und ich schau dass ich mit C#/VS Erfahrungen sammeln kann.

[sh17]

Zitat:

Zitat von freimatz (Beitrag 1387857)

Bei dem Problem läuft der unit-test mit GUI ganz normal durch und wird beendet. In Delphi kann man dann weiterarbeiten, der Test wird nicht mehr als "Running" angezeigt. Wenn man versucht den Test dann wieder zu compilieren meint Delphi die exe sei gesperrt (Could not create output file). Nach dem Processexplorer sitzt Delphi selber drauf. Wenn man Delphi dann beendet erscheinen Schutzverletzungen in dcc32230.dll. Irgendwann ist Delphi dann beendet und nach einen Neustart von Delphi geht es dann wieder - oft nur einmal.

Arbeitest Du in einer VM? Virenscanner eingestellt?

[matze8426]

Zitat:

Zitat von ATS3788 (Beitrag 1387115)

Microsoft Visual Studio ist meiner Meinung zum vergleich mit Delphi einfach nur schlecht.

Sowohl beruflich als auch privat nutze ich Delphi und C#.
Beides hat Vor- und Nachteile. Ich mag auch beide Sprachen, aber bzgl. der IDE finde ich Delphi wesentlich schlechter als Visual Studio. Beruflich nutze ich noch viel Delphi 7, das ist grottig (liegt aber zum Teil auch einfach am Alter). 10.2 ist schon recht gut, aber ich persönlich fände es toll, wenn ich Delphi mit Visual Studio programmieren könnte. Ähnlich wie ich mit VS auch C, C++, C#, Python etc. schreiben kann.

[Der schöne Günther]

Zitat:

Zitat von matze8426 (Beitrag 1394925)

aber ich persönlich fände es toll, wenn ich Delphi mit Visual Studio programmieren könnte. Ähnlich wie ich mit VS auch C, C++, C#, Python etc. schreiben kann.

Da gibt's doch was von Ratiopharm Wosi: http://omnipascal.com/

Klar, den Luxus eines WPF-Formulardesigners wird man unter Delphi so oder so nicht bekommen, aber vielleicht wenigstens eine IDE mit IntelliSense die nicht alle paar Sekunden stehen bleibt wenn der Code Completion wieder irgend etwas quer hängt :stupid:

[matze8426]

Zitat:

Zitat von Der schöne Günther (Beitrag 1394937)

... aber vielleicht wenigstens eine IDE mit IntelliSense die nicht alle paar Sekunden stehen bleibt wenn der Code Completion wieder irgend etwas quer hängt :stupid:

So siehts aus 8-)

[jaenicke]

Zitat:

Zitat von Der schöne Günther (Beitrag 1394937)

aber vielleicht wenigstens eine IDE mit IntelliSense die nicht alle paar Sekunden stehen bleibt wenn der Code Completion wieder irgend etwas quer hängt :stupid:

Solange man nicht große Unitabhängigkeiten hat kann ich mich diesbezüglich nicht beschweren... Auch in größeren Projekten, die durch Interfaces stark entkoppelte Units enthalten, habe ich weder mit der Code Completion noch mit Error Insight nennenswerte Probleme.

[himitsu]

Alles threaded und entkoppelt in der IDE ist auch nicht immer so toll. (wenn man nicht gleich irgendeine winzige Rückmeldung bekommt)

Ich erinnere mich noch an das Android Studio 0.5irgendwas.
Wenn man da im Menü irgendwas anklickte, dann passiert erstmal garnichts und "irgendwann" später poppt das neue Fenster auf, oder 800 Fenster, weil man ungedultig mehrmals draufklickte. :stupid:

[hoika]

Hallo,

Zitat:

Nach dem Processexplorer sitzt Delphi selber drauf. Wenn man Delphi dann beendet erscheinen Schutzverletzungen in dcc32230.dll. Irgendwann ist Delphi dann beendet und nach einen Neustart von Delphi geht es dann wieder - oft nur einmal.

Das riecht doch nach irgendeiner IDE-Erweiterung, wie jedi, cnpack oder so.

[zeras]

Heute war ein Vertreter bei uns. Der stellte uns eine Lösung mit einen IPC vor. Um den IPC mit unserer Steuerung zu verbinden, warf ich in den Raum, dass man möglicherweise auf seinem IPC ein Delphiprogramm installieren könnte.
Da kam die Frage: "Gibts denn Delphi noch"?
Ich antwortete nur kurz und er hat sich mehr oder weniger entschuldigt.

[Der schöne Günther]

Kennen wir das nicht alle 8-)

[TiGü]

Für solche Situationen haben wir einen eigenen Raum: