Vala?!

[sacridex]

Schade, dass Vala immer noch nicht allzuviel Verbreitung hat.
Es ist eine sehr schöne Sprache(stark Java/C# angelehnt), jedoch wird der Code in C + GObject Code übersetzt und dann von einem gcc übersetzt, was deutlich performanter als Java/C#.net sein dürfte.

[74zm]

sieht sehr interessant aus! danke für den hinweis.

[Schnarchnase]

sacridex schrieb:
--------------------------------------------------------------------------------
> Es ist eine sehr schöne Sprache(stark Java/C# angelehnt), jedoch wird der
> Code in C + GObject Code übersetzt und dann von einem gcc übersetzt, was
> deutlich performanter als Java/C#.net sein dürfte.

Ja sie vereint praktisch die Vorteile Java/C# und C und ist damit auch die Sprache meiner Wahl, wann immer ich die Wahl habe.

[YAN]

Java und C# sind keine schönen Sprachen, sondern sind vor allem deshalb stark weil die Werkzeuge unglaublich ausgereift sind, Vala hat das nicht, deswegen wirkte Vala schon bei Release uralt, Sprachenthusiasten die immer in der State-of-the-art-Sprache programmieren wollen werden darum wohl lieber einen Bogen machen, konservative schreiben ihre Gnome und GTK Programme lieber weiterhin in C, weil das bisher ja auch funktioniert hat, wen spricht die Sprache also an? Konservative die von Java oder C# auf ein GObjectbasierendes System wechseln wollen, warum auch immer(Geschwindigkeit.. vl, aber so groß wird der Unterschied nicht sein - ginge es nur um eine OOP-Sprache mit großer Geschwindigkeit und Optimierungsmöglichkeit wäre C++ die naheliegendere Wahl), die vl, aber so viele sind das vermutlich nicht.

[Schnarchnase]

Werkzeuge schön und gut, aber nach der Logik wird es nie wieder eine neue Sprache schaffen sich durchzusetzen, da am Anfang die Zahl der Werkzeuge immer gering ist.

Der große Vorteil von Vala gegenüber C++ ist, dass es zu C-Code kompiliert und so sämtliche C-Bibliotheken genutzt werden können. Ich finde den Ansatz sehr interessant. Warum so pessimistisch?

[YAN]

>>Der große Vorteil von Vala gegenüber C++ ist, dass es zu C-Code kompiliert und so sämtliche C-Bibliotheken genutzt werden können.
-Du kannst auch in C++ sämtliche C Bibliotheken verwenden, in der Hinsicht sind die Sprachen vollständig kompatibel.

>>Werkzeuge schön und gut, aber nach der Logik wird es nie wieder eine neue Sprache schaffen sich durchzusetzen, da am Anfang die Zahl der Werkzeuge immer gering ist.
-nein das habe ich nicht gesagt. Ich habe gesagt Vala bietet für kaum jemanden Anreiz, ich habe nicht gesagt das träfe auf alle Sprachen zu. Eine Sprache die hinreichend großen Mehrwert bietet wird zunächst von einer Gruppe und dann ggf. allgemein akzeptiert.

Wobei das ein wenig idealisiert ist, manchmal mag das stimmen, aber in der Realität spielen oft auch andere Faktoren eine Rolle, C# wurde von MS gepushed, Java ist auf der Browserwelle geritten, wenn auch schon lange abgesprungen, C++ war vor allem C kompatibel und C selbst ist wegen Unix populär geworden.

Aber Vala hat kein Schwergewicht dahinter, dient nicht zur Entwicklung von etwas besonders populären (die Gnome-Welt hat eher kleine Marktanteile) und ist sprachlich nur ein Rip-Off einer 11 Jahre alten Sprache, die größtenteils ein Rip-Off einer 20 Jahre alten Sprache ist, die damals schon nicht wahnsinnig innovativ ist(vgl. z.B. Smalltalk aus der Zeit davor) und die Features auf die das nicht zutrifft werden nicht unterstützt(Stichwort Linq, aber ich muss hier zugeben die neueste Geschichte von Vala nicht verfolgt zu haben, falls es mittlerweile ebenfalls derartige Dinge hat kannst du den Punkt streichen), inwiefern kommt dir das modern vor? Die Welt der Programmiersprachen bleibt nicht stehen.



1 mal bearbeitet, zuletzt am 27.04.12 23:36 durch YAN.

[derats]

Ich code gerade was kleines in C(++) (winhud). Vorher habe ich jetzt ein gutes halbes Jahr nur in Python programmiert. Ich habe bei der statischen Typisierung praktisch im Strahl gekotzt (gut, liegt auch daran, dass ich die Windows C API genutzt habe), weil man einfach immer jeden Typen bis auf den Buchstaben ausschreiben muss.
Dafür kriegt man dann einen Perfomancevorteil von 1-10 % (im Schnitt) i.Vgl. zu Pypy oder JIT-JVM.

Um es kurz zu machen: ich halte von statischer Typisierung nicht mehr viel. Sie hilft zwar bei der Kompilierung Fehler zu erkennen, behindert aber zumindest meinen Workflow enorm. Bei C++ kommt dann noch die schwache Standardbibliothek dazu...

[Kartoffel]

YAN schrieb:
--------------------------------------------------------------------------------
> Java und C# sind keine schönen Sprachen, sondern sind vor allem deshalb
Im vergleich zu C++ schon.

> stark weil die Werkzeuge unglaublich ausgereift sind, Vala hat das nicht,
> deswegen wirkte Vala schon bei Release uralt, Sprachenthusiasten die immer
Vala bietet mehr Features wie Java von daher kann das nicht stimmen. Das fängt z.b schon bei dynamischer Array Erweiterung an:
int[] arr = {}
arr += zahl;

und geht weiter mit Higher-Order ähnlichen Konzepten usw. usw.

> in der State-of-the-art-Sprache programmieren wollen werden darum wohl
> lieber einen Bogen machen, konservative schreiben ihre Gnome und GTK
> Programme lieber weiterhin in C, weil das bisher ja auch funktioniert hat,
Das ist nicht ganz richtig. Vala wird vor allem mehr und mehr in der Gnome Gemeinde genutzt. Tendenz steigend.

> wen spricht die Sprache also an? Konservative die von Java oder C# auf ein
Es spricht vor allem die C,Java und C# Entwickler an.
> GObjectbasierendes System wechseln wollen, warum auch
Vala ist nicht an GObject gebunden.
> immer(Geschwindigkeit.. vl, aber so groß wird der Unterschied nicht sein -
> ginge es nur um eine OOP-Sprache mit großer Geschwindigkeit und
> Optimierungsmöglichkeit wäre C++ die naheliegendere Wahl), die vl, aber so
> viele sind das vermutlich nicht.
Vala ist natürlich auf dem Niveau von C welches auch mal schneller wie C++ sein kann.
http://jpaflacerda.wordpress.com/2011/11/08/vala-benchmarking/

Man kann von Vala halten was man will, aber das einfache Konzept von Vala ist einfach gut.
Eine Moderne Sprache welche astreinen C-Code generiert und kompiliert welche ja bekanntliche extrem ressourcenschonend und portabel ist. Die einzige Kritik die man gelten lassen kann ist das Bindings zu XY noch nicht existieren oder selber erstellt werden müssen. Das war es dann aber auch schon.

Ich erlaube mir mal etwas Eigenwerbung für meinen Blog:
http://valasprache.wordpress.com/

[YAN]

>>weil man einfach immer jeden Typen bis auf den Buchstaben ausschreiben muss.
nein, das hat mit statischer Typisierung nix zu tun, Type Inference hat jede moderne Sprache (inkl. C# und C++11) und verhindert genau das. Aber prinzipiell hast du Recht, statische Typisierung ist mehr bloated und du entwickelst darin langsamer, das ist aber ein bekannter Trade-Off bei dem Thema, je nach Situation wählst du halt:
schnelle Entwicklung vs. robusterer Code.

>>Im vergleich zu C++ schon.
C++ kann Dinge die die beiden nicht können, von daher hat C++ seine Nische und die ist gar nicht mal so klein.
Außerdem ist die allgemeine Verteufelung von C++ auch nicht förderlich, Value-Semantik hat auch was für sich, templates sind ebenfalls etwas das in java z.B. gar kein Äquivalent hat(außerhalb dessen was generics könne, was viel weniger ist), C# hat wenn die Generizität nicht ausreicht wahlweise dynamische Typisierung, nicht das gelbe vom Ei tut aber, Scala hat als moderne Sprache hingegen solche Dinge wie structural types und kann C++ damit in einigen Punkten das Wasser reichen(Meta programmierung können diese zwar nicht, aber immerhin).
Dennoch gebe ich dir Recht, es gibt viel zu viele Fallstricke, die man kennen muss und man fällt dennoch häufig rein.

>>Vala bietet mehr Features wie Java von daher kann das nicht stimmen.
habe ich auch gar nicht bestritten, aber so radikal viele sinds halt nicht, es ist doch noch näher an Java oder wenigstens C# 3.0 als an dem womit heutzutage experimentiert wird Scala, F#, Clojure, meinetwegen auch Groovy o.ä.

>>Vala ist natürlich auf dem Niveau von C welches auch mal schneller wie C++ sein kann.
Das sind Toy-Benchmarks, für reale Programme spielen die keine Rolle. Worauf ich hinauswollte ist, dass die reine Ausführungszeit deines Programms meistens gar nicht so relevant ist, und erst recht nicht im Umfeld von Anwendungsprogrammen in denen sich Vala eigentlich ansiedelt, dein Bottleneck liegt einfach wo anders, die Sprache kann 3 mal so schnell sein, 90% deiner Antwortzeit liegen aber im Bottleneck, wenn du da lange auf etwas anderes wartest und vl nur 5% deinen Code ausführst hast du es effektiv geschafft das Programm um 10% zu beschleunigen, DAS ist nicht genug für die Wahl einer Sprache.

>>Eine Moderne Sprache welche astreinen C-Code generiert und kompiliert welche ja bekanntliche extrem ressourcenschonend und portabel ist.
C an sich ist nur Ressourcenschonend, weil es nichts weiter als ein high-level Assembler ist, das Vala schnellen C Code generiert glaub ich dir, aber das jede Sprache die nach C kompiliert deswegen automatisch schnell ist ist falsch.
C++ hat übrigens in seinen Anfangstagen auch zunächst C Code generiert(CFront), der GHC kann ebenso C Code generieren und meines Wissens auch noch einige andere Sprachen nur lässt mich mein Gedächnis grad im Stich welche, die Idee ist alles andere als neu.
Auf ein existierendes Ecosystem aufzubauen ist ja heutzutage nicht unüblich, meistens wählt man allerdings mittlerweile .NET oder die Java Umgebung.

Mir stellt sich in Puncto Geschwindigkeit auch noch die Frage was für Optimierungsmöglichkeiten Vala bietet, in C++ kannst du beispielsweise an jeder Stelle schrauben(eigene Allokatoren etc. pp.), in C sowieso weil du alles zusammenschraubst, bei Vala bin ich in dem Punkt nicht sattelfest.

[Tapsi]

Schnarchnase schrieb:
--------------------------------------------------------------------------------
> Werkzeuge schön und gut, aber nach der Logik wird es nie wieder eine neue
> Sprache schaffen sich durchzusetzen, da am Anfang die Zahl der Werkzeuge
> immer gering ist.

Das stimmt nich so ganz. Es sind die neuen Sprachen die sich langsam durchsetzen, die mit den alten kombatibel sind. Bei der JVM fällt mir immer gleich Scala ein, da diese Sprache eben mit allen alten Libraries aus der Java-Welt umgehen kann. Das ist denke ich ein wichtiges Kriterium was eine neue Sprache erfüllen muss um über das Nischendasein hinaus zu kommen.


> Der große Vorteil von Vala gegenüber C++ ist, dass es zu C-Code kompiliert
> und so sämtliche C-Bibliotheken genutzt werden können. Ich finde den Ansatz
> sehr interessant. Warum so pessimistisch?

Mir fehlt so dass Alleinstellungsmerkmal... was hat Vala was andere nicht haben, oder nicht einfach realisieren könnten?

while not sleep
sheep++



1 mal bearbeitet, zuletzt am 28.04.12 09:22 durch Tapsi.

[Tapsi]

> Um es kurz zu machen: ich halte von statischer Typisierung nicht mehr viel.
> Sie hilft zwar bei der Kompilierung Fehler zu erkennen, behindert aber
> zumindest meinen Workflow enorm. Bei C++ kommt dann noch die schwache
> Standardbibliothek dazu...

Naja ich programmiere auch viel in JS und ich mag dynamische Typisierung auch, aber es ist einfach so das dyn. Typen extrem viel Selbstdisziplin erfordert um vern. Code zu programmieren. Viele haben das nicht.. dann kommt schnell Murcks bei rum. Unterm Strich aber ist es bei größeren Projekten vorteilhaft schon zur Kompilierungszeit Typ-Fehler zur erkennen.. bei JS / Python muss man die Immer zur Laufzeit klären... das ist auch manchmal nervig ( wo bleiben coole Typannotationen in JS... nein ich will den GoogleSCHROTT nicht ). Aber mit der Performance hast du recht.. es kostet.. aber eig. nicht viel.

while not sleep
sheep++

[sacridex]

YAN schrieb:
--------------------------------------------------------------------------------
> Mir stellt sich in Puncto Geschwindigkeit auch noch die Frage was für
> Optimierungsmöglichkeiten Vala bietet, in C++ kannst du beispielsweise an
> jeder Stelle schrauben(eigene Allokatoren etc. pp.), in C sowieso weil du
> alles zusammenschraubst, bei Vala bin ich in dem Punkt nicht sattelfest.

Kannst ja den Vala Code nach C übersetzen lassen, optimieren und dann erst compilieren.

[YAN]

und das geht dann in der nächsten Version direkt verloren?

[derats]

Ich finde, dass das Thema Geschwindigkeit maßlos überschätzt wird.
Nehmen wir z.B. mal CPython her, das ist im Regelfall ungefähr 20 mal langsamer als C und trotzdem kann ich bei interaktiven Anwendungen keinen Unterschied feststellen.
Selbst heutige Netbooks sind so schnell, dass die Ausführungsgeschwindigkeit der Applikationen in gewissen Grenzen irrelevant ist.

Und selbst wenn ich mal "nativen Speed" brauche, komme ich mit Pypy, JIT usw. locker auf Augenhöhe mit C, manchmal sogar deutlich schneller (->Source-level-optimization über Modulgrenzen hinweg, was C-Compiler prinzipbedingt meist nicht können).

Verzeiht mit daher, wenn Geschwindigkeit einer Sprache für mich weder ein intrinsisches Merkmal dieser ist noch für mich ein relevantes Kriterium darstellt.

Tapsi schrieb:
--------------------------------------------------------------------------------
> > Um es kurz zu machen: ich halte von statischer Typisierung nicht mehr
> viel.
> > Sie hilft zwar bei der Kompilierung Fehler zu erkennen, behindert aber
> > zumindest meinen Workflow enorm. Bei C++ kommt dann noch die schwache
> > Standardbibliothek dazu...
>
> Naja ich programmiere auch viel in JS und ich mag dynamische Typisierung
> auch, aber es ist einfach so das dyn. Typen extrem viel Selbstdisziplin
> erfordert um vern. Code zu programmieren. Viele haben das nicht.. dann
> kommt schnell Murcks bei rum. Unterm Strich aber ist es bei größeren
> Projekten vorteilhaft schon zur Kompilierungszeit Typ-Fehler zur erkennen..
> bei JS / Python muss man die Immer zur Laufzeit klären... das ist auch
> manchmal nervig ( wo bleiben coole Typannotationen in JS... nein ich will
> den GoogleSCHROTT nicht ). Aber mit der Performance hast du recht.. es
> kostet.. aber eig. nicht viel.

Eigentlich sollten die Unit-Tests das ja alles abdecken. Die man eigentlich sowieso schreiben muss ... SCNR :D

[Tapsi]

> Eigentlich sollten die Unit-Tests das ja alles abdecken. Die man eigentlich
> sowieso schreiben muss ... SCNR :D

Aber die müssen ja auch erstmal geschrieben werden xD

while not sleep
sheep++

[YAN]

und frei von Typbedingten Fehlern sein!

[Kartoffel]

Natürlich kann man vala wie auch c optimieren, aber wie hier meiner Meinung nach schon richtig geschrieben wurde ist die Laufzeit Performance meistens weniger wichtig. Es geht bei vala viel mehr um sprach Features und C bindings. Jeder muss natürlich von einer neuen Sprache überzeugt sein sich damit zu beschäftigt. Sei es nun Go oder Scala oder vala. In meinen Augen spricht gegen Go mangelndes Tooling, mäßige APIs. Gegen Scala..... Scala ist in meinen Augen die interessanteste Sprache allerdings ist Scalas größter Vorteil (die VM) gleichzeitig Ihr größter Nachteil. Gegen C könnte man nicht vorhandenes OO vorbringen. Wenn man was gegen vala vorbringen möchte finde man sicherlich auch was, aber wenn man mal objektiv darüber nachdenkt ist vala eine gelungene sache welche ganz sicher mehr und mehr eingesetzt wird. Ich finde das Das Argument das es noch nicht sonderlich verbreitet ist relativ schwach und wer unbedingt ein Alleinstellungsmerkmal sucht dem würde ich sagen das vala ganz einfach das weit bessere C ist.


Ich finde man sollte als Entwickler flexibel sein und sich generell nicht nur einer Sprache versprechen. Alle sprachen haben ihre Daseinsberechtigung ;-)



3 mal bearbeitet, zuletzt am 28.04.12 14:58 durch Kartoffel.