1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Qt: Qbs 1.0.0 ist…

Qt vs Java

  1. Thema

Neues Thema Ansicht wechseln


  1. Qt vs Java

    Autor: Anonymer Nutzer 04.06.13 - 10:46

    Vorweg: Ich bitte Euch diskutiert sachlich, die Hoffnung stirbt zuletzt ;-)

    Seit Qt 4.x schwanke ich zunehmend zwischen Java und Qt. Als Client-Anwendung nehmen sich beide ja nicht viel aber wie schaut es bei Client/Server-Anwendungen aus?

    Mit EJB hat man bei Java ein komfortables und mächtiges Werkzeug, das einem eine Menge Arbeit abnimmt. Gibt es unter Qt adäquaten "Ersatz" dafür?

  2. Re: Qt vs Java

    Autor: tehsre 04.06.13 - 11:13

    Hi,

    nein. Die einzige Gemeinsamkeit von Qt und Java ist dass beide "Cross-Platform" auf ihre Fahnen schreiben.

    Qt ist ein Cross-Platform UI Framework, nicht mehr, aber auch nicht weniger.
    Qt ist darauf ausgelegt auch auf embedded devices zu funktionieren und bringt dafür einige recht gute Mechanismen mit die eine portierung relativ einfach machen.

    Zitat qt-project.org: "Qt is a cross-platform application and UI framework for developers using C++ or QML, a CSS & JavaScript like language."

    Dass nativ sich nach wie vor i.d.R. "besser" anfühlt wie Java muss man vermutlich nicht gesondert erwähnen.



    1 mal bearbeitet, zuletzt am 04.06.13 11:15 durch tehsre.

  3. Re: Qt vs Java

    Autor: Anonymer Nutzer 04.06.13 - 11:26

    tehsre schrieb:
    --------------------------------------------------------------------------------
    > Qt ist ein Cross-Platform UI Framework, nicht mehr, aber auch nicht
    > weniger.
    Nunja Qt bietet ja nicht nur UI Elemente, sondern auch eine Menge "Hintergrund-Werkzeug" bspw. die Module QtNetwork, QtSql oder QtCore.

    > Dass nativ sich nach wie vor i.d.R. "besser" anfühlt wie Java muss man
    > vermutlich nicht gesondert erwähnen.
    Das ist u.a. der Grund warum ich zunehmend Interesse an Qt habe.

  4. Re: Qt vs Java

    Autor: pythoneer 04.06.13 - 11:44

    Das ist richtig. Aber da wo es anfängt, hört es auch schon wieder auf. Man möchte nicht wirklich einen Server basieren auf TCP selber schreiben oder? Persistenz und Session Frameworks sucht man bei Qt vergeblich. Man kann zwar bissl mit Bytestreams rumexperimentieren aber das war es auch schon. Für diese Fälle müsste man dann immer auch wieder Drittanbieter mit an Bord hohlen.
    Versteh mich nicht falsch! Ich bin absoluter Fan von Qt und bin auch auf nem guten weg dahin, dass es Java für mich ersetzt. Das liegt aber vielmehr daran, dass ich einen beschränkten Einsatzbereich dafür habe und wohl Java auch in dessen schwachen Bereich (Desktopapplikationen) verwendet habe. Wie gesagt trifft das alles nur für mich persönlich zu und ein anderer mag da andere Erfahrungen haben.
    Qt passt einfach besser in mein Denkschema und ich arbeite damit einfach sehr gerne. Mit Java bin ich nie so richtig warm geworden.
    Ich habe aber schon einen Einblick in die Serverentwicklung von Java. Ich sehe sehr wohl dessen Mächtigkeit, was in meinen Augen auch dessen Problem ist. Mir ist es einfach zu Mächtig und man kommt sich als Entwickler immer wie ein Fremdkörper in dem Ökosystem vor. Ich glaube in der IX stand es mal, das sie Specs zu EJB umfangreicher sind als die europäische Verfassung. Auch das entwickeln kommt mir einfach langsam vor. Aus diesem Grund bin ich bei der Serverentwicklung mittlerweile auf Python*(mein kleiner Liebling) umgestiegen, weil die meisten meiner Projekte einfach nicht den Umfang haben und es – zumindest ausreicht. Ob es sich für Mega Projekte eignet kann ich nicht sagen. Was ich aber sagen kann ist, dass Java für mich weitestgehend nicht mehr interessant ist – Server wie Desktop.

    Eine Antwort auf deine Frage – auch wenn es Stückwerk aus verschiedenen Projekten ist (Persistenz, Kommunikation .. etc.) würde mich auch interessieren. Jemand Erfahrung mit zeroc ICE(wollte ich mir demnächst mal ansehen als Kommunikationsersatz zu normalen Sockets aus Qt)?

    EDIT:
    Als Stichworte fallen mir da noch das webtoolkit wt (http://www.webtoolkit.eu/wt) und gwan (http://gwan.com/) ein. Habe beides nur mal kurz ausprobiert und wollte es immer mal näher unter die Lupe nehmen, bin aber noch nicht dazu gekommen.

    * auch javascript mit node und was sich lohnt mal anzusehen ist Meteorjs und die ganzen anderen lustigen auf node basierenden Projekte.



    5 mal bearbeitet, zuletzt am 04.06.13 11:58 durch pythoneer.

  5. Re: Qt vs Java

    Autor: jpuhr 04.06.13 - 12:28

    > Jemand Erfahrung mit zeroc ICE(wollte ich mir demnächst
    > mal ansehen als Kommunikationsersatz zu normalen Sockets aus Qt)?

    Scheint sehr gut zu sein. Der Grund, warum wir es nicht eingesetzt haben: Die GPL kam für uns nicht in Frage und für die kommerzielle Lizenz wollten die einen sechsstelligen Betrag (wenn ich mich recht erinnere; auf jeden Fall war er astronomisch).

  6. Re: Qt vs Java

    Autor: Anonymer Nutzer 04.06.13 - 12:50

    pythoneer schrieb:
    --------------------------------------------------------------------------------
    > Ich habe aber schon einen Einblick in die Serverentwicklung von Java. Ich
    > sehe sehr wohl dessen Mächtigkeit, was in meinen Augen auch dessen Problem
    > ist. Mir ist es einfach zu Mächtig und man kommt sich als Entwickler immer
    > wie ein Fremdkörper in dem Ökosystem vor. Ich glaube in der IX stand es
    > mal, das sie Specs zu EJB umfangreicher sind als die europäische
    > Verfassung. Auch das entwickeln kommt mir einfach langsam vor.

    EJB nimmt einen viel "Standard-Arbeit" ab aber man hat immer noch die Möglichkeit manuell einzugreifen, da wird die Sache imho auch etwas komplizierter aber ansonsten schreibt man serverseitig seine Session Beans und bindet clientseitig bequem das entsprechende Interface ein ... fertig und man muss sich prinzipiell keinerlei Gedanken darüber machen, wie die Daten vom Server zum Client kommen. Vielleicht eine etwas übersimplifizierte Erklärung aber ich habe nicht das Gefühl damit langsam zu entwickeln gerade weil man sich um so viele Dinge keinen Kopf mehr machen muss.

    > Aus diesem Grund bin ich bei der Serverentwicklung mittlerweile auf Python*(mein
    > kleiner Liebling) umgestiegen, ...
    Python kommt für mich derzeit nicht in Frage, aus dem einfachen Grund das ich die Sprache erst einmal lernen müsste, da wäre mir z.Z. der Aufwand zu hoch.

    > * auch javascript mit node und was sich lohnt mal anzusehen ist Meteorjs
    > und die ganzen anderen lustigen auf node basierenden Projekte.

    Nodejs habe ich auch schon im Blick, es ist extrem interessant aber dort hat man auch das Problem das man selbst mit Modulen wie Expressjs noch eine Menge selbst schreiben muss und mit einer Webanwendung clientseitig hätte ich nicht die Möglichkeit auf Hardware zuzugreifen.

  7. Re: Qt vs Java

    Autor: Kelteseth 04.06.13 - 13:00

    jpuhr schrieb:
    --------------------------------------------------------------------------------
    > > Jemand Erfahrung mit zeroc ICE(wollte ich mir demnächst
    > > mal ansehen als Kommunikationsersatz zu normalen Sockets aus Qt)?
    >
    > Scheint sehr gut zu sein. Der Grund, warum wir es nicht eingesetzt haben:
    > Die GPL kam für uns nicht in Frage und für die kommerzielle Lizenz wollten
    > die einen sechsstelligen Betrag (wenn ich mich recht erinnere; auf jedeni
    > Fall war er astronomisch).

    Qt gibt es auch unter der LGPL. Das heißt wenn du dynamisch linkst musst du nix zählen.

    Was mich vor allem an Qt begeistert is QML. Einfach genial wie man damit Guis erstellen kann :)



    1 mal bearbeitet, zuletzt am 04.06.13 13:01 durch Kelteseth.

  8. Re: Qt vs Java

    Autor: jpuhr 04.06.13 - 13:10

    > Qt gibt es auch unter der LGPL. Das heißt wenn du dynamisch linkst musst du
    > nix zählen.

    Zeroc ICE != Qt

  9. Re: Qt vs Java

    Autor: pythoneer 04.06.13 - 13:12

    Darf man fragen, was ihr stattdessen im Einsatz habt?

  10. Re: Qt vs Java

    Autor: bodsch 04.06.13 - 13:29

    pythoneer schrieb:
    --------------------------------------------------------------------------------
    > Das ist richtig. Aber da wo es anfängt, hört es auch schon wieder auf. Man
    > möchte nicht wirklich einen Server basieren auf TCP selber schreiben oder?

    Doch, kann man.
    Ich hab mir mal den Spaß gemacht und einen kompletten Applikationsserver in Qt4 programmiert.
    Alles an Board, was man für eine Webanwendung brauchte, Templates, Datenbanken, Session- und Cookiehandling ...
    Und der rannte wie die wutz!

  11. Re: Qt vs Java

    Autor: bodsch 04.06.13 - 13:30

    jpuhr schrieb:
    --------------------------------------------------------------------------------
    > > Jemand Erfahrung mit zeroc ICE(wollte ich mir demnächst
    > > mal ansehen als Kommunikationsersatz zu normalen Sockets aus Qt)?
    >
    > Scheint sehr gut zu sein. Der Grund, warum wir es nicht eingesetzt haben:
    > Die GPL kam für uns nicht in Frage und für die kommerzielle Lizenz wollten
    > die einen sechsstelligen Betrag (wenn ich mich recht erinnere; auf jeden
    > Fall war er astronomisch).

    Das war einmal.
    Und zwar noch vor Nokia ...

  12. Re: Qt vs Java

    Autor: pythoneer 04.06.13 - 13:33

    lolig schrieb:
    --------------------------------------------------------------------------------
    > EJB nimmt einen viel "Standard-Arbeit" ab aber man hat immer noch die
    > Möglichkeit manuell einzugreifen, da wird die Sache imho auch etwas
    > komplizierter aber ansonsten schreibt man serverseitig seine Session Beans
    > und bindet clientseitig bequem das entsprechende Interface ein ... fertig
    > und man muss sich prinzipiell keinerlei Gedanken darüber machen, wie die
    > Daten vom Server zum Client kommen. Vielleicht eine etwas
    > übersimplifizierte Erklärung aber ich habe nicht das Gefühl damit langsam
    > zu entwickeln gerade weil man sich um so viele Dinge keinen Kopf mehr
    > machen muss.

    Ja, da gebe ich dir recht. Meine Erinnerung hat auch noch viel JSF etc. im Gepäck. Ich kann auch nicht konkret mit dem Finger drauf zeigen aber ich habe immer den Eindruck, dass ich mich bei den Aufwandsabschätzungen immer vertue, wenn ich Java verwende. Wo man auf der einen Seite spart kommt es auf der anderen wieder doppelt drauf. Und was mich an der Sprache irgendwie stört ist der viele Code, den ich schreibe. Das mag an mir liegen aber ich habe das Gefühl, dass ich in anderen Sprachen auch einfach sparsamer bin. Ich habe selber mit C/C++ angefangen (als Jugendlicher um kleine Spiele mit Irrlicht und Ogre3d, Raknet, Fmod zu programmieren) und bin dann, durch die Uni – die das sehr gehypt haben (vllt. berechtigter weise), auf Java gekommen und habe auch viel Spaß damit gehabt. Seit ich dann aber auf Python und dank node auf Javascript bin und ich den Weg zurück zu C++ durch/mit Qt gefunden habe, kommt mir das entwickeln irgendwie weider deutlich schneller vor, das mag auch einfach eine Eigenart von mir sein.

    > Python kommt für mich derzeit nicht in Frage, aus dem einfachen Grund das
    > ich die Sprache erst einmal lernen müsste, da wäre mir z.Z. der Aufwand zu
    > hoch.

    Ok, dass kann ich verstehen und nachvollziehen. Vielleicht dann nicht beruflich, aber vielleicht mal privat. Es macht wirklich sehr viel Spaß und hat mir das Programmieren wieder zur Freude gemacht, nachdem ich langsam wirklich den gefallen daran verloren hatte. Ich weiß nicht auf welchem System du zu gange bist aber unter Linux macht es auch als tool zum verwalten sinn (wenn man shellscripts nicht so mag). Viele lustige Tools lassen sich damit bauen, wo man in anderen Sprachen wohl nicht die Zeit damit verschwendet hätte. Wer an der Programmierung Freude hat, sollte sich das einfach mal ansehen. Ich finde für mich hatte es auch einen positiven Effekt auf meinen generellen Programmierstil.

    > Nodejs habe ich auch schon im Blick, es ist extrem interessant aber dort
    > hat man auch das Problem das man selbst mit Modulen wie Expressjs noch eine
    > Menge selbst schreiben muss und mit einer Webanwendung clientseitig hätte
    > ich nicht die Möglichkeit auf Hardware zuzugreifen.

    Ja das ist natürlich Anforderungsabhängig. Aus diesem Grund hatte ich ja ICE erwähnt. Ich habe es wie gesagt selber noch nicht so ausführlich betrachtet, aber aus den selben Gründen wie du, war ich auf der suche nach so etwas, weil ich in meinem letzten Project viel mit Sockets gemacht hatte und es war ein wenig müßig.
    Für reine Webanwendungen – und wenn du zu viel Freizeit hast :/ – schau dir für die Zunkunft mal Meteorjs an. Ich habe damit mal eine etwas umfangreichere Webanwendung geschrieben und war sehr angetan. Das war auch in Konkurrenz zu anderen die es mit Java, Ruby etc. gemacht haben. Und ich war deutlich schneller im entwickeln. Ich galube nicht, dass ich so extrem schneller bin. Das Projekt passte auch einfach wie Arsch auf Eimer zu Meteorjs.



    1 mal bearbeitet, zuletzt am 04.06.13 13:44 durch pythoneer.

  13. Re: Qt vs Java

    Autor: pythoneer 04.06.13 - 13:36

    Geil! :D
    Opensource? ;)

    Edit: Das man es nicht kann hab ich ja nicht behauptet, nur dass "man" es nicht möchte ;) Was du gemacht hast erfordert ja schon "besonderen Ehrgeiz" :)



    2 mal bearbeitet, zuletzt am 04.06.13 13:38 durch pythoneer.

  14. Re: Qt vs Java

    Autor: jpuhr 04.06.13 - 14:12

    > Darf man fragen, was ihr stattdessen im Einsatz habt?

    Einen QTcpSocket in Verbindung mit QDataStream. Die sendende Seite serialisiert eine Datenstruktur mit QDataStream in den Socket hinein, die andere Seite deserialisiert die Datenstruktur, auch wieder mit QDataStream. Für unseren einfachen Anwendungsfall reicht das voll und ganz. Zeroc ICE wäre sicher eleganter, von den Lizenzkosten aber völlig indiskutabel gewesen.
    Und an CORBA sind bei uns schon einige Projekte gescheitert.

  15. Re: Qt vs Java

    Autor: superhans 04.06.13 - 14:25

    >Und was mich an der Sprache irgendwie stört ist der viele Code, den ich schreibe. Das
    >mag an mir liegen aber ich habe das Gefühl, dass ich in anderen Sprachen auch einfach
    >sparsamer bin.

    Das ist nicht nur dein Gefühl, das ist Tatsache. Java ist über die Jahre veraltet und bräuchte mal eine Verjüngungskur. Wäre schon hilfreich, wenn sie in Java 8 endlich mal Lambda Expressions einbauen würden, aber das wird wahrscheinlich eh nichts...

    Was ich dir empfehlen würde ist, da du anscheinend gerne deine Sprachkenntnisse erweiterst, dir Scala anzusehen. Es ist auch eine JVM-basierte Sprache wie Java, aber viel eleganter. Die Entwickler haben ihr Möglichstes getan, damit man sich nicht mit unnötiger Schreibarbeit aufhält, wie z. B. bei der Variablendeklaration. Die Sprache ist statisch typisiert, aber man muss nicht jedes mal den Typ einer Variable hinschreiben, wenn der Compiler das erkennen kann (Type Interference).
    Das ist aber nur syntaktischer Zucker, wie man so schön sagt. Die eigentliche Stärke der Sprache liegt darin, dass sie die beiden Paradigma FP und OOP miteinander vereint und auch jeder Ausdruck einen Wert zurückliefert (bis auf die while-Schleife, glaube ich).

    Ich bin gerade dabei mir die Sprache anzueignen, weil sie m.M.n großes Potenzial hat, Java zu verdrängen (aber nicht in absehbarer Zeit) oder zumindest zu beeinflussen. Vielleicht ist es auch was für dich.

  16. Re: Qt vs Java

    Autor: Anonymer Nutzer 04.06.13 - 14:33

    pythoneer schrieb:
    --------------------------------------------------------------------------------
    > Ja, da gebe ich dir recht. Meine Erinnerung hat auch noch viel JSF etc. im
    > Gepäck. Ich kann auch nicht konkret mit dem Finger drauf zeigen aber ich
    > habe immer den Eindruck, dass ich mich bei den Aufwandsabschätzungen immer
    > vertue, wenn ich Java verwende.
    JSP war/ist imho ziemlich besch ... eiden aber mit JSF (ins besonders ab v2) wurde das erstellen von Webanwendungen wesentlich verbessert/-einfacht.

    > Und was mich an der Sprache irgendwie
    > stört ist der viele Code, den ich schreibe. Das mag an mir liegen aber ich
    > habe das Gefühl, dass ich in anderen Sprachen auch einfach sparsamer bin.
    Ja das kann sowohl Vorteil als auch Nachteil sein. Ich finde die Lesbarkeit von Java extrem gut aber an manchen stellen habe ich auch das Gefühl mehr Code als "nötig" zu produzieren.

    > Ich habe selber mit C/C++ angefangen (als Jugendlicher um kleine Spiele mit
    > Irrlicht und Ogre3d, Raknet, Fmod zu programmieren) und bin dann, durch die
    > Uni – die das sehr gehypt haben (vllt. berechtigter weise), auf Java
    > gekommen und habe auch viel Spaß damit gehabt. Seit ich dann aber auf
    > Python und dank node auf Javascript bin und ich den Weg zurück zu C++
    > durch/mit Qt gefunden habe, kommt mir das entwickeln irgendwie weider
    > deutlich schneller vor, das mag auch einfach eine Eigenart von mir sein.
    Ich bin eigentlich kein großer Fan von C/C++ aber mit Qt ist es doch sehr brauchbar *g* Ansonsten bin ich jetzt an einem Punkt, wo ich das Gefühl habe, dass mir der Kopf platzt, wenn ich noch eine neue Sprache inkl. aller Eigenheiten lernen müsste.

    > Für reine Webanwendungen – und wenn du zu viel Freizeit hast :/
    > – schau dir für die Zunkunft mal Meteorjs an. Ich habe damit mal eine
    > etwas umfangreichere Webanwendung geschrieben und war sehr angetan. Das war
    > auch in Konkurrenz zu anderen die es mit Java, Ruby etc. gemacht haben. Und
    > ich war deutlich schneller im entwickeln. Ich galube nicht, dass ich so
    > extrem schneller bin. Das Projekt passte auch einfach wie Arsch auf Eimer
    > zu Meteorjs.
    Zu meiner Schande muss ich gestehen das ich von Meteorjs noch nichts gehört oder wahrgenommen habe, dass werde ich mal nachholen ;-)

  17. Re: Qt vs Java

    Autor: pythoneer 04.06.13 - 17:44

    Ich habe mir Scala schon angesehen. Und bin leider kein großer Fan von geworden und denke auch nicht, dass sich das mal durchsetzt (oder hoffe es zumindest) warum?

    Scala hat zwar viele tolle Sachen nur leider sieht es so aus als sei das nur für Akademiker interessant. Man darf nicht vergessen – und in diesem Punkt ist Java "toll" – man braucht bei einer Sprache auch die einfache Erlernbarkeit. Nicht jeder lernt programmieren an der Uni. Viele gehen lieber den Weg über einen Ausbildungsberuf um Anwendungsentwickler zu werden. Hier muss ich Java eigentlich ein großes Lob aussprechen, weil es sich wirklich gut eignet um einfach gelernt zu werden. Es gibt bessere Sprachen – hierzu zähle ich Python – aber Scala zähle ich ganz klar nicht dazu.

    Es ist eine super interessante Sprache aber einfach zu umfangreich. Viele werden einfach nur eine Teilmenge davon lernen (wie es vielleicht auch schon bei C++ der Fall ist, wo viele einen bogen um Templates machen und Template Metaprogrammierung der Teufel ist). Das macht es unter den Entwicklern dann einfach schwer zu entwickeln. Scala eignet sich ja auch um DSL's zu erstellen und das könnte dann schnell in einem wirrwar wie bei Lisp enden, wenn man nicht besonders aufpasst.

    Ich habe selber mal einen Vortrag über Scala gehalten um mal meine Erfahrungen mitzuteilen. Darunter gab es dann auch ein "Kapitel Kurioses". Einfach Sachen die man mal gesehen haben sollte, wenn man von Python oder Ruby kommt.

    scala> 100 < 65000 * 65000
    res0: Boolean = False

    Einen Javaentwickler wird das nicht wundern aber in Python und Ruby kommt da halt True raus. Nicht ganz so super ersichtlich sind dann solche Sachen hier.

    scala> 0.3 < Math.asin(1.0001)
    res0: Boolean = False

    Was wirklich keinen Sinn macht finde ich. In Python:
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    ValueError: math domain error

    Ruby:
    Math::DomainError: Numerical argument is out of domain

    In Scala kann ich solche Sachen hier machen.

    scala> def bar() = "hello bar"
    bar: ()java.lang.String

    scala> def foo = "hello foo"
    foo: java.lang.String

    scala> print(bar())
    hello bar
    scala> print(bar)
    hello bar
    scala> print(foo)
    hello foo
    scala> print(foo())
    <console>:9: error: not enough arguments for method apply:

    dann – zumindest damals wie ist das heute? – gab es kein break in Schleifen. Das konnte man dann so machen:

    import scala.util.controls.Breaks._
    breakable{
    for(x <- xs){
    if(Math.random < 0.1) break
    }
    }

    und sowas finde ich recht unschön. Im ganzen war auch irgendwie nicht klar, was nun Sprachbestandteil war und was nicht!?

    scala.collection.immutable.Map konnte ich ohne import verwenden.
    val m1:Map = ... ->m1 immutable

    importiere ich aber collection.mutable.Map
    val m1:Map = ... ->m1 mutable ??

    das geht so doch nicht! Und sone "Zaubereien" gab es auch an anderer Stelle
    val numbers = shuffle((1 to 49).toList) ... wo kommt das toList her?

    Das waren so Kleinigkeiten die mir einfach aufgefallen sind. Und das liegt wohl daran, dass Scala auch aus dem akademischen Bereich kommt. Die Sprache wirkt so wie ein Laboratorium damit einige Studenten mit dessen Entwicklung ihre Diplomarbeit verbringen konnten. XML ist Teil der Sprache aber RegEx nicht. Es wirkt halt nicht so als sei es aus einem Bereicht der Anwendungsentwickler gekommen sonder ist irgendwie akademisches Spielzeug. Mir macht die Sprache nichts des nichtsdestotrotz viel Spaß, sehe aber nicht dass man das irgendwie nem Anwendungsentwickler "verkaufen" kann. Ich kann mich aber auch irren.

  18. Re: Qt vs Java

    Autor: pythoneer 04.06.13 - 17:56

    lolig schrieb:
    --------------------------------------------------------------------------------
    > JSP war/ist imho ziemlich besch ... eiden aber mit JSF (ins besonders ab
    > v2) wurde das erstellen von Webanwendungen wesentlich
    > verbessert/-einfacht.

    Ja definitiv. Aber für kleine Projekte aber der totale overkill. Ich habe JSF auch erst schätzen gelernt. Wenn man dann aber agil entwickelt, öfter mal was ausprobiert, mal was wegschmeißt und neu macht, dann geht einem der Boilerplate und das ganze drum herum schon ziemlich auf die Nerven. Für einen Prototypen benutze ich das überhaupt nicht mehr, dafür ist mir meine Lebenszeit zu schade. Wenn es dann ernst wird, kann man noch mal darüber nachdenken.

    > Ich bin eigentlich kein großer Fan von C/C++ aber mit Qt ist es doch sehr
    > brauchbar *g* Ansonsten bin ich jetzt an einem Punkt, wo ich das Gefühl
    > habe, dass mir der Kopf platzt, wenn ich noch eine neue Sprache inkl. aller
    > Eigenheiten lernen müsste.

    Ja das geht wohl vielen so. Irgendwann ist man an dem Punkt, wo man einfach mal produktiv arbeiten möchte. Und dann ist es irgendwann egal in welcher Sprache und welches Framework. Nicht direkt egal aber man muss ja irgendwann mal damit fertig werden und kann nicht sein ganzen Leben damit verbringen alles auszuprobieren, leider. Lieber hat man dann ein Werkzeug mit dem man gut umgehen kann auch wenn es für den konkreten Fall vielleicht ungeeignet ist, als viele Werkzeuge die man nur zur hälfte kennt und mit keinem wirklich umgehen kann.

    > Zu meiner Schande muss ich gestehen das ich von Meteorjs noch nichts gehört
    > oder wahrgenommen habe, dass werde ich mal nachholen ;-)

    Das ist keine Schande, ich denke das kennen recht wenige (zu mindest aus meinem Umfeld kennen das die wenigsten, obwohl ich immer Werbung dafür mache :D ) Es ist ja auch noch beta und wohl auch nicht DAS universal Werkzeug. Ich finde aber es hat super Ansätze und die Jungs machen da wirklich mal was anders, als man das gewohnt ist. Man muss sich ein wenig umgewöhnen aber wenn man dann was hat, wo das Prinzip gut passt, dann ist man wirklich rasend schnell in der Entwicklung. So kam es mir zumindest vor, es machte einfach sehr viel Spaß.

  19. Re: Qt vs Java

    Autor: superhans 04.06.13 - 18:59

    >Scala hat zwar viele tolle Sachen nur leider sieht es so aus als sei das nur für Akademiker
    >interessant. Man darf nicht vergessen –
    >und in diesem Punkt ist Java "toll" – man braucht bei einer Sprache auch die einfache
    >Erlernbarkeit. Nicht jeder lernt programmieren an der Uni.

    Ich stimme wohl zu, dass Scala schwerer zu erlernen ist, als andere Sprachen, aber das liegt zum Teil auch daran, dass man sich neue Konzepte aneignen muss, wenn man nur die OOP-Welt kennt.
    Dass es eine akademische Sprache ist, verneine ich. Es wird schon in der Industrie verwendet und gewinnt immer mehr an Beliebheit.

    >Es ist eine super interessante Sprache aber einfach zu umfangreich. Viele werden einfach
    >nur eine Teilmenge davon lernen (wie es vielleicht auch schon bei C++ der Fall ist, wo viele
    >einen bogen um Templates machen und Template Metaprogrammierung der Teufel ist).
    >Das macht es unter den Entwicklern dann einfach schwer zu entwickeln.

    Jop, das ist der andere Teil, weswegen die Lernkurve steiler als bei anderen Sprachen ist. Es bietet viele Möglichkeiten, durch die man sich auch selbst ein Bein stellen kann, aber ich sehe da kein großes Problem. Man muss nicht alles von Anfang an können und auch versuchen muss anzuwenden. Die Erfahrung kommt ja bekanntlich mit der Zeit.

    >Scala eignet sich ja auch um DSL's zu erstellen und das könnte dann schnell in einem
    >wirrwar wie bei Lisp enden, wenn man nicht besonders aufpasst.

    Die Entwickler wollten, dass die Sprache "scalable" ist, d. h. auch in Zukunft durch neue Bibliotheken erweitert werden kann, weswegen einige mächtige Konstrukte eingebaut wurden (s. implicit conversion). Aber die Anwendungsfälle dieser Konstrukte wurde ziemlich klar definiert und eingeschränkt.
    Ein gutes Anwendungsbeispiel ist das Test-Framework von Scala (http://www.scalatest.org) mit dem sich Tests wie Spezifikationen lesen lassen. Hat aber auch gedauert, bis ich verstanden habe, wie man so eine API schreibt - aber das muss man ja nicht können.

    >Ich habe selber mal einen Vortrag über Scala gehalten um mal meine Erfahrungen
    >mitzuteilen. Darunter gab es dann auch ein "Kapitel Kurioses". Einfach Sachen die man mal
    >gesehen haben sollte, wenn man von Python oder Ruby kommt.[..]

    Das foo-Beispiel ist das einzige, was mich auch stört (ist wohl auf eine Konvention zurückzuführen). Auf die anderen Probleme würde ich selbst nie stoßen, in keiner Programmiersprache :)

    >dann – zumindest damals wie ist das heute? – gab es kein break in Schleifen. Das konnte
    >man dann so machen: [...]

    Hier sehe ich auch kein Problem, da man Breaks auch anders einbauen kann, wenn man sie benötigt. Man müsste nur die Schleife umschreiben oder besser eine rekursive Funktion definieren - die im Übrigen optimiert werden (tail call elimination).

    >und sowas finde ich recht unschön. Im ganzen war auch irgendwie nicht klar, was nun
    >Sprachbestandteil war und was nicht!?

    Die Immutables sind die Standard-Implementierungen, da die Sprache zur Funktionalen Programmierung anregen möchte.

    A useful convention if you want to use both mutable and immutable versions of collections is to import just the package collection.mutable. Then a word like Set without a prefix still refers to an an immutable collection, whereas mutable.Set refers to the mutable counterpart.

    >das geht so doch nicht! Und sone "Zaubereien" gab es auch an anderer Stelle
    >val numbers = shuffle((1 to 49).toList) ... wo kommt das toList her?

    (1 to 49) wird zu einer Sequenz umgewandelt, die die toList-Methode bereitstellt.

    >XML ist Teil der Sprache aber RegEx nicht. Es wirkt halt nicht so als sei es aus einem
    >Bereicht der Anwendungsentwickler gekommen sonder ist irgendwie akademisches
    >Spielzeug. Mir macht die Sprache nichts des nichtsdestotrotz viel Spaß, sehe aber nicht
    >dass man das irgendwie nem Anwendungsentwickler "verkaufen" kann. Ich kann mich aber
    >auch irren.

    Ws meinst du damit, dass RegEx kein Teil der Sprache sei? Man kann es innerhalb von Match-Pattern bspw. nutzen. Dass XML nun ein first class citizen ist, kenne ich auch von keiner anderen Programmiersprache und ich finde es sehr gut!

    Scala ist aber keine Sprache, die man sich mal so nebenbei aneignet. Ich würde dafür das Scala-Buch von den Entwicklern empfehlen, in dem auch auf einige deiner Probleme eingegangen wird.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Fachhochschule Südwestfalen, Meschede
  2. EPLAN Software & Service GmbH & Co. KG, Monheim (Köln/Düsseldorf), Stuttgart oder München
  3. PDR-Team GmbH, Schwäbisch Gmünd
  4. Würth Industrie Service GmbH & Co. KG, Bad Mergentheim

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-70%) 5,99€
  2. 2,49€
  3. (-80%) 9,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Elektroschrott: Kauft keine kleinen Konsolen!
Elektroschrott
Kauft keine kleinen Konsolen!

Ich bin ein Fan von Retro. Und ein Fan von Games. Und ich habe den kleinen Plastikschachteln mit ihrer schlechten Umweltbilanz wirklich eine Chance gegeben. Aber es hilft alles nichts.
Ein IMHO von Martin Wolf

  1. IMHO Porsche prescht beim Preis übers Ziel hinaus
  2. Gaming Konsolenkrieg statt Spielestreaming

VW-Logistikplattform Rio: Mehr Fracht transportieren mit weniger Lkw
VW-Logistikplattform Rio
Mehr Fracht transportieren mit weniger Lkw

Im Online-Handel ist das Tracking einer Bestellung längst Realität. In der Speditionsbranche sieht es oft anders aus: Silo-Denken, viele Kleinunternehmen und Vorbehalte gegenüber der Digitalisierung bremsen den Fortschritt. Das möchte Rio mit seiner Cloud-Lösung und niedrigen Preisen ändern.
Ein Bericht von Dirk Kunde

  1. Vernetzte Mobilität Verkehrsunternehmen könnten Datenaustauschpflicht bekommen
  2. Studie Uber und Lyft verschlechtern den Stadtverkehr
  3. Diesel-Ersatz Baden-Württemberg beschafft Akku-Elektrotriebzüge Mireo

Sendmail: Software aus der digitalen Steinzeit
Sendmail
Software aus der digitalen Steinzeit

Ein nichtöffentliches CVS-Repository, FTP-Downloads, defekte Links, Diskussionen übers Usenet: Der Mailserver Sendmail zeigt alle Anzeichen eines problematischen und in der Vergangenheit stehengebliebenen Softwareprojekts.
Eine Analyse von Hanno Böck

  1. Überwachung Tutanota musste E-Mails vor der Verschlüsselung ausleiten
  2. Buffer Overflow Exim-Sicherheitslücke beim Verarbeiten von TLS-Namen
  3. Sicherheitslücke Buffer Overflow in Dovecot-Mailserver

  1. Internetdienste: Ermittler sollen leichter an Passwörter kommen
    Internetdienste
    Ermittler sollen leichter an Passwörter kommen

    Die Bundesregierung will Ermittlern den Zugriff auf Nutzerdaten bei Internetdiensten wie Mail-Anbieter, Foren oder sozialen Medien erleichtern. Die IT-Branche und die Opposition sehen einen "Albtraum für die IT-Sicherheit".

  2. Netflix und Youtube: EU-Kommissarin warnt vor hohem Energiebedarf des Internets
    Netflix und Youtube
    EU-Kommissarin warnt vor hohem Energiebedarf des Internets

    Youtube, Netflix und Prime Video sind die Dienste, die besonders viel Internetverkehr generieren und damit auch einen besonders hohen Energiebedarf nach sich ziehen. Das sieht die Vizepräsidentin der EU-Kommission kritisch.

  3. Galaxy Fold: Samsung dementiert eigene Verkaufszahlen
    Galaxy Fold
    Samsung dementiert eigene Verkaufszahlen

    Samsung widerspricht sich selbst. Das Unternehmen bestreitet die Angabe eines ranghohen Samsung-Managers, der verkündet hatte, weltweit seien bereits eine Million Galaxy Fold verkauft worden. Vieles bleibt ungeklärt.


  1. 12:25

  2. 12:10

  3. 11:43

  4. 11:15

  5. 10:45

  6. 14:08

  7. 13:22

  8. 12:39