🚀 go-pugleaf

Johan Vervloet <johan@linux.be> wrote:
> Een heel eenvoudige vraag:
>
> welke programmeertalen zijn er ter beschikking om een 
> gui-database-applicatie te programmeren? In eerste instantie geen 
> web-app, maar in de toekomst zou dat er wel van kunnen komen.

Hangt af van je databeest. :-)  De meeste databeesten hebben een C API waarop
eventuele andere language bindings ge�mplementeerd zijn.  C is een heerlijk
eenvoudige taal waar je alles mee kunt doen.

> Belangrijk is dat de taal een grote `user base' heeft (veel gebruikers ->
> veel support op nieuwsgroepen), en dat de taal niet `aan het uitsterven' is.

Regel #1: don't believe in hype.

 - Philip

-- 
Philip Paeps                              Please don't email any replies
philip@paeps.cx                               I follow the newsgroup.

  BOFH Excuse #118:
    the router thinks its a printer.

Philip Paeps <philip+usenet@paeps.cx> wrote:

> De meeste databeesten hebben een C API
> waarop eventuele andere language bindings ge�mplementeerd zijn.  C is
> een heerlijk eenvoudige taal waar je alles mee kunt doen.

Mensen die een programmeertaal simpel noemen beheersen meestal de taal 
zelfs niet in haar simpelste vorm.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

"Steven Spits" <nospam@company.com> wrote:

> Trouwens, als je C# kent ben je binnen een dag productief in Java en 
> andersom.

Bullshit. Als je dat schrijft ken je noch C# niet, noch Java. Ik ken Java, 
en heb naar C# gekeken, en er zijn diverse dingen anders. En dan heb ik 
het niet eens over de andere opzet van libraries. Hello, world lukt wel, 
maar dat noem ik niet produktief.

Een voorzichtige schatting, switchen van de ene taal naar de andere (C# 
<-> Java), en er daadwerkelijk produktief in zijn (dus niet het aantal 
knopjes dat per minuut ingedrukt worden) zal zeker 1 jaar kosten.

> Alleen zijn vele dingen IMHO vaak beter ge�mplementeerd in
> .NET dan in Java (generics, asp vs jsp, remoting vs RMI).

Yup, dat komt omdat MS goed naar Java heeft gekeken, zeker naar de 
knelpunten.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Philip Paeps <philip+usenet@paeps.cx> wrote:

> Ik geloof niet in IDEs. ;-)

Ook al niet :-D Ik geloof wel heel sterk in losse tools, die te integreren 
zijn, zoals een eenvoudige editor (Textpad) en Subversion [1], Ant, enz.

Eclipse heb ik een paar keer bekeken, en ik blijf het een draak vinden.

> Het is mogelijk om in C hetzelfde te doen als in .NET of Java (of
> whatever), het is gewoon moeilijker (en vaak ook idioot).  Het is
> echter niet mogelijk om in .NET of Java (of whatever) hetzelfde te
> doen als in C.  Vertrouwde "IDE" of niet.

Maar in dat geval kan je het laatste stukje vaak in C schrijven.

>> Trouwens, als je C# kent ben je binnen een dag productief in Java en
>> andersom. Alleen zijn vele dingen IMHO vaak beter ge�mplementeerd in
>> .NET dan in Java (generics, asp vs jsp, remoting vs RMI).
> 
> Daar kan ongetwijfeld zwaar over gediscussieerd worden door mensen in
> beide kampen.  Mij lijkt het eerder onwaarschijnlijk.  Je kan na een
> dag misschien de syntax onder de knie hebben, maar onmogelijk de
> "idioms".

Zelfs de syntax gaat niet lukken in 1 dag. Er zijn voldoende subtiele 
verschillen. Alleen al de C# kretologie onder de knie krijgen kost al een 
dag.

> Iemand die jaren C schrijft kan ook perfect werkende C++ schrijven. 
> In dat opzicht is hij misschien productief na een dag.  Uit het
> perspectief van een ervaren C++ developer zal de code echter nergens
> op lijken.

Yup, alweer eens ;-)


[1] http://johnbokma.com/textpad/textpad-subversion.html

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Philip Paeps <philip+usenet@paeps.cx> wrote:

> Steven Spits <nospam@company.com> wrote:
>> Philip Paeps schreef:
>> > Omdat de wereld meer is dan *DBC en sommige mensen zich de overhead
>> > van zulke abstractie niet kunnen veroorloven of er gewoon geen
>> > behoefte aan hebben en liever hun queries rechtstreeks in memory
>> > aan de database engine geven.
>>
>> Maw, je applicatie hangt muurvast aan die database. Van database
>> veranderen om ��n of andere reden (failliet, performance,
>> mogelijkheden) is onmogelijk of vergt veel werk. Nee, bedankt.
> 
> Het leuke aan Open Source gebruiken, is dat "failliet" onmogelijk is
> en dat "performance" en "mogelijkheden" met eigen resources op te
> lossen zijn. ;-) 

Met als leuk resultaat dat het bedrijf failliet kan zijn voor het af is. 

Een mythe van Open Source is dat iedereen er ook echt mee aan de slag kan. 
Eventjes een OS programma reverse engineeren (noem 1 OS project met goede 
documentatie op source nivo, ontwerpbeslissingen gedocumenteerd, etc), 
aanpassen, debuggen enz. kan nogal wat manmaanden kosten. En tja, die 
kosten kunnen ver boven de beschikbare resources uitstijgen, en dan doet 
het er bitter toe dat het OS is voor dat bedrijf.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

"Steven Spits" <nospam@company.com> wrote:

> Maar wat me opvalt : plots hebben we het over Open Source, IPC,
> embedded systems, etc...,

Dat is vrij gebruikelijk op Usenet.

> ver buiten de vraag van de OP.

Die vraag lijkt mij inmiddels meer dan beantwoord.

> Wel op het
> juiste pad blijven h�? Als het doel van je postings is om je gelijk te
> halen, wil ik je dat geenzins ontnemen: je hebt gelijk Philip.

Maar als Philip geen gelijk hebt, dan heb jij het toch?

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

John Bokma <john@castleamber.com> wrote:
> Philip Paeps <philip+usenet@paeps.cx> wrote:
> > Steven Spits <nospam@company.com> wrote:
> > > Philip Paeps schreef:
> > > > Omdat de wereld meer is dan *DBC en sommige mensen zich de overhead
> > > > van zulke abstractie niet kunnen veroorloven of er gewoon geen
> > > > behoefte aan hebben en liever hun queries rechtstreeks in memory aan
> > > > de database engine geven.
> > >
> > > Maw, je applicatie hangt muurvast aan die database. Van database
> > > veranderen om ��n of andere reden (failliet, performance, mogelijkheden)
> > > is onmogelijk of vergt veel werk. Nee, bedankt.
> > 
> > Het leuke aan Open Source gebruiken, is dat "failliet" onmogelijk is en
> > dat "performance" en "mogelijkheden" met eigen resources op te lossen
> > zijn. ;-) 
>
> Met als leuk resultaat dat het bedrijf failliet kan zijn voor het af is. 

Dat heet "resource management" :-)

> Een mythe van Open Source is dat iedereen er ook echt mee aan de slag kan.

Dat is geen mythe maar een feit.  De mythe is dat het een silver bullet zou
zijn, wat het dus niet is.  Het voordeel is dat eens je er mee aan de slag
bent, je veel effici�nter knelpunten kunt oplossen dan met proprietaire
software.

> Eventjes een OS programma reverse engineeren (noem 1 OS project met goede
> documentatie op source nivo, ontwerpbeslissingen gedocumenteerd, etc),
> aanpassen, debuggen enz. kan nogal wat manmaanden kosten.

Klassieke voorbeelden zijn de BSD kernels en de Linux kernel.  Er zijn boeken
over geschreven die de lezer van naaldje tot draadje uitleggen hoe het geheel
in elkaar past.  Ik denk aan de "Design and Implementation" boeken en aan
"Understanding the Linux Kernel".

Met een beetje ervaring met kernel werk, kan een blocking bug of ontbrekende
feature in dergelijke kernels snel opgelost worden.  Als je op de vendor van
een proprietair systeem moet wachten, ben je al snel een aantal maanden of
jaren verder.

> En tja, die kosten kunnen ver boven de beschikbare resources uitstijgen, en
> dan doet het er bitter toe dat het OS is voor dat bedrijf.

Als bedrijf zet je natuurlijk geen "newbie" als leerling tovenaar op een
project, maar iemand die weet waar hij mee bezig is...  Een goede developer is
niet goedkoop, maar spaart wel tijd en kosten uit op langere termijn.

 - Philip

-- 
Philip Paeps                              Please don't email any replies
philip@paeps.cx                               I follow the newsgroup.

  Real programmers are kind to rookies.

> Twee talen die mij te binnen schieten:
> 
> - Java
> - C#

C++ met grafische toolkit (bijv. qt; open source versie werkt 
tegenwoordig met mingw onder windows)

Python? (met tkinter, pyqt, wxpython)

Ruby?

Java in combinatie met AndroMDA?

...

Philip Paeps <philip+usenet@paeps.cx> wrote:

> John Bokma <john@castleamber.com> wrote:
>> Philip Paeps <philip+usenet@paeps.cx> wrote:

[ .. ]

>> Met als leuk resultaat dat het bedrijf failliet kan zijn voor het af
>> is. 
> 
> Dat heet "resource management" :-)

Als de resources er niet zijn, kan je ze ook niet managen. Ik lever 
regelmatig lijmoplossingen. Soms tussen CS en OSS, soms tussen OSS en 
OSS en soms tussen CS en CS. Ik heb nog niet kunnen ontdekken dat het 
een goedkoper is dan het ander.

>> Een mythe van Open Source is dat iedereen er ook echt mee aan de slag
>> kan. 
> 
> Dat is geen mythe maar een feit.

Dan heb je nog nooit serieus naar de source van een gemiddeld OS project 
gekeken.

> De mythe is dat het een silver
> bullet zou zijn, wat het dus niet is.  Het voordeel is dat eens je er
> mee aan de slag bent, je veel effici�nter knelpunten kunt oplossen dan
> met proprietaire software.

Misschien moet je voor de grap eens naar het history bestand van Firefox 
kijken... Of wellicht gewoon eens een willekeurig OSS project op source 
nivo doorwerken. Als er bakken met geld zijn, dan is het inderdaad geen 
probleem, maar dan is het vaak ook geen probleem om eventjes een aan de 
telefoon te hangen met de makers van het CS project.

>> Eventjes een OS programma reverse engineeren (noem 1 OS project met
>> goede documentatie op source nivo, ontwerpbeslissingen
>> gedocumenteerd, etc), aanpassen, debuggen enz. kan nogal wat
>> manmaanden kosten. 
> 
> Klassieke voorbeelden zijn de BSD kernels en de Linux kernel.  Er zijn
> boeken over geschreven die de lezer van naaldje tot draadje uitleggen
> hoe het geheel in elkaar past.  Ik denk aan de "Design and
> Implementation" boeken en aan "Understanding the Linux Kernel".
> 
> Met een beetje ervaring met kernel werk, kan een blocking bug of
> ontbrekende feature in dergelijke kernels snel opgelost worden.  Als
> je op de vendor van een proprietair systeem moet wachten, ben je al
> snel een aantal maanden of jaren verder.

Het hangt simpel weg af van de kosten. De ene keer kan het schuiven van 
een zak geld naar een CS bedrijf het toevoegen van een feature 
bespoedigen, en veel goedkoper zijn dan het vinden van een programmeur 
die ff een OS project induikt. Iemand met ervaring met kernel werk moet 
je maar kunnen vinden. Ik gok/vrees dat het meestal neerkomt op het 
huren van iemand die C kan programmeren, en de kernel wel ff in wilt 
duiken.

Mijn ervaring (jaren :-) ) is dat ik bijna altijd ingehuurd wordt om 
mijn programmeerkennis, en niet om de kennis met een bepaald systeem. En 
dat komt vaak neer dat ik "eventjes" mijzelf ergens in moet verdiepen. 
De ene keer is dat een API van een stukje CS, de andere keer is dat OSS. 

Wat mij erg opvalt, gemeten over 10+ jaar, is dat een API voor CS keurig 
gedocumenteerd is, dat er met een telefoontje of email vaak binnen een 
uur een reaktie binnenkomt op een support vraag, en zelfs voorstellen 
voor verbeteringen extreem snel doorgevoerd werden. 

Met OSS is mijn ervaring dat de documentatie soms 1 jaar (en soms nog 
meer) achter loopt op de werkelijkheid (ik vrees dat dat met de door 
jouw genoemde kernel boeken helaas ook het geval is, soms valt daar mee 
te leven, soms niet). Dat een vage foutmelding in Google stoppen soms 
een fix opleverd, en soms tig meldingen van mensen met hetzelfde 
probleem. Dat support soms ver te zoeken is (ja, eh, niet zeuren he, tis 
wel allemaal gratiz), niet meer werkende email adressen, maintainers die 
het al 5 keer naar anderen doorgeschoven hebben, enz. En als je dan al 
een verbetering durft voor te stellen mag je hopen dat je niet tegen een 
betonblok opbotst waar een ego achter schuil gaat waar ik bang van word.

Natuurlijk zijn er ook gevallen dat het prima werkt, dat OSS, en dat ik 
er probleemloos doorheen rol. Maar als ik ff snel over 10 jaar heen 
kijk, vrees ik dat ik meer tijd gestoken heb in al dat OSS gekloot 
versus al dat enge, vendor locked in CS.

>> En tja, die kosten kunnen ver boven de beschikbare resources
>> uitstijgen, en dan doet het er bitter toe dat het OS is voor dat
>> bedrijf. 
> 
> Als bedrijf zet je natuurlijk geen "newbie" als leerling tovenaar op
> een project, maar iemand die weet waar hij mee bezig is...

Ik doe nogal eens werk voor bedrijven met 4-5 man. Daar is geen geld en 
ruimte voor een leerling tovenaar. Niet eens voor een leerling 
programmeur. 

> Een goede
> developer is niet goedkoop, maar spaart wel tijd en kosten uit op
> langere termijn. 

Als er geld is om te investeren, uiteraard. Maar ik zie regelmatig 
bedrijven die een idee hebben, en denken dat het met OSS goedkoop te 
realiseren is (kost geen drol, geen licentie kosten, patches en de hele 
she-bang gratiz, gratiz). Om er vervolgens achter te komen dat een 
leerling tovenaar, de dagelijkse geit die geofferd moet worden, en 1x 
per maand een schone maagd, toch meer geld kost dan gewoon je ziel 
verkopen aan Microsoft of een andere CS toko.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Johan Vervloet <johan@linux.be> wrote:

>> Twee talen die mij te binnen schieten:
>> 
>> - Java
>> - C#
> 
> C++ met grafische toolkit (bijv. qt; open source versie werkt 
> tegenwoordig met mingw onder windows)
> 
> Python? (met tkinter, pyqt, wxpython)

Ik heb zelf wxperl gebruikt, en brrrr. Het ziet er niet uit, en de API is 
rete slecht gedocumenteerd (of ik zat op een foute pagina) en in mijn ogen 
een bende (maar dat kan de combinatie van de paginas die ik zag, plus mijn 
ogen geweest zijn).

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

On 2006-03-01, Johan Vervloet <johan@linux.be> wrote:
>
>> Welk OS?
>
> Uiteindelijk zal het zeker onder Windows moeten draaien, maar 
> multi-platform is zeker niet verboden :)

Al eens een kijkje genomen tussen de tools op
http://osswin.sourceforge.net/#programming ?  Staat vast en zeker
interessant materiaal tussen...

Groeten,
Bart

-- 
	"Share what you know.  Learn what you don't."

"John Bokma" schreef:

>> Trouwens, als je C# kent ben je binnen een dag productief in Java en
>> andersom.
>
> Bullshit. Als je dat schrijft ken je noch C# niet, noch Java. Ik ken Java,
> en heb naar C# gekeken, en er zijn diverse dingen anders. En dan heb ik
> het niet eens over de andere opzet van libraries. Hello, world lukt wel,
> maar dat noem ik niet produktief.

Ik schreef dan ook "productief" en niet "guru". Na 5 jaar C# had ik weinig 
problemen om iets in Java te maken. Alleen wegwijs geraken in het framework, 
pardon libraries, vergt wat tijd (zoals je zelf al stelde).

Welke dingen zijn dan �cht anders?

>> Alleen zijn vele dingen IMHO vaak beter ge�mplementeerd in
>> .NET dan in Java (generics, asp vs jsp, remoting vs RMI).
>
> Yup, dat komt omdat MS goed naar Java heeft gekeken, zeker naar de
> knelpunten.

Hierin heb je 100% gelijk. Ze hebben de goede dingen schaamteloos 
overgenomen en de slechte verbererd. Ja, het inhuren van Anders Hejlsberg 
heeft Mircrosoft geen windeieren gelegd. C# is mi dan ook een taal geworden 
om u tegen te zeggen.

Hejlsberg is nu bezig met C# 3.0, waarvan LINQ ��n van de nieuwigheden is. 
Moet je zeker eens intypen op google.

Steven

- - -

"John Bokma" schreef:

>> Wel op het juiste pad blijven h�? Als het doel van
>> je postings is om je gelijk te halen, wil ik je dat
>> geenzins ontnemen: je hebt gelijk Philip.
>
> Maar als Philip geen gelijk hebt, dan heb jij het toch?

Nee hoor, de wereld is grijs.

Steven

- - -

"Steven Spits" <someone@company.com> wrote:

> "John Bokma" schreef:
> 
>>> Trouwens, als je C# kent ben je binnen een dag productief in Java en
>>> andersom.
>>
>> Bullshit. Als je dat schrijft ken je noch C# niet, noch Java. Ik ken
>> Java, en heb naar C# gekeken, en er zijn diverse dingen anders. En
>> dan heb ik het niet eens over de andere opzet van libraries. Hello,
>> world lukt wel, maar dat noem ik niet produktief.
> 
> Ik schreef dan ook "productief" en niet "guru".

Ik noem knopjes indrukken niet productief. Productief is voor mij source 
opleveren die door een Java guru te lezen is, zonder het C# manual door 
te moeten spitten. En nee, dat lukt niet in 1 dag, en wellicht niet in 
een maand of 2-3.

> Na 5 jaar C# had ik
> weinig problemen om iets in Java te maken. Alleen wegwijs geraken in
> het framework, pardon libraries, vergt wat tijd (zoals je zelf al
> stelde). 
> 
> Welke dingen zijn dan �cht anders?

Als je wegwijs bent in zowel Java als C# moet je die vraag zelf kunnen 
beantwoorden. Ik kon na 1 dag "Hello, World" in C# maken, maar wil dat 
zeer zeker niet produktief noemen.

>>> Alleen zijn vele dingen IMHO vaak beter ge�mplementeerd in
>>> .NET dan in Java (generics, asp vs jsp, remoting vs RMI).
>>
>> Yup, dat komt omdat MS goed naar Java heeft gekeken, zeker naar de
>> knelpunten.
> 
> Hierin heb je 100% gelijk. Ze hebben de goede dingen schaamteloos 
> overgenomen en de slechte verbererd.

Hoezo schaamteloos? Java was in mijn ogen ooit een poging om alles wat 
in C++ er lastig uit zag er uit te slopen. Inmiddels is men daar 
(gelukkig) voor een deel van terug gekomen. 

> Ja, het inhuren van Anders
> Hejlsberg heeft Mircrosoft geen windeieren gelegd. C# is mi dan ook
> een taal geworden om u tegen te zeggen.
> 
> Hejlsberg is nu bezig met C# 3.0, waarvan LINQ ��n van de nieuwigheden
> is. Moet je zeker eens intypen op google.

Ik volg C# een beetje, en LINQ is voor mij dus geen nieuws :-D Maar voor 
de andere lezers, aanrader. Als Perl programmeur ken ik natuurlijk tie, 
waarmee je een variabele stiekem aan een database kan knopen. 
Bijvoorbeeld een hash table, dus echt schokkend was het niet.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

"Steven Spits" <someone@company.com> wrote:

> "John Bokma" schreef:
> 
>>> Wel op het juiste pad blijven h�? Als het doel van
>>> je postings is om je gelijk te halen, wil ik je dat
>>> geenzins ontnemen: je hebt gelijk Philip.
>>
>> Maar als Philip geen gelijk hebt, dan heb jij het toch?
> 
> Nee hoor, de wereld is grijs.

Niet op Usenet ;-)

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Steven Spits wrote:
> Alleen zijn vele dingen IMHO vaak beter ge�mplementeerd in .NET 
> dan in Java (generics, asp vs jsp, remoting vs RMI).

Hoe kom je daarbij?  Java generics <-> .net generics, remoting <-> Jini, 
... (asp en jsp heb ik geen ervaring mee)

En studies wijzen uit dat de performance van beiden vergelijkbaar zijn.

Het lijkt dus veel meer aan de smaak van de programmeur te liggen dan 
aan de technische kant van de zaken lijkt me.

"wem" schreef:

>> Alleen zijn vele dingen IMHO vaak beter ge�mplementeerd in .NET dan in 
>> Java (generics, asp vs jsp, remoting vs RMI).
>
> Hoe kom je daarbij?  Java generics <-> .net generics, remoting <-> Jini, 
> ... (asp en jsp heb ik geen ervaring mee)

Nee, ze zijn lang niet zo vergelijkbaar als jij denk. Wat me ze direct te 
binnen schiet :

Generics: Voor Java zijn generics een compile-time ding. .NET gaat een stap 
verder waardoor .NET generics �cht typed zijn in het geheugen (in 
tegenstelling tot Java generics die geboxed worden naar objects). In .NET 
hoef je dus niet te casten. Het heeft echter nog minder voor de hand liggend 
(maar h��l belangrijk) voordeel : in .NET kan je met reflection je generics 
gebruiken, iets wat in Java onmogelijk is.

Remoting: RMI gaat over TCP, Remoting gaat over TCP of HTTP (handig voor 
firewalls). Tunneling is mogelijk, maar zorgt voor de nodige valkuilen. 
Configuratie van Remoting gebeurt met XML-files.

ASP.NET en JSP zijn gewoon te verschillend. Iedereen die �cht met ASP.NET 
gewerkt heeft zal toegeven dat deze technologie gewoon lichtjaren verder 
staat.

Ik ben niet altijd een fan van Microsoft, maar met .NET hebben ze enorm goed 
werk geleverd.

> En studies wijzen uit dat de performance van beiden vergelijkbaar zijn.

Achja, afhankelijk van wie de tests doet natuurlijk...

> Het lijkt dus veel meer aan de smaak van de programmeur te liggen dan aan 
> de technische kant van de zaken lijkt me.

Voor een stuk wel natuurlijk...

Steven

- - -

"Johan Vervloet" <johan@linux.be> schreef in bericht 
news:NClNf.287769$YA1.9144381@phobos.telenet-ops.be...
> Dag allemaal,
>
> Een heel eenvoudige vraag:
>
> welke programmeertalen zijn er ter beschikking om een 
> gui-database-applicatie te programmeren? In eerste instantie geen web-app, 
> maar in de toekomst zou dat er wel van kunnen komen.
>
> Belangrijk is dat de taal een grote `user base' heeft (veel gebruikers -> 
> veel support op nieuwsgroepen), en dat de taal niet `aan het uitsterven' 
> is.
>
> Ik vraag bewust niet naar `de beste' taal, omdat zoiets naar alle 
> waarschijnlijkheid niet bestaat.  Maar ik ben een overzicht aan het maken 
> van beschikbare talen, zodat ik daaruit mijn keuze ga kunnen maken.
>
> Bedankt,
> Johan

PHP in combinatie met MySQL (je databank) en Apache. Kun je op je pc 
draaien, op intranet en internet.
Massa's info en kant en klare coding te vinden op het web.


Pugi! 

"Pugi!" <reply@group.be> schreef in bericht 
news:3IednSv2YYxWhpXZRVnyug@scarlet.biz...
>
> "Johan Vervloet" <johan@linux.be> schreef in bericht 
> news:NClNf.287769$YA1.9144381@phobos.telenet-ops.be...
>> Dag allemaal,
>>
>> Een heel eenvoudige vraag:
>>
>> welke programmeertalen zijn er ter beschikking om een 
>> gui-database-applicatie te programmeren? In eerste instantie geen 
>> web-app, maar in de toekomst zou dat er wel van kunnen komen.
>>
>> Belangrijk is dat de taal een grote `user base' heeft (veel gebruikers -> 
>> veel support op nieuwsgroepen), en dat de taal niet `aan het uitsterven' 
>> is.
>>
>> Ik vraag bewust niet naar `de beste' taal, omdat zoiets naar alle 
>> waarschijnlijkheid niet bestaat.  Maar ik ben een overzicht aan het maken 
>> van beschikbare talen, zodat ik daaruit mijn keuze ga kunnen maken.
>>
>> Bedankt,
>> Johan
>
> PHP in combinatie met MySQL (je databank) en Apache. Kun je op je pc 
> draaien, op intranet en internet.
> Massa's info en kant en klare coding te vinden op het web.
>
>
> Pugi!
>

Je had ook niet vermeld of het voor priv� doeleinden , vereniging, kmo'ke of 
groot bedrijf is.
En in geval van bedrijf welke software je nu gebruikt oa voor database.
In de eerste drie gevallen : PHP, MySQL en Apache is gratis.
Je kunt XAMPP (www.apachefriends.org) downloaden en geen zorgen over 
installatie of settings. Webhosts op met PHP, Apache, MySQL zijn ook stuk 
goedkoper dan op basis van .NET.

Pugi! 

Steven Spits wrote:
> Remoting: RMI gaat over TCP

Tenzij je zelf je Socket-klasse schrijft, dan kan je het over eender wat 
laten gaan (UDP, TCP, SSL, ...) (echt niet zoveel werk als ik m'n prof 
mag geloven).

> 
>>En studies wijzen uit dat de performance van beiden vergelijkbaar zijn.
> 

Ik baseer me vooral op studies van UA, dus volledig onafhankelijk.  Wat 
van de twee het minste resources gebruikte was vooral afhankelijk van 
het aantal basistypes dat je gebruikte, was de conclusie als ik me niet 
vergis.

Pugi! wrote:
> Je had ook niet vermeld of het voor priv� doeleinden , vereniging, kmo'ke of 
> groot bedrijf is.
> En in geval van bedrijf welke software je nu gebruikt oa voor database.
> In de eerste drie gevallen : PHP, MySQL en Apache is gratis.

Vergeet dan ook niet te vermelden dat MySQL niet altijd gratis is, maar 
ook een commerci�le licentie heeft.

Verder: PHP is voor mij nog altijd een scripting-taal, geen 
programmeertaal.

Hey Wim,

> Ik baseer me vooral op studies van UA, dus volledig onafhankelijk.

Mwa, Java is altijd al (terecht) het troetelkindje van de academische wereld 
geweest...

> Wat  van de twee het minste resources gebruikte was vooral
> afhankelijk van het aantal basistypes dat je gebruikte, was de
> conclusie als ik me niet vergis.

Tsss, en om tot die conslusie te komen worden studies uitgevoerd?

Steven

- - -

wem <wim.robijn@telenet.be> wrote:

> Verder: PHP is voor mij nog altijd een scripting-taal, geen 
> programmeertaal.

Heerlijk! 

Kan je het verschil precies uitleggen?

Ik wacht met spanning af :-D.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

John Bokma wrote:
> wem <wim.robijn@telenet.be> wrote:
> 
> 
>>Verder: PHP is voor mij nog altijd een scripting-taal, geen 
>>programmeertaal.
> 
> 
> Heerlijk! 
> 
> Kan je het verschil precies uitleggen?
> 
> Ik wacht met spanning af :-D.
> 

Precies het verschil uitleggen?  Ik denk niet dat iemand dat kan.
Het zijn volgens mij termen die niet door iedereen op dezelfde manier 
ge�nterpreteerd worden.
Bij het "indelen" van een taal zal ik persoonlijk kijken naar de 
levenscyclus van de source (compilatie, interpretatie nodig?), of de 
taal gebruik maakt van externe libraries of eerder van externe 
programma's, de mogelijkheden om de hardware te gebruiken, ...

Een groot grijs vlak dus, en niets zwart-wit.

wem <wim.robijn@telenet.be> wrote:

> John Bokma wrote:
>> wem <wim.robijn@telenet.be> wrote:
>> 
>> 
>>>Verder: PHP is voor mij nog altijd een scripting-taal, geen 
>>>programmeertaal.
>> 
>> 
>> Heerlijk! 
>> 
>> Kan je het verschil precies uitleggen?
>> 
>> Ik wacht met spanning af :-D.
>> 
> 
> Precies het verschil uitleggen?  Ik denk niet dat iemand dat kan.
> Het zijn volgens mij termen die niet door iedereen op dezelfde manier 
> ge�nterpreteerd worden.
> Bij het "indelen" van een taal zal ik persoonlijk kijken naar de 
> levenscyclus van de source (compilatie, interpretatie nodig?),

Leuk voorbeeldje: Perl compileerd naar een interne representatie, en 
interpreteerd die. Tishetnu?

> of de 
> taal gebruik maakt van externe libraries of eerder van externe 
> programma's, de mogelijkheden om de hardware te gebruiken, ...
> 
> Een groot grijs vlak dus, en niets zwart-wit.

Ok, maar waarom denk je dat je niet kan programmeren in PHP (Ik bedoel, je 
noemt het geen programmeertaal, maar een scripting-taal).

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

John Bokma wrote:
> Leuk voorbeeldje: Perl compileerd naar een interne representatie, en 
> interpreteerd die. Tishetnu?

  Ik ken perl enkel van naam, dus geen idee ;-)

> 
> Ok, maar waarom denk je dat je niet kan programmeren in PHP (Ik bedoel, je 
> noemt het geen programmeertaal, maar een scripting-taal).
> 

dan hangt het weer af van de gebruikte definitie van "programmeren". 
Ruw gezegd is dat voor mij het schrijven van broncode.  En dus valt 
PHP-files schrijven er ook onder.

Maar ik heb het gevoel dat deze discussie gewoon aan het afstevenen is 
op een conlusie: we gebruiken verschillende betekenissen achter de 
gebruikte termen.

Maar ik blijft het gevoel hebben dat PHP als taal kiezen voor een 
programma (in strikte zin, dus geen website) te maken, geen goede keuze 
is.  (als het al mogelijk is)

"wem" <wim.robijn@telenet.be> schreef in bericht 
news:cZlOf.294694$IC1.9166903@phobos.telenet-ops.be...
> John Bokma wrote:
>> Leuk voorbeeldje: Perl compileerd naar een interne representatie, en 
>> interpreteerd die. Tishetnu?
>
>  Ik ken perl enkel van naam, dus geen idee ;-)
>
>>
>> Ok, maar waarom denk je dat je niet kan programmeren in PHP (Ik bedoel, 
>> je noemt het geen programmeertaal, maar een scripting-taal).
>>
>
> dan hangt het weer af van de gebruikte definitie van "programmeren". Ruw 
> gezegd is dat voor mij het schrijven van broncode.  En dus valt PHP-files 
> schrijven er ook onder.
>
> Maar ik heb het gevoel dat deze discussie gewoon aan het afstevenen is op 
> een conlusie: we gebruiken verschillende betekenissen achter de gebruikte 
> termen.
>
> Maar ik blijft het gevoel hebben dat PHP als taal kiezen voor een 
> programma (in strikte zin, dus geen website) te maken, geen goede keuze 
> is.  (als het al mogelijk is)

Moet de originele poster wat meer uitleg geven. Als het niet veel mag kosten 
is PHP, MySQL en Apache ideaal. Verplaats het van je PC naar je intranet en 
naar het internet, mits wat aanpassingen. Als je met .NET wilt werken of 
Delphi of JAVA ben je al geld kwijt nog voor je iets van coding hebt.

Pugi!

wem <wim.robijn@telenet.be> wrote:

> John Bokma wrote:
>> Leuk voorbeeldje: Perl compileerd naar een interne representatie, en 
>> interpreteerd die. Tishetnu?
> 
>   Ik ken perl enkel van naam, dus geen idee ;-)

Maar wat zegt je gevoel?

>> Ok, maar waarom denk je dat je niet kan programmeren in PHP (Ik
>> bedoel, je noemt het geen programmeertaal, maar een scripting-taal).
>> 
> 
> dan hangt het weer af van de gebruikte definitie van "programmeren".
> Ruw gezegd is dat voor mij het schrijven van broncode.  En dus valt 
> PHP-files schrijven er ook onder.

En dan zou PHP een programmeertaal zijn. Ik noem b.v. het maken van HTML 
pagina's geen programmeren omdat ik HTML geen programmeertaal vind.

> Maar ik heb het gevoel dat deze discussie gewoon aan het afstevenen is
> op een conlusie: we gebruiken verschillende betekenissen achter de 
> gebruikte termen.

Daar is niets mis mee, als je die betekenissen kan toelichten, en ik ben 
nieuwsgierig naar waarom PHP geen programmeeertaal is, en waarom een 
scripttaal geen programmeertaal is.

> Maar ik blijft het gevoel hebben dat PHP als taal kiezen voor een 
> programma (in strikte zin, dus geen website) te maken, geen goede
> keuze is.  (als het al mogelijk is)

Waarom zou het niet mogelijk zijn?

    	- PHP kan aangeroepen worden vanaf de command line
    	- Je kan een GUI applicatie maken in PHP

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

"Pugi!" <reply@group.be> wrote:

> Moet de originele poster wat meer uitleg geven. Als het niet veel mag
> kosten is PHP, MySQL en Apache ideaal. Verplaats het van je PC naar je
> intranet en naar het internet, mits wat aanpassingen. Als je met .NET
> wilt werken of Delphi of JAVA ben je al geld kwijt nog voor je iets
> van coding hebt. 

Geld aan wat? Als je een groot project in PHP wilt doen, vrees ik dat je 
nogal wat bakken tijd kwijt bent. Als je dan een complete 
ontwikkelomgeving voor .NET daar tegen over zet [1], *bespaar* je bakken 
met geld (tenzij jouw tijd gratis is).

Daarnaast, zelfs met AJAX in de mix is een lekkere GUI ervaring nogal een 
klus.

[1] Ipv de gratis dingen downloaden en een gratis IDE.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

John Bokma wrote:
> Maar wat zegt je gevoel?

niets, want ik ken de taal niet ;-)

> Ik noem b.v. het maken van HTML 
> pagina's geen programmeren omdat ik HTML geen programmeertaal vind.

daarom dat er "ruw" bij stond, omdat ik ook HTML in het achterhoofd had, 
waar ook bronbestanden voor geschreven worden, maar ik noem het ook niet 
programmeren.

> Daar is niets mis mee, als je die betekenissen kan toelichten, en ik ben 
> nieuwsgierig naar waarom PHP geen programmeeertaal is, en waarom een 
> scripttaal geen programmeertaal is.

Voor mij heeft een begrip/woord ook een gevoelswaarde, en dat valt niet 
altijd toe te lichten.
Ik heb altijd programmeer- en scripting-talen als twee verschillende 
verzamelingen gezien, mogelijks met een niet-lege doorsnede.
Maar je visie van scriptingtalen een deelverzameling van 
programmeertalen valt ook wat voor te zeggen moet ik toegeven.

> Waarom zou het niet mogelijk zijn?
> 
>     	- PHP kan aangeroepen worden vanaf de command line
>     	- Je kan een GUI applicatie maken in PHP

Ik wist niet of het mogelijk was, daarom die laatste opmerking erbij ;-)

"Steven Spits" <nospam@company.com> wrote in message
news:4407fdb1$0$437$6c56d894@reader0.news.be.easynet.net...
> "wem" schreef:
>
> Nee, ze zijn lang niet zo vergelijkbaar als jij denk. Wat me ze direct te
> binnen schiet :
>
> Generics: Voor Java zijn generics een compile-time ding. .NET gaat een
stap
> verder waardoor .NET generics �cht typed zijn in het geheugen (in
> tegenstelling tot Java generics die geboxed worden naar objects). In .NET
> hoef je dus niet te casten. Het heeft echter nog minder voor de hand
liggend
> (maar h��l belangrijk) voordeel : in .NET kan je met reflection je
generics
> gebruiken, iets wat in Java onmogelijk is.

Ik snap niet helemaal wat je bedoeld. Ik dacht dat het hele principe van
generics er net voor diende om een buch cast exceptions tijdens run time te
voorkomen?
Ik ben totaal niet op de hoogte van welke reflectie mogelijkhede .NET biedt.
Welke straffe stoot kan je via generics en reflectie doen?


gC

wem <wim.robijn@telenet.be> wrote:

> John Bokma wrote:
>> Maar wat zegt je gevoel?
> 
> niets, want ik ken de taal niet ;-)
> 
>> Ik noem b.v. het maken van HTML 
>> pagina's geen programmeren omdat ik HTML geen programmeertaal vind.
> 
> daarom dat er "ruw" bij stond, omdat ik ook HTML in het achterhoofd
> had, waar ook bronbestanden voor geschreven worden, maar ik noem het
> ook niet programmeren.

Ok, maar PHP is geen HTML :-D

>> Daar is niets mis mee, als je die betekenissen kan toelichten, en ik
>> ben nieuwsgierig naar waarom PHP geen programmeeertaal is, en waarom
>> een scripttaal geen programmeertaal is.
> 
> Voor mij heeft een begrip/woord ook een gevoelswaarde, en dat valt
> niet altijd toe te lichten.

Ja, daar was ik bang voor. Ik ken bosjes mensen die een groep 
programmeertalen om een of andere reden "scripttalen" noemen, en ze op 
de hoop "niet echt" gooien, vaak zonder echt te snappen waarom. Dat is 
en jammer omdat ze zichzelf te kort doen, maar ook extreem jammer omdat 
ze een soort mythe in stand houden.


> Ik heb altijd programmeer- en scripting-talen als twee verschillende 
> verzamelingen gezien, mogelijks met een niet-lege doorsnede.

Leuk om over verzamelingen en doorsnede te praten in de context van 
"gevoel" :-D

> Maar je visie van scriptingtalen een deelverzameling van 
> programmeertalen valt ook wat voor te zeggen moet ik toegeven.

Moet er eerst een goede definitie van scriptingtalen gevonden worden. En 
niet elke scripttaal een programmeertaal. Ik heb zelf script talen 
ontworpen, en je kon er niet in programmeren :-D

>> Waarom zou het niet mogelijk zijn?
>> 
>>          - PHP kan aangeroepen worden vanaf de command line
>>          - Je kan een GUI applicatie maken in PHP
> 
> Ik wist niet of het mogelijk was, daarom die laatste opmerking erbij
> ;-) 

:-D.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

"Pugi!" schreef:

> Als je met .NET wilt werken of Delphi of JAVA ben je al geld kwijt
> nog voor je iets van coding hebt.

De thread wel een beetje volgen h�?

Voor Delphi misschien wel, maar voor Java en .NET absoluut niet.

Steven

- - -

"wem" schreef:

>>     - Je kan een GUI applicatie maken in PHP
>
> Ik wist niet of het mogelijk was, daarom die laatste opmerking erbij ;-)

Ik eigenlijk ook niet.

Worden dan de widgets van Windows gebruikt? Of is het zo'n Java swing gedoe 
met een eigen GUI?

Steven

- - -

"Gerrit Cornelis" schreef:

> Ik snap niet helemaal wat je bedoeld. Ik dacht dat het hele principe van
> generics er net voor diende om een buch cast exceptions tijdens run time 
> te
> voorkomen?

Dat klopt, je zal inderdaad geen exceptions krijgen omdat het type tijden 
het compileren gecontroleerd wordt. MAAR achter de scherm gaat Java wel 
casten en .NET niet. En d�t is nu precies waarom ik vind dat generics in 
.NET beter geimplementeerd zijn tov Java.

> Ik ben totaal niet op de hoogte van welke reflectie mogelijkhede .NET 
> biedt.
> Welke straffe stoot kan je via generics en reflectie doen?

Bij mijn weten bestaat reflection ook in Java, maar ik heb geen idee hoe het 
daar heet? Ik dacht net hetzelfde?

Met reflection kan je een assembly (of hoe je het ook wil noemen) gaan 
ontleden tijdens runtime en kijken wat er allemaal inzit. Zo kan je in bv in 
runtime in klasse instanti�ren zonder je het type tijden het compileren 
kent. Zonder reflection is zoiets niet mogelijk, je zou immers tijden het 
compileren een fout krijgen.

Bij generics in Java zal reflection zeggen dat het objects zijn (want dat 
zijn het ook in Java!) terwijl je in .NET het echte type krijgt. Gevolg is 
dat je in .NET alle methods kan opvragen, ipv enkel .ToString().

Kweet niet of ik een beetje duidelijk ben?

Steven

- - -

"Steven Spits" <someone@company.com> wrote:

> "Pugi!" schreef:
> 
>> Als je met .NET wilt werken of Delphi of JAVA ben je al geld kwijt
>> nog voor je iets van coding hebt.
> 
> De thread wel een beetje volgen h�?
> 
> Voor Delphi misschien wel, maar voor Java en .NET absoluut niet.

Marco leest hier niet (vzviw), dus ik doe het maar ff:
<http://www.freepascal.org/>
<http://www.lazarus.freepascal.org/>
"Lazarus is the class libraries for Free Pascal that emulate Delphi. Free 
Pascal is a GPL'ed compiler that runs on Linux, Win32, OS/2, 68K and more. 
Free Pascal is designed to be able to understand and compile Delphi 
syntax, which is of course OOP. Lazarus is the part of the missing puzzle 
that will allow you to develop Delphi like programs in all of the above 
platforms."


-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

"Steven Spits" <someone@company.com> wrote:

> "wem" schreef:
> 
>>>     - Je kan een GUI applicatie maken in PHP
>>
>> Ik wist niet of het mogelijk was, daarom die laatste opmerking erbij
>> ;-) 
> 
> Ik eigenlijk ook niet.
> 
> Worden dan de widgets van Windows gebruikt? Of is het zo'n Java swing
> gedoe met een eigen GUI?

<http://gtk.php.net/>
"PHP-GTK is an extension for the PHP programming language that implements 
language bindings for GTK+. It provides an object-oriented interface to 
GTK+ classes and functions and greatly simplifies writing client-side 
cross-platform GUI applications."

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

"John Bokma" schreef:

>> Worden dan de widgets van Windows gebruikt? Of is het zo'n Java swing
>> gedoe met een eigen GUI?

> <http://gtk.php.net/>
> "PHP-GTK is an extension for the PHP programming language that implements
> language bindings for GTK+. It provides an object-oriented interface to
> GTK+ classes and functions and greatly simplifies writing client-side
> cross-platform GUI applications."

Interessant, maar ik vond niet direct een antwoord op m'n vraag. Zal morgen 
eens googelen, ik kruip nu in m'n warm bed...

Steven

- - -

"Steven Spits" <someone@company.com> wrote:

> "John Bokma" schreef:
> 
>>> Worden dan de widgets van Windows gebruikt? Of is het zo'n Java
>>> swing gedoe met een eigen GUI?
> 
>> <http://gtk.php.net/>
>> "PHP-GTK is an extension for the PHP programming language that
>> implements language bindings for GTK+. It provides an object-oriented
>> interface to GTK+ classes and functions and greatly simplifies
>> writing client-side cross-platform GUI applications."
> 
> Interessant, maar ik vond niet direct een antwoord op m'n vraag.

GTK wordt dus gebruikt. Ik gok dat het tussen Windows en Swing gedoe inzit 
:-D. Ken je Gaim?

> Zal
> morgen eens googelen, ik kruip nu in m'n warm bed...

:-) Heerlijk, kan ik slechts een paar dagen in het jaar, daarna is het een 
erg warm of te warm bed.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Op Thu, 02 Mar 2006 19:06:22 +0000, schreef John Bokma:

> Misschien moet je voor de grap eens naar het history bestand van Firefox 
> kijken...

Goed nieuws: dat formaat wordt vervangen tegen Firefox 2 (door SQLite,
dacht ik).


> Het hangt simpel weg af van de kosten. De ene keer kan het schuiven van
> een zak geld naar een CS bedrijf het toevoegen van een feature
> bespoedigen, en veel goedkoper zijn dan het vinden van een programmeur
> die ff een OS project induikt. Iemand met ervaring met kernel werk moet
> je maar kunnen vinden. Ik gok/vrees dat het meestal neerkomt op het
> huren van iemand die C kan programmeren, en de kernel wel ff in wilt
> duiken.

Philip heeft het voordeel dat hij zelf een "kernel hacker" is...   ;-)


> Met OSS is mijn ervaring dat de documentatie soms 1 jaar (en soms nog
> meer) achter loopt op de werkelijkheid

Dat hangt sterk van project tot project af, maar zo zijn er inderdaad veel
te veel...


-- 
JanC

Op Thu, 02 Mar 2006 08:14:04 +0000, schreef John Bokma:

> Maar Perl en Python gaan ooit op dezelfde VM draaien (Parrot) en dan 
> is het leuk om van beiden iets af te weten.

Het zou me verwonderen als Python ooit op Parrot zal draaien, behalve als
proof-of-concept (maar ik kan me vergissen).

Maar Perl en Python draaien, als je dat wil, nu al op dezelfde VM: op de
Java VM heb je Jython (na de offici�le "CPython" implementatie de
meest-gebruikte) en perljvm.


-- 
JanC

Jan Claeys <usenet@janc.invalid> wrote:

> Op Thu, 02 Mar 2006 19:06:22 +0000, schreef John Bokma:
> 
>> Misschien moet je voor de grap eens naar het history bestand van
>> Firefox kijken...
> 
> Goed nieuws: dat formaat wordt vervangen tegen Firefox 2 (door SQLite,
> dacht ik).

Yup, had ik ook ergens opgepikt.

>> kernel werk moet je maar kunnen vinden. Ik gok/vrees dat het meestal
>> neerkomt op het huren van iemand die C kan programmeren, en de kernel
>> wel ff in wilt duiken.
> 
> Philip heeft het voordeel dat hij zelf een "kernel hacker" is...   ;-)

Zelfs dan kan het de vraag zijn (binnen een bedrijf), zetten we onze man 
(of vrouw) er op, of huren we er 1 (of een handvol). Dingen die extreem 
duur kunnen zijn.

>> Met OSS is mijn ervaring dat de documentatie soms 1 jaar (en soms nog
>> meer) achter loopt op de werkelijkheid
> 
> Dat hangt sterk van project tot project af, maar zo zijn er inderdaad
> veel te veel...

Helaas. Ik had bij bepaalde projecten wel eens het idee om mijn steentje 
bij te dragen, maar ik heb helaas nog 10001 andere dingen te doen.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Jan Claeys <usenet@janc.invalid> wrote:

> Op Thu, 02 Mar 2006 08:14:04 +0000, schreef John Bokma:
> 
>> Maar Perl en Python gaan ooit op dezelfde VM draaien (Parrot) en dan 
>> is het leuk om van beiden iets af te weten.
> 
> Het zou me verwonderen als Python ooit op Parrot zal draaien, behalve
> als proof-of-concept (maar ik kan me vergissen).

Zelf hoop ik dat PHP ook mee gaat doen (vzviw zijn er mensen mee bezig),
en dat er per taal een front endje komt, en de mensen met vm kennis zich
gezamelijk op Parrot kunnen richten. En iets als mod_parrot zou een hele
berg dingen eenvoudiger maken. 

> Maar Perl en Python draaien, als je dat wil, nu al op dezelfde VM: op
> de Java VM heb je Jython (na de offici�le "CPython" implementatie de
> meest-gebruikte) en perljvm.

Parrot heeft, naar ik begreep, wat voordelen. De java VM is niet echt
gemaakt voor dit werk (vzviw, ik heb mij opervlakkig ooit een (te)
weinig er in verdiept). 

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Op Tue, 07 Mar 2006 19:39:15 +0000, schreef John Bokma:

> Jan Claeys <usenet@janc.invalid> wrote:
> 
>> Op Thu, 02 Mar 2006 19:06:22 +0000, schreef John Bokma:
> 
>>> kernel werk moet je maar kunnen vinden. Ik gok/vrees dat het meestal
>>> neerkomt op het huren van iemand die C kan programmeren, en de kernel
>>> wel ff in wilt duiken.
>> 
>> Philip heeft het voordeel dat hij zelf een "kernel hacker" is...   ;-)
> 
> Zelfs dan kan het de vraag zijn (binnen een bedrijf), zetten we onze man 
> (of vrouw) er op, of huren we er 1 (of een handvol). Dingen die extreem 
> duur kunnen zijn.

Tuurlijk, maar Philip wordt vziw (liefst) net voor dat soort jobs
ingehuurd.  De projecten waar hij mee te maken krijgt zullen dan ook wel
vaak van die aard zijn dat hij "low level" *moet* prutsen...   ;-)

In ieder geval, het _is_ mogelijk om dergelijke zaken op relatief korte
termijn te realiseren met linux/*bsd/etc., op voorwaarde dat je de prijs
ervoor wil betalen als firma.


>>> Met OSS is mijn ervaring dat de documentatie soms 1 jaar (en soms nog
>>> meer) achter loopt op de werkelijkheid
>> 
>> Dat hangt sterk van project tot project af, maar zo zijn er inderdaad
>> veel te veel...
> 
> Helaas. Ik had bij bepaalde projecten wel eens het idee om mijn steentje
> bij te dragen, maar ik heb helaas nog 10001 andere dingen te doen.

Begrijpelijk...

Al ken ik ook open source projecten waar de documentatie samen met de
code toegevoegd _moet_ worden.

-- 
JanC

Op Tue, 07 Mar 2006 19:42:34 +0000, schreef John Bokma:

> Jan Claeys <usenet@janc.invalid> wrote:
> 
>> Het zou me verwonderen als Python ooit op Parrot zal draaien, behalve
>> als proof-of-concept (maar ik kan me vergissen).
> 
> Zelf hoop ik dat PHP ook mee gaat doen (vzviw zijn er mensen mee bezig),
> en dat er per taal een front endje komt, en de mensen met vm kennis zich
> gezamelijk op Parrot kunnen richten. En iets als mod_parrot zou een hele
> berg dingen eenvoudiger maken. 

Ik vrees dat "parrot" een doodgeboren kind is...

>> Maar Perl en Python draaien, als je dat wil, nu al op dezelfde VM: op
>> de Java VM heb je Jython (na de offici�le "CPython" implementatie de
>> meest-gebruikte) en perljvm.
> 
> Parrot heeft, naar ik begreep, wat voordelen. De java VM is niet echt
> gemaakt voor dit werk (vzviw, ik heb mij opervlakkig ooit een (te)
> weinig er in verdiept).

Als er al een _veelgebruikte_ gemeenschappelijke VM voor Python en Perl
komt, zal dat vermoedelijk eerder .NET/Mono zijn; tenzij perl voor de JVM
plots populair wordt...

En "Python" werkt momenteel aan een universele "compiler" die in theorie
elke willekeurige backend kan gebruiken.  (PyPy zou uiteindelijk moeten
toelaten dat zelfs GCC e.d. een valabele backend voor python is...)


-- 
JanC

Jan Claeys <usenet@janc.invalid> wrote:

> Op Tue, 07 Mar 2006 19:42:34 +0000, schreef John Bokma:
> 
>> Jan Claeys <usenet@janc.invalid> wrote:
>> 
>>> Het zou me verwonderen als Python ooit op Parrot zal draaien,
>>> behalve als proof-of-concept (maar ik kan me vergissen).
>> 
>> Zelf hoop ik dat PHP ook mee gaat doen (vzviw zijn er mensen mee
>> bezig), en dat er per taal een front endje komt, en de mensen met vm
>> kennis zich gezamelijk op Parrot kunnen richten. En iets als
>> mod_parrot zou een hele berg dingen eenvoudiger maken. 
> 
> Ik vrees dat "parrot" een doodgeboren kind is...

Gebaseerd op wat?

>>> Maar Perl en Python draaien, als je dat wil, nu al op dezelfde VM:
>>> op de Java VM heb je Jython (na de offici�le "CPython" implementatie
>>> de meest-gebruikte) en perljvm.
>> 
>> Parrot heeft, naar ik begreep, wat voordelen. De java VM is niet echt
>> gemaakt voor dit werk (vzviw, ik heb mij opervlakkig ooit een (te)
>> weinig er in verdiept).
> 
> Als er al een _veelgebruikte_ gemeenschappelijke VM voor Python en
> Perl komt, zal dat vermoedelijk eerder .NET/Mono zijn;

Betwijfel ik. De Java VM is uitdrukkelijk niet gekozen, omdat zowel Perl
als Python dingen doen die daar niet makkelijk op gaan. Ik ben vrij
zeker dat dit ook voor .NET op gaat. 

ff de FAQ er bij gehaald:

"Those VMs are designed for statically typed languages. That's fine,
since Java, C#, and lots of other languages are statically typed. Perl
isn't. For a variety of reasons, it means that Perl would run more
slowly there than on an interpreter geared towards dynamic languages. 

The .NET VM didn't even exist when we started development, or at least
we didn't know about it when we were working on the design. We do now,
though it's still not suitable." <http://www.parrotcode.org/faq/>

> tenzij perl voor de JVM
> plots populair wordt...

Betwijfel ik.

> En "Python" werkt momenteel aan een universele "compiler" die in
> theorie elke willekeurige backend kan gebruiken.  (PyPy zou
> uiteindelijk moeten toelaten dat zelfs GCC e.d. een valabele backend
> voor python is...) 

Ik moet weer eens in Python duiken :-D.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Op Tue, 14 Mar 2006 23:30:59 +0000, schreef John Bokma:

> Jan Claeys <usenet@janc.invalid> wrote:
> 
>> Ik vrees dat "parrot" een doodgeboren kind is...
> 
> Gebaseerd op wat?

Ik bedoelde daarmee als cross-language VM, daarvoor is het te laat op de
markt. Als "standaard" VM voor Perl 6 zie ik het eventueel wel gebruikt
worden.


>> Als er al een _veelgebruikte_ gemeenschappelijke VM voor Python en
>> Perl komt, zal dat vermoedelijk eerder .NET/Mono zijn;
> 
> Betwijfel ik. De Java VM is uitdrukkelijk niet gekozen, omdat zowel Perl
> als Python dingen doen die daar niet makkelijk op gaan. Ik ben vrij
> zeker dat dit ook voor .NET op gaat. 
>
> ff de FAQ er bij gehaald:
> 
> "Those VMs are designed for statically typed languages. That's fine,
> since Java, C#, and lots of other languages are statically typed. Perl
> isn't. For a variety of reasons, it means that Perl would run more
> slowly there than on an interpreter geared towards dynamic languages. 
> 
> The .NET VM didn't even exist when we started development, or at least
> we didn't know about it when we were working on the design. We do now,
> though it's still not suitable." <http://www.parrotcode.org/faq/>

De voormalige projectleider van Jython (Python-on-Java, wordt ook
effectief gebruikt), Jim Hugunin, is enkele jaren geleden begonnen met
IronPython (Python-on-.NET) en Microsoft heeft hem vervolgens in dienst
genomen om daar verder aan te werken, maar ook om de .NET engine aan te
passen om die dynamische-taal-vriendelijk(er) te maken.  De resultaten
daarvan zitten deels al in .NET 2.0.

<http://www.ironpython.com/>


-- 
JanC

Op Fri, 17 Mar 2006 20:54:40 +0000, schreef Jan Claeys:

> <http://www.ironpython.com/>

Of, beter:
<http://blogs.msdn.com/hugunin/>
<http://msdn.microsoft.com/msdntv/transcripts/20051110PythonJHTranscript.aspx>
<http://www.gotdotnet.com/workspaces/workspace.aspx?id=ad7acff7-ab1e-4bcb-99c0-57ac5a3a9742>

-- 
JanC

Jan Claeys <usenet@janc.invalid> wrote:

> Op Tue, 14 Mar 2006 23:30:59 +0000, schreef John Bokma:
> 
>> Jan Claeys <usenet@janc.invalid> wrote:
>> 
>>> Ik vrees dat "parrot" een doodgeboren kind is...
>> 
>> Gebaseerd op wat?
> 
> Ik bedoelde daarmee als cross-language VM, daarvoor is het te laat op de
> markt.

Misschien, geen idee. Als ik mij goed herinner is er rekening gehouden met 
ondersteuning voor een aantal andere talen, en CPAN is wellicht erg 
aantrekkelijk voor die andere talen.  (Zelf hoop ik dat een klein team 
heel CPAN eens lekker onder handen neemt, en alles netjes structureerd en 
zo).

[ VM ]
> De voormalige projectleider van Jython (Python-on-Java, wordt ook
> effectief gebruikt), Jim Hugunin, is enkele jaren geleden begonnen met
> IronPython (Python-on-.NET) en Microsoft heeft hem vervolgens in dienst
> genomen om daar verder aan te werken, maar ook om de .NET engine aan te
> passen om die dynamische-taal-vriendelijk(er) te maken.  De resultaten
> daarvan zitten deels al in .NET 2.0.
> 
> <http://www.ironpython.com/>

Dank je, ga ik doorlezen. Je reply op je eigen bericht heb ik even 
gemarkeerd voor doorlezen, later ;-)

Als .NET Perl6 goed zou kunnen ondersteunen gaat daar zeker mijn voorkeur 
naar uit. Misschien een leuk project voor als ik mij ooit ga vervelen :-D. 

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

John Bokma wrote:
> Johan Vervloet <johan@linux.be> wrote:
>
>>> Twee talen die mij te binnen schieten:
>>>
>>> - Java
>>> - C#
>>
>> C++ met grafische toolkit (bijv. qt; open source versie werkt
>> tegenwoordig met mingw onder windows)
>>
>> Python? (met tkinter, pyqt, wxpython)
>
> Ik heb zelf wxperl gebruikt, en brrrr. Het ziet er niet uit, en de
> API is rete slecht gedocumenteerd (of ik zat op een foute pagina) en
> in mijn ogen een bende (maar dat kan de combinatie van de paginas die
> ik zag, plus mijn ogen geweest zijn).

Perl/TK met DBI dan ? =)
Je hebt tegenwoordig zelfs use Java::Swing in perl ^^

-- 
Dieter D'Hoker
#TriviaX - http://trivia.leuven.nu/