Welcher Sprache gehört die Zukunft?
-
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.
-
pale dog schrieb:
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?
Hmm, nee, ich glaube das liegt daran, dass der da viel auf den Speicher zugreift oder so und mein Speicher ist halt relativ alt. Außerdem werden bestimmte in Benchmarks uninteressante Instruktionen glaub nicht so richtig optimiert.
Ausbremsen tut er bestimmt nicht.
Die Erlang-VM läuft so schnell sie kann, da ist nix festgelegt.
pale dog schrieb:
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.
Das ändert nichts daran, dass er danach nicht mehr frei ist, oder? :p
Tim schrieb:
Ermmm, nein. Ich hab ML ganz ohne deine einflussnahme gewählt.
Das ändert nichts daran, dass ichs dir empfohlen habe.
- Selbst wenn ichs erst danach empfohlen habe. OK, ich wusste, dass du ML gut findest und hab dir daher gesagt, dass es die Möglichkeit gibt... :p
-
Das mit den 45 Mikrosekunden für einen Erlang-Task war etwas voreilig, da ich es nicht reproduzieren kann. Der Charme von Erlang ist allerdings trotzdem, dass die Sprache zwar eigentlich elendslangsam ist, aber dafür eben Parallelisierung drauf hat. Und Fehlertoleranz. Und das klingt wie Musik in meinen Ohren.
-
Mr. N schrieb:
Welcher Sprache gehört die Zukunft?
Ich habe an der Umfrage nicht teilgenommen, weil keine der Sprachen in meinen Augen auf Dauer eine Zukunft hat, sie sind alle zu beschränkt.
Alle Programmiersprachen haben Einschränkungen, die nicht hingenommen werden wollen. C/C++ hat ein schlechtes Image, es wäre zu kompliziert, Java ist einfach nur ein immer größer werdender Klotz, PHP ist als Sprache krank, aber kompiliert nicht, was für die Webprogrammierer toll ist und die Sprache mit einem sehr dicken Bremsklotz versieht.
.NET wird von Microsoft grade durchgeboxt. Aber ist es wirklich sinnvoll bei jedem Programmstart das Programm erst zu kompilieren. Selbiges gilt für Java. Ist "kostet doch nicht viel" wirklich ein Argument, um Rechenzeit zu verschwenden?
Also lösen wir uns von der beschränkten Sicht konkreter Sprachen zu betrachten und machen uns über Konzepte Gedanken. Imperativ oder Funktional?
So, wie ich das sehe, läßt sich mit C++ wunderbar funktional programmieren. Man kan auch Befehle serialisieren und es hat den Anschein, dass das als Vorteil empfunden wird, denn die erfolgreichen Sprachen sind imperativ. Das könnte an den westlichen Sprache liegen, die Arbeitsweisungen serialisieren: "Packung aufreißen, Nüsse essen" stand auf einer Packung Nüsse als Bedienungsanleitung. Die Asiaten sehen das vielleicht anders: "Aus der aufgerissenen Packung entnommende Nüsse essen".Es gibt viele Asiaten. Imperativ ist eine zusätzliche Möglichkeit sich auszudrücken, also warum verzichten?
Vielleicht über Sprachgenerationen?
Maschinensprache (1.) und Assembler (2.) ist zu aufwendig, also nicht. Die 3. Generation wird benutzt. Die 4. Generation (spezialisierte Sprachen, z.B. SQL) nimmt eigentlich keiner als Programmiersprache ernst, für die meisten Probleme gibt es keine Sprache. Bleibt die 5. Generation - Problemorientierte: Programmiersprachen, die ohne den Lösungsweg zu kennen, aus dem beschriebenen Problem eine Lösung erstellen. Per BruteForce.Hier wird sich garantiert auch nichts ändern. Wir werden weiter beschreiben, was wir wollen und erklären, wie wir das erreichen wollen.
Was bleibt?
Die sogenannten "nicht spezialisierten" Sprachen, (C++, Java, Lisp, ...), die für beliebige Probleme, sind wie oben beschrieben, beschränkt. Wer schreibt Websites in C++? Treiber in Java? Raytracer in PHP?
Es gibt keine Sprache, die alle Problembereiche abdeckt. Nichtmals eine festgelegte Syntax.
Für alles darf man eine neue Sprache lernen.
5 Sprachen, die nach .NET kompilieren interessieren nicht, es gibt mehr als 5 Sprachen, die nach x86 kompilieren. Interessant ist also eher sich auf eine Sprache zu spezialisieren und damit Beliebiges zu programmieren.Damit der Programmierer nicht laufend Neues lernen muss, muss der Compiler Bekanntes auf den Problembereich anpassen können. Dafür müssten existierende Sprachen erweitert werden.
C++ ist eine recht bekannte Weiterentwicklung von C. Die größten Fehler in C++ liegen in der Abstammung von C - und es sind nicht die Zeiger...
An der Syntax traut sich niemand ran, wie PHP, C#, Java und so weiter belegen.Also sehe ich die Zukunft in einer C++ ähnlichen Sprache mit einem leistungsfähigen Compiler.
Ich selbst habe mich für das akademische Schattendasein entschieden - ich habe mich von der C++-Syntax verabschiedet.
-
Also sehe ich die Zukunft in einer C++ ähnlichen Sprache mit einem leistungsfähigen Compiler.
Klingt doch gut. Was meinst Du damit genau?
-
Xin schrieb:
Also sehe ich die Zukunft in einer C++ ähnlichen Sprache mit einem leistungsfähigen Compiler.
Was ist eine C++-ähnliche Sprache? Und worin soll die Ähnlichkeit bestehen? Anscheinend siehst du die Zukunft ja nicht in der Sprache die C++ (trivial) am ähnlichsten ist ...
-
Erhard Henkes schrieb:
Also sehe ich die Zukunft in einer C++ ähnlichen Sprache mit einem leistungsfähigen Compiler.
Klingt doch gut. Was meinst Du damit genau?
"genau" ist ein böses Wort.
Bei einer Umfrage, sagte mir jemand, dass die Ideen zu denen ich frage, zu ungenau wären. Ich würde ja nichtmals sagen, ob meine Sprache kompilierend oder interpretierend sei. Warum ist es eigentlich so selbstverständlich, dass eine Sprache entweder das eine oder das andere ist?
Wie entsteht aus einem ASCII Text ein ausgeführtes Programm?
Man kompiliert es und führt es aus. Ist es so einfach?
Ich hab's mal aufgedröselt: aktuell gibt es 10 Möglichkeiten, wie ein ASCII-Text zu einem ausgeführten Programm wird, beschrieben durch die 2 Begriffe "Interpreter" und "Compiler".
"genau" ist die Sache also heutzutage schon mehr zu beschreiben.Wie ich schon schrieb, ist es erforderlich, dass Programmiersprachen Beschränkungen verlieren, was heute gerne genau festgelegt sein soll, muss morgen ein Compilerswitch sein.
Bashar schrieb:
Xin schrieb:
Also sehe ich die Zukunft in einer C++ ähnlichen Sprache mit einem leistungsfähigen Compiler.
Was ist eine C++-ähnliche Sprache? Und worin soll die Ähnlichkeit bestehen? Anscheinend siehst du die Zukunft ja nicht in der Sprache die C++ (trivial) am ähnlichsten ist ...
Syntaktische Ähnlichkeit.
Beispiel: Die meisten populären Sprachen nach C vergleichen mit "==" und weisen mit "=" zu.
Ist das sinnvoll? In der Mathematik ist "=" der Vergleich. In Pascal auch.
":=" und "=" ist schlechter zu vertauschen, als "=" und "==".
Obwohl die beiden Operatoren leicht versehentlich zu vertauschen sind, heißen die Operatoren in PHP, Java, JavaScript und C# (und vermutlich 5 Milliarden anderen Sprachen) genau wie in C.Ich vermute, dass eine Sprache, die diesen Unsinn abstellt, erstmal nicht so schnell akzeptiert wird. Also wird die Sprache der Zukunft syntaktisch ähnlich zu C++ sein und einen leistungsfähigeren Compiler besitzen.
-
Xin schrieb:
Also wird die Sprache der Zukunft syntaktisch ähnlich zu C++ sein und einen leistungsfähigeren Compiler besitzen.
Nen leistungsfähigen Compiler finde ich auf jeden Fall Top!
Solche Visionen muß man haben!
-
Xin schrieb:
Erhard Henkes schrieb:
Also sehe ich die Zukunft in einer C++ ähnlichen Sprache mit einem leistungsfähigen Compiler.
Klingt doch gut. Was meinst Du damit genau?
"genau" ist ein böses Wort.
Xin schrieb:
Bei einer Umfrage, sagte mir jemand, dass die Ideen zu denen ich frage, zu ungenau wären. Ich würde ja nichtmals sagen, ob meine Sprache kompilierend oder interpretierend sei. Warum ist es eigentlich so selbstverständlich, dass eine Sprache entweder das eine oder das andere ist?
Wie entsteht aus einem ASCII Text ein ausgeführtes Programm?
Man kompiliert es und führt es aus. Ist es so einfach?
Ich hab's mal aufgedröselt: aktuell gibt es 10 Möglichkeiten, wie ein ASCII-Text zu einem ausgeführten Programm wird, beschrieben durch die 2 Begriffe "Interpreter" und "Compiler".
"genau" ist die Sache also heutzutage schon mehr zu beschreiben.Wie ich schon schrieb, ist es erforderlich, dass Programmiersprachen Beschränkungen verlieren, was heute gerne genau festgelegt sein soll, muss morgen ein Compilerswitch sein.
Ich denke, weder Erhard Henkes noch Bashar und erst recht nicht ich interessieren uns für so sprachfremde Dinge wie die Übersetzungsmodalitäten.
Das sind Implementierungsdetails, die lang nicht so wichtig sind wie die Sprache selbst.
Xin schrieb:
Bashar schrieb:
Xin schrieb:
Also sehe ich die Zukunft in einer C++ ähnlichen Sprache mit einem leistungsfähigen Compiler.
Was ist eine C++-ähnliche Sprache? Und worin soll die Ähnlichkeit bestehen? Anscheinend siehst du die Zukunft ja nicht in der Sprache die C++ (trivial) am ähnlichsten ist ...
Syntaktische Ähnlichkeit.
Beispiel: Die meisten populären Sprachen nach C vergleichen mit "==" und weisen mit "=" zu.
Ist das sinnvoll? In der Mathematik ist "=" der Vergleich. In Pascal auch.
":=" und "=" ist schlechter zu vertauschen, als "=" und "==".
Obwohl die beiden Operatoren leicht versehentlich zu vertauschen sind, heißen die Operatoren in PHP, Java, JavaScript und C# (und vermutlich 5 Milliarden anderen Sprachen) genau wie in C.Ist das wirklich das wichtigste, was dir einfällt??
Xin schrieb:
Ich vermute, dass eine Sprache, die diesen Unsinn abstellt, erstmal nicht so schnell akzeptiert wird. Also wird die Sprache der Zukunft syntaktisch ähnlich zu C++ sein und einen leistungsfähigeren Compiler besitzen.
Ich finde nicht, dass das eine Antwort ist. Du hast hier also gesagt, dass die Sprache nicht in Richtung Pascal gehen wird. So weit sind wir denke ich alle.
-
Jester schrieb:
Xin schrieb:
Also wird die Sprache der Zukunft syntaktisch ähnlich zu C++ sein und einen leistungsfähigeren Compiler besitzen.
Nen leistungsfähigen Compiler finde ich auf jeden Fall Top!
Solche Visionen muß man haben!Wohlwissend, dass es kein Kompliment ist, stimme ich Deiner Aussage ansonsten zu.
Manche Sprachdetails werden sicherlich nicht nur positiv aufgenommen werden. Sollte ich es zeitlich schaffen, den Compiler umzusetzen, sehe ich die Sache im großen Ganzen optimistisch - selbst, wenn ich erst in 10 Jahren fertig würde.Mr. N schrieb:
Ich denke, weder Erhard Henkes noch Bashar und erst recht nicht ich interessieren uns für so sprachfremde Dinge wie die Übersetzungsmodalitäten.
Das sind Implementierungsdetails, die lang nicht so wichtig sind wie die Sprache selbst.
Wenn das stimmen würde, gäbe es viel weniger PHP-Programmierer.
Mr. N schrieb:
Xin schrieb:
Beispiel: Die meisten populären Sprachen nach C vergleichen mit "==" und weisen mit "=" zu.
Ist das wirklich das wichtigste, was dir einfällt??
Es war ein Beispiel dafür, dass sich die C-Syntax hartnäckig inkl. ihrer Mängel hält, weil Änderungen schlecht akzeptiert werden. Die Variablendeklaration ist ja leider nur bedingt vergleichbar. Wie sieht's mit 'C#' aus? Wie deklariert man dort ein Array von Pointer Arrays?
(Doch, es gibt Pointer in C#...)Mr. N schrieb:
Xin schrieb:
Ich vermute, dass eine Sprache, die diesen Unsinn abstellt, erstmal nicht so schnell akzeptiert wird. Also wird die Sprache der Zukunft syntaktisch ähnlich zu C++ sein und einen leistungsfähigeren Compiler besitzen.
Ich finde nicht, dass das eine Antwort ist. Du hast hier also gesagt, dass die Sprache nicht in Richtung Pascal gehen wird. So weit sind wir denke ich alle.
Nein, ich sage, dass sie vermutlich C++ ähnlich blieben wird. Die Dinge, die ich interessant finde, sind für Dich nur unwichtige Implementierungsdetails.
Es ist halt eine Antwort, die Dich nicht interessiert.
-
Xin schrieb:
Nein, ich sage, dass sie vermutlich C++ ähnlich blieben wird. Die Dinge, die ich interessant finde, sind für Dich nur unwichtige Implementierungsdetails.
Es ist halt eine Antwort, die Dich nicht interessiert.Das triffts.
-
Xin schrieb:
Syntaktische Ähnlichkeit.
Beispiel: Die meisten populären Sprachen nach C vergleichen mit "==" und weisen mit "=" zu.Achso, dann war diese Aussage also reiner Zynismus. Ich verstehe. Passt auch zu deinen bisherigen Äußerungen zu dem Thema.
-
Bashar schrieb:
Xin schrieb:
Syntaktische Ähnlichkeit.
Beispiel: Die meisten populären Sprachen nach C vergleichen mit "==" und weisen mit "=" zu.Achso, dann war diese Aussage also reiner Zynismus. Ich verstehe. Passt auch zu deinen bisherigen Äußerungen zu dem Thema.
Ich bin ausnahmsweise mal nicht zynisch.
Allerdings bin ich mir auch bewußt, dass ein Konzept, das auf einer Reihe von Detailverbesserungen aufbaut, nicht mit einem oder zehn Details überzeugen kann. Die einen sind theoretischer Natur und damit unwichtig, andere sind unsichtige "Implementierungsdetails" und andere sind praktisch, aber verunreinigen das Gesamtkonzept.Die Chance so positive Rückmeldung zu erhalten ist im Prinzip Null und das Thema ist zu groß, um für jeden einzelnen Überzeugungsarbeit zu leisten.
Solange ich den Compiler nicht fertig habe und weiß, ob _ich_ damit zufrieden bin, werde ich die Spezifikationen nicht veröffentlichen. Bis dahin veröffentliche ich nichts, weil ich auch keine Lust habe, mich für Änderungen zu rechtfertigen.
Bis dahin habe ich kein Problem damit, dass es als Hoax, Vaporware oder sonstwas abgetan wird. Ich empfinde es als unhöflich, aber ich kann es verstehen.
Von einigen nicht ernstgenommen zu werden muss ich daher hinnehmen. Es gibt Leute, die das Projekt und mich besser kennen und es ernstnehmen.
-
Xin schrieb:
Es gibt Leute, die das Projekt und mich besser kennen und es ernstnehmen.
dann verheimlichst du's nur vor vor sachkundigen leuten, weil du angst hast, dass die nur daran herumnörgeln würden?
-
@Xin! Erst mit deinem letzten Post habe ich gerafft, das du an einer Sprache + Compiler arbeitest. Das sagt schon alles über dein Verhalten aus. Wenn du uns nichts über deine Sprache erzählen willst, solltest du auch davon nichts andeuten. Und es ganz für dich behalten.
