Java

[Konrad Rudolph]

Was Java z.B. obsolet macht, ist Case Sensitivity. Das ist ein unbrauchbares Konzept, das früher einfach aus Gründen der Einfachheit beim Compilerbau eingeführt wurde.

Früher vielleicht. Heute verhindert es solche Geschichten:
  int columnCount;
  [..]
  COLUMNCOUNT = 15;

Dafür ermöglicht es folgendes:
  int columnCount = 15;
  int columncount = 20;

Hat halt alles zwei Seiten...

na, es geht aber wesentlich schneller, zu programmieren, wenn man keine Rücksicht auf Groß-/Kleinschreibung lesen muß. Vor allem bei der IntelliSense-Hilfe in der IDE ist das ein ganz enormer Vorteil.

Beispiel: bei .NET gebe ich ein "sys<Strg+Leertaste>" und bekomme eine Liste aller Members vom Namespace "System" angezeigt. Wenn ich das selbe in C# mache, bekomme ich nüx. Ich muß stattdessen schreiben "<Umschalt>sys<Strg+Leertaste>". Wenn man das am laufenden Band machen muß, ist der Geschwindigkeitsunterschied recht erheblich (ich würde mal grob 5-10% schneller schätzen).

Klar, natürlich. Und du bist ein typischer Fall, weißt du das? Du siehst einmal VBA oder VBS (noch schlimmer!) und denkst "oh, Gott, Kindergarten".

Ja. Und vor allem habe ich mich gefragt, was dieses hübsche VBA-
Programm, das da irgendwelche Excel-Sheets geholt und einzelne
Zeilen farblich markiert hat, da eigentlich tut, und wie man mit
einer untypisierten Sprache wirklich arbeiten soll.

Wie meinst du das? Untypisiert? Seit wann ist VB nicht typisiert?

Ganz zu
schweigen davon, daß nie wirklich klar wurde, was da jetzt für
ein Objekt in der Variable steckt oder welche Default-Methode
jetzt implizit aufgerufen wurde.

das ist absolut Gewöhnungssache.

Folgende Zeile Code:

Worksheets(Blatt1)

bedeutete letztendlich sowas:

Worksheets.Worksheet.Select("Blatt1")

Ok, wer sowas schreibt, ist selber Schuld. Aber es gibt Fälle, wo das durchaus praktisch sein kann.
In VB z.B. gibt es zwar Arrays, aber keine Hashtables. Naja, daher kann man dank Defaultmethode eine äquivalente Syntax verwenden:

\\ ' nativ:
ArrayVar(0) = "hi"

' Hashtable:
ArrayVar("Index") = "hi"
///

das geht dank Defaultmethode. Wenn eine Programmiersprache Operatorenüberladung unterstützt, braucht man sowas nicht.
Das ist halt eine Sache, die richtig angewendet sehr mächtig sein kann, aber falsch angewendet auch sehr viel Unheil stiften kann.

Aber ich denke, es ist recht akkurat. So denken nämlich die meisten "harten Programmierer", die nicht VB verwenden und all ihre GUIs am liebsten mit ASM-Mnemonics oder noch besser Bytecode schreiben.

Was genau hat das Schreiben einer GUI mit der Syntax einer Sprache
zu tun?

na, findest du es nicht leicht unsinnig, eine GUI in ASM zu schreiben? Es gibt Leute, die das machen. Und die lachen sich dann natürlich über sowas wie VB tot. Klar. Aber praktischer wäre es trotzdem, zum Programmieren von GUIs eine High-Level-Sprache zu verwenden.

Tatsache ist, daß die Syntax von VB.NET (!!! *nur* die von .NET!)

Die kenne ich nicht konkret. So gravierend waren die Änderungen
zwischen VB6 und VB.Net doch aber gar nicht. Jedenfalls bin ich an
der Syntax verzweifelt.

hmm. Inwiefern denn nun verzweifelt?
Die Unterschiede zwischen VB.NET und VBC sind recht groß, auch, was die Syntax betrifft.

Ein Beispiel habe ich ja oben genannt.

welches? Daß VB untypisiert ist? Oder daß es unleserlich sei, Default-Methoden zu verwenden?
Ich denke, hier muß zwischen den Kapazitäten der Sprache und denen des Programmierers unterschieden werden.

die beste Syntax ist, die es zur Zeit auf dem Markt gibt.

Wenn VB.Net größte Teile von VB6 übernommen hat (und soweit ich weiß,
hat es das), dann definitiv nicht!

also, was Produktivität angeht, ganz eindeutig. Die Entwicklungszeit von VB-Programmen ist nachweisbar kürzer als die von Programmen in anderen Sprachen.

Und zwar aus einem handfesten Grund: Lesbarkeit. Dies erhöht die Produktivität nachweislich um einen recht hohen Faktor. Man kann einfach viel schneller entwickeln und sich in alte Codes / Fremdcodes einarbeiten.

Das gilt allgemein, ja.
Basic ist aber definitiv nicht besser lesbar als andere Sprachen.

doch, da sich VB (oder meinetwegen auch Basic) ähnlich wie eine menschliche Sprache liest.

was ist daran gut und sinnvoll? So schreibt man doch nicht in normalen Texten, warum dann in Quelltexten?

In normalen Texten trennt man mit Leerzeichen. Da das in Programmier-
sprachen nicht geht, muß eben ein Ersatz her. Unterstriche sehen
dämlich aus. Sonst würden sie wohl kaum noch so selten verwendet
werden. Also bleibt Camel-Case. Oder sehe ich das falsch?

ja. Es gibt nämlich noch PascalCase und diese Schreibweise entspricht sehr viel eher als camelCase dem typischen Schriftbild eines Texts, da der erste Buchstabe eben groß ist. sagen wir mal so: angesichts der Existenz sehe ich keinen Grund für die Einführung/Verwendung von camelCase, die lediglich eine veränderte Schreibweise von PascalCase darstellt.

Ja, schon. Auch die Ungarische Notation hat sich durchgesetzt

Die ungarische Notation hat sich nur bei Microsoft durchgesetzt.

"bei Microsoft". Du meinst in der Firma "Microsoft"?
Also, ich habe schon oft die Ungarische Notation gesehen, nicht nur in VB und nicht nur bei MS.

Den meisten dürfte klar sein, daß die Notation Mist ist.

das dürfte es auch bei camelCase, ist es aber anscheinend nicht.

Es ist eben eine sehr C-ähnliche Sprache, was die Syntax anbelangt, auch wenn Pointers etc. wegfallen. Diese Syntax ist einfach obsolet, da schwerer lesbar als Sprachen wie VB.NET.

Geschmackssache. (Meistens.)

Hmm. Der Autor des Artikels schreibt übrigens den ästhetischsten Quellcode, den ich je zu Gesicht bekommen habe. Die Bedeutung des Codes ist immer sofort klar.

Wie, fehlendes Schlüsselwort? Als was würdest du "int", "double",
"float" bezeichnen?

allein schon dadurch, daß die klein geschrieben werden, überliest man sie leicht bzw. nimmt sie nicht als Schlüsselwörter wahr. Natürlich, moderne Editoren sollten Syntaxhighlighting unterstützen, aber z.B. in NGs und Foren ist so etwas nicht gewährleistet.

Du hast Recht bei nicht-primitiven Datentypen. Es gibt kein ein-
leitendes Schlüsselwort. Trotzdem ist es mir noch nicht einmal
passiert, daß ich eine Variablendeklaration als Methodenaufruf
interpretiert hätte. (Zumal sich ein Methodenaufruf nicht nur durch
die Klammern von der Deklaration unterscheidet.)

Na, verwechselt habe ich das auch noch nie. Aber es ist für das Gehirn wesentlich schwerer, den Unterschied sofort zu erfassen. Ganz unbewußt erleichtert die Verwendung von Schlüsselwörtern dem Gehirn das Lesen und Verstehen eines Codes.

Um auf die Ausgangsfrage zurückzukommen: Wieso sind dann Teile von
StarOffice "baa", nur weil sie in Java geschrieben sind.

ok, *die* sind "baa", weil ich mir extra die Java-Runtime installieren mußte, die ich prior aus Gründen der Performance von meinem System verbannt hatte.

Eigentlich hab ich noch immer kein wirkliches Argument gesehen.

ok, ich fasse noch einmal zusammen:

1. die maschinen- (statt menschen-) nahe Syntax
2. camelCase
3. Case Sensitivity

Einig sind wir uns aber, daß C++ (und wohl auch C) ziemlich unleserlich sind.

Ich sehe keine großen syntaktischen Unterschiede zwischen Java und C++.

Allerdings halte ich auch Basic für unleserlich und vor allem
auch fehleranfälliger als Java.

fehleranfällig? Also, fehleranfällig fände ich C, weil es nicht typensicher ist und Pointers unterstützt, oder PHP, weil es untypisiert ist.

Du findest es anscheinend syntaktisch ausgesprochen gut.
Mein erster Eindruck von der Syntax war jedenfalls ein anderer...

Jahrelange Arbeit in VB und C++ haben mich bekehrt.
Übrigens gibt es viele professionelle C++-Programmierer, die lediglich die Backends aus Performancegründen in C++ schreiben und das Frontend in VB. Ob es eine solche Symbiose auch bei anderen Sprachen in diesem Maße gibt, weiß ich nicht, glaube es aber nicht, da keine andere Sprache so viel verwendet wird, wie VB (nicht einmal C++).

Gruß,
KonRad -