1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › .Net Core 5: Microsoft…

Ist ja auch richtig so

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Ist ja auch richtig so

    Autor: AllDayPiano 13.03.20 - 15:26

    Visual Basic ist eigentlich tot. Seit .NET hat es keine Vorteile mehr gegenüber C#; im Gegenteil: Es verklausuliert durch unnötig viel Linguistik im den Code.

    Unter VB 6 war ich noch ein großer Fan der Sprache. Mittlerweile musste ich auf C# umsatteln und kann mir beim besten Willen nicht mehr vorstellen, jemals wieder zurück zu wechseln. Code in C# ist effizienter, mindestens genauso gut zu lesen, aber viel angenehmer geschrieben.

    Das einzige, das VB am Leben gehalten hat, war VBA. Aber auch das hat sich meiner Meinung nach einfach selbst überlebt.

    Eigentlich sollte MS VB komplett sterben lassen, und nurnoch C# forcieren (konsequent über alle Belange). Dann könnte man auch moderne Sprachfeatures in Office nutzen.

  2. Re: Ist ja auch richtig so

    Autor: Marcus Porcius Cato 13.03.20 - 15:45

    AllDayPiano schrieb:
    --------------------------------------------------------------------------------
    > Das einzige, das VB am Leben gehalten hat, war VBA. Aber auch das hat sich
    > meiner Meinung nach einfach selbst überlebt.
    >
    > Eigentlich sollte MS VB komplett sterben lassen, und nurnoch C# forcieren
    > (konsequent über alle Belange). Dann könnte man auch moderne Sprachfeatures
    > in Office nutzen.

    Aber genau dort werden die weiter VBA unterstützen müssen, da man von den Verwaltungskräften die sich mühsam in VBA_Makros eingearbeitet haben nicht erwarten kann, dass die jetzt C# lernen.
    PHP gibt es ja aus den fast den gleichen Gründen leider auch noch.

  3. Re: Ist ja auch richtig so

    Autor: Akaruso 13.03.20 - 15:54

    Nun, PHP entwickelt sich aber deutlich schneller weiter, wobei - zumindest nach meinem Empfinden - die Richtung klar hin zu einer 'ausgereiften' (oder wie man auch immer sagen möchte) Sprache geht.
    Dies erkennt man auch (manchmal leider) daran, dass immer wieder Dinge zuerst Deprecated und dann gar nicht mehr unterstützt werden. (Ein Projekt auf den aktuellen Stand zu halten ist gar nicht immer so einfach ;-) )

  4. Seh ich komplett anders.

    Autor: n0x30n 13.03.20 - 15:56

    In VB.NET könte man sich zum Beispiel diese dämlich Semikolon am Ende jeder Zeile sparen.
    Was ist das für eine dämliche Syntax in C, die im Regelfall ein Zeichen am Ende einer jeden Zeile erfordert? Das Carriage Return ist doch wohl das deutlich bessere Zeichen um das Befehlsende zu kennzeichnen als das Semikolon.

    Und warum um alles in der Welt gibt man in der C-Syntax den Return Wert vor dem Übergabewert zurück? Das stellt die Logik doch vollkommen auf den Kopf.
    Das macht keine andere Sprachsyntax so und auch in der Mathematik macht man das anders.
    f(x) = y und nicht y = f(x)

    VB: function f (a as integer) as integer
    Pascal: function f (a : integer) : integer
    Haskell: f :: integer a -> integer

    oder die Datentypen werden inferred

    Erlang: f = fun(a) -> ...
    Lisp: (defun f (a) (...))
    F#: let f a = ...
    selbst IO ist logischer aufgebaut: f := method(a,...)

    Kein Mensch kommt auf die dämliche Idee den Rückgabewert zuerst zu definieren und erst danach den Übergabeparameter anzugeben oder auch auf ähnliche Weise Variablen zu definieren.

    Und wer um alles in der Welt möchte eine Cace-Sensitive Programmiersprache?
    Das braucht kein Mensch. Case-Agnostisch, so wie in VB.NET reicht vollkommen. Da schreibt man einfach alles klein und man macht keinerlei Fehler.
    Wer CLR konformen Code schreiben will darf ohnehin keine groß und kleinschreibung mischen. Auch in C# Code nicht, denn sonst wäre er ja nciht mehr kompatibel mit VB.NET Code.

    Und dann dieses nervige Klammern setzen in C # bei Funktionen ohne Parametern. In VB.NET schreibt man einfach weiter und die () werden automatisch ergänzt, wenn nötig.

    Und wo wir schon bei Klammern sind. Die gesamte C-Syntax ist auf die amerikanische Tastatur ausgelegt, wo die { } und das ; deutlich einfacher zu erreichen sind.
    Warum möchte man sich das auf einer deutschen Tastatur antun und sich ständig die Finger brechen, wenn man diese Zeichen eingibt?
    10 fach verschachtelte geschweifte Klammern sind ebenfalls total unübersichtlich }}}}} , während
    end if
    end while
    end function
    end class
    end namespace

    im Gegensatz dazu sehr übersichtlich zeigt, welcher Block gerade geschlossen wird.

    Warum will man die Zeilen ständig von Hand einrücken müssen, wenn man doch eh ein Standard hat, das man einhalten soll?
    VB.NET rückt den Code vollkommen automatisch ein und man hat überhaupt keine andere Wahl den Code anders einzurücken.

    Der Background Compiler von VB.NET ist auch deutlich besser als der von C# und erkennt schon während des Eingebens deutlich mehr Fehler, die bei C# erst beim Compilieren auffallen.

    Ich sehe also überhaupt keine Grund, warum C# so viel besser sein soll als VB.NET.

    Ich sehe allerdings ein, dass es absoluter Blödsinn ist zwei Sprachen zu unterstützen, die quasi das selbe featureset bieten und auf dem selben Framework aufbauen und sich lediglich in ihrer Syntax unterscheiden.
    Das separiert die Entwicklergemeinde, macht das gemeinsame Entwickeln schwieriger, verschlingt Rsourcen bei der Pflege und Weiterentwicklung der Sprachen und so weiter und so fort.
    Allerdings finde ich, dass sich die Leute immer wieder auf die falsche Sprache geeinigt haben, wenn es darum ging.
    Bloß weil Entwickler zuvor bereits eine Sprache in C-Syntax genutzt haben heißt das nicht, dass C# jetzt automatisch die beste Wahl für .NET war.

    Allein die Tatsache, dass C# Case Sensitive ist halte ich für einen riesen Fehler, da es nur unnötiges Fehlerpotenzial darstellt und dieses Feature abersolut keinerlei Vorteile bietet.

  5. Re: Ist ja auch richtig so

    Autor: jimbokork 13.03.20 - 15:57

    stimmt wir sollten endlich alle python benutzen lernen ... scnr

  6. Re: Ist ja auch richtig so

    Autor: jimbokork 13.03.20 - 16:01

    Sie ist vor allem mächtig umfangreich, allein der Standardsatz zur Manipulation von Zeichenketten übertrifft das anderer bei weitem bzw. benötigt man dort spezielle Bibliotheken dritter dafür oder stückelt das rudimentär selbst zusammen. Das Macht sie u.a. Ideal für Webprojekte.



    2 mal bearbeitet, zuletzt am 13.03.20 16:09 durch jimbokork.

  7. Re: Seh ich komplett anders.

    Autor: Akaruso 13.03.20 - 16:30

    Ist wohl einfach geschmackssache!

    Ich fühle mich sehr wohl in der C-Syntax. Sie ist außerdem darauf ausgelegt, den Code kompakt zu halten. Wenn man eine weile mit c/c++ gearbeitet hat, entdeckt man auch die Logik welche z. T. hinter der Syntax steht

    Dieses ständige Beginn, ELSE IF und Endif zu schreiben ist echt auf dauer lästig.
    Aber deine Meinung, dass die deutsche Tastatur nicht so geeignet ist, teile ich.

    Über das Semikolon lässt sich streiten, aber es ermöglicht auch mehrere Anweisungen in einer Zeile zu Schreiben, was ich in Ausnahmefällen auch schon genutzt habe.

    Die Funktionsdeklaration finde ich auch kompakter und übersichtlicher.
    int abc(int xy); habe ich schneller mit dem Auge erfasst wie
    function abc(xy as integer) as integer
    Außerdem ist die Information, welchen Datentyp die Funktion zurückliefert ist in C wichtig sodass die Position vorne gut ist.

    Die Case-Sensitiven Variablennamen sind in der Tat eine Fehlerquelle, vor allem bei Sprachen, bei denen keine Variablendeklaration nötig ist, wie PHP

    Ansonsten möchte ich nicht auf Groß-/Kleinschreibung verzichten. Bei zusammengestzten Namen oder Prefixes (wie das m für Member) erhöht es die Lesbarkeit: auftragsnr <-> AuftragsNr oder mauftrag <-> mAuftrag.

    Ich hätte jetzt noch viel mehr zu schreiben, aber lassen wir es dabei.
    Schlußendlich ist es, wie ich am anfang schon geschrieben habe, Geschmackssache und Gewohnheit.

  8. Re: Seh ich komplett anders.

    Autor: tomate.salat.inc 13.03.20 - 16:52

    n0x30n schrieb:
    --------------------------------------------------------------------------------
    > In VB.NET könte man sich zum Beispiel diese dämlich Semikolon am Ende jeder
    > Zeile sparen.
    > Was ist das für eine dämliche Syntax in C, die im Regelfall ein Zeichen am
    > Ende einer jeden Zeile erfordert? Das Carriage Return ist doch wohl das
    > deutlich bessere Zeichen um das Befehlsende zu kennzeichnen als das
    > Semikolon.
    Nope. Zum einen ermöglicht es dir mehrere Befehle pro Zeile (wovon ich abraten würde) und zum anderen hat nicht jede Zeile ein Semikolon, aber ein Leerzeichen:

    var a = "Hallo"
    + " Welt";

    > Und warum um alles in der Welt gibt man in der C-Syntax den Return Wert vor
    > dem Übergabewert zurück? Das stellt die Logik doch vollkommen auf den
    > Kopf.
    > Das macht keine andere Sprachsyntax so und auch in der Mathematik macht man
    > das anders.
    > f(x) = y und nicht y = f(x)
    Da ist das aber kein Zuweisungsoperator sondern ein Vergleich. Und dann wäre das equivalent: f(x) == y - das geht durchaus.

    Ansonsten folgt es einfach dem Prinzip, dass wir von links nach rechts lesen.

    > VB: function f (a as integer) as integer
    > Pascal: function f (a : integer) : integer
    > Haskell: f :: integer a -> integer

    > Kein Mensch kommt auf die dämliche Idee den Rückgabewert zuerst zu
    > definieren und erst danach den Übergabeparameter anzugeben oder auch auf
    > ähnliche Weise Variablen zu definieren.
    Verstehe dein Problem daran nicht (und erst recht nicht, wie man sich da drüber so aufregen kann).

    > Und wer um alles in der Welt möchte eine Cace-Sensitive
    > Programmiersprache?
    Weil es die Leserlichkeit erhöht. Wobei mir die Konventionen von Java mehr zusagen. Und Code an sich ist nunmal auch Dokumentation.

    > Und wo wir schon bei Klammern sind. Die gesamte C-Syntax ist auf die
    > amerikanische Tastatur ausgelegt, wo die { } und das ; deutlich einfacher
    > zu erreichen sind.
    > Warum möchte man sich das auf einer deutschen Tastatur antun und sich
    > ständig die Finger brechen, wenn man diese Zeichen eingibt?
    Da dramatisierst du jetzt aber schon sehr stark. Die Klammern gehen einem nach der Zeit locker von der Hand. Ich tippe mehr als genug jeden Tag davon und hab absolut kein Problem damit - funktioniert sogar ohne Blick auf die Tastatur ohne Problem.

    > 10 fach verschachtelte geschweifte Klammern sind ebenfalls total
    > unübersichtlich }}}}} , während
    > end if
    > end while
    > end function
    > end class
    > end namespace
    Wenn du in deinem Code 10 Ebenen drin hast, dann hast du ganz andere Probleme als Klammern.

    > im Gegensatz dazu sehr übersichtlich zeigt, welcher Block gerade
    > geschlossen wird.
    In ordentlichem Code ist das absolut kein Problem. Wenn das zu einem Problem wird, dann hat der Code ein refactoring notwendig.

    > Warum will man die Zeilen ständig von Hand einrücken müssen, wenn man doch
    > eh ein Standard hat, das man einhalten soll?
    > VB.NET rückt den Code vollkommen automatisch ein und man hat überhaupt
    > keine andere Wahl den Code anders einzurücken.
    Du weißt schon, dass es auch für andere Sprachen Code-Formatter gibt?

  9. Re: Ist ja auch richtig so

    Autor: sambache 13.03.20 - 17:12

    jimbokork schrieb:
    --------------------------------------------------------------------------------
    > Sie ist vor allem mächtig umfangreich, allein der Standardsatz zur
    > Manipulation von Zeichenketten übertrifft das anderer bei weitem bzw.
    > benötigt man dort spezielle Bibliotheken dritter dafür oder stückelt das
    > rudimentär selbst zusammen. Das Macht sie u.a. Ideal für Webprojekte.

    Also sobald man Unicode benutzt (im web immer), kann man in PHP auch keine der internen Methoden verwenden.
    Eigentlich sind diese nicht Unicode tauglichen Stringfunktionen von PHP das beste Argument gegen PHP.

  10. Re: Seh ich komplett anders.

    Autor: AllDayPiano 13.03.20 - 17:13

    Das meiste, das Du anmerkst, ist schlichtweg Geschmacks- und Gewohnheitssache, wobei Du damit schon auch recht hast.

    Es hat Auslegungen in beide Richtungen. Die Ultimo Ratio gibt's halt leider nicht. Oder anders: Des einen Leid ist des anderen Freud.

    Dass C# case-sensitive ist, finde ich persönlich sogar gut. Denn wenn man sich an die Coding Guidelines hält, kann man damit auf den ersten Blick erkennen, was private und was öffentliche Funktionen sind. Wenn man allerdings sein zeug runterrotzt - vollkommen egal, ob andere das lesen können müssen - dann ist das natürlich eine riesige Fehlerquelle.

  11. Re: Ist ja auch richtig so

    Autor: Akaruso 13.03.20 - 17:19

    Nicht mehr!
    Es gibt inzwischen die Stringfunktionen auch in der Multibyte-Variante (mit Prefix mb_ )
    z. B. mb_strlen().

    (Der Begriff Multibyte bezieht sich vermutlich darauf, dass in UTF8 alle Zeichen außerhalb von ASCII mit mehr als einem Byte codiert sind)

  12. Re: Seh ich komplett anders.

    Autor: n0x30n 13.03.20 - 17:43

    > Ist wohl einfach geschmackssache!

    Das schon, aber es gibt Sachen, die sind einfach besser.
    VB.NET verlangt zum Beispiel nur im Ausnahmefall, wenn man eine Codezeile auf mehrere Zeilen verteilen will, dass man am Ende ein "_"anhängen muss.
    In C# muss hingegen im Regelfall das ";" angehängt werden und nur im Ausnahmefall kann das Zeichen weggelassen werden.

    Mittlerweile kann in VB.NET sogar komplett auf den "_" verzichtet werden und der Compiler merkt selbst, ob der Code auf eine oder mehrere Zeilen aufgeteilt ist.

    Ob eine kompaktere Schreiweise immer besser ist, ist auch fraglich.
    Wenn dem so wäre würden wir unsere Variablen und Methodennamen ja auch a,b,c nennen.
    Dem ist aber nicht so. Wir haben mittlerweile gemerkt, dass Code gut leserlich sein sollte und möglichst wenig kryptisch.

    > Wenn man eine weile mit c/c++
    > gearbeitet hat, entdeckt man auch die Logik welche z. T. hinter der Syntax
    > steht

    Naja. Eine Logik steckt hinter jeder Syntax, denn sonst könnte sie der Parser ja nicht anlysieren.
    Ob die Logik allerdings für den Parser oder für den Menschen besser geeignet ist, dass ist hier die Frage.
    Die C-Syntax ist meiner Meinung nach eher dafür geschaffen worden um von Parsern einfacher gelesen werden zu können, während die Basic Syntax das ziel hatte von Menschen einfacher verstanden werden zu können.

    > Dieses ständige Beginn, ELSE IF und Endif zu schreiben ist echt auf dauer
    > lästig.

    Die IDE tut das ja für einen und wie ich bereits erwähnte finde ich, dass man Worte sogar schneller tippen kann, als die umständliche {
    Ich tippe "If a=b th" drücke Enter und er schreibt das "en" und das end if.
    Vorteil ist auch beim If brauche ich keine ( ), die ebenfalls sehr umständlich zu tippen sind.
    Seit ich auf C# umsteigen musste bin ich jedenfalls deutlich langsamer geworden was die Geschwindigkeit des codens angeht. Einzig und allein, weil ich all die Klammern und Sonderzeichen eingeben muss.
    VB.NET ersetzt dir übrigens auch die end-Texte automatisch, wenn du das Konstrukt am Anfang änderst. Das brauchst du nicht manuell am Ende editieren.


    > Ansonsten möchte ich nicht auf Groß-/Kleinschreibung verzichten. Bei
    > zusammengestzten Namen oder Prefixes (wie das m für Member) erhöht es die
    > Lesbarkeit: auftragsnr <-> AuftragsNr oder mauftrag <-> mAuftrag.

    Das ist klar.
    VB.NET ist nicht Case-insensitive, sondern Case-Agnostisch, so wie das Dateisystem von Windows zum Beispiel.
    Das heißt, dass du die Variable oder die Methode mit Groß- und Kleinschreibung deklarierst und anschließend kannst du die immer klein eingeben, aber die IDE formatiert sie dir dann so um, wie du sie deklariert hast.

    > Ich hätte jetzt noch viel mehr zu schreiben, aber lassen wir es dabei.
    > Schlußendlich ist es, wie ich am anfang schon geschrieben habe,
    > Geschmackssache und Gewohnheit.

    Jep und das ist dann auch der Grund, warum wir jetzt bei der C-syntax bleiben.
    Ich finde es ja ganz gut, dass wir endlich eine der beiden Sprachen streichen. Es ist halt nur schade, dass es VB.NET ist.
    Da ist in meiner Firma aber auch schon auf C# wechseln musste habe ich mich ohnehin schon seit längerem damit abgefunden.

  13. Re: Seh ich komplett anders.

    Autor: n0x30n 13.03.20 - 18:34

    > Nope. Zum einen ermöglicht es dir mehrere Befehle pro Zeile (wovon ich
    > abraten würde) und zum anderen hat nicht jede Zeile ein Semikolon, aber ein
    > Leerzeichen:
    >
    > var a = "Hallo"
    > + " Welt";

    Das kann VB.NET natürlich auch. Alles ohne Semikolon und trotzdem über mehrere Zeilen.
    dim a = "Hallo" +
    " Welt"

    Man braucht das Semikolon nicht. Das ist absolut überflüssig. Ein Compiler kann absolut selbstständig erkennen, ob der Befehl in der Zeile endet oder in der nächsten Zeile weitergeht. zumindest der in VB.NET


    > > f(x) = y und nicht y = f(x)
    > Da ist das aber kein Zuweisungsoperator sondern ein Vergleich. Und dann
    > wäre das equivalent: f(x) == y - das geht durchaus.

    Das sollte keine Programmiersprache darstellen, sondern die schreibweise, die man in der Mathematik verwendet. Sin(x) = y. So schreibt man für gewöhnlich die Funktionen auf und nicht umgehert.


    > Ansonsten folgt es einfach dem Prinzip, dass wir von links nach rechts
    > lesen.

    Dann hast du glaube ich ncoh nciht analysiert, was du wirklich tust, wenn du eine Methode definierst.
    Schritt 1) Was tut sie? -> Name ausdenken.
    Schritt 2) Was übergebe ich ihr -> Übergabeparameter festlegen
    Schritt 3) Was liefert sie mir zurück. -> Rückgabeparameter bestimmen

    Ich kann nur wissen, was sie mir zurückliefert, wenn ich weiß, was ich zuvor reingegeben habe. Ergo muss dieser Parameter als letzetes kommen und nicht vor dem Übergabeparameter.

    Du liest also nicht von links nach rechts. Du musst dir also schon alles vorher im Kopf zurechtgelegt haben, bevor du überhaupt anfangen kannst zu schreiben.

    Das Gleiche gilt übrigens auch bei Variablendeklarationen.


    > Weil es die Leserlichkeit erhöht. Wobei mir die Konventionen von Java mehr
    > zusagen. Und Code an sich ist nunmal auch Dokumentation.

    Code in VB.NET ist auch Groß und Klein geschrieben.
    Du musst das nur nicht immer wieder von Hand vornehmen. Du schreibst alles klein und die IDE formatiert die Variablen und die Methodennamen so um, wie du sie deklariert hast.
    deklarierst du sie mit "dim myLocalVar", dann ersetzt die IDE "mylocalvar" immer durch "myLocalVar". Der code ist also immer einheutlich und schön ordentlich und du kannst dich nie vertippen. Du brauchst auf nichts achten.

    > Da dramatisierst du jetzt aber schon sehr stark. Die Klammern gehen einem
    > nach der Zeit locker von der Hand. Ich tippe mehr als genug jeden Tag davon
    > und hab absolut kein Problem damit - funktioniert sogar ohne Blick auf die
    > Tastatur ohne Problem.

    if ( a == b ) {

    enthält 5 Sonderzeichen, die du nur über Shift und Alt+Gr erreichen kannst.

    if a=b then

    enthält nur eines. Was meinst du was davon schneller geht?
    Leerzeichen vor und hinter dem Gleichheitszeichen würde VB mir auch einfügen. Macht C# per Default auch nicht, weil C#-ler gerne jedes Leerzeichen von Hand eintippen.


    > Wenn du in deinem Code 10 Ebenen drin hast, dann hast du ganz andere
    > Probleme als Klammern.

    Also 5 habe ich dir ja schon mal aufgezeigt und die enthielten nur ein If innerhalb einer While Schleife in einer Methode in einer Klasse in einem Namespace. Das ist ganz normal.
    10 ist natürlich ein Extremfall, aber ich wollte es hier auch mal als Extrembeispiel ansetzen wo es mit Klammern wirklich absolut unübersichtlich wird und man mit VB.NET atsächlich noch durchsteigen würde.
    Die Situation kann in großen Projekten aber durchaus auch mal vorkommen.

    > In ordentlichem Code ist das absolut kein Problem. Wenn das zu einem
    > Problem wird, dann hat der Code ein refactoring notwendig.

    Kein gutes Argument um auf ein Feature zu verzichten, dass die Übersicht verbessert, oder?
    Wenn der Code optimal ist, dann braucht man es nicht. Von daher hat die C-Syntax es nicht nötig.

  14. Re: Seh ich komplett anders.

    Autor: n0x30n 13.03.20 - 18:49

    > Dass C# case-sensitive ist, finde ich persönlich sogar gut. Denn wenn man
    > sich an die Coding Guidelines hält, kann man damit auf den ersten Blick
    > erkennen, was private und was öffentliche Funktionen sind. Wenn man
    > allerdings sein zeug runterrotzt - vollkommen egal, ob andere das lesen
    > können müssen - dann ist das natürlich eine riesige Fehlerquelle.

    in VB.NET hält man sich natürlich auch an Guidelines.
    Wenn ich die Variable mit "Private _myPrivateVar as String" oder "Public MyPublicVar as String" deklariere, dann werden die anschließend von der IDE auch so umformatiert, wenn ich die komplett klein in der IDE eintippe.
    Ich muss mich nicht mehr um Groß- und Kleinschreibung kümmern und mache auch keine Fehler mehr.

    Auch Keywords und all das kann ich einfach alles kleinschreiben. if wird zu If, tostring wird zu ToString() und so weiter und so fort.
    VB.NET sieht im Endeffekt zwar sehr verbos aus, aber erstellen lässt sich das alles sehr schnell und sehr leicht, da sich das ratz fatz heruntertippen lässt.
    Das Einzige was ich nicht machen kann ist eine andere Variable mit dem gleichen Namen aber anderer Schreibweise anlegen. Ich finde aber, dass das eh schlechter Stil ist und nicht gemacht werden sollte.

  15. Re: Seh ich komplett anders.

    Autor: gadthrawn 13.03.20 - 18:57

    n0x30n schrieb:
    --------------------------------------------------------------------------------
    > In VB.NET könte man sich zum Beispiel diese dämlich Semikolon am Ende jeder
    > Zeile sparen.

    Das Seminar ist nur nicht am Ende einer Zeile, sondern am Ende einer Anweisung.

    Das macht manches logischer
    for(Initialisierung; Bedingung; Iterative)
    Befehl;

    Zeigt recht deutlich, das da 4 Befehle abgearbeitet werden.

    > Was ist das für eine dämliche Syntax in C, die im Regelfall ein Zeichen am
    > Ende einer jeden Zeile erfordert? Das Carriage Return ist doch wohl das
    > deutlich bessere Zeichen um das Befehlsende zu kennzeichnen als das
    > Semikolon.

    Ein unsichtbares Zeichen als Steuerzeichen zu verwenden ist eigentlich immer bescheiden.
    Es gibt durchaus auch Sprachen ala den Quatsch der in Silkperformer ist bei der Leerzeichen oder Tab am Anfang dazu führt, das etwas zu einem anderen Programmteil gehört.

    Das Semikolon kostet mittlerweile von Speicher her gesehen so gut wie nichts, macht aber gerade lange Anweisungen lesbar.


    > Und warum um alles in der Welt gibt man in der C-Syntax den Return Wert vor
    > dem Übergabewert zurück? Das stellt die Logik doch vollkommen auf den
    > Kopf.

    ? Macht man nicht.

    > Das macht keine andere Sprachsyntax so und auch in der Mathematik macht man
    > das anders.
    > f(x) = y und nicht y = f(x)
    >
    > VB: function f (a as integer) as integer
    > Pascal: function f (a : integer) : integer
    > Haskell: f :: integer a -> integer
    >
    > oder die Datentypen werden inferred
    >
    > Erlang: f = fun(a) -> ...
    > Lisp: (defun f (a) (...))
    > F#: let f a = ...
    > selbst IO ist logischer aufgebaut: f := method(a,...)

    Oh wenn du bei mistigen Sprachen bist: didaktisch ist es einfacher. Das ist aber keine Rückgabe.


    > Kein Mensch kommt auf die dämliche Idee den Rückgabewert zuerst zu
    > definieren und erst danach den Übergabeparameter anzugeben oder auch auf
    > ähnliche Weise Variablen zu definieren.

    Nicht?

    For indexA 1 To 3
    Befehl
    Next

    Dim currentDate = Datetime.Now

    100% das gleiche Prinzip. Nur bei den c ähnlichen ist es durchgezogen.

    > Und wer um alles in der Welt möchte eine Cace-Sensitive
    > Programmiersprache?
    > Das braucht kein Mensch. Case-Agnostisch, so wie in VB.NET reicht
    > vollkommen. Da schreibt man einfach alles klein und man macht keinerlei
    > Fehler.

    wER mÖChte DAUerND gRoẞ unD KLEin WecHseLn?


    > Wer CLR konformen Code schreiben will darf ohnehin keine groß und
    > kleinschreibung mischen. Auch in C# Code nicht, denn sonst wäre er ja nciht
    > mehr kompatibel mit VB.NET Code.

    Quatsch.

    > Und dann dieses nervige Klammern setzen in C # bei Funktionen ohne
    > Parametern. In VB.NET schreibt man einfach weiter und die () werden
    > automatisch ergänzt, wenn nötig.

    Je nach Entwicklungsumgebung + Tools bekommst du die Klammern bei c# gratis dazu.

    > Und wo wir schon bei Klammern sind. Die gesamte C-Syntax ist auf die
    > amerikanische Tastatur ausgelegt, wo die { } und das ; deutlich einfacher
    > zu erreichen sind.
    > Warum möchte man sich das auf einer deutschen Tastatur antun und sich
    > ständig die Finger brechen, wenn man diese Zeichen eingibt?
    > 10 fach verschachtelte geschweifte Klammern sind ebenfalls total
    > unübersichtlich }}}}} , während
    > end if
    > end while
    > end function
    > end class
    > end namespace
    >
    > im Gegensatz dazu sehr übersichtlich zeigt, welcher Block gerade
    > geschlossen wird.

    Dann wäre eventuell Cobol eine Sprache für dich, da labbert man gefühlt millionenmal das gleiche

    > Warum will man die Zeilen ständig von Hand einrücken müssen, wenn man doch
    > eh ein Standard hat, das man einhalten soll?

    Musst du nicht. Geht normal automatisch.

    > VB.NET rückt den Code vollkommen automatisch ein und man hat überhaupt
    > keine andere Wahl den Code anders einzurücken.

    Liegt aber teuer an Problemen in vb

    > Der Background Compiler von VB.NET ist auch deutlich besser als der von C#
    > und erkennt schon während des Eingebens deutlich mehr Fehler, die bei C#
    > erst beim Compilieren auffallen.
    ? Ist der gleiche.

    > Ich sehe also überhaupt keine Grund, warum C# so viel besser sein soll als
    > VB.NET.
    >
    > Ich sehe allerdings ein, dass es absoluter Blödsinn ist zwei Sprachen zu
    > unterstützen, die quasi das selbe featureset bieten und auf dem selben
    > Framework aufbauen und sich lediglich in ihrer Syntax unterscheiden.
    > Das separiert die Entwicklergemeinde, macht das gemeinsame Entwickeln
    > schwieriger, verschlingt Rsourcen bei der Pflege und Weiterentwicklung der
    > Sprachen und so weiter und so fort.
    > Allerdings finde ich, dass sich die Leute immer wieder auf die falsche
    > Sprache geeinigt haben, wenn es darum ging.
    > Bloß weil Entwickler zuvor bereits eine Sprache in C-Syntax genutzt haben
    > heißt das nicht, dass C# jetzt automatisch die beste Wahl für .NET war.
    >
    > Allein die Tatsache, dass C# Case Sensitive ist halte ich für einen riesen
    > Fehler, da es nur unnötiges Fehlerpotenzial darstellt und dieses Feature
    > abersolut keinerlei Vorteile bietet.

  16. Re: Ist ja auch richtig so

    Autor: Anonymer Nutzer 13.03.20 - 20:10

    AllDayPiano schrieb:
    -------------------------------------------------------------------------------
    > Eigentlich sollte MS VB komplett sterben lassen, und nurnoch C# forcieren
    > (konsequent über alle Belange). Dann könnte man auch moderne Sprachfeatures
    > in Office nutzen.

    Ich glaube ehrlich gesagt, dass das gleiche Schicksal in den nächsten 10 Jahren auch C# zuteil wird. Die Nachfrage an C# Entwicklern sinkt und auch die Gehälter. Unterschied zu VB wird dann lediglich sein, dass es Open Source noch weiter entwickelt wird. Da ist MS mit . Net Core die richtigen Schritte gegangen allerdings ist da kaum Bewegung drin wenn man sich mal das Github Repository anschaut. Sobald MS dann nur noch Cloud macht, wird das ein niesche dasein Fristen wie heute Perl6. Für Cloud und Microservices braucht keiner C#. Dafür gibt es modernere Alternativen wie Go, Rust etc. und wenn man unbedingt do ein fettes framework braucht für irgendeine grosse Applikation, dann nehmen die meisten eher Java.

    .Net Core war ein nice try. Hat sich aber einfach überholt.



    1 mal bearbeitet, zuletzt am 13.03.20 20:13 durch nweeiqr.

  17. Re: Seh ich komplett anders.

    Autor: Deff-Zero 13.03.20 - 21:53

    n0x30n schrieb:
    --------------------------------------------------------------------------------

    > Die C-Syntax ist meiner Meinung nach eher dafür geschaffen worden um von
    > Parsern einfacher gelesen werden zu können, während die Basic Syntax das
    > ziel hatte von Menschen einfacher verstanden werden zu können.

    C ist sogar eher schwer zu parsen, weil man im Prinzip erst eine Analyse laufen
    lassen muß, die erst alle Typnamen aufsammelt, damit man damit dann Casts
    von geklammerten Ausdrücken unterscheiden kann.

  18. Re: Seh ich komplett anders.

    Autor: schnedan 13.03.20 - 23:25

    cool, ein Spezialist!

    ich freu mich schon auf die neue voll geniale Sprache die auch noch in 50 Jahren im Einsatz ist und wo noch 50 Jahre alter Code auf modernen Computern läuft.

  19. Re: Seh ich komplett anders.

    Autor: jimbokork 14.03.20 - 03:20

    Du gehst schon von viel Wohlfühlunterstützung aus, geh mal an Systeme bei denen du quasi keine IDE hast und auch keinen Code über einen Datenträger oder Link von deinem Gerät einspielen kannst oder darfst, du hast dort einen Editor der Wahl des Betreibers und sonst nur die Kommandozeile, wenn du Glück hast etwas erweiterbares wie VI ... nur zum erstellen einer IDE wurdest du nicht engagiert ...

    C wurde auch nicht entworfen um möglichst leserlich im Quellcode zu sein, sondern afaik um gleiche Spiele möglichst schnell auf unterschiedliche Automaten portieren zu können.

  20. Re: Ist ja auch richtig so

    Autor: jimbokork 14.03.20 - 03:35

    ich hatte eigentlich nie ernsthafte probleme damit, kann aber auch sein, dass die webserver dahingehend freundlich eingestellt waren und das php modul vom apache gesteckt bekam welche codierung bei request daten anlag ... aus seiner db weis man das selbst und codiert entsprechend um.



    1 mal bearbeitet, zuletzt am 14.03.20 03:37 durch jimbokork.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. ED Netze GmbH, Rheinfelden
  2. LGC Standards GmbH, Wesel
  3. über duerenhoff GmbH, Raum Berlin
  4. Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH, Eschborn

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (aktuell u. a. Seagate Backup Plus 8TB für 139€, Roccat Khan Pro für 63,99€ (inkl...
  2. 11,19€
  3. (aktuell WISO steuer:Sparbuch 2020 ab 11,19€ und Amazon-Geräte reduziert, z. B. Kindle, Echo...
  4. (u. a. Tom Clancy's Ghost Recon Wildlands für 18,99€, Oriental Empires für 5,99€, Crowntakers...


Haben wir etwas übersehen?

E-Mail an news@golem.de