Man liest hier oft über "nicht ganz so optimale IDE", schreiben hier, brennen im Avr-Studio dort und sonstigen diversen Unzulänglichkeiten. Wenn man sich diesen Bascom-"Compiler" ernsthaft näher anschaut muss man bezweifeln das der Entwickler überhaupt etwas von richtigem Compilerbau versteht. Beschränkte Argumente und Expressions, keine Optimierungen, undurchdachte Semantik uvm. Die IDE könnte man auch leider schon vor 10 Jahren als völlig überholt bezeichnen. Darf man ein solch kostenpflichtiges Produkt als "der beste Basiccompiler" bezeichnen? Ich frage mich ernsthaft, wieso man sich das antut. Anstatt sich damit herumzuquälen könnte man ja gleich C programmieren im Avr-Studio, möglicherweise ist das zu einfach?
Natürlich ist der Bascom der "beste" Basic-Compiler für die Kleinen AVR Controler, oder kennst Du einen besseren?
Ahh, mal wieder ein Bascom-Bashing Thread. Ich hol grad mein Popcorn. C ist ja so gut und ausgereift, da müssen wir doch jetzt mal über den Tellerand schauen und die anderen IDEs heruntermachen. Da fühlt man sich auch gleich wieder besser.
Programmierer schrieb: > C ist ja so gut und ausgereift, da müssen wir doch jetzt mal über den > Tellerand schauen und die anderen IDEs heruntermachen. Da fühlt man sich > auch gleich wieder besser. C ist viel besser als dieses komische Bascom! nur mülL! aber ich mag gerne wow!
Ich wollte gerade schreiben, dass es nicht zum Schwanzvergleich BASCOM-C kommen wird, da ist auch schon der erste da. Also: Es wird nicht weiter ausarten. Jede Programmiersprache hat ihre Berechtigung und Flame Wars werde ich im Keim ersticken.
Ist aber alles kein Basic ;-) Ps.: Sehe gerade, es gibt ja auch noch mikroBasic. Niemand ist gezwungen Bascom zu benutzen, es gibt genügend Alternativen, da ist für jeden etwas dabei.
Bascom tue ich mir an, wenns schnell gehen soll. Ein Pin wackeln lassen, ein paar Zeilen aufs LCD und den ADC auswerten und über die serielle was rausschieben: Alles zeitunkritische Sachen, die man mal schnell "hinrotzen" kann:
1 | Config Lcdpin = Pin , Db4 = Porta.4 , Db5 = Porta.5 , Db6 = Porta.6 , Db7 = Porta.7 , E = Portc.7 , Rs = Portc.6 |
2 | Config Lcd = 16 * 2 |
3 | |
4 | Cls |
5 | Lcd "Hallo Welt!" |
(aus der Hilfe kopiert) Es gibt des weiteren gute Befehle für I²C, 1Wire, etc... Wo Licht ist, ist auch Schatten: Man muss sich sehr selbstdisziplinieren um Code zu schreiben, den man in einem halben Jahr nochmal lesen kann. Es gibt keine Möglichkeit Sachen wie a=b*(c+d) zu schreiben. Statt dessen gibt es ein: a=c+d : a=a*b (Nach einem halben Jahr noch klar was gemeint ist?) Wenn man das Hex-File sich dann mal im AVR Studio ansieht, wird es gruselig. Es werden grundsätzlich bei jedem Funktionsaufruf alle(!) Register gerettet. --- Fürs schnelle Bitschubsen nehme ich Assembler. Bascom wenns schnell bunt werden soll und ganz toll blinkt... ;) ...und C? Naja...weniger Schreibarbeit als die selbe Funktion in Assembler und mehr Schreibarbeit als die selbe Funktion in Bascom... ;) Tja...bin ein Kind der 80er: Homecomputer mit Basic und Assembler. Und auf dem PC dann noch Turbo Pascal. ;) Irgendwie wird man dann mit C nicht so richtig warm. Mirko
Hendrik schrieb: > Wenn man sich diesen Bascom-"Compiler" ernsthaft näher anschaut muss man > bezweifeln das der Entwickler überhaupt etwas von richtigem Compilerbau > versteht. Beschränkte Argumente und Expressions, keine Optimierungen, > undurchdachte Semantik uvm. ich denke der TO zielt hier nicht auf "was ist besser" ab, sondern einfach der realistischen Frage was das Teil eigentlich sein soll, denn ein Compiler ist es nicht. Rein technisch würde ich hier eher dazu neigen zu sagen es handelt sich um einen Makroprozessor. Analysieren wir doch mal diesen sogenannten "Compiler": - er versteht keine Ausdrücke, sondern nur 3-Argument-Funktionen, dies betrifft Bedingungen genauso wie arithmetische Operationen
1 | if (a+b)*3^2 and funktion1(a*3,b/7) then |
führt zu einer Fehlermeldung, jede billige Scriptsprache kann das. - selbst diese Argumente müssen also einzelne Variablen oder Funktionen sein, was dazu führt das man den ganzen Kram aufdröseln muss. Übersichtlich ist dann anders. "Compiler": - Funktionspointer? - gibts nicht - Strukturen? - gibts nicht - Mehrdimensionale Arrays? - gibts nicht - Makros? - gibts nicht - Bedingte Kompilierung? - gibts nicht - rekursive Funktionen - stürzt gerne ab - getrennte lokale Speicher - stürzt ab - Codeanalyse zur Optimierungen? - gibts nicht - Strukturanalyse zur Optimierung? - gibts nicht - sprachliche Unterstützung zur Modularisierung von Code - nicht vorhanden usw. usf. "IDE" - automatisches Einrücken - gibts nicht - Blockpfade - gibts nicht - automatisches Vervollständigen - gibts nicht usw. usf. Realistisch betrachtet gleicht dieser "Compiler" mehr einem Makroprozessor eines aufgebohrten Assemblers. Die Codequalität ist unterirdisch schlecht (riesig und langsam).
Emron-C schrieb: > Realistisch betrachtet gleicht dieser "Compiler" mehr einem > Makroprozessor eines aufgebohrten Assemblers. Die Codequalität ist > unterirdisch schlecht (riesig und langsam). es fehlt noch: instabil bei großen Projekten und dieses wirre Gefummel mit Framesize hwstack usw. ich habe Wochen damit zu gebracht eines meiner großen Projekte irgendwie stabil zu bekommen. ich bin gescheitert. Ich hatte die Nase voll und habe das Ganze dann in einer anderen Sprache neu geschrieben (ich sage jetzt nicht welche, um Glaubenskriege nicht zu unterstützen). Selbst als Anfänger in der neuen Sprache war das Ergebnis: wesentlich kleiner, fast doppelt so schnell und stabil.
Ja, müssig solche Diskussionen...
zumindest habe ich es damit geschafft einen AVI Video in Farbe auf einem
TFT wiederzugeben, Internetradio mit M128@8MHz zu realisieren u.a.
Es gibt einen alten Spruch: Ein Programmierer kann in jeder
Programmiersprache Fortran programmieren.
Auch nicht jeder {} Code sieht für mich so aus, als hätte sich dabei
jemand was gedacht.
Was sagt uns das? Genau... nix... Möge doch jeder das so gestalten, wie
er kann und mag; wobei mit die Intension des Thread Starter dann nicht
so ganz klar wird...
den Beitrag vom TO verstehe ich weniger als eine Diskussion welche Sprache denn nun das Schönste wäre, sondern schlicht die Qualität dieses Pseudocompilers.
Ich denke, es ist dem Wetter geschuldet, das manch Einem auf die Birne schlägt. Da kann man mal versuchen, ein bisschen Stimmung anzufachen.... :-( Emron C schrub u.A.: >Analysieren wir doch mal diesen sogenannten "Compiler": Wir? Mach selbst eine Anneliese -hier sind ein paar Anhaltspunkte: >Makros? - gibts nicht Na freilich gibt es Makros -genauso, wie beim Bäcker Makronen http://avrhelp.mcselec.com/index.html?macro.htm >Mehrdimensionale Arrays? - gibts nicht Die kann man sich bei Bedarf selbst zusammenbauen: http://www.mcselec.com/index2.php?option=com_forum&Itemid=59&page=viewtopic&t=9675&highlight=array >Bedingte Kompilierung? - gibts nicht http://www.roboternetz.de/community/archive/index.php/t-59370.html Ich hoffe, daß Du mit der Sprache C besser zurecht kommst. Ab dafür Paul
Paul Baumann schrieb: > Ich denke, es ist dem Wetter geschuldet, das manch Einem auf die Birne > schlägt. Da kann man mal versuchen, ein bisschen Stimmung anzufachen.... > :-( > > Emron C schrub u.A.: >>Analysieren wir doch mal diesen sogenannten "Compiler": > > Wir? Mach selbst eine Anneliese -hier sind ein paar Anhaltspunkte: > >>Makros? - gibts nicht > Na freilich gibt es Makros -genauso, wie beim Bäcker Makronen > > http://avrhelp.mcselec.com/index.html?macro.htm > >>Mehrdimensionale Arrays? - gibts nicht > > Die kann man sich bei Bedarf selbst zusammenbauen: > > http://www.mcselec.com/index2.php?option=com_forum... > >>Bedingte Kompilierung? - gibts nicht > > http://www.roboternetz.de/community/archive/index.... > > Ich hoffe, daß Du mit der Sprache C besser zurecht kommst. > > Ab dafür > Paul hier hast du recht, da hat er sich wohl getäuscht, aber was ist mit dem ganzen entscheidenden Rest? Was ist mit einer Version für Linux und Vielleicht auch Mac? Wann dürfen die geneigten Nutzer in den Genuss eines halbwegs modernen Editors und Oberfläche kommen? Ich meine ich war auch Bascom-Anwender, aber ich führe keinen Glauben an irgendwas, sondern will ein ordentliches Werkzeug. und diese Punkte sind mehr oder weniger nur oberflächlich betrachtet. Es ist nicht erkennbar warum das Teil so hoch gelobt wird. Es ist schlicht schlecht programmiert und völlig überaltert. Darf man darüber denn keine Diskussion führen ohne von Bascom-Gläubigen angegriffen zu werden? An der Diskussion über das Für und Wieder und der Qualität ist nichts teuflisches.
Lysium schrob: >Darf man darüber denn keine >Diskussion führen ohne von Bascom-Gläubigen angegriffen zu werden? Aber selbstverfreilich kann man diskutieren. >An der Diskussion über das Für und Wieder und der Qualität ist nichts >teuflisches. Ich habe auch nichts Teuflisches gesehen, nur einige Parolen entkräftet. Mich ärgert nur die Ansicht, daß Leute, die mit Bascom an's Werk gehen, unterschwelig als Stümper und lausige Amateure hingestellt werden sollen. Wenn das Programm so wenig komfortabel und so schwierig zu bedienen ist, müßte man dann nicht den Leuten, die diese schwere Last auf sich nehmen ein Beifallssturm entgegenbranden? ;-) MfG Paul
Edith sagt: Hier ist noch ein kleines "L" für unterschwellig. MfG Paul
Emron-C schrieb: > "Compiler": > - Funktionspointer? - gibts nicht Hat nichts mit "Compiler" zu tun, sondern mit der Sprache "Basic". > - Strukturen? - gibts nicht Hat nichts mit "Compiler" zu tun, sondern mit der Sprache "Basic". > - Mehrdimensionale Arrays? - gibts nicht Hat nichts mit "Compiler" zu tun, sondern mit der Sprache "Basic". > - Makros? - gibts nicht Hat nichts mit "Compiler" zu tun, sondern mit der Sprache "Basic". > - Bedingte Kompilierung? - gibts nicht Hat wenig mit "Compiler" zu tun, aber viel mit der Sprache "Basic". > - rekursive Funktionen - stürzt gerne ab Bug, aber kein Kriterium für Compiler oder nicht > - getrennte lokale Speicher - stürzt ab Bug, aber kein Kriterium für Compiler oder nicht > - Codeanalyse zur Optimierungen? - gibts nicht Quality of implementation, aber kein Kriterium für Compiler oder nicht > - Strukturanalyse zur Optimierung? - gibts nicht Quality of implementation, aber kein Kriterium für Compiler oder nicht > - sprachliche Unterstützung zur Modularisierung von Code - nicht > vorhanden Hat nichts mit "Compiler" zu tun, sondern mit der Sprache "Basic". > usw. usf. Gut, so viele Punkte, und nicht ein einziger, der deine These auch nur stützt, Bascom sei kein Compiler. Wie auch? Es ist offensichtlich einer.
Paul Baumann schrieb: > Mich ärgert nur die Ansicht, daß Leute, die mit Bascom an's Werk gehen, > unterschwelig als Stümper und lausige Amateure hingestellt werden > sollen. > Wenn das Programm so wenig komfortabel und so schwierig zu bedienen ist, > müßte man dann nicht den Leuten, die diese schwere Last auf sich nehmen > ein Beifallssturm entgegenbranden? > ;-) ich glaube hier ziehst du etwas aus dem Zusammenhang. Ich will nicht verleugnen, dass das gerne gemacht wird. Der TO jedoch hat sich allein auf die Qualität der Software konzentriert, von schwierig war hier nicht die Rede. Was dabei als Fazit rüberkommt kann ich als designierter Bascom-Anwender vollumfänglich unterschreiben. Wenns denn doch mal komplexer wird, hat man sich da schnell verrannt und "kotzt einfach nur ab". l.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.