Hallo, ich habe warscheinlich für die meisten hier eine ziemlich banale frage. und zwar ist es so, dass ich gerne mikrocontroller programmieren lernen möchte und mir dafür einen myavr bausatz bestellt habe. So wie ich mittlerweile schon weiß, kann man die Dinger in Assembler, C oder Bascom(Basic) programmieren. Berichtigt mich wenn ich falsch liege. so ich hätte jetzt gedacht dass es für mich warscheinlich am besten und einfachsten wäre in c zu programmieren, weil ich java programmieren kann. Die Frage die sich bei mir nur irgendwie aufstellt ist die, "wie soll ich was programmieren wenn ich nicht weiß was ich zur verfügung habe". also beim java programmieren ist das ja auch so, dass man oft die java-api benutzt und sich darraus bestimmte klassen mit methoden usw. sucht, die das machen, was man gerade brauch, und wo man auch nachlesen kann welche parameter der methode übergeben werden müssen und welche sie wieder zurückliefert usw. Woher weiß man denn mit welchen Methoden ich einen Atmega8 programmieren kann? also ich muss ja irgendwie ne auflistung haben, wo ich sehen kann "aha das macht dass und das macht das" usw. wäre echt nett wenn mir da einer helfen könnte. gruß markus
nen kleiner Tipp: Lies das das entsprechende Datenblatt durch und schau dir hier auf der Seite mal das AVR-GCC-Tutorial an ... Grüße, Ralf,
Es gibt sicherlich noch weitere Sprachen mit denen du einen Microcontroller programmieren kannst. Mir wuerde da z.B noch Forth einfallen. .-) C ist aber schon die beste Wahl einfach deshalb weil es bei Microcontrollern die verbreiteste Sprache ist. Und jetzt zu den guten Nachrichten. Du musst keine Methoden lernen weil es in C keine gibt. :-) Nun ist es so das C fast garnichts kann. Sehr viele Dinge von denen Anfaenger glauben sie sind Teil der Sprache sind eigentlich nur Libaries (z.B printf). Und da ein Microcontroller ziemlich mickrig ist kannst er auch fast nichts von dem Zusatzkram und wenn er es kann dann meist in einer abgespeckten Version die zwischen verschiedenen Controllern noch nichtmal kompatibel sein muss. Es reicht daher vollkommen aus wenn du das Standardwerk zu C von K&R liesst. Und wenn du damit umgehen kannsst dann nochmal die Dokumentation zum verwendeten Compiler. Ansonsten willkommen in der Welt der richtigen (TM) Programmierer die auch Zeiger benutzen duerfen... Olaf
Wie schon geschrieben wurde, Du musst praktisch (fast) alles von Hand machen. Du hast mit C das Werzeug für Schleifen, Funktionen und Vergleiche etc. Dann kannst Du auch noch auf die Hardware des Controllers zugreifen, in dem Du bestimmte Register oder Speicheradresse liest und schreibst oder einzelne Bits in irgendwelchen Speicheradressen manipulierst. Zusätzlich gibt es dann mit praktisch jedem C-Compiler für Mikrocontroller noch eine kleine Laufzeitumgebung, die Dir den Stack und den Heap initialisiert, so dass Du malloc() verwenden kannst usw. Wie schon geschrieben wurde: Willkommen in der echten Welt. Die echte Welt hat nichts mit der Spielzeugsprache Java zu tun.
> also beim java programmieren ist das ja auch so, dass man oft > die java-api benutzt und sich darraus bestimmte klassen mit > methoden usw. sucht, die das machen, was man gerade brauch, und wo > man auch nachlesen kann welche parameter der methode übergeben > werden müssen und welche sie wieder zurückliefert usw. Also API-Docs? Die findest du für die AVR-Libc unter: http://www.nongnu.org/avr-libc/user-manual/
vielen dank für eure Antworten, ich werde dann mal schaun wie es läuft. @Unbekannter: Spielzeugsprache? Kann es sein dass du Java mit Java-Script verwechselst? Java ist eine Objektorientierte Programmiersprache die durch die Objektorientierung relativ ähnlich zu C++ ist.
Jeder der JAVA eine Spielzeugsprache nennt, kann offensichtlich nicht sehr viel weiter als über einen kleinen µController hinausdenken... Unbekannter, ich habe ernsthafte Zweifel ob du der richtige bist um jemanden in der "echten Welt" willkommen zu heißen....
Controllerprogrammierung ist sicherlich eine andere Welt, als Javaprogrammierung - oft viel rudimentärer und näher an der Maschine dran. Ob das aber die echte Welt ist und Java die Spielzeugwelt - ich weiß nicht... Ich würd sagen, dass sind zwei Welten und für Programmierer ist es ein echter Zugewinn, beides kennenzulernen.
genau das mit der hardware wird vermutlich auch mein problem werden. weil so begriffe wie 5-schichten programmierung usw. nützen mir hier ja vermutlich garnix, ich hätte auch lieber was anderes als java gelernt was mir fürs studium mehr gebracht hätte, aber wir hatten da keine wahl weil wir das mit den informatikern zusammen machen mussten :( aber vielen dank für eure antworten!! echt prima
Hey, Kopf hoch ;) C ist von der Syntax her fast identisch mit der von Java, und wenn du statt Java C gehört hättest würde dir das für die Microcontrollerprogrammierung auch nicht sehr viel mehr bringen. Das wichtigste was du wol noch nachholen musst sind Zeiger.
> Unbekannter, ich habe ernsthafte Zweifel ob du der richtige bist > um jemanden in der "echten Welt" willkommen zu heißen Sagen wir mal so. Ich programmiere beruflich schon seit ca. 15 Jahren. Java habe ich zum ersten mal nun schon vor ziemlich genau 10 Jahren programmiert, damals war es noch Version 1.0. Damals fand jeder die Idee dieser Applets so furchtbar hip... Naja, war ein Flopp, wie viele "Anwendungsideen" für Java, aber egal. Klar, Java hat seine Nische gefunden, dennoch bleibt es eine Spielzeugsprache. Java hat in etwa den gleichen Charme wie Pascal.
> Java hat seine Nische gefunden
Und die ist also Applet-Programmierung, oder wie darf ich das verstehen
?
versteh irgendwie nicht wie man Java mit Pascal gleichsetzen kann als Programmierer. Java hat Vor und Nachteile genau wie C++ auch. Der große Vorteil bei Java liegt einfach drin, dass es plattformunabhängig ist! und so weit ich weiß war pascal doch nicht objektorientiert?
C++ ist nicht plattformunabhängig? Mist! Eigentlich sollte doch nur Assembler plattformabhängig sein... Mit JAVA kann man schon schöne (bunte) Sachen machen. Mit C++ kann man JAVA-Compiler schreiben...
Der grosse Nachteil von JAVA ist der Performanceverlust weil es emuliert wird, und der grosse Vorteil von JAVA ist die Plattformenunabhängikeit weil es emuliert wird ;-) Je nach Ansicht halt der Vor- oder Nachteil... Und doch noch zum Thema zu kommen: Du hast logischerweise keine Api weil du auch kein OS hast, du kannst dafür machen was du willst, wodurch man aber auch wieder aufpassen muss. Und wie schon gesagt, C ist verbreitet in der Mikrocontroller Welt, darum hast du auch grosse Chancen Funktionen im Web zu finden, die du dann einbauen und somit nicht alles selber schreiben musst ;-) mfg Andreas
@Rahul C++ ist schon Plattformenunabhängig, die Libraries und APIs ist das Problem... mfg Andreas
Hallo Java als Spielzeugsprache und die hardwarenahe Programmierung als 'echte Welt' zu bezeichnen, finde ich etwas gewagt. Ich würde mal behaupten, dass 95% der verwendeten Software von ihrem Entwickler nicht-hardwarenah geschrieben wurde, und dies auch nicht nötig war. Riesige Datenbanksysteme, ausgefeilte GUIs, komplexe Algorithmen etc. konfrontieren den Entwickler sehr wohl mit der Realität. Ich finde es sogar wesentlich gemütlicher, auf dem kleinen Mikrocontroller zu proggen. Wo sonst hat man schon volle Kontrolle über die gesamte Umgebung, die man nochdazu bis ins Detail kennt? Ist fast ein bisschen wie im guten alten Kinderzimmer... Für 'Java = Spielzeugsprache' gilt sinngemäss selbiges. An die Hardware kommt man zwar nicht 'ran, was aber anspruchsvolle, komplexe Umgebungen in keinster Weise verunmöglicht. Java macht einem die Programmierung sehr einfach (Klare Syntax, streng objektorientiert, sehr grosse Bibliothek, Schutz vor Fallstricken wie Pointern etc.) - aber noch lange nicht alles, was einem das Leben erleichtert, ist ein Spielzeug. Und wer Java mit Applets gleichsetzt, der hat sowieso recht wenig kapiert. Dass Java zwar eher ein Nischendasein fristet, ist wohl korrekt, hat aber wenig mit Technik und viel mit Markt & Geschichte zu tun. Es soll mir mal jemand sagen, was man mit Java nicht kann. Gruss Michael
Wie schon gesagt wurde, aufm MC gibts kein API. Es gibt z.B. keine Instanz, wo Du den Portpin erst umständlich anfordern mußt und dann einen Handle kriegst, um ihn zu manipulieren. Wenn Du einen Portpin setzen willst, dann tus einfach. Aber da gehts schon los, C-Instruktionen sind ja erstmal nicht atomar. Wenn also ein Interrupt nen anderen Portpin des gleichen Ports auch braucht, gehts in die Hose. Du mußt dann als Main-Funktionen immer schön die Hardwarezugriffe in cli() und sei() klammern. Peter P.S.: Warum müssen C++ Programmierer Funktionen als Methoden bezeichnen ? Eine Methode ist doch nur das Prinzip, wie ich etwas machen könnte. Eine Funktion macht es aber wirklich.
> Warum müssen C++ Programmierer Funktionen als Methoden bezeichnen ?
Och, die tun das eigentlich gar nicht. Der korrekte Ausdruck für
"Methode" in C++ ist Elementfunktion.
Gibt es nicht auch mal Java für den AVR? Stand doch mal eine Zeitlang als Aufreisser hier im Forum...
JAVA auf dem MC kannst du dann verwenden wenn du einfach das Ram nicht vollkriegst und im Timig einfach nur einen Quarz zu gross zur Verfügung hast... Nein ich würde C empfehlen... Auch wenns JAVA gibt, ich finde JAVA ist zu gross für AVRs... (Jedem das seine...)
Schon lustig, wie Java-Jünger reagieren, wenn man ihre heilige Kuh kritisiert. Ich habe übrigens hier nie geschrieben, dass die Java-Nische Applets wären. Ich habe geschrieben, dass die Applet-Idee genau so gefloppt ist, wie dutzende andere Versuche, für Java irgendeine Killer-Anwendung zu finden. Warum Java eine Spielzeugsprache ist? Weil Java den Programmieren einen IQ von unter 50 unterstellt. Man hat praktisch C++ hergenommen, und alles was denken erfordert, dafür aber mächtig war, rausgestrichen. Ich möchte nur mal daran erinnern, wie lange es gedauert hat, bis Java endlich wieder ein simples assert() bekommen hat, oder dass man nach Ewigkeiten sich doch entschlossen hat, etwas ähnliches wie Templates aus C++ in Java einzubauen, aber auch hier wieder kastriert ohne Ende. Java ist und bleibt eine Babysprache mit Idioten-Wortschatz.
Lieber unbekannter, Deine persönliche Meinung über Java magst Du ruhig pflegen. Nimm bitte trotzdem zur Kenntniss, dass Java heute alles andere als nur ein Nischen-Dasein führt. Wenn Du mal Stellenanzeigen für Informatiker und Programmierer liest (ich meine Anwendungen auf Computern, nicht auf Mikrocontrollern), solltest auch Du bemerken, dass Java eine sehr viel benutzte Sprache geworden ist, die im Vergleich zu C++ übrigens zahlreiche Vorteile bietet. Diese liegen teilweise gerade darin, dass man damit nicht alles machen kann, was mit C++ geht. Ich kenne Informatiker, die ernsthaft der Meinung sind, dass man aus der Sicht objektorientier Entwicklung 'so einen Dreck wie C++ verbieten sollte, weil man damit zu viel Blödsinn anstellen kann'. Diese Worte stammen nicht von mir, ich denke aber einen Hauch von Verständniss dafür zu haben, was damit gemeint ist. Auf einem AVR würde ich Java nicht einsetzen, für eine Anwendung auf einem PC aber schon. Einen schönen zweiten Osterfeiertag wünsch ich, Michael
Hi das ist ja gerade das Problem von C++ das man damit zu viel machen kann. Bis man diese Sprache wirklich beherscht vergehen Jahre. Die meisten begnügen sich mit einem Subset von C++. Und genau so ein Subset von C++ ist Java. Die Sprache ist schnell erlernbar und beherschbar. Gerade Templates sind zwar ein unheimlich mächtiges Werkzeug aber auch reichlich komplex in der Anwendung wenn es mehr als ein std::vector<T> wird. Matthias
> Ich habe übrigens hier nie geschrieben, dass die Java-Nische Applets
wären.
Hat dir auch niemand unterstellt. Mir ist nur der Verdacht gekommen, du
würdest das tatsächlich glauben, deshalb hab ich mal unschuldig
nachgefragt.
Überhaupt von einer 'Niesche' zu sprechen ist angesichts der weiten Verbreitung von Java der Hauptfehler, würd' ich sagen!
Also für Raumfahrt und ähnlich sicherheitskritische Dinge werden doch auch Sprachen verwendet die "nicht soviel können" wie C/C++ - sind das deswegen Spielzeugsprachen? "Less is more" würde ich mal sagen. Speicherfehler o.ä. (die auch guten Programmieren bei C passieren können) gibt es bei Java nunmal nicht. Keine Pointer zu haben ist hier sogar ein großer Vorteil. PS: Ich programmiere PICs und AVRs in C - kann also durchaus mit Pointern umgehen ;) Auf dem Rechner kommt für mich aber nur Java in frage, denn so schnell kommt man mit C nicht zu guten Ergebnissen. Java spart einem dutzende graue Haare. Und dass die Programme dann auch noch direkt unter Linux, Windows und MacOS laufen ist schon was feines. Applets? Hab noch nie eins geschrieben. Braucht doch keine Sau. Oh und zum Thema Geschwindigkeit: Das meiste wir vom JIT beim Starten der Java Applikation in passenden Maschinencode übersetzt - läuft eigentlich alles recht flüssig. Gibt ja sogar nen 3D Shooter der mit Java erstellt worden ist. http://www.chromethegame.com/ Zugegeben - der nutzt für die 3D Grafik soweit ich mich erinnere OpenGL...
Hi so ein 3D-Shooter macht ja nicht wirklich so viel reine Rechenarbeit auf der CPU (so er denn nicht die Doom3 Engine verwendet) was Java nicht ganz so gut kann wie eine compilierte Sprache. Auch die impliziete Arraygrenzenprüfung kann je nach Algorithmus etwas durchschlagen. Und was passiert wenn der GC zufällig mal anspringt wenn gerade ordentlich was zu tun ist will ich auch nicht wissen. Aber Java ist ja für eine 3D-Spiel auch nicht unbedingt das Werkzeug der ersten Wahl -> Außnahmen bestätigen die Regel. >Speicherfehler o.ä. (die auch guten Programmieren bei C passieren >können) gibt es bei Java nunmal nicht. Das ist so nicht richtig. Auch in Java kann ich einen null-Pointer dereferenzieren (was die VM wie ein OS auch mit einer Exception "bestraft"). Oder ich kann auch beliebige Speicherlöcher produzieren indem ich Objekte so miteinander verknüpfe das der GC sie nie löschen kann da das Objekt noch immer vom Wurzelknoten aus erreichbar ist. Was natürlich nicht passieren kann ist ein vergessenes free()/delete. Das ist aber auch "alles". Wie ich immer wieder gerne schreibe: Jede Sprache für ihren Anwendungszweck. Man kann zwar mit C/C++ wirklich alles machen aber ob das immer Sinn macht wage ich mal zu bezweifeln. Java hat da, wie auch das .NET-System von M$, durchaus einige interessante Aspekte zu bieten. Matthias
"Wie ich immer wieder gerne schreibe: Jede Sprache für ihren Anwendungszweck." Ganz meine meinung: für jedes Problem das richtige Werkzeug verwenden!
> -> Außnahmen bestätigen die Regel. Eben. War ja auch nur ein Beispiel was es auch in Java so gibt und das es keine Nieschensprache mehr ist, sondern sogar schon bei Mainstream geschichten wie 3D Shootern angekommen ist ;) > Das ist so nicht richtig. Eine Nullpointer Exception ist aber IMHO kein echter "Speicherfehler" der mir andere Daten im Programm verhageln kann. Ne NullPointer Exception sagt ja nur - das kein Objekt vorhanden ist. Vor allem lassen sich NullPointer Exceptions schön einfach abfangen. In C kann ich doch munter durch den Speicher durchlaufen und drauflosschreiben wo es eigentlich nicht vorgesehen war... jedenfalls auf nem AVR - wie das auf dem PC ausschaut hab ich noch nie getestet ;)
"Wie ich immer wieder gerne schreibe: Jede Sprache für ihren Anwendungszweck." Das stimmt natürlich :)
@Markus Hermann: Erstmal Glückwunsch zu Deinem myAVR-Einsteigerpaket. Ich hab in dem Osterspiel auf deren Seite das 'myAVR LCD Add-On' und das 'LCD Lehrheft' gewonnen. http://www.myavr.de/shop/artikel.php?artID=15 (19,49 EUR) http://www.myavr.de/shop/artikel.php?artID=16 (9,95 EUR) Wenn Du Interesse an den beiden Artikeln hast, kannst Du ja mal ein Angebot an 'worldbelongs2me at web dot de' schicken. Rechnung ist von letzter Woche oder so und beides ist noch Original verpackt. Grüße, Karl
Java is doch schrott. OK, vielleicht ist es schön wenn man eine Anwendung auf linus und win oder mac ausführen kann, ABER was ist, wenn es nicht bei einer Anwendung bleibt...Java bremst den rechner ungemein aus wenn mehrere Programme Laufen. Und dann beschwert sich wieder jeder weil sein rechner (trotz weniger anwendungen) langsam ist. Die meisten anwender haben immernoch windoof und wiso soll dieser großteil von anwendern geschwindigkeitseinbussen eingehen nur für diesen Portbilitäts kram ??? Wenn eine Software auf meinem rechner Läuft soll diese schnell laufen und den rechner möglichst wenig ausbremsen und da isses mir egal ob das Teil auch unter Linux oder sonst wo läuft. Ich bin jetzt schon oft genug vor diesen ehlend lahmen Java Programmen gehockt. Beispiel: wenn auf spielkonsolen eine vm laufen würde. Würdet ihr euch ein Spiel kaufen das ruckelt ohne ende, dafür aber auch auf einer anderen Konsole läuft ? ich glaube nicht. Jetzt kommen sogar immer mehr embedded systeme auf den markt die sich mit Java Programmieren lassen. und durch dieses Java ist auch der ARM mit 100 mhz wieder auf dem niveau eines kleinen AVRs (ich spreche aus erfahrung). In meinen Augen ist und bleibt Java eine Kindergartensprache. Meine Meinung !
@Simon: Full Ack. Problem ist einfach, daß momentan im Studium Java gedrückt wird und es halt 'hipp' ist. Da wollen Arbeitgeber natürlich nicht nachstehen. Ich hab damals als Sun-Developer meine Dipl.-Arbeit in Java geschrieben. Wie oft da das SDK GRUNDLEGEND(!) geändert wurde war zum Kotzen. Java hat für mich absolut NIX an Vorteilen gebracht. Vielleicht wurde da mittlerweile was behoben (sind schon ein paar Jährchen her), aber das ist dann auch wieder nur rumgebessert wie an der Gesetzgebung hier im Lande. Nenn mir einer einen vernünftigen Grund für Java. Das mit der Portabilität ist übrigens das ausgelaugteste was es gibt. Meine Programme laufen unter Linux und Windows. Sind relativ fix und haben unter beiden OS GUIs (wenn benötigt. Meistens brauchen die sowas nicht). Den Krampf mit AWK(?)/Swing kann man sich schenken. BTW: Wenn man es übrigens vernünftigt handhabt sind Pointer was Tolles und echt ein Verlust in Java. Grüße, Freakazoid
Hi Große (Server)-Anwendungen werden oftmals in Java geschrieben da damit der Umzug auf eine andere Architektur (z.B. x86 -> UltraSparc/Power/PARISC) problemlos (im Prinzip reicht ein cp) funktioniert. Viel was in C auf x86 mit Pointern machbar und auch zulässig ist wird dir von einer anderen Architektur um die Ohren gehauen. Verteilte Anwendungen in heterogenen Netzen sind ein weiterer Anwendungszweck. Niemand will für eine solche Umgebung zig Binaries für 10 verschiedene Hardwareplatformen vorhalten und warten. Die Welt der Rechnersysteme ist größer als das was auf privaten und beruflichen Schreibtischen steht. Matthias
> Beispiel: wenn auf spielkonsolen eine vm laufen würde. Würdet ihr euch > ein Spiel kaufen das ruckelt ohne ende, dafür aber auch auf einer > anderen Konsole läuft ? ich glaube nicht. Pff..wenn du wüsstest, wieviele moderne Spiele einen Grossteil der Gamelogik mit irgendeiner eingebetteten Skriptsprache implementiert haben.
@Bartli: Das sind aber Skripte, die die Gameengine interpretiert. Es ging wohl darum was wäre, wenn diese in Java geschrieben wäre. Man braucht ja wohl eine Schnittstelle zu Engine. @Matthias: Okay. Andere Architekturen wäre ein Grund. Zudem endlich mal einer den man akzeptieren könnte (also Portierbarkeit zwischen Architekturen. Das mit der Portierbarkeit zwischen verschiedenen OS ist Mumpitz). Allerdings wüßte ich keinen Grund in einem Rechenzentrum mehrere Architekturen vorrätig zu haben. Was das alleine schon an Verwaltung verschlingt ;-( Es gibt auch andere Sprachen, die Platformunabhängig sind. Auch Skriptsprachen (Perl). Man kann da einiges an Geschwindigkeit rausholen und teilweise sind die Programme/Skripte in Geschwindigkeit/GUI nicht von Native-C zu unterscheiden. Grüße, Freakazoid
Cool, jetzt hab ich durch copy&paste unter Karl gepostet ;-) @Karl: Sorry. Grüße, Freakazoid
> Das sind aber Skripte, die die Gameengine interpretiert.
Das ist natürlich richtig, aber, pfuibäh, es ist schlussendlich nicht
Code, der nativ ausgeführt wird, und darum muss es Kacke sein.
@Bartli > Das ist natürlich richtig, aber, pfuibäh, es ist schlussendlich nicht > Code, der nativ ausgeführt wird, und darum muss es Kacke sein. ??? Wie kommst Du auf den Trichter? Ich hab kein Problem mit 'nativ' oder 'interpreted' Code. Ich sehe nur keinen Grund (okay, dank Matthias kann ich mir wage einen vorstellen g) für Java. Ich entwickle z.B. viel in Skriptsprachen. Es geht ja eigentlich auch darum eine für sich / für das Problem passende Sprache zu benutzen (Kern ist natürlich der Algorithmus welcher sich wohl in jeder Sprache implementieren läßt). Meiner Meinung nach wird aber alles in Java von bereits vorhandenen Sprachen abgedeckt -> nutzlos. Grüße, Freakazoid
> Wie kommst Du auf den Trichter?
Das ist eine weit verbreitete Ansicht, über die ich mich gerne mal
lustig mache :D
Dich habe ich damit jetzt nicht einmal gemeint.
@Bartli: Okay. Aber meine Erklärung war vielleicht trotzdem angebracht, bevor jemand anders sowas vermutet ;-) Grüße, Freakazoid
> Auf dem Rechner kommt für mich aber nur Java in frage, denn so schnell
kommt man mit C nicht zu guten Ergebnissen. Java spart einem dutzende
graue Haare.
Volle Zustimmung. Mit Java geht einfach vieles schneller und einfacher
als mit den meisten anderen Programmiersprachen. Zudem gibt es gute,
freie IDEs und sehr viele Bibliotheken. Java als Spielzeug zu
bezeichnen, ist allerdings eine ganz seltsame Logik. Es geht ja nicht
darum, möglichst den harten Typen 'rauszuhängen, sondern mit
vernünftigem Lern- und Arbeitsaufwand ein Problem zu lösen. Und das
geht mit Java nunmal sehr effizient, da die Sprache sowohl sehr
mächtig, aber auch sehr einfach ist.
Natürlich forder Java gegenüber nativ compilierten Sprachen den Rechner
etwas mehr. Von der Performance bei der Ausführung her gibt es
allerdings schon seit längerer Zeit nicht mehr allzugrosse Unterschiede
beispielsweise zu C. Ein echtes Problem ist aber der Overhead durch die
Runtime Engine. Kleine Java-Tools, die nebenher laufen können so den
Computer tatsächlich etwas ausbremsen.
Übrigens fällt mir auf, dass Java häufig von Personen kritisiert wird,
die kaum oder nur wenig damit in Berührung kamen. Deswegen reagieren
Java-Fans meist auch relativ heftig auf Kritik, da diese oftmals nur
schlecht begründet ist (wenn die Kritiker auch kaum eine Ahnung haben,
wovon sie sprechen).
Interessant wird das ganze, wenn jemand, der überwiegend mit Java gearbeitet hat, plötzlich auf einen C- oder C++-Compiler losgelassen wird. Könnte man die ertönenden frustrierten Schreie in elektrische Energie umwandeln, könnte man sicherlich das eine oder andere Atomkraftwerk abschalten.
@Mr.Chip: > Von der Performance bei der Ausführung her gibt es allerdings schon > seit längerer Zeit nicht mehr allzugrosse Unterschiede beispielsweise > zu C. Das war zu meiner Zeit aber völlig anders. > Ein echtes Problem ist aber der Overhead durch die Runtime Engine. > Kleine Java-Tools, die nebenher laufen können so den Computer > tatsächlich etwas ausbremsen. Das kann natürlich sein. Vielleicht ist der Overhead geringer, wenn mehrere Java-Programme gleichzeitig laufen. Hoffe die Runtime wird dann geshared. Dann sollte sich das Bild zugunsten Java verbessern. > Übrigens fällt mir auf, dass Java häufig von Personen kritisiert > wird, die kaum oder nur wenig damit in Berührung kamen. Das ist nicht richtig. Meine Dipl.-Arbeit ist in Java geschrieben und ich hatte damals engen Kontakt mit SDK-Entwicklern bei Sun. > Deswegen reagieren Java-Fans meist auch relativ heftig auf Kritik, > da diese oftmals nur schlecht begründet ist (wenn die Kritiker auch > kaum eine Ahnung haben, wovon sie sprechen). Naja. Meistens kommt als einziges Gegenargument 'Portierbarkeit' zwischen OS (oben erwähnt). Damit disqualifiziert sich jeder Java-Entwickler. BTW: Wir haben hier einen Uni-Abgänger der meint unbedingt Java verwenden zu müssen. Der Server ist dermaßen unter Last, daß es nicht mehr feierlich ist. Vom dadurch entstehenden Wartungsoverhead mal abgesehen. Grüße, Freakazoid
Ich finde sowiso, dass ein Großteil der vielgelobten Plattformunabhängigkeit von Java eher durch die umfangreiche Klassenbibliothek als durch die VM begründet ist. Dazu kommt dann noch die Einfachkeit der Sprache und des Compilers und ein paar gute IDEs und schon neigt man dazu Java auch mal schnell da einzusetzen, wo eigentlich gar keine VM nötig währe. Wenn es so ein Gespann von umfangreicher Bibliothek, einfacher Sprache und Compiler eingebettet in ner netten IDE nativ verfügbar für alle Plattformen gäbe dann währe Java sicherlich nicht so erfolgreich. Sowas währe dann zwar nur im Quellcode plattformunabhängig, aber wann außer für Applets ist Binärkompatibität denn wirklich nötig wenn man ohne Mehraufwand native Versionen bereitstellen kann?
> ... wann außer für Applets ist Binärkompatibität denn wirklich nötig
wenn man ohne Mehraufwand native Versionen bereitstellen kann?
Da stimme ich dir eigentlich zu. Ich verstehe sowieso nicht ganz, warum
Sun Java nicht auch nativ-compilierbar macht, so dass man wahlweise auf
die VM und die Plattformunabhängigkeit verzichten kann. Ich wage zu
behaupten, dass die Programmiersprache Java eine wirklich überzeugende
Sprache ist, ihre Probleme jedoch vorallem im VM-Konzept begründet sind
- darauf könnte man meist aber sehr gut verzichten, was die Sprache noch
vielfältiger einsetzbar machen würde.
In einem Punkt muss man aber den Java-Kritikern bzw. besonders den
C-Programmierern ganz sicher Recht geben: Wirklich umzugehen mit der
Maschine lernt man erst mit Programmiersprachen wie C/C++ oder gar
Assembler, die einem auch wirklich auf das Silizium los lassen.
Relativiert wird dieser Aspekt dadurch, dass optimale Hardwarenutzung
nur ein Aspekt unter vielen ist, die einen guten Programmierer
ausmacht.
> der vielgelobten Plattformunabhängigkeit von Java eher durch > die umfangreiche Klassenbibliothek als durch die VM begründet ist. Naja. Der springende Punkt ist: Java definiert ja nicht nur eine Sprache. Java definiert ja im Grunde die komplette Plattform. Und erst diese wird dann auf der Zielhardware emuliert. Damit ist es natuerlich relativ leicht plattformunabhängig zu sein, denn im Grunde arbeitet der normale Programmierer immer nur gegen ein und dieselbe Plattform, nämlich die die durch Java definiert worden ist.
>ihre Probleme jedoch vorallem im VM-Konzept begründet sind Naja, das VM-Konzept hat auch Vorteile, MS setzt ja mit .NET auch auf ne VM obwohl die das von der Plattformunabhängigkeit her zumindest sicher nicht nötig hätten. Was ist eigentlich mit so Sachen wie dem Garbage Collector oder diesen try/catch Statements? Das sind doch bestimmt Funktionen der VM und nicht der Sprache, oder? >Wirklich umzugehen mit der Maschine lernt man erst mit Programmiersprachen wie C/C++ oder gar Assembler das ist wol richtig, zumindest wenn man ohne Betriebssystem arbeitet, aber das ist ja auch eine Frage des Abstraktionslevels, und der ist ja durchaus gewollt.
> Da stimme ich dir eigentlich zu. Ich verstehe sowieso nicht ganz, warum > Sun Java nicht auch nativ-compilierbar macht. Ob Sun Compiler welche native Binaries erzeugen anbietet oder jemals angeboten hat wüsste ich nicht einmal, aber zumindest gibt es solche Compiler, z.B. gcj.
> Interessant wird das ganze, wenn jemand, der überwiegend mit Java > gearbeitet hat, plötzlich auf einen C- oder C++-Compiler > losgelassen wird. > > Könnte man die ertönenden frustrierten Schreie in elektrische > Energie umwandeln, könnte man sicherlich das eine oder andere > Atomkraftwerk abschalten. Das kann aber durchaus auch passieren, wenn du einen C-Programmierer auf einmal Java-Code schreiben lässt. Übrigens erinnerte mich dein Posting ein bischen an die Monster-AG ;-)
Bitte 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.