Würde heute eher auf Python setzen. - Python ist verbreiteter - Python ist etwas schneller - Python wird ebenfalls ständig weiterentwickelt - Für Python sind Bindings für fast alle Toolkits vorhanden - Die Sprache ist eleganter - Bin mir nicht sicher: aber Python ist im Gegensatz zu Ruby in OpenSuse ein obligatorisches Paket
Aber wenigstens ist Ruby nicht so sinnfrei wie YPC.
Scheinen die Stärken von Ruby doch eher in der Webentwicklung zu liegen (Ruby on Rails). Und da gibt es anscheinend grosse Unterschiede zwischen Community und Enterprise Edition. Wir mussten wegen schlechter Skalierbarkeit auf die Enterprise Version umsteigen und sind da anscheinend nicht die einzigen. Aber abgesehen davon weiss ich nichts von Ruby. Vielleicht habe ich auch ein falsches Bild?
Da gebe ich dir recht. Ich hätte auch zu Python gegriffen. Aber ist ja eigentlich auch kein Problem Ruby zu einem obligatorischen Paket zu machen. Wer OpenSuse und Yast einsetzt dem dürfte die schlanke Linie einer Distribution nicht ganz so wichtig sein.
Ruby scheint wirklich nicht so verbreitet zu sein. Das einzige Paket auf meinem System das Ruby als Abhängigkeit herein zieht ist texlive-context. Da ich ConTeXt vermutlich nicht brauche, wäre es interessant es komplett loszuwerden.
Das OpenSuse nicht die schlankste Distri ist, ist auch OK. Aber man muss es ja nicht auf Biegen und Brechen künstl. aufblähen. Vorallem, weil dann neben Java, Python noch ein dritter Parser im RAM läuft.
Aber ob der Dritte jetzt YCP oder Ruby heißt ist doch letztlich egal. Wenn es vorher nicht gestört hat, dann wird es nun auch nicht stören. Diejenigen die Ruby eh verwenden gewinnen sogar noch an Platz.
So lange man mit der API und nicht an der API arbeiten möchten ist es eigentlich egal wie sie erzeugt wurde. Vorausgesetz die API ist ausreichend Dokumentiert, dann kommt man ja selten in Verlegenheit in ihren Quellcode zu schauen.
Von .-,.-,.-,.-,-,. am Mi, 5. Juni 2013 um 13:59 #
Das heißt wohl, dass Yast zu Beginn der Veröffentlichung von openSUSE 13.1 vor Bugs nur so strotzen wird. Die Einführung in Milestone 4 ist IMO zu spät.
Wenn Yast nicht problemlos funktionieren sollte, so kann man die ganze openSUSE 13.1-Veröffentlichung getrost vergessen.
Genau genommen sind Sprachen erst einmal überhaupt nicht "schnell", da sie lediglich Konzepte sind. Du meinst sicherlich die Referenzimplementierung "CPython"; da beides oftmals synonym verwendet wird, muss man da ein wenig aufpassen. Speziell beim Thema Benchmarking, sollte man da Präzision walten lassen.
Generell stimme ich Dir aber zu, dass ich Ruby auch eher als Mittelsmann des "... on Rails"-Hype sehe. Langsam aber sicher wird es da auch stiller und abseits davon empfinde ich Ruby als wenig sichtbar.
Bei Python gibt es leider seit dem schwierigen und teilweise unglücklichen 3.x Wechsel auch wenig innovatives. Aber vielleicht ändert sich das ja wieder in nächster Zeit, jetzt wo die meisten Kinderkrankheiten seit dem 3.3er Release beseitigt sind.
Fehlt dir denn noch etwas? Viele scheinen ja noch mit dem 2.X Sprachstand zufrieden zu sein, anders kann man sich das langsame adaptieren von 3.X ja eigentlich nicht erklären.
Neben besserer Unicodeunterstützung gibt es eben kaum Vorteile. Statt Typinferenz gibt es weiterhin nur dynamische Typisierung, welche nur Nachteile bietet und parallele Abarbeitung ist nach wie vor problematisch. Die Referenzimplementierung (und ja, nur diese wird benutzt) ist in diversen Kriterien nach wie vor designtechnisch gewollt mangelhaft.
Die Nutzerschaft ist doch zwiegespalten: -Leute, die Bashersatz und Webskripte schreiben -Leute, die ernste Anwendungen entwickeln
Die erste Gruppe interessiert sich nicht für die Vorteile, der zweiten dürfte der Schritt einfach nicht weit genug gehen. Früher oder später landet Gruppe 2 dann bei C++, Scala, Java, OCAML, C# oder einer anderen technisch besseren Lösung. Die Sprache an sich ist ihnen erstmal weniger wichtig.
Ruby steht vor dem selben Problem. Von den großen Versprechungen, dass Ruby 2.0 in eingebetteten Systemen laufen kann, ist nichts übrig geblieben.
Ich finde, Leute, die ihren Interpreter veröffentlichen, sollten erstmal ihre Professur in Typentheorie, Nebenläufigkeit und Speicherverwaltung abschließen.
Statt Typinferenz gibt es weiterhin nur dynamische Typisierung, welche nur Nachteile bietet
Vorsicht mit Pauschalisierugen. "Nur" Nach- bzw. Vorteile gibt es de facto nicht.Hier wird das schön zusammengefasst.
Ich finde, Leute, die ihren Interpreter veröffentlichen, sollten erstmal ihre Professur in Typentheorie, Nebenläufigkeit und Speicherverwaltung abschließen.
Anders Hejlsberg hat das sicherlich nicht - C# und die CLR sind aber durchaus gut designt
Aber sicherlich kann man bei Python noch vieles verbessern - sowohl im Backend als auch in der Sprache selber. Ich hoffe da kommt - auch durch PyPy - in Zukunft wieder mehr frischer Wind rein
Nicht dein ernst, oder? C# ist ein Haufen nicht-orthogonaler Konzepte, es gibt sogar Keywords für Office Interoperability. Die Klassenbibliothek von .Net ist einfach grausig. Microsoft hätte sich Java anschauen können und es besser machen können, stattdessen ist die .Net Klassenbibliothek in vielen Bereichen deutlich schlechter. Schau dir mal Scala an, das ist meiner Meinung nach eine moderne, gut designte Sprache.
Welche denn? Und warum benutzt du nicht Scala? Ich habe in der Arbeit eine >50.000 Zeilen Java-Code umfassende Applikation nach Scala portiert (was wirklich gut geht da man im Gegensatz zu VB und C# nicht auf Projektebene, sondern auf Klassenebene Java und Scala mischen kann) und bin begeistert. Ich hab vorher eine ähnlich große Applikation in C# geschrieben und bin echt froh, nichts mehr damit zu tun zu haben. C# hat meiner Meinung nach gegenüber Scala keinen einzigen Vorteil, Scala hat jede Menge Vorteile gegenüber C#·
Öh... also speziell die JRE strotzt nur so von schlimmen Dingen... "java.io" z.B., die Collection-Interfaces von Java sind viel zu überladen und ohne "Apache Commons" kann man viele simple Dinge nicht vernünftig umsetzen. Also wäre ich da mal sehr vorsichtig.
Genercis sind in C# deutlich besser umgesetzt als in Java.
Microsoft hat sogar sehr gut bei Java gespickt und vieles besser gemacht. Natürlich gibt es nirgends eine totale Dominanz; das ist aber wie immer im Leben so Aber Leute, die die Welt derart schwarz weiß sehen, kann ich nicht wirklich ernst nehmen!
C# ist jedoch nicht wie Java stehen geblieben, sondern hat sich von einem Java-Clone schnell zu einer eigenständigen Sprache mit tollen Features (LINQ z.B.) weiterentwickelt.
Scala sollte ich mir wirklich einmal ansehen; allerdings habe ich im Moment dazu zu wenig Zeit
Es geht. Man benötigt keine Schlüsselwörter wie let, var oder auto. Das sind nur Provisorien vorhandener Sprachen. Und Typannotationen sind nicht nur in Methoden sinnvoll.
Und Tests: Die braucht man bei größeren Systemen IMMER. Nur: Desto automatisierter, desto besser, also macht das am besten der Compiler. Natürlich sollte es auch Live-Debugging möglich sein. Die Werkzeuge machen ja 90% aus.
>Anders Hejlsberg hat das sicherlich nicht - C# und die CLR sind aber durchaus gut designt
Naja: Es ist viel überflüssiger Müll drin; z.B. Arrays. Es wird ja eh gemanaged, deshalb sollte es keinen Unterschied machen, ob man Arrays oder gleich richtige Listen verwendet.
Naja: Es ist viel überflüssiger Müll drin; z.B. Arrays. Es wird ja eh gemanaged, deshalb sollte es keinen Unterschied machen, ob man Arrays oder gleich richtige Listen verwendet.
OMG... nur weil Du kein Arrays brauchst, heißt das doch nicht, dass die niemand brauchen kann
Wieso können so viele einfach nicht über den Tellerrand gucken?
Ich vermeide Arrays auch wo ich es kann - aber es gibt def. Einsatzzwecke dafür, bei denen dynamische Strukturen nicht sinnvoll sind (Grafikprogrammierung z.B.).
Wie kann man sich denn an so etwas stören? Es ist einfach eine Klasse von Typen, die Du einfach ignorieren kannst. Die Sprache an sich wird dadurch nicht ein Deut komplexer oder komplizierter!
Im übrigen wollte ich nur darauf hinweisen, dass man keine Professur in etwas braucht, um eine Sache gut zu machen! Die meisten erfolgreichen Sprachen, und davon sind viele gut, stammen nicht aus der Feder von Professoren.
github zählt allerdings auch die sehr vielen Webprojekte mit, die hier jedoch kein Maßstab sind, geht es hier doch um eine lokale Anwendung. Bei den lokalen Anwendungen ist Python deutlich stärker vertretten, eigentlich hat Ruby hierbei fast gar keine Bedeutung.
Nicht zu vergessen, dass sich auf GitHub die ganzen Hipster und Brogrammer rumtummeln, die dort ihre unwichtigen Wegwerfcodes und Webframeworks veröffentlichen. Ein hingegen wirklich wichtiges Kriterium ist z.B. die Verbreitung als Automatisierungsmöglichkeit. Python ist hier in fast allen Anwendungen eingebettet. -Blender -GIMP (hier leider schlecht dokumentiert) -die ganzen Office-Suits -Scribus -Inkscape -usw. Quasi das Lua-Equivalent der nicht-Spiele-Welt. Ruby hingegen...
Würde heute eher auf Python setzen. - Python ist verbreiteter - Python ist etwas schneller - Python wird ebenfalls ständig weiterentwickelt - Für Python sind Bindings für fast alle Toolkits vorhanden - Die Sprache ist eleganter - Bin mir nicht sicher: aber Python ist im Gegensatz zu Ruby in OpenSuse ein obligatorisches Paket
Aber wenigstens ist Ruby nicht so sinnfrei wie YPC.
Och nöö. Offenbar übernehmen jetzt auch noch die Website bastelnden Ruby-Hipster die Kontrolle über die arme Suse. Was kommt als nächstes? Skinny-Jeans, Beanies und Ray-Ban Brillen für Chamäleons. Vielleicht wird das arme Tier auch noch mit dem Dreck aus dem Starbucks duchgefüttert! Das ist doch Tierquälerei! Tut was dagegen!
Würde heute eher auf Python setzen.
- Python ist verbreiteter
- Python ist etwas schneller
- Python wird ebenfalls ständig weiterentwickelt
- Für Python sind Bindings für fast alle Toolkits vorhanden
- Die Sprache ist eleganter
- Bin mir nicht sicher: aber Python ist im Gegensatz zu Ruby in OpenSuse ein obligatorisches Paket
Aber wenigstens ist Ruby nicht so sinnfrei wie YPC.
Bin deiner Meinung. Ich verstehe das auch nicht.
Scheinen die Stärken von Ruby doch eher in der Webentwicklung zu liegen (Ruby on Rails). Und da gibt es anscheinend grosse Unterschiede zwischen Community und Enterprise Edition. Wir mussten wegen schlechter Skalierbarkeit auf die Enterprise Version umsteigen und sind da anscheinend nicht die einzigen. Aber abgesehen davon weiss ich nichts von Ruby. Vielleicht habe ich auch ein falsches Bild?
Da gebe ich dir recht. Ich hätte auch zu Python gegriffen. Aber ist ja eigentlich auch kein Problem Ruby zu einem obligatorischen Paket zu machen. Wer OpenSuse und Yast einsetzt dem dürfte die schlanke Linie einer Distribution nicht ganz so wichtig sein.
Ruby scheint wirklich nicht so verbreitet zu sein. Das einzige Paket auf meinem System das Ruby als Abhängigkeit herein zieht ist texlive-context. Da ich ConTeXt vermutlich nicht brauche, wäre es interessant es komplett loszuwerden.
Das OpenSuse nicht die schlankste Distri ist, ist auch OK. Aber man muss es ja nicht auf Biegen und Brechen künstl. aufblähen. Vorallem, weil dann neben Java, Python noch ein dritter Parser im RAM läuft.
Aber ob der Dritte jetzt YCP oder Ruby heißt ist doch letztlich egal. Wenn es vorher nicht gestört hat, dann wird es nun auch nicht stören. Diejenigen die Ruby eh verwenden gewinnen sogar noch an Platz.
Ich frage mich grade, wie der Quellcode aussehen wird, wenn man den automatisch generiert? Wird das wirklich Entwickler anlocken?
So lange man mit der API und nicht an der API arbeiten möchten ist es eigentlich egal wie sie erzeugt wurde. Vorausgesetz die API ist ausreichend Dokumentiert, dann kommt man ja selten in Verlegenheit in ihren Quellcode zu schauen.
Das heißt wohl, dass Yast zu Beginn der Veröffentlichung von openSUSE 13.1 vor Bugs nur so strotzen wird. Die Einführung in Milestone 4 ist IMO zu spät.
Wenn Yast nicht problemlos funktionieren sollte, so kann man die ganze openSUSE 13.1-Veröffentlichung getrost vergessen.
Ehehe, hatte exakt den selben Gedanken und wollte das kommentieren bis ich deinen Eintrag sah. Ruby (on Rails) ist aber auch kein Unbekannter.
> Würde heute eher auf Python setzen.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 05. Jun 2013 um 11:11.++
Generell stimme ich Dir aber zu, dass ich Ruby auch eher als Mittelsmann des "... on Rails"-Hype sehe. Langsam aber sicher wird es da auch stiller und abseits davon empfinde ich Ruby als wenig sichtbar.
Bei Python gibt es leider seit dem schwierigen und teilweise unglücklichen 3.x Wechsel auch wenig innovatives. Aber vielleicht ändert sich das ja wieder in nächster Zeit, jetzt wo die meisten Kinderkrankheiten seit dem 3.3er Release beseitigt sind.
Neben besserer Unicodeunterstützung gibt es eben kaum Vorteile.
Statt Typinferenz gibt es weiterhin nur dynamische Typisierung, welche nur Nachteile bietet und parallele Abarbeitung ist nach wie vor problematisch.
Die Referenzimplementierung (und ja, nur diese wird benutzt) ist in diversen Kriterien nach wie vor designtechnisch gewollt mangelhaft.
Die Nutzerschaft ist doch zwiegespalten:
-Leute, die Bashersatz und Webskripte schreiben
-Leute, die ernste Anwendungen entwickeln
Die erste Gruppe interessiert sich nicht für die Vorteile, der zweiten dürfte der Schritt einfach nicht weit genug gehen.
Früher oder später landet Gruppe 2 dann bei C++, Scala, Java, OCAML, C# oder einer anderen technisch besseren Lösung. Die Sprache an sich ist ihnen erstmal weniger wichtig.
Ruby steht vor dem selben Problem. Von den großen Versprechungen, dass Ruby 2.0 in eingebetteten Systemen laufen kann, ist nichts übrig geblieben.
Ich finde, Leute, die ihren Interpreter veröffentlichen, sollten erstmal ihre Professur in Typentheorie, Nebenläufigkeit und Speicherverwaltung abschließen.
Aber sicherlich kann man bei Python noch vieles verbessern - sowohl im Backend als auch in der Sprache selber. Ich hoffe da kommt - auch durch PyPy - in Zukunft wieder mehr frischer Wind rein
C# und die CLR sind aber durchaus gut designt
Nicht dein ernst, oder? C# ist ein Haufen nicht-orthogonaler Konzepte, es gibt sogar Keywords für Office Interoperability. Die Klassenbibliothek von .Net ist einfach grausig. Microsoft hätte sich Java anschauen können und es besser machen können, stattdessen ist die .Net Klassenbibliothek in vielen Bereichen deutlich schlechter. Schau dir mal Scala an, das ist meiner Meinung nach eine moderne, gut designte Sprache.
Als bekennender Java Programmier wünschte ich mir die Eleganz einiger C# Features in Java.
Und was sagt das über Java aus.
Welche denn? Und warum benutzt du nicht Scala? Ich habe in der Arbeit eine >50.000 Zeilen Java-Code umfassende Applikation nach Scala portiert (was wirklich gut geht da man im Gegensatz zu VB und C# nicht auf Projektebene, sondern auf Klassenebene Java und Scala mischen kann) und bin begeistert. Ich hab vorher eine ähnlich große Applikation in C# geschrieben und bin echt froh, nichts mehr damit zu tun zu haben. C# hat meiner Meinung nach gegenüber Scala keinen einzigen Vorteil, Scala hat jede Menge Vorteile gegenüber C#·
Spekulation: Chef erlaubts net.
Öh... also speziell die JRE strotzt nur so von schlimmen Dingen... "java.io" z.B., die Collection-Interfaces von Java sind viel zu überladen und ohne "Apache Commons" kann man viele simple Dinge nicht vernünftig umsetzen. Also wäre ich da mal sehr vorsichtig.
Genercis sind in C# deutlich besser umgesetzt als in Java.
Microsoft hat sogar sehr gut bei Java gespickt und vieles besser gemacht. Natürlich gibt es nirgends eine totale Dominanz; das ist aber wie immer im Leben so
Aber Leute, die die Welt derart schwarz weiß sehen, kann ich nicht wirklich ernst nehmen!
C# ist jedoch nicht wie Java stehen geblieben, sondern hat sich von einem Java-Clone schnell zu einer eigenständigen Sprache mit tollen Features (LINQ z.B.) weiterentwickelt.
Scala sollte ich mir wirklich einmal ansehen; allerdings habe ich im Moment dazu zu wenig Zeit
>Hier wird das schön zusammengefasst.
Es geht. Man benötigt keine Schlüsselwörter wie let, var oder auto. Das sind nur Provisorien vorhandener Sprachen.
Und Typannotationen sind nicht nur in Methoden sinnvoll.
Und Tests: Die braucht man bei größeren Systemen IMMER. Nur: Desto automatisierter, desto besser, also macht das am besten der Compiler.
Natürlich sollte es auch Live-Debugging möglich sein. Die Werkzeuge machen ja 90% aus.
>Anders Hejlsberg hat das sicherlich nicht - C# und die CLR sind aber durchaus gut designt
Naja: Es ist viel überflüssiger Müll drin; z.B. Arrays. Es wird ja eh gemanaged, deshalb sollte es keinen Unterschied machen, ob man Arrays oder gleich richtige Listen verwendet.
Wieso können so viele einfach nicht über den Tellerrand gucken?
Ich vermeide Arrays auch wo ich es kann - aber es gibt def. Einsatzzwecke dafür, bei denen dynamische Strukturen nicht sinnvoll sind (Grafikprogrammierung z.B.).
Wie kann man sich denn an so etwas stören? Es ist einfach eine Klasse von Typen, die Du einfach ignorieren kannst. Die Sprache an sich wird dadurch nicht ein Deut komplexer oder komplizierter!
Im übrigen wollte ich nur darauf hinweisen, dass man keine Professur in etwas braucht, um eine Sache gut zu machen! Die meisten erfolgreichen Sprachen, und davon sind viele gut, stammen nicht aus der Feder von Professoren.
ist doch immer wieder schön zu lesen das es noch Leute gibt die Differenzieren können.Gratulation.
(x^n)' = n*x^(n − 1)
Sicher? Definitiv nicht in der Open-Source-Welt..
github zählt allerdings auch die sehr vielen Webprojekte mit, die hier jedoch kein Maßstab sind, geht es hier doch um eine lokale Anwendung.
Bei den lokalen Anwendungen ist Python deutlich stärker vertretten, eigentlich hat Ruby hierbei fast gar keine Bedeutung.
Nicht zu vergessen, dass sich auf GitHub die ganzen Hipster und Brogrammer rumtummeln, die dort ihre unwichtigen Wegwerfcodes und Webframeworks veröffentlichen.
Ein hingegen wirklich wichtiges Kriterium ist z.B. die Verbreitung als Automatisierungsmöglichkeit. Python ist hier in fast allen Anwendungen eingebettet.
-Blender
-GIMP (hier leider schlecht dokumentiert)
-die ganzen Office-Suits
-Scribus
-Inkscape
-usw.
Quasi das Lua-Equivalent der nicht-Spiele-Welt.
Ruby hingegen...
-die ganzen Office-Suits
Business-Anzüge mit eingebettetem Python?
Richtig. Dadurch sind die wichtig.
Gut erkannt Watson. Ich spendiere ein e .
Auch wenn die Wahrscheinlichkeit klein ist, dass das jemand noch liest. Ich würde mich auf diesen Index hier mehr verlassen als auf Github:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Es ist doch beides Schwachsinn.
Tiobe sind nur Suchanfragen und ändern sich jedes Jahr.
Ich stimme Dir zu.
Aber Hauptsache, man lässt dieses YCP hinter sich. Das ist mit Abstand das Allerwichtigste.
Würde heute eher auf Python setzen.
- Python ist verbreiteter
- Python ist etwas schneller
- Python wird ebenfalls ständig weiterentwickelt
- Für Python sind Bindings für fast alle Toolkits vorhanden
- Die Sprache ist eleganter
- Bin mir nicht sicher: aber Python ist im Gegensatz zu Ruby in OpenSuse ein obligatorisches Paket
Aber wenigstens ist Ruby nicht so sinnfrei wie YPC.
... oder auch für die textbasierte Version?
Och nöö. Offenbar übernehmen jetzt auch noch die Website bastelnden Ruby-Hipster die Kontrolle über die arme Suse.
Was kommt als nächstes? Skinny-Jeans, Beanies und Ray-Ban Brillen für Chamäleons. Vielleicht wird das arme Tier auch noch mit dem Dreck aus dem Starbucks duchgefüttert! Das ist doch Tierquälerei! Tut was dagegen!
Ich kann Dir sagen, was als Nächstes kommt, nämlich ein im voraus angekündigter openSUSE-13.1 Evergreen-LTS.
Kennst Du YCP?
Nein? Ok.
YPC:
http://www.99-bottles-of-beer.net/language-ycp-1160.html