  INFO - FAQ - CC2-Forum - CCPro-Forum |
|
||
|
Hallo, > Und dabei ist die Ausführungsgeschwindigkeit bei vielen Anwendungen zweitrangig. Stellt sich die Frage, was zweitrangiger ist. Ein langsamer Controller (deswegen, und das ist einer der Hauptgründe von vielen, die zu AVR wechseln), oder die Option je nach Controller per Patchwork ein größeres (aber immer noch langsames) EEPROM zu nehmen. Eine Erweiterung bei der M Unit 2 ist schon aus technischen Gründen nicht möglich. Gleiches gilt für die OpenMicro. Mich wundert es daher, dass grade Du einen solchen Wert auf diesen Punkt legst, da dies ja ein entscheidener Vorteil der alten M Unit sei (die Standadmäßig weniger Speicher hatte). > Außerdem gibt es immer noch die Möglichkeit, die 1.1er mit einem anderen Quarz auszustatten Auch das ist Patchwork und hebt den Controller nicht hervor. Hier muss sogar mit veränderten Eigenschaften der TIMER Funktionen gearbeitet werden. Die M Unit 2 verfügt auch über einen Quarz. Bisher gab es noch keine Tests diesbezüglich, ob man einen schnelleren Quarz nehmen kann. > Warum Du behauptest, C3C könne mit der 2.0er benutzt werden ist mir ebenfalls ein Rätsel. C3C benutzt für die Realisierung einiger Funktionen ein Assemblermodul, das nur auf der 1.1er lauffähig sein dürfte. Entscheidend hier sei wohl, dass es sich hierbei um einige Funktionen wie z.B. Pointer handelt. Diese gab es ja in CCBasic noch nicht einmal und gibt es erst seit der M Unit 2.03 (bzw. auf der M Unit 2.01 mit einem Assemblermodul). Nicht nachvollziehen kann ich warum der Downloadmodus nicht funktioniert, immerhin nutze ich bei BASIC++ den gleichen Modus für die 1.1, 2.0 und Micro. > Es sind schon sehr merkwürde Ansichten, die Du hier vertrittst. Du ignorierst sämtliche Optionen, die eine Verbesserung der Programmierung ermöglicht haben Einen Vorparser zwischen CCBasic und IDE zu setzten ist immer noch Patchwork und kein Vorteil, den man CCBasic zu gute halten kann. Selbst wenn man nun einige Dinge mit dem Parser einfacher hat, so kann ich hier eine ganze Liste von kritischen Elementen von CCBasic auslisten, die nicht unbedingt hätten sein müssen. Dabei geht es mir gar nicht darum CCBasic schlecht zu reden. Sinn der Diskusion war es doch, dass es angeblich schwerer sei modular zu programmieren als mit CCBasic. Das kann aber nicht sein. Wenn Du mal meine Posts lesen würdest, würdest Du feststellen, dass ich CCBasic vornehmlich mit "modularem Basic" vergleiche, keineswegs also nur mein Basic zum Vergleich ziehe. Außerdem habe ich schon gesagt, dass ich viele Dinge aus CCBasic übernommen habe, die ich nicht gut finde (z.B. Define, Table, Deklarierung von Sprungmarken, ...). Auch diese Tatsache ignorierst Du wieder. Langsam kommt es mir so vor, als würdest Du mir ständig das vorwerfen, was Du selber machst, nämlich die Argumentation zurecht zu biegen. Das erkennt man schon daran, dass Du offensichtlich zum Wiederholten male in Posts (nicht im letzten) von der fachlichen Diskusion abweichst und mir z.B. unterstellst ich würde die Wahrheit verdrehen. Dabei habe ich nur Stellung zu Sachverhalten bezüglich modularer Programmierung und CCBasic bezogen, auch wenn das nicht Deiner Meinung entsprechen mag. > vergleichst Dein BASIC mit der Programmiersprache und der Sprachenversion, die dir gerade an sinnvollsten erscheinst Hallo? Seit Beginn der Diskusion rede ich nur von CCBasic und 1.1 auf der einen die 2.0 und modulare Programmierung (u.a. am Beispiel von BASIC++ oder C3C) auf der anderen Seite. > Falsch! Es geht darum, daß Du die Wahrheit so zurechtbiegst, bis sie Dir in den Kram paßt. Der komplette Satz ist kein sachlicher Kommentar zu dem von Dir zitierten Satz. Sowas ist immer schön. Hier nochmal mein Zitat: > Es ging ja darum, dass sich ein User darüber beschwerte der Umstieg von CCBasic nach BASIC++ um die M Unit 2 zu programmieren fiele ihm schwer und CCBasic sei einfacher zu handhaben als die modulare Programmierung, wie sie z.B. in BASIC++ oder C3C vorhanden ist. Ich habe daraufhin einige Beispiele genannt, warum ich es nicht nachvollziehen kann, dass eine Programmiersprache, die einen Anwender zwingt unübersichtliche Konstrukte zu verwenden (die heute in keiner anderen modernen Basic Programmiersprache mehr angeraten werden) einfacher sein soll, als modulare Sprachkonzepte. Da steht, dass "ich es nicht nachvollziehen kann, dass eine Programmiersprache, die einen Anwender zwingt unübersichtliche Konstrukte zu verwenden (...) einfacher sein soll, als modulare Sprachkonzepte." und ich sogar Beispiel gezeigt habe. In dem kompletten Satz steht nichts, aber auch gar nicht von BASIC++ sondern modulare Sprachkonzepte allgemein. Bitte wo verbiege ich da die Wahrheit? > Gegen Deinen BASIC-Dialekt habe ich nichts, schließlich wirst Du auf den Infosites zur OM auch Hinweise darauf finden, daß die OM auch in Deinem BASIC programmierbar ist. Es gibt sogar einige Anwender, die das machen. Und genauso wirst Du auf der BASIC++ Seite sehen, dass auch die OM unterstützt wird. Wieso sollte ich also nun etwas schlechtes gegen die OM gesagt haben? Unterstellung über Unterstellung. > Ich will im Gegensatz Du Dir niemandem vorschreiben, welche Programmiersprache oder welchen Programmierstil er zu benutzen hat. Bitte wo habe ich das gesagt? Gib mir ein Zitat. > Wer mit CCBASIC gut leben kann, soll das tun. Ja natürlich. Zu Beginn der Diskusion ging es sich aber um's Umsteigen nach BASIC++. Meine Intention war es zu zeigen, dass es in der Tat nicht schwer sein muss auf einmal modular zu Programmierung, zumal dies sowieso heute Standard ist (wenn nicht sogar OOP). > Sinnvoller, weil kein Umlernen erforderlich ist, ist in diesem Fall zwar ein Wechsel zu OCBASIC, aber sei's drum. Sinnvoller wäre es gewesen, wenn CCBasic sich von Anfang an an bestimmte gundlegende Konventionen gehalten hätte. CCBasic war aber lange Zeit die Sprache der C-Control I. Selbst die Alternative über Parser oder C3C veränderten das nicht: CCBasic blieb der De Facto Standard der C-Control. Insofern wurde den Anwendern also die Methodik von CCBasic aufgezwungen. > Diese Leute als Idioten abzustempeln und CCPLUS als "Gebärdensprache" zu bezeichen, wie es in diesem Forum geschehen ist, halte ich für reichlich unverschämt. Ach und das schiebst Du mir jetzt auch noch in die Schuhe? Und nun noch einige Dinge, die ich an CCBasic kritisiere und eben versuche darzustellen, dass grade diese Dinge CCBasic nicht einfacher machen, die aber selbst in BASIC++ aus historischen Gründen übernommen wurden. - GOSUB Anweisung, obwohl es eigentlich eine CALL Anweisung sein müsste - DEFINE für Konstanten, obwohl CONST Konvention ist - WORD, obwohl es eigentlich ein Integer ist - kein echtes WORD, also ein Datentyp ohne Vorzeichen für 16 Bit Werte - #-Zeichen zum Deklarieren von globalen Labels und Unterprogrammen, obwohl dieses Zeichen in BASIC allgemein ein Datentypzeichen ist - Nur ein Schleifentyp - keine lokalen Variablen (z.B. um "i" immer wieder als Zählervariable zu nehmen, was z.B. bei INCLUDE und Libs sehr sinnvoll ist), keine lokalen Sprungmarken (z.B. sehr sinnvoll bei Fehlerbehandlungen und Standard-Funktionsrümpfen - keine mehrzeiligen IFs und kein SELECT - Unterprogrammaufruf mit GoSub, obwohl dies in BASIC allgemein nur optional ist - Bit Datentyp, der sonst eigentlich Boolean heisst - ON und OFF statt TRUE und FALSE (auch gegen die Konvention) - Tables bieten die einzige Möglichkeit Tokencode (allerdings in etwas beschwerlicher Form) einzufügen. Gerade das ist aber manchmal bei einem Controller sinnvoll (auch wenn ich hier zugeben muss, dass das nicht den allg. Konventionen entspricht) Einige Kritikpunkte ergeben sich aus den technischen Gegebenheiten. Vieles hätte auch besser gelöst werden können, ohne im erheblichen Maße einen aufwendigeren Compiler zu schreiben. Einige Kritikpunkte führen dazu, dass Code mit unter unübersichlich werden kann und somit kaum zu warten. Das erhöt auch die Fehleranfälligkeit. Wie tötlich wäre das z.B. eben bei einem 64 KB Code? Daher kann ich eben nicht nachvollziehen, wieso CCBasic einfacher wäre als modulare Programmierung. Gruß, Stefan Meine Homepage: http://www.fdos.de |
| Antwort schreiben |
Re: C-Control am Ende? (von Dietmar - 29.10.2005 0:35)Re: C-Control am Ende? (von Stefan Tappertzhofen - 29.10.2005 1:58)Re: C-Control am Ende? (von Dietmar - 29.10.2005 10:37)Re: C-Control am Ende? (von Stefan Tappertzhofen - 29.10.2005 11:44)Re: C-Control am Ende? (von Stefan Tappertzhofen - 29.10.2005 11:51)Klarstellungen (von Dietmar - 30.10.2005 1:16)Re: Klarstellungen (von Stefan Tappertzhofen - 30.10.2005 12:49)Re: Klarstellungen (von Stefan Tappertzhofen - 30.10.2005 16:49)Re: Klarstellungen (von Dietmar - 30.10.2005 15:25)Re: Klarstellungen (von Stefan Tappertzhofen - 30.10.2005 15:59)Richtigstellungen (von Dietmar - 5.11.2005 17:26)Re: Richtigstellungen (von Dietmar - 18.11.2005 0:10)Re: Klarstellungen (von Dietmar - 30.10.2005 17:56)Re: Klarstellungen (von DIE HARD - 30.10.2005 18:29)Re: Klarstellungen (von Dietmar - 30.10.2005 19:53)Re: Klarstellungen (von DIE HARD - 30.10.2005 20:39)Re: Klarstellungen (von Dietmar - 31.10.2005 0:57)Re: Klarstellungen (von OM-Betatester - 30.10.2005 17:03)Re: Klarstellungen (von Dierk - 30.10.2005 17:25)Re: Klarstellungen (von Eckhard - 30.10.2005 16:09)Re: C-Control am Ende? (von André H. - 29.10.2005 7:15)Re: C-Control am Ende? (von Stefan Tappertzhofen - 29.10.2005 11:29)Re: C-Control am Ende? (von André H. - 30.10.2005 19:53)nicht nur CCBASIC (von C64 - 29.10.2005 5:36)Re: nicht nur CCBASIC (von Dierk - 29.10.2005 11:22)Re: nicht nur CCBASIC (von Jens - 29.10.2005 16:41)Re: nicht nur CCBASIC (von Stefan Tappertzhofen - 29.10.2005 17:04)Re: nicht nur CCBASIC (von André H. - 30.10.2005 20:12)Re: nicht nur CCBASIC (von Dierk - 29.10.2005 18:18)Re: nicht nur CCBASIC (von Jens - 29.10.2005 21:30)Re: nicht nur CCBASIC (von Dierk - 29.10.2005 11:50)Re: nicht nur CCBASIC (von Stefan Tappertzhofen - 29.10.2005 11:03)Re: nicht nur CCBASIC (von OM-Betatester - 29.10.2005 12:35)Re: nicht nur CCBASIC (von Stefan Tappertzhofen - 29.10.2005 13:07)