[Chrome] Der Blick über den Tellerrand

[Alexander]

Ich finde es eigentlich auch recht gut, dass z.B. Variablen fest im Methodenkopf deklariert werden müssen. Ist einfach übersichtlicher. Gut, bei Variablen, die nur für eine For-Schleife benötigt werden, ist das vielleicht gar nicht so schlecht.
Aber nett, vielleicht kaufe ich mir das auch mal

Ein wenig Bedenken habe ich jedoch dabei, dass die Firma ja noch recht jung ist und evtl. schnell wieder vom Markt verschwinden kann. Oder Nachfolgeversionen nicht mehr abwärtskompatibel sind. Wer übersetzt mir dann mein eigentlich fertiges Programm in eine neue Sprache ?

Nachtrag:
Was ich aber sehr fair finde ist das:

Zitat:

Chrome 1.5 is a free update for all existing users of Chrome 1.0.

Eine deutsche Version fände ich auch nicht schlecht

[MagicAndre1981]

Zitat von Alexander:

Wer übersetzt mir dann mein eigentlich fertiges Programm in eine neue Sprache ?

Lutz Roeders Reflactor

[MrSpock]

Hallo Christian,

Zitat von Christian S.:

...
Ja, einige der Features von Chrome sind eine klare Abkehr von den Regeln, die Pascal dem Programmierer auferlegt, um sauberen Code zu erzwingen. Ich würde daher Delphi auch Chrome als Sprache für Anfänger vorziehen. Aber irgendwann ist man aus dem Stadium heraus, dass man einen Compiler braucht, der einem Vorschriften macht, um lesbaren Code zu erzeugen. Und an dem Punkt kommt mir Chrome sehr entgegen, weil es mir mehr Freiheiten gibt....

Hört sich an, wie irgendwann bin ich so gut, dass ich keinen sauberen Code mehr schreiben muss. Die Einschränkungen, die Pascal einem auferlegt, dienen nun mal auch dazu wartbaren Code zu schreiben und Fehler schon frühzeitig mit Hilfe des Compilers zu vermeiden. Ich programmiere jetzt schon seit über 20 Jahre und habe mich durch Pascal / Delphi nie eingeschränkt gefühlt, glaube aber gut wartbaren Code zu schreiben.Sinnvolle Erweiterungen hat es ja im Laufe der Zeit auch in Delphi's Pascal gegeben.

[Elvis]

Zitat von Alexander:

Ich finde es eigentlich auch recht gut, dass z.B. Variablen fest im Methodenkopf deklariert werden müssen. Ist einfach übersichtlicher.

Das hört man von Chome newbies immer wieder. Dauert nicht lange und man sieht nur noch dann eine var section in ihren Codes, wenn sie sinnvoll oder notwendig ist.
Zum Bleistift wenn man die Variable auch in der "require" oder "ensure" Clause benutzen will.

Delphi-Quellcode:

var
  mieps := iif(assigned(someParameter),
               someParameter.GetMieps(),
               nil);
require
  assigned(someParameter);
  assigned(mieps);
  mieps.Count > 0;
begin
...
ensure
  mieps.Count = old mieps.Count - 1;
end;

Ansonsten benutzt man eher using oder with-Blöcke, da kann man sofort sehen wo der Wert herkommt und die Variable lebt nur in diesem Block.

Delphi-Quellcode:

using dialog := new MyDialogForm(SomeProperty := 'miep') do
begin
  if dialog.ShowDialog() = DialogResult.Ok then
    blabla
end;

Variablen am Beginn einer Methode bringen IMO keineswegs mehr Übersichtlichkeit. Wenn ich hingegen den Methodenrumpf zusammenklappe und erst auf die Contracts schaue weiß ich viel mehr über das was in der Methode passiert und vor allem welche Zustände sie benötigt und welchen Endzustand sie garantiert.

Zitat:

Ein wenig Bedenken habe ich jedoch dabei, dass die Firma ja noch recht jung ist und evtl. schnell wieder vom Markt verschwinden kann.

Chrome ist nur ein kleines Produkt von RO, ihren Hauptumsatz machen sie anscheinend mit Delphikomponenten wie dem RO SDK, Data abstract und Hydra.
btw: hinter Klaradingsens Link findest du auch warum es Chrome überhaupt gibt. RO hat nämlich seine .Net Versionen der Delphiprodukte in Chrome geschrieben. Solange es also das RO SDK un DA gibt, wird es zwangsläufig auch Chrome geben.

Zitat:

Oder Nachfolgeversionen nicht mehr abwärtskompatibel sind.

Sie haben selbst legacy switches eingebaut um halbwegs kompatibel zu Delphi code zu sein[1] und da die Sprache von vornherein auf die CLR getrimmt ist, wüsste ich nicht was da an Problemen auftauchen sollte.
Sie sind auch ein wenig zurückhaltend was Features angeht, die komplett "unpascalish" wären: Ich habe sie z.Bsp. bis heute nicht von +=, -=, ++, -- überzeugen können. (habe es aber schon vor langem aufgegeben. )
Wobei += und -= nur für Events vorhanden waren.

[1] das beschränkt sich aber eigentlich nur auf

• namespace->unit
• new X -> X.Create (aber auch NUR Create, keine anders benannten Kontruktoren sind erlaubt)
• aliaslose with-clauses

Zitat:

Was ich aber sehr fair finde ist das:

Zitat:

Chrome 1.5 is a free update for all existing users of Chrome 1.0.

Es heißt auch nur aus diesem Grund 1.5 und nicht 2.

Zitat:

Eine deutsche Version fände ich auch nicht schlecht

Wird so schnell nicht passieren, lohnt sich einfach nicht. Vor allem da du ohne Englischkenntnisse auch in ROs support NGs auf wenig (sprachl.) Verständis stoßen wirst.


@MrSpock
Viele von Delphis Einschränkungen sind IMO nur vermarktet als qualitätsfördernde Strenge.
Gäbe es den Zwang, Variablen nur in der Var section deklarieren zu können, wirklich nur um saubereren Code zu erzwingen, hätte es niemals ein with in dieser kranken Form gegeben.
Ich denke eher, dass die Investition in einen Compiler, der dazu in der Lage wäre, gescheut wurde.

Aber Chrome ist IMO keine Sprache für Anfänger, schlicht und ergreifend weil ich keine richtige (also mit Ausnahme von KPL ) .Net Sprache als anfängertauglich bezeichnen würde.

[Frickeldrecktuxer_TM]

Zitat von MrSpock:

Hört sich an, wie irgendwann bin ich so gut, dass ich keinen sauberen Code mehr schreiben muss.

Nein, eher so wie "Irgendwann bin ich so gut, daß ich sauberen Code schreibe, und nicht mein Compiler."

Zitat von MrSpock:

Ich programmiere jetzt schon seit über 20 Jahre und habe mich durch Pascal / Delphi nie eingeschränkt gefühlt, glaube aber gut wartbaren Code zu schreiben.Sinnvolle Erweiterungen hat es ja im Laufe der Zeit auch in Delphi's Pascal gegeben.

Einige Features des Delphi-Refactorings sind durch die Sprache erst notwendig geworden. Zum Beispiel waren alle ganz aus dem Häuschen, als es hieß, die IDE würde jetzt lokale Variablen automatisch im Funktionskopf ergänzen, wenn man sie weiter unten einführt, und zwar ohne daß man selbst nach oben scrollt und die Variablen entsprechend selber nachträgt.
Und ich persönlich finde es in komplexen Funktionen deutlich unübersichtlicher, alle Variablen im Funktionskopf zu haben. Man nehme zum Beispiel eine Nachrichtenbehandlungsroutine:

Code:

void myhandler(message_t somemmessage)
{
  switch (somemmessage.type)
  {
  TYPE_1:
    {
      int i; // und weitere Variablen, die ich nur in dem Fall benötige, wenn ich Nachrichten vom Typ 1 erhalte
      break;
    }
  TYPE_2:
    {
      int i; // und weitere Variablen, die ich nur in dem Fall benötige, wenn ich Nachrichten vom Typ 2 erhalte
      break;
    }
  TYPE_3
    {
      int i; // und weitere Variablen, die ich nur in dem Fall benötige, wenn ich Nachrichten vom Typ 3 erhalte
      break;
    }
  TYPE_4:
    {
      int i; // und weitere Variablen, die ich nur in dem Fall benötige, wenn ich Nachrichten vom Typ 4 erhalte
      break;
    }
  TYPE_5:
    {
      int i; // und weitere Variablen, die ich nur in dem Fall benötige, wenn ich Nachrichten vom Typ 5 erhalte
      break;
    }
  default:
    break;
  }
}

Mit passenden Optimierungen hältst du dir damit auch noch den Stack sauber. Angenommen ich bräuchte für jede Nachricht 5 Variablen unterschiedlichen Typs. Warum sollte ich mir meinen Funktionskopf mit 25 Variablen zukleistern? So kann ich wunderbar die Variablen dort deklarieren, wo ich sie benötige. Nur dort sind sie gültig und Objekte werden automatisch freigegeben, sobald der Scope verlassen wird (okay, sowas kennt Delphi nicht, aber das ist ja ein anderes Thema).
Vom Entwickler wird bezüglich der Wartbarkeit nur verlangt, daß er nicht einfach "irgendwo" die Variablen deklariert, dann das wäre wirklich unübersichtlich. Aber der Entwickler hat so ein feineres Werkzeug um zu bestimmen, wie lange die Variablen überhaupt existieren und bezüglich der Wartbarkeit den Variablen einen Block zuzuordnen, zu dem sie gehören.

Dieses Märchen, daß die Pascal-Syntax automatisch für wartbaren Code sorgt und daß alle anderen Programmiersprachen dadurch automatisch böhse[tm] sind, habe ich oft genug gehört, als daß ich es noch ernstnehmen würde. Wartbarer Code liegt immer am Entwickler. Wer mit C oder C++ keinen wartbaren Code schreibt, benutzt sein Werkzeug falsch.

[Christian S.]

Wie kann sich denn das:

Zitat von Christian S.:

Aber irgendwann ist man aus dem Stadium heraus, dass man einen Compiler braucht, der einem Vorschriften macht, um lesbaren Code zu erzeugen.

Wie das:

Zitat von MrSpock:

Hört sich an, wie irgendwann bin ich so gut, dass ich keinen sauberen Code mehr schreiben muss.

anhören, ohne dass der Zuhörer das wirklich so verstehen will?

Zitat von MrSpock:

Ich programmiere jetzt schon seit über 20 Jahre und habe mich durch Pascal / Delphi nie eingeschränkt gefühlt, glaube aber gut wartbaren Code zu schreiben.

Dann ist es für Dich gut und richtig, bei Delphi zu bleiben. Wie ich obne schon schrieb: Jedem das, was ihm am Besten gefällt. Es heisst aber nicht, dass man nicht auch in Chrome gut wartbaren Code schreiben kann. Es erfordert halt eine gewisse Disziplin des Programmierers. Das ist z.B. die Disziplin, die dazu führt, dass man in Delphiprogrammen kaum Goto-Anweisungen sieht, obwohl die Sprache es zur Verfügung stellt.

[Hansa]

Zitat von MrSpock:

..Hört sich an, wie irgendwann bin ich so gut, dass ich keinen sauberen Code mehr schreiben muss...

Schlimmer noch : einige fühlen sich offensichtich geradezu ermuntert, die Fehler von C-Programmierern nachmachen zu müssen. Ist halt momentan in. Ich kann nur sagen : es lebe die Freiheit, die nur die Inkompatibilität zur Folge hat. 8) Und die Tatsache, daß man nicht alles so machen muß, was man kann, bedeutet nach Murphy : es wird doch gemacht werden ! Elvis weiß zwar sowieso nicht, was er will 8) , aber was jetzt ? Kommt es auf die IDE an, oder auf die Programmiersprachen-Syntax ? Erst wird Delphi auf diese "Mist-IDE" reduziert und nun isr die ziemlich egal, denn die Syntax von Chrome ist ja so viel besser und bietet viel mehr ? Das soll verstehen, wer will.

Einige "Erweiterungen" durch Chrome sehe ich zumindest als klare Nachteile an. Und was nützt es mir, wenn ich sie dann gar nicht brauche oder vorsichtshalber nicht benutze ? Übrig bleiben mehr Nach- als Vorteile. Meine Meinung dazu ! Solche Threads führen sowieso zu keinem Ergebnis.

[Daniel]

Zitat von Hansa:

Solche Threads führen sowieso zu keinem Ergebnis.

Definitiv falsch und nicht zuende gedacht.

Christian hatte doch selbst schon geschrieben, dass es sich um einen Blick über den Teller-Rand handelt und das im Endeffekt jeder für sich entscheiden müsse. Es wäre schön, wenn Ihr wieder zu einer sachlichen (!) Bewertung zurückfinden könntet.

Ganz nebenbei geht es hier nicht um "Highlander" - es kann also auch mehr als einen geben.

[Frickeldrecktuxer_TM]

Zitat von Hansa:

einige fühlen sich offensichtich geradezu ermuntert, die Fehler von C-Programmierern nachmachen zu müssen.

Welche "Fehler von C-Programmierern"? Und wer fühlt sich dazu ermuntert?

Zitat von Hansa:

Ich kann nur sagen : es lebe die Freiheit, die nur die Inkompatibilität zur Folge hat.

Na also, dann leb' du weiterhin eingeschränkt (beinahe hätte ich "beschränkt" geschrieben ), aber lass Christian S. die Freiheit, eine Sprache zu benutzen, die ihm deutlich mehr Vorteile bietet, weil er weiß, wie er damit umgehen muss.

Zitat von Hansa:

Kommt es auf die IDE an, oder auf die Programmiersprachen-Syntax ? Erst wird Delphi auf diese "Mist-IDE" reduziert und nun isr die ziemlich egal, denn die Syntax von Chrome ist ja so viel besser und bietet viel mehr ? Das soll verstehen, wer will.

Dir ist aber schon bewusst, daß Chrome nicht mit Delphi/BDS funktioniert, sondern nur im VS? Wenn jemand über die "Mist-IDE" meckert, wie du es ausdrückst, ist es nur konsequent, sich für Chrome oder andere Sprachen zu interessieren, die nicht "Mist" sind. Außerdem hat nicht jeder Delphi nur auf die IDE reduziert. Elvis, wenn du ihn schon nennst, hat beispielsweise immer gesagt, daß auch die Sprache selbst genug Mängel aufweist.
Also, um deine Frage zu beantworten: Ja, die Syntax von Chrome ist für einige so viel besser und bietet (faktisch, nicht für einige) viel mehr, deswegen kann Delphi aber weiterhin eine "Mist-IDE" sein, weil das eine das andere nicht ausschließt. Chome hat schließlich nichts mit Delphi oder Borland gemein.

Zitat von Hansa:

Einige "Erweiterungen" durch Chrome sehe ich zumindest als klare Nachteile an.

Welche? Besagte Variablendeklaration zwischen begin und end? Warum ist das ein Nachteil für jemanden, der damit umgehen kann?

Zitat von Hansa:

Und was nützt es mir, wenn ich sie dann gar nicht brauche oder vorsichtshalber nicht benutze ?

Du hast die Freiheit (da ist sie wieder), die zusätzlichen Features einzusetzen, wenn du einmal reif genug sein wirst, dies sinnvoll zu tun.

Zitat von Hansa:

Übrig bleiben mehr Nach- als Vorteile.

Benutzt du eigentlich Messer? Es ist ein ganz klarer Nachteil, daß man damit Menschen umbringen kann. Und so unglaublich nützlich sind die verbleibenden Vorteile von Messern ja auch nicht, schließlich kann ich meine Nahrung auch mit den Zähnen zerkleinern. Es bleiben also mehr Nach- als Vorteile beim Gebrauch von Messern. Ich werde gleich eine Petition einreichen, die die Benutzung von Messern EU-weit untersagt!

[lizardking]

Zitat von Christian S.:

Ein guter Punkt, um zum nächsten Beispiel zu kommen, wo der Compiler Arbeit übernimmt. Oft kommt es vor, dass eine Property einfach nur ein privates Feld kapselt, also gar keine get- und set-Methoden vorhanden sind.

Hier hilft Chrome, den ewig gleichen Standardcode zu vermeiden, indem es folgende Syntax erlaubt:

Delphi-Quellcode:

type
  TFoo = public class
  public
    property aProp : String;
  end;

Mehr ist nicht nötig, um eine Property anzulegen, der Rest wird implizit deklariert. (Obiges Beispiel zeigt ein weiteres Chrome-Feature: Typensichtbarkeit wird vollständig unterstützt.)

Ein Beispiel fuer ein Feature, was mich persoenlich stoeren wuerde. In Delphi saehe es ja so aus :

Delphi-Quellcode:

type
  TFoo = public class
  private
    FProp: String;
  public
    property Prop : String read FProp write FProp;
  end;

Jetzt hab ich ein wenig mehr Code, wenn ich aber in der Klasse TFoo arbeite, weiss ich immer genau was passiert. Wenn ich dort naemlich "fremden" Code von Kollegen durchgehe, kann ich bei jeder Zuweisung erstmal nachschauen, ob nicht eine Setter-Methode noch mehr macht als nur die Variable zu setzen. Wenn sich aber jeder daran haelt innerhalb der Klasse nur auf die Feldvariablen zuzugreifen, kann ich auf einen Blick ausschliessen, dass noch irgendwas sonst passiert.

Wenn mich diese klare Trennung von Feldvariablen und Properties nicht sonderlich kuemmert, dann kann ich zur Not auch einfach die Variablen als public deklarieren

Gruss, Lizzy