Wieso gibt es keine gute Programmiersprache?

ShadowClone schrieb:

Gab es Borrow-Checker und das Spezifizieren von Lifetimes auch davor? Zur Compilezeit?

Mach mal halblang. Dir fehlt deutlich sowohl die Praxiserfahrung als auch das theoretische Hintergrundwissen, sonst würdest du hier nicht solchen Stuss bezüglich Teamarbeit und Programmierparadigmen von dir geben.
Lern also bitte mal die Grundlagen und sammle ein wenig Erfahrung aber bis dahin: sei leise!

Kenner der Idioten schrieb:

ShadowClone schrieb:

Gab es Borrow-Checker und das Spezifizieren von Lifetimes auch davor? Zur Compilezeit?

Mach mal halblang. Dir fehlt deutlich sowohl die Praxiserfahrung als auch das theoretische Hintergrundwissen, sonst würdest du hier nicht solchen Stuss bezüglich Teamarbeit und Programmierparadigmen von dir geben.
Lern also bitte mal die Grundlagen und sammle ein wenig Erfahrung aber bis dahin: sei leise!

Armselig. Du scheinst nicht mal zu wissen, dass du z. B. unter rust nichts kompilieren kannst, wo die Lebenszeit von Objekten nicht genau spezifiziert ist (wenn das implizit nicht ermittelt werden kann, dann muss das explizit geschehen).
Bei anderen Sprachen kennt der Compiler nicht für jedes Objekt die Lebenszeit zur Compilezeit.
Also: Wenn hier jemand die Klappe halten muss, dann bist du das! Besonders armselig ist deine beleidigende Sprachwahl und dass dein Beitrag tatsächlich 0% Sachinformation enthält, sondern rein persönlich ist. Es ist nicht mal klar, was genau du an meinem Beitrag kritisierst und ich deswegen nur mutmaßen kann.

hustbaer

Arcoth schrieb:

hustbaer schrieb:

(viele kennen das Keyword gar nicht)

Du arbeitest also mit Anfängern?

Nö. Aber mit Leuten die deine und meine Faszination für C++ nicht teilen und das einfach mehr als "ist halt ein Job" sehen.

Arcoth schrieb:

Zumindest nicht ausreichend viele ausreichend kompetente Seniors.

Dann mach halt einen Style Guide, zwing die Leute ihn sich anzuschauen.

Ja. Leicht gesagt. Schwer zu enforcen.

5cript

Gast3 schrieb:

Ich muss nicht bevormundet werden, nur weil es in manchen Fällen falsch ist. Ich weiß ganz genau was ich tue.

wie gut das man immer nur alleine an einem Projekt arbeitet - und besonders immer nur neuen eigenen Code schreibt - falls du es vergessen hast: es ist immer das höchste Ziel das Produkt mit den notwendigen Feature so schnell und so fehlerfrei wie möglich auf den Markt zu bringen - und dort zu halten/warten - das erzeugt mehr Zeit und Geld um weitere Investitionen in andere Produkte/Features zu tätigen - das bedarf meistens mehr als einen Mitarbeiter - aber wenn man denkt das das Geld für deine Arbeitsleistung so oder so irgendwie erwirtschaftet wird - und nur die Qualität deiner Module entscheident ist wird es mit dem argumentieren ein wenig schwierig

[...]

explicit wenn nötig, sonst optional. Das werde ich verteidigen.
Wenn jemand anders explicit vergisst, ist das nicht mein Fehler.
In diesem Fall ist es wenigstens keine Kastrierung der Programmiererfreiheit.
So kann es mir wenigstens egal sein. Dann würde ich eben oft implicit vorschreiben.

Wenn jemand anders explicit vergisst, ist das nicht mein Fehler.

schön das dir die machbare Qualität der anderen nicht so wichtig ist - oder für dein Gehalt und marktschlagkraft deiner Firma scheinbar unrelevant - es geht nicht darum nur das Ziel zu erreichen - noch schneller(am Markt) und noch fehlerfreier ist noch besser - aber das verstehen viele Entwickler leider einfach nicht

In diesem Fall ist es wenigstens keine Kastrierung der Programmiererfreiheit.

Programmiererfreiheit und Einfachheit wird oft direkt mit "besser" verwechselt - das stimmt so aber leider nicht - und bedarf viel Erfahrung um erkannt zu werden - in ein paar Jahren/Firmen siehst du das vielleicht anders

Gast3 schrieb:

es geht nicht darum nur das Ziel zu erreichen - noch schneller(am Markt) und noch fehlerfreier ist noch besser - aber das verstehen viele Entwickler leider einfach nicht

was ist denn "fehlerfreier", beispielsweise im Vergleich zu "fehlerfrei"?

was ist denn "fehlerfreier", beispielsweise im Vergleich zu "fehlerfrei"?

fehlerfrei ist absolut = 0 Fehler
fehlerfreier = weniger Fehler = befreiter von Fehlern

wollte das Kunstwort auch eher in Hochkommas schreiben

asc

turbo autist schrieb:

Jetzt mal ohne Witz, Computer Science existiert schon mehrere Dekaden und die Leute haben es noch immer nicht hinbekommen, eine gute Programmiersprache zu schreiben?

Schon einmal überlegt das es vielleicht viele gute Programmiersprachen gibt, nur nicht aus deiner Sicht. Jeder Entwickler einer Sprache hat sich sicherlich nicht daran gesetzt eine Schlechte zu schreiben. Die Definition von gut/schlecht ist nur für Jeden eine andere.

Ich habe durchaus Kritik gegen viele Sprachen, ich hasse sogar ein paar. Das heißt aber nicht, das diese Sprache per se schlecht ist.

Ich gehe sogar noch weiter: Ich behaupte das es niemals eine perfekte Sprache geben kann. Den je nach Anwendungsfall können unterschiedliche Ziele im Widerspruch zueinander stehen.

Ethon

Genau das.
Eine komplexe Webapplikation entwickelt man nicht in C, da bedient man sich zb. Java. Und da beschwert man sich nicht über einen GC.
Auf der anderen Seite wird niemand einen Gerätetreiber in Java entwickeln wollen und der GC wird auch niemanden abgehen.

ShadowClone schrieb:

Du scheinst nicht mal zu wissen, dass du z. B. unter rust nichts kompilieren kannst, wo die Lebenszeit von Objekten nicht genau spezifiziert ist

Wenn das so wäre, wie könnte man dann interaktive Programme kompilieren? Denn bei einem Programmlauf eines Programms mit einer objektorientierten Benutzeroberfläche ist oft erst zur Laufzeit bekannt, welche Lebenszeit bestimmte Objekte (z.B. das Hauptfenster) haben, da ich das Hauptfenster ja wegklicken kann, wann ich will.

SeppJ

zufallswert schrieb:

ShadowClone schrieb:

Du scheinst nicht mal zu wissen, dass du z. B. unter rust nichts kompilieren kannst, wo die Lebenszeit von Objekten nicht genau spezifiziert ist

Wenn das so wäre, wie könnte man dann interaktive Programme kompilieren? Denn bei einem Programmlauf eines Programms mit einer objektorientierten Benutzeroberfläche ist oft erst zur Laufzeit bekannt, welche Lebenszeit bestimmte Objekte (z.B. das Hauptfenster) haben, da ich das Hauptfenster ja wegklicken kann, wann ich will.

Du nimmst Lebenszeit viel zu wörtlich.

5cript

Gast3 schrieb:

Wenn jemand anders explicit vergisst, ist das nicht mein Fehler.

schön das dir die machbare Qualität der anderen nicht so wichtig ist - oder für dein Gehalt und marktschlagkraft deiner Firma scheinbar unrelevant - es geht nicht darum nur das Ziel zu erreichen - noch schneller(am Markt) und noch fehlerfreier ist noch besser - aber das verstehen viele Entwickler leider einfach nicht

In diesem Fall ist es wenigstens keine Kastrierung der Programmiererfreiheit.

Programmiererfreiheit und Einfachheit wird oft direkt mit "besser" verwechselt - das stimmt so aber leider nicht - und bedarf viel Erfahrung um erkannt zu werden - in ein paar Jahren/Firmen siehst du das vielleicht anders

Ich habe 7 Jahre Erfahrung und mit kompetenten Menschen entwickelt.
C++ hat sowieso eine lange Lernkurve. Und wer dämlich ist hat mit C++ die falsche Sprache gewählt, der darf gerne wieder Java programmieren.
Ich sehe implizierte Typkonvertierung in vielen Fällen als feature, nicht als Last.
Wer nicht die Zeit investiert zu überlegen, ob ein Konstruktor explicit sein sollte, ... (EDIT: ja da fehlen mir die Worte.)

Aber ja ich habe noch nicht in einer Firma gearbeitet, die so groß ist, dass sie Anfänger einstellen. Bisher nur Akademisch gearbeitet und bei internationalen Firmen.
Aber dass ich solch irrelevante, Themenfremde Sachen überhaupt erwähnen muss...

EDIT / PS: Wer schnelle Ergebnisse von Monkeys haben will soll gefälligst Java verwenden. Das ist ideal für sowas. (Das ist nicht abfällig gemeint, sondern tod ernst)

Ich habe 7 Jahre Erfahrung und mit kompetenten Menschen entwickelt.

also noch relativ jung dabei und meistens Glück gehabt mit den Kollegen

C++ hat sowieso eine lange Lernkurve. Und wer dämlich ist hat mit C++ die falsche Sprache gewählt,
der darf gerne wieder Java programmieren.

nicht alle Entwickler mit denen du mal zusammenarbeiten musst "wählen" ihre Sprache - es gibt viele Firmen
die mehr Spass (und auch Geld) machen würden wären nur einzelne Entwickler eher in der Lage besseren Code zu schreiben - man muss
ja nicht immer kündigen (wenn nötig aber doch)

bessere Sprachen versuchen die Lernkurve kürzer zu machen und das Niveau *aller* Entwickler zu heben - also nicht nur der guten wie du

bisher haben aber alle neuen Sprachen nur neue Nischen gefüllt - die Ausdrucksstärke reduziert - massiven Overhead eingeführt oder noch mehr Design-Lücken erzeugt

mein Liebling bei .Net: manchen Typen implicit nullable:

https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
http://twistedoakstudios.com/blog/Post330_non-nullable-types-vs-c-fixing-the-billion-dollar-mistake

auch für die meisten Entwickler nicht zu verstehen was damit das Problem sein soll - ist doch "nett" das Feature

Ich sehe implizierte Typkonvertierung in vielen Fällen als feature, nicht als Last.
Wer nicht die Zeit investiert zu überlegen, ob ein Konstruktor explicit sein sollte, ... (EDIT: ja da fehlen mir die Worte.)

das Fehlerpotenzial ist einfach sehr gross (ich hab über meine fast schon 20 Jahre so vielen C/C++ Code von verschiedenen Entwicklern/Firmen gelesen und korrigiert das ich dir einfach wiedersprechen muss - die Breite Masse macht viele/diese Fehler)
und deswegen sind z.B. in der C++-Entwicklung Konstruktoren mit nur einem Parameter ohne explicit relativ verpönt
- die meisten statischen Analysetools werten fehlendes explicit als Problem (cppcheck, PVS, Coverity, clang-tidy glaube ich auch)

aus dem Google C++ Styleguide: https://google.github.io/styleguide/cppguide.html#Implicit_Conversions
CERT: https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=3416
...

Aber ja ich habe noch nicht in einer Firma gearbeitet, die so groß ist, dass sie Anfänger einstellen.
Bisher nur Akademisch gearbeitet und bei internationalen Firmen.

ich hab in allen Bereiche Fehler in der Verwendung von convert-ctors gesehen und korrigiert - Azubis bis Profis - ein Vater mit kränkelndem Kind zuhause
kann nicht immer 100% Leitstung/Konzentration bringen - egal wie gut er ist

Aber dass ich solch irrelevante, Themenfremde Sachen überhaupt erwähnen muss...

musst du - es gibt hier auch Leute die erst kurz (<5 Jahre) dabei sind und nur 2 oder weniger Firmen kennen oder C++ schon mal aus der Ferne gesehen habe und dann so
argumentieren als hätte sie mit Stroustrup und den anderen über Jahre in eine WG gewohnt und mitgearbeitet

EDIT / PS: Wer schnelle Ergebnisse von Monkeys haben will soll gefälligst Java verwenden.
Das ist ideal für sowas. (Das ist nicht abfällig gemeint, sondern tod ernst)

ich meinte nicht die extreme zwischen dir und Monkeys - ganz normale durchschnittliche (die meisten) Entwickler machen einen Haufen Fehler und sind schlecht
Es gab bisher noch kein Projekt in C/C++ das nicht ohne fiese Aliasing-Fehler, Memoryleaks, ctor-Conversion-Fehler usw. (die Liste ist lang)
durch meine Hände gekommen ist - egal wie gross/klein/International oder toll die Firma war - die einfach Kombination von cppcheck, PVS, ASan/TSan, VS/gcc/clang in Kombination und meistens kommst was böses raus

Wenn man heute bei C++ einen Kompatibilitätsstrich ziehen würde und die ganze mittlerweile klar gefährlichen Sprachkonstrukte weglassen und härtere implicite Regel durchsetzen würde - nebst Module/Concepts usw. - müssest du auch nicht so viel mehr Tippe aber die Qualität der anderen Module die nicht von dir kommen würde trotzdem steigen (weltweit)

bei dem Design neuer Sprache ist das Ziel die globale Verbesserung von Entwicklungsleistung nicht die Arbeit von ein paar guten, wenigen Entwicklern

asc

5cript schrieb:

Ich habe 7 Jahre Erfahrung und mit kompetenten Menschen entwickelt.

Ich hoffe in zumindest 2 Unternehmen, sonst kann man Kompetenz nicht unbedingt gut einschätzen. Zudem sind 7 Jahre nicht unbedingt viel Empfehlung.

5cript schrieb:

Aber ja ich habe noch nicht in einer Firma gearbeitet, die so groß ist, dass sie Anfänger einstellen.

Meiner Erfahrung nach stellen eher kleine Firmen Anfänger ein, kosten ja weniger.

Ethon

Ich habe genug sehr kompetente Menschen erlebt, die Java sehr zu schätzen wissen, ich sehe nicht im geringsten, warum die Sprache möglichst "kompliziert" sein muss, nur weil der Entwickler kompetent genug ist, die Sprache zu verwenden.

Es gibt halt einfach nicht die universale Sprache.

Ethon schrieb:

Ich habe genug sehr kompetente Menschen erlebt, die Java sehr zu schätzen wissen, ich sehe nicht im geringsten, warum die Sprache möglichst "kompliziert" sein muss, nur weil der Entwickler kompetent genug ist, die Sprache zu verwenden.

Es gibt einen sehr deutlichen Unterschied zwischen "nicht möglichst kompliziert" und "künstlich beschnitten". Dass die Java-String-Klasse den +-Operator überlädt, dies den Nutzern für ihre eigenen Klassen aber explizit vorenthalten wird, ist ein typisches Beispiel dieser Philosophie. Selbes gilt auch bei Mehrfachvererbung, die bei Interfaces dann kurioserweise doch wieder erlaubt ist, oder bei integrierten Datentypen, von denen es nur vorzeichenbehaftete gibt.

Ethon

String ist halt bei Java eine Mischung aus Builtin und Library.
Ansonsten kann ich sagen, dass ich Operatorenüberladung in Java noch nie vermisst habe, ich überlade auch in C++ keine Operatoren, finde ich richtig unnötig und kann andere Entwickler unnötig verwirren.
Es gibt wenig Fälle, in denen Operatorenüberladung wirklich logisch ist, zb wenn man eine Klasse für komplexe Zahlen oder etwas wie BigInteger entwickelt. Und da fällt mir kein Zacken aus der Krone, a.add(b) statt a + b zu schreiben.
Abgesehen davon sind die Usecases für diese Klassen auch ziemlich selten und eher lokal.
Grundsätzlich finde ich es positiv, wenn keine Operatorenüberladung mit der Mächtigkeit von C++ möglich ist. Dinge wie Boost.Spirit sind für mich nichts außer Spielereien.
Da gefällt mir der Ansatz von D schon besser, dass alle relationalen Vergleichsoperatoren der selben Ordnungsrelation zugrunde liegen, weniger Unfug möglich.

Das mit der Mehrfachvererbung und den Interfaces ist für mich absolut logisch: Mehrere Interfaces produzieren keine Probleme wie zb. das diamond problem.

Columbo

Ethon schrieb:

Dinge wie Boost.Spirit sind für mich nichts außer Spielereien.

Einige Arbeiten mit Spirit (und erfolgreich, wie du dir vorstellen kannst). Nur weil du keine application domain kennst, ist es nicht nutzlos oder suboptimal.

Ansonsten kann ich sagen, dass ich Operatorenüberladung in Java noch nie vermisst habe, ich überlade auch in C++ keine Operatoren, finde ich richtig unnötig und kann andere Entwickler unnötig verwirren.

Oh, wow. Dass wir strings mittels == vergleichen können ist ja so verdammt verwirrend. Und diese ganzen + Operatoren für string und chrono::duration , auch so ein Blödsinn! Wer braucht schon Syntax?

Mehrere Interfaces produzieren keine Probleme wie zb. das diamond problem.

Das Diamond Problem ist kein Problem, weil es eine Lösung hat. Und wir können leere Basisklassen als Interfaces einsetzen, kein Problem.

SideWinder

Operatorenüberladung geht mir nur dann ab, wenn ich mathematisch anspruchsvollere Dinge baue - etwas was mir im Java-Bereich wahrscheinlich einfach nicht häufig passiert -> wiederum, richtige Sprache für den richtigen Einsatzzweck.

Das Diamond-Problem hat zwar eine Lösung, die ist aber auf Sprachlevel schwieriger umzusetzen weil das Speicherlayout eines Objektes dadurch verkompliziert wird. Das macht es schwieriger eine VM für die Sprache zu schreiben, etc. pp.

MfG SideWinder

5cript

Ethon schrieb:

Ich habe genug sehr kompetente Menschen erlebt, die Java sehr zu schätzen wissen, ich sehe nicht im geringsten, warum die Sprache möglichst "kompliziert" sein muss, nur weil der Entwickler kompetent genug ist, die Sprache zu verwenden.

Es gibt halt einfach nicht die universale Sprache.

Was ich ausdrücken wollte: Java ist ein Sprache, bei der man mit wenig regeln und sprachmitteln saubere, leicht testbare Programme schreiben kannst mit schwer zu vermodelnder Struktur.
C++ ist einfach ein großer Haufen Mittel etc und mit C++17 wirds noch umfangreicher und schwerer für Anfänger alles gleichzeitig im Kopf zu haben oder zu kennen.

Ich hoffe in zumindest 2 Unternehmen

ja 2 In dem einen jetzt seit 1.5 Jahren.

Zudem sind 7 Jahre nicht unbedingt viel Empfehlung

In meinem Alter schon.
Ich will sowas auch gar nicht erwähnen, aber ich fühlte mich ziemlich angegriffen nach dem Motto: "Was weißt du denn schon?"

Und wenn ich Leute mit Java-philosophie "entfernen oder ändern wir das, weil man dann weniger falsch machen kann" an C++ rangehen, dann reagiere ich außerordentlich allergisch.

Granted: explicit hätte meinetwegen auch andersrum sein können, aber dann würde es gar keiner benutzen.