cobra die bessere Schlange?

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Samstag 23. Februar 2008, 14:41

Gerade in der c't gelesen (nur ein kleiner Artikel). Laut wikipedia:
Cobra ist eine objektorientierte Programmiersprache die von der Einfachheit und syntaktisch sehr stark an einige Skriptsprachen, im spieziellen an Python, angelehnt ist, jedoch nicht wie Skriptsprachen direkt interpretiert wird, sondern compiliert wird. Durch das Compilieren, also das Erzeugen einer direkt ausführbaren Datei (Binaries), ist Cobra wesentlich performanter als die Ausführung von Skripten und verbindet dies mit deren Ausdrucksstärke.
Hört sich schon mal interessant an...

Offizielle Webseite: http://cobra-language.com
Was ich auf die schnelle nicht finden konnte, unter welcher Lizenz das ganze steht...

Was haltet ihr davon?

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Samstag 23. Februar 2008, 15:03

Also das optionale static typing haut mich jetzt nicht um, das ist nur ganz selten mal nützlich und da kommt man oft mit Multimethods auch hin. Ansonsten sieht es ganz nett aus, erinnert mich vom Aufbau etwas an Pyrex, wenn auch einen Level höher. Contracts könnten interessant sein, aber da ich nicht aus der Eiffel-Ecke komme müsste ich erst selbst die Nützlichkeit ausprobieren (sieht aber aus, wie etwas was man mit bbisschen weniger syntaktischen Zucker auch mit RuleDispatch oder PEAK-Rules in python hinbekommt und wenn man EE noch dazu nimmt dann sogar mit syntaktischen Zucker). Was mich jetzt auch nicht groß begeistert ist, dass es auf der CLR läuft, und dass es nicht freie Software ist (wobei, wenn man WP glaubt wird es BSD oder MIT werden, was ich super finde). Es generiert wohl auch Binaries für .NET, aber das kann IronPython ja auch.

Gemacht ist Cobra von Chuck Esterbrook, den kenne ich noch aus Webware-Zeiten. Hmm, hoffentlich ists besser als das ;)

Naja, damit reiht sich Corba zu den anderen Python-like Sprachen wie Boo und tinypy ein. Ich glaub es ist mir zu Python-ähnlich, damit ich da besonders begeistert wäre. Wenn ich mit .NET was machen wollte, könnte das sich allerdings als nützlich erweisen.

Edit: Contracts als Docstring-Hack. Hmm, wir brauchen eine Möglichkeit, Python-Syntax zur Laufzeit zu modifizieren ;)
My god, it's full of CARs! | Leonidasvoice vs Modvoice
lunar

Samstag 23. Februar 2008, 16:38

Begeistert bin ich nicht wirklich... der Vergleich mit Python hat mich nicht überzeugt, meiner Lieblingssprache den Rücken zu kehren:

Better error checking
Ich glaube nicht an die Vorteile statischer Typisierung bei der Fehlersuche, sonst würde ich Python nicht nutzen.

Contracts
Täusche ich mich, oder kann man das mit assert und Unittests auch erreichen? Als Ersatz für Dokumentation sind sie - anders als im Vergleich behauptet - nicht wirklich tauglich.

Unit tests
Hier sehe ich sogar eher Nachteile als Vorteile. Tests sind nicht Teil des Programmablaufs. In echten Code sind sie also deplaziert. Gerade bei umfangreichen Tests versperren sie nur den Blick auf den eigentlichen Code.

Das Argument, Tests würde so eher von vorneherein implementiert, kann ich nicht nachvollziehen. Warum sollte jemand, der unittests nicht in einem externen Modul implementiert, seine Meinung bei integrierten Tests ändern?

Gleiches gilt für das Argument, Tests würde so eher aktuell gehalten. Wer sich streng an das Prinzip "ungetesteter Code ist fehlerhafter Code" hält, wird seine Tests aktuell halten, gleich ob intern oder extern. Wer dagegen schlampig im Umgang mit Tests ist (so wie ich ;) ), wird sich durch interne Tests auch nicht wirklich zum Testen motiviert oder gezwungen fühlen.
Die Frage nach der Aktualität des Codes ist mehr eine Frage der Einstellung und der Entwicklungspolitik. Syntaktischer Zucker kann da meiner Meinung nach nur wenig Hilfestellung leisten. Ordentliche Entwicklungsrichtlinien sowie ein Review-Prozess für Commits bewirken da mehr. Glücklicherweise ist derartiges bei großen Projekten mittlerweile üblich.

Accurate Math
Ungenaue Fließkommatypen sind in der Tat problematisch. Genaue Fließkommazahlen als Sprachbestandteil zu implementieren, ist also keine schlechte Idee. Dies ist auch der einzige Punkt, an dem ich diesem Vergleicht tatsächlich zustimme.

Allerdings halte ich dieses Problem nicht für so dramatisch, als dass ich meine Lieblingssprache dafür ändern würde. Der Workaround für Python wird in dem Artikel ja bereits gezeigt (Runden wäre eine Alternative), und bei mathematischen Berechnungen ist man mit numpy und dergleichen eh besser bedient.

Speed
Auch ohne Benchmarks glaube ich dem Autor einfach mal, dass seine Sprache schnell ist. Nur sehe ich den Mehrwert nicht:

Die reine Geschwindigkeit der Sprache ist heute immer weniger wichtig. Gefordert sind doch viel mehr Sprachen und Bibliotheken, die effizienten, parallelen Code ermöglichen. Jede Art von Number Crunching läuft heute auf Mehrprozessor-Systemen ab. Effiziente Parallelisierung ist also wichtiger als reine Sprachgeschwindigkeit selbst. Das bietet momentan weder Python noch Cobra. In diesem Gebiet erlebt C++ gerade seine Wiederauferstehung dank OpenMP und Bibliotheken wie Thread Building Blocks.

Für Spiele und Suche scheint CPython dagegen schnell genug zu sein. Battlefield 2 und Google kennt jeder ;)

Designed for .NET/Mono
IronPython existiert.

Syntactic improvements
Ausführliche Assertions sind nett. Für den Syntaktischen Zucker bei Eigenschaften gibt es autoproperty. Und bin ich eigentliche der einzige, der bei in Strings eingebetteten Code die Gefahr von Code-Injection sieht?

Self-hosted / Self-implemented
Let's wait fpr pypy ;)

Was ich damit sagen will: Nett, aber nicht unbedingt ein elementarer Vorteil ;)
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Samstag 23. Februar 2008, 17:46

lunar hat geschrieben:Self-hosted / Self-implemented
Let's wait fpr pypy ;)

Was ich damit sagen will: Nett, aber nicht unbedingt ein elementarer Vorteil ;)
Das hat sowohl vor als auch Nachteile, ganz recht. Vorteile sind, dass die User auch ganz einfach zu Entwicklern werden können. Aber wie man an Django sieht, kann man da auch einfach über das Ziel hinausschießen, wenn das Kernteam zu klein ist, alle Verbesserungen durchzugehen und implementieren. Cobra hat einen Entwickler.
Der Nachteil ist auch, dass man wenn man self-hosted ist, weniger bereits existierende Tools nutzen kann. Als Beispiel könnte ich Bison und Flex angeben, die einem Arbeit abnehmen können. Andererseits, CPython hat so oder so einen eigenen Parser.

Python selbst hat so viele interessante Erweiterungen (Rule-Dispatch, Monaden, Continuations), was ich mir da wünschen würde, wäre eine Möglichkeit die Syntax anzupassen. Natürlich - ein zweischneidiges Schwert. MonadPython würden viele nicht auf den ersten Blick verstehen. Andererseits Monaden in normalen Python-Code sind auch nicht einfacher zu verstehen. Ich sollte mir definitiv mal EasyExtend ansehen.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
BlackJack

Samstag 23. Februar 2008, 19:25

@lunar: Contracts: Man kann mit ``assert``\s und Unit Tests nicht ganz das gleiche erreichen. Zum einen sind die Vor- und Nachbedingungen beim Vertrag klar als solche ausgezeichnet und damit viel öffentlicher als interne Zusicherungen, bei denen man ja nicht auf den ersten Blick weiss, ob sie nun teil der API sind, oder nur "interne" Tests. Damit sind sie auf jeden Fall eine nette formale Ergänzung zur Dokumentation. Und dann erlaubt Cobra anscheinend, genau wie Eiffel in der Nachbedingung auch auf den alten Zustand zuzugreifen.

Unit tests: Sehe ich auch so. Direkt im Code eignet sich das höchstens für Sachen, die man in Python auch in einen Doctest schreiben würde, also eher dazu um Beispiele in der Doku abzusichern, so dass sie auch dem tatsächlichen Verhalten des Codes entsprechen.

Accurate Math: Die Argumente von der Seite kann ich gar nicht nachvollziehen. Rechnen mit Kommazahlen ist beim Computer letztendlich immer mit Ungenauigkeiten verbunden. Meine Mono-Version ist gerade nicht aktuell genug um Cobra zu starten, aber ich wette auch bei denen ist (1.0/3)*3 nicht 1. Und Falls es bei 1/3 keine Probleme gibt, sind es halt andere Brüche, die in der internen Darstellung nicht mit endlichen Stellen repräsentiert werden können.

Speed: Ich glaube es erst einmal nicht. Es gibt Bereiche wo IronPython schneller ist als CPython und umgekehrt. Warum sollte Cobra jetzt plötzlich klar schneller sein. Die statische Typisierung ist optional. Und wenn durchgehend typisiert wird, möchte ich aus Fairnisgründen bitte Cython auf der Python-Seite im Einsatz sehen. Die Autoren haben sich unter anderem das Ziel gesetzt Cython in absehbarer Zeit in die Standardbibliothek zu bringen.

Designed for .NET/Mono: IronPython läuft nur auf .NET, ist aber soweit ich weiss nicht unbedingt ein netter "Mitspieler". Cobra schon eher, eben wegen der statischen Typisierung, die es auch erlaubt Cobra-Code von anderen Sprachen aus zu nutzen.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Samstag 23. Februar 2008, 19:49

BlackJack hat geschrieben:Designed for .NET/Mono: IronPython läuft nur auf .NET, ist aber soweit ich weiss nicht unbedingt ein netter "Mitspieler". Cobra schon eher, eben wegen der statischen Typisierung, die es auch erlaubt Cobra-Code von anderen Sprachen aus zu nutzen.
Naja, aber es ist auch optional statisch typisiert und da gibts schon wieder das Problem. Ich weiß jetzt gar nicht wie das in IronPython und IronRuby auf der DLR gelöst wird, weiß da jemand Details?

Außerdem habe ich in Erinnerung, dass man IronPython-Code auch in anderen .NET-Sprachen nutzen kann. Das war ja eben der größte Vorteil gegenüber Python.NET, welches nur unidirektional ist/war.

Edit: Die Cython-Leute haben die Python-Lizenz nicht gelesen und gemerkt, dass sie die Lizenz nicht nutzen können, weil die nur von der PSF ausgestellt werden kann. OSI hat sie unter die "non-reusable licenses" eingestuft.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
lunar

Samstag 23. Februar 2008, 20:20

BlackJack hat geschrieben:Zum einen sind die Vor- und Nachbedingungen beim Vertrag klar als solche ausgezeichnet damit viel öffentlicher als interne Zusicherungen, bei denen man ja nicht auf den ersten Blick weiss, ob sie nun teil der API sind, oder nur "interne" Tests. Damit sind sie auf jeden Fall eine nette formale Ergänzung zur Dokumentation.
Aber auch nicht mehr. Die Nachbedingungen einer Funktion sind eh durch den Zweck der Funktion selbst definiert. Um das Beispiel aus der Dokumentation aufzugreifen: Wem nicht klar ist, dass die Methode drive eines Autos die Anzahl der gefahrenen Kilometer erhöht, sollte sich fragen, ob Programmierung wirklich das richtige ist ;)

Für die Vorbedingungen gilt dies zwar nicht, aber diese sollten imho eh nochmal in der Dokumentation erklärt werden. Folglich muss man die Informationen des Contracts in der Dokumentation eh nochmals gesondert erwähnen und vor allem erklären.

Die Absicherung der Zustände dagegen erreicht man auch mit assert und Testing.
Und dann erlaubt Cobra anscheinend, genau wie Eiffel in der Nachbedingung auch auf den alten Zustand zuzugreifen.
Das macht Sinn, lässt sich aber bei Bedarf auch anders lösen.

Es ist ja nicht so, dass Contracts schlecht wären, nur sehe ich eben keinen gewaltigen Vorteil durch ihren Einsatz. Imho kaum mehr als syntaktischer Zucker und Dokumentationsfeature.
Designed for .NET/Mono: IronPython läuft nur auf .NET, ist aber soweit ich weiss nicht unbedingt ein netter "Mitspieler".
Das wusste ich nicht. So tief habe ich mich nie mit IronPython auseinander gesetzt. Allerdings gibt es für .NET noch andere, Python-artige Sprachen.
Ich persönlich finde z.B. wesentlich interessanter als Cobra, weil es in meinen Augen wirklich sinnvolle Dinge umsetzt. Neben größeren Dingen wie syntaktischen Makros, die in gewissen Grenzen die Definition eigener Statements ermöglichen, sind es vor allem auch kleine Dinge, die an boo cool sind: Literale für reguläre Ausdrücke syntaktisch mal richtig gelöst zu sehen, ist einfach schön ;)

Solche kleinen Dinge erleichtern imho das Programmieren wesentlich mehr als Contracts oder Tests im Code.
Filb
User
Beiträge: 8
Registriert: Dienstag 19. Februar 2008, 20:55

Samstag 23. Februar 2008, 21:35

hmm, mich würden laufzeit benchmarks zu cobra vs. python interessieren :shock:
BlackJack

Samstag 23. Februar 2008, 22:58

@lunar: Klar kann man sich immer Anhand von einfachen Beispielen lustig machen. Selbst wenn dem Programmierer klar ist, dass sich das Auto weiterbewegt, und er sich alle Mühe gibt, die Methode so zu implementieren, kann es ja trotzdem immer noch passieren, das es *nicht* geschieht, weil er in den insgesamt, sagen wir mal 20 möglichen Verzweigungen inklusive Aufrufen von anderen Methoden, irgendwo eine Konstellation von Anlasser, Motordrehzahl, Öl- und Benzinstand einen Fall vergessen hat, der dann zu einem unerwarteten Zustand des Objekts führt. Oder vielleicht irgendwo ein Integer der zu gross wird, ins negative umkippt und sich das Auto dann im Vorwärtsgang 2 Lichtjahre rückwärts bewegt. Ist ja nicht so, dass so etwas nicht vorkommen würde. Und dann gibt's halt diesen Check. Bei (wirklich) statisch typisierten Sprachen kann unter Umständen sogar der Compiler melden, wenn einem möglichen Programmablauf die Nachbedingung nicht erfüllt werden kann.

Und nicht immer ist so klar was *genau* als Nachbedingung gilt. Diese Garantien und der eigentliche Code können auch von völlig verschiedenen Personen, aus unterschiedlichen Abteilungen kommen. Da ist manchmal so eine Beschreibung besser als (nur) eine formale, pseudoformale, oder vielleicht sogar nur umgangssprachliche Spezifikation. Bei einem solchen Grad an Arbeitsteilung kann es ein wirklicher Mehrwert sein, Vertrag und Implementierung nicht zu vermischen.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Sonntag 24. Februar 2008, 10:32

Ich habe mir gestern das 2008 Lang.NET Video angeschaut und kurz die Doku überflogen. Ich finde zwar die Tatsache beeindruckend, dass jemand ein Jahr an seiner eigenen Sprache arbeitet, aber das Ergebnis ist dann doch nur ein C# mit anderer Syntax.

Wohl in der Versuch, alles statisch zu typisieren führt, zeigt z.B. Scala. Prinzipiell klingt das Versprechen, Typfehler zur Übersetzungszeit zu finden gut, der Preis ist aber IMHO zu hoch und außerdem - wieso Übersetzungszeit? Programmiersprachen, die einen Edit-Compile-Test-Ritus benötigen sind so "letztes Jahrtausend", dass mir der Ansatz von Cobra, eine reine Compilersprache zu sein, missfällt.

In die Sprache eingebaute Unittests (statt diese im Kommentarstring zu verstecken) finde ich gut. Vor- und Nachbedingungen haben mich selten überzeugt, diese empfinde ich als entbehrlich. Dennoch: statische Typen sind natürlich nur ein Speziallfall von contracts und diese Erkenntnis vermisse ich ein bisschen in der Sprache.

Das floats nicht der Default für Arithmetik sind, ist eine gute Entscheidung.

Die Syntax finde ich zu einfach. Was ich damit meine, ich finde kaum Konstrukte, die helfen zu abstrahieren. Der nutzen des "?"-Operator ist IMHO eher fragwürdig, List Comprehensions sehen primitiver aus als das Python-Gegenstück, top-level-Funktionen gibt es gnauso wenig wie verschachtelte Klassen oder Funktionen wie es scheint. Und etwas wie "post while" ist eher irritierend. Mich persönlich stören auch noch die fehlenden ":" im Vergleich zu Python und die regel, dass man das "this" weglassen kann und dann einfach ".foo" schreibt statt den Empfänger immer explizit zu schreiben.

Ich hatte mir den Forth-Interpreter als Beispiel angeschaut. Daraus schließe ich, dass Pythons Mehrfachzuweisungen ebenfalls nicht gehen. Dafür darf man offenbar () bei Definitionen von Methoden ohne Parameter weglassen.

Wie Leonidas aus "self-hosted" einen Nachteil kreiert, finde ich interessant, ich kann aber diese Einschätzung nicht teilen. Ich halte es für einen großen Vorteil, hat man doch wenigstens den Beweis, dass die Sprache zur Entwicklung von Sprachen taugt. Ich sehe das eher als Praxistest und Gelegenheit, die passenden Werkzeuge zu entwickeln. Da Cobra ja C# erzeugt, sollte es dem Erfinder daher doch möglich sein, ein VisualStudio-Plugin (ich vermute mal, dass man diese in C# bauen kann) in Cobra zu bauen. Es wäre jedenfalls IMHO viel einfacher, ein in Python geschriebenes Python zu erweitern als eines, das in C entwickelt ist - schon der Buildprocess ist dort nicht ohne.

Das etwa Squeak-Smalltalk in (einem Subset von) Squeak geschrieben wurde, war IMHO immer ein großer Vorteil. Die VM wird da über den Umweg GCC erstellt.

Ich finde BlackJacks Argument "das war schon immer" bgzl. floats wenig überzeugend. Scheme etwa unterscheidet seit je her bei numerischen Typen "exact" und "inexact" und man warnt vor zweiterem. Bei fast allen Smalltalk-Systemen die ich kenne, wird standardmäßig mit Brüchen gearbeitet, wenn Ganzzahlen nicht reichen und "floats" muss man wieder explizt konvertieren. Sehr praktisch, wenn "1 / 3 * 3" auch wirklich wieder "1" ist - und zwar, weil das System Bruchrechnung beherrscht und kürzen kann.

Das Cobra schneller als Python ist, glaube ich im Gegensatz zu BlackJack durchaus, denn wir sehen da ja "nur" ein C# oder VB mit anderer Syntax. Dynamische Aspekte von Python, wie z.B. das __dict__ einer Klasse zur Laufzeit ändern zu können, sind soweit ich es sehe, in Cobra überhaupt nicht möglich. Etwas wie

Code: Alles auswählen

class ForthMachine
  var _stack as Stack<of Word>
  var _definitions as Dictionary<of Word, Definition>

  def init
    _stack = Stack<of Word>()
    _definitions = Dictionary<of Word, Definition>()
    .define('quit', 'built-in:quit')
 
class Word
  implements IComparable<of Word>

  def compareTo(other as Word) as int
    if .isInt
      if other.isInt
        return .int.compareTo(other.int)
      else
        return -1
    # usw..
kann man 1:1 in C# und damit dann auch in IL kompilieren. Das ist dann natürlich genauso schnell und deutlich schneller als (C|Iron)Python, welches für jede Methode in einem Dictionary suchen muss.

Leonidas fragte noch, wie die DLR funktioniert. Meines Wissens stellt die DLR einen abstrakten AST als Rahmenwerk zur Verfügung, der für jede Sprache konkretisiert werden muss, gemeinsame Sprachfeatures wie if-Bedingungen oder while-Schleifen aber schon mal abbildet. Die DLR macht es daneben einfach, aus dem AST IL-Bytecode zu generieren, wieder zu laden und dann von der .NET-VM ausführen zu lassen. Methodensuche, Methodenaufruf, usw. sind Sprachspezifisch und müssen jeweils implementiert werden. DLR legt hier den Einsatz von CallSite-Objekten (das sind AFAIK Polymorphic Inline Caches, PICs, ein typischer Weg, dynamische Sprachen schneller zu machen) nahe, die Ergebnisse vorheriger Suchen aufbewahren. Deren Verwaltung ist jedoch nicht trivial und diese machen es dann auch schwierig, Sprachen per DLR auf .NET zu ziehen. Dennoch ist es einfacher als bei Java, wo man sie eine entsprechende Infrastruktur selber bauen müsste - wie es z.B. JRuby oder Groovy machen. Allerdings ist die Java-VM deutlich besser, was Optimierungen angeht und man muss hier nicht so viel Aufwand treiben, sagt Sun. Dafür kann der Bytecode nicht so viel und man muss etwa für jede Python-Funktion oder Ruby-Methode eine Java-Klasse mit eigenem ClassLoader erzeugen, während .NET hier nur Delegates für mehrere Methoden einer Klassen braucht. Aber auch hier gibt es Probleme, wenn man Methoden zur Laufzeit ändern will, irgendwie muss man mit AppDomains was machen, was letztlich noch aufwendiger ist als die ClassLoader von Java.

Prinzipiell funktioniert JRuby oder Jython wohl so:

Code: Alles auswählen

public abstract class PyFunction extends PyObject {
  public abstract PyObject call(PyFrame f, PyTuple args, PyDict kw);
  ...
}
public class PyBuiltinFunctionAbs extends PyFunction {
  public PyObject call(PyFrame f, PyTuple args, PyDict kw) {
    if (args.len() != 1) return raise(TypeError, "abs() takes ...");
    PyObject o = args.getitem(f, 0);
    if (o isinstanceof PyInt) {
      PyInt i = (PyInt) o;
      if (i.value < 0) return PyInt.make(-i.value);
      return i;
    }
    if (o isinstanceof PyInstance) {
      o = o.getattr(f, "__abs__");
      if (o != null) return o.call(f, args, kw);
      return raise(AttributeError, "...");
    }
    return raise(TypeError, "bad operand type for abs()...")
  }
}
static {
  builtins = new PyModule();
  builtins.def("abs", new PyBuiltinFunctionAbs());
}
Für jeden noch so kleinen Funktionsaufruf muss bei Python gewaltig viel Code durchlaufen werden.

Was ich mir bei einer neuen Sprache wie Cobra wünschen würde, wären z.B. sealed classes ähnlich wie sie Dylan kennt. Damit könnte man dem System sagen, es kann gefahrlos die __dict__ wegoptimieren, man wird sie nie verändern. Andererseits, offene Klassen sind so verdammt praktisch.

Fazit: Müsste ich VB oder C# mit Super-IDE-Support aber nicht so doller Syntax gegen Cobra mit vielleicht netterer Syntax aber zur Zeit ohne IDE Support abwägen, würde wohl C# gewinnen. Wenn schon neue Sprache, dann auch bitte neue Konzepte und nicht einfach nur eine andere Syntax.

Stefan
BlackJack

Sonntag 24. Februar 2008, 11:49

@sma: Mein Argument zu Fliesskommazahlen sollte nicht "das war schon immer" sein, sondern das mit "genauen" Zahlen entweder auch Probleme mit der endlichen Genauigkeit auftreten, oder im Fall von Brüchen, die Zahlen vom Speicherverbrauch bei nicht trivialen Rechnungen in Schleifen ganz schön "explodieren" können, wenn keine kleinen gemeinsamen Nenner gefunden werden können. Probleme können in jedem Fall auftreten und darüber sollte man den Anwender informieren, statt zu sagen hey, Cobra hat endlich mal exakte Zahlen, das ist viel besser als bei Python/C#/whatever uses floats.

Ich weiss nicht was Cobra so eigenes an Standardbibliothek mit bringt, aber spätestens wenn man andere .NET-Bibliotheken verwendet, die in der Regel "normale" Fliesskommazahlen benutzen bekommt man wieder deren Verhalten. Und auch Cobra wird Pi nicht genau darstellen und die trigonometrischen Funktionen werden sicher "überraschende" Ergebnisse liefern, die ein klein wenig daneben liegen.

Beim wahrscheinlichen Geschwindigkeitsvergleich, von welcher Python-Implementierung gehst Du da aus? Und von welcher .NET Implementierung? Ist Psyco erlaubt? Wenn Cython Bestandteil der Standardbibliothek wäre, wäre dass dann auch erlaubt? Falls nicht, müsste man nicht Typdeklarationen im Cobra-Code verbieten um äquivalente Programme zu haben? Was sind die Testfälle? Etwas mit viel (un)genauer Arithmetik? Ich sage nicht, dass Cobra langsamer ist. Aber eben auch nicht, dass es schneller ist, bevor ich nicht harte Zahlen für etwas genauer beschriebene Testfälle sehe. Eine Aussage wie "Sprache X ist schneller als Sprache Y" ist in der Regel sehr ungenau bis falsch.

Neue Konzepte in .NET ist wahrscheinlich nicht so einfach, weil die Laufzeitumgebung halt hauptsächlich auf C# ausgerichtet ist und wenn man mit C# und den anderen .NET-Sprachen zusammen arbeiten möchte, schränkt das die Möglichkeiten etwas "anderes" zu machen, wohl ziemlich ein.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Sonntag 24. Februar 2008, 12:33

BlackJack, ich verstehe. Aber ich erwarte eigentlich, das eine vernünftige Sprache (wie Python es glücklicherweise eine ist) keine in der Größe beschränkten Ganzzahlen hat. Dies erkaufe ich mir gerne mit etwas mehr Speicherplatz und etwas langsamerer Arithmetik. Pythons "int"s sind eh schon mindestens 12 Bytes groß, da sie neben dem 32-Bit-Wert noch einen Zeiger auf ihre Klasse mit sich schleppen und einen Referenzzähler, der wohl auch 32-Bit groß ist.

Übrigens, unbeschränkte Genauigkeit macht bei statischer Typisierung natürlich Ärger: Gibt es je einen Typ für beschränkte und unbeschränkte Ganzzahlen? Was bedeutet es, wenn ich eine Variable auf "int" (als angenommener Typ für beschränkte Zahlen im Gegensatz zu "bigint") typisiere und durch eine Operation das Ergebnis zu groß ist, um da reinzupassen? Stillschweigend abschneiden? Exception? (Aber Laufzeitfehler hofft man durch die Typen ja zu vermeiden) Eigentlich darf ein Compiler den folgenden Ausdruck nicht erlauben:

Code: Alles auswählen

def m(a as int, b as int) as int
   return a + b
oder aber diese Sprache ist zu abschneidenden Ganzzahlen verdammt. Jedenfalls wäre es total verwirrend, wenn ohne typen da ein "bigint" zurückkommen könnte, mit Typdeklarationen aber nicht.

So wie ich Cobra verstanden hatte, hat es gar keine eigene Standardbibliothek, sondern nutzt die von .NET. Damit ist dann auch die Überlegung, eine Version für die JVM zu bauen, eigentlich zum scheitern verurteilt, außer man findet die Vorstellung gut, zwei semantisch inkompatible Sprachen mit der selben Syntax zu haben. Ich gebe dir Recht, da man durch die CLR eh floats benutzen muss, ist der Vorteil von decimals bei Cobra sehr gering.

Beim Geschwindigkeitsvergleich ging ich von CPython aus. Ohne die Internas von Psyco zu kennen, wäre ich allerdings skeptisch, dass dieser das "Grundproblem" von Python, dass man zur Laufzeit Klassendefinitionen ändern kann und damit die einfachen indirekten Sprünge mittels Methodentabelle wie sie die Einschränkungen von C# oder Java möglich machen, nicht so einfach erreichen kann. Man müsste große Teile des Programms rekompilieren, etwa wie es das Self-System gemacht hat. Ich kann mir nicht vorstellen, dass Psyco eine derartige komplett andere Ausführungsumgebung zur Verfügung stellt.

Typdeklarationen müsste man nicht verbieten, diese sind ja das Argument (oder der Preis - je wie man's sieht), warum's schneller sein soll.

Ich stimme dir gerne zu, das pauschale Aussagen "X ist besser als Y" ungenau bis falsch sind. Ich hatte aber konkret den Lookup von Methoden über "dict" angesprochen und hier ist Cobra prinzipbedingt schneller als Python - einfach aufgrund der anderen Semantik. Das ist eine IMHO valide Aussage.

Stefan
BlackJack

Sonntag 24. Februar 2008, 13:10

In der Grösse unbeschränkte Ganzzahlen sind aber etwas anderes als exakte gebrochene Zahlen.

Und die Funktion mit den ``int``\s ist okay, solange man den Datentyp ``int`` so spezifiziert, dass er zum Verhalten der 32-Bit-Zahlen passt, die der Rechner benutzt. Also dass es nicht die Menge der natürlichen Zahlen, sondern ein Restklassenkörper ist. Ist das nicht Anfängerfreundlich? :twisted:

AFAIK kennt Psyco die eingebauten Typen, die ja nicht so dynamisch veränderbar sind, und übersetzt Arithmetik mit "Zahlen" die in Register passen wohl auch in entsprechenden direkteren Maschinencode.

Ein weiterer leichter Geschwindigkeitsschub kommt dadurch, dass Bytecode durch direkte Aufrufe der C-API ersetzt werden können. Und man kann dann auch auf Typen testen und eventuell schnellere API-Aufrufe wählen, statt der generischen. Damit spart man sich den Overhead der Interpreterschleife bzw. "inlined" ihn, natürlich auf Kosten von Codegrösse.
Antworten