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.
>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.
Hallo, Du willst etwas über eine Beta Version erfahren, die noch in der Entwicklung ist und nur von wenigen Nutzern verwendet wird. Was soll man Dir dann sagen ? Geht - geht nicht... Am Einfachsten ist es sich die V2014 R2.4 zu laden und die Beispiele zu verstehen, dann kann man sich ein eigenes Bild mache.
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...
Guten Tag, die Welt dreht sich weiter und für LunaAVR werden einige Neuerungen angekündigt: http://forum.myluna.de/viewtopic.php?p=5330#p5330
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.
programming schrieb: > 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 Ach, du meinst so was wie http://www.bomerenzprojekt.de/Website/home.html lädt nicht ein? Staun! ;-D
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.
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.