ja ich finde es auch blöd mit RAD immer das Rad wieder neu zu erfinden
Die dynamisch typisierte Sprachen sollten ja eigentlich nur für RAD verwendet werden und die richtige Software dann mit richtigen Sprachen noch mal neu geschrieben werden. Das so was keiner macht sollte eigentlich allen schon von Anfang an klar sein
Von Anonymous am Do, 23. September 2010 um 07:29 #
Ach, und wieso? Ein Paketmanager ist ein Beispiel für ein Programm, das vermutlich I/O-limitiert ist. Mit anderen Worten: der größte Teil der Zeit wird mit I/O verbracht und lässt sich deswegen durch schnellere Berechnungen nicht einsparen, womit eine schnellere Programmiersprache kaum etwas bringt. Hinzu kommt: Wenn man weniger Zeit damit verbringt, Pointer-Bugs und ähnliches zu jagen, die mit Python usw. nie passiert werden, hat man mehr Zeit, um Features und Optimierungen an den richtigen Stellen (also bei den I/O-Mustern) zu entwickeln, was letzten Endes zu einer besseren Performance als im C-Programm führen kann. Klar, die gleichen Optimierungen könnte man dann theoretisch auch in einem C-Programm durchführen, aber man hat eben weniger Zeit, und nicht selten ist genau das der begrenzende Faktor.
Und ganz nebenbei sind sowohl dpkg als auch rpm in C geschrieben.
Von statisch typisiert != C am Do, 23. September 2010 um 14:28 #
Pascal ist auch statisch typisiert und hat keine "Pointerbugs" Angeblich wird es in medizinischen Bereichen immer noch verwendet. Halte ich aber eher für ein Gerücht.
Von Bernd Schmitt am Do, 23. September 2010 um 05:50 #
Performanzeinbußen beim Programm - ja (deshalb am besten eine Sprache die per Default dynamisch typisiert, aber statische Typisierung via Deklarationen anbietet )
Tausche ich gegen Performanzgewinn in der Entwicklung und deshalb meist Funktionsgewinn
Sicheres Refactoring ist mMn Theorie und an sich überschätzt.
Von Smartphoner am Do, 23. September 2010 um 08:32 #
Kann man mit Vala eigentlich auch für Symbian oder Bada programmieren, die ja beide C-Porgramme präferieren? Wie sieht es da mit Zugriff auf GPS etc aus?
Von Anonymous am Mi, 22. September 2010 um 20:36 #
Das ist alles sehr positiv finde ich - scheinbar auch der Rest der Community auch was man so liest... Nach den "schrecklichen" Meldungen der letzten Wochen war die Unsicherheit doch sehr groß - nun sieht alles so aus, als ob das zum größten Teil nur ein schrecklicher Traum gewesen wäre. Hoffentlich bleibts dabei
JavaFX Skript war nun wirklich nicht der Hit und SUN hat Swing schon arg schleifen gelassen - nun herrscht wieder Hoffnung an der "Rich-Client-Front" auf ein verbessertes, modernes, Swing-kompatibles GUI-Toolkit.
Die Auftrennung des offenbar doch arg komplexen JDK 7 zeigt IMHO, dass offenbar (endlich wieder) ein gesunder Pragmatismus eingekehrt ist.
Weiterhin gibt es keine (weiteren) schlimmen Ankündigungen - das Java-Schiff fährt ruhig und mit Dampf weiter - ist doch auch was in diesen "stürmischen Zeiten".
Ach ja: MySQL 5.5 RC ist auch dieser Tage erschienen: Ein weiteres gutes Zeichen finde ich.
Aber dieses verfluchte Calendar/Date API-Konstrukt sollte Oracle jetzt endlich mal anfangen zu ersetzen. Desweiteren ist SimpleDateFormat, etc. auch eine Zumutung (noch immer nicht thread-safe). Schön wäre auch das Beheben der Probleme in JSF, welche durch das Verhalten von UIData ausgelöst werden.
Ich mag Java und das ganze "Ökosystem" drumherum, aber so langsam gehören die 10 Jahre alten Leichen mal ersetzt.
Von Anonymous am Do, 23. September 2010 um 20:25 #
Nunja, in JDK 7 soll ein Ersatz für die Date-API kommen - guck mal auf JSR 310: http://jcp.org/en/jsr/detail?id=310. Die nicht thread-safen Formatter sind in der Tat ziemlich verrückt.
JSF benutze ich nicht - das Teil ist so krumm, da biegt es einem die Zehennägel hoch - aber es gibt ja wirklich mehr als genug guten Ersatz dafür - ich glaub, das, was in C der obligatorische Editor ist, den scheinbar jeder neu erfindet, ist in Java das Webframework
Kommt der Ersatz wirklich? Meine letzte Information bezieht sich auf http://tech.puredanger.com/java7. Da steht immer noch ein Fragezeichen hinter dem "YES".
Bei JSF 1.x fehlen einige Dinge, welche jetzt mit JSF 2.x nachgereicht werden. In Verbindung mit ICEFaces (oder ähnlichem) und Spring (incl. Spring Security) wird daraus eine ganz brauchbare Sache. Aber der Einstieg ist trotzdem nicht leicht.
Soweit ich weiss, war die grösste Arbeit beim öffnen vom JDK zu überprüfen, ob der Code unter einer fremden Lizenz steht und gar nicht veröffentlicht werden darf. Es wurde dann Teil um Teil freigegeben. Teile die nicht freigegeben werden konnten, da nicht im Besitz von Sun mussten ersetzt werden. Das Projekt IcedTea hat sich dem angenommen: IcedTea
Es sieht also danach aus, dass das Oracle JDK die proprietären Codeteile enthält die sie nicht in das OpenJDK überführen konnten und des OpenJDK diese Teile durch freie Implementierungen ersetzt.
Was mich am eingangs erwähnten Blog Post irritiert ist, dass das OpenJDK den TCK bestanden hat und damit zu recht das Label Java trägt. Was sicherstellen sollte, dass sich darauf ausgeführter Bytecode gleich verhält wie auf allen anderen JDK Implementationen die den TCK bestanden haben (also z.B. das Oracle JDK). Aber auch der TCK kann wohl nicht alles abdecken.
Was ich auch nicht wusste ist, dass OpenJDK nur ein Oberbegriff für freie JDK-Implementationen ist und nicht spezifisch die Implementation von Oracle referenziert (geht so aus dem Wikipedia Eintrag zu IcedTea hervor).
bevor wieder die Diskusion um Alternativen los geht - lang lebe vala
statisch Typisiert - langweilig
Clojure, ABCL oder ECL
plattformabhängige Binaries
linuxiert
------------------------
igitt
Dynamische Typisierung ist blöd. Performanzeinbußen und kein sicheres Refactoring.
ja ich finde es auch blöd mit RAD immer das Rad wieder neu zu erfinden
Die dynamisch typisierte Sprachen sollten ja eigentlich nur für RAD verwendet werden und die richtige Software dann mit richtigen Sprachen noch mal neu geschrieben werden. Das so was keiner macht sollte eigentlich allen schon von Anfang an klar sein
Beim Blick auf die ganzen Python-Programme die tatsächlich von Distributionen ausgeliefert werden wird mir oft schlecht.
Oder die Tatsache, warum große teile vo Paketsystemen in Perl verfasst sind, lässt erahnen, dass Paketsysteme erheblich schneller sein könnten.
Ach, und wieso? Ein Paketmanager ist ein Beispiel für ein Programm, das vermutlich I/O-limitiert ist. Mit anderen Worten: der größte Teil der Zeit wird mit I/O verbracht und lässt sich deswegen durch schnellere Berechnungen nicht einsparen, womit eine schnellere Programmiersprache kaum etwas bringt. Hinzu kommt: Wenn man weniger Zeit damit verbringt, Pointer-Bugs und ähnliches zu jagen, die mit Python usw. nie passiert werden, hat man mehr Zeit, um Features und Optimierungen an den richtigen Stellen (also bei den I/O-Mustern) zu entwickeln, was letzten Endes zu einer besseren Performance als im C-Programm führen kann. Klar, die gleichen Optimierungen könnte man dann theoretisch auch in einem C-Programm durchführen, aber man hat eben weniger Zeit, und nicht selten ist genau das der begrenzende Faktor.
Und ganz nebenbei sind sowohl dpkg als auch rpm in C geschrieben.
Pascal ist auch statisch typisiert und hat keine "Pointerbugs" Angeblich wird es in medizinischen Bereichen immer noch verwendet. Halte ich aber eher für ein Gerücht.
Delphi wird hier und da noch verwendet, in speziellen Kreisen sogar Lazarus.
Performanzeinbußen beim Programm - ja (deshalb am besten eine Sprache die per Default dynamisch typisiert, aber statische Typisierung via Deklarationen anbietet
)
Tausche ich gegen Performanzgewinn in der Entwicklung und deshalb meist Funktionsgewinn
Sicheres Refactoring ist mMn Theorie und an sich überschätzt.
Bevor die Diskusion wieder losgeht - lang leben D, Objeck, Seed7, OOC und Eiffel.
Kann man mit Vala eigentlich auch für Symbian oder Bada programmieren, die ja beide C-Porgramme präferieren? Wie sieht es da mit Zugriff auf GPS etc aus?
Sind das nict C++ APIs? Dann geht das nicht.
Das ist alles sehr positiv finde ich - scheinbar auch der Rest der Community auch was man so liest...
Nach den "schrecklichen" Meldungen der letzten Wochen war die Unsicherheit doch sehr groß - nun sieht alles so aus, als ob das zum größten Teil nur ein schrecklicher Traum gewesen wäre.
Hoffentlich bleibts dabei
JavaFX Skript war nun wirklich nicht der Hit und SUN hat Swing schon arg schleifen gelassen - nun herrscht wieder Hoffnung an der "Rich-Client-Front" auf ein verbessertes, modernes, Swing-kompatibles GUI-Toolkit.
Die Auftrennung des offenbar doch arg komplexen JDK 7 zeigt IMHO, dass offenbar (endlich wieder) ein gesunder Pragmatismus eingekehrt ist.
Weiterhin gibt es keine (weiteren) schlimmen Ankündigungen - das Java-Schiff fährt ruhig und mit Dampf weiter - ist doch auch was in diesen "stürmischen Zeiten".
Ach ja: MySQL 5.5 RC ist auch dieser Tage erschienen: Ein weiteres gutes Zeichen finde ich.
Aber dieses verfluchte Calendar/Date API-Konstrukt sollte Oracle jetzt endlich mal anfangen zu ersetzen. Desweiteren ist SimpleDateFormat, etc. auch eine Zumutung (noch immer nicht thread-safe). Schön wäre auch das Beheben der Probleme in JSF, welche durch das Verhalten von UIData ausgelöst werden.
Ich mag Java und das ganze "Ökosystem" drumherum, aber so langsam gehören die 10 Jahre alten Leichen mal ersetzt.
lg unreal
Nunja, in JDK 7 soll ein Ersatz für die Date-API kommen - guck mal auf JSR 310: http://jcp.org/en/jsr/detail?id=310.
Die nicht thread-safen Formatter sind in der Tat ziemlich verrückt.
JSF benutze ich nicht - das Teil ist so krumm, da biegt es einem die Zehennägel hoch - aber es gibt ja wirklich mehr als genug guten Ersatz dafür - ich glaub, das, was in C der obligatorische Editor ist, den scheinbar jeder neu erfindet, ist in Java das Webframework
Kommt der Ersatz wirklich? Meine letzte Information bezieht sich auf http://tech.puredanger.com/java7. Da steht immer noch ein Fragezeichen hinter dem "YES".
Bei JSF 1.x fehlen einige Dinge, welche jetzt mit JSF 2.x nachgereicht werden. In Verbindung mit ICEFaces (oder ähnlichem) und Spring (incl. Spring Security) wird daraus eine ganz brauchbare Sache. Aber der Einstieg ist trotzdem nicht leicht.
Was ist jetzt der Unterschied zwischen OpenJDK und Oracle JDK, außer der Lizenz?
Die Reife.
Habe ich mich auch schon gefragt.
Hier hat jemand einen Unterschied festgestellt: Oracel JDK vs. OpenJDK auf Ubuntu
Soweit ich weiss, war die grösste Arbeit beim öffnen vom JDK zu überprüfen, ob der Code unter einer fremden Lizenz steht und gar nicht veröffentlicht werden darf. Es wurde dann Teil um Teil freigegeben. Teile die nicht freigegeben werden konnten, da nicht im Besitz von Sun mussten ersetzt werden.
Das Projekt IcedTea hat sich dem angenommen: IcedTea
Es sieht also danach aus, dass das Oracle JDK die proprietären Codeteile enthält die sie nicht in das OpenJDK überführen konnten und des OpenJDK diese Teile durch freie Implementierungen ersetzt.
Was mich am eingangs erwähnten Blog Post irritiert ist, dass das OpenJDK den TCK bestanden hat und damit zu recht das Label Java trägt. Was sicherstellen sollte, dass sich darauf ausgeführter Bytecode gleich verhält wie auf allen anderen JDK Implementationen die den TCK bestanden haben (also z.B. das Oracle JDK). Aber auch der TCK kann wohl nicht alles abdecken.
Was ich auch nicht wusste ist, dass OpenJDK nur ein Oberbegriff für freie JDK-Implementationen ist und nicht spezifisch die Implementation von Oracle referenziert (geht so aus dem Wikipedia Eintrag zu IcedTea hervor).
Cheers haschibaschi