Ich weiß, ich bin ein Ketzer, wenn ich sowas behaupte. Aber ich schaue immer wieder mal über den Tellerrand von Python und bin jetzt über die .NET Sprache Boo gestolpert.
Die Sprache ist syntaktisch an Python angelehnt, ist aber im Unterschied dazu statisch typisiert. Ob man das als Vor- oder Nachteil sehen will muss denke ich jeder für sich selbst entscheiden. Wem die statische Typisierung nicht gefällt hat sogar die Wahl, "duck typing" zu nutzen.
Mit dem .Net Framework hat Boo eine kaum schlechtere Mitgift als Python. Einige Dinge wie Qt Bindings fehlen vielleicht, dafür gibt es sicher Dinge, die man in Python eventuell nicht findet.
Was Boo aber von Python abhebt ist die Geschwindigkeit. Hier gibt es signifikante Unterschiede zugunsten von Boo.
Boo ist irgendwie eine Mischung aus der einfachen und klaren Syntax von Python mit der Performance von .Net Programmen und der Wahlfreiheit zwischen statischer und dynamischer Typisierung.
Die einzigen Schwächen von Boo sind die etwas dünne Dokumentation und die kleine Community. Aber auch Python hat mal klein angefangen. Der eine oder andere mag die Microsoft-Abstammung von .Net noch als Nachteil empfinden, aber es gibt ja auch noch Mono
Ist Boo das bessere Python?
-
querdenker
- User
- Beiträge: 424
- Registriert: Montag 28. Juli 2003, 16:19
- Wohnort: /dev/reality
ich bleibe da lieber bei python, wenn ich dann .Net brauche nehme ich ironpython.
just my 0,02 €
just my 0,02 €
Naja, IronPython ist in Sachen Performance nicht besser als CPython. Je nachdem, welchen Benchmark man nimmt sogar schlechter.
Wäre das nicht der Fall würde ich keine Sekunde mehr mit Boo verschwenden. Der Nachteil, wenn man von Python umsteigen möchte ist klar. Man kann die Klassenbibliothek nicht mitnehmen.
Versteht mich nicht falsch. Python ist immer noch meine Lieblingssprache, aber ich habe einfach das Gefühl, dass sie meinen Anforderungen bald nicht mehr gerecht wird, was Geschwindigkeit angeht und ich habe keine Lust, irgendwelche Klimmzüge in C oder C++ zu machen, um das zu kompensieren.
Ich habe ein Programm in Python mal auf einem Atom330 laufen lassen. Das war schon recht mühsam und die Nutzung des zweiten Cores ist noch umständlicher. Hier kann Mono eindeutig punkten. Zumindest mit einer für CLR entwickelten Sprache.
Wäre das nicht der Fall würde ich keine Sekunde mehr mit Boo verschwenden. Der Nachteil, wenn man von Python umsteigen möchte ist klar. Man kann die Klassenbibliothek nicht mitnehmen.
Versteht mich nicht falsch. Python ist immer noch meine Lieblingssprache, aber ich habe einfach das Gefühl, dass sie meinen Anforderungen bald nicht mehr gerecht wird, was Geschwindigkeit angeht und ich habe keine Lust, irgendwelche Klimmzüge in C oder C++ zu machen, um das zu kompensieren.
Ich habe ein Programm in Python mal auf einem Atom330 laufen lassen. Das war schon recht mühsam und die Nutzung des zweiten Cores ist noch umständlicher. Hier kann Mono eindeutig punkten. Zumindest mit einer für CLR entwickelten Sprache.
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Das kann ich durchaus verstehen, jedoch bevor ich zu Boo greifen würde tät ich mir zuerst Cython anschauen und wenn es damit nicht geht dann eher Vala und (gerade wenn du die Syntax so magst) Genie ansehen. Vala ist so eine Art Objective-C mit gobject-Basis und C#-Syntax, Genie ist im großen und ganzen eine einrückungsbasierte Syntax dafür.burli hat geschrieben:Versteht mich nicht falsch. Python ist immer noch meine Lieblingssprache, aber ich habe einfach das Gefühl, dass sie meinen Anforderungen bald nicht mehr gerecht wird, was Geschwindigkeit angeht und ich habe keine Lust, irgendwelche Klimmzüge in C oder C++ zu machen, um das zu kompensieren.
Boo hat mich hingegen nie begeistern können. Wenn schon auf .NET, dann würde mich eher Nemerle oder Fantom oder gar F# interessieren.
Achja, genau: OCaml und Haskell haben ziemlich gute Compiler und OCaml unterstützt imperative Programmierung, vielleicht wär das nen Blick wert?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Mh, entweder habe ich gerade Pech oder Nemerle ist gestorben. Zumindest komme ich nicht auf die Projektseite. Fantom ist noch exotischer als Boo.Leonidas hat geschrieben:Boo hat mich hingegen nie begeistern können. Wenn schon auf .NET, dann würde mich eher Nemerle oder Fantom oder gar F# interessieren.
Was stört dich denn an Boo? Vielleicht gibt es ja etwas, dass ich noch nicht kenne.
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Fantom hat den Vorteil, dass es sowohl auf .NET als auch auf der JVM läuft. Eigentlich das was Scala hätte können sollen, bis sie .NET weggesägt haben.burli hat geschrieben:Fantom ist noch exotischer als Boo.
Und Nemerle ist irgendwie down, stimmt. Da ist in letzter Zeit auch nicht mehr viel passiert. Na immerhin haben sie mit C# ne starke Konkurrenz.
Oooh, nichts bestimmtes. Aber es hat jetzt auch keine Features wo ich gesagt hätte: "wow, wenn Python zu langsam ist dann nehm ich das".burli hat geschrieben:Was stört dich denn an Boo? Vielleicht gibt es ja etwas, dass ich noch nicht kenne.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Es ist halt langweilig nichts neues zu lernen, irgendwie. Boo ist schön und gut, nicht schlecht und so... aber... es ist halt ... Python. Für mich zumindest.Leonidas hat geschrieben:Aber es hat jetzt auch keine Features wo ich gesagt hätte: "wow, wenn Python zu langsam ist dann nehm ich das".
-
lunar
@burli: Wenn man aus äußeren Zwängen heraus eine neue Sprache lernen muss, ist es naheliegend, sich eine möglichst bekannte zu wählen.
Wenn ein solcher Zwang allerdings fehlt, wäre mir die Zeit zu schade, denn schließlich ist Boo eine Sprache, die einem Python-Entwickler wenig Neues bietet. Dann lieber eine Sprache wählen, mit der man wirklich Neues lernen kann … und .NET ist ja nun nicht arm an Sprachen.
Wenn ein solcher Zwang allerdings fehlt, wäre mir die Zeit zu schade, denn schließlich ist Boo eine Sprache, die einem Python-Entwickler wenig Neues bietet. Dann lieber eine Sprache wählen, mit der man wirklich Neues lernen kann … und .NET ist ja nun nicht arm an Sprachen.
Das ist ja gerade das Argument FÜR Boo. Man muss sich sprachlich nicht übermäßig anstrengen.
Ich merke inzwischen aber, dass die beiden genannten Schwächen, nämlich dünne Dokumentation und kleine Community, ein ziemlicher Hemmschuh sind. Es nutzt wenig, wenn man sich die Vorteile bei einer Sprache durch haufenweise Nachteile erkauft. So wird z.B. das Boo Addin in Monodevelop schon seit Jahren nicht mehr gepflegt.
Da beißt man sich lieber durch den syntaktischen Unsinn von C#
Ich merke inzwischen aber, dass die beiden genannten Schwächen, nämlich dünne Dokumentation und kleine Community, ein ziemlicher Hemmschuh sind. Es nutzt wenig, wenn man sich die Vorteile bei einer Sprache durch haufenweise Nachteile erkauft. So wird z.B. das Boo Addin in Monodevelop schon seit Jahren nicht mehr gepflegt.
Da beißt man sich lieber durch den syntaktischen Unsinn von C#
@burli: Hast Du Dir D schon angeschaut. Ich habe schon einige Python-Scripts ohne große Mühe in D umgewandelt. Die Performance ist dann natürlich wesentlich besser als Python, kann allerdings nicht mit C/C++ mithalten.
MfG
HWK
MfG
HWK
Bei int scheint bei 32 Bit Schluß zu sein.
Hatte kurz das Fibo Beispiel getestet. Als es über den 32 Bit Bereich hinaus ging hats gleich ne Overflow Exception gegeben.
In der Doku war auch nichts zu finden über den Wertebereich von int.
C# und selbst C unterstützen ja immerhin schon 64 Bit.
Bißchen dünn. Wäre für mich eigentlich schon ein Showstopper.
Hatte kurz das Fibo Beispiel getestet. Als es über den 32 Bit Bereich hinaus ging hats gleich ne Overflow Exception gegeben.
In der Doku war auch nichts zu finden über den Wertebereich von int.
C# und selbst C unterstützen ja immerhin schon 64 Bit.
Bißchen dünn. Wäre für mich eigentlich schon ein Showstopper.
-
philistion
- User
- Beiträge: 108
- Registriert: Sonntag 7. Februar 2010, 14:16
Ich habe irgendwie eine große Ablehnung gegenüber dem ganzen .Net - Zeug! Warum etwas proprietäres von Microsoft benutzen, wenn es auch GPL-lizensierte Frameworks gibt, nein Python ist da schon der beste Kompromiss. Plattformunabhängig, freie Software und extrem flexibel!
Da wir gerade beim "Über-den-Tellerrand-schauen" sind, was haltet Ihr vom Monkey-Patching wie es bei Ruby betrieben wird, findet ihr man sollte auch in Python toleranter demgegenüber sein?
Da wir gerade beim "Über-den-Tellerrand-schauen" sind, was haltet Ihr vom Monkey-Patching wie es bei Ruby betrieben wird, findet ihr man sollte auch in Python toleranter demgegenüber sein?
Mir gefällt Boo nicht. Das ist mehr ein Bauchgefühl als wirklich zu begründen. Das Argument ist ähnlich wie bei Groovy. Im Prinzip ist Boo ein zweiter syntaktischer Skin für C# und einfach nur die Syntax tauschen ist lame. Dadurch, dass Boo effizient auf der CLR mitspielen will, hat es leider kaum eine andere Wahl.
Ein Ausdruck "o as object" sieht für mich nicht wie eine Variablendeklaration aus (warum auch immer man die braucht). Wenn schon, dann hätte ich gesagt, es muss eine initialisierung erfolgen, etwa "o as object = foo" doch auch dann wirkt das komisch. Python folgt IMHO eher der Tradition von Pascal, eine LL(1) parsebare Sprache zu sein, deren syntaktische Konstrukte durch Schlüsselwörter eingeleitet werden. Daher müsste das IMHO "var o: object = foo" sein. Das ":" statt "as" habe ich gewählt, weil auch in Funktionen bei Python 3 "def (o:object)" gilt. Das Boo sich da "falsch" entschieden hat, ist deren Problem, nicht meins. Außerdem würde ich "as" nur für Casts benutzen.
Ein "unless" (was IMHO nicht besser ist als "if not") und ein nachgestelltes "if" oder "unless" wie bei Perl oder Ruby braucht ein Python-Dialekt, in dem es möglichst nur einen Weg geben sollte, auch nicht. Womöglich gibt es auch noch ein nachgestelltes "while"?
Ein "--" und "++" sollte es (schrieb ich gerade in einem anderen Thread) nicht geben, wenn, dann bitte zwei eingebaute Funktionen "inc" und "dec", die gerade bei funktionalen Operationen praktisch sind. Was noch witzig ist, sie schreiben in ihrem Tutorial, man sollte "--" und "++" nicht benutzen. Herje, warum gibt es dann diese Operatoren?
Es wäre so überhaupt kein Problem, statt "def __add__()" ein "def +()" zu erlauben. Wenn schon was, ändern, dann diese ganzen "__" reduzieren. IMHO. Andererseits, was will man bei "__call__" machen? "def ()()"? Eher nicht.
Um auch mal was zu sagen, das mir gefällt: Ich finde Strings, in die man Code einbetten kann, damit man "'Hallo ${name}'" statt "'Hallo %s' % name" schreiben kann, sehr praktisch, auch wenn es einen das "$" kostet. Oder man muss solche Strings kennzeichnen, etwa "$'Hallo ${name}'". Hm.
Die Syntax für CLR-Properties (im Gegensatz zu Python-artigen Attributen und Properties) finde ich grenzwertig hässlich und hier gibt es eben das Problem, dass Boo für alles, was C# kann, auch Syntax haben muss, damit eine Interoperatibilität möglich ist. Aber man könnte eher mit Python-decorators arbeiten, etwa "@abstract class X" statt "abstract class X".
Die Syntax für "interface" neben "class" sei geschenkt, aber wenn eine Sprache hier man mehr können will, fände ich es viel spannender entweder traits statt interfaces zu unterstützen oder das Objektmodell von Objective-C oder das von Go. Das ist alles jeweils mächtiger. Natürlich zum Preis der fehlende Interoperatibilität.
Ich finde auch, dass Boo unnötig von Python abweicht, indem es "true", "false", "null" statt "True", "False" und "None" benutzt oder das "self" in Methoden implizit macht oder C#-style Attribute mit [] statt Decorators mit @ benutzt.
Schließlich finde ich dass die CLR mit ihren Methoden, die mit Großbuchstaben beginnen, irgendwie nicht richtig zu Python passen. Die CLR ist nun mal für C# entwickelt und das sieht man und jetzt eine neue Sprache zu benutzen, erfordert eigentlich auch, dafür eine eigene Funktionsbibliothek zu haben.
Ach ja, ich finde Fantom übrigens irgendwie interessanter als Boo, vielleicht weil die Webseiten besser aussehen und es schon mal im JavaPosse-Podcast vorkam, als es noch Fan hieß. Da aber Fantom eine {}-Syntax benutzt (um sich bei Java und C#-Entwicklern anzubiedern) ist es doch syntaktisch gar nicht vergleichbar.
Stefan
Ein Ausdruck "o as object" sieht für mich nicht wie eine Variablendeklaration aus (warum auch immer man die braucht). Wenn schon, dann hätte ich gesagt, es muss eine initialisierung erfolgen, etwa "o as object = foo" doch auch dann wirkt das komisch. Python folgt IMHO eher der Tradition von Pascal, eine LL(1) parsebare Sprache zu sein, deren syntaktische Konstrukte durch Schlüsselwörter eingeleitet werden. Daher müsste das IMHO "var o: object = foo" sein. Das ":" statt "as" habe ich gewählt, weil auch in Funktionen bei Python 3 "def (o:object)" gilt. Das Boo sich da "falsch" entschieden hat, ist deren Problem, nicht meins. Außerdem würde ich "as" nur für Casts benutzen.
Ein "unless" (was IMHO nicht besser ist als "if not") und ein nachgestelltes "if" oder "unless" wie bei Perl oder Ruby braucht ein Python-Dialekt, in dem es möglichst nur einen Weg geben sollte, auch nicht. Womöglich gibt es auch noch ein nachgestelltes "while"?
Ein "--" und "++" sollte es (schrieb ich gerade in einem anderen Thread) nicht geben, wenn, dann bitte zwei eingebaute Funktionen "inc" und "dec", die gerade bei funktionalen Operationen praktisch sind. Was noch witzig ist, sie schreiben in ihrem Tutorial, man sollte "--" und "++" nicht benutzen. Herje, warum gibt es dann diese Operatoren?
Es wäre so überhaupt kein Problem, statt "def __add__()" ein "def +()" zu erlauben. Wenn schon was, ändern, dann diese ganzen "__" reduzieren. IMHO. Andererseits, was will man bei "__call__" machen? "def ()()"? Eher nicht.
Um auch mal was zu sagen, das mir gefällt: Ich finde Strings, in die man Code einbetten kann, damit man "'Hallo ${name}'" statt "'Hallo %s' % name" schreiben kann, sehr praktisch, auch wenn es einen das "$" kostet. Oder man muss solche Strings kennzeichnen, etwa "$'Hallo ${name}'". Hm.
Die Syntax für CLR-Properties (im Gegensatz zu Python-artigen Attributen und Properties) finde ich grenzwertig hässlich und hier gibt es eben das Problem, dass Boo für alles, was C# kann, auch Syntax haben muss, damit eine Interoperatibilität möglich ist. Aber man könnte eher mit Python-decorators arbeiten, etwa "@abstract class X" statt "abstract class X".
Die Syntax für "interface" neben "class" sei geschenkt, aber wenn eine Sprache hier man mehr können will, fände ich es viel spannender entweder traits statt interfaces zu unterstützen oder das Objektmodell von Objective-C oder das von Go. Das ist alles jeweils mächtiger. Natürlich zum Preis der fehlende Interoperatibilität.
Ich finde auch, dass Boo unnötig von Python abweicht, indem es "true", "false", "null" statt "True", "False" und "None" benutzt oder das "self" in Methoden implizit macht oder C#-style Attribute mit [] statt Decorators mit @ benutzt.
Schließlich finde ich dass die CLR mit ihren Methoden, die mit Großbuchstaben beginnen, irgendwie nicht richtig zu Python passen. Die CLR ist nun mal für C# entwickelt und das sieht man und jetzt eine neue Sprache zu benutzen, erfordert eigentlich auch, dafür eine eigene Funktionsbibliothek zu haben.
Ach ja, ich finde Fantom übrigens irgendwie interessanter als Boo, vielleicht weil die Webseiten besser aussehen und es schon mal im JavaPosse-Podcast vorkam, als es noch Fan hieß. Da aber Fantom eine {}-Syntax benutzt (um sich bei Java und C#-Entwicklern anzubiedern) ist es doch syntaktisch gar nicht vergleichbar.
Stefan
Mono ist vollständig Offen. Von daher hab ich also keine Bedenken. Und selbst MS veröffentlicht inzwischen viel als OpenSource, wie z.B. ASP.NET MVCphilistion hat geschrieben:Ich habe irgendwie eine große Ablehnung gegenüber dem ganzen .Net - Zeug! Warum etwas proprietäres von Microsoft benutzen, wenn es auch GPL-lizensierte Frameworks gibt, nein Python ist da schon der beste Kompromiss. Plattformunabhängig, freie Software und extrem flexibel!
@sma: der Witz bei Boo ist ja eigentlich, dass man "o as object" nicht unbedingt schreiben muss sondern der Compiler sich das selber raussucht.
i=0 //wird zu einem Integer
f=1.0 //wird zu einem Float
s="Hallo Du" //wird zu einem String
usw. Nur mit dem Unterschied, dass die Typen dann statisch sind. Eine Stärke der Sprache ist denke ich, dass man Variablen unabhängig voneinander statisch oder dynamisch typisieren kann.
Im Gegensatz z.B. zu C# kann man sich auch sowas sparen
MeineKlasse foo = new MeineKlasse()
sondern es reicht
foo = MeineKlasse()
Der Compiler weiß von alleine, dass foo vom Typ MeineKlasse sein muss. Auch der Rückgabewert einer Methode muss bei der Methodendefinition nicht angegeben werden. Das was hinter "return" steht ist gleichzeitig der Rückgabewert. Klar, das birgt auch Gefahren, wenn man z.B. mal return vergisst.
Das bessere Python ist es ganz sicher nicht. Vielleicht ganz nett anzuschauen, aber wenn ich sowas will, würde ich wohl auch eher zu D tendieren. Insgesamt hat sich für mich persönlich aber immer wieder gezeigt, dass ich mit Python am Besten klar komme. Mag sein, dass manche tollen Features aus anderen Sprachen fehlen, aber als bestes Gesamtpaket bleibt für mich Python bestehen.
-
philistion
- User
- Beiträge: 108
- Registriert: Sonntag 7. Februar 2010, 14:16
Keine Bedenken? Viele Teile des Monoprojekts sind wahrscheinlich von Patentrechtsansprüchen Microsofts betroffen, Novell hat lediglich mit Microsoft einen Pakt geschlossen, dass Novell-Kunden vor Patentrechtsklagen Microsofts geschützt sind.burli hat geschrieben:Mono ist vollständig Offen. Von daher hab ich also keine Bedenken.
Auch wenn Microsoft es nun hoch und heilig versprochen hat, warum sollte man sich auf so ein unsympathisches Projekt verlassen, wenn es doch genügend andere Möglichkeiten gibt, plattformunabhängige Software zu entwickeln.
Ich finde die Gedanken von Richard Stallman immer noch sehr zutreffend: http://www.fsf.org/news/dont-depend-on-mono
Ja sehr paradox, erst solche Aussagen:burli hat geschrieben:Und selbst MS veröffentlicht inzwischen viel als OpenSource, wie z.B. ASP.NET MVC
http://www.theregister.co.uk/2001/06/02 ... _a_cancer/
dann ist Open Source wieder "interessant": http://www.silicon.de/mittelstand/0,390 ... eteran.htm
Wenn bei einer Firma so ein Verrückter der CEO ist, vertraue ich auch nicht auf Zusagen bezüglich des Nicht-Einklagens von Patentrechtsansprüchen.. so oft wie der die Meinung bezüglich Open Source wechselt, kann er genauso gut die Meinung zum Einklagen wechseln.