Sprachensuche
-
Gregor schrieb:
Profi aller Sprachen schrieb:
zu a. PHP ist schneller als Java!
Warum lasse ich mich eigentlich immer provozieren?
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=php
Weil das zu krass ist, um es einfach so stehen zu lassen...
Etwas unbekanntere Sprachen, aber immer einen Blick Wert:
- Dylan(http://www.opendylan.org/)
- D(http://www.digitalmars.com/d/)
-
M.C.Sc. schrieb:
Etwas unbekanntere Sprachen, aber immer einen Blick Wert:
- Dylan(http://www.opendylan.org/)
- D(http://www.digitalmars.com/d/)Hallo,
Dylan sieht tatsächlich hochinteressant aus; die Anforderungen a. bis d.
sind offenbar erfüllt. Nur mit e. scheint es meinem ersten Eindruck nach
etwas zu hapern; auf opendylan.org sind drei Projekte verzeichnet, die
Dylan verwenden.Käme vielleicht nahe an die Erfüllung eines alten Programmiererwunschtraums: "so schnell wie C(C++,Java,C#,Haskell,...) und so einfach wie Python(Perl,Ruby,Smalltalk,...)" oder so ähnlich -- nichtzutreffendes bitte streichen
Also gut; dann mal sehen, was man mit Dylan so machen kann.
Danke für den Hinweis jedenfalls.
Grüße
-
Vielleicht ist folgender Link noch interessant für Dich(lohnt sich auf jeden Fall): http://chaosradio.ccc.de/cre031.html
-
-
Hallo
was ich suche, wäre eigentlich am ehesten sowas wie die Einheit von
* Syntax von Python
* OO-Modell und GC von Ruby
* Funktionales wie Lambda, closures, higher-order-functions etc. von Lisp
oder zumindest auch von Ruby
* konzeptionelle Eleganz von Smalltalk(oder Self,Io)
* Performance von C/C++ oder zumindest Java/C#.
* Popularität und Programmvielfalt wie bei Perl/Ruby/Python oder besser.Schade, daß es sowas nicht gibt. Obwohl ja, wie ich auch an den Antworten hier
sehen kann, Sprachen existieren, die den Anforderungen nahe kommen, aber
bei denen es dann meinem Eindruck nach leider etwas an der Popularität und der Implementatsionvielfalt hapert.
Na gut, ich warte weiter, vielleicht schreibt ja jemand mal so eine
one-size-fits-all-Programiersprache.
Von Fortran bis Ruby hat es ja auch fast ein halbes Jahrhundert gedauert.Grüße
-
Mir fällt da Spontan nichts ein, was deine Anforderungen erfällt.
Zu "c" fällt mir das Stichwort "duck typing" ein
Zu "e" könnte es vielleicht hilfreich sein, eine Sprache (bzw. eine konkrete Implementierung) aussuchen, die Code für die .Net oder Java-Plattform generiert, auch wenn "e" an sich dadurch noch nicht erfüllt ist.Die kombination deiner Kriterien wirst du nur in wenig populären Sprachen finden und somsit "e" nicht efüllen. Ansonsten musst du eben einen Teil deiner Anforderungen aufgeben. Ohne den funktionalen Teil von "b" könntest du beispielsweise Objective-C in betracht ziehen, was zu mindest in der Apple-Welt sehr populär ist und somit nicht alsozubald austerben will, aber auch für andere populäre Systeme verfügbar ist.
-
Hallo Helium,
ja, "Duck Typing" wäre wünschenswert wegen der bekannten Vorteile zur Entwicklungszeit,
aber es sollte dennoch möglich sein, gewisse Variablen, die an performance-kritischen Unterroutinen beteiligt sind, statisch zu typisieren,
damit ein Compiler performanten Code daraus machen kann.Denn wenn man sich die "Language shooutout Benchmarks" ansieht, dann frißt aus irgendeinem Grunde die dynmische Typisierung öfters mal 2 oder 3 Größenordnungen (Faktor 10..100) an Laufzeit-Performance, wohl weil vor jedem Methodenaufruf erst geprüft werden muß, ob das fragliche Objekt die Methode überhaupt kennt und sich
dann mittels "pointer-chase" zum Beginn der Methode durchhangeln muß.Noch besser wäre eine Sprache, bei der man keine Typen angeben müßte, weil der
Compiler selbst intelligent genug ist, um die Typangaben für jede Variable
aus der Initialisierung und den jeweiligen Methodenaufrufen
zu ergänzen und dann statisch typisiert zu compilieren, aber das ist vermutlich
im Moment noch science-fiction, wenn es nicht unmöglich ist.Boo käme wohl auch noch in Frage, zumindest, wenn man noch etwas wartet. Habe ich aber noch nicht ausprobiert.
-
Quodli Z. schrieb:
Noch besser wäre eine Sprache, bei der man keine Typen angeben müßte, weil der Compiler selbst intelligent genug ist, um die Typangaben für jede Variable aus der Initialisierung und den jeweiligen Methodenaufrufen
zu ergänzen und dann statisch typisiert zu compilieren, aber das ist vermutlich
im Moment noch science-fiction, wenn es nicht unmöglich ist.Die Type-Deduction von vielen funktionalen Sprachen geht doch schon sehr in die Richtung. Typen muss man da selten angeben. Dann wäre ja O'Caml oder F# vielleicht eine Möglichkeit, wobei du dann entscheiden musst, ob "d" für dich erfüllt ist. Ncoh viel besser gefällt mir allerdings Scala. Aber Type-Deduction ist eben keine dynamische Typisierung.
-
Noch besser wäre eine Sprache, bei der man keine Typen angeben müßte, weil der Compiler selbst intelligent genug ist, um die Typangaben für jede Variable
aus der Initialisierung und den jeweiligen Methodenaufrufen zu ergänzen und dann statisch typisiert zu compilieren, aber das ist vermutlich im Moment noch science-fiction, wenn es nicht unmöglich ist.D scheint das zu können: http://www.digitalmars.com/d/declaration.html
-
Helium:
Scala muß ich mir jetzt doch mal wirklich genau ansehen, vorgenommen
hatte ich mir das schon länger, aber u.a. die Notwendigkeit der Java-Runtime hatte mich bisher davon abgehalten, da ich lieber eine Sprache hätte, die nicht
von Runtimes oder VMs anderer Sprachen abhängt -- trotzdem.
-
x schrieb:
Noch besser wäre eine Sprache, bei der man keine Typen angeben müßte, weil der Compiler selbst intelligent genug ist, um die Typangaben für jede Variable
aus der Initialisierung und den jeweiligen Methodenaufrufen zu ergänzen und dann statisch typisiert zu compilieren, aber das ist vermutlich im Moment noch science-fiction, wenn es nicht unmöglich ist.D scheint das zu können: http://www.digitalmars.com/d/declaration.html
Wie gesagt gibt es viele Sprachen mit Type-Deduction (Beispielsweise alle ML-Derivate, wie SML, O'Caml, etc., Haskell und Hasekell-ähnliches, wie Clean, ...).
-
Hallo,
Hm... D hatte ich eigentlich schon für mich ausgeschlossen (Syntax und so), aber wenn einem das trotz statischer Typisierung das Deklarieren der Typen von
Variablen abnimmt, muß ich mir D auch noch mal genau ansehen.Haskell habe ich mir früher schon mal angesehen, und ich bezweifle nicht,
daß es sich um eine hervorragend konzipierte Sprache mit zahlreichen innovativen Ideen handelt, aber ich finde letztendlich doch, daß Haskell einem eine recht große Umgewöhnung in der Denkweise abverlangt. Die Performance von Haskell-Code
ist aber schon sehr beeindruckend.Gerade habe ich beim Stöbern im Internet ein Zitat gefunden, das (frei übersetzt)
ungefähr besagt, daß die meisten Features moderner Programmiersprachen
in den letzten paar Jahrzehnten das wieder-erfinden, was Smalltalk schon
vor ca. 25 Jahren hatte. Ein anderes Zitat besagt in etwa, daß es vielleicht gar
nicht so gut ist, Smalltalk zu lernen, so lange man vorhat, noch in anderen
Sprachen als Smalltalk zu programmieren, weil man dann im Vergleich mit Smalltalk enttäuscht sein würde.
Vielleicht schaue ich mir jetzt erstmal Smalltalk an, auch wenn mir klar
ist, daß die Laufzeit-Performance nicht (oder zumindest nicht immer)
mit der von statisch getypten Sprachen gleichziehen kann.Jedenfalls Danke für Eure Hinweise auf Sprachalternativen.
-
Du solltest dich vor allem nicht von einzelnen "Zitaten" die Wahl der zu erlernenden Sprache abhaengig machen, sondern dir verschiedene Sprachen gruendlich ansehen, um dann selbst ein Urteil bilden zu koennen. Wenn du jetzt beginnst, ueber Smalltalk zu lesen, kann es sein, dass du irgendwo ein Zitat findest, das dich dazu bewegt, Lisp zu lernen. Dann liest du in einer Usenetgruppe ploetzlich von einem ehem. Lispprogrammierer, der mit O'Caml gluecklich geworden ist. So wird man dann zum richtigen "Sprachenhopper".
Uebrigens werden wohl alle diese Sprachen den Punkt
* Popularität und Programmvielfalt wie bei Perl/Ruby/Python oder besser.
nicht erfuellen.
-
Hallo
ich stimme Dir im Grunde völlig zu, aber da ich "meine" Prog.Sprache
noch nicht gefunden habe, ist "Sprachen-Hopping" durchaus Mittel zum
Zweck, denn um eine Sprache zu wählen muß man ja auch einige ungefähr
kennen (wobei ich mit "kennen" meine: "kennen auf Tutorial- oder
Manual-Niveau").Es gibt aber auch wirklich viele Prog.Sprachen zur Auszahl; wenn es in den 60er
Jahren schon 700 Sprachen gab (s.Paper "the next 700 programming languages"),
dann müssen es inzwischen tausende sein.Immerhin habe ich meine Auswahl inzwischen einschränken können
auf OcaML, Scala, D, (evtl Haskell, Dylan) sowie (performance-mäßig
außer Konkurrenz) Smalltalk.Falls ich nicht bei Ruby für performace-unkritische kleine Aufgaben
und C++ für performance-kritische oder größere Sachen bleibe.Grüße
QZ.