Welcher Sprache gehört die Zukunft?
-
Der Durchschnitt schrieb:
Ich möchte hier allerdings auch nicht Lisp schlechtreden, auch wenn das bisher den Anschein hat, sondern nur klarstellen, dass Programmierer nicht zwangsweise "dumm" sind, wenn sie sich auf Mainstream-Sprachen konzentrieren.
Ich möchte hier allerdings nur klarstellen, dass das auch niemand behauptet hat. Wenn du meinst ich hätte so etwas gesagt, dann hast du meinen Beitrag falsch gelesen.
-
viele sprachen haben ihre daseinsberechtigung, weil sie für bestimmte aufgabengebiete geschaffen wurden. trotzdem denke ich, dass den mehr oder minder "plattformunabhängigen" sprachen die zukunft gehören wird. denn die systemvielfalt ist momentan recht hoch. meist liegt zwar mittlerweile die x86 architektur zugrunde (wenn man server systeme mal aussen vor lässt und sich auf anwender seite beschränkt), aber die betriebssysteme unterscheiden sich in zig windows varianten, mac systeme und diverse *nix dialekte.
zumindest in meiner firma wurden deshalb unlängst viele systeme von c++ auf java umgestellt, um mit minimalen* anpassungen auf all diesen zielplattformen lauffähig zu sein.
* die sind in der realität dann doch manchmal nicht so minimal, wie man gerne hätte. aber bei weitem sparsamer, als die c++ legacy ungetüme damals.
-
Erhard Henkes schrieb:
Es ist sogar zumeist so, dass der Mainstream und das Beste nicht identisch sind. Beispielsweise war MS Winword zu Anfang der Neunziger nicht das beste Textverarbeitungsprogramm, aber es war von Microsoft. Wer sich damals z.B. für WordPerfect, Text5 (IBM) oder AmiPro entschied, hatte verloren, nämlich gegen Microsoft, den Riesen aus Seattle.
Naja, MS Word hatte einen ziemlichen Vorteil gegenüber den anderen Produkten: es war deutlich preiswerter (und Textverarbeitung haben die meisten Leute ein paar Monate vorher noch mit der Schreibmaschine gemacht). Es löst also ein Problem mit ziemlich geringem Aufwand. Ob das nun das Beste oder Murks ist, ist doch überhaupt nicht weiter relevant.
-
thordk schrieb:
zumindest in meiner firma wurden deshalb unlängst viele systeme von c++ auf java umgestellt, um mit minimalen* anpassungen auf all diesen zielplattformen lauffähig zu sein.
* die sind in der realität dann doch manchmal nicht so minimal, wie man gerne hätte. aber bei weitem sparsamer, als die c++ legacy ungetüme damals.
Man kann auch mit C++ plattformneutral programmieren. Wobei es wohl pragmatischer ist, Plattformabhängigkeiten nur zu minimieren.
Java funktioniert auf wesentlich weniger Plattformen als C++. :p
Naja, ich hab allerdings aus anderen technischen Gründen (und weils interessanter ist als immer nur C++ vs Java) für Erlang gestimmt. (So wie CengizS, Betreiber von JavaCore. :D)
-
Mr. N schrieb:
Java funktioniert auf wesentlich weniger Plattformen als C++.
wie kommst du auf das schmale brett?
-
pale dog schrieb:
Mr. N schrieb:
Java funktioniert auf wesentlich weniger Plattformen als C++.
wie kommst du auf das schmale brett?
Ich habe keine Ahnung was du meinst, will es auch gar nicht wissen, meine Aussage stimmt einfach (du kannst ja gerne zählen) und fertig.
-
der riesigen masse an windows, mac und *nix systemen steht zwar ne unglaubliche vielzahl proprietärer systeme gegenüber, allerdings spielt für den großteil dieser "plattformunabhängigkeit" gar keine rolle, da programme für diese systeme exakt auf das system zugeschnitten wird.
wenns um die frage geht, welcher sprache die zukunft gehört, sollte man sich auf consumer systeme beschränken. gibt für viele derzeit bestehende lösungen gar keine veranlassung, was anderes zu nehmen (z.b. die ganzen fortran und cobol programme, die immer noch ihren dienst verrichten).
wenns um industrielösungen (maschinensteuerungen, dtp automatisierung, etc.) und consumer anwendungen (textverarbeitung und gedöns) geht, dann spielen allerdings die zuvor genannten drei betriebssystemtypen die hauptrolle. die müssen nämlich kostengünstig und in den meisten fällen portabel sein. und für diese existieren jvms.
-
pale dog schrieb:
Mr. N schrieb:
Java funktioniert auf wesentlich weniger Plattformen als C++.
wie kommst du auf das schmale brett?
Zähl doch mal die Plattformen auf, auf denen ein Java Programm laufen kann? Und dann zähl mal die auf, wo es für C++ Compiler gibt... Aha! Damit ist Mr. N einfach auf einem breiten Brett. Sowas kann ich nur machen, weil es C++ für jede erdenkliche Plattform gibt. An Java ist auf solchen Plattformen nicht mal im entferntesten zu denken.
-
Mr. N schrieb:
pale dog schrieb:
Mr. N schrieb:
Java funktioniert auf wesentlich weniger Plattformen als C++.
wie kommst du auf das schmale brett?
Ich habe keine Ahnung was du meinst, will es auch gar nicht wissen, meine Aussage stimmt einfach (du kannst ja gerne zählen) und fertig.
ich will's dir trotzdem erzählen
erinnere dich an die einschränkung, die du in deinem eingangsposting gemacht hast und dann brauche ich nintendo-ds u.ä. gar nicht mitzählen.
...und dann ist deine aussage auch einfach falsch :p
-
pale dog schrieb:
Mr. N schrieb:
pale dog schrieb:
Mr. N schrieb:
Java funktioniert auf wesentlich weniger Plattformen als C++.
wie kommst du auf das schmale brett?
Ich habe keine Ahnung was du meinst, will es auch gar nicht wissen, meine Aussage stimmt einfach (du kannst ja gerne zählen) und fertig.
ich will's dir trotzdem erzählen
erinnere dich an die einschränkung, die du in deinem eingangsposting gemacht hast und dann brauche ich nintendo-ds u.ä. gar nicht mitzählen.
...und dann ist deine aussage auch einfach falsch :pDie Aussage hat die Einschränkung ignoriert. Schließlich war die Einschränkung zur Orientierung für die Umfrage gedacht, und damit Tim mich mit C in Ruhe lässt.
-
Mr. N schrieb:
...und damit Tim mich mit C in Ruhe lässt.
C taucht überhaupt nicht in der liste auf und wieso sollte Tim dir C aufschwatzen wollen?
btw: du hattest für erlang gestimmt?
das bestätigt doch meine prognose, dass VM- und interpreter-sprachen auf systemen mit hocher rechenleistung und hoher speicherkapazität im vormarsch sind...
-
pale dog schrieb:
Mr. N schrieb:
...und damit Tim mich mit C in Ruhe lässt.
C taucht überhaupt nicht in der liste auf und wieso sollte Tim dir C aufschwatzen wollen?
Weil Tim ein C-Fan ist und ich C vergessen habe. Ich hab ihm dann ML vorgeschlagen.
pale dog schrieb:
btw: du hattest für erlang gestimmt?
Ja.
pale dog schrieb:
das bestätigt doch meine prognose, dass VM- und interpreter-sprachen auf systemen mit hocher rechenleistung und hoher speicherkapazität im vormarsch sind...
Ich habe nicht deswegen für Erlang gestimmt. Obwohl, teilweise doch, weil es so um die teuren Betriebssystem-Prozesse herumkommt.
-
Mr. N schrieb:
Weil Tim ein C-Fan ist und ich C vergessen habe. Ich hab ihm dann ML vorgeschlagen.
und du meinst, dass ML ein ersatz für C wäre?
übrigens ist Tim nicht der einzige C-fan hier
Mr. N schrieb:
Ich habe nicht deswegen für Erlang gestimmt. Obwohl, teilweise doch, weil es so um die teuren Betriebssystem-Prozesse herumkommt.
nimm windows, da muss man für komkurrierende tasks nicht jedesmal einen neuen prozess starten
-
pale dog schrieb:
Mr. N schrieb:
Ich habe nicht deswegen für Erlang gestimmt. Obwohl, teilweise doch, weil es so um die teuren Betriebssystem-Prozesse herumkommt.
nimm windows, da muss man für komkurrierende tasks nicht jedesmal einen neuen prozess starten
Ich bezweifle, dass Windows es schafft, einen Thread in 45 Mikrosekunden zu starten. Erlang schon.
Linux braucht für einen neuen Prozess 100 Mikrosekunden, aber das ist eben mehr als doppelt so viel.
Kann allerdings auch leicht auf 200-300 hochgehen und das Beenden eines Prozesses dauert gleich nochmal länger.
-
pale dog schrieb:
nimm windows, da muss man für komkurrierende tasks nicht jedesmal einen neuen prozess starten
(selbst wenn Linux keine Threads hätte, erzeugt es immer noch schneller Prozesse als Windows Threads auf der gleichen Hardware :p)
Der enorme Vorteil von Userspace-Threads ist ja nicht nur das schnelle anlegen/zerstören. Auch der Speicherbedarf ist klein. Für Betriebssystem Threads werden zumindest auf PC-Betriebssystemen idr. eine eigene Page reserviert!
-
rüdiger schrieb:
pale dog schrieb:
nimm windows, da muss man für komkurrierende tasks nicht jedesmal einen neuen prozess starten
(selbst wenn Linux keine Threads hätte, erzeugt es immer noch schneller Prozesse als Windows Threads auf der gleichen Hardware :p)
Der enorme Vorteil von Userspace-Threads ist ja nicht nur das schnelle anlegen/zerstören. Auch der Speicherbedarf ist klein. Für Betriebssystem Threads werden zumindest auf PC-Betriebssystemen idr. eine eigene Page reserviert!
Mehrere denke ich, sogar.
Aber für Threads wird auch sicher mindestens eine Page verbraucht, für den Stack.
-
Mr. N schrieb:
Ich bezweifle, dass Windows es schafft, einen Thread in 45 Mikrosekunden zu starten. Erlang schon.
das ist keine hexerei. wahrscheinlich benutzt die erlang runtime unter win dafür einen thread pool oder fibers, nicht systemthreads.
Mr. N schrieb:
Linux braucht für einen neuen Prozess 100 Mikrosekunden, aber das ist eben mehr als doppelt so viel.
Kann allerdings auch leicht auf 200-300 hochgehen und das Beenden eines Prozesses dauert gleich nochmal länger.solche zeitangaben sind doch sinnlos. das ist von vielen faktoren abhängig z.b. von der taktfrequenz und was sonst noch so los ist. genauso gut könnte ich sagen, dass der tnkernel auf einem, mit 96 Mhz getakteten ARM7, eine task in weniger als 1µS startet. was spielt das für eine rolle?
rüdiger schrieb:
Für Betriebssystem Threads werden zumindest auf PC-Betriebssystemen idr. eine eigene Page reserviert!
warum muss das so sein?
-
pale dog schrieb:
Mr. N schrieb:
Ich bezweifle, dass Windows es schafft, einen Thread in 45 Mikrosekunden zu starten. Erlang schon.
das ist keine hexerei. wahrscheinlich benutzt die erlang runtime unter win dafür einen thread pool oder fibers, nicht systemthreads.
Nein. Erlang-Threads werden auf der Reduktions-Ebene geschedulet, ganz ohne Threads. Ich denke, wenn man Erlang auf einem Dualcore-System einsetzt startet er exakt zwei Threads (vielleicht auch drei).
Thread Pools skalieren nicht auf 40000 Threads!
pale dog schrieb:
Mr. N schrieb:
Linux braucht für einen neuen Prozess 100 Mikrosekunden, aber das ist eben mehr als doppelt so viel.
Kann allerdings auch leicht auf 200-300 hochgehen und das Beenden eines Prozesses dauert gleich nochmal länger.solche zeitangaben sind doch sinnlos. das ist von vielen faktoren abhängig z.b. von der taktfrequenz und was sonst noch so los ist. genauso gut könnte ich sagen, dass der tnkernel auf einem, mit 96 Mhz getakteten ARM7, eine task in weniger als 1µS startet. was spielt das für eine rolle?
Nun, die Zeit ermöglicht mir, abzuschätzen, wieviele Prozesse ich in einer Sekunde von Nulllast aus starten kann.
Die Zahlen sind auf einen modernen x86 ausgelegt. Ist erstaunlicherweise relativ konstant. fefe hat auf seiner Maschine 100 gebraucht und ich brauch auf meiner moderneren etwas mehr als 100.
pale dog schrieb:
rüdiger schrieb:
Für Betriebssystem Threads werden zumindest auf PC-Betriebssystemen idr. eine eigene Page reserviert!
warum muss das so sein?
Wegen dem Stack.
-
Mr. N schrieb:
Die Zahlen sind auf einen modernen x86 ausgelegt. Ist erstaunlicherweise relativ konstant. fefe hat auf seiner Maschine 100 gebraucht und ich brauch auf meiner moderneren etwas mehr als 100.
seltsam. ob da wohl die startzeit einer task wichtig ist, so dass sie auf schnellen maschinen ausgebremst werden muss? vielleicht ist auch der takt einer erlang-VM irgendwie festgelegt?
Mr. N schrieb:
pale dog schrieb:
rüdiger schrieb:
Für Betriebssystem Threads werden zumindest auf PC-Betriebssystemen idr. eine eigene Page reserviert!
warum muss das so sein?
Wegen dem Stack.
aber das ist doch nicht zwingend so. der stack einer neuen task könnte bereits allozierten bzw. reservierten speicher verwenden, auch bei systemen mit virtual memory management oder hardware MMU. die werkeln schliesslich 'unten' und sorgen dafür, dass der speicher auch da ist.
-
Mr. N schrieb:
pale dog schrieb:
Mr. N schrieb:
...und damit Tim mich mit C in Ruhe lässt.
C taucht überhaupt nicht in der liste auf und wieso sollte Tim dir C aufschwatzen wollen?
Weil Tim ein C-Fan ist und ich C vergessen habe. Ich hab ihm dann ML vorgeschlagen.
Ermmm, nein. Ich hab ML ganz ohne deine einflussnahme gewählt.