Welche Programmiersprachen haben noch eine große Zukunft vor sich, welche gelten als veraltet?
-
Basic im Bios.
-
redrew99 schrieb:
]
Der Großteil der Programmiersprachen wird wohl in der heutigen Form bestehen bleiben. Viele davon werden wie heute auch wohl nur in Nischen eingesetzt.Sehe ich auch so.
Was die Hauptprogrammiersprachen(C++,Java,C,"XYZ") anbetrifft, scheint es aktuell wohl so zu sein, daß es nichts gibt, was man damit nicht programmieren kann.
Erst wenn sich das ändert, wird es wohl neue Programmiersprachen geben.
Die Änderungen werden sich durch die Leistungsanforderung zukünftiger Software, die z.B. auf viele MultiCore CPUs angewiesen sind oder so teuer sind, daß man Entwicklungskosten sparen will, ergeben.
Und da steht C++ leider nicht gut da.
Man kann zwar MultiCores damit programmieren, aber C++ ist dabei keine große unterstützende Hilfe und beim Sparen von Entwicklungskosten ist C++ auch nicht viel besser.Die zukünftige Programmiersprache der Wahl wird also so eine sein, die Multicores gut erschließen kann und von den Softwaretechnikentwicklungskosten für eine günstige Entwicklung durch wenig Aufwand sorgt.
Die Programmiersprache D wäre hier ein guter Kandidat, denn durch die Unterstützung der funktionalen Programmierung, Bindung der unmutablebarkeit von Datentypen und Objekten an den Typ und viele weitere Sprachfeatures ist sie dazu prädestiniert und aufgrund ihrer guten sauberen Strukturiertheit und umfangreichen API kommt man mit ihr auch sehr schnell ans Ziel, was wiederum Entwicklungskosten spart.
So muß man sich bei D z.B. nicht noch extra um Headerfiles kümmern, denn diese Unterstützung für den Compiler und Linker wird direkt aus dem D Quellcode erzeugt, weshalb sich der Entwickler darum keine Gedanken machen muß.
Der Garbage Collector und die Möglichkeit der Nicht Nutzung des GC helfen ebenfalls beim Entwicklungaufwand, dazu kommen noch Module und die Unterscheidung zwischen Kommentaren und Kommentaren zur Codedokumentation.
Das sind alles so Dinge, bei der C++ krankt oder nur durch Zusatzsoftware hinkriegt.Natürlich ist damit nicht gesagt, ob es D schafft an Verbreitung zuzunehmen, so daß bessere Compiler entstehen und eine besserer Unterstützung von der Community dieser Sprache erfolgt, aber die Grundvorrausssetzungen hat D schon einmal dazu, noch groß rauszukommen. Python hat dazu auch 15 Jahre gebraucht. Ob es klappt, das steht in den Sternen.
Wenn Oracle jedenfalls weiterhin die Java Entwickler vergrault und Microsoft wegen .Net mit Klagen droht und auf Windows beschränkt bleibt, dann sehe ich jedenfalls für D gute Chancen.
Ein anderer Grund für die Verbreitung einer neuen Programmiersprache könnte darin bestehen, daß sie wesentlich einfacher ist als die aktuellen.
Sie muß nicht unbedingt einfacher sein, sondern Aufwandersparender.
Programmierer haben nicht unbedingt ein Problem mit der Komplexität von Programmiersprachen, bei denen gute Sprachen eine gewisse Grundkomplexität mit sich bringen, sondern mit dem Aufwand in einer entsprechenden Zeit schnell die Software zu entwickeln.
Hier, beim Entwicklungsaufwand sind Einsparungen gewünscht.Bei D muß ich z.B. schonmal keine Headerfiles mehr pflegen, das ist also ein deutlich geringerer Aufwand als man ihn in C++ hat.
-
Zeus schrieb:
Basic im Bios.
Sagen wir mal im ROM bzw. BIOS ROM Baustein des IBM PCs.
-
ipsec schrieb:
Die FH hat also durchaus ihre Existenzberechtigung, Forschung und Weiterentwicklung in der Informatik findet aber bei den Universitätlern statt.
Blödsinn. Nimm eine x-beliebige FH, suche dir dort eine Fakultät aus und dann gucke mal unter dem Punkt "Forschung".
Zugegeben: Eine Uni wird wohl mehr Geld und Personal in Forschung reinstecken als eine FH, aber dein Satz liest sich so, als ob eine FH gar nicht forscht, was - wie gesagt - Blödsinn ist.
-
muemmel schrieb:
Hi,
es gibt einen ganz einfachen Grund, warum immer noch Firmen mit Basic arbeiten: Basic-Programmierer sind billig und schnell auszubilden.Jetzt fällt mir erst wieder ein das in meiner Firma unter anderem AutoIt Skripte geschrieben werden ( hat ja eine BASIC-like Syntax ). Meistens auch aus dem Grund weil man damit schnell und einfach eine Anwendung zusammenschreiben kann ( als Beispiel - Parser für Messwerte ) und weil man dafür nicht zwingend einen Informatiker braucht ( der Großteil der AutoIt-Coder hier sind keine Informatiker bzw. sind nicht aus der IT-Abteilung )
War vor kurzem selber davon überrascht was man damit erreichen kann
-
phcn.fraggle schrieb:
War vor kurzem selber davon überrascht was man damit erreichen kann
Wo früher zur Messwerterfassung und verarbeitung ein C64 ausreichte, braucht man heute einen Intel QuadCore für die gleiche Aufgabe.
Basic und Quereinsteigern sei Dank!
-
Steffo schrieb:
Zugegeben: Eine Uni wird wohl mehr Geld und Personal in Forschung reinstecken als eine FH, aber dein Satz liest sich so, als ob eine FH gar nicht forscht, was - wie gesagt - Blödsinn ist.
In meinem Bereich macht es nicht den Eindruck, als wären besonders viele Publikationen in renommierten Journalen an FHs entstanden, und auch auf Konferenzen sieht man eher keine Leute von der FH rumlaufen. Ein befreundeter FH-Professor sagte mir mal, dass er in erster Linie für die Lehre zuständig ist und nebenbei noch forschen kann, wenn er Zeit und Lust hat. Auch wenn die FHs auf dem Papier keine reinen Lehreinrichtungen mehr sind, ist die Forschung in der Realität - meines Wissens nach - quasi eher ein Hobby.
D kann gute Zukunft sein schrieb:
Die Änderungen werden sich durch die Leistungsanforderung zukünftiger Software, die z.B. auf viele MultiCore CPUs angewiesen sind oder so teuer sind, daß man Entwicklungskosten sparen will, ergeben.
Und da steht C++ leider nicht gut da.
Man kann zwar MultiCores damit programmieren, aber C++ ist dabei keine große unterstützende Hilfe und beim Sparen von Entwicklungskosten ist C++ auch nicht viel besser.Wenn sich mal umschaut, dann sind Fortran, C und C++ die einzigen Sprachen, in denen paralleles Rechnen ernsthaft betrieben wird. Die Entwicklung ist zwar nicht unbedingt immer eine Freude, aber es setzt sich nur durch, was auch benutzt wird.
-
Ein anderer Grund für die Verbreitung einer neuen Programmiersprache könnte darin bestehen, daß sie wesentlich einfacher ist als die aktuellen.
das gibt es mit lisp und smalltalk schon seit über 50 bzw 35 Jahren, teils verbunden mit erheblichen Ersparnissen an Entwicklungszeit. Scheint aber nicht entscheidend zu sein. Sonst würden ja mehr in lisp oder smalltalk programmieren.
Stichwort dsl (domain specific languages) - wenn das eines Tages wichtig wird, könnten sich solche "minimal syntax" Sprachen durchsetzen.
-
ipsec schrieb:
1. google „fh informatik“, erster brauchbarer Link führt zur FH Köln. Deren Modulbeschreibung für Bachelor Informatik findet sich hier.
Wie man sieht, kommen im Grundstudium 3 theoretische Vorlesungen (Mathe 1 und 2 sowie Theoretische Informatik) und 4 praktische. In den Beschreibungen für Mathe liest man dabei
Die Studierenden sollen
• die Fähigkeiten zur Analyse realer oder geplanter
Systeme entwickeln, indem sie praktische
Aufgabenstellungen aus dem Informatik-Umfeld in
mathematische Strukturen abstrahieren und lernen,
selbstständig die Modellfindung und die
Ergebnisbeurteilung vorzunehmen.
• Dabei sollen die Anwendungsbezüge der Mathematik
deutlich werden, z.B. die Bedeutung funktionaler
Beziehungen für kontinuierliche Zusammenhänge, die
lineare Algebra z.B als Grundlage der grafischen
Datenverarbeitung und die Analysis zur Verarbeitung
von Signalen und zur Lösung von mathematischen
Modellen..(Hervorhebung durch mich). Auch Mathematik ist hier also praxisorientiert.
Schaut ja schon sehr schlimm praxisorientiert aus.
Auch das Skript.
http://www.gm.fh-koeln.de/~konen/Mathe1-WS/inhalt-mathe1.PDF...
Wozu InformatikerInnen Folgen brauchen
...
Warum Informatiker Funktionen brauchen
...
Wozu Informatikerinnen Differentialrechnung brauchenGut, dass ich noch studiert habe, als es noch keinen Bachelor gab. Damals gabs bei uns noch keine "Warum Informatiker * brauchen" Kapitel, sondern war noch viel theoretischer.
-
Das Niveau hier ist unter aller Sau!!
Chuck Norris hat an einer Uni studiert und Punkt.
-
Chucky die Mörderpuppe schrieb:
Chuck Norris hat an einer Uni studiert und Punkt.
http://upload.wikimedia.org/wikipedia/commons/e/e3/Studenten_Protest_in_Bamberg-2009.jpg
-
Nachrichtentext schrieb:
Chucky die Mörderpuppe schrieb:
Chuck Norris hat an einer Uni studiert und Punkt.
http://upload.wikimedia.org/wikipedia/commons/e/e3/Studenten_Protest_in_Bamberg-2009.jpg
Faule Säcke.
-
Chucky die Mörderpuppe schrieb:
Das Niveau hier ist unter aller Sau!!
Chuck Norris hat an einer Uni studiert und Punkt.
Chucky gehört vor die Säue geworfen.
Dafür!
-
Noobs.
-
So muß man sich bei D z.B. nicht noch extra um Headerfiles kümmern
Ja, das Totschlagargument. Ich finde Headerfiles eher hilfreich als hinderlich.
Unterscheidung zwischen Kommentaren und Kommentaren zur Codedokumentation
Wahnsinns Fortschritt. Das Killerfeature schlechthin.
Python hat dazu auch 15 Jahre gebraucht
Und wenn man sich Python genauer anschaut, dann erkennt man einen verkappten Scheme-Dialekt. Wahrscheinlich programmieren wir in 10 Jahren in Lisp, nur heisst es dann Ruby oder eben anders.
Wenn ..., dann sehe ich jedenfalls für D gute Chancen.
Neben den anderen gehypten Sprachen. Da hat googles Go wesentlich groessere Chancen.
Fortran, C und C++ die einzigen Sprachen, in denen paralleles Rechnen ernsthaft betrieben wird
Supercomputing ist nicht das gleiche wie paralleles Rechnen. Manchmal sind 16 bzw. 48 Kerne herausfordernd. Simon Peyton Jones hat in einigen Vortraegen relevante Beispiele fuer Haskell aus der Praxis, auch haben sie STM (andere wie Clojure auch, aber anders).
Scheint aber nicht entscheidend zu sein. Sonst würden ja mehr in lisp oder smalltalk programmieren.
Weil Lisp nicht fuer den Durchschnitt verstaendlich ist.
-
knivil schrieb:
Supercomputing ist nicht das gleiche wie paralleles Rechnen. Manchmal sind 16 bzw. 48 Kerne herausfordernd. Simon Peyton Jones hat in einigen Vortraegen relevante Beispiele fuer Haskell aus der Praxis, auch haben sie STM (andere wie Clojure auch, aber anders).
Haskell und Praxis sagt doch eigentlich schon alles. In den Größenordnungen, die Du so nennst, ist GPU-Computing momentan angesagter, und da bin ich mir nicht sicher, ob die Unterstützung in diesen ewigen Modesprachen überhaupt in dem Maße gegeben ist. Für shared-memory Systeme mit wenigen Prozessoren funktioniert außerdem OpenMP super. Ich sehe im Moment nicht den großen Vorteil anderer Sprachen, die es rechtfertigen würden rüber zu wechseln.
-
knivil schrieb:
wenn man sich Python genauer anschaut, dann erkennt man einen verkappten Scheme-Dialekt.
das lese ich zum x-ten Mal. Wie kommst du darauf ?
knivil schrieb:
Wahrscheinlich programmieren wir in 10 Jahren in Lisp, nur heisst es dann Ruby oder eben anders.
ruby ähnelt entfernt aber eher smalltalk als lisp.
Weil Lisp nicht fuer den Durchschnitt verstaendlich ist.
das könnte man ja leicht ändern, indem man den Code durch Einrücktiefe statt durch runde Klammern strukturiert. Python macht es ja vor.
-
!rr!rr_. schrieb:
das lese ich zum x-ten Mal. Wie kommst du darauf ?
Zeig mir, was Python grundsaetzlich anders macht als Scheme. Nein ich meine nicht die verfuegbaren Bibliotheken. Nein, ich meine nicht die Einrueckungen.
ruby ähnelt entfernt aber eher smalltalk als lisp
Whatever. Fuer Lisp bedeuten diese Sprachen mit ihren Ansaetzen und Features eigentlich nur: Kenn ich schon, hab ich schon, war ich schon. Also ein alter Hut.
das könnte man ja leicht ändern, indem man den Code durch Einrücktiefe statt durch runde Klammern strukturiert. Python macht es ja vor.
Jeha, DAS KILLERFEATURE. Plonk, wie konnte ich das uebersehen. Nein, mit verstaendlich meine ich nicht Syntax oder Klammern, sondern eher die Werkzeuge, Mittel und Abstraktionsmoeglichkeiten der Sprache.
Haskell und Praxis sagt doch eigentlich schon alles.
Ich kann dir mindestens 2 Firmen nennen, die Haskell ueberwiegend einsetzen und gerade deshalb sehr erfolgreich sind. Leider kann der Entwickler nur selten seine Werkzeuge waehlen und Manager eigentlich Angsthasen sind.
In den Größenordnungen, die Du so nennst, ist GPU-Computing momentan angesagter
Nein, ich rede nicht von GPU-Computing. Ich rede beispielsweise von einem Game-Loop: Wie kann eingabe Ausgabe, Sound, KI, ... sinnvoll parallelisiert werden. Da hilft mir ein Shader recht wenig. Ich rede von Prozessoren mit 16 oder mehr Kernen oder die Inkarnationen von Larrabee (ist keine GPU mehr) etc. Ich habe OpenMP benutzt und es fuer nicht gut empfunden. Warum: Das bischen Wrapper-Code um pthreads kann ich auch noch selbst schreiben.
-
Ach, das mit der gezwungenen Einrückung in Python ist gewollt? Ich dachte immer das wäre ein Bug..
-
Python wins.
The rest can suck it.
