JavaFX; Een volwassen taal?

[Bram77]

Ik ben op zoek naar een RAD taal en ontwikkelomgeving die een cross platform oplossing bied (hoe meer platformen hoe beter). Ik heb de afgelopen twee jaar uitgebreid gestoeid met C# (Windows.Forms en GTK#) maar het geeft niet de vodoening die ik zoek. Windows.Forms is te beperkt bruikbaar op niet Windows platformen en GTK# is een peuter qua documentatie en bruikbaarheid op non-linux platformen.

Java is natuurlijk bewezen bruikbaar op alle platformen (OpenOffice, Eclipse) maar qua presentatie ook wat 'dull', niet echt op de toekomst voorbereid. JavaFX lijkt uitkomst te bieden. De filosofie is anders dan ik gewent ben (PHP, C++, C#) en daarom weet ik ook niet zeker of ik er energie in moet gaan steken. Nog een belangrijke reden om daar aan te twijfelen is dat het een redelijk jong concept is. Ik heb geen ervaring met applicatie ontwikkeling in Java. Ook 'de performance vraag' t.o.v. C# (als min-of-meer vergelijkbare) is nog onbeantwoord. Ik heb veel energie gestoken in GTK# maar ben er eerlijk gezegd niet erg lovend over, ondanks dat ik het meer dan waardeer dat er mensen zijn die de poging hebben gewaagd (mogelijk wordt het ook nog volwassener).

Ik heb tot nu toe enkel de oppervlakte van JavaFX geraakt qua verdieping. Maar vraag me dus af of het de moete waard is om me in te verdiepen. kan ik bijvoorbeeld volledig gebruik maken van alle bronnen die er zijn voor Java? Sluit het daarop naadloos aan? Misschien kan iemand met ervaring wat licht schijnen in mijn JavafX duidsternis?

http://javafx.com/
http://javafx.com/samples/
http://jfx.wikia.com/wiki/Demos

[ Voor 6% gewijzigd door Bram77 op 02-05-2009 02:18 ]

[Mr_Light]

Javafx heeft (nog) geen linux runtime. Javafx richt zich op RIA ik weet niet wat je rapid wil developen. Heb je wel eens naar scala/groovy/ruby/python gekeken?

maar qua presentatie ook wat 'dull',

https://aerith.dev.java.net/

niet echt op de toekomst voorbereid.

Wie wat waar?

Niet dat javaFX slecht is of dat het niet hele coole value binding heeft.. Het richt zich alleen op RIA als al je applicaties daar onder vallen dan is het uiteraard prima.
http://java.sun.com/javafx/1/tutorials/core/dataBinding/

Mja wat is volwassen? dat kan ik moeilijk beantwoorden Wanneer noem jij een taal/platform volwassen?

kan ik bijvoorbeeld volledig gebruik maken van alle bronnen die er zijn voor Java?

ja je kan direct gebruik maken van java
http://java.sun.com/devel...g/javafx/javafx_and_java/

[roy-t]

Wat betreft je vragen of Java trager is dan C#, dat is slechts marginaal zo. Je zult gemerkt hebben dat C# bijna altijd meer dan snel genoeg is voor wat je wilt doen, dat geld bij JAVA net zo.

Zelf zou de logische keuze hier volgens mij toch echt Java zijn (hoewel ik C# fan ben, maar idd als ook linux belangrijk is in het plaatje is Java een geschiktere variant). Wat betreft het 'dulle' imago van Java dat je beschrijft, dat zie ik niet zo. Java mist op dit moment idd een aantal features die wel in C# (.net3.5) zitten maar is zeker niet dull ouderwets of achterhaald, en met java 7 zullen ze toch weer bij trekken, het is wel jammer dat de ontwikkeling van Java wat langzamer gaat dan van C#. Maar C# gaat dan ook wel heel erg hard (eigenlijk het hele .net platform gaat hard), weer andere talen zoals C++ en Python gaan op dit moment ook niet meer zo hard.

[user109731]

Misschien is Python iets voor de TS? Draait op veel platforms, waarbij vooral Windows, Linux en MacOS X uitstekend ondersteunt worden. Dan heb je een aantal mogelijkheden voor de user-interface (PyGTK, wxPython en PyQt), waarvan imho vooral PyQt aan te raden is.

Ik weet niet hoe belangrijk performance voor je applicaties is. Voor de meeste taken is het snel genoeg, ook omdat de onderliggende (UI-)libraries geschreven zijn in C/C++.

roy-t schreef op zaterdag 02 mei 2009 @ 08:51:
weer andere talen zoals C++ en Python gaan op dit moment ook niet meer zo hard.

Dat valt wel mee volgens mij, er is elke paar jaar wel een major release. De ontwikkeling van Python 3 heeft alleen wat tijd gekost, omdat veel dingen herschreven of anders opgezet zijn. 3.1 zal ergens in juni uitkomen, een half jaar na 3.0.

[ Voor 3% gewijzigd door user109731 op 02-05-2009 10:12 ]

[OMX2000]

Misschien moet je ff dit lezen, en eventueel dezelfde vraag stellen daar op stackoverflow :
http://stackoverflow.com/...ross-platform-development

Waarom stackoverflow, omdat daar het niveau van advies redelijk hoog is.

Persoonlijk denk ik bij RAD meteen aan Winforms op het .NET platform. Natuurlijk zijn er andere RAD platformen, maar qua productiviteit denk ik dat er niet veel andere platformen sneller zijn. Toen je multi-platform zei en RAD dacht ik nog wel aan QT (C/C++), maar daar heb ik weinig ervaring mee. Het bestaat al echt heel lang, en ik neem dus aan dat de support (documentatie, bugfixes) goed op orde zijn.
Zou je ook de mogelijkheid hebben om web interfaces te gaan gebruiken, dan heb je opeens veel meer keus: Ruby on Rails, ASP.NET/Webforms, ASP.NET/MVC, Flex, etc...

[Mr_Light]

grappig dat ms het voor mekaar heeft gekregen dat iedereen (blijkbaar) meteen aan ms denkt bij RAD, niet dat ik die mening deel overigens.

Starting with the ideas of Brian Gallagher, Alex Balchin, Barry Boehm and Scott Shultz, James Martin developed the Rapid Application Development approach during the 1980s at IBM and finally formalized it by publishing a book in 1991, Rapid Application Development.

Of RAD wel of niet kan heeft veel meer met tooling en frameworks te maken dan met de taal zelf volgens mij.

[ Voor 4% gewijzigd door Mr_Light op 02-05-2009 12:46 . Reden: spelling ]

[Bob]

Inderdaad, qt heeft de laatste tijd een mooie evolutie doorgemaakt. Als je een snelle indruk wil van de ontwikkelomgeving:
http://www.youtube.com/watch?v=U7yje3D1UM4

[OMX2000]

Mr_Light schreef op zaterdag 02 mei 2009 @ 11:04:
grappig dat ms het voor mekaar heeft gekregen dat iedereen (blijkbaar) meteen aan ms denkt bij RAD, niet dat ik die mening deed overigens.


[...]


Of RAD wel of niet kan heeft veel meer met tooling en frameworks te maken dan met de taal zelf volens mij.

Wat je zegt klopt helemaal. .NET is een framework, en 9 van de 10 keer wordt er ook visual studio mee bedoelt. Dus meer specifiek, als je vandaag de dag denkt aan RAD dan denk je aan Visual Studio .NET en ontwikkel je op het .NET platform met C# of VB.Net als taal.

En tja de R staat voor Rapid... En als Java iets niet is, dan is het wel Rapid.

[Verwijderd]

Extra plus punt ten opzichte van C# is dat de reference implementatie van de runtime environment en SDK van Java onder de GPL met classpath exception gereleased zijn.

Daarnaast is Java ook een spec die gebacked word door meerdere partijen dan Oracle/Sun, zoals bijvoorbeeld IBM die ook zelf hun eigen implementatie van de spec hebben. Bij C# is eigenlijk de enige serieuze implementatie de implementatie van MS zelf; Mono is leuk, maar is feitelijk wat GNU Classpath altijd voor Java was.

En tja de R staat voor Rapid... En als Java iets niet is, dan is het wel Rapid.

Ik neem aan dat we het hier hebben over de ontwikkel methodiek en niet over Java performance ? Zowel met C# als Java kan je RAD doen.

[Remus]

OMX2000 schreef op zaterdag 02 mei 2009 @ 11:17:
[En tja de R staat voor Rapid... En als Java iets niet is, dan is het wel Rapid.

Kan je deze boude uitspraak ook onderbouwen, of roep je gewoon maar wat?

[OMX2000]

Remus schreef op zaterdag 02 mei 2009 @ 11:57:
[...]


Kan je deze boude uitspraak ook onderbouwen, of roep je gewoon maar wat?

Nee ik roep niet maar wat. Da's mijn ervaring als architect. De oplossingen in Java of .NET zijn technisch gelijkwaardig, maar ik merk keer op keer dat de productiviteit achter blijft op het .NET platform. In algemene zin, het zal zeker zo zijn dat er in specifieke gevallen java productiever kan zijn dan .NET, maar in het algemeen kost het meer tijd om wat in Java gedaan te krijgen. De belangrijkste reden, in mijn ogen, is de enorme flexibiliteit en keuze mogelijkheden (bijv. ontelbaar aantal xml parsers, verschillende webservice stacks).

[Mr_Light]

Bob schreef op zaterdag 02 mei 2009 @ 11:12:
Inderdaad, qt heeft de laatste tijd een mooie evolutie doorgemaakt. Als je een snelle indruk wil van de ontwikkelomgeving:
http://www.youtube.com/watch?v=U7yje3D1UM4

Ik zag daar niet zo iets wat een (kale) java IDE niet al jaren kan, heb jij toevallig een filmpje met de wat fancier feature's? (hij zei dat er meerdere filmpjes in de serie zat maar kon het zo niet vinden)

OMX2000 schreef op zaterdag 02 mei 2009 @ 12:58:
[...]


Nee ik roep niet maar wat. Da's mijn ervaring als architect. De oplossingen in Java of .NET zijn technisch gelijkwaardig, maar ik merk keer op keer dat de productiviteit achter blijft op het .NET platform. In algemene zin, het zal zeker zo zijn dat er in specifieke gevallen java productiever kan zijn dan .NET, maar in het algemeen kost het meer tijd om wat in Java gedaan te krijgen. De belangrijkste reden, in mijn ogen, is de enorme flexibiliteit en keuze mogelijkheden (bijv. ontelbaar aantal xml parsers, verschillende webservice stacks).

Die 'problemen' hebben niets met rad te maken omdat je vaste keuzes daar bij maakt om mee te beginnen. van implementatie wisselen doe je op basis van gemiste features of omdat je profiler dat zegt.

Wat betreft competities zie je minstens zo vaak teams die Java gebruiken als c#, alhoewel je sterk mag twijfelen over of dat wel over dezelfde 'applicaties' gaat als wanneer je het over RAD hebt.

[ Voor 52% gewijzigd door Mr_Light op 02-05-2009 13:12 ]

[momania]

OMX2000 schreef op zaterdag 02 mei 2009 @ 12:58:
[...]
De belangrijkste reden, in mijn ogen, is de enorme flexibiliteit en keuze mogelijkheden (bijv. ontelbaar aantal xml parsers, verschillende webservice stacks).

Dat is juist enorm goed, die flexibiliteit imo. Dat dat ten koste gaat aan de poductie snelheid betekend alleen maar dat je mensen hebt die zelf niet in staat zijn om daar een goede keuze uit te maken dus een omgeving moeten hebben waar weinig tot geen keuze is.

[Moraelyn]

Mr_Light schreef op zaterdag 02 mei 2009 @ 03:23:
Javafx heeft (nog) geen linux runtime.

eh? JavaFX draait gewoon onder de gewone Java runtime, heb je niks extras voor nodig.

[OMX2000]

momania schreef op zaterdag 02 mei 2009 @ 13:01:
[...]

Dat is juist enorm goed, die flexibiliteit imo. Dat dat ten koste gaat aan de poductie snelheid betekend alleen maar dat je mensen hebt die zelf niet in staat zijn om daar een goede keuze uit te maken dus een omgeving moeten hebben waar weinig tot geen keuze is.

Precies, en daar gaat het dus fout. De techniek staat niet stil, trends komen er in sneltrein vaart. Er zijn in de java wereld tig initiatieven die inspringen op die laatste trends. Dus als ik als architect keuzes moet maken, ben ik dus in eerste instantie een tijd bezig om de juiste frameworks en tooling te vinden.
In de .NET wereld gebeurt dat door 1 bedrijf, Microsoft. En in het algemeen heeft Microsoft een pragmatische aanpak (don't get me started on 'M'). Je ziet dus dat MS zeer snel inspringt op trends (Ajax, Silverlight, dynamic languages, etc), en dat ook zo doet dat je out of the box snel aan de slag kunt.
Dus in het algemeen zal een .NET ontwikkelaar 80% van zijn tools/frameworks van Microsoft betrekken. Wat als voordeel heeft dat .NET ontwikkelaars goed uitwisselbaar zijn. Java ontwikkelaars kunnen ervaring hebben met een bepaalde ontwikkelomgeving (Eclipse/Webspere, Netbeans...) of al dan niet ervaring hebben met bepaalde frameworks (Spring, Hibernate).
Doe je dus relatief korte projecten (3-4 maanden), dan geloof ik gewoon niet dat Java productiever zal zijn dan .NET. Loopt je project langer, en kun je investeren in het opzetten van een standaard workspace, selectie van frameworks, strikte keuzes van frameworks, dan denk ik dat weinig verschil is tussen Java en .NET.

[BCC]

Dat java niet rapid is qua development ben ik het zeker mee eens. Wij zijn daarom voor onze webapplicaties bijna volledig overgestapt op Ruby On Rails. Het is niet dat het niet kan in Java (in tegendeel zelfs), maar een nieuwe feature of een nieuw scherm bouwen kost gewoon zoveel meer tijd in Java tov Ruby dat het gewoon niet leuk meer is.

Dat MS het beter doet kan ik niet zeggen trouwens. Heeft heeft echt VEEL te lang geduurd voordat daar bijvoorbeeld een fatsoenlijke OR-mapper voor was.

Maar dit wordt zo wel erg offtopic.

De belastingdienst gebruikt tegenwoordig Qt voor hun crossplatform zaken.

[ Voor 66% gewijzigd door BCC op 02-05-2009 13:32 ]

[Bram77]

Het lijkt er op dat hij/zij denk dat de R met performance te maken heeft. Niet dus

Bedankt voor de reacties! Heb ik wat aan
Ik heb naar QT gekeken, maar helaas ligt QT# op zijn gat.
C# is cool, maar om een C# cross platform applicatie te onderhouden is veel meer werk dan een Java applicatie. Als het engsinds native over met komen moet ik voor MS omgevingen Windows.Forms gebruiken, voor Unix-achtigen GTK# en voor mobiele platformen het zelfde verhaal...
Voor C++ geldt eigenlijk het zelfde...

Ik twijfel nu eigenlijk alleen nog tussen Java en JavafX. Vergeef me als ik nu iets doms zeg, dan heb ik me blijkbaar nog niet genoeg verdiept in de materie. Maar kan JavaFX als interface-taal gebruikt worden met Java? Dus alleen de interface opbouwen in JavaFX en het model en de view in Java afhandelen?

De hoeveelheid beschikbare libraries en de uitgebreide documentatie maakt Java bijzonder aantrekkelijk. De applicatie moet op Windows, Linux, Windows Mobile, iPhone, Android en Symbian kunnen draaien met zo min mogelijk gedoe om de verschillende branches te onderhouden. Het liefst zou ik de applicatie schrijven in Linux en daarna enkel de interface aanassen voor verschillende doeleinden.
Ik heb dit geprobeert met Glade-sharp/GTK-sharp en weet dat WPF de zelfde mogelijkheid bied. Maar ik vind het toch behoorlijk tegenvallen qua eenvoud in onderhoud. Al vind ik de duidelijke scheiding tussen interface en engine wel heerlijk!

Zowel Java als C# zijn snel genoeg voor wat ik er mee wil.

edit: Ik ben er niet op uit om een webapplicatie te schrijven.

[ Voor 4% gewijzigd door Bram77 op 02-05-2009 13:33 ]

[Mr_Light]

Moraelyn schreef op zaterdag 02 mei 2009 @ 13:16:
[...]

eh? JavaFX draait gewoon onder de gewone Java runtime, heb je niks extras voor nodig.

JavaFX 1.1.1 is not currently supported on your operating system. We encourage you to try JavaFX on Windows XP, Windows Vista or Mac OS X. (See system requirements for details.)

http://javafx.com/faq/

3.6 Will JavaFX be supported on Linux and Solaris?

The JavaFX 1.1 Desktop Runtime is officially supported on Microsoft Windows and Mac OS X desktops. Sun will be including support for these platforms in a future release in 2009.

unsupported versies zijn er wel(had ik duidelijker moeten zeggen).

//edit
JavaFX complimenteert Java en Javafx zou makkelijk op te pakken moeten zijn ik weet niet of je wel een keuze hoeft te maken. Anders kan je als nog van beide wat leren en vervolgens pakken waar jij denkt de meeste bang for buck te krijgen.

Geplaatst op zaterdag 02 mei 2009 12:58

@OMX2000
Wat betreft ide's heb ik nog nooit problemen gezien en voor hibernate en co hebben we standaarden als JPA. En spring is ontworpen met het idee dat afhankelijkheden met spring minimaal en geïsoleerd zouden moeten zijn. Nu heb ik nog niemand in een 3 maanden duren project spring voor guice of dergelijk zien verwisselen, of je dat zou moeten willen is ook erg twijfelachtig. Ik heb ook nog nooit problemen gehad met het vinden van de de-facto standaard binnen de java ecosysteem.

En zo als ik eerder aanwees is het volgens mij bij rad zo dat je sensibele standaard keuzes gebruikt. Revolutionaire feature's passen toch niet binnen rad. Bij rapid prototyping is dat wat anders maar dan mock je toch alles en nog wat.

[ Voor 41% gewijzigd door Mr_Light op 02-05-2009 13:52 ]

[Bram77]

Ik kan gewoon JavaFX applicaties draaien hier onder Linux. Zonder iets extra's te hoeven installeren, gewoon de laatste JRE uit de Ubuntu repos

[Mr_Light]

Bram77 schreef op zaterdag 02 mei 2009 @ 13:39:
Ik kan gewoon JavaFX applicaties draaien hier onder Linux. Zonder iets extra's te hoeven installeren, gewoon de laatste JRE uit de Ubuntu repos

ook de Media Component For Streaming Video demo enzo? (na maar even via de pm)

[Bram77]

Ik meen gelezen te hebben dat Video streaming niet werkt in Linux nee. Maar ik zal het eens even proberen.

[Gomez12]

OMX2000 schreef op zaterdag 02 mei 2009 @ 13:18:
[...]


Precies, en daar gaat het dus fout. De techniek staat niet stil, trends komen er in sneltrein vaart. Er zijn in de java wereld tig initiatieven die inspringen op die laatste trends. Dus als ik als architect keuzes moet maken, ben ik dus in eerste instantie een tijd bezig om de juiste frameworks en tooling te vinden.

Dat is meer onbekendheid met de taal. Als je bekend met de taal en de frameworks heb je al een keuze gemaakt voordat je aan het project begint...

In de .NET wereld gebeurt dat door 1 bedrijf, Microsoft. En in het algemeen heeft Microsoft een pragmatische aanpak (don't get me started on 'M'). Je ziet dus dat MS zeer snel inspringt op trends (Ajax, Silverlight, dynamic languages, etc), en dat ook zo doet dat je out of the box snel aan de slag kunt.

Wederom bekendheid, werk eens wat langer met Java en een bepaald framework en je kan net zo snel devven als met .Net.

Op de lange termijn maakt die keuzevrijheid niets meer uit, net zoals je bij .NET voor 1 framework kiest kan je dit ook bij Java ( dit is een eenmalige investering ) doen.

Als je bij Java per project een ander framework gaat kiezen dan kost dit inderdaad ontzettend veel tijd, maar je dit doet bij .Net niet ( kan wel als je echt wilt ) dus waarom bij java wel?

Doe je dus relatief korte projecten (3-4 maanden), dan geloof ik gewoon niet dat Java productiever zal zijn dan .NET. Loopt je project langer, en kun je investeren in het opzetten van een standaard workspace, selectie van frameworks, strikte keuzes van frameworks, dan denk ik dat weinig verschil is tussen Java en .NET.

En als je meerdere korte projecten achter elkaar doet dan kan je ook gewoon blijven profiteren van een standaard workspace / framewroks etc.
Het enige waar het fout gaat is als je per project iets 100% nieuw gaat opbouwen, maar waarom zou je dat willen doen?

[momania]

Gomez12 schreef op zaterdag 02 mei 2009 @ 14:35:
[...]
Als je bij Java per project een ander framework gaat kiezen dan kost dit inderdaad ontzettend veel tijd, maar je dit doet bij .Net niet ( kan wel als je echt wilt ) dus waarom bij java wel?

Omdat het je soms 1 of 2 dagen kost om een framework onder de knie te krijgen en je dat uiteindelijk een bak werk kan schelen. Waardoor je dus uiteindelijk weer sneller met je project klaar bent.
Je moet altijd de juiste tools/frameworks/(of zelfs taal) voor je project pakken en juist niet domweg maar hetzelfde blijven gebruiken omdat je dat al kent.

Alle frameworks hebben hun eigen voor- en nadelen. Op zichzelf staand, maar vaak ook afhankelijk van het project wat je er mee wilt doen.

[OMX2000]

Gomez12 schreef op zaterdag 02 mei 2009 @ 14:35:
[...]

Dat is meer onbekendheid met de taal. Als je bekend met de taal en de frameworks heb je al een keuze gemaakt voordat je aan het project begint...


[...]

Wederom bekendheid, werk eens wat langer met Java en een bepaald framework en je kan net zo snel devven als met .Net.

Op de lange termijn maakt die keuzevrijheid niets meer uit, net zoals je bij .NET voor 1 framework kiest kan je dit ook bij Java ( dit is een eenmalige investering ) doen.

Als je bij Java per project een ander framework gaat kiezen dan kost dit inderdaad ontzettend veel tijd, maar je dit doet bij .Net niet ( kan wel als je echt wilt ) dus waarom bij java wel?


[...]

En als je meerdere korte projecten achter elkaar doet dan kan je ook gewoon blijven profiteren van een standaard workspace / framewroks etc.
Het enige waar het fout gaat is als je per project iets 100% nieuw gaat opbouwen, maar waarom zou je dat willen doen?

Mijn argument is niet dat het bij Java niet kan. Maar mijn ervaring is dat steeds wanneer er wat nieuws wordt geintroduceerd, het gewoon meer tijd kost voordat de rook is opgetrokken, en het duidelijk is welke keuzes er gemaakt moeten worden. Natuurlijk heeft bekendheid met het platform ermee te maken, maar wat ik zie gebeuren in de Java wereld is dat trends niet snel opgepakt worden in de officiele "distributies" (IBM, Sun, Oracle.

Simpel voorbeeld. Een team van rond de ca. 30 Java ontwikkelaars gebruiken gestandaardiseerde workspaces, dit om te zorgen dat je sneller up en running bent bij het starten van een project. En dat er een standaard manier van werken ontstaat. Handig! Maar nu moet de boel ge-upgrade worden. Wat betekent dat alle 30 ontwikkelaars minimaal 2 dagen zoet zijn om hun workspaces te upgraden.
In .Net gebruik je over het algemeen Visual Studio, en customize je wat kleine dingen. Upgraden kost je hooguit een dag (da's uitzonderlijk). En vaak ondersteund een nieuwe versie van .NET het upgraden van een project van een vorige versie.

Ander voorbeeld. Webservices met Java... Een belangrijke eis is dat die dingen zich conformeren aan standaarden, en interop staat hoog op de eisenlijst. Er was daar een tijd lang (voor dat Axis volwassen werd) geen fatsoenlijke webservice stack. En het bouwen van services duurde gewoon echt langer in Java. Een service bouwen in .NET (ASMX) is een no-brainer (sommige vinden het zelfs te makkelijk).

Maar goed ik ga enorm off topic. Ik denk dat als je multi-plaftorm zeer belangrijk vindt. Je gewoon snel bij Java komt. Dus ik zeg go Java....

[roy-t]

Er worden hier nu veel rare dingen verteld,

Dat de beste oplossing voor de TS java is zijn we het denk ik allemaal mee eens.

Maar verder offtopic begrijp ik dat de diversteit in ontwikkel stijl en ontwikkel omgeving in Java er voor zorgt dat korte projecten minder RAD zijn dan korte projecten in .Net (1 IDE, 1 duidelijk gedocumenteerde codestijl 1 Framwork, etc...). Dat is toch ook logisch, bij .Net is er gewoon minder diversiteit.

Voor langere projecten gaat dit natuurlijk minder uitmaken en zou er net een tool kunnen zijn voor Java waar je een week aan moet wennen maar daarna per week 4 uur scheelt, die tijd haal je er natuurlijk uiteindelijk uit.

Het is dus hier ook weer een "Best tool for the Job" verhaal, en bij RAD is de snelheid waarmee je iets afmaakt gewoon ontzettend belangrijk, je wilt niet dat de klant betaald omdat jij het framework nog moet leren en iedereen op elkaar moet afstemmen, de klant wil betalen voor een programma, dus tenzij het in het voordeel van de klant is moet je dat niet doen .

Verder zij ook iemand dat als je 'goed' bent of alles weet over de tookits e.d. je de taal al weet voor het project. Ik hoop dat dit figuurlijk is want dit is natuurlijk pertinent onwaar, hoe kun je de taal kiezen als je niet weet wat de job is .

Anyway laat dit nou niet uitmonden tot een ordinaire java vs C# discussie. Iedereen heeft hier een andere visie op, persoonlijk prefereer ik C# voor Windows en Java voor multiplatform, maar iedereen mag lekker doen wat hij/zij wil

[Remus]

roy-t schreef op zaterdag 02 mei 2009 @ 18:25:
Er worden hier nu veel rare dingen verteld,

Dat de beste oplossing voor de TS java is zijn we het denk ik allemaal mee eens.

Maar verder offtopic begrijp ik dat de diversteit in ontwikkel stijl en ontwikkel omgeving in Java er voor zorgt dat korte projecten minder RAD zijn dan korte projecten in .Net (1 IDE, 1 duidelijk gedocumenteerde codestijl 1 Framwork, etc...). Dat is toch ook logisch, bij .Net is er gewoon minder diversiteit.

Voor langere projecten gaat dit natuurlijk minder uitmaken en zou er net een tool kunnen zijn voor Java waar je een week aan moet wennen maar daarna per week 4 uur scheelt, die tijd haal je er natuurlijk uiteindelijk uit.

Het is dus hier ook weer een "Best tool for the Job" verhaal, en bij RAD is de snelheid waarmee je iets afmaakt gewoon ontzettend belangrijk, je wilt niet dat de klant betaald omdat jij het framework nog moet leren en iedereen op elkaar moet afstemmen, de klant wil betalen voor een programma, dus tenzij het in het voordeel van de klant is moet je dat niet doen .

Dus je zegt eigenlijk: onder C#/.net heb ik geen keuze dus is de ontwikkelsnelheid hoger. Dat is natuurlijk een versimpelde voorstelling van zaken. Als een bedrijf oid net in C#/.net begint, dan hebben ze ook 'opstartkosten' om bekend te worden met de taal en het ontwikkelplatform. Hetzelfde geld voor Java, alleen heb je initieel een grotere keuze uit IDEs en frameworks om te gebruiken. Zodra je een keuze hebt gemaakt als bedrijf, projectorganisatie of team, dan moet je natuurlijk niet bij ieder project gaan switchen (tenzij daar een heel goede reden voor is) anders blijf je inderdaad iedere keer weer dat soort opstartkosten dragen.

Als je dus verder niet switched is er IMHO vervolgens nauwelijks verschil tussen gebruik van C#/.net en Java wat betreft de ontwikkelsnelheid.

[Gomez12]

momania schreef op zaterdag 02 mei 2009 @ 16:28:
[...]

Omdat het je soms 1 of 2 dagen kost om een framework onder de knie te krijgen en je dat uiteindelijk een bak werk kan schelen. Waardoor je dus uiteindelijk weer sneller met je project klaar bent.
Je moet altijd de juiste tools/frameworks/(of zelfs taal) voor je project pakken en juist niet domweg maar hetzelfde blijven gebruiken omdat je dat al kent.

Alle frameworks hebben hun eigen voor- en nadelen. Op zichzelf staand, maar vaak ook afhankelijk van het project wat je er mee wilt doen.

Tja, als jij elke keer van framework wilt switchen moet je imho niet zeuren over dat dit extra tijd zou kosten bij Java, het kost net zoveel tijd bij .Net alleen doe je het daar niet

Het is gewoon een keuze.

[Hydra]

Gomez12 schreef op zondag 03 mei 2009 @ 14:57:
Tja, als jij elke keer van framework wilt switchen moet je imho niet zeuren over dat dit extra tijd zou kosten bij Java, het kost net zoveel tijd bij .Net alleen doe je het daar niet

Het is gewoon een keuze.

Vind het sowieso gewoon een vreemde redenatie: "Onze .Net developers zijn one-trick-ponies, en daarom is .Net meer RAD dan Java". Als voorbeeld wordt de verscheidenheid aan XML parsers aangehaald: ik hoop dat je niet bedoelt dat je het verschil tussen een DOM en een SAX parser niet snapt?

[Sh4wn]

Ik zou voor python gaan. Tis crossplatform, tegen de tijd dat jij een Java applicatie voor het eerst gecompiled, heb ik mijn python applicatie volledig gedebugged en draait het als een zonnetje.

Daarnaast is het een prachtige syntax (ja het is anders dan je gewend bent, toen ik er mee begon dacht ik ook van wtf), maar nu ik het een tijdje doe, vind ik het eigenlijk de mooiste taal qua syntax.

Daarnaast is python nog veel mooier in veel meer opzichten. Tis bijvoorbeeld gigantisch dynamisch, een mega standaard lib, en nog een veel groter scala een 3rd party libs zijn te vinden op internet. Je hebt volledig de keuze welke UI toolkit je gaat gebruiken, zoals eerder genoemd zou ik ook voor PyQT gaan.

http://www.ferg.org/projects/python_java_side-by-side.html



En zoals dit plaatje al zegt, ik vind programmeren in python echt veel leuker dan in Java oid. En geloof me, als je al programmeer ervaring hebt, is python echt een appeltje eitje.

[ Voor 4% gewijzigd door Sh4wn op 04-05-2009 13:12 ]

[roy-t]

Wat betreft .net one trick ponies, er werd gepraat over projecten, daar heb je vaak niet een vast team, maar veel mensen van verschillende origine, vandaar. Natuurlijk heb je bij een vast bedrijf na 1 maal kiezen voor 1 toolkit/lib/etc.. even veel RAD als bij .net

Sh4wn schreef op maandag 04 mei 2009 @ 13:10:
Ik zou voor python gaan. Tis crossplatform, tegen de tijd dat jij een Java applicatie voor het eerst gecompiled, heb ik mijn python applicatie volledig gedebugged en draait het als een zonnetje.

Daarnaast is het een prachtige syntax (ja het is anders dan je gewend bent, toen ik er mee begon dacht ik ook van wtf), maar nu ik het een tijdje doe, vind ik het eigenlijk de mooiste taal qua syntax.

Daarnaast is python nog veel mooier in veel meer opzichten. Tis bijvoorbeeld gigantisch dynamisch, een mega standaard lib, en nog een veel groter scala een 3rd party libs zijn te vinden op internet. Je hebt volledig de keuze welke UI toolkit je gaat gebruiken, zoals eerder genoemd zou ik ook voor PyQT gaan.

http://www.ferg.org/projects/python_java_side-by-side.html

[afbeelding]

En zoals dit plaatje al zegt, ik vind programmeren in python echt veel leuker dan in Java oid. En geloof me, als je al programmeer ervaring hebt, is python echt een appeltje eitje.

Hoewel ik Python graag een keer zou willen programmeren klinkt dit wel erg fanboy, ook ben ik nu wel erg benieuwd naar de giga standaard lib, want ik vind die van .Net (en in iets mindere mate Java) al super giga .
(/me is stiekem heel benieuwd naar stackless Python omdat CCP daar zulke mooie dingen mee doet )

[ Voor 3% gewijzigd door roy-t op 04-05-2009 13:28 ]

[Sh4wn]

roy-t schreef op maandag 04 mei 2009 @ 13:27:
Wat betreft .net one trick ponies, er werd gepraat over projecten, daar heb je vaak niet een vast team, maar veel mensen van verschillende origine, vandaar. Natuurlijk heb je bij een vast bedrijf na 1 maal kiezen voor 1 toolkit/lib/etc.. even veel RAD als bij .net


[...]


Hoewel ik Python graag een keer zou willen programmeren klinkt dit wel erg fanboy, ook ben ik nu wel erg benieuwd naar de giga standaard lib, want ik vind die van .Net (en in iets mindere mate Java) al super giga .
(/me is stiekem heel benieuwd naar stackless Python omdat CCP daar zulke mooie dingen mee doet )

Het klinkt zo, omdat ik het eigenlijk ook een beetje ben En terecht ook, want het is gewoon een super taal

Hier heb je trouwens de library reference:
http://docs.python.org/library/index.html

Van simpele webservers tot File I/O, van XML tot Ini Parsers, van DB access tot serializers, python heeft bijna alles

[ Voor 11% gewijzigd door Sh4wn op 04-05-2009 13:32 ]

[OMX2000]

Hydra schreef op maandag 04 mei 2009 @ 10:56:
[...]


Vind het sowieso gewoon een vreemde redenatie: "Onze .Net developers zijn one-trick-ponies, en daarom is .Net meer RAD dan Java". Als voorbeeld wordt de verscheidenheid aan XML parsers aangehaald: ik hoop dat je niet bedoelt dat je het verschil tussen een DOM en een SAX parser niet snapt?

Nee, dat is niet wat ik bedoel. Ik bedoel dat er verschillende xml parsers zijn met ieder hun voor en nadelen. Dan heb je ook weer keus uit verschillende XSLT processors, en schema validators.

In .NET gebruikt je gewoon de standaard xml parser (pull parser ala stax) , en da's simpelweg een hele goede parser. Het moet gek lopen als je een reden kunt verzinnen om 'm niet te gebruiken.

Maar goed ik denk dat we een andere topic zouden moeten starten om het te hebben over de voor en nadelen van de verschillende platformen.

[Hydra]

Sh4wn schreef op maandag 04 mei 2009 @ 13:10:
http://www.ferg.org/projects/python_java_side-by-side.html

Sorry hoor, maar mag ik een teiltje? Grasping for straws comes to mind... Meer dan de helft van wat daar staat is gewoon niet van toepassing tenzij je Java code in notepad.

[rrrandy]

Bram77 schreef op zaterdag 02 mei 2009 @ 13:31:
De applicatie moet op Windows, Linux, Windows Mobile, iPhone, Android en Symbian kunnen draaien met zo min mogelijk gedoe om de verschillende branches te onderhouden.

Als je voor de iPhone ontwikkelt ben je gebonden aan Objective C. Sterker nog, je bent gebonden aan OS X als je de iPhone SDK wilt gebruiken.

[user109731]

Je kunt ook nog Jython gebruiken, Python met toegang tot alle Java classes. Probleem is dat je dan afaik geen PyQt kunt gebruiken, maar het kan handig zijn als je bestaande Java-code wilt gebruiken.

IMHO is Python een goed uitgedachte taal met een eenvoudige en uitgebreide standaard library, waarin je zeer snel kunt scripten. Java is meer verbose, je moet over het algemeen meer tikken om hetzelfde te bereiken. Dat helpt de compiler dan weer om snellere code te maken, maar de vraag is dan of je dat in elke programma merkt of nodig hebt...

Het is aan de TS om te beslissen welke tool/taal hij gaat gebruiken. Ik zou aanraden om een simpel cross-platform programma (soort prototype) te schrijven in de mogelijke omgevingen, en kijken hoe het bevalt

[YopY]

Hydra schreef op maandag 04 mei 2009 @ 13:48:
[...]


Sorry hoor, maar mag ik een teiltje? Grasping for straws comes to mind... Meer dan de helft van wat daar staat is gewoon niet van toepassing tenzij je Java code in notepad.

^dit. Sowieso is Java vs Python een onbegonnen zaak, aangezien ze een zeer verschillende doelgroep hebben. Dat Python meer productiviteit brengt zegt niks over hoe het zich houdt over 3-jaar lang durende projecten met meerdere ontwikkelaars - waar Java veel vaker voor gebruikt wordt dan Python. Dat Java 'verbose' en statically typed is geeft aan dat het veel geschikter is voor 'Design By Contract' en ander van dat soort powertermen, en minder voor RAD. Ik heb geen ervaring met RAD, echter (of Python), dus dat soort uitspraken zijn slechts gebaseerd op die link daar.

@Java vs .NET: Java lijkt veel opener en dynamischer te zijn dan .NET. Ik bedoel, pas sinds de laatste versie van .NET hebben ze een MVC framework - eigelijk de enige manier om een professionele webapp te bouwen waarbij de functionaliteit geheel gescheiden is van de presentatie en dat soort reclametermen, waarbij het bij Java en andere talen al jarenlang gemeengoed is. D'r was een poging om een .NET MVC framework te maken, maar die lijkt nooit echt aangeslagen te hebben. Ik heb niks tegen op Microsoft en .NET verder hoor (ik moet het nodig eens uitproberen overigens), maar met dat soort zaken krijg ik echt het idee dat Microsoft achter de feiten aanloopt bij bepaalde zaken.

@topic, Java is ideaal voor crossplatform ontwikkelen, lijkt me, als je 'officieel' wilt programmeren of een project hebt die langer loopt. Python lijkt me geschikter voor kortere projecten. JavaFX heb ik totaal geen ervaring mee, maar dat leek mij een soort van web-GUI / animatie-scripttaal, in de 5 minuten die ik ernaar gekeken heb. Ik wil wel eens zien of je daar GUIs mee kunt programmeren, liefst crossplatform, en liefst veel eenvoudiger dan Swing code kloppen.

[Abductee]

Ik heb Adobe AIR hier nog niet langs zien komen als voorstel, dus misschien is dit wel iets waar de TS naar kan kijken. Het draait op alle gangbare OS'en, en volgens mij moet het ook wel doenbaar zijn om de applicatie in bv Flash Player Lite te laten draaien...

[Mr_Light]

Mr_Light schreef op zaterdag 02 mei 2009 @ 13:33:
[...]


[...]


http://javafx.com/faq/

[...]


unsupported versies zijn er wel(had ik duidelijker moeten zeggen).

http://weblogs.java.net/b...9/05/full_javafx_com.html