Ich glaube das Thema alternative Sprachen wurde hier schon einige male diskutiert. Dennoch..
Ich halte C/C++ eigentlich für ein MUSS. Es ist speziell in der Industrie noch immer der Standard. Auch wenn zumindest C etwas ärmlich an Funktion daherkommt. C++ hat mit der STL schon einiges zu bieten.
Haskell gehört ebenso zu meinen Favoriten. Bedarf aber immer einem Stück Motivation und vor allen Dingen Durchhaltevermögen. Z. Bsp. die Tatsache das es keine Schleifen gibt ist für mich immer wieder eine Challenge. Ohne Übung lässt sich bei weitem nicht so intuitiv ein Problem lösen.
Selbst bin ich auch an OCaml interessiert. Vielversprechend.
Interessante / sinnvolle Programmiersprache nach Python
Wenn es einem um "Erleuchtung" und das Erweitern des eigenen Horizonts geht, würde ich extreme Sprachen vorschlagen, die sich auf ein Paradigma konzentrieren. Pragmatischer sind Multiparadigmen-Sprachen, wo die einzelnen Paradigmen dann natürlich schwerer zu erlernen sind, weil sie zu vermischt sind.
Für rein funktionale Programmierung mit statisches Typsystem bietet sich ML (moderne Variante mit ein bisschen Objektorientierung ist OCaml) an. Für funktionale Programmierung mit dynamischem Typsystem würde ich Scheme empfehlen. Scheme ist zudem ideal, wenn man Metazirkularität und Homoikonizität kennenlernen möchte. Siehe auch http://www.python-forum.de/post-83870.html#83870
Haskell ist rein funktional, statisch getypt und träge in der Auswertung, was der Sprache einen ganz eigenen Twist gibt. Wer in die Welt der Monaden und Arrows vordringen will, ist hier richtig.
Für echte Objektorientierung führt ein Weg an Smalltalk vorbei, schon weil das Smalltalk-System historisch nicht nur wichtig als Programmiersprache ist, sondern auch für Maus, GUIs und Entwurfsmuster wie MVC und MVP. Für den Extrakick an Strangeness lohnt ein Blick auf Self, Io oder, zusammen mit den beiden oben genannten Schlagworten auf Ola Binis Ioke.
Stackbasierte Programmiersprachen wie Forth sind einfach anders und erlauben sowohl maschinennahe Programmierung als auch starke Abstraktionen. Factor ist eine moderne Implementierung. Wer eine Sun Sparc, einen PowerPC-Mac oder sonst ein Gerät mit OpenBoot BIOS hat, kann dort übrigens direkt Forth benutzen, es ist eingebaut. Ist es nicht cool, dass die nakte Maschine Fibonacci-Zahlen berechnen kann: `: fib dup 2 < if drop 1 else dup 1- fib 2- fib + then ; 10 fib`. Siehe auch http://www.python-forum.de/post-122068.html#122068
Prolog kann man machen, bringt einem aber IMHO nicht so viel. Selbst Syntax, aber funktional und nebenläufig ist Erlang. Kann man auch machen.
Ada, C, usw. finde ich zu gewöhnlich. Assembler bringt außer Schmerzen glaube ich auch nicht viel. Ich habe nach Basic zwar Z80 (teilweise sogar im Hexcode) erlernt, aber ich denke nicht, dass man heutzutage noch diesen Weg gehen muss.
Wichtig ist eigentlich nur eins: Wenn man eine neue Sprache erlernen will, darf man nicht einfach die bekannte Sprache in einer Syntax einzusetzen versuchen, sondern muss sich auf die neue Sprache auch wirklich einlassen.
Stefan
Für rein funktionale Programmierung mit statisches Typsystem bietet sich ML (moderne Variante mit ein bisschen Objektorientierung ist OCaml) an. Für funktionale Programmierung mit dynamischem Typsystem würde ich Scheme empfehlen. Scheme ist zudem ideal, wenn man Metazirkularität und Homoikonizität kennenlernen möchte. Siehe auch http://www.python-forum.de/post-83870.html#83870
Haskell ist rein funktional, statisch getypt und träge in der Auswertung, was der Sprache einen ganz eigenen Twist gibt. Wer in die Welt der Monaden und Arrows vordringen will, ist hier richtig.
Für echte Objektorientierung führt ein Weg an Smalltalk vorbei, schon weil das Smalltalk-System historisch nicht nur wichtig als Programmiersprache ist, sondern auch für Maus, GUIs und Entwurfsmuster wie MVC und MVP. Für den Extrakick an Strangeness lohnt ein Blick auf Self, Io oder, zusammen mit den beiden oben genannten Schlagworten auf Ola Binis Ioke.
Stackbasierte Programmiersprachen wie Forth sind einfach anders und erlauben sowohl maschinennahe Programmierung als auch starke Abstraktionen. Factor ist eine moderne Implementierung. Wer eine Sun Sparc, einen PowerPC-Mac oder sonst ein Gerät mit OpenBoot BIOS hat, kann dort übrigens direkt Forth benutzen, es ist eingebaut. Ist es nicht cool, dass die nakte Maschine Fibonacci-Zahlen berechnen kann: `: fib dup 2 < if drop 1 else dup 1- fib 2- fib + then ; 10 fib`. Siehe auch http://www.python-forum.de/post-122068.html#122068
Prolog kann man machen, bringt einem aber IMHO nicht so viel. Selbst Syntax, aber funktional und nebenläufig ist Erlang. Kann man auch machen.
Ada, C, usw. finde ich zu gewöhnlich. Assembler bringt außer Schmerzen glaube ich auch nicht viel. Ich habe nach Basic zwar Z80 (teilweise sogar im Hexcode) erlernt, aber ich denke nicht, dass man heutzutage noch diesen Weg gehen muss.
Wichtig ist eigentlich nur eins: Wenn man eine neue Sprache erlernen will, darf man nicht einfach die bekannte Sprache in einer Syntax einzusetzen versuchen, sondern muss sich auf die neue Sprache auch wirklich einlassen.
Stefan
Was meinst du in diesem Zusammenhand mit „Skalierbarkeit“?herakles hat geschrieben:Über Smalltalk hört man ja auch nur gutes. Auch hier würde mich der Vergleich zu C++ interessieren. Also Geschwindigkeitsnachteile ist klar. Aber wie siehts mit der skalierbarkeit aus?
Für Smalltalk-80 wurde Anfang der 90er noch bevor es Java gab der JIT-Compiler erfunden. Es hat Jahre gedauert, bis Java aufholen konnte und jetzt mit Hotspot die selbe VM-Technologie benutzt und weiter entwickelt hat, wie sie für Smalltalk (genauer Self) entwickelt wurde. Googles V8 JavaScript-Engine benutzt den selben Ansatz und ist daher mit Abstand die schnellste Implementierung. Prinzipiell kann die Performance daher vergleichbar mit Java und C++ sein. Viele existierende Systeme sind aber irgendwo auf dem Weg zu diesem Ziel bei "gut genug" stehen geblieben bzw. hatten wie CPython nie ein JIT-Compiler.
Squeak-Smalltak ist ein reiner Interpreter und von der Performance gleichauf mit CPython - jedenfalls was einen kurzer Test für Fibonacci-Zahlen angeht. Auf Grund der einfacheren Objektstruktur und des besseren Garbage-Collectors würde ich sagen, dass andere Benchmarks in Squeak besser abschneiden als sie es in CPython würden.
Was mit Skalierbarkeit gemeint ist, kann ich auch nur raten.
Wie bei CPython haben alle mir bekannten Smalltalk-Systeme ein Problem mit Mehrkernsystemen, da die Klassenbibliothek nicht für mehrere Threads ausgelegt ist. Das schränkt die Skalierbarkeit ein, denn man muss jetzt über Betriebssystemprozesse skalieren und jeder Prozess will ein komplettes Smalltalk-System mit eigenen Objekte und 10+ MB Hauptspeicher oder so haben. Die selbe Einschränkung hält aber auch Ruby-on-Rails-basierte Systeme davon ab, beliebt zu sein. Dort geht man von 50+ MB pro Prozess aus. Man müsste es JRuby nachmachen und ein JSmalltalk basierend auf der JVM entwickeln. Dabei hätte man natürlich die selben Probleme wie JRuby, auf einer eigentlich zu statischen Plattform laufen zu müssen, könnte aber die selbe Performance erreichen.
Ein Nachteil ist IMHO eher, dass die Entwicklungsumgebungen, auch wenn sie in den 80er und 90er Jahren führend waren, irgendwie in die Jahre gekommen sind. Squeak-Smalltalk wirkt so einfach fremdartig. Das Pharo-Projekt, auf dem jetzt Seaside aufbaut, bemüht sich allerdings, dies ein bisschen abzumildern. Es gibt da jetzt z.B. neuerdings moderne Truetype-Fonts mit Antialiasing, so wie das native UIs schon seit 10 Jahren oder so haben. Squeak zeichnet, das sollte man erwähnen, wie das Original-Smalltalk-80 von dem es geklont ist, sein UI bis zum letzten Pixel komplett selbst. Es lebt in einem Image, einem Speicherdump aller Objekte und man kann eigentlich sagen, dass das Original-Smalltalk seit es irgendwann im Jahre 1978 gestartet wurde, seit dem nie wieder beendet wurde. Es wird zum Speichern einfach nur angehalten und eingefroren.
Stefan
Squeak-Smalltak ist ein reiner Interpreter und von der Performance gleichauf mit CPython - jedenfalls was einen kurzer Test für Fibonacci-Zahlen angeht. Auf Grund der einfacheren Objektstruktur und des besseren Garbage-Collectors würde ich sagen, dass andere Benchmarks in Squeak besser abschneiden als sie es in CPython würden.
Was mit Skalierbarkeit gemeint ist, kann ich auch nur raten.
Wie bei CPython haben alle mir bekannten Smalltalk-Systeme ein Problem mit Mehrkernsystemen, da die Klassenbibliothek nicht für mehrere Threads ausgelegt ist. Das schränkt die Skalierbarkeit ein, denn man muss jetzt über Betriebssystemprozesse skalieren und jeder Prozess will ein komplettes Smalltalk-System mit eigenen Objekte und 10+ MB Hauptspeicher oder so haben. Die selbe Einschränkung hält aber auch Ruby-on-Rails-basierte Systeme davon ab, beliebt zu sein. Dort geht man von 50+ MB pro Prozess aus. Man müsste es JRuby nachmachen und ein JSmalltalk basierend auf der JVM entwickeln. Dabei hätte man natürlich die selben Probleme wie JRuby, auf einer eigentlich zu statischen Plattform laufen zu müssen, könnte aber die selbe Performance erreichen.
Ein Nachteil ist IMHO eher, dass die Entwicklungsumgebungen, auch wenn sie in den 80er und 90er Jahren führend waren, irgendwie in die Jahre gekommen sind. Squeak-Smalltalk wirkt so einfach fremdartig. Das Pharo-Projekt, auf dem jetzt Seaside aufbaut, bemüht sich allerdings, dies ein bisschen abzumildern. Es gibt da jetzt z.B. neuerdings moderne Truetype-Fonts mit Antialiasing, so wie das native UIs schon seit 10 Jahren oder so haben. Squeak zeichnet, das sollte man erwähnen, wie das Original-Smalltalk-80 von dem es geklont ist, sein UI bis zum letzten Pixel komplett selbst. Es lebt in einem Image, einem Speicherdump aller Objekte und man kann eigentlich sagen, dass das Original-Smalltalk seit es irgendwann im Jahre 1978 gestartet wurde, seit dem nie wieder beendet wurde. Es wird zum Speichern einfach nur angehalten und eingefroren.
Stefan
Ich bedanke mich bei allen für die Antworten. Sehr interessant und erkenntnisreich was hier geschrieben wird.
Übrigens auch sehr interessant wie viele Leute hier, in einem Python-Forum, zahlreiche "exotischere" Programmiersprachen kennen, welche sich im Berufsleben als Programmierer eigentlich nicht auszahlen. Schon klar dass man dadurch automatisch ein besserer Programmierer in einer Industrie-Programiersprache werden kann aber ihr wisst ja wie ichs mein: Es gibt nunmal kaum bis keine Stellenanzeigen für Forth, Lisp, Ocaml, Haskell, Snobol4, Smalltalk usw. - Programmierer.
Zum Thema: Eine eindeutige entscheidung kann ich momentan nicht treffen. Hat halt alles seine vor und Nachteile.
Ein Lisp steht aber ganz oben auf meiner Liste. Vor allem aufgrund der Eigenschaft als "programmierbare Programmiersprache". Dazu würde ich gern wissen ob cLisp/Scheme die einzigen Sprachen sind die dies ermöglichen oder ob es andere abseits der Lisp-Welt gibt. Ist Lisp nicht eigentlich recht nahe an einem Parser? Und zweitens: Welche interessanten Dinge kann man eigentlich mit dieser programmierbarkeit in sich selbst anstellen? Gibt es da konkrete Beispiele?
Zu Forth: Ist Forth tatsächlich schneller als C und benötigt weniger Code so wie es diese Seite behauptet:
http://www.inventio.co.uk/forthvsc.htm
Darii:
Mit skalierbarkeit meinte ich wie Smalltalk gegenüber C++ in Codezeilen, also Programmieraufwand, und Ausführungsgeschwindigkeit des enstandenen Programms, bei größeren und komplexeren Problemen abschneidet.
Übrigens auch sehr interessant wie viele Leute hier, in einem Python-Forum, zahlreiche "exotischere" Programmiersprachen kennen, welche sich im Berufsleben als Programmierer eigentlich nicht auszahlen. Schon klar dass man dadurch automatisch ein besserer Programmierer in einer Industrie-Programiersprache werden kann aber ihr wisst ja wie ichs mein: Es gibt nunmal kaum bis keine Stellenanzeigen für Forth, Lisp, Ocaml, Haskell, Snobol4, Smalltalk usw. - Programmierer.
Zum Thema: Eine eindeutige entscheidung kann ich momentan nicht treffen. Hat halt alles seine vor und Nachteile.
Ein Lisp steht aber ganz oben auf meiner Liste. Vor allem aufgrund der Eigenschaft als "programmierbare Programmiersprache". Dazu würde ich gern wissen ob cLisp/Scheme die einzigen Sprachen sind die dies ermöglichen oder ob es andere abseits der Lisp-Welt gibt. Ist Lisp nicht eigentlich recht nahe an einem Parser? Und zweitens: Welche interessanten Dinge kann man eigentlich mit dieser programmierbarkeit in sich selbst anstellen? Gibt es da konkrete Beispiele?
Zu Forth: Ist Forth tatsächlich schneller als C und benötigt weniger Code so wie es diese Seite behauptet:
http://www.inventio.co.uk/forthvsc.htm
Darii:
Mit skalierbarkeit meinte ich wie Smalltalk gegenüber C++ in Codezeilen, also Programmieraufwand, und Ausführungsgeschwindigkeit des enstandenen Programms, bei größeren und komplexeren Problemen abschneidet.
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Bedenke dass Python-Stellenanzeigen frueher auch sehr selten waren und der Bedarf zurzeit eher zunimmt.herakles hat geschrieben:ihr wisst ja wie ichs mein: Es gibt nunmal kaum bis keine Stellenanzeigen für Forth, Lisp, Ocaml, Haskell, Snobol4, Smalltalk usw. - Programmierer.
Nein, Factor hat auch Makros (mehr Infos) und ist ebenso wie Lisp eine Sprache mit sehr wenig Syntax. Und Lisp ist nicht nahe an einem Parser sondern eher an einem AST, also einen Quellcode-Baum in Reinform. Dabei sind Makros einfach nur Transformationen auf diesem Baum bevor der transformierte Baum tatsaechlich auch ausgefuehrt wird.herakles hat geschrieben:Ein Lisp steht aber ganz oben auf meiner Liste. Vor allem aufgrund der Eigenschaft als "programmierbare Programmiersprache". Dazu würde ich gern wissen ob cLisp/Scheme die einzigen Sprachen sind die dies ermöglichen oder ob es andere abseits der Lisp-Welt gibt. Ist Lisp nicht eigentlich recht nahe an einem Parser? Und zweitens: Welche interessanten Dinge kann man eigentlich mit dieser programmierbarkeit in sich selbst anstellen? Gibt es da konkrete Beispiele?
Interessante Dinge die man damit anstellen kann sind etwa die Objektsysteme von denen Scheme allein 15 verschiedene bietet oder dumme Spielereien, die Lisp zu Postfix-Syntax umbauen oder etwas weniger dumme aber ebenfalls sinnlose Spielereien, die die Haskell-Funktions-Semantik nachbauen. Ausserdem besteht die Sprache selbst aus Funktionen, Macros und Special-Forms, als Beispiel fuer ein Makro sei ``let`` gegeben, dass verwendet wird um Werte an Namen zu binden (wie Zuweisungsoperatoren in anderen Sprachen). Ein anderes Makro waere ``or``, dass bei einem Aufruf wie ``(or #f (long-computation))`` das zweite Argument niemals aufruft und dennoch von aussen wie ein normaler Funktionsaufruf ausschaut.
Wenn man bedenkt, dass Funktionsaufrufe in Forth nahezu nichts kosten da man schlichtweg keine Stackframes hat, koennte das zumindest fuer einige Codes zutreffen.herakles hat geschrieben:Zu Forth: Ist Forth tatsächlich schneller als C und benötigt weniger Code so wie es diese Seite behauptet:
http://www.inventio.co.uk/forthvsc.htm
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Ablaufgeschwindigkeit ist bis auf wenige Spezialfälle das bei weitem unwichtigste Feature einer Programmiersprache. Daher ist es scheißegal, ob nun bestimmte Programme in C oder Forth oder Smalltalk oder C++ schneller sind. Entscheidend ist viel mehr, wie die Sprache hilft, ein Problem zu verstehen und eine Lösung zu erarbeiten und diesen Prozess zu dokumentieren. Der schwierige Teil ist nämlich nicht das Aufschreiben der Lösung sondern das Finden und Verstehen des Problems.
Skalierbarkeit meint übrigens nicht, ob etwas schnell oder langsam ist, sondern, ob es (möglichst mit linearem Aufwand) vervielfältigbar ist. Ein PHP-Programm ist in der Regel skalierbar, wenn es die übliche "share-nothing"-Architektur hat und man einfach beliebig viele PHP-Server parallel schalten kann. Eine Datenbank wie mysql skaliert hingegen nicht so gut und CouchDB würde besser skalieren als mysql, auch wenn ein einzelnes mysql schneller ist als ein einzelner CouchDB-Server.
Smalltalk würde ich wie Lisp zur Gruppe der programmierbaren Programmiersprachen zählen. Forth ebenso. Gleiches gilt für alle Mitglieder der jeweiligen Familien wie Self, Io, Joy, Factor, usw. Dylan wäre z.B. ein Lisp mit Pascal-artiger Notation. IMHO furchtbar, aber das Ur-Dylan kennt glaube ich kaum einer. Da gab es so ein Handbuch von Apple, das man sich bestellen konnte und das ich mir viele Jahre später für viel Geld über ebay ersteigert habe. Hat jemand zufällig noch ein gut erhaltenes Bluebook für einen akzeptablen Preis? Fehlt mir noch in meiner Sammlung. Ach, und kennt jemand Curl? Das war ein Versuch, eine Alternative zu HTML + CSS + JavaScript als Lisp mit curly braces zu etablieren. Interessant, aber die hatten die irrige Annahme, damit richtig viel Geld verdienen zu können und somit war und ist es eine Randnotiz der Geschichte.
BTW, Smalltalks Syntax umfasst neben dem üblichen Zeug wie Zahlen, Zeichenketten, Symbole, Arrays und Blöcke noch das Vereinbaren von lokalen Variablen, Zuweisungen mittels :=, Rückgabe von Objekten mit ^ und Ausdrücken zum Senden von Nachrichten (also dem Aufrufen von Methoden). Das ist es. Im Gegensatz zu Lisp gibt es keine vordefinierten Namen für Bedingungen, Schleifen, usw. Das ist alles Teil der Klassenbibliothek.
Stefan
Skalierbarkeit meint übrigens nicht, ob etwas schnell oder langsam ist, sondern, ob es (möglichst mit linearem Aufwand) vervielfältigbar ist. Ein PHP-Programm ist in der Regel skalierbar, wenn es die übliche "share-nothing"-Architektur hat und man einfach beliebig viele PHP-Server parallel schalten kann. Eine Datenbank wie mysql skaliert hingegen nicht so gut und CouchDB würde besser skalieren als mysql, auch wenn ein einzelnes mysql schneller ist als ein einzelner CouchDB-Server.
Smalltalk würde ich wie Lisp zur Gruppe der programmierbaren Programmiersprachen zählen. Forth ebenso. Gleiches gilt für alle Mitglieder der jeweiligen Familien wie Self, Io, Joy, Factor, usw. Dylan wäre z.B. ein Lisp mit Pascal-artiger Notation. IMHO furchtbar, aber das Ur-Dylan kennt glaube ich kaum einer. Da gab es so ein Handbuch von Apple, das man sich bestellen konnte und das ich mir viele Jahre später für viel Geld über ebay ersteigert habe. Hat jemand zufällig noch ein gut erhaltenes Bluebook für einen akzeptablen Preis? Fehlt mir noch in meiner Sammlung. Ach, und kennt jemand Curl? Das war ein Versuch, eine Alternative zu HTML + CSS + JavaScript als Lisp mit curly braces zu etablieren. Interessant, aber die hatten die irrige Annahme, damit richtig viel Geld verdienen zu können und somit war und ist es eine Randnotiz der Geschichte.
BTW, Smalltalks Syntax umfasst neben dem üblichen Zeug wie Zahlen, Zeichenketten, Symbole, Arrays und Blöcke noch das Vereinbaren von lokalen Variablen, Zuweisungen mittels :=, Rückgabe von Objekten mit ^ und Ausdrücken zum Senden von Nachrichten (also dem Aufrufen von Methoden). Das ist es. Im Gegensatz zu Lisp gibt es keine vordefinierten Namen für Bedingungen, Schleifen, usw. Das ist alles Teil der Klassenbibliothek.
Stefan
Ist denke ich unterschiedlich. Ich habe das Gefühl, dass man bei Squeak lieber alles in Smalltalk programmiert als Sachen in C auszulagern, das macht sich bei Methoden wie ByteString(String)>>asInteger natürlich besonders bemerkbar. Das ist verglichen mit Python unglaublich langsam.sma hat geschrieben:Auf Grund der einfacheren Objektstruktur und des besseren Garbage-Collectors würde ich sagen, dass andere Benchmarks in Squeak besser abschneiden als sie es in CPython würden.
Guter Punkt, Darii. Gerade Squeak-Smalltalk folgt der Tradition, alles (auch die virtuelle Maschine) in Smalltalk zu bauen und ist damit eher mit PyPy als mit CPython zu vergleichen. IMHO ist das auch der richtige Weg, denn dann profitiert der gesamte Code von allen Optimierungen, die mit der Zeit in die VM eingebaut werden. Ein JIT-Compiler lässt aber schon Jahre auf sich warten... leider. Andere Smalltalk-Systeme wie VisualWorks haben so etwas schon länger als es den Begriff gibt (der aus der Java-Welt stammt).
Stefan
Stefan
Ich hab' jetzt mal so nebenbei mit Ocaml n'bisschen rumgespielt. Mein aktuelles Fazit: Ist nicht ganz so solide wie Haskell und schon gar nicht so easy wie Python. Alles ein bischen Krampf. Am Ende läuft es zwar, aber der Weg zum Erfolg ist sehr steinig. Nichts für Anfänger.hendrikS hat geschrieben:Selbst bin ich auch an OCaml interessiert. Vielversprechend.
Ich schätze mal, daß ich ein Problem in Python ca. 10 mal schneller implementiere.
Ich würde auch C empfehlen, das ist nicht so schwer. Ich habe auch nicht lange gebracht um mein erstes program damit zu schreiben - leider noch keins was mit dem internet zu tun hat, weil windows mir das vergrault hat und ich jetzt seid ca. 1 Woche versuche Linux auf meinen PC zu bekommen. Aber C ist auch - teilweise - platformunabhäning und mansche sachen sind auch so ähnlich wie in python. Man kann sogar hier highligned C Code schreiben:
Code: Alles auswählen
int main(void){
printf("Du willst C nehmen!");
return EXIT_SUCCESS;
}[b][i]ein kleines game für die die lust haben http://konaminut.mybrute.com[/i][/b]
;-)
;-)
-
lunar
Es wird aber spätestens dann recht schnell recht kompliziert, wenn man komplexere Datenstrukturen und/oder generische Programmierung benötigt.INFACT hat geschrieben:Ich würde auch C empfehlen, das ist nicht so schwer.
Die Highlighting-Fähigkeiten von phpbb sind natürlich auch hervorragend zur Beurteilung von Programmiersprache geeignet
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ja. Da bin ich immer total froh, dass die GLib einiges mitliefert, was C weniger schmerzhaft macht.lunar hat geschrieben:Es wird aber spätestens dann recht schnell recht kompliziert, wenn man komplexere Datenstrukturen und/oder generische Programmierung benötigt.
Zudem phpBB gar nicht von selbst highlighten kann sondern dies von CodeBB übernommen wirdlunar hat geschrieben:Die Highlighting-Fähigkeiten von phpbb sind natürlich auch hervorragend zur Beurteilung von Programmiersprache geeignet
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
birkenfeld
- Python-Forum Veteran
- Beiträge: 1603
- Registriert: Montag 20. März 2006, 15:29
- Wohnort: Die aufstrebende Universitätsstadt bei München
Ja, so gings mir auch. Nur schade, dass Ocaml in Sachen Performance Haskell immer wieder Schnippchen schlägt und viele deswegen doch zu Ocaml laufen...hendrikS hat geschrieben:Ich hab' jetzt mal so nebenbei mit Ocaml n'bisschen rumgespielt. Mein aktuelles Fazit: Ist nicht ganz so solide wie Haskell und schon gar nicht so easy wie Python. Alles ein bischen Krampf.hendrikS hat geschrieben:Selbst bin ich auch an OCaml interessiert. Vielversprechend.
Ich hab gestern Kaya gefunden, und fand das bisher relativ angenehm.
Syntaktisch würd ich die sprache zwischen Java und C++ einordnen.. was das Type-system angeht ist die sprache statisch getypt, und lässt sich mit dem mitgeliefertem Compiler in nativen Maschinencode übersetzen (der Compiler selbst ist in Haskell geschrieben).
Zudem bringt Kaya, genau wie Python, auch einen Interpreter mit, was für mich persönlich ein pluspunkt ist.
Ich werd mich jetzt weiter dem Kaya-tutorial widmen
Syntaktisch würd ich die sprache zwischen Java und C++ einordnen.. was das Type-system angeht ist die sprache statisch getypt, und lässt sich mit dem mitgeliefertem Compiler in nativen Maschinencode übersetzen (der Compiler selbst ist in Haskell geschrieben).
Zudem bringt Kaya, genau wie Python, auch einen Interpreter mit, was für mich persönlich ein pluspunkt ist.
Ich werd mich jetzt weiter dem Kaya-tutorial widmen
Das kommt denke ich sehr darauf an was man programmieren möchte bzw. was damit machen. Für Anwendungssoftware würde ich Python nehmen.
Ich persönlich liebe die Freiheit von C++ und die tiefen Einsichten bei Assemblersprache.
Ich denke in Zukunft werden sich Sprachen wie Python immer mehr durchsetzen, es ist einfach einfacher
Doch genau wie Assemblersprachen heute nicht ausgestorben sind (man denke an Cracking, Software Analyse...) wird auch C/C++ für bestimmte Zwecke überleben.
Ich persönlich liebe die Freiheit von C++ und die tiefen Einsichten bei Assemblersprache.
Ich denke in Zukunft werden sich Sprachen wie Python immer mehr durchsetzen, es ist einfach einfacher
Doch genau wie Assemblersprachen heute nicht ausgestorben sind (man denke an Cracking, Software Analyse...) wird auch C/C++ für bestimmte Zwecke überleben.
-
Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Hui... Leichenfledderei
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
-
noisefloor
- User
- Beiträge: 3856
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
IMHO ist ein guter Weg, wie es ziemlich weit vorne steht: nimm' das, was dir am meisten zusagt (aus welchen Gründen auch immer), dann ist wenigstens die Motivation hoch genug, der Lernkurve zu folgen.
Persönlich finde ich Lua interessant, dass ist aber rein subjektiv (nein, ich spiele kein WoW ).
Zum Thema Geschwindigkeit: Einen IMHO ganz interessanten Benchmark für wirklich viele Programmiersprachen gibt es hier: http://theowoll.netau.net/benchmark.html (immerhin braucht Lua 6x weniger CPU-Zeit als Python
).
Das Englische Wikipedia hat BTW eine ganz nette Übersicht über Programmiersprachen: http://en.wikipedia.org/wiki/Comparison ... _languages
Gruß, noisefloor
EDIT: noch ein Benchmark: http://shootout.alioth.debian.org/u32q/ ... t&lang=all
IMHO ist ein guter Weg, wie es ziemlich weit vorne steht: nimm' das, was dir am meisten zusagt (aus welchen Gründen auch immer), dann ist wenigstens die Motivation hoch genug, der Lernkurve zu folgen.
Persönlich finde ich Lua interessant, dass ist aber rein subjektiv (nein, ich spiele kein WoW
).Zum Thema Geschwindigkeit: Einen IMHO ganz interessanten Benchmark für wirklich viele Programmiersprachen gibt es hier: http://theowoll.netau.net/benchmark.html (immerhin braucht Lua 6x weniger CPU-Zeit als Python
).Das Englische Wikipedia hat BTW eine ganz nette Übersicht über Programmiersprachen: http://en.wikipedia.org/wiki/Comparison ... _languages
Gruß, noisefloor
EDIT: noch ein Benchmark: http://shootout.alioth.debian.org/u32q/ ... t&lang=all
-
BlackJack
@noisefloor: Geh mir weg mit Benchmarks und dann auch noch welche, die die Geschwindigkeit von *Sprachen* messen. Vergleich zum Beispiel mal 'ne JavaScript Implementierung von Microsoft mit V8 von Google. Welches von beiden ist jetzt "die Geschwindigkeit von JavaScript"?
Du magst den Benchmark mit dem Apfelmännchen interessant finden, aber das entspricht irgendwie nicht der typischen Anwendung für die *ich* Python einsetze. Das wird sicher nicht nur für mich zutreffen und sicher auch nicht nur für Python.
Ausserdem scheinen die Programme alle syntaktisch möglichst 1:1 die C-Version umzusetzen. Wenn Sprachen zum Beispiel eine Endlosschleife besitzen, wird trotzdem das ``while (1)``-Äquivalent genommen, was einen zusätzlichen unnötigen Test pro Schleifendurchlauf bedeuten kann.
Du magst den Benchmark mit dem Apfelmännchen interessant finden, aber das entspricht irgendwie nicht der typischen Anwendung für die *ich* Python einsetze. Das wird sicher nicht nur für mich zutreffen und sicher auch nicht nur für Python.
Ausserdem scheinen die Programme alle syntaktisch möglichst 1:1 die C-Version umzusetzen. Wenn Sprachen zum Beispiel eine Endlosschleife besitzen, wird trotzdem das ``while (1)``-Äquivalent genommen, was einen zusätzlichen unnötigen Test pro Schleifendurchlauf bedeuten kann.