Klassen, Objekte, Struct, Überladen in LUNA AVR

>Bitte nur antworten wenn ihr auch von Luna Ahnung habt.

Die haben doch ein Forum. Da kriegst du sicher gute 
Antworten...irgendwann;)

Dann sag doch auch den C Leuten die sollen in ein C Forum gehen.

>Dann sag doch auch den C Leuten die sollen in ein C Forum gehen.

Dann sind sie hier ja an der richtigen Stelle.

Haben die Luna Anwender hier keine Meinung?

Das haben wir hier schon diskutiert
Beitrag "Vorteile von Basic, Pascal, C und C++ in einem: LunaAVR"
und haben insbesondere festgestellt, dass die "Objektorientierung" von 
Luna nicht dem entspricht, was man üblicherweise darunter versteht, und 
die "Klassen" in Luna nicht das können, was Klassen in allen anderen 
Sprachen können. Klassen in Luna sind das, was in C++ namespaces sind. 
Der Mangel an "richtigen" Klassen (OOP) ist für eine Sprache ein großer 
Nachteil. Also: Finger weg.

Kindergärtner schrieb:
> Das haben wir hier schon diskutiert
> Beitrag "Vorteile von Basic, Pascal, C und C++ in einem: LunaAVR"
> und haben insbesondere festgestellt, dass die "Objektorientierung" von
> Luna nicht dem entspricht, was man üblicherweise darunter versteht, und
> die "Klassen" in Luna nicht das können, was Klassen in allen anderen
> Sprachen können. Klassen in Luna sind das, was in C++ namespaces sind.
> Der Mangel an "richtigen" Klassen (OOP) ist für eine Sprache ein großer
> Nachteil.

Man muss jedoch schon wissen von was man spricht. Es ist hier mitnichten 
so, dass es keine instanzierbaren Objekte/Klassen gäbe. Das weiß man, 
nachdem man damit auch mal herumgespielt hat. Man sollte also etwas mehr 
als drei Absätze lesen, wenns einen interessiert.
So wie ich das sehe, sind die benannten "Klassen" absichtlich wie Units 
in Pascal, da für die meisten Anwendungsfälle sowieso nur eine Instanz 
sinnvoll ist, wohingegen wenn man wirklich instanzierbare Objekte 
benötigt dann halt sich eine externe Bibliothek bauen kann. Insgesamt 
ist das Konzept schon stimmig und die Fähigkeiten beeindruckend.

Ich kann mit diesem basic/pascal-gedöhns nichts anfangen, mich hats aber 
interessiert und meiner Meinung nach ist das um das zigfache sinnvoller 
sich damit zu beschäftigen als mit dem popel-basic bascom, wenns denn 
sein muss.

Curious (Gast) schrieb:

> Wer kann zu den Voteilen/Nachteilen von LunaAVR was konstruktives sagen?

> http://avr.myluna.de/doku.php?id=de:about
> http://avr.myluna.de/doku.php?id=de:procedure-endproc

> Bitte nur antworten wenn ihr auch von Luna Ahnung habt. Es interessiert
> mich hier nicht der Einsatz im professionellen Bereich, sonder die
> Eignung für fortgeschrittene Hobby-Anwender.

Kann dir leider aufgrund Zeitmangels noch nichts nennenswertes dazu 
sagen, außer dass mich vor allem die LunaAVR-Webseite in ihrer 
Gestaltung anspricht, neugierig macht und zum lesen einlädt. Das ist für 
mich persönlich schon mal ein großes Pfund. Wenn eine Programmiersprache 
das nicht schafft, lasse ich sie erst mal bis auf weiteres links liegen, 
warte erst mal ab oder wende mich gleich ganz ab. LunaAVR trifft 
definitiv auf mein Interesse.

Was mir beim Thema LunaAVR bisher hier im Forum (mit Verweis auf den 
Nörgelthread) auffällt, ist, wie krampfhaft bestimmte immer gleiche 
Miesmacher sich auf LunaAVR einschießen, ohne je damit groß in Kontakt 
gekommen zu sein. Da werden sich "Argumente" regelrecht aus den Fingern 
gesogen, die man bei anderen Programmiersprachen so nie hören würde 
(oder dort wie bei C# auch manchmal). Das legt den Verdacht nahe, dass 
diese Spezln wohl ein auffälliges Interesse am Misserfolg vom 
LunaAVR-Projekt haben und gerne hier im Forum Threads über LunaAVR 
gezielt stören. Warum auch immer. Auf diese Typen höre ich prinzipiell 
nicht, merke sie mir aber und ziehe daraus meine Schlüsse in anderen 
Diskussionen.

Bilde dir einfach dein eigenes Urteil! Wichtig für mich persönlich ist, 
was ich mit LunaAVR umsetzen kann und ob mir das Konzept durchdacht und 
im Ablauf angenehm erscheint. Ob da mit LunaAVR im übersetzten Code dann 
beispielsweise das letzte Quäntchen an Optimierung rausgeholt ist oder 
nicht, ist für mich eher sekundär, bzw. eine Gespensterdebatte, die sehr 
einseitig ist und andere Aspekte unterschlägt. Eine Sprache die C++ an 
Komplexität noch schlägt brauche ich nicht. Für mich ist eher das 
Gegenteil wichtig, d.h. so kompliziert wie nötig und so einfach wie 
möglich im Handling.

Schau halt einfach mal rein.

Die Welt geht vor die Hunde schrieb:
> wenn man wirklich instanzierbare Objekte benötigt dann halt sich eine
> externe Bibliothek bauen kann
Ach so? Wo steht das denn auf der Website? Bei den Kapiteln über 
"Klassen" jedenfalls nicht. Und man muss Klassen in externe Bibliotheken 
packen? Klingt enorm umständlich.

programming schrieb:
> die LunaAVR-Webseite in ihrer
> Gestaltung anspricht, neugierig macht und zum lesen einlädt.
Hervorragend zum Bauern fangen geeignet! Vernünftige Sprachen haben eine 
Website, die mit http://www.iso.org/... anfängt, denn sie sind 
international standardisiert, sodass es nicht nur einen Compiler und 
eine Plattform gibt. Bei C und C++ ist das zB so. Die konkreten 
Umgebungen haben dann eigene Websiten.
Aber daran sieht man wieder, Marketing sells! Die Qualität des Produkts 
ist weniger wichtig als die Buntheit der Website... Funktioniert ja auch 
bei Apple hervorragend.

programming schrieb:
> Da werden sich "Argumente" regelrecht aus den Fingern
> gesogen, die man bei anderen Programmiersprachen so nie hören würde
Doch. Jede Sprache die sich "objektorientiert" nennt es aber nicht ist 
würde ähnlich kritisiert. Nur eine solche hab ich bis jetzt nicht 
gesehen!

programming schrieb:
> Das legt den Verdacht nahe, dass
> diese Spezln wohl ein auffälliges Interesse am Misserfolg vom
> LunaAVR-Projekt haben
Das macht ja auch Sinn, denn je mehr sich die Entwickler auf 
verschiedene obskure Sprachen aufteilen (fragmentieren), desto 
schlechter ist es mit der Interoperabilität bestellt...

Kindergärtner schrieb:
> Website, die mit http://www.iso.org/... anfängt, denn sie sind
> international standardisiert, sodass es nicht nur einen Compiler und
> eine Plattform gibt. Bei C und C++ ist das zB so. Die konkreten
> Umgebungen haben dann eigene Websiten.
> Aber daran sieht man wieder, Marketing sells! Die Qualität des Produkts
> ist weniger wichtig als die Buntheit der Website... Funktioniert ja auch
> bei Apple hervorragend.

Von was sprechen wir denn hier? Das sich die Sprache an aktuellen 
Basic/Pascal-Arten vom PC-orientiert ist doch sinnvoll, denn das kennen 
Viele und hilft beim Verständnis. Dennoch ist es wie auch sämtliche für 
den PC verfügbaren, ähnlichen Sprachen propritär! Man will doch nicht 
ernsthaft behaupten das die PC-Basic/Pascal-Dielekte offizielle, 
ISO-zertifizierte Standards sind? Von kommerziellem Marketing kann ich 
da ehrlich gesagt nichts erkennen, das trifft eher auf bascom zu. 
Insofern könnte man das Promoten des minimal-basics bascom dann durchaus 
verstehen, denn die Leute verdienen damit ihr Geld.

Einen Vergleich mit Standardisierten Sprachen wie C++ würde ich zudem 
nicht vornehmen wollen, sorry. Einen Vergleich kann man höchstens mit 
ebenfalls propritären Sprachen vornehmen - z.B. eben mit bascom und 
schauen uns an was von den heutzutage modernen, erwarteten Fähigkeiten 
dort umgesetzt ist, das wird dann schnell lächerlich. Das sie es nicht 
geschafft haben ihr Produkt in den ganzen Jahren zu modernisieren, 
spricht nicht gerade für die Entwickler von bascom. Kritisch betrachtet 
muss man sogar vermuten das sie eigentlich nicht wissen wie Compiler 
gebaut werden.

Kindergärtner (Gast) schrieb:

programming schrieb:
>> Das legt den Verdacht nahe, dass
>> diese Spezln wohl ein auffälliges Interesse am Misserfolg vom
>> LunaAVR-Projekt haben

> Das macht ja auch Sinn, denn je mehr sich die Entwickler auf
> verschiedene obskure Sprachen aufteilen (fragmentieren), desto
> schlechter ist es mit der Interoperabilität bestellt...

Gott sei Dank gibt es Vielfalt! In deinem Hirn entscheidet wohl nur die 
Einfalt. Aber gut, dass du es sogar zugegeben hast, was ich schrieb. Das 
entlarvt dich als Störenfried, der anderen den Erfolg neidet. 
Erbärmlicher kann man sich hier gar nicht darstellen.

programming = mws = mws, der Admin aus dem Bascom Forum.

Sorry meinte natürlich:

Kindergärtner (Gast) = mws = mws, der Admin aus dem Bascom Forum.

Kindergärtner schrieb:

> Jede Sprache die sich "objektorientiert" nennt es aber nicht ist
> würde ähnlich kritisiert. Nur eine solche hab ich bis jetzt nicht
> gesehen!

Gab's aber schon, z.B. VisualBasic (vor VB.net).

Es handelt sich nur um syntaktisches Zuckerwerk, welches die Benutzung 
von "außen" stammender Objekte ermöglicht. Es ist aber keine Sprache, 
die die Erstellung eigener instanziierbarer Klassen ermöglicht und schon 
garnicht  übliche Features von OOP-Sprachen wie Vererbung und 
Polymorphie.

Bei dem ollen VB konnte man aber immerhin via COM/ActiveX eigene 
Objekt-Typen (wenn auch in einer anderen Sprache geschrieben) in die 
Sprache einbringen.

Etwas ähnliches wird bei Luna (wohl absichtlich) verhindert, denn die 
dazu nötigen Schnittstellen für den Compiler sind schlicht nicht 
dokumentiert oder existieren möglicherweise nicht einmal, wenn's 
schlimme Bastelsoftware ist. Wirklich einschätzen kann man das nicht, 
weil's nicht OpenSource ist.

Ich würde die Finger davon lassen. Das riecht mindestens so stark nach 
"vendor-lock-in" wie Bascom. Das will man nicht, dann doch lieber noch 
C++. Das ist zwar auch eine üble Seuche, aber aus ganz anderen Gründen.

c-hater schrieb:
> Das will man nicht, dann doch lieber noch
> C++. Das ist zwar auch eine üble Seuche, aber aus ganz anderen Gründen.

Nun ja, es gibt sicher mehr Alternativen.

Yalu hatte kürzlich dazu ja etwas geschrieben "... als 
Hobby_Programmiersprache" und auch mal ein leeres Progrämmchen zumindest 
kompilert bekommen. Aber die Frage ist ja, was will man bzw. der 
Threadstarter überhaupt? Weg von C? Und wenn, warum. Und: Will man alles 
vorgekaut vorgesetzt bekommen? Dann muss man halt was kommerzielles 
nehmen. Sonst könnte man eine der von Yalu genannten Sprachen vielleicht 
in Erwägung ziehen, eher aber für große AVR oder ARM. Aber da muss man 
etwas Arbeit reinstecken -- könnte aber durchaus Spaß machen. Und sonst, 
es gab hier auch noch den Oberon-Thread? Naja, da bin ich aber etwas 
skeptisch.

Die Welt geht vor die Hunde schrieb:
> Man will doch nicht
> ernsthaft behaupten das die PC-Basic/Pascal-Dielekte offizielle,
> ISO-zertifizierte Standards sind?
Nö, also auch alle mist.

ArduinoDriver schrieb:
> Kindergärtner (Gast) = mws = mws, der Admin aus dem Bascom Forum.
Wer Luna nicht mag, ist schließlich automatisch Bascom-Fan...

c-hater schrieb:
> Gab's aber schon, z.B. VisualBasic (vor VB.net).
http://msdn.microsoft.com/en-us/library/7zzxk2t0%28v=vs.90%29.aspx
Das klingt hier aber anders.


... Warum wollen immer alle neue Sprachen haben, wenn die Leute nichtmal 
die Fähigkeiten der vorhandenen Sprachen wie C++ ausnutzen?

c-hater (Gast) schrieb:

> Etwas ähnliches wird bei Luna (wohl absichtlich) verhindert, denn die
> dazu nötigen Schnittstellen für den Compiler sind schlicht nicht
> dokumentiert oder existieren möglicherweise nicht einmal, wenn's
> schlimme Bastelsoftware ist. Wirklich einschätzen kann man das nicht,
> weil's nicht OpenSource ist.

> Ich würde die Finger davon lassen. Das riecht mindestens so stark nach
> "vendor-lock-in" wie Bascom. Das will man nicht, dann doch lieber noch
> C++. Das ist zwar auch eine üble Seuche, aber aus ganz anderen Gründen.

Mal abgesehen von deinen Verschwörungstheorien, der Satz mit "Wirklich 
einschätzen kann man das nicht, weil's nicht OpenSource ist." ist immer 
wieder der gleiche Mist, der von bestimmten "ich mag nur OS und sonst 
gar nichts"-Indoktrinierten in Foren geschrieben wird. Ich kann so einen 
Unfug bald nicht mehr hören. Borlands Turbo Pascal war einst auch kein 
"Open Source" und erfreute sich größter Beliebtheit nicht nur bei 
Privatcodern, sondern bei Firmen und auch an deutschen Hochschulen. Das 
gleiche galt für deren Turbo C++ 3.0. Microsoft's C-Compiler war und ist 
kein Opensource und fand ebenso wie die Borlandprodukte Einlass in 
zahlreiche Artikel der damaligen c't, also einem großen bundesweiten 
Leserkreis. Kannst du alles heute noch nachlesen in den alten Ausgaben. 
Altium und eagle waren und sind auch nie "OpenSource" gewesen und 
bedienen seit langem einen Markt, an den KiCAD, dass erst Jahrzehnte 
später aufkam und noch immer halbgar an allen Ecken und Enden ist, erst 
mal heranreichen muss. Heute gibt es u.a. auch Dank Borland 
Nachfolgeprodukte, wie ein freies Lazarus und ein gut gepflegtes Closed 
Source Delphi, für Leute, die die Kohle dafür haben und die damit Geld 
verdienen wollen sowie professionellen Support suchen. Das .NET 
Framework von MS war bisher auch kein OpenSource, wiewohl sich das 
gerade langsam ändert. C# wurde eigens dafür von einen Closed Source 
Anbieter wie MS erschaffen, standardisiert und existiert nun als auch 
als OS Software sowohl für Windows als auch Linux. Was wurde gerade bei 
C#/.NET alles für Schmähartikel von OpenSource'lern als es rauskam 
verfasst, die euch heute alle Lügen strafen. Ihr Miesmacher seid 
heutzutage einfach viel zu übersättigt in eurem Anspruchsdenken. Keiner 
zwingt euch das zu benutzen. Lasst die anderen ihre eigenen Erfahrungen 
machen. Freut euch einfach an der Vielfalt.

Kindergärtner (Gast) schrieb:

> ... Warum wollen immer alle neue Sprachen haben, wenn die Leute nichtmal
> die Fähigkeiten der vorhandenen Sprachen wie C++ ausnutzen?

Weil sie nun mal keinen Bock haben sich mit C++ herumzuquälen. Ist das 
so schwer zu verstehen? Brauchst du Altium, um eine einfache Platine zu 
routen? Ich nicht! Habe ich Lust mir die Zeit zu verplempern mit einem 
unausgereiften KiCAD? Nicht wenn es für mich gute Alternativen gibt!

Das wirst du wohl nie verstehen, armer Indoktrinierter.

Kindergärtner schrieb:

> http://msdn.microsoft.com/en-us/library/7zzxk2t0%28v=vs.90%29.aspx
> Das klingt hier aber anders.

Naja. Du mußt halt noch lernen, verstehend zu lesen. Winzigweich erklärt 
natürlich die Restriktionen nicht oder nur in locker hingestreuten 
unverdächtigen Halbsätzen.

c-hater schrieb:
> Etwas ähnliches wird bei Luna (wohl absichtlich) verhindert, denn die
> dazu nötigen Schnittstellen für den Compiler sind schlicht nicht
> dokumentiert oder existieren möglicherweise nicht einmal, wenn's
> schlimme Bastelsoftware ist. Wirklich einschätzen kann man das nicht,
> weil's nicht OpenSource ist.

Das Ganze ist eigentlich recht gut dokumentiert.
Die ganzen Bibliotheken sind ebenfalls im Source komplett edierbar und 
wie der Compiler bzw. Linker das intern einbindet ist im Quelltext und 
in Beispielen beschrieben. Sämtliche Controllerwerte kann ich ändern und 
Neue einfügen wenn mir danach ist. Alle Informationen, von internen 
Compilerfunktionen, Controller-Infos und Bibliotheken sind offen und 
editierbar DAS ist für mich ein Argument. Insbesondere für einen Moment, 
wo die Entwicklung stockt oder verhindert ist, dann kann ich nämlich 
trotzdem alle Bausteine der Codeerzeugung selber erweitern und 
Controller neu einpflegen usw.

Das ganze Geschrei nach OpenSource ist völliger Quatsch. Ich will mal 
die Vermutung aufstellen, dass nur eine homöopathische Anzahl Leute die 
Fähigkeit haben an einem Compiler bauen zu können, das sieht man ja auch 
sehr schön am AVR-GCC. Da fummeln höchstens drei Hanseln dran herum, der 
Rest - mich eingeschlossen - versteht da nur Bahnhof.

Seit wann ist Bascom eigentlich opensource? Da kann man höchstens in 
vereinzelten Bibliotheken editieren, der Rest ist absichtlich 
unleserlich kodiert.

Wire schrieb:
> Das ganze Geschrei nach OpenSource ist völliger Quatsch. Ich will mal
> die Vermutung aufstellen, dass nur eine homöopathische Anzahl Leute die
> Fähigkeit haben an einem Compiler bauen zu können,

Ja, das stimmt schon. Open Source wird ja heute von den Kids auch meist 
mit kostenlos gleichgesetzt. Und beteiligen tut sich von denen ja eh 
fast keiner mehr an der Entwicklung von FOSS Projekten -- die spielen 
lieber mit dem Handy, gucken Videos oder Facebook. Und wegen G8 und 
Batcheler/Master ist wohl einfach der Stess auch zu hoch. Und später im 
Job eh.

Aber bei Software, insbesondere einer Programmiersprache: Offene Quellen 
gewährleisten, dass das Projekt fortbesteht und zumindest schlimme 
Probleme auch von irgendjemanden behoben werden. Kommerzielles Software 
-- da macht der Hersteller pleite, verliert das Interesse oder verlangt 
plötzlich Mondpreise. Und irgendwie mag ich es, wenn ich mir den Code 
mal ansehen kann, auch wenn ich nicht viel verstehe.

Ich programmiere meine Arduino Uno und Nano Boards alle mit LunaAVR. Für 
Hobbybedürfnisse ist Luna ideal und meilenweit dem ollen Bascom 
überlegen.
Ich habe früher die AVR's in C programmiert, Luna ist aber weit weniger 
fehlerträchtig, selbstdokumentierend und schnell erlernbar. Das ideale 
Tool für den Hobbyisten.