Welke programmeertaal/ontwikkelomgeving voor Linux?

[Verwijderd]

Ik moet binnenkort een kleine applicatie schrijven dat in een Windows omgeving komt te draaien, tot dusver geen probleem, maar in een later stadium moet die applicatie mogelijk naar Linux 'gepoort' worden. Mijn vraag is nu in welke programmeertaal ik die applicatie het beste kan ontwikkelen, ik heb namelijk geen ervaring met programmeren voor Linux omgevingen.
Als ik de applicatie in Linux maak, is het dan een kwestie van compilen onder Kylix en klaar, of zit er meer achter? Het liefst programmeer ik niet in C, aangezien dat te veel tijd gaat kosten. Het liefst een ontwikkelomgeving zoals Delphi.

[Freee!!]

Ik zou haast zeggen dat je het eens met COBOL moet proberen, dat werkt zo ongeveer op alle mogelijke platformen (daarvoor is het een standaard taal ), maar als je C teveel werk vindt, zal dat ook voor andere 3-GL talen gelden.

offtopic:
Ik denk dat dit topic eigenlijk in SA thuishoort (is nog geen Software Ontwikkeling)PW thuishoort

[ Voor 24% gewijzigd door Freee!! op 18-02-2003 14:55 . Reden: Offtopic ]

[Rukapul]

Al gedacht aan Java? Dat is toch ongeveer de makkelijkste methode omdat je gewoon onder Windows kan devven.

Overigens hoef je voor een dual platform applicatie niet per se 2 mooi grafische interfaces te hebben. Prog de laatste tijd wel voor meerdere platformen, maar het hoofdwerk wordt gewoon onder Windows gedaan. Taal is C++. Elke nacht wordt de code automatisch op een Linux systeem gecompiled en uitgevoerd (test-before-programming) waarbij eventuele fouten gemaild worden. Zo hoef je altijd maar een paar kleine wijzigingen te maken die eenvoudig met een texteditor te maken zijn.
Om crossplatform makefiles te maken kun je evt qmake gebruiken (van QT) als je in C++ programmeert.
Zelf gebruik ik om te programmeren onder Linux met een IDE kdevelop, maar er zijn ongetwijfeld betere alternatieven (zijn ook topics hier in NOS/PW over geweest).

[Verwijderd]

IDE: anjuta is onder Gnome erg populair. Zelf gebruik ik overigens vim.

Taal: mjah... C++/C is erg moeilijk omdat je systeem calls doet, gebruik dus iets hogers. java, zoiets...

[Verwijderd]

Maar kan het met Delphi, dat zou namelijk de makkelijkste en snelste manier zijn.

[Kees]

nee, het kan niet met delphi, omdat delphi niet op linux draait.

Java draait wel onder linux, en is gewoon de beste keuze hiervoor.

[ronaldmathies]

Kees schreef op 18 February 2003 @ 15:19:
nee, het kan niet met delphi, omdat delphi niet op linux draait.

Java draait wel onder linux, en is gewoon de beste keuze hiervoor.

Zelf zou ik ook voor Java gaan omdat ik dat nu zelf doe. Maar als je eventueel Delphi wilt kijk dan eens naar Kylix van Borland (inprise.com). Dit is een ontwikkel IDE voor linux met volgens mij een pascal achtige taal.

[Sir Isaac]

python werkt onder zowel windows als linux als nog een heleboel. Het is een geinterpreteerde taal (je hoeft dus niet te compileren) met een erg eenvoudige syntax. Bovendien zijn er veel bibliotheken voor python, veel meer dan voor pascal/delphi.
Als je een gui bij je programma nodig hebt, kijk dan naar wxPython. Dit is een toolkit voor python die op windows gebruik maakt van wxWindows en op linux van wxGtk. Op deze manier kun je grafische programma's maken die onder zowel windows als linux draaien.

[u_nix_we_all]

Heb je zelf al eens gezocht? Wat heb je zelf al gevonden ?

Op de site van borland staat dit over delphi:

Borland® Delphi™ 7 Studio provides the migration path to Microsoft® .NET that developers have been waiting for. With Delphi, the choices are always yours: you're in control of a complete e-business development studio— with the freedom to easily take your solutions cross-platform to Linux.®

[edit]
1. Wat doet dit in NOS ? gaat duidelijk over proggen onder windows zowel als linux
2. Lees de NOS Faq/policy

[ Voor 15% gewijzigd door u_nix_we_all op 18-02-2003 15:28 ]

[Verwijderd]

Het kan dus wel met delphi, zolang je maar gebruik maakt van de CLX componenten. Je kunt dan je app onder linux compileren met kylix.

Wel de juiste feiten posten, Kees

Ik zou de keuze beperkt houden tussen Java of Kylix/Delphi. COBOL is nauwelijks serieus te nemen (je kunt die mensen ook een telraam geven ipv een computer) en C/C++ gaat je teveel tijd kosten. Dan blijven er imo 2 over.

[LordLarry]

Lijkt me een vraag voor P&W, maar toevallig viel ik hier binnen

Verwijderd schreef op 18 februari 2003 @ 15:16:
Maar kan het met Delphi, dat zou namelijk de makkelijkste en snelste manier zijn.

Ja, er is een Delphi versie voor Linux genaamd Kylix. Je kan zelfs vanaf Delphi 6 je Windows source (gemaakt met CLX, niet VCL) recompilen onder Linux met Kylix en dan heb je hetzelfde programma onder Linux!

Kees schreef op 18 februari 2003 @ 15:19:
nee, het kan niet met delphi, omdat delphi niet op linux draait.

Java draait wel onder linux, en is gewoon de beste keuze hiervoor.

Zie je wel dat het beter in P&W gevraagt had kunnen zijn Want dit klopt dus niet. Bovendien heb ik nog geen goede reden gehoord om java te gebruiken...

ronaldmathies schreef op 18 februari 2003 @ 15:21:
Dit is een ontwikkel IDE voor linux met volgens mij een pascal achtige taal.

Pascal idd, maar met Kylix 3 kan er ook C++ gebruikt worden. Ook in combinatie met Borland C++ Builder onder windows

[Freee!!]

Verwijderd schreef op 18 February 2003 @ 15:25:
Het kan dus wel met delphi, zolang je maar gebruik maakt van de CLX componenten. Je kunt dan je app onder linux compileren met kylix.

Wel de juiste feiten posten, Kees

Ik zou de keuze beperkt houden tussen Java of Kylix/Delphi. COBOL is nauwelijks serieus te nemen (je kunt die mensen ook een telraam geven ipv een computer)

Voorzichtig, ik ben een professioneel COBOL programmeur en hier word ik niet echt vrolijk van

en C/C++ gaat je teveel tijd kosten. Dan blijven er imo 2 over.

[Verwijderd]

[NOS] -> [PW]

[u_nix_we_all]

Mr. Liu schreef op 18 February 2003 @ 15:28:
[...]
Voorzichtig, ik ben een professioneel COBOL programmeur en hier word ik niet echt vrolijk van

[...]

Word je niet vrolijk van de discussie , of van het "professioneel cobol programmeur" zijn ?

[ Voor 3% gewijzigd door u_nix_we_all op 18-02-2003 15:33 . Reden: typo's ]

[Freee!!]

u_nix_we_all schreef op 18 februari 2003 @ 15:31:
[...]
Wordt je niet vrolijk van de discussie , of van het "profesioneel COBOL programmeur" zijn ?

Ik word niet zo vrolijk van het COBOL niet serieus nemen en het vergelijken met een telraam. Ik wil niet zover gaan dat ik het een flame of een troll noem, maar ik ken mensen die dat wel doen.

edit:

Maar zullen we het verder weer gezellig on-topic houden

[ Voor 14% gewijzigd door Freee!! op 18-02-2003 15:36 . Reden: on-topic :? ]

[LordLarry]

Om hier nog even extra op in te gaan

Verwijderd schreef op 18 februari 2003 @ 14:49:
Als ik de applicatie in Linux maak, is het dan een kwestie van compilen onder Kylix en klaar, of zit er meer achter? Het liefst programmeer ik niet in C, aangezien dat te veel tijd gaat kosten. Het liefst een ontwikkelomgeving zoals Delphi.

Als je je applicatie maakt met CLX componenten ipv de standaard VCL componenten is het een kwestie van hercompileren onder het juiste platform en klaar. Natuurlijk moeten er geen andere windows of linux specifieke dingen in de code zitten. CLX is gebaseerd op de Qt library. Deze zal je onder Linux en Windows dan ook nodig hebben.

[Verwijderd]

Voorzichtig, ik ben een professioneel COBOL programmeur en hier word ik niet echt vrolijk van

[off-topic]
Oops.. Het spijt me hoor, maar COBOL aanraden voor een nieuw te ontwikkelen project is imo gewoon op z'n zachts gezegd niet echt bij de tijd meer.

Dat COBOL een volledig functionele programmeertaal is waar nog steeds hele grote en belangrijke applicaties op draaien weet ik, maar als keuze voor 'nieuw project' is COBOL toch al jaren geen keuze meer, net zoals bv. FORTRAN, Clipper, etc.[/off-topic]

On-topic:

je zou natuurlijk ook kunnen overwegen om je app server-side te maken met webpagina's als output. Op die manier werkt het op alle systemen waarop een browser beschikbaar is (talk about cross-platform)

[mbravenboer]

Een aantal opties:

Java + SWT
Java + Swing
Java + AWT
Microsoft .NET + GTK (Mono, WinForms is geen optie)

Bij .NET is de programmeertaal niet relevant: C# is waarschijnlijk de meest logische keuze.

[Freee!!]

Verwijderd schreef op 18 February 2003 @ 15:40:
[...]
[off-topic]
Oops.. Het spijt me hoor, maar COBOL aanraden voor een nieuw te ontwikkelen project is imo gewoon op z'n zachts gezegd niet echt bij de tijd meer.

Dat COBOL een volledig functionele programmeertaal is waar nog steeds hele grote en belangrijke applicaties op draaien weet ik, maar als keuze voor 'nieuw project' is COBOL toch al jaren geen keuze meer, net zoals bv. FORTRAN, Clipper, etc.[/off-topic]
[...]

Er wordt nog steeds nieuwbouw gedaan in COBOL, er is een tekort aan COBOL programmmeurs (niemand die het nog op school krijgt) en het is toch de manier om COBOL te leren.

[nero355]

Java werkt ook nog eens op een MAC dus Java

[mbravenboer]

Er wordt nog steeds nieuwbouw gedaan in COBOL

Ik snap best dat je dit als professional nog als een optie aandraagt, maar je moet toch zelf ook wel toegeven dat het in deze context een beetje lachwekkend is? (niet denigrerend bedoeld uiteraard)

Mr. Liu: , er is een tekort aan COBOL programmmeurs (niemand die het nog op school krijgt) en het is toch de manier om COBOL te leren.

Is dat niet met name tbv van onderhoud, reengineering en conversie?

[djluc]

Perl kan je toch ook op Linux gebruiken, en ook op de Mac trouwens mocht je dat graag willen.

[Freee!!]

mbravenboer schreef op 18 February 2003 @ 15:51:
[...]
Ik snap best dat je dit als professional nog als een optie aandraagt, maar je moet toch zelf ook wel toegeven dat het in deze context een beetje lachwekkend is? (niet denigrerend bedoeld uiteraard)

Kijk nog eens goed naar mijn eerste reply (de eerste na de openingspost)

[...]
Is dat niet met name tbv van onderhoud, reengineering en conversie?

Onderhoud: ja
Reengineering: niet dat ik weet (ik weet niet alles)
Conversie: Waarheen? Bedrijven die serieus COBOL gebruiken willen toch graag iets dat even goed gedocumenteerd, even stabiel (ook platform afhankelijk maar goed) en bijvoorkeur ook nog ISO is.

[mbravenboer]

Mr. Liu: Reengineering: niet dat ik weet (ik weet niet alles)

Zie bijvoorbeeld dit project:
http://www.stratego-langu.../bin/view/Stratego/CobolX

Ik geloof dat ze bij de http://www.software-improvers.com/ (SIG) aardig wat met dergelijke geautomatiseerde Cobol renovatie projecten bezig zijn.

Zie bijvoorbeeld: http://www.software-improvers.com/Publications/senr9805.pdf

Je bent duidelijk een groot kenner (en dus aanhanger) van Cobol .

[whoami]

Ik heb nog COBOL gehad op de hogeschool (zo'n 5-tal jaar geleden).

Ik kan me goed voorstellen dat bedrijven - zoals banken, ed - nog steeds gebruik maken van COBOL. Ze hebben nl. tal van 'legacy' COBOL applicaties, en als ze nieuwe applicaties nodig hebben, waarom zouden ze die dan niet in COBOL schrijven? Anders moeten ze waarschijnlijk al hun reeds bestaande applicaties porten willen ze nog een geintegreerd geheel hebben.
Ik hou/hield zelf niet van de taal COBOL, maar ze is zeker niet te onderschatten. COBOL werd speciaal ontwikkeld om business-applicaties mee te schrijven.

Voor de topicstarter: als je zowiezo het liefst in iets 'Delphi-achtig' iets wilt werken, ga dan voor Kylix.
Echter, bedenk je wel dat, als je echt een goeie applicatie wilt bouwen, je er ook veel tijd zult moeten aan besteden. Gebruik Kylix/Delphi niet als VB, ttz, een RAD tool waar je gewoon je interface in elkaar klikt en dan speelt met de properties ed. Gebruik de kracht van Delphi/Kylix! Maak gebruik van de OO aspecten van de taal.

[Freee!!]

mbravenboer schreef op 18 February 2003 @ 16:25:
[...]
Je bent duidelijk een groot kenner (en dus aanhanger) van Cobol .

Voor grote kenners van COBOL moet je toch echt bij Wim Ebbinkhuizen zijn
Ik weet inderdaad redelijk wat van COBOL en vind het soms inderdaad de beste tool voor de job, maar ik ben geen blinde aanhanger van COBOL. Voor sommige dingen gebruik ik liever andere programmeertalen die daar beter geschikt voor zijn, maar COBOL blijft altijd aanwezig als nuttige all-round tool.

edit:

Het voordeel van COBOL (zoals ik al eerder noemde) is dat het op de meeste (vrijwel alle) platforms gebruikt kan worden en daarbij voorspelbare resultaten geeft.

[ Voor 14% gewijzigd door Freee!! op 18-02-2003 16:51 ]

[joepP]

mbravenboer schreef op 18 February 2003 @ 15:41:
Een aantal opties:

Java + SWT
Java + Swing
Java + AWT
Microsoft .NET + GTK (Mono, WinForms is geen optie)

Bij .NET is de programmeertaal niet relevant: C# is waarschijnlijk de meest logische keuze.

Een client-applicatie ontwikkelen in Java? Met een fatsoenlijke, snelle en portable user-interface? Geef mij eens één goed werkend voorbeeld...

[tomato]

joepP schreef op 18 februari 2003 @ 17:02:
Een client-applicatie ontwikkelen in Java? Met een fatsoenlijke, snelle en portable user-interface? Geef mij eens één goed werkend voorbeeld...

Beetje achterhaalde houding joepP...

Tegenwoordig kunnen we ons best andersom opstellen en er vanuit gaan dat dit alles goed mogelijk is tot jij met goede argumenten tegen komt.

[Glimi]

Even ten overvloede:
Ik zit niet te wachten op rants, trolls, flames en niet onderbouwde meningen!

[Verwijderd]

Kylix lijkt mij een zeer goede keuze in jou geval omdat je al ervaring met Delphi, en omdat het (vanaf versie 6/7) volledig compatible is.

Let wel op: als je componenten gaat aanschaffen oid, kijk dan wel of het ook onder Kylix werkt.

Gezien jou situatie (als ik deze goed begrijp) heb je niets / niet veel met Java gedaan, dus dat lijkt me ook niet de slimste keuze.

Daarnaast wil ik je ook aanraden om verder te kijken als GoT (nofi) en bij (andere) professionele gebruikers te raden te gaan.

[MSalters]

Qt is indrukwekkend simpel. Vanaf 3.0 zit er een ook een GUI designer bij, dus je kunt sleur&pleur je interface is elkaar duwen, en vervolgens er gewoon C++ (dus ook C) in hangen. En omdat die designer ook in Qt gebuwd is, is ook die op Linux beschikbaar en vrijwel identiek.
Als je je software Open Source maakt is Qt overigens gratis

* MSalters is professionele Qt gebruiker, en best tevreden. (fi)

[joepP]

tomato schreef op 18 February 2003 @ 17:15:
[...]

Beetje achterhaalde houding joepP...

Tegenwoordig kunnen we ons best andersom opstellen en er vanuit gaan dat dit alles goed mogelijk is tot jij met goede argumenten tegen komt.

Begrijp me niet verkeerd, Java is in essentie een prachtige taal! Maar, in mijn ervaring althans, ongeschikt als platform voor normale applicaties. Ik zal het wat verder toelichten.

Ik heb zelf wel wat ervaring met Java en cross-platform client-applicaties. Het is mij nooit gelukt om een fatsoenlijke userinterface onder zowel Windows als Linux als X-Windows te laten draaien. Als het er goed uitzag onder Windows was het gewoon niet mooi onder de rest, en andersom.

De enige manier om een mooie interface te krijgen was de Swing componenten te gebruiken, maar dan draaide alles te langzaam. Alsof over elke mouseklik nagedacht moet worden, om over het verslepen van vensters maar te zwijgen.

Vandaar dat ik vroeg naar een werkend voorbeeld van een multi-platform client-aplpicatie onder Java, die er mooi uitziet en lekker aanvoelt. Wat ik nog steeds nooit gezien heb...

[ Voor 5% gewijzigd door joepP op 19-02-2003 09:56 ]

[Bobco]

Mr. Liu schreef op 18 februari 2003 @ 16:49:
[...]
Voor grote kenners van COBOL moet je toch echt bij Wim Ebbinkhuizen zijn
Ik weet inderdaad redelijk wat van COBOL en vind het soms inderdaad de beste tool voor de job, maar ik ben geen blinde aanhanger van COBOL. Voor sommige dingen gebruik ik liever andere programmeertalen die daar beter geschikt voor zijn, maar COBOL blijft altijd aanwezig als nuttige all-round tool.

edit:

Het voordeel van COBOL (zoals ik al eerder noemde) is dat het op de meeste (vrijwel alle) platforms gebruikt kan worden en daarbij voorspelbare resultaten geeft.

Ebbinkhuizen weet ongetwijfeld veel van COBOL, maar zijn boek, waar vrijwel iedere cursus COBOL mee werkt, blinkt nu niet echt uit in overzichtelijkheid.

Verder heb ik niet het idee dat COBOL nu een schoolvoorbeeld is van een all-round programmeertaal. Naar mijn idee is COBOL voornamelijk geschikt voor het in batch verwerken van grote aantallen gegevens. Als je kijkt naar de toepassingen waarin COBOL veel gebruikt wordt dan is dat blijkbaar ook het type applicatie waar deze taal het meest geschikt voor is.

Persoonlijk heb ik geen enkele ervaring met de combinatie GUI/COBOL. De taal zelf lijkt me daar ook niet geschikt voor, maar misschien kun jij hier nog wat over roepen.

Voorspelbare resultaten geeft (hopelijk) iedere programmeertaal. COBOL had met het ALTER statement trouwens wel een heel erg mooie constructie om die voorspelbare resultaten om zeep te helpen

[Freee!!]

Bobco schreef op 19 februari 2003 @ 10:40:
[...]


Ebbinkhuizen weet ongetwijfeld veel van COBOL,

Mag ook wel, hij zit nog steeds in het ANSI-commitee voor COBOL

maar zijn boek, waar vrijwel iedere cursus COBOL mee werkt, blinkt nu niet echt uit in overzichtelijkheid.

Heb ik niet zoveel last van

Verder heb ik niet het idee dat COBOL nu een schoolvoorbeeld is van een all-round programmeertaal. Naar mijn idee is COBOL voornamelijk geschikt voor het in batch verwerken van grote aantallen gegevens. Als je kijkt naar de toepassingen waarin COBOL veel gebruikt wordt dan is dat blijkbaar ook het type applicatie waar deze taal het meest geschikt voor is.

De basis van het pakket waar ik aan werk is COBOL (sommige delen al dertig jaar oud), met voldoende scherm-toepassingen

Persoonlijk heb ik geen enkele ervaring met de combinatie GUI/COBOL. De taal zelf lijkt me daar ook niet geschikt voor, maar misschien kun jij hier nog wat over roepen.

Dat is gewoon een interface, kan altijd (maar persoonlijk ben ik niet zo'n voorstander van GUIs, ik heb zelfs een hekel aan GUI/400 van Seagull, een screenscraper die op de PC draait en je AS/400 green-screen vertaalt naar een GUI).

Voorspelbare resultaten geeft (hopelijk) iedere programmeertaal. COBOL had met het ALTER statement trouwens wel een heel erg mooie constructie om die voorspelbare resultaten om zeep te helpen

Het belangrijkste woord heb je hier zelf al gebruikt ('had')

[Bobco]

Mr. Liu schreef op 19 February 2003 @ 10:57:
De basis van het pakket waar ik aan werk is COBOL (sommige delen al dertig jaar oud), met voldoende scherm-toepassingen

[...]

Dat is gewoon een interface, kan altijd (maar persoonlijk ben ik niet zo'n voorstander van GUIs, ik heb zelfs een hekel aan GUI/400 van Seagull, een screenscraper die op de PC draait en je AS/400 green-screen vertaalt naar een GUI).

Mja, COBOL heeft absoluut nog steeds een plaats als het gaat om legacy applicaties. Het is alleen wel duidelijk dat COBOL nooit meer uit de administratieve hoek zal komen. Niet dat dat nu betekent dat er binnen afzienbare tijd geen COBOL apps meer zullen zijn, maar de markt wordt niet echt groter.

Wat je hierboven al meldt over de 'scherm-toepassingen' laat volgens mij duidelijk zien dat COBOL niet de meest geschikte taal is om mooie user interfaces mee te bouwen. En mooi slaat dan niet alleen op kleurtjes.

Zelf heb ik in een grijs verleden nog wel eens TIP transacties in COBOL op een Unisys 2200 aangepast/gemaakt. Heel betrouwbaar, maar om het nu een fijne interface te noemen gaat wel heel erg ver.

Het hele model van werken met transactie monitoren als CICS is natuurlijk ondertussen al zo oud als de weg naar Rome. Het werkt goed, maar het idee dat je eerst een compleet scherm door moet en daarna pas een idee hebt of het goed is of niet is niet meer helemaal van deze tijd. Een moderne interface is veel interactiever (als het goed is) en kan de gebruiker sneller wijzen op fouten en mogelijkheden dan mogelijk is met een transactie monitor.

[Freee!!]

Bobco schreef op 19 februari 2003 @ 11:07:
[...]

Mooi gaat best wel.

Ik denk dat we het hier maar bij moeten laten, want hoewel best interessant gaat dit toch wel heel erg off-topic

[tomato]

joepP schreef op 19 February 2003 @ 09:56:
De enige manier om een mooie interface te krijgen was de Swing componenten te gebruiken, maar dan draaide alles te langzaam. Alsof over elke mouseklik nagedacht moet worden, om over het verslepen van vensters maar te zwijgen.

Dat is inderdaad wel een van de grootste nadelen van Swing, maar met de huidige computers valt dat allemaal best wel mee.

Vandaar dat ik vroeg naar een werkend voorbeeld van een multi-platform client-aplpicatie onder Java, die er mooi uitziet en lekker aanvoelt. Wat ik nog steeds nooit gezien heb...

Bijvoorbeeld Eclipse (IDE) of Jext (editor).

Java heeft nu zeker met SWT een erg strakke GUI lib die ook nog eens snel is op alle platformen. Alleen jammer dat SWT vooralsnog erg aan Eclipse gebonden wordt door IBM. Ik verwacht wel dat dat gaat veranderen als het een en ander wat verder ontwikkeld is en door meer mensen ontdekt is.

[joepP]

tomato schreef op 19 februari 2003 @ 12:02:
[...]

Dat is inderdaad wel een van de grootste nadelen van Swing, maar met de huidige computers valt dat allemaal best wel mee.

Valt wel mee?

Het valt helemaal niet mee. Met een 1.4GHz processor draaien applicaties met wat meer dan 3 knoppen gewoon te traag. En de meeste kantoormachines hebben niet eens zo'n processor.

[...]

Bijvoorbeeld Eclipse (IDE) of Jext (editor).

Java heeft nu zeker met SWT een erg strakke GUI lib die ook nog eens snel is op alle platformen. Alleen jammer dat SWT vooralsnog erg aan Eclipse gebonden wordt door IBM. Ik verwacht wel dat dat gaat veranderen als het een en ander wat verder ontwikkeld is en door meer mensen ontdekt is.

Je begrijpt me verkeerd. Ik wil graag een voorbeeld zien van een programma met een mooie userinferface, dat er goed uitziet en goed performt op zowel Windows als Linux als X-Windows. Geschreven in Java, zonder aanpassingen per OS.

Meer vraag ik niet

[mbravenboer]

joepP: Het valt helemaal niet mee. Met een 1.4GHz processor draaien applicaties met wat meer dan 3 knoppen gewoon te traag. En de meeste kantoormachines hebben niet eens zo'n processor.

Nou ja, de performance (snelheid en geheugengebruik) van Swing is inderdaad wel een issue (zeker van de EditorPanes en dergelijke), maar je kan ook overdrijven. Ik heb toevallig precies zo'n 1.4 Ghz. Ik gebruik voor ontwikkeling altijd een lichte editor omdat IDEs niet geschikt zijn voor mijn werkzaamheden. Jext draait daarbij als een zonnetje en ik gebruik ik het dus voor al mijn ontwikkelwerk, wat over het algemeen geen Java werk is. Jext heeft toch wel iets meer dan drie knoppen .

Je begrijpt me verkeerd. Ik wil graag een voorbeeld zien van een programma met een mooie userinferface, dat er goed uitziet en goed performt op zowel Windows als Linux als X-Windows. Geschreven in Java, zonder aanpassingen per OS.

Eclipse en Jext lijken me goede voorbeelden? Eclipse heeft een zeer fraaie GUI, Jext heeft een redelijk goede GUI. Jext maakt gebruik van Swing en dus is alle GUI code daar platform onafhankelijk (ook de GUI library zelf dus). Eclipse maakt gebruik van SWT. De GUI library zelf (SWT dus) heeft een port naar elk systeem nodig, maar de GUI zelf is natuurlijk gewoon platform onafhankelijk.

Overigens heeft Apple voor Mac OS X een native look and feel geimplementeerd voor Swing. Swing applicaties draaien hierdoor op een Mac OS X machine zeer fraai en vloeiend. Ik zou graag zien dat er voor meer platformen (met name Microsoft Windows uiteraard) native look and feel implementaties komen.

[Verwijderd]

tomato schreef op 19 februari 2003 @ 12:02:

[..]

Java heeft nu zeker met SWT een erg strakke GUI lib die ook nog eens snel is op alle platformen. Alleen jammer dat SWT vooralsnog erg aan Eclipse gebonden wordt door IBM. Ik verwacht wel dat dat gaat veranderen als het een en ander wat verder ontwikkeld is en door meer mensen ontdekt is.

Valt redeling mee. Pak swt.jar en de .dll of .so uit je org.eclipse.swt.<OS>_2.0.X directory, zorg dat je swt.jar in je classpath hebt staan en de .dll in je huidige dir of in java.library.path (zal wel System.property zijn ofzo, nog niet uitgezocht) en je kunt swt gebruiken.

Dit voorbeeld zojuist in windows gecompiled en het werkt... (overigens niet zelf geschreven )

Java:

import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.widgets.Label;
import org.eclipse.swt.SWT;
import org.eclipse.swt.layout.RowLayout;

public class Hello {

    public static void main(String[] args)
    {
        Display display = new Display();
        final Shell shell = new Shell(display);
        RowLayout layout = new RowLayout();
        layout.justify = true;
        layout.pack = true;
        shell.setLayout(layout);
        shell.setText("Hello, World!");
        Label label = new Label(shell, SWT.CENTER);
        label.setText("Hello, World!");
        shell.pack();
        shell.open ();
        while (!shell.isDisposed())
        {
            if (!display.readAndDispatch()) display.sleep ();
        }
       display.dispose ();
   }
}

Ga nu ff in linux testen met de .so

[Bobco]

joepP schreef op 19 February 2003 @ 13:07:
[...]
Valt wel mee?
Het valt helemaal niet mee. Met een 1.4GHz processor draaien applicaties met wat meer dan 3 knoppen gewoon te traag. En de meeste kantoormachines hebben niet eens zo'n processor.
[...]
Ik wil graag een voorbeeld zien van een programma met een mooie userinferface, dat er goed uitziet en goed performt op zowel Windows als Linux als X-Windows. Geschreven in Java, zonder aanpassingen per OS.

Ik draai hier IntelliJ, een behoorlijk uitgebreide ontwikkelomgeving (in Java) op een PIII 600 en ik heb niet het idee dat het langzaam gaat. De applicatie laden duurt wel even, maar daarna heb ik niet het gevoel dat het een langzame applicatie is. Word2000 afsluiten duurt bijvoorbeeld langer dan IntelliJ stoppen.

Kijk ook hier eens rond...

[tomato]

edit:
Sorry, nooit edit-venstertje een kwartier open laten staan voor op 'submit' te klikken. Beetje late reactie dus

joepP schreef op 19 February 2003 @ 13:07:
Het valt helemaal niet mee. Met een 1.4GHz processor draaien applicaties met wat meer dan 3 knoppen gewoon te traag. En de meeste kantoormachines hebben niet eens zo'n processor.

Ja-nee-ja-nee wordt een beetje vervelend, zeker als het onderwerp subjectief is, maar dit soort opmerkingen zijn toch echt zwaar overdreven.

Je begrijpt me verkeerd. Ik wil graag een voorbeeld zien van een programma met een mooie userinferface, dat er goed uitziet en goed performt op zowel Windows als Linux als X-Windows. Geschreven in Java, zonder aanpassingen per OS.

Je begrijpt mijn antwoord verkeerd

Precies op die vraag gaf ik een antwoord.

(ik bedoelde dus niet dat je met Eclipse, of met Jext bepaalde applicaties kunt maken. ik doelde echt op de applicaties Eclipse en Jext zelf)

Jext gebruikt volgens mij Swing en Eclipse gebruikt SWT.

[ Voor 7% gewijzigd door tomato op 19-02-2003 13:53 ]

[joepP]

Okee,

ik heb net IntelliJ IDEA gedownload, en geinstalleerd op een Celly 1Gig. Ik moet bekennen, het ziet er erg goed uit! Niets mis mee. Maar sorry, het IS gewoon echt traag...

- Als ik in de editor stukken code wil selecteren met het toetsenbord (Shift ingedrukt, je weet wel) reageert het gewoon niet lekker. Soms duurt het even voor er reactie is, vooral als je snel op de knoppen drukt. Net of het gebufferd wordt, en er ineens 2 keypresses tegelijk uitgevoerd worden.

- Als je Ctrl-V ingedrukt houdt wordt het scherm niet continu ververst, maar slechts de scrollbar rechts. Beetje jammer.

- Je ziet het scherm gewoon opgebouwd worden als er flink wat elementen op een formpje staan, bijvoorbeeld bij Options/Keymaps.

- Met de muis bewegen over het dropdown menu aan de bovenkant loopt ook al niet lekker.

Het voelt allemaal aan alsof ik werk op een Terminal Server Client over een trage internet-verbinding. Misschien ben ik wel een zeikerd, maar we hebben het hier over een 1GHz processor, en dan verwacht ik dat dit soort zaken gewoon VEEL sneller werken.

[joepP]

LordLarry schreef op 20 februari 2003 @ 16:00:
Waarom schop je? Je stelt toch geen vraag meer? Het topic is al genoeg uitgekauwd IMHO. Als je nog specifieke vragen hebt moet je die stellen. Het liefst in een nieuw topic.

Omdat er nog een discussie loopt over het wel/niet traag zijn van Java voor desktop applicaties. Ik heb gister een applicatie geinstalleerd die volgens enkelen hier voldeed aan mijn eisen van snelheid & uiterlijk. Niet dus.

Daar wil ik nog wel graag een reactie op eigenlijk.

[whoami]

Mensen hebben ook nog een leven, misschien komt die reactie er wel nog, misschien ook niet meer.
_{enkele replies getrashed}

[mbravenboer]

Eerlijk gezegd vind ik die discussie zo enorm afgezaagd dat ik er absoluut niet op in wil gaan .

Toch dan maar een beetje reactie, een kansloze en zinloze discussie zorgvuldig vermijdend: De manier waarop je software ervaart verschilt nogal, met name afhankelijk van je instelling en het pakket wat je normaal gewend bent. Ook computers verschillen sterk: een goede processor is zeker niet de beste garantie voor een vloeiende Swing GUI. Zelfs besturingssystemen en Java 2 Runtime Environment versies verschillen sterk.

Niemand zal zeggen dat Java GUIs snelheidsmonsters zijn, maar je overdrijft ook al je ze allemaal afwijst. Ik heb zelf altjd een lichte en snelle editor gebruikt en ben op dit moment trevreden met Jext. Dat zegt voldoende voor mijn situatie.

Probeer Eclipse nog maar eens zou ik zeggen. SWT is weer een hele andere wereld.

[joepP]

mbravenboer schreef op 20 februari 2003 @ 17:44:
Eerlijk gezegd vind ik die discussie zo enorm afgezaagd dat ik er absoluut niet op in wil gaan .

Toch dan maar een beetje reactie, een kansloze en zinloze discussie zorgvuldig vermijdend: De manier waarop je software ervaart verschilt nogal, met name afhankelijk van je instelling en het pakket wat je normaal gewend bent. Ook computers verschillen sterk: een goede processor is zeker niet de beste garantie voor een vloeiende Swing GUI. Zelfs besturingssystemen en Java 2 Runtime Environment versies verschillen sterk.

Uiteraard. Het is allemaal maar subjectief. Mijn punt was echter dat Java voor normale Desktopapplicaties te traag was, en daar blijf ik bij. Hoewel ik moet zeggen dat er wel VEEL vooruitgang geboekt is de laatste tijd, ik was verbaasd over de looks van Eclipse.

Niemand zal zeggen dat Java GUIs snelheidsmonsters zijn, maar je overdrijft ook al je ze allemaal afwijst. Ik heb zelf altjd een lichte en snelle editor gebruikt en ben op dit moment trevreden met Jext. Dat zegt voldoende voor mijn situatie.

Probeer Eclipse nog maar eens zou ik zeggen. SWT is weer een hele andere wereld.

Eclipse had ik juist geprobeerd, en als te traag bevonden.

De reden dat ik zo zeikerig overkom is dat ik me soms nogal stoor aan het Java-voor-Java-na gepraat. Het lijkt wel een godsdienst.

[Glimi]

joepP schreef op 20 February 2003 @ 17:54:
Eclipse had ik juist geprobeerd, en als te traag bevonden.

De reden dat ik zo zeikerig overkom is dat ik me soms nogal stoor aan het Java-voor-Java-na gepraat. Het lijkt wel een godsdienst.

joepP schreef op 19 February 2003 @ 16:05:
Okee,

ik heb net IntelliJ IDEA gedownload, en geinstalleerd op een Celly 1Gig. Ik moet bekennen, het ziet er erg goed uit! Niets mis mee. Maar sorry, het IS gewoon echt traag...

Dusssssss, wat is het nu (IDEA == Swing nl.)

[Verwijderd]

Er zitten hier gewoon een aantal goede java-minded-programmeurs, en dan krijg je dit al snel.

Goed, dan spuit 11, met een andere invalshoek..

waarom moeilijk doen met java, terwijl je met kylix gewoon heel eenvoudig een app in elkaar draait die op beide platformen goed draait, en nog snel is ook?

Zonder dat er op de client PC ook maar iets geinstalleerd hoeft te worden, enz..

//edit iets uitgebreider dan

wat ik niet begrijp: topicstarter geeft aan dat het om een kleine applicatie gaat, welke in 1e instantie op windows gedraaid gaat worden, later mogelijk op linux.

C wordt uitgesloten vanwege tijdsoverwegingen, topicstarter geeft aan dat hij het liefst een IDE als Delphi gebruikt.

Hoe kun je dan (objectief gesproken) tot een ander advies dan Delphi/Kylix komen?

Ik zie archaische talen voorbijkomen en niche talen. De enige andere suggestie die nog enigszins reeel is tot nu toe is Java. Echter, topicstarter geeft al aan dat tijd een factor is.

De hele discussie omtrend Java geeft al aan dat je niet zo een-twee-drie klaar bent. Je moet eerst op zoek naar een editor die je bevalt, dan nog de juiste libraries erbij, ik zie registersleutels welke bij bep. keuze gewijzigd moeten worden, andere applicaties/libraries welke op het client station geinstalleerd moeten worden en als laatste performance.

De discussie of java snel of traag is, is hier volledig off-topic en overbodig. Het gaat er namelijk niet over de absolute snelheid, maar om de relatieve snelheid. Topicstarter vraagt om een keuze tussen ontwikkelomgeving/talen. Dan is de enige juist performance overweging een vergelijking tussen Java en Delphi. En dat wint delphi, hands down. Gisteren, vandaag en ook in de toekomst voorlopig nog wel even. Wil je echte pure performance dan moet je voor Assembly, C of C++ gaan, maar dat heeft topicstarter zelf al uitgesloten.

Nadeel van Delphi: Linux en Windows, dan houdt het al snel op.

[ Voor 69% gewijzigd door Verwijderd op 20-02-2003 18:49 ]

[mbravenboer]

joepP: Mijn punt was echter dat Java voor normale Desktopapplicaties te traag was, en daar blijf ik bij.

Het grootste probleem is dat Sun op GUI gebied alleen maar troep aflevert. AWT was gewoon een volledige giller. Het design van Swing is voor een developer fantastisch, maar qua performance was het lange tijd te triest voor woorden (verbeterend dus).

De reden dat ik zo zeikerig overkom is dat ik me soms nogal stoor aan het Java-voor-Java-na gepraat. Het lijkt wel een godsdienst.

Nou ja, ik hier maar weinig echt opgehemeld zien worden. Kan je je voorstellen dat mensen die er soms in slagen om een redelijke GUI in Java te programmeren weer iemand langs zien komen die volledig ongenuanceerd alle GUis in Java afkraakt? Nuance is dus aan beide 'kanten' belangrijk.

Het probleem van Java zit naar mijn mening overigens niet in Java maar met name in de GUI libraries. SWT is een aardige poging denk ik. Ook zijn er nog andere bindingen naar native implementaties zoals van GTK en Qt.

Overigens ben ik een ernstige zondaar als ik Java als godsdienst zou hebben .

[whoami]

Owja, om nog eens terug te komen op dat Java verhaal (dat Java traag zou zijn enzo). Oké, het is misschien wel traag, maar ik heb hier JBuilder staan (dat in Java geschreven is als ik mij niet vergis), en dat draait hier op m'n P2 400 met 356 mb RAM wel vloeiend. ('t Opstarten duurt wel een tijdje).

Verder: zoals ik al eerder verkondigd had, en zoals hezik al zei is de topicstarter het meest gebaat bij Kylix. (Maar ik denk dat hij dat nu toch al door heeft).

[Bobco]

joepP schreef op 20 februari 2003 @ 17:40:
[...]
Ik heb gister een applicatie geinstalleerd die volgens enkelen hier voldeed aan mijn eisen van snelheid & uiterlijk. Niet dus.
Daar wil ik nog wel graag een reactie op eigenlijk.

Sommige mensen hebben inderdaad een leven Maar om nog even op jouw ervaringen met IntelliJ terug te komen: ik heb het idee dat jij een andere applicatie ziet dan ik.

Ik draai hier IntelliJ 3.0 op een PIII met 384MB naast een applicatie als Word2000 op NT4 (tja, een bedrijfsmachine, dus het is niet anders...). Als ik met mijn muis over de dropdown menus ga waadoor ze openklappen kan ik geen echt verschil in snelheid zien tussen Word2000, een applicatie waar je van mag aannemen dat íe snel is, en IntelliJ. Misschien dat er wel een verschil is, maar dat is voor mij in deze configuratie echt niet merkbaar.

Verder heb ik nog even gekeken naar de manier waarop bijvoorbeeld dat Options|Keymaps dialoogje openklapt. De eerste keer duurt het minder dan een seconde, de tweede keer staat 'ie er ogenblikkelijk.

Kortom: onze ervaringen verschillen.

Ik werk al meer dan een jaar met IntelliJ en heb nog nooit het gevoel gehad dat het 'langzaam' zou zijn. Ik denk dat de snelhied van de GUI ook net iets minder belangrijk is dan de functionaliteit.

Verder ben ik het met je eens dat een 'standaard' Swing GUI nu niet het meest fraaie is om te zien. Maar het werkt wel, en dat ook nog eens cross-platform. In sommige omstandigheden (zie de aanleiding tot dit topic) is dat een belangrijk voordeel...

[joepP]

mbravenboer schreef op 20 February 2003 @ 18:43:
[...]

Het grootste probleem is dat Sun op GUI gebied alleen maar troep aflevert. AWT was gewoon een volledige giller. Het design van Swing is voor een developer fantastisch, maar qua performance was het lange tijd te triest voor woorden (verbeterend dus).

Helemaal mee eens.

[...]

Nou ja, ik hier maar weinig echt opgehemeld zien worden. Kan je je voorstellen dat mensen die er soms in slagen om een redelijke GUI in Java te programmeren weer iemand langs zien komen die volledig ongenuanceerd alle GUis in Java afkraakt? Nuance is dus aan beide 'kanten' belangrijk.

Het probleem van Java zit naar mijn mening overigens niet in Java maar met name in de GUI libraries. SWT is een aardige poging denk ik. Ook zijn er nog andere bindingen naar native implementaties zoals van GTK en Qt.

Overigens ben ik een ernstige zondaar als ik Java als godsdienst zou hebben .

Je hebt helemaal gelijk. Mijn mening is ook niet zo ongenuanceerd als het misschien overkomt, ik ben zelfs zeer gecharmeerd van Java als taal. Alleen je geeft de topicstarter gewoon een verkeerd advies hier, zeker als ie al bekend is met Delphi en alleen Linux als extra platform wenst.

Ik geef ook toe dat ik wat vooringenomen was door ZEER slechte ervaringen met Java in het verleden, het gaat momenteel duidelijk de goede kant op.

[Verwijderd]

Ik vind Delphi goed alternatief voor heem, en dan suggestie dat qua performance C/C++ sneller is dan een Delphi programma is in sommige situaties niet het geval; dan is een Delphi programma toch echt sneller dan een C/C++ programma. Ligt er gewoon aan hoe je je programam in elkaar sloopt

[Creepy]

Verwijderd schreef op 21 February 2003 @ 14:10:
Ik vind Delphi goed alternatief voor heem, en dan suggestie dat qua performance C/C++ sneller is dan een Delphi programma is in sommige situaties niet het geval; dan is een Delphi programma toch echt sneller dan een C/C++ programma. Ligt er gewoon aan hoe je je programam in elkaar sloopt

Jah.. en natuurlijk heb je dit topic gelezen en gezien dat de TS al met Delphi bezig was en een alternatief zoekt voor Linux?????
(en niet aankomen dat ie dan Kylix moet gebruiken, want dat is ook al flink uitgelegd in dit topic).

[joepP]

whoami schreef op 20 februari 2003 @ 19:51:
Owja, om nog eens terug te komen op dat Java verhaal (dat Java traag zou zijn enzo). Oké, het is misschien wel traag, maar ik heb hier JBuilder staan (dat in Java geschreven is als ik mij niet vergis), en dat draait hier op m'n P2 400 met 356 mb RAM wel vloeiend. ('t Opstarten duurt wel een tijdje).

Verder: zoals ik al eerder verkondigd had, en zoals hezik al zei is de topicstarter het meest gebaat bij Kylix. (Maar ik denk dat hij dat nu toch al door heeft).

Ik draai hier JBuilder 8, op een 2Gig processor met 512Mb RAM. En sorry, echt vloeiend durf ik het toch allemaal niet te noemen. Als je een formpje ontwikkelt en je dropt er wat knopjes/whatever op moet je gewoon wachten. Zeker als ik het vergelijk met Delphi, wat op mijn 1Gig Celly vele malen sneller loopt.

Blijkbaar hanteer jij een andere definitie van vloeiend.

[Elissen]

Ik ga toch weer ff terug komen op Delphi/Kylix. Ik ga geen objectief verhaaltje neerzetten want ik ben Delphi fan .
De voordelen voor het gebruik van Delphi & Kylix:
- Bij aanschaf van Delphi 7 krijg je Kylix 3 Delphi Edition erbij kado
- Grandioze IDE (die de topicstarter al kent?)
- (is al eerder aangegeven) Bij gebruik van de CLX is de gehele GUI zo te compileren. Dit komt omdat er dan gebruik wordt gemaakt van de QT-Libary. Deze moet dan wel aanwezig zijn. Lijkt me onder Linux niet echt een probleem, onder Windows moet je een extra dll mee leveren, maar die kan je ook in de dir van je applicatie plaatsen.
- Database is ook cross-platform. Gebruik daarvoor de dbExpress componenten.
- Veel systeemverschillen worden door Delphi/Kylix al afgevangen. Alle functies die in Delphi in SysUtils zitten werken precies hetzelfde onder Kylix.

Wat moet je doen voor het porteren? Hier en daar mbv compiler directives aanpassingen maken.

Delphi:

uses
  {$IFDEF MSWINDOWS} Windows, {$ENDIF}
  {$IFDEF LINUX} Libc, {$ENDIF}
  SysUtils;

MSWINDOWS is gedefinieerd onder Windows en LINUX onder Linux . Borland raad het gebruik van MSWINDOWS aan, omdat er wellicht in de toekomst ook nog een WIN32 en WIN64 gaat komen en dan zal in beide gevallen MSWINDOWS gedefinieerd zijn. Tevens raad Borland het af om de volgende te gebruiken:

Delphi:

uses {$IFDEF MSWINDOWS} Windows, {$ELSE} Libc, {$ENDIF} SysUtils;

Dit omdat er wellicht in de toekomst nog een Mac-versie komt.

Ik heb zelf nog niet de kans gehad om serieus met Kylix aan de gang te gaan, maar als je beging lijkt het me handig om aan een paar dingen te denken.
Als je gebruik maakt van een functie uit bijvoorbeeld Windows, maar dan voor jezelf een functie waarvoor je mbv compiler directives twee implementaties maakt.

Ik hoop dat ik een beetje heb kunnen toelichten wat er bij komt kijken. Als er verder nog vragen zijn hoor/lees ik het wel.