Habt ihr euch schonmal gefragt wieso...

[af0815]

Ideal wäre wenn da steht
"du hast nen fehler gemacht in zeile xy wahrscheinlich ist es ein longint, es kann aber auch ein schotint seien, was sollen wir tun?"
"nix"
"shortint"
"longint"
...

Ich wiss es klingt hart, aber mir ist eine einfache klare Fehlermeldung lieber als ein Ratespiel. Ich möchte ja Software kompilieren und nicht mit Eliza eine Doppelconferance halten.
Denn den (Fehler-)Text lesen, verstehen und dann richtig handeln musst, so sehe ich da keinen wesentlichen Unterschied. Nur das in dem Beispiel oben, ganz einfach Lotto gespielt wird - der DAU nimmt dann je nach Laune 1,2 oder x. Denn wenn man nicht versteht was der Kompiler meint, der fängt an zu raten.

Denn wenn schon wahrscheinlich in der Fehlermeldung drinnen steht, so kann 'wahrscheinlich' nur Murks dahinter sein.

Steht dort drinnen-> Inkompatible Zuweisung in Zeile xy <- So ist das klar und eindeutig und kein 'vielleicht' Gewäsch, das nur vom Problem abhält.

[Christian]

Ich sehe das genauso, die fehlermeldungen vom FPC sind meisst sehr aussagekräftig.

[Socke]

Warum schreiben wir denn in ObjectPascal und nicht in (Visual)Baisc?
In VB kann man einem Bild einen Dateinamen zuweisen in ObjectPascal nicht
...
Man kann ja mal einem VB-Programmierer versuchen Pascal zu erklären... der wird an der Typensicherheit verzweifeln.
Und der Pascal-Programmierer fragt sich, wie es möglich sein kann mit VB-Programme, die auch noch funktionieren, zu schreiben ohne alles von Hand zu machen.

MfG Socke
P.S. zum Thema: eine noch weiter ausgebaute Code-Vervollständigung erzeugt auf Dauer nur VIVA- und MTV-Zuschauer

[marcov]

ich bin auch zufrieden, trotzdem wenn da steht
Da steht was vom Typ string , hier wird allerding integer benötigt.
Wen Lazarus doch schon soviel weis sollte man auch ne möglichkeit haben das der das einfach in integer umwandelt.

Gut. Und was soll es mit "integer+string" machen? Da an alle Parameter wo man integer nutzen kann, kann man dann auch Expressionen die in Theorie bis Integer Reduzierbar sein geben. Und dass wird sehr schnell undurchsichtig.

Mit Autoconversion sind die einfache Fälle nie das Problem. Das Problem sind die schwierige Fälle, und den unterschied zwischen einfache- und schwierige Fälle _automatisch_ machen.

[pluto]

Gut. Und was soll es mit "integer+string" machen?

Ganz einfach: Den Interger den String hinzufügen. Also sowas:
IntTostr(IntVar) + 'Mein langer langer Text' Was würdest du denn hier erwarten ?

[af0815]

Man kann ja mal einem VB-Programmierer versuchen Pascal zu erklären... der wird an der Typensicherheit verzweifeln.
Und der Pascal-Programmierer fragt sich, wie es möglich sein kann mit VB-Programme, die auch noch funktionieren, zu schreiben ohne alles von Hand zu machen.

variant geht in pascal auch (War NICHT sehr ernst gemeint)

[monta]

IntTostr(IntVar) + 'Mein langer langer Text' Was würdest du denn hier erwarten ?

es kann genau so gut ein integer + StrToInt(integer) sein sobald es um Typen geht, ist das nie eindeutig aufzulösen.

bei fehlenden ; usw. sieht es vielleicht anders aus.

[Euklid]

Und der Pascal-Programmierer fragt sich, wie es möglich sein kann mit VB-Programme, die auch noch funktionieren, zu schreiben ohne alles von Hand zu machen.

MOMENT: Du Vergleichst gerade Pascal - also eine _saubere_ Programmiersprache- mit VB. Das kann nicht gut gehen.

Mit VB kann man zwar sehr leicht kleine Programme erstellen. Was hier das Programmieren erleichtert, erschwert aber das Programmieren großer Projekte. Wenn man sich mehrere tausend Zeilen große Projekte ernsthaft widmet, lernt man die strenge Typenunterscheidung, die Befehlstrennung durch Semikolon, den Unterschied zwischen vergleichendem und zuweisendem Gleich erst richtig schätzen! Diese Dinge erleichtern das Debuggen und machen den Code leichter wart- und lesbar. Pascal ist an dieser Stelle also außerordentlich zweckmäßig und vorallem sauber.

Ich finde immer, Pascal ist das goldene Mittelmaß: Es ist zum Einen eine vollständige, saubere Programmiersprache, mit der sich relativ systemnah programmieren lässt (im Gegensatz zu interpretierenden Sprachen). Zum Anderen wurde die Sprache aus einem didaktischen Konzept heraus entwickelt - sprich, sie ist relativ einfach zu erlernen. Sie eint damit die Vorteile von Basic und C.

Viele Grüße, Euklid

[af0815]

Mit VB kann man zwar sehr leicht kleine Programme erstellen. Was hier das Programmieren erleichtert, erschwert aber das Programmieren großer Projekte. Wenn man sich mehrere tausend Zeilen große Projekte ernsthaft widmet, lernt man die strenge Typenunterscheidung, die Befehlstrennung durch Semikolon, den Unterschied zwischen vergleichendem und zuweisendem Gleich erst richtig schätzen! Diese Dinge erleichtern das Debuggen und machen den Code leichter wart- und lesbar. Pascal ist an dieser Stelle also außerordentlich zweckmäßig und vorallem sauber.

Einspruch: VB ist (MITTLERWEILE) eine vollwerige Programmiersprache, auf die die obigen Argumente nicht mehr zutreffen. Besonders dann wenn man die Überprüfungen auch aktiviert hat und nicht im 'lazy' Stil arbeitet. Bei älterne Version stimme ich zu den obigen Argumenten schon zu (Ist aber Geschichte). Da haben die Leute mit VB am meisten umlernen müssen.

Es ist mittlerweile ehr eine Frage des Stils geworden ob eine Programmiersprache geeignet ist oder nicht. Alle modernen Sprachen stellen ähnliche mächtige Werkzeuge zur Verfügung. Ich kann auch in Pascal kranke Programme schreiben, dazu benötige ich nicht VB oder C oder ....

[marcov]

Gut. Und was soll es mit "integer+string" machen?

Ganz einfach: Den Interger den String hinzufügen. Also sowas:
IntTostr(IntVar) + 'Mein langer langer Text' Was würdest du denn hier erwarten ?

Es ist "integer+string" nicht "string+integer". Also logischer wäre um der String nach integer zu konvertieren und zu addieren.

Der Punkt dieser Geschichte ist das wann auto konvertiert, es plötzlich mehrere Pfade gibt, die schnell undurchsichtig werden.

Es ist einfach zu zagen "in dieser einfachen Fall sollte _dies_ passieren". Aber das ist nicht das Problem einer Computersprache. Der soll _immer_ definiert sein (und bestens soll ein Programmierer das verhalten ein bisschen ahnen können)

Sie auch http://www.freepascal.org/faq.var#extensionselect" onclick="window.open(this.href);return false;

[martin_frb]

Auch bei fehlendem Semikolon ist das alles, nur nicht eindeutig:

if a < 0 then a := 1
memo1.lines.add("---");

Was soll nun hinter die "1" ?
Zur Auswahl stehen:
";"
"else"
"+" (add gibt einen integer zurück)
oder sollte die "1" entfernt werden ("a := \n memo1.lines.add()"
oder es könnte aus Versehen eine ganze Zeile gelöscht worden sein "\n else a := a * 2;"

[KOBOLD Messring GmbH]

Das schönste am fehlenden Semikolon ist doch dieser Fall:
Der Cursor steht am ENDE (von hunderten Zeilen Code) am End. (Punkt !) und meckert: "¡Semicolon expected!"
Also fehlt _irgendwo_ ein End; (mit Semikolon, ¿vielleicht von einem For.. einem While.. dem 25sten geschachtelten if-then-else Konstrukt, einer ganzen Nested-Function, ... ?
Also einfach unmöglich für den Lazarus-Syntax-checker dies in einen vernünftigen Vorschlag - geschweige denn in eine Auto-Korrektur - umzuwandeln. Ich finde die Fehleranzeige (und Hinweise) sehr gut, ¡alle Achtung an die Programmierer vom Lazaraus!
Ich muss (leider) viel mit php programmieren, das ist eine Gülle im Vergleich zu Pascal: da gibts nur erstmal nur Variant, da kann ich in einer if-Bedingung einem (vermeintlichen) Integer einen String zuweisen (der z.B. den Char ('0'), ascii=48) enthält (und es wird immer die "then"-Anweisung ausgeführt). Wenn man das dann wieder ausgeben würde, wird ein Leerstring erzeugt, denn die Zahl 0 ist ja nix...
Da muss man so einen Murks bauen: if ($MeineVar == 0) { echo '0' } else { echo $MeineVar }; (zur Ausgabe, nicht mein Vergleichsbeispiel)
Da lernt man die Pascal-Sprache lieben, da _kann_ einem so ein Murks gar nicht passieren.

[Hitman]

Naja das mit dem fehlenden "end" ist ein guter Punkt. Da könnte man meines Erachtens schon eine Art "guessing" einbauen, basierend auf der Indention des Quelltextes. Klar, ist das auch keine perfekte Lösung (die gibt es nicht), aber es würde weitaus mehr Fälle abdecken als im Moment ... wer nämlich schlecht/gar nicht einrückt, weiß soviel wie vorher ("irgendwo fehlt ein 'end'"). Wer aber ordentlich einrückt, kriegt dann eine ganz gute Abschätzung "hier an dieser Stelle könnte das fehlende 'end' hingehören".

[pluto]

@KOBOLD Messring GmbH
Wer so ein Code erzeugt sollte sich nicht wundern, wenn er da Syntax Fehler einbaut und sie nicht findet. Der Code sollte immer übersichtlich sein, dann ist ein fehlendes ; sofort erkennbar wobei was ich viel lustiger finde ist: Wenn er ein End vermisst.

[Targion]

Das ist der Compilerfehler, den ich am hässlichsten finde: Man hat eine verschachtelte Funktion und der Compiler sagt, dass ein "End" fehlt. Nur: Bei welcher Bedingung/Schleife? Und welches End gehört zu welchem begin? Lazarus 0.9.27 färbt zusammengehörige begin- und ends zum Glück neuerdings ein, damit ist dieses Problem gelöst.