Ich muss sagen, vom kurzen Überfliegen her, zig gefällt mir sehr gut.
Sicherer als C, aber weniger restriktiv als rust wegen weniger starken
Objektlifetimerestriktionen (wobei das einige auch als nachteil sehen
könnten).
Ich hab mir ja auch schon überlegt, einmal eine eigene Sprache zu
machen, und ich muss sagen, zig kommt sehr nah an meine Traumsprache
heran. Macros mit compile time funktionen ersetzt, reflection, und alles
ohne GC und solchen kram, auch das Error handling hätte ich nicht anders
gewollt. Sehr schöne Sprache.
Was mir nicht so gefällt ist, dass es keine headerfiles, also keine
getrennte explizite interfacedefinition zu geben scheint. Statdessen
wird dass wenn benötigt aus den sourcen extrahiert. Und beim Kompilieren
schaut es glaub ich wie rust auch die ganzen Sourcen an, statt einzelne
Object files zu generieren? Es scheint auch noch ein eigenes build
system zu sein, das ähnlich wie meson zu funktionieren scheint?
Und dass es in structs Methoden gibt finde ich einfach unnötig.
Was mir noch unklar ist:
* In C kann ich einen upcast, sowie ein container_of makro machen. In
C++ gibt es statdessen vererbung. Wie macht man sowas in zig?
* In c bau ich mir beim Kompilieren oder beim Start gerne mit dem
section oder contructor Attribut eine Liste auf, mit Implementationen
von Interfaces, für eine art inversion of control. Das ist recht wichtig
für meinen Programmierstil geworden. Kann ich sowas auch in zig machen?
Eine Sache, die ich noch schade finde, ist, dass sie vorhaben, einen
Paketmanager hinzuzufügen: https://github.com/ziglang/zig/issues/943
Aber im grossen und ganzen finde ich zig gut, ich habe einfach ein wenig
die Befürchtung, dass es sich in Zukunft noch verschlimmbessern könnte /
es seinen Peak an guten/notwendigen Ideen bereits hinter sich hat, und
jetzt noch unnötiger kram dazu kommt...
🐧 DPA 🐧 schrieb:> Eine Sache, die ich noch schade finde, ist, dass sie vorhaben, einen> Paketmanager hinzuzufügen:
So lange das Managment nicht unbedingt auf irgendeinem Server liegt
sondern auch komplett lokal laufen kann verstehe ich noch nicht die
Nachteile eines Paketmanagers (cargo von Rust kann z.b. auch völlig ohne
einen Server laufen)
Kann jemand mal detailiert erkläre was die Nachteile sind - aber bitte
auch mögliche Vorteile nennen, damit die Kritik nicht so einseitig wird
cppbert3 schrieb:> Andre Kelley
wow, ich beneide die Leute, die mit 19(?) so selbstsicher und von sich
selbst so überzeugt sind ;-)
"Zig competes with C instead of depending on". Na dann, viel Spass.
Wie ist Python entstanden? Guido war krank und hat eine neue
Programmiersprache erfunden? Wegen Lockdowns wird es in diesem Jahr wohl
ein paar Tausend Programmiersprachen geben (die natürlich alle besser
sind und "competes with C").
cppbert3 schrieb:> Kann jemand mal detailiert erkläre was die Nachteile sind - aber bitte> auch mögliche Vorteile nennen, damit die Kritik nicht so einseitig wird
Naja, der Vorteil ist, man gibt die Dependencies an, und rekursiv wird
alles nötige herunter geladen. Das ist zugleich auch der Nachteil. Man
braucht etwas, eine Dependency hinzufügen ist einfach. Das führt dann
schnell mal dazu, dass man sich überall sofort indirekt hunderte
Dependencies einfängt. Verwaltet man Dependencies stattdessen manuell,
gibt es ein Inzentiv, diese möglichst zu vermeiden, dann es ist Arbeit,
diese herunterzuladen und aktuell zu halten. Das hilft auch, den
Überblick darüber zu behalten, wovon man tatsächlich abhängig ist, und
vereinfacht das Problemmanagement. Zudem werden so fälle
unwahrscheinlicher, in denen man mehrere Versionen der selben Library
brauchte, rein gezogen von unterschiedlichen Dependencies, und solcher
kram. Insgesamt macht das ein Projekt robuster & kleiner.
Das führt aber auch zu massiver Code Duplikation über tausende von Libs
weil jeder seine eigenen Micro Implementierungen von XYZ macht
Für profesionelle Entwicklung wären die Packages sowieso lokal verwaltet
und ich kann mir irgendwie nicht vorstellen das dann die wichtigen und
gern genutzten Libs die sich über die Zeit herauskristalisieren
hyperdependcies als Qualitätsmerkmal hätten, natürliche Auslese
verhindert sowas doch
Für Anfänger und die Open Source Community wäre eine echte out of the
box buildbarkeit schon eine Erleichterung
Ich habe oft das Gefühl das die Argumente mit den zu vielen Dependencies
nur von Leuten kommen die kaum Abhängigkeiten haben oder sehr viel
selber machen wollen oder müsse, oder nicht trennen zwischen Hobby und
professioneller Entwicklung, welche Sprache duduie so was kann stirbt
denn gerade oder ist schon an der Dependecyhölle gestorben?
can't see sharp schrieb:> wow, ich beneide die Leute, die mit 19(?) so selbstsicher und von sich> selbst so überzeugt sind ;-)> "Zig competes with C instead of depending on". Na dann, viel Spass.
Denkst du ernshaft das eine Programmiersprachentwicklung kein Anzeichen
von Überheblichkeit oder einem Gotteskomplex ist?
Wird schon seit 4 Jahren dran gearbeitet und er ist wohl ein bisschen
älter als 19 :)
Und heute steht Gerhard wieder auf der Seifenkiste und versucht
Windmühlen aufzuhalten;-)
Ist es nicht vielleicht besser im großen Gesamtbild trotz aller
Argumente für Verbesserungen oder neue Ansätze mit C weiterzumachen?
Ich könnte mir in der Firma nicht vorstellen, Projekte die gepflegt
werden zu müssen, auf eine neue Sprache trotz aller Möglichen
Verbesserungen, umzuschreiben. Das hat wegen dem Zeitaufwand und damit
zusammenhängenden Kosten, Fehlersuche, Prüfen, keinen wirklichen Sinn.
Man mag darüber streiten, aber in der Firma verwenden wir nur
kommerzielle Werkzeuge wie IAR, KEIL, Atollic/ST. Sicherlich sind diese
Werkzeuge auch nicht perfekt, aber mit Erfahrung und Flexibilität sind
das keine Show-Stoppers. In über dreissig Jahren sind wir damit ganz gut
klargekommen. Die Produkte sprechen für sich selbst.
Der Konsumbereich ist da eher das wirkliche Sorgenkind. Wegen der
schnellen Marktzyklen wird viel SW freigelassen die im industriellen
Umfeld unakzeptabel wäre. Es gibt leider viele grottenschlechte,
schlecht durchdachte, schwer bedienbare Konsumerprodukte. Ausnahmen
bestätigen da eher die Regel. Man mag an Apple viel zurecht kritisieren,
aber durchdacht sind die meisten Gerätschaften schon und vom Laien in
der Regel gut bedienbar. Die Geräte sind meist extrem zuverlässig.
Bei neuen Projekten könnte man ja möglicherweise Versuche zur
Erfahrungssammlung an kleinen Projekten anstellen.
Mit dem Feind, den man kennt, ist in der Regel leichter klarzukommen.
Man hüte sich gegen unbekannte Gegner anzugehen. Das geht meistens nicht
gut.
Mit C/C++ kommt man mit Erfahrung trotz aller Einwände im industriellen
Umfeld meist ganz gut zum Ziel. Wenn man bewährte Funktionen und
Praktiken immer wieder verwendet hat man dann doch zuverlässige
Ressourcen. Mit Disziplin, Vermeidung bekannter Schwächen und
Gewohnheiten und ausreichender Planung lassen sich viele "Real World"
Anwendungen in der Industrie wiederholt mit großer Zuverlässigkeit
verwirklichen.
Was ich persönlich sehr kritisiere ist, daß viele auf den Markt
geworfene Produkte extrem unfreundliche Bedienung und oft zahlreiche
Bugs und fehlende notwendige Fähigkeiten vermissen die einen zur
Weissglut irritieren können. Anstatt im Prinzip gut durchdachte Designs
über Generationen graduell zu verbessern, rennt man von einem Produkt
zum andern die alle hudelig ins Leben gebracht wurden und zahlreiche
Unzulänglichkeiten werden aber nie angegangen. Da lasse ich als Kunde
lieber die Finger davon weil Enttäuschung garantiert ist.
Die Chinaproduktionsmaschine läuft auf Hochtouren und überschwemmt die
Welt...
Ich kaufte mir vor über zehn Jahren einen Alpine Auto Media Player. Die
HW funktioniert super. Da gibt es nichts auszusetzen. Die SW verursacht
aber zahlreiche kleine Irritierungen. Da wurde ein 320x240 Pixel
wunderschönes TFT Display eingebaut. Man hätte da wirklich ein
vollendetes Design erarbeiten können. Trotz der sehr guten HW - ein
Krüppel. Das Teil erhielt nie irgendwelche SW Upgrades. Folgende
Produkte waren auch nicht wesentlich besser oder vollständiger. So, als
Kunde muß man notgedrungen (zähnekirschend) mit den Unzulänglichkeiten
leben weil auch die Nachfolgemodelle ähnlich mangelhaft sind. Das ist
der Zustand unserer modernen Produkte. Wir haben ein Meer an
unvollständiger Elektronik um uns herum die lange Listen von Fähigkeiten
haben, aber oft doch nicht zufriedenstellend funktionieren. Anstatt
Produkte langfristig zu verbessern und den Kundenwünschen anzupassen,
läuft man von Produkt zu Produkt die alle die gleichen fundamentalen
Mängel aufweisen. Ich könnte da wesentlich mehr Beispiele geben. Die
einzige Ausnahme bilden teils semi und professionelle wichtige Produkte
bekannter großer Hersteller die sich die Zeit für ausgedachte Produkte
nehmen müssen weil sie sonst keiner kaufen würde.
Ich habe eine Android Media Box. Die HW funktioniert super. Die SW ist
aber eine reine Katastrophe. Ich kaufte mir das Ding hauptsächlich um
Youtube Videos am Fernseher anschauen zu können. Das Teil hat eine IR
Remote. Wenn ich jetzt YT Sachen navigieren möchte braucht man
allerdings eine Tastatur und Maus um damit einigermaßen bequem umgehen
zu können. Wenn nun jemand anruft und ich die Darbietung unterbrechen
möchte, muß ich es mit der Maus machen anstatt die IR-Remote dafür
verwenden zu können. Irritiert furchtbar wie unausgedacht das ganze
Zeugs ist. Andauernd muß SW updated werden. Andauernd muß daran
rumgebastelt werden anstand zuverlässig wie ein Industrieprodukt
dauerhaft zu funktionieren. Da ist die Frage, C oder ZIG eher unwichtig.
Da gibt es wesentlich größere Fische zu braten. Die Sw Tools sind da das
geringste Problem.
Die Zukunft vorauszusagen ist meist töricht. Trotzdem wage ich
vorauszusagen, daß C und C++ noch lange "Fußtritte" austeilen wird;-)
Die Gerüchte vom Ableben von C sind bestimmt ketzerisch übertrieben.
Abgesehen davon kann jeder in der Sprache seine Projekte verwirklichen,
wie für ihn die Programmier-Schnauze gewachsen ist. Vielen Kunden ist
das meist egal so lange es funktioniert.
Ich habe mir die Zig Sachen auch angeschaut. Ich habe den Eindruck, bis
Zig industrietauglich und im embedded Bereich tatsächlich praktisch
vergleichbar verwendbar ist, werden noch viele Forellen ihre Bäche
hinaufschwimmen müssen.
Für die jungen Entwickler neuer Generationen hat es ja Sinn über den
Tellerrand zu schauen und die für die Umstände besten Werkzeuge und
Praktiken zu etablieren. Aber für uns alte Entwickler ist es in der
Regel nicht so nützlich. Da gilt es eher, Problem schnell und
zuverlässig mit dem schon vorhanden Erfahrungsschatz zu lösen da man
kaum jemals genug Zeit hat sich mit neuen Wegen vertraut zu machen. Das
ist besonders in jenen Firmenbereichen wichtig wo großer Kunden und
Zeitdruck vorliegt und Spielen mit neuer Technik oft verpönt ist. Da
sind die meisten von uns doch schon ziemlich in die Gleise eingefahren
und scheuen das Neue;-)
Hallo
Aus reiner Hobbyistensicht der -zumindest was er unter richtig
Programmieren können bezeichnet- immer noch Anfänger ohne jeden
Beruflichen und "offiziellen" ausbildungmäßigen Hintergrund hat:
Erst wenn jeder Nutzer seine eigne Programmiersprache hat, "jeder" der
es kann (also Entwickler einer Sprach) die Kuh finanziell gemolken hat
bzw. sein Ego auf "ewig" konserviert hat (irgendwo wird die Sprache auch
2100 erwähnt sein...) gibt es genug Programmiersprachen...
Ehrlich: Irgendwann muss doch Schluss sein - gibt es denn nicht wirklich
mehr als genug Sprachen?
Wäre es nicht Zeit endlich etwas zu entwickeln was das
"Programmierdenken" mit weniger Aufwand und Anstrengung vermittelt.
Programmiersprachen -egal welche- sind von ihrer "Grammatik" her mehr
oder weniger schnell erlernbar besonders wenn es nicht mehr die erste
ist- aber wirklich programmieren können ist einfach unglaublich
anspruchsvoll und oft auch entnervent (sicherlich auch in der Profiliga)
- da müsste es mal den "genialen" Durchbruch -Nürnberger Trichter ?!-
geben...
So was hätte den "Friedensnobelpreis" verdient und würde tatsächlich
auch "Power to the people geben".
Ja ich weis auch nicht wie das gehen sollte...
Hobbyist
Hobbyist schrieb:> Ehrlich: Irgendwann muss doch Schluss sein - gibt es denn nicht wirklich> mehr als genug Sprachen?
Nein.
Es entstehen ständig neue Dinge in neuen Sprachen, die dann später
teilweise auch in klassische Sprachen integriert werden.
Neue Sprachen sind der Innovationsherd. Auch wenn die neue Sprache
ansich nicht so erfolgreich ist, kann sie einen signifikanten Einfluss
haben.
MaWin schrieb:> Nein.> Es entstehen ständig neue Dinge in neuen Sprachen, die dann später> teilweise auch in klassische Sprachen integriert werden.
Das glaube ich nicht.
Was ist denn so Neue, was es früher nie gegeben hat?
Ich fand dieses Video einfach nur super:
https://www.youtube.com/watch?v=P2yr-3F6PQo
Es ist an der Zeit eine Sprache zu wählen und damit zu arbeiten. Wir
kennen doch die Geschichte aus dem Alten Testament zum Turmbau und
vielen Sprachen ;-)
MaWin schrieb:> Hobbyist schrieb:> Ehrlich: Irgendwann muss doch Schluss sein - gibt es denn nicht wirklich> mehr als genug Sprachen?>> Nein.> Es entstehen ständig neue Dinge in neuen Sprachen, die dann später> teilweise auch in klassische Sprachen integriert werden.> Neue Sprachen sind der Innovationsherd. Auch wenn die neue Sprache> ansich nicht so erfolgreich ist, kann sie einen signifikanten Einfluss> haben.
Z.b. constexpr-if kommt Ursprünglich als Erstumsetzung aus D
und seit Rust ein erste produktive Umsetzung des Ownershippings gezeigt
hat probieren viele Sprachendesigner das besser oder anders zu
integrieren
cppbert3 schrieb:> Z.b. constexpr-if
Ja, und?
Bei C gab es am Anfang wohl auch kein volatile, const, etc..
Eine Sprache weiterentwickeln oder wegwerfen und sich eine andere
ausdenken - das ist nicht das Gleiche.
Auch die deutsche Sprache entwickelt sich weiter. Das ist normal. Aber
es ist nicht normal immer wieder von vorne anzufangen. Weil das ja so
viel besser ist. Nein, ist es nicht.
can't see sharp schrieb:> Das glaube ich nicht.> Was ist denn so Neue, was es früher nie gegeben hat?
Erreichen konnte man das auch alles schon früher, aber wenn
Typensicherheit und Optimierbarkeit ins Spiel kommen stossen einige
Sprachen einfach an Ausdrucksgrenzen z.B. unklares ptr Aliasing in C/C++
verhindern einen haufe Optimierung, oder noch schlimmer bedürfen sehr
komplexe Optimizer um alles raus zu holen
Trivial wirkende Erweiterungen von Sprachen können imensen Einfluss auf
die Backendsimplifizierung beitragen, aber das stört eben die wenigsten
- ist ja nicht deren Bier das guter, schneller Code entsteht, wen juckt
schon die komplexität der Toolchain
Klar ist Rust das viel schlimmer, aber Zig ist eher ein C mit
typsicheren generics
can't see sharp schrieb:> Das glaube ich nicht.>> Was ist denn so Neue, was es früher nie gegeben hat?
Schaue dir einfach mal an, was in die neuen C++-Standards alles so
einfließt.
Das wurde signifikant von neueren Sprachen und Nischensprachen
beeinflusst.
can't see sharp schrieb:> cppbert3 schrieb:> Z.b. constexpr-if>> Ja, und?> Bei C gab es am Anfang wohl auch kein volatile, const, etc..>> Eine Sprache weiterentwickeln oder wegwerfen und sich eine andere> ausdenken - das ist nicht das Gleiche.
Und argumentierst einseitig, keiner hat geschrieben das neue Einflüsse
nur von anderen Sprachen kommen
Aber leider hat es C bis heute nicht geschafft eine cleane Lösung für
Macros anzubieten, nicht weil das keiner braucht sondern weil nur noch
kleinständerungen gemacht werden welche die kompatibilität nicht brechen
cppbert3 schrieb:> Aber leider hat es C bis heute nicht geschafft eine cleane Lösung für> Macros anzubieten, nicht weil das keiner braucht
Ich habe solche unglaubliche Geschichten über Macros gehört! Wie sie
mächtig sich und was sie so alles ermöglichen.
In Lisp.
Wo ist Lisp jetzt?
"The most powerful programming language is Lisp. If you don't know Lisp
(or its variant, Scheme), you don't know what it means for a programming
language to be powerful and elegant. Once you learn Lisp, you will see
what is lacking in most other languages. ...."
https://stallman.org/stallman-computing.html
can't see sharp schrieb:> Ich habe solche unglaubliche Geschichten über Macros gehört! Wie sie> mächtig sich und was sie so alles ermöglichen.>> In Lisp.
und welchen Bezug hat das zu Vereinfachungen, Substitution von C-Macros
in Zig zu tun?
Ich freue mich, wenn ein junger Menschen eine neue Sprache erschafft.
Wie soll man denn sonst ein Experte darin werden? Wo sollen sonst
Innovationen herkommen?
So wie SW-Entwickler ihr eigenes Bubblesort schreiben müssen, braucht
der Sprachexperte der Zukunft diese Erfahrung.
Wie soll jemand Feuer fangen, wenn er sich für C ein Feature überlegt
und 11 Jahre auf dessen Realisierung hofft.
Ich glaube es gibt so eine Konstante von etwa 6000 Sprachen. Natürliche.
Und ebenso viele Programmiersprachen.
Ob zig was wird? Das hängt davon ab, was ihr draus macht.
Ich frage mich auch echt woher diese Besorgnis kommt die hier manche auf
die eine oder andere Art äussern, keiner zwingt zum Umstieg oder einer
vollständigen Portierung aller Mio Zeilen Code die vorhanden sind noch
wird irgendein globaler Entwicklerspirit dadurch verwässert, ich glaube
die meisten Entwickler die pro-Aktiv gegen Neu oder Weiterentwicklungen
argumentieren haben einfach persönlich kein Interesse daran und wollen
diese Abneigung aber als Erfahrung verkaufen - aber um deutlich zu
bleiben: damit meine ich nicht das Perl kein Fehler war :)
Es macht keinen Sinn sich in eine Sprachendiskussion zu involvieren wenn
man an Sprachendesign keinen Spass hat und nur an den alten oder
zukünftigen Code in seiner jetzigen wahl oder pflichtsprache denkt, egal
aus welchen Gründen
cppbert3 schrieb:> Ich frage mich auch echt woher diese Besorgnis kommt die hier manche auf> die eine oder andere Art äussern,
Es ist die Angst abgehängt zu werden. Die Angst zum alten Eisen zu
gehören.
Diese Leute können vielleicht C und wollen sich nicht mehr
weiterbilden. Wenn jetzt aber die Welt plötzlich auf eine neue Sprache
umsteigt, dann werden sie nutzlos. Das muss also verhindert werden,
indem dagegen gewettert wird.
MaWin schrieb:> cppbert3 schrieb:> Ich frage mich auch echt woher diese Besorgnis kommt die hier manche auf> die eine oder andere Art äussern,>> Es ist die Angst abgehängt zu werden. Die Angst zum alten Eisen zu> gehören.> Diese Leute können vielleicht C und wollen sich nicht mehr weiterbilden.> Wenn jetzt aber die Welt plötzlich auf eine neue Sprache umsteigt, dann> werden sie nutzlos. Das muss also verhindert werden, indem dagegen> gewettert wird.
Ich kann mir so was schwer vorstellen, ich glaube es ist eher die
Kombination aus Abneigung gepaar mit dem väterlichen Schutz vor
Enttäuschung wenn die zwölfte neue Sprache doch nicht die Probleme so
einfach löst obwohl doch eigentlich nur Erfahrung fehlt
Und es gibt wirklich Entwickler die sich für eine Sprache entscheiden,
wie bei einer Hochzeit bis das der Tod sie scheidet, das heisst nicht
das sie dann automatisch besonders gut oder schlecht darin sind, für
solche Entwickler ist diese "Vielweiberei" einfach nicht ihr Ding, ich
glaube da kommen auch oft diese Alles-portieren-Aussagen her, obwohl
natürlich niemand 7 verschiedene Sprachen in einem Projekt haben will
(ich hatte mals eins mit gleichmässig Verteilt, Java, Python, C, C++ und
C#, übel übel)
cppbert3 schrieb:> Und es gibt wirklich Entwickler die sich für eine Sprache entscheiden,> wie bei einer Hochzeit bis das der Tod sie scheidet,
Für mich ist Englisch ein Werkzeug. Ich nehme es her, kann es nicht
schlecht. Es begeistert mich nicht. Ich mag aber Italienisch, die
Sprache gefällt mir, ich kann viel verstehen. Aber ich nehme es selten
her.
Für mich ist C ein Werkzeug. Früher konnte ich es nicht leiden, heute
nehm ich es gerne her.
Früher hab ich Englisch gehasst, was man an den Noten gemerkt hat. Von
einem Schuljahr aufs andere hab ich nur noch Einsen und Zweien in
Englisch gehabt.
Auch Programmiersprachen haben was mit Sympathie zu tun. Der Eine findet
formatierungsabhängige Sprachen unterirdisch, der Andere wird Pointer
nie kapieren.
Neue Sprachen haben neue Konzepte. Und die soll man sich ruhig mal
anschauen und verstehen. Das hilft einem auch bei seiner
Lieblingssprache / Arbeitssprache. Und wenn man die neue Sprache
halbwegs kann, kann man sie auch evtl. irgendwann als Arbeitssprache
verwenden.
Ich trauere Objective-C hinterher zusammen mit den
NextStep-Bibliotheken.
Mal angeschaut.
Fazit: Kurz: Altbacken an jeder Ecke. Das ist die überflüssigste Sprache
übehaupt, vermutlich habe ich deshalb noch nie was davon gehört.
Da ist ja Rust 10x interessanter.
MaWin schrieb:> Es ist die Angst abgehängt zu werden. Die Angst zum alten Eisen zu> gehören.> Diese Leute können vielleicht C und wollen sich nicht mehr> weiterbilden. Wenn jetzt aber die Welt plötzlich auf eine neue Sprache> umsteigt, dann werden sie nutzlos.
Als ein Psychologe bist du richtig schlecht ;-)
Mir geht es z.B. um Folgendes: Eine Sprache (EGAL(!) welche -
meinetwegen auch eine Neue) festlegen und diese dann nutzen und
erweitern. Und nicht jedes Jahr umsteigen!
Was soll man bei diesem Umstieg (von z.B. C# zu C++, Java, ...) lernen?
Die Programmierparadigmen sind die gleichen - da lernt man nichts Neues.
Aber man muss eine neue Library mit 1000 Klassen und 10.000 Funktionen
lernen (die wieder Strings verketten, umdrehen, zu Zahlen umwandeln,
usw.. - aber natürlich alles sicherer und "besser") WOZU DAS GANZE??? Wo
ist da der Sinn?
Wo macht man das in "real life"? Lasst man zu Japanern sagen "Eure
Sprache ist doch doof - ihr habt x tausend Symbole! Steigt mal auf
Englisch um".
Oder zu uns: der, die das - kann sich keiner merken. Wir sollten nur
"das" beibehalten (wie im Englischen) und für alle Wörter den Artikal
"das" nehmen: das Fenster, das Buch, das Tisch, das Zeitung, das Frau,
das Mann (ist jetzt ja auch richtig "modern").
Warum streiten sich die Physiker oder Mathematiker nicht ständig über
irgenwelche Abkürzungen und ändern diese nicht ständig? Weil es
Wissenschaflter sind.
Jedes Jahr eine neue Programmiersprache erfinden, die wieder alles
besser macht - das ist ABM (Arbeitsbeschaffungsmaßnahmen).
Ja, ich kenne die diese Aussage:
"Wenn ich acht Stunden Zeit hätte, um einen Baum zu fällen, würde ich
sieben Stunden dafür aufwenden, meine Axt zu schärfen." (Abraham
Lincoln)
Und das ist richtig. Aber was machen die Informatiker jetzt? Sie
schärfen eine Axt, werfen diese Weg und holen eine neue raus. Das ist
absurd.
Es gibt ja imperative, funktionale, OOP, logische, ...., Programmierung.
Alle diese Programmierparadigmen wurden vor 50-60 Jahren erfunden. Warum
können wir also nicht eine Programmiersprache (oder zwei, drei) wählen
(wie es alle anderen Wissenschaftler tun) und damit arbeiten? Es gibt da
nichts Neues. Lambdas sind vielleicht in C++ neue, aber als Idee seit
1930 bekannt!
can't see sharp schrieb:> Als ein> Es gibt ja imperative, funktionale, OOP, logische, ...., Programmierung.> Alle diese Programmierparadigmen wurden vor 50-60 Jahren erfunden. Warum> können wir also nicht eine Programmiersprache (oder zwei, drei) wählen> (wie es alle anderen Wissenschaftler tun) und damit arbeiten? Es gibt da> nichts Neues. Lambdas sind vielleicht in C++ neue, aber als Idee seit> 1930 bekannt!
Dem hat doch noch nie jemand wiedersprochen, du bist nicht der einzige
der schon mit vielen System gearbeitet hat und sich bewusst ist das es
nur bekanntes in schöneren Gewändern ist, aber ist das nicht genau
Evolution, in kleinen Schritte zur Perfektion?
Bei dir klingt das aber irgendwie so als wäre der Sprung von Assembler
auf C der letzte wirklich notwendige gewesen, als wäre alles perfekt und
kaum noch zu verbessern und du kannst doch nicht wirklich von der
absoluten Perfektion von C oder C++ sprechen, was müsse da früher für
Götter am Werk gewesen sein
Alleine die Menge an UBs, das Präprozessorsystem, das altbackende
Includesystem (das für gänzlich andere Systembedinungen entwickelt
wurden), Array-Ptr decay,... die Liste ist lang und primär aus
Kompatibilitätsgründen so langsam in Bearbeitung - und nicht nur weil
das nur ganz ganz kluge Köpfe sind
Und ja es sind teilweise Nuancen welche die Wertigkeit und wirkliche
Nutzbarkeit von altbekanntem möglich machen
can't see sharp schrieb:> Warum streiten sich die Physiker oder Mathematiker nicht ständig über> irgenwelche Abkürzungen und ändern diese nicht ständig? Weil es> Wissenschaflter sind.
Vielleicht weil die Zunft etwas älter ist als 1930?
can't see sharp schrieb:> Die Programmierparadigmen sind die gleichen - da lernt man nichts Neues.
Das zeigt nur, dass du dir noch nie eine innovative, ungewöhnliche
und/oder moderne Sprache ernsthaft angeschaut hast.
Schaue dir z.B. mal Rust an. Also ernsthaft mal versuchen, was damit zu
entwickeln. Nicht nur die Doku angucken und behaupten du wüsstest schon
wie das alles ginge.
can't see sharp schrieb:> Lambdas sind vielleicht in C++ neue, aber als Idee seit 1930 bekannt!
Und warum hat es dann fast 80 jahre gedauert bis sich diese sich aus dem
universitären Schleier in echten Mainstream Sprachen etablieren konnten,
obwohl trivial in der Umsetzung, weil sehr viele den generischen
Charakter davon nicht verstanden oder einfach die Notwendigkeit nicht
gesehen haben
Funktionale Programmierung ist auch uralt aber erst die etwas lockerere
Integration , ohne den Paradigmen (Pure) zu strikt zu folgen, hat
gezeigt das damit gute und sinnvolle Reduktion von Codemenge(aka Fehler)
möglich ist, C hat diese Entwicklung bisher völlig ignoriert
cppbert3 schrieb:> Und warum hat es dann fast 80 jahre gedauert
Tja, das frage ich mich auch.
Wo ist Lisp jetzt? Die zweitälteste Programmiersprache der Welt? Warum
hat man nicht einfach diese Programmiersprache genommen? Warum ist sie
jetzt quasi tot?
Aus Wikipedia: "Lisp was originally created as a practical mathematical
notation for computer programs, influenced by (though not originally
derived from [6]) the notation of Alonzo Church's lambda calculus.... "
Hier! Das ist doch die einheitliche Sprache für Informatik! Das, was
alle Wissenschaftler haben - die Mathematiker, Physiker, Chemiker.
Eine Notation, die schon in den Schriften von Turing und Church (in
einer ähnlicher Form) auftaucht.
Warum wird C benutzt und nicht z.B. Haskell? Haskell ist doch so toll?
Kann man das irgenwie rational erklären?
Hier ist eine mögliche Erklärung:
https://www.youtube.com/watch?v=iSmkqocn0oQ
Direkt vom Haskell-Creator ;-) (Zitat "Haskell is useless")
Darum muss man eine Sprache (auch eine Programmiersprache) festlegen.
Ja, a la Nordkorea ;-)
can't see sharp schrieb:> Darum muss man eine Sprache (auch eine Programmiersprache) festlegen.> Ja, a la Nordkorea ;-)
Die Deutsche - auf dem Schulhof.
Und XYZ in Programmierabteilungen ;-)
can't see sharp schrieb:> Warum wird C benutzt und nicht z.B. Haskell? Haskell ist doch so toll?> Kann man das irgenwie rational erklären?
Weil wir klare Bezüge gerne Funktional ausdrücken wie z.b. in der
Mathematik, aber Abläufe von uns Menschen eher gerne imperativ
formuliert und programmiert werden, ist das so neu? Die Versuche sind
eben gescheitert, thats it
Keine Ahnung warum du so gehaltslos argumentierst
cppbert3 schrieb:> du bist nicht der einzige> der schon mit vielen System gearbeitet hat
hab' ich nicht.
Darum wundert mich dass Leute, die genau diese Erfahrung haben, so
einfach alles wegwerfen und immer wieder neu anfangen.
Das ist für mich schon Masochismus.
can't see sharp schrieb:> Darum wundert mich dass Leute, die genau diese Erfahrung haben, so> einfach alles wegwerfen und immer wieder neu anfangen.
Das tut niemand, außer in deiner Fantasie.
can't see sharp schrieb:> cppbert3 schrieb:> du bist nicht der einzige> der schon mit vielen System gearbeitet hat>> hab' ich nicht.> Darum wundert mich dass Leute, die genau diese Erfahrung haben, so> einfach alles wegwerfen und immer wieder neu anfangen.>> Das ist für mich schon Masochismus.
Wiso involvierst du dich in die Diskussion wenn du die Grundlagen von
Forschung und den langen Weg von der Theorie zur Anwendbarkeit und dann
das jahrzehntelange Feintuning nicht verstehst?
Du siehst das Ergebnis von tausend Jahren Trial & Error und denkst das
man diesen Prozess so einfach auf wenige Jahrzehnten eindampfen kann und
dann praktisch fertig ist?
MaWin schrieb:> Das tut niemand, außer in deiner Fantasie.
Alter Schwede.
Microsoft bietet zu allen Sachen eine eigene Alternative. Z.B zu Java -
C#.
Sogar eine eigen Rust-Version wollen sie jetzt entwickeln (habe ich
irgendwo gelesen).
Die Sache ist also viel schlimmer.
Es werden nicht nur "neue" Programmiersprachen erfunden (mit Ideen, die
seit x Jahrzehnten bekannt sind und schon längst umgesetzt wurden - in
anderen (alten) Programmiersprachen), nein, es werden Kopien von
irgendwelchen Sprachen erstellt um die Programmierer an das eigene
Betriebssystem, IDE-System, .... zu binden.
Man hat dann x verschiedene Programmiersprachen, die alle ähnlich
funktionieren, aber zueinander nicht kompatibel sind. Und das macht man
absichtilich! Wozu das Ganze???
can't see sharp schrieb:> Microsoft bietet
Ja und?
Wer migriert nun seine riesigen C-Projekte nach C#? Kaum jemand tut das.
Es werden nur neue Projekte in neuen Sprachen gestartet.
Ich sehe echt dein Problem nicht.
can't see sharp schrieb:> Es werden nicht nur "neue" Programmiersprachen erfunden (mit Ideen, die> seit x Jahrzehnten bekannt sind und schon längst umgesetzt wurden
Du kannst das noch 1000 mal behaupten. Damit wird es nicht wahrer.
Schaue dir Rust an!
MaWin schrieb:> Ich sehe echt dein Problem nicht.
weil ich es nicht habe.
Der Turmbau zu Babel ist das Problem.
Es können nicht jedes Jahr ein dutzend neue Programmiersprachen gefeiert
werden.
MaWin schrieb:> Du kannst das noch 1000 mal behaupten. Damit wird es nicht wahrer.> Schaue dir Rust an!
Ok, "alle" Programmierer nehmen jetzt Rust und nutzen diese
Programmiersprache für die nächsten 30 Jahre, einverstanden?
Also ich hätte nichts dagegen. Wir können C in die Mülltonne werfen. Und
C++ gleich mit.
Aber wir werden dann eine Programmiersprache wählen und diese nutzen.
Ja?
Oder werden wir in drei Jahren wieder umsteigen müssen? Auf Zig(tausend
neue Sprachen, die noch besser sind)? ;-)
can't see sharp schrieb:> MaWin schrieb:> Du kannst das noch 1000 mal behaupten. Damit wird es nicht wahrer.> Schaue dir Rust an!>> Ok, "alle" Programmierer nehmen jetzt Rust und nutzen diese> Programmiersprache für die nächsten 30 Jahre, einverstanden?>> Also ich hätte nichts dagegen. Wir können C in die Mülltonne werfen. Und> C++ gleich mit.> Aber wir werden dann eine Programmiersprache wählen und diese nutzen.> Ja?>> Oder werden wir in drei Jahren wieder umsteigen müssen? Auf Zig(tausend> neue Sprachen, die noch besser sind)? ;-)
Von was redest du eigentlich? Das es jedes Jahr zig neue Sprachen gibt
ist schon ewig so, kann es sein das durch die neue mediale Präsenz
(heise schreibt jetzt auch darüber) dir das neu vorkommt? :)
can't see sharp schrieb:> weil ich es nicht habe.
Dafür, dass du kein Problem hast, wetterst du hier aber ganz ordentlich
gegen alles.
> Der Turmbau zu Babel ist das Problem.
Also doch ein Problem?
> Es können nicht jedes Jahr ein dutzend neue Programmiersprachen gefeiert> werden.
Warum nicht?
can't see sharp schrieb:> Ok, "alle" Programmierer nehmen jetzt Rust und nutzen diese> Programmiersprache für die nächsten 30 Jahre, einverstanden?
Nein, warum?
> Also ich hätte nichts dagegen. Wir können C in die Mülltonne werfen. Und> C++ gleich mit.
Ok.
> Aber wir werden dann eine Programmiersprache wählen und diese nutzen.> Ja?
Warum muss ich mich mit dir abstimmen, wenn ich eine Sprache wähle?
> Oder werden wir in drei Jahren wieder umsteigen müssen? Auf Zig(tausend> neue Sprachen, die noch besser sind)? ;-)
Niemand muss jetzt oder in drei Jahren umsteigen.
MaWin schrieb:> Warum muss ich mich mit dir abstimmen, wenn ich eine Sprache wähle?
musst du nicht.
Informatik ist halt keine Wissenschaft. Darum hat sie auch keine
einheitliche Sprache (wie z.B. die Mathematik).
Das ist ehe sowas wie Genderwissenschaft. Nur erfindet man hier jedes
Jahr ein dutzend neue Programmiersprachen.
Guten Rutsch!
cat't see sharp schrieb:>> Warum muss ich mich mit dir abstimmen, wenn ich eine Sprache wähle?> musst du nicht.
Da bin ich ja beruhigt.
> Informatik ist halt keine Wissenschaft. Darum hat sie auch keine> einheitliche Sprache (wie z.B. die Mathematik).
Informatik hat kaum etwas mit Programmieren zu tun und nur wenig mit
Programmiersprachen. Informatik nutzt unter anderem natürlich auch die
Sprache der Mathematik.
> Das ist ehe sowas wie Genderwissenschaft.
Ah ja.
Könntest du das auch begründen?
> Nur erfindet man hier jedes Jahr ein dutzend neue Programmiersprachen.
Ich sehe das Problem immer noch nicht.
Warum wird es schlechter, wenn man mehr Auswahl hat?
cat't see sharp schrieb:> Informatik ist halt keine Wissenschaft. Darum hat sie auch keine> einheitliche Sprache (wie z.B. die Mathematik).
Wann hast Du denn das letzte Mal eine mathematische Formulierung
gelesen, die 2000 Token oder 2 Milionen enthielt? Und das ohne
Entwicklung, also in der Endgleichung?
Mir ist auch nicht klar, wo Du genau die analogien ziehen willst. Eine
Programmiersprache ist natürlich nicht die Notation der Informatik.
Sowenig wie es für Mathematik die Notation von Matlab, Excel, R oder
Oktav ist.