Wieso gibt es keine gute Programmiersprache?
-
hustbaer schrieb:
(viele kennen das Keyword gar nicht)
Du arbeitest also mit Anfängern?
Zumindest nicht ausreichend viele ausreichend kompetente Seniors.
Dann mach halt einen Style Guide, zwing die Leute ihn sich anzuschauen.
Siehst du dich etwa als Junior?
Ich bin Student, sonst gar nichts.
-
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
wenn explict von Anfang an implizit gewesen wäre (geht eben nicht wegen Kompatitbilität) müsstes du dich auch nicht wund tippen und viele Fehler die daran hängen wären damit schon mal vom Tisch und davon gibt es eben viele kleine Dinge die in C++ wegen der Kompatitbilität nicht so supertoll sind - und arbeite selbst schon >20 Jahre mit C/C++ in allen Tiefen
-
Hi,
allseitig gute Programmiersprachen gibt es wirklich nicht. Ich vermute mal, es wird sie auch nicht geben. Jede Programmiersprache ist eine Abstraktion und Einschränkung auf eine bestimmte Anwendung.
SQL ist z.B. eine sehr gute Sprache zum arbeiten mit Datenbanken. Aber ein Programm schreiben, das Wellen auf Dauerbruchfestigkeit nachweist wäre schon sehr anspruchsvoll.
Für solche Berechnungen war Fortran damals der Renner (auf dem MainFrame auch heute noch). Mit Fortran Datenbanken auswerten mag gehen, aber es ist ein Krampf.
Cobol ist in der Finanzmathematik kaum zu schlagen, aber damit einen CAD-Arbeitsplatz programmieren, da nehmen wir aber doch lieber was anderes.
In den letzten Jahren der DDR war Forth eine regelrechte Hype. Alles sollte in Forth gehen. Nur Forth wurde zur Echtzeitsteuerung von Radioteleskopen entwickelt. Sicher auch für Waschmaschinen- und Geschirrspülersteuerungen sehr brauchbar. Aber will man damit wirklich ein Buchhaltungsprogramm schreiben?
C war von Hause aus als maschinenunabhängiger Assembler geplant. Ist eine sehr schöne kleine elegante Sprache, die auf Grund ihrer Abgrenzung gute Möglichkeiten für leistungsfähige und fehlerarme Compiler bietet. Ich habe damals sehr gerne mit C gearbeitet. Aber in Sachen Abstraktionsmöglichkeiten und Objektorientiertheit hat sie ihre Grenzen. Für kleine Sachen immer noch gut zu brauchen, aber mit größer werdenden Programmen sehr schnell unhandlich. Und es erfordert sehr viel Disziplin vom Programmierer, die nicht jeder hat.
Als eierlegende Wollmilchsäue waren damals PL/1 und Algol68 angedacht. Beide sehr leistungsfähig, vor allem PL/1 von Echtzeitprogrammierung bis Finanzmathematik geeignet. Aber einfach zu groß, zu unhandlich, zu kompliziert.
Heute spricht mit Recht von beiden keiner mehr.
ADA war als Alleskönner-Sprache für Anwendungen mit höchstem Sicherheitsanspruch ausgelegt. Flugzeugsteuerungen werden wohl zum Teil heute noch in ADA programmiert. Aber kennt sonst noch einer jemanden der ADA verwendet.
Pascal war als Lehrsprache entwickelt. Das reine Pascal hat aber auch nicht überlebt. Allerdings hat es unter Borland in der weiterentwicklung Delphi ein zweites Leben (und insgeheim ganz viele Eigenheiten von C++) eingehaucht bekommen. Für nicht zu große Anwendungen unter Verwendung der VCL und für Datenbankanwendungen ist es immer noch eine sehr leistungsfähige Sprache, die sich schnell und übersichtlich programmieren lässt und selbst vor parallelisierung nicht zurückschreckt. Wird aber (abgesehen vono Lazarus) nur vom Borland-Nachfolger Embarcadero angeboten.
Für parallelverarbeitung war lange Zeit Occam der Renner, gibts hier bei uns im Forum noch einen, dem die Sprache was sagt?
C++ hab ich damals mit dem alten Borland Turbo-C++ gemacht und war sehr zufrieden damit. Mit den alten C++Buildern von Borland war ich dagegen nicht so sehr zufrieden. Programme, die ohne Fehlermeldungen komplett abstürzen und auch die Entwicklungsumgebung mit runterreißen machen keinen Spaß. Irgendwie war damals die Anbindung der Delphi-VCL an C++Quelltext nicht so optimal gelöst. Das konnte Delphi damals besser. Aber trotzdem ist C++ eine extrem leistungsfähige Sprache, die aber in ihrer Komplexität mittlerweile PL/1 überholt haben dürfte. Vorteil von C++, dass man mit dem Befehlssatz von C schon anfangen kann erste Programme zu schreiben und sich schrittweise tiefer einarbeiten kann. Vorteil auch gute Literatur für C++ (Stroustrup, Scott Meyers...). Aber auch C++ benötigt den disziplininierten Programmierer. Dafür sind die OOP- und Abstraktionsmöglichkeiten sehr gut, so dass auch sehr große Projekte noch gut händelbar sein können.
Java ist damals angetreten, ein C++ für alle die sein zu wollen, die für C++ nicht gut oder nicht diszipliniert genug waren. Mittlerweile ist es aber auch schon ein ziemlicher Saurier geworden.
Bei mit im Betrieb haben sie damals "Compiler" für die Übersetzung von NC-Maschinen-Programmen, sowie eine Steuerung eines Integrierten Fertigungsabschnittes in dBase II programmiert. Hat auch funktioniert. dBase war da, und einer des konnte auch (ich nicht). Der Rest waren Eda-Kosten (der war ja eh da).
Irgendwie ist die Summe der Huckel in der Straße eigentlich konstant. Sie sid nur unterschiedlich angeordnet.Gruß Mümmel
-
Andromeda schrieb:
hustbaer schrieb:
Ausser Blabla noch was beizutragen?
Schau mal hier: http://winfuture.de/news,87623.html
Sieht also aus, als wäre C# sehr stabil. Es gibt einfach mehr Vielfalt als vor 5 Jahren. BTW: stärkster Anstieg in den Top10: Visual Basic .NET.
MfG SideWinder
-
Was mich eher wundert als die Abwesenheit universell idealer Programmiersprachen ist, daß die heute verwendeten Paradigmata überwiegend aus den 1950er bis 1970er Jahren stammen. Oder gibt es Features in gängigen modernen Programmiersprachen, die nicht zumindest im Prinzip schon zwischen 1950 und 1980 erfunden worden waren?
-
Hi Zufallswert,
zufallswert schrieb:
Was mich eher wundert als die Abwesenheit universell idealer Programmiersprachen ist, daß die heute verwendeten Paradigmata überwiegend aus den 1950er bis 1970er Jahren stammen. Oder gibt es Features in gängigen modernen Programmiersprachen, die nicht zumindest im Prinzip schon zwischen 1950 und 1980 erfunden worden waren?
Ich würde sagen, generische Programmierung ist neuer.
Gruß Mümmel
-
Gab es Borrow-Checker und das Spezifizieren von Lifetimes auch davor? Zur Compilezeit?
-
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.
-
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.
-
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 Fehlernwollte das Kunstwort auch eher in Hochkommas schreiben
-
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.
-
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.
-
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.
-
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-mistakeauch 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 istAber 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 mitgearbeitetEDIT / 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 rausWenn 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
