Verehrter Herr Professor Dr. Dr. (h.c.) med. vet. Duden,
erlaube mir untertänigst anzumerken, dass sich offensichtlich gewisse Meeressäuger von einem altgriechischen Orakel unterscheiden. Außerdem meint Ihr allergnädigster Herr Namensvetter aus der Sprachwissenschaft: "Del|phin, auch: Delfin der; -s, -e : eine Walart".
Java, C, C++, Fortran, Cobol sind Sprachen, mit denen man einen Job findet. Weitere: C#, Visual Basic unter Unix/Linux außerdem notwendig: Bash (und/oder andere Shell-Sprachen), Perl WWW: Perl/PHP Datenbanken: SQL (hab garantiert was vergessen)
Wenn du aber was aus Spaß am Programmieren lernen willst, dann könnte Ruby was für dich sein.
Bei einer meiner letzten Anstellungen wurde hauptsächlich Ruby verwendet und ist hoch im kommen, eben wegen diesen Vorteilen!
Ruby ist sehr einfach erlernbar und sehr mächtig ...
Ruby ist nicht nur Spass, sondern auch sehr gut einzubauen (z.B.: in C, Pascal, ..., - Code: Damit erreicht man höhere Flexibilität in fix kompilierten Programmen.)
jap! die einfachheit von ruby war auch der grund warum ich das als erste sprache mir genauer und freiwillig angeschaut habe. syntax sieht ueberzeugend uebersichtlich aus und das objektorientierte programmieren ist mir durch ruby wesentlich naeher gebracht wurden. schade das es noch keinen compiler fuer native code gibt - aber bitte mit gc
Naja kommt drauf an was du machen willst...also Ruby, Perl, etc. sind ja Skriptsprachen, daher nicht für rechenintensive Programme geeignet. Generell kann man IMO sagen, dass um so komplexer und strukturbehafteter ein Projekt ist, umso eher eine Compilersprache gut ist. Naja das tolle an Skriptsprachen, vor allem an solchen wie Ruby, Perl oder Python, ist, dass sie relativ leicht erlernbar sind, der Code kurz ist (ein Helloworld braucht eine Zeile..) und natürlich nicht kompiliert werden müssen. Von wegen Kürze und Einfachheit des Codes steht Ruby wohl ganz vorne, was ich dir auch als Skriptsprache empfehlen würde ;). Naja als Compilersprache würde ich Java oder C++ empfehlen, je nach dem, ob dir Plattformunabhängigkeit und eine featurereiche Programmiersprache wichtig sind (-> Java). An C++ führt kaum ein Weg vorbei, wenn du rechenintensive Programme schreiben willst oder Hardwarenähe suchst. Oder du programmierst in C, was IMO nur Vorteile hinsichtlich der (mathematischen) Verifizierung von Code nützlich ist, was bei C++ Code soweit ich weiß kaum möglich ist. Dass C-Maschinencode schlanker als C++-Code sein soll ist ein Gerücht, dass wohl vor allem dadurch zustande kam, dass die meisten Betriebssysteme von Natur aus nur C unterstützen und der typische C-Compiler bei _weitem_ ausgereifter als der typische C++Compiler ist ;-). Ganz vorne ist da wohl der Comeau-C++-Compiler... Hmm...naja soweit ich weiß wurd Pascal sogar als Lernsprache entwickelt =)...
Warum soll Python eine Scriptsprache sein, Java aber nicht? Wird bzw. kann nicht beides kompiliert werden? Wird nicht beides zur Laufzeit interpretiert?
Ich mag mich irren, aber soweit ich weiss laufen Java und Python in einer VM, und werden vorher in Bytecode (bei Java .jar, bei Python .pyc) übersetzt und dieser Bytecode wird dann in der VM ausgeführt. Das heisst, dass Python eigentlich keine Scriptsprache im klassischen Sinne ist. Ob das nun ein Vor- oder Nachteil ist, ist Thema vieler Flamewars..
Fagt ist doch nun mal, daß sowohl python als auch Java und ruby zur Laufzeit interpretiert werden. Die erzeugten pyc/class/*-Dateien sind _nicht_ nativ und werden durch einen Interpreter dynamisch zur Laufzeit ausgewertet und entsprechend umgesetzt. Daraus würde ich folgern, dass Java genauso eine Scriptsprache ist wie Python oder Ruby.
ruby wird sowohl einen JIT als auch einen AOT Compiler besitzen wird. realisiert über einen ruby->c umsetzer. so kann ruby-sharedobject in ruby schreiben.
und was heißt nativer code? Fakt ist das C(++) auch keinen Microcode erzeugt, oder? ;-)
> und was heißt nativer code? Fakt ist das C(++) auch keinen Microcode erzeugt, oder?;-)
Durchaus richtig. Zudem lassen sich aus den "kompilierten" Java/Python Quellen auch ausführbare Dateien erzeugen die dann keinen installierten Interpreter mehr bedürfen. Sieht man die Hardware als Interpreter, so ist letztendlich alles scriptingcode...
Du kannst deinen Pythoncode schreiben, als "hello.py" abspeichern und ihn mit "python hello.py" ausführen. Unter Java erstellst du deinen Code und lässt dann den Bytecodecompiler drauf los. Dann hast du diese *.class-Dateien (Binärcode!), die dann mit dem JRE benutzbar sind. Dieser Bytecode ist allerdings kein nativer Maschinencode, sonst wär er schließlich nicht plattformunabhängig. Deshalb muss er nochmal weiter verarbeitet werden. Abgesehen davon gibts ja noch Javascript, welches als Skriptsprache dient...
Dass C-Maschinencode schlanker als C++-Code sein soll ist ein Gerücht, dass wohl vor allem dadurch zustande kam, dass die meisten Betriebssysteme von Natur aus nur C unterstützen und der typische C-Compiler bei _weitem_ ausgereifter als der typische C++Compiler ist;-). Das ist wirklich so. Liegt aber daran, dass man in C keine Objekte benötigt, während in C++ selbst die Ausgabe auf der Konsole über das std::cout-Objekt erfolgt. Auch wird neuer Speicherbereich via new angefordert sowie im Anschluss das Objekt konstruiert, während in C ein einfaches malloc reicht. Klar, dass C++-Objektcode somit größer sein muss.
Ich versteh nicht ganz dein Argument. C kennt keine Objekte, C++ kennt Objekte. Warum sollte der Aufwand höher sein, wenn die gesamte Betriebsumgebung objektorientiert ist? Ob du jetzt eine Klasse erstellt mit ein paar Integerwerten und von der Klasse dann einen Array bildest oder ob du mehrere Integerarrays bildest - wo liegt da letztendlich der Unterschied? >Auch wird neuer Speicherbereich via new angefordert sowie im >Anschluss das Objekt konstruiert, während in C ein einfaches >malloc reich Du scheinst C++ noch nie benutzt zu haben. "new" _ist_ "malloc", mit dem Unterschied, dass es für den Programmierer leichter zu benutzen ist.
Ruby ist sehr gut dokumentiert. Hier ein paar Links:
ruby-lang.org. Dort einfach weiter den Links folgen.
Sehr gutes Buch (selber gelesen) Programming Ruby (Die erste Auflage gibts auch online, wobei der Kauf der 2. AUflage trotzdem lohnt, wenn man erst mal die Onlineausgabe gelesen hat.)
Von Chunky Bacon Chunky Bacon am Mo, 28. November 2005 um 16:48 #
Falls du Ruby nicht nur lernen willst, sondern dabei unterhalten werden, und ab und zu mal herzhaft lachen willst, kann ich dir diese Einführung in Ruby empfehlen. So was gabs noch nie *g* Der Typ ist durchgeknallt, aber gut. Am besten du holst es dir über die Development Site, da isses am aktuellsten: http://poignant.rubyforge.org/ Ansonsten hier, ist aber momentan etwas überlastet die Seite (vll wegen pro-linux? *g*): http://poignantguide.net/ruby/
es gibt ein deutsches forum genannt rubyforen wo man rund um fragen bezueglich ruby geholfen bekommt. ich bin gespannt wie sich ruby so entwickelt gegenueber den alternativen.
Man kann grundsätzlich in beiden Sprachen jedes Problem lösen, was mir momentan einfällt, die Frage ist immer nur wie. Ruby ist recht einfach, während ich Perl doch eher als umständlich beschreiben muss. Ausserdem produziert man in Perl meiner Meinung nach read-only Code, was ich als hauptsächlichen Nachteil empfinde. In Ruby kann man auch nach 2 Jahren noch nachvollziehen, was man gemacht hat und lesbarkeit ist nunmal eine wichtige Eigenschaft einer Programmiersprache, besonders in Zeiten von Open Source Software. Allerdings gefällt mir da Python im Moment noch ein wenig besser.
> Ruby ist recht einfach, während ich Perl doch eher als umständlich beschreiben muss.
Zitat aus http://www.rubycentral.com/faq/rubyfaqall.html : Ruby's syntax and design philosophy are heavily influenced by Perl. [...] If you like Perl, you will like Ruby and be right at home with its syntax. If you like Smalltalk, you will like Ruby and be right at home with its semantics.
doch, lesbarkeit ist zwar ganz sicher nicht das einzige oder entscheidende, aber es gehört u.a. dazu. sicher kann man in jeder sprache so und so programmieren, aber in ruby ist es eine stufe _natürlicher_ ,es geht leichter vonstatten, kommt automatischer. bei brainfuck wird dies z.b. definitiv nicht der fall sein, oder? python kenn ich nicht gut genut, aber perl ist definitiv nicht dazu geeignet, lesbarkeit implizit zu fördern. aber vor allem ist meiner meinung nach der spass, den ruby tatsächlich bringt, das entscheidende.
Vielleicht gibt es irgendwen, der lieber Brainfuck als Ruby liest. IMO gehört zum Können einer Programmiersprache nur, welche Sprachen sie akzeptieren kann. Der Rest ist egal... ;-)
Wie man ja weiss ist die standard ruby vm langsam (eh die ersten kontra posts kommen erst informieren *fg*) es sind ja mehere VMs in arbeit, wie sieht es aus das eine die standard vm ersetzt? weiss da jemand genaueres?
Ruby ist nicht stark getypt. Dies ist ein gravierender unterschied zu Java. Nicht stark getypte Sprachen werden heute in neuen Projekten hauptsächlich zu rapid prototyping und scripting eingesetzt. Dagegen halte ich in großen Projekten (> 2 Entwickler) starke Typisierung für eine hervorragende Eigenschaft, um einfache Programmierfehler zu vermeiden. Daher kann man meiner Meinung nach ruby mit java kaum vergleichen.
oh mein gott, die typisierung ist immer wieder so ein pseudo-argument. nur weil typisierung einen höheren aufwand erzeugt, macht es die sache weder sicherer noch überschaubarer. an den meisten stellen ist sie einfach unnatürlich und lenkt von den wesentlichen aufgaben ab, auch was die sicherheit betrifft. übrigens, was sind _einfache_ programmierfehler? i.d.r. ist die typisierung gar nicht das problem...
Das sehe ich ähnlich.. Sicherlich unterbindet starke Typisierung einige Fehler, aber eigentlich sollten Fehler (und vor allem Fehler dieser Art) vom Programmierer vermieden werden. Gerade Java verleitet viele Programmierer (leider nicht nur Hobby~) zum einfach so dahinprogrammieren, wenn ich n Fehler mache wirds mir der Compiler schon sagen.. Und durch solche schlechte Programmierung (und ok, den früheren bug-gesähten VMs) hält sich bei Java ewig das Vorurteil Java sei langsam. Ist es nicht, wenn man programmieren kann!
Aber wir sind eigentlich bei Ruby und ich kann Java aus anderen Gründen auch nicht leiden..
Naja, oft geht die Typisierung mit einer generellen Notwendigkeit der definierung von Variablen einher (muss ja auch sein dafür), und das ist wiederum eine große Hilfe bei der Ordnung.
In vielen dynamisch typisierenden Sprachen kann eine Variable direkt und ohne definierung verwendet werden, oder diese kann jederzeit überall geschehen. Das hat den Nachteil das mitten im Code eine unbekannte Variable auftauchen kann, deren Typ und Quelle nur schwer/unständlicher zu finden ist.
Hast du aber den Typ erst definieren müssen wird der Code meiner Erfahrung nach eher an solchen stellen durchdacht. Es ist einfach ein Mehraufwand der zum Nachdenken anregt.
Es ist meiner Meinung einfach auch so das zu wenige Hürden zu schnell zu fehlern verleiten. Es muss so nicht kommen, aber es kann.
Vor allem ermöglicht die zwingende vorherige Deklaration von Variablen ein Completing in diversen IDEs. Je nach Länge mancher Variablen hat man wirklich keine Lust, den Namen dieser Variablen zig-Mal neuzuschreiben.
Zu starke Typisierung macht dann aber auch oft Probleme weil es den Code sehr aufblaeht. Das beste sind Zwischenloesungen wo man die Wahl hat zwischen dynamischer und statischer Typisierung. Sprachen die dies koennen sind z.B. Objective-C oder Common Lisp.
In dem Artikel von Bruce Eckel werden Paradigmen der objektorientierten Programmierung verletzt. Es darf z.B. einfach nicht sein, dass ein Objekt der Klasse "Bob" in "Pets" landet, weil "Bob" nun mal kein "Pet" ist.
Wenn ich seinen Artikel korrekt verstehe will er das tatsächlich so machen.
Da Frage ich mich allerdings warum er nicht alle entsprechenden Objekte von einer Classe ableitet und dann diese erwartet. Damit sollten auch die abgeleiteten Klassen gültig sein.
Fast jede aktuelle OO Sprache besitzt dafür eigentlich eine Lösung.
Genau das will er ja eben nicht, weil ihn die Hierarchie seiner Meinung nach einschränkt. Warum verwendet er dann allerdings als Gegenbeispiel Python? Da muss man sich schließlich an vorgegebene Einrückungen halten. Gibt sicherlich einige, die das als zu einschränkend empfinden.
Man sollte nicht verschweigen, dass dynamisch getypte Sprachen einen nicht zu unterschätzenden Laufzeitnachteil gegenüber statisch getypten Sprachen haben. Im Beispiel muss zur Lauzeit geprüft werden, ob eine bestimmte Methode exisiert. Ich persönlich finde es gut, zwischen dynamisch und statisch einen Kompromiss zu schließen, um die Vorteile beider Welten zu vereinen. Boo macht das z.B so. Fühlt sich wie eine dynamisch getypte Sprache an, ist aber intern statisch.
Um die ganzen *.rb *.py *.pl etc nutzen zu können muß man den jeweiligen Interpreter installieren. Wo ist die Grenze? Ich verstehe das es für bestimmte Anwendungen optimierte Werkzeuge gibt - wie z.B. Brotmesser und Tomatenmesser- aber irgendwann ist schluss. Für den User machen diese Interpreter doch alle das gleiche: Text-Code in Maschinen-Code übersetzen.
Wozu soviele Bibliotheken, die installiert werden müssen... Gtk, QT, zlib, Xlib, xine-lib... Warum gibt es nicht eine einzige Bibliothek, die alles kann?
Und die ganzen Werkzeuge, die es so gibt und die man sch u.U. kaufen muss... Schraubenzieher, Hammer, Bohrer, Messer, Gabel, Uhr... Warum gibt es nicht ein Schweizer Taschenmesser, das wirklich all diese Dinge enthält?
> Und die ganzen Werkzeuge, die es so gibt und die man sch u.U. kaufen muss... Schraubenzieher, Hammer, Bohrer, Messer
Aus User-Sicht ist es aber irrelevant ob ein Programm mit Python oder Ruby erstellt wurde, das Programm soll seinen Zweck erfüllen. Das ist als ob Handwerker für dasselbe Ergebnis unterschiedliche Werkzeuge anfordert - mach das mal dem User klar wieso er soviel installieren soll. Für Python gibt es z.B. py2exe wo Python-Code in Maschinencode umgesetzt wird(als .exe für Win) - wozu wohl?
> Ich hoffe, deine Frage ist beantwortet.
Es wird demnach in Zukunft noch mehr Interpreter geben? Ich habe nichtmal Ruby installiert...
schon mal nachgeschaut wieviel programme auf wievielen bibliotheken aufbauen?!
das ganz ist doch völlig egal. unter windows bringen die programme die dlls und exen mit, in einer distro mach das ganze der paketmanager und wer selbst kompiliert naja 5min extra.
in einer zeit wo 1GB RAM normal ist, kommts doch auf das auch nicht an, und dem user ist es wohl völlog egal ob lisp, ruby, c++, oder doch c#, war ;-)
(mein Lehrer ist immer noch bei Pascal
Ja und? Mit Delphi (trotzt .Net) ist Pascal auch heute noch eine wichtige und effiziente Programmiersprache.
erlaube mir untertänigst anzumerken, dass sich offensichtlich gewisse Meeressäuger von einem altgriechischen Orakel unterscheiden.
Außerdem meint Ihr allergnädigster Herr Namensvetter aus der Sprachwissenschaft: "Del|phin, auch: Delfin der; -s, -e : eine Walart".
Aller ergebenste Grüße
Alefanz ;-)
Weitere: C#, Visual Basic
unter Unix/Linux außerdem notwendig: Bash (und/oder andere Shell-Sprachen), Perl
WWW: Perl/PHP
Datenbanken: SQL
(hab garantiert was vergessen)
Wenn du aber was aus Spaß am Programmieren lernen willst, dann könnte Ruby was für dich sein.
Ruby ist sehr einfach erlernbar und sehr mächtig ...
Ruby ist nicht nur Spass, sondern auch sehr gut einzubauen (z.B.: in C, Pascal, ..., - Code: Damit erreicht man höhere Flexibilität in fix kompilierten Programmen.)
Ruby ist einfach
Perl ist schon an zu vielen Orten eingebaut und nicht mehr wegzudenken, wie C, C++, ...
Ruby ist hingegen für neuere Projekte einfach genial ...
Wird bzw. kann nicht beides kompiliert werden? Wird nicht beides zur Laufzeit interpretiert?
Das heisst, dass Python eigentlich keine Scriptsprache im klassischen Sinne ist. Ob das nun ein Vor- oder Nachteil ist, ist Thema vieler Flamewars..
MfG
Daraus würde ich folgern, dass Java genauso eine Scriptsprache ist wie Python oder Ruby.
und was heißt nativer code? Fakt ist das C(++) auch keinen Microcode erzeugt, oder? ;-)
MfG
Durchaus richtig. Zudem lassen sich aus den "kompilierten" Java/Python Quellen auch ausführbare Dateien erzeugen die dann keinen installierten Interpreter mehr bedürfen. Sieht man die Hardware als Interpreter, so ist letztendlich alles scriptingcode...
Das ist wirklich so. Liegt aber daran, dass man in C keine Objekte benötigt, während in C++ selbst die Ausgabe auf der Konsole über das std::cout-Objekt erfolgt. Auch wird neuer Speicherbereich via new angefordert sowie im Anschluss das Objekt konstruiert, während in C ein einfaches malloc reicht. Klar, dass C++-Objektcode somit größer sein muss.
>Auch wird neuer Speicherbereich via new angefordert sowie im
>Anschluss das Objekt konstruiert, während in C ein einfaches
>malloc reich
Du scheinst C++ noch nie benutzt zu haben. "new" _ist_ "malloc", mit dem Unterschied, dass es für den Programmierer leichter zu benutzen ist.
Wo finde ich Infos, um Ruby als Programmiersprache zu lernen?
Gibt es ein gutes Buch zum Einstieg (Papier oder PDF)?
Danke!
ruby-lang.org. Dort einfach weiter den Links folgen.
Sehr gutes Buch (selber gelesen)
Programming Ruby (Die erste Auflage gibts auch online, wobei der Kauf der 2. AUflage trotzdem lohnt, wenn man erst mal die Onlineausgabe gelesen hat.)
ja,
Ruby Don't Take Your Love To Town" (Kenny Rogers)
Und viel spass...ich mach schon fast alles damit..finde Ruby einfach nur genial!!
http://poignant.rubyforge.org/
Ansonsten hier, ist aber momentan etwas überlastet die Seite (vll wegen pro-linux? *g*):
http://poignantguide.net/ruby/
Viel Spaß *g*
ich bin gespannt wie sich ruby so entwickelt gegenueber den alternativen.
Das gabs doch schonmal. Das haben sie doch damals bei PHP und bei Python auch gesagt.
Hmm.
Zitat aus http://www.rubycentral.com/faq/rubyfaqall.html :
Ruby's syntax and design philosophy are heavily influenced by Perl. [...]
If you like Perl, you will like Ruby and be right at home with its syntax. If you like Smalltalk, you will like Ruby and be right at home with its semantics.
NikN
sicher kann man in jeder sprache so und so programmieren, aber in ruby ist es eine stufe _natürlicher_ ,es geht leichter vonstatten, kommt automatischer.
bei brainfuck wird dies z.b. definitiv nicht der fall sein, oder?
python kenn ich nicht gut genut, aber perl ist definitiv nicht dazu geeignet, lesbarkeit implizit zu fördern.
aber vor allem ist meiner meinung nach der spass, den ruby tatsächlich bringt, das entscheidende.
NikN
zu Java. Nicht stark getypte Sprachen werden heute in neuen Projekten
hauptsächlich zu rapid prototyping und scripting eingesetzt.
Dagegen halte ich in großen Projekten (> 2 Entwickler) starke Typisierung für eine
hervorragende Eigenschaft, um einfache Programmierfehler zu vermeiden.
Daher kann man meiner Meinung nach ruby mit java kaum vergleichen.
Gruß,
Manuel
Aber wir sind eigentlich bei Ruby und ich kann Java aus anderen Gründen auch nicht leiden..
In vielen dynamisch typisierenden Sprachen kann eine Variable direkt und ohne definierung verwendet werden, oder diese kann jederzeit überall geschehen. Das hat den Nachteil das mitten im Code eine unbekannte Variable auftauchen kann, deren Typ und Quelle nur schwer/unständlicher zu finden ist.
Hast du aber den Typ erst definieren müssen wird der Code meiner Erfahrung nach eher an solchen stellen durchdacht. Es ist einfach ein Mehraufwand der zum Nachdenken anregt.
Es ist meiner Meinung einfach auch so das zu wenige Hürden zu schnell zu fehlern verleiten. Es muss so nicht kommen, aber es kann.
Interessanter Artikel dazu ("Strong Typing vs. Strong Testing", Bruce Eckel):
http://www.mindview.net/WebLog/log-0025
Da Frage ich mich allerdings warum er nicht alle entsprechenden Objekte von einer Classe ableitet und dann diese erwartet. Damit sollten auch die abgeleiteten Klassen gültig sein.
Fast jede aktuelle OO Sprache besitzt dafür eigentlich eine Lösung.
Warum verwendet er dann allerdings als Gegenbeispiel Python? Da muss man sich schließlich an vorgegebene Einrückungen halten. Gibt sicherlich einige, die das als zu einschränkend empfinden.
Mir geht es durchaus so :)
Daher finde ich Ruby auch interessanter
Ich persönlich finde es gut, zwischen dynamisch und statisch einen Kompromiss zu schließen, um die Vorteile beider Welten zu vereinen. Boo macht das z.B so. Fühlt sich wie eine dynamisch getypte Sprache an, ist aber intern statisch.
Wo ist die Grenze? Ich verstehe das es für bestimmte Anwendungen optimierte Werkzeuge gibt - wie z.B. Brotmesser und Tomatenmesser- aber irgendwann ist schluss. Für den User machen diese Interpreter doch alle das gleiche: Text-Code in Maschinen-Code übersetzen.
Und die ganzen Werkzeuge, die es so gibt und die man sch u.U. kaufen muss... Schraubenzieher, Hammer, Bohrer, Messer, Gabel, Uhr... Warum gibt es nicht ein Schweizer Taschenmesser, das wirklich all diese Dinge enthält?
Ich hoffe, deine Frage ist beantwortet.
NikN
Aus User-Sicht ist es aber irrelevant ob ein Programm mit Python oder Ruby erstellt wurde, das Programm soll seinen Zweck erfüllen. Das ist als ob Handwerker für dasselbe Ergebnis unterschiedliche Werkzeuge anfordert - mach das mal dem User klar wieso er soviel installieren soll.
Für Python gibt es z.B. py2exe wo Python-Code in Maschinencode umgesetzt wird(als .exe für Win) - wozu wohl?
> Ich hoffe, deine Frage ist beantwortet.
Es wird demnach in Zukunft noch mehr Interpreter geben?
Ich habe nichtmal Ruby installiert...
Schönen Abend
das ganz ist doch völlig egal. unter windows bringen die programme die dlls und exen mit, in einer distro mach das ganze der paketmanager und wer selbst kompiliert naja 5min extra.
in einer zeit wo 1GB RAM normal ist, kommts doch auf das auch nicht an, und dem user ist es wohl völlog egal ob lisp, ruby, c++, oder doch c#, war ;-)
MfG