Programmiersprachen der Zukunft
-
@Bushmaster sagte in Programmiersprachen der Zukunft:
ein bekannter von mir hat letztens von einer neuen, visuellen programmiersprache geschwärmt, wo man funktionsblöcke zusammenstöpselt. er fand das total zukunftsweisend. als ich ihm sagte dass man schon im letzten jahrtausend so sps-steuerungen programmiert hat - https://de.wikipedia.org/wiki/Funktionsbausteinsprache - war er ganz verwundert
Mal ganz davon abgesehen dass es keinen Spass macht mit so Klickibunti Umgebungen grössere Programme zu schreiben. Zum Shader im 3D-Programm Zusammenstoppeln oder DSP Audio-Filter Basteln ist das toll. Aber komplexe Anwendung
kann manmag ich damit nicht schreiben. Ganz abgesehen davon dass es viele Probleme mit Tooling macht (Source-Control/Diffing, Suchbarkeit etc.).
-
also ich mag die auch nicht und allgemein unterstützen sps nicht ohne grund C oder wenigstens strukturierten text (ST).
-
@Wade1234
dieses 'st' sieht ein bisschen wie pascal und fortran aus. die sps-leute die ich kenne mögen das aber nicht so gern. eher nehmen sie die sps-assemblersprache 'awl' oder diese kontakt-darstellung, die schaltplänen ähnelt. zwischen it-leuten und elektrotechnikern klafft offenbar ein großer spalt.andererseits sind strukturierte sprachen wie vhdl beim chipdesign sehr angesagt, obwohl man dort im prinzip auch bloß logikblöcke zusammenstöpselt. aber da wird imho sehr wenig auf grafischer basis programmiert.
-
Die Programmiersprache der Zukunft wird für die Programmierung von Quantencomputern entwickelt werden. Da das noch komplett neu ist und erst noch entwickelt wird, ist hier das Feld noch komplett unbestellt.
Was die klassischen von Neumann Architekturen betrifft, da wird es immer wieder Variationen des bereits bekannten geben, und Unterstützung von Konzepten direkt durch die Sprache, die ggf. noch entwickelt werden, siehe Rust siehe Ada und das wird auch in andere Sprachen einfließen.
-
Dieser Beitrag wurde gelöscht!
-
@KahnSoft was ist denn deine Alternative zu der Verwendung diverser externer Libraries/Frameworks?
-
Dieser Beitrag wurde gelöscht!
-
@KahnSoft sagte in Programmiersprachen der Zukunft:
@It0101 Die einzige Möglichkeit ist es in den 80ziger Jahren mit der Entwicklung zu beginnen.
Du hast recht, für alle späteren die innerhalb von 3-5 Jahren Ergebnisse brauchen ist es nicht möglich auf die händische Kunst zuzugreifen. Umso erschreckender das gerade jene die alten Fähigkeiten weder Akzeptieren noch verstehen, schlimmer noch -es wird als Unfähigkeit betrachtet. Leider Gottes sind nur wenige Informatiker aus dieser Zeit übrig. Und die die noch da sind werden verachtet führ Ihre WeisenMeiner Erfahrung nach haben sich von den "alteingesessenen" kaum welche weiterentwickelt. Die Softwareentwicklung verändert sich stetig weiter und man muss immer hinterkommen.
Heutzutage ist man gezwungen externe Libs zu nutzen. Anders kann man große Projekte doch gar nicht bewältigen. Ich setze mich jedenfalls nicht hin und schreibe mir ne SSL-Bibliothek...
-
Dieser Beitrag wurde gelöscht!
-
@KahnSoft Weil man nirgends das Rad neu erfindet. Du hast oben was zu Speichermanagemant geschrieben, was mich schaudern lässt. Eine gut getestete Bibliothek verwenden ist in den meisten Fällen besser. Siehe das Beispiel von @It0101 bezüglich SSL, auch wenn man das theoretisch selber machen kann, wird es doch garantiert nicht besser, als das was es schon gibt.
-
Weiterentwicklung bedeutet, dass man LIBS rauswirft? Und dann setzt du dich ne Woche hin und schreibst einen XML-Parser. Noch ein halbes Jahr für SSL und dann vielleicht noch ein HTML-Protokoll....
Vielleicht noch ne Grafik-Engine im Fall von Visualisierung.Weiterentwicklung bedeutet für mich, dass man lernt, seine Skills und seine kostbare und teure Entwicklerzeit dort einzusetzen, wo man etwas bewegen kann und an anderen Stellen eben externe Libs ( oder Module von Kollegen ) verwendet. Man muss nicht alles selber programmieren, denn im Allgemeinen wird die Softwarequalität dadurch nicht steigen.
Wir haben uns z.b. ein Framework für unsere Server selber gebaut, basierend auf STL-Threads, aber auch dort verwenden wir Module aus anderen externen Frameworks.
Einfach weil wir nicht jedesmal von vorne anfangen wollen.
-
@KahnSoft: Bist du wirklich so naiv oder hast du die letzten 20 Jahre im stillen Kämmerlein verbracht?
Sollen andere Produkte, wie Autos, Maschinen etc., auch noch wie vor zig Jahrzehnten produziert werden?Und wo ist für dich der Unterschied zwischen System-APIs und externen Frameworks? Also z.B. viele Boost-Libs sind im Laufe der letzten Jahre in die C++ Standard Library übernommen worden: dies bedeutet Weiterentwicklung!
@It0101 sagte in Programmiersprachen der Zukunft:
Meiner Erfahrung nach haben sich von den "alteingesessenen" kaum welche weiterentwickelt. Die Softwareentwicklung verändert sich stetig weiter und man muss immer hinterkommen.
@It0101: Also auch ich könnte mich als "alteingesessen" bezeichnen, da ich seit Ende der 80iger Jahre (professionell) Software entwickle, aber ich entwickle mich täglich weiter (auch durch dieses Forum hier). Aber vllt. bin ich auch schon (lange) auf dem Abstellgleis, weil ich mich nicht mit KI, ML (Deep Learning, ...), Big Data, ... befasse?
-
Dieser Beitrag wurde gelöscht!
-
Dieser Beitrag wurde gelöscht!
-
@Th69 sagte in Programmiersprachen der Zukunft:
@It0101: Also auch ich könnte mich als "alteingesessen" bezeichnen, da ich seit Ende der 80iger Jahre (professionell) Software entwickle, aber ich entwickle mich täglich weiter (auch durch dieses Forum hier). Aber vllt. bin ich auch schon (lange) auf dem Abstellgleis, weil ich mich nicht mit KI, ML (Deep Learning, ...), Big Data, ... befasse?
Es gibt immer Ausnahmen. Wir haben hier auch eine davon. Er liest sich auch in agile Entwicklung ein, unittests, moderne C++ Standards, usw.
Aber es gibt auch einige, denen ich den Übergang vom CVS ( älter als die Welt ) auf GIT ( state-of-the-art ) regelrecht mit der Peitsche einbläuen musste.
-
Dieser Beitrag wurde gelöscht!
-
@It0101 sagte in Programmiersprachen der Zukunft:
Aber es gibt auch einige, denen ich den Übergang vom CVS ( älter als die Welt ) auf GIT ( state-of-the-art ) regelrecht mit der Peitsche einbläuen musste.
GIT = Git Ist Toll
Vor allen Dingen gehen Dinge damit wesentlich einfacher. Ein Vergleich von Datei XYZ Version ABC zu dem aktuellen Working Tree ist mit TortoiseGit nur ein paar Mausclicks entfernt.
Wenn ich da an CVS denke, so endete das meistens in einer etwas längeren Recherche in der Doku.
Aber ich kenne viele Leute welche GIT bis heute nicht verstanden haben und auch nicht verstehen wollen sondern eher bei CVS bleiben wollen. Wie sagt man so schön: "Was der Bauer nicht kennt, frisst er nicht."
-
@It0101
Ich erlebe es eigentlich häufiger genau anders herum, dass nämlich irgendwelche jungen, neuen Leute nach dem zweiten Arbeitstag wissen, dass man doch viel besser das Buzz-Word-Tool xy nehmen muss.
-
@It0101 Dann sei froh. Ich musste schon Leuten erklären wozu sie überhaupt Versionskontrolle brauchen. Für die reichte ein Verzeicnisbaum voller zip files.
-
@Tyrdal Das hat nach meiner Erfahrung mit dem Alter nixe zu tun.
@Quiche-Lorraine Zum Thema Git ist toll: nein, Git ist nicht toll. Es ist alles in allem ein akzeptables Tool. Wobei dummerweise übersehen wird dass Git bestimmte Dinge nicht kann und für wieder andere einfach nicht sehr gut ist.
Nebenbei auch witzig dass viele von den Jungen nichtmal wissen was Git nicht kann, weil sie nie mit 'was anderem gearbeitet haben und nichtmal auf die Idee kommen dass ein Versionskontrollsystem das können könnte."Git ist toll" ist Gehirnwäschepropaganda. Genau so wie die Glorifizierung des veralteten durchwachsenen Haufens schlecht entworfener APIs der sich da POSIX schimpft.