Responstijd testen in verschillende talen met zoekalgoritmen

[ToFast]

Het lijkt mij interessant om voor mijn Bachelor scriptie (Informatiekunde) te onderzoeken wat de verschillen in responstijd zijn tussen verscheidene programmeer/script talen. Er wordt getest op één grote tekstfile met veel Nederlandse zinnen,(al dan niet woorden per 1 regel) waar een specifiek woord in gezocht moeten worden (en eventueel geteld).

Als zoekalgoritmen kan ik bijvoorbeeld sequential-search, binary-search, b-trees en quicksort gebruiken. Wellicht dat de ene taal meer processor-tijd nodig heeft voor een bepaald algoritme dan de andere. Er zal tevens gekeken worden naar de worst- en bestcases, omdat ik ook benieuwd ben of de invloed hiervan nog respectievelijke verschillen(dat er verschil is per algoritme tussen worst/best case weten we wel) opleveren ten aanzien van de verschillende talen.

Ik kan al omgaan met JAVA, PERL en PHP. Van deze talen weet ik dat het uitvoerbaar is (qua niveau, de syntax, werken met bestanden en de zoekalgoritmen).

Nu vraag ik me af, voor welke andere programmeertalen denken jullie dat dit voor mij uitvoerbaar is. (C++, C#, Visual Basic, Python, Delphi). Dit houdt ook onder meer in dat het vrij gemakkelijk te 'installeren' en te compileren moet zijn. Bovendien moet het natuurlijk gratis zijn. Ik heb genoeg materiaal(boeken en ebooks) om de talen, voor dit specifieke onderwerp, te leren.

[Boudewijn]

Haskell.


Reden is dat het grappig is een heel ander paradigma te gebruiken, en je dus meer conclusies kunt trekken.
Ook omdat puur functionele talen niet voor IO gemaakt zijn (en, laten we eerlijk zijn monads ook wat raar zijn).

Gratis en veel boeken (wikibooks....) : check.

[Haan]

Ik vraag me meer af of dit niet al eerder is uitgezocht? Ik kan me wel zo'n tabel herinneren waarin verschillende programmeertalen op snelheid werden vergeleken.

[ToFast]

Een ander punt:

Het is niet de bedoeling dat ik met een stopwatch ga kijken wat de responstijd is per algoritme per taal. Valt er iets te regelen in al deze talen dat de output (hoef al helemaal niet te werken met GUI's of input van gebruikers) de tijd is, die nodig was voor het uitvoeren van de code per taal?

[Boudewijn]

Ik neem aan dat hij daar voor zijn bachelor thesis wel over nagedacht heeft? Op zich zou ik hier trouwens wel nog een zekere 'verrijking' in verwachten, want echt spannend is het nog niet.

[Boudewijn]

ToFast schreef op woensdag 22 april 2009 @ 17:20:
Een ander punt:

Het is niet de bedoeling dat ik met een stopwatch ga kijken wat de responstijd is per algoritme per taal. Valt er iets te regelen in al deze talen dat de output (hoef al helemaal niet te werken met GUI's of input van gebruikers) de tijd is, die nodig was voor het uitvoeren van de code per taal?

Uiteraard wel, maar dat zal waarschijnlijk je executie ook (minimaal) beinvloeden .
Het linux time commando kan dat iig voor alle executables.


Btw; interpreted talen zijn vaak veel langzamer dan gecompileerde.

offtopic:
Shit dubbelpost, sorry

[ Voor 13% gewijzigd door Boudewijn op 22-04-2009 17:22 ]

[ToFast]

Boudewijn schreef op woensdag 22 april 2009 @ 17:19:
Haskell.
Reden is dat het grappig is een heel ander paradigma te gebruiken, en je dus meer conclusies kunt trekken.
Ook omdat puur functionele talen niet voor IO gemaakt zijn (en, laten we eerlijk zijn monads ook wat raar zijn).

Kan je dit nader toelichten? Bedoel je dat het zoeken van woorden in tekst (tekstfile(input)) met behulp van genoemde algoritmen niet veel gedaan wordt? En dat het daarom wel grappig is om te testen?

[Verwijderd]

@ToFast
Als je iets met linux doet (zoals ik ongeveer uit je plaatje kan opmaken ) kan je zoiets doen van:

time ./prog

Desnoods kan je in bijvoorbeeld C intern gebruik maken voor de tijd bijhouden van de duur dat een algoritme bezig is. ik weet de precieze syntax niet meer maar ik geloof dat het wel te regelen is dat het kan door time.h te includen en daar wat mee te doen

[Boudewijn]

True, maar dan ga je op verschillende manieren meten. En dat is niet de bedoeling. Time is overal hetzelfde .

ToFast schreef op woensdag 22 april 2009 @ 17:23:
[...]


Kan je dit nader toelichten? Bedoel je dat het zoeken van woorden in tekst (tekstfile(input)) met behulp van genoemde algoritmen niet veel gedaan wordt? En dat het daarom wel grappig is om te testen?

Omdat het een compleet ander soort taal is? Functionele talen zijn niet gemaakt voor IO, maar wel erg sterk in bomen etc (dankzij lazy evaluation bijvoorbeeld....). Daarom leuke vergelijking.

[Haan]

Ik kwam deze pagina tegen, staan een hoop links in, veel niet relevant, maar sommige misschien wel

[TheBorg]

An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl for a search/string-processing program

Ada is hier niet getest maar dat is geloof ik nog sneller dan C.

[ Voor 10% gewijzigd door TheBorg op 22-04-2009 17:31 ]

[bomberboy]

http://shootout.alioth.debian.org/

Is het dan zoiets dat je probeert te realiseren, maar dan met je eigen benchmark-applicatie?

[ToFast]

Hier kan ik wel mee uit de voeten. @ TheBorg, interessante pdf ook!
@bomberboy ~ No way dat ik een dergelijke bench-mark applicatie (eromheen?) zelf maak. Het blijft bij het maken en runnen van de codes voor de verscheidene talen en zet deze gegevens bijvoorbeeld in Excel (grafiekjes).

Nog even voor de record, welke van de volgende talen <C++, C#, Visual Basic, Python, Delphi> vallen buiten de boot dan qua uitvoerbaarheid?

Voor de duidelijkheid, ik heb wel wat ervaring in linux, maar zeker niet veel. Daarnaast ben ik ook geen ster in programmeren, dus het moet wel uitvoerbaar blijven! Misschien dat de daadwerkelijke test (code in verschillende talen en de test) dus voor sommige mensen niet al te veel diepgang lijkt te bieden.

Daarnaast is dit de praktische kant van de scriptie. Een veel groter deel is de taalkundige kant, wat in het (ondersteunende) theoretisch gedeelte van de scriptie aan de orde komt.

[ Voor 11% gewijzigd door ToFast op 22-04-2009 18:25 ]

[RobIII]

Zoals ik het nu lees in je TS zul je sowieso eerst eens veel en veel duidelijker moeten gaan definieëren hoe die algoritmes geïmplementeerd moeten worden etc. etc. want je gaat gewoon appels met peren vergelijken. Daarbij heb je nog compiler-optimilisaties, JIT zaken, GC enz. enz. die allemaal van invloed zullen zijn en dan nog de OO/Structured/procedural paradigma's. Je kunt elk van de gewenste algoritmes die je wil gaan vergelijken in verschillende talen op 1001 manieren uitwerken/compileren en zo ver ik zie is er niet echt een beginnen aan als je niet heel duidelijke regels op stelt of is het zoals gezegd appels met peren vergelijken.

[ToFast]

RobIII schreef op woensdag 22 april 2009 @ 17:58:
Zoals ik het nu lees in je TS zul je sowieso eerst eens veel en veel duidelijker moeten gaan definieëren hoe die algoritmes geïmplementeerd moeten worden etc. etc. want je gaat gewoon appels met peren vergelijken. Daarbij heb je nog compiler-optimilisaties, JIT zaken, GC enz. enz. die allemaal van invloed zullen zijn en dan nog de OO/Structured/procedural paradigma's. Je kunt elk van de gewenste algoritmes die je wil gaan vergelijken in verschillende talen op 1001 manieren uitwerken/compileren en zo ver ik zie is er niet echt een beginnen aan als je niet heel duidelijke regels op stelt of is het zoals gezegd appels met peren vergelijken.

Duidelijk, over de implementatie van de algoritmen had ik al wel nagedacht. Tenminste, als je hier bedoelt dat de opbouw van één en hetzelfde algoritme in elke taal zo goed als hetzelfde moet zijn (en zeker niet in de ene taal iteratief en in de andere taal recursief).

Ik had nog niet stil gestaan bij de compiler optimalisaties, maar dit kan ik eventueel (als dat voor elke taal mogelijk is) ook proberen met en zonder optimalisatie. Als een compiler voor een taal geen optimalisaties kan verrichten (of het voor/door mij niet te veranderen is) is dat geen probleem, als ik alles maar goed documenteer en beargumenteer in de scriptie. Maar goed ik zou dus ook moeten uitzoeken in hoeverre deze optimalisaties invloed hebben. Ik verwacht ook dat niet elke taal automatisch bepaalde optimalisaties verricht (java compiler doet wel bijvoorbeeld aan GC standaard dacht ik )

[ Voor 7% gewijzigd door ToFast op 22-04-2009 18:24 ]

[RobIII]

En dat is dus precies waar ik op doel Je zult donders goed allerlei zaken tegen elkaar uit moeten zetten en zélfs dan nog is het eigenlijk appels en peren vergelijken. Tevens ontgaat me een beetje het nut van deze vergelijking; het is niet alsof je een onderbouwde beslissing voor taal X of Y kunt maken op basis van deze non-informatie (IMHO en NOFI verder hoor).

Dom voorbeeldje; maar in sommige talen heb je al een 'native' sortering mogelijkheden. Laat die nou net Quicksort zijn. Gebruik je die dan of ga je het Quicksort algoritme dan alsnog 'met de hand' implementeren? Of gebruik je dan gewoon "MyArray.Sort()"?
En dan heb je straks je meting gedaan en blijk je (bijv.) voor een string-comparison eigenlijk veel beter strcomp te kunnen gebruiken i.p.v. de gangbare operators waardoor je meting 10% sneller is (ik roep maar wat). Wat doet dat met je resultaten? En hoe lang/ver ga je dan door met ieder individueel meetresultaat voor elk algoritme in elke taal optimaliseren? En hoe weet je, als 'beginner' voor elk van die talen, of het wel écht optimaal is? Hoe betrouwbaar zullen je resultaten zijn? En dan: de ene taal gebruikt 500Mb geheugen terwijl de ander de helft zo snel is maar wel maar 16mb geheugen gebruikt. Hoe vergelijk je dat? Hoe trek je dat recht? Of de ene taal performed fantastisch op een Quad Core blabla maar ruk op een Atom en de andere taal juist precies andersom. De ene taal gebruikt native "MMX/SSE/Branch/Pipeline/Memory/Heap/Cache/whatever-optimizations/Andere zaken™" of weet ik het wat en de andere doet/kan dat niet. Hoe verreken je die verschillen?

En stel: uiteindelijk zijn ze dusdanig gelijk met elkaar dat ze op machinetaal niveau vergelijkbaar met elkaar zijn. Je zou haast appels met appels gaan vergelijken. Maar dan: Los van het feit dat je metingen dan ook nauwelijks nog zullen schelen en de hele meting dus bij voorbaat al voor niets is geweest: Hoeveel is er dan nog van de originele/gangbare taal over om te vergelijken? In hoeveel bochten heb je je moeten wringen? En hoeveel werk/tijd kostte dat?

En dan wil ik straks, bij wijze van, nog wel een Rob.Net, Rob# of Rob++ taaltje produceren die in elk van je metingen "wint". Kan die taal verder wel geen ruk maar die taal wint wél... Hoe 'eerlijk' is dat?

Appels en peren. Wat ik je brom

[ Voor 87% gewijzigd door RobIII op 22-04-2009 18:43 ]

[ToFast]

RobIII schreef op woensdag 22 april 2009 @ 18:28:
En dat is dus precies waar ik op doel Je zult donders goed allerlei zaken tegen elkaar uit moeten zetten en zélfs dan nog is het eigenlijk appels en peren vergelijken. ...

Dom voorbeeldje; maar in sommige talen heb je al een 'native' sortering mogelijkheden. Laat die nou net Quicksort zijn. Gebruik je die dan of ga je het Quicksort algoritme dan alsnog 'met de hand' implementeren? Of gebruik je dan gewoon "MyArray.Sort()"?
En dan heb je straks je meting gedaan en blijk je (bijv.) voor een string-comparison eigenlijk veel beter strcomp te kunnen gebruiken i.p.v. de gangbare operators waardoor je meting 10% sneller is (ik roep maar wat). Wat doet dat met je resultaten? En hoe lang/ver ga je dan door met ieder individueel meetresultaat optimaliseren?
De ene taal gebruikt 500Mb geheugen terwijl de ander de helft zo snel is maar wel maar 16mb geheugen gebruikt. Hoe vergelijk je dat? Hoe trek je dat recht?....

Ook dit zijn zeer zeer interessante zaken. Ik zal deze morgen met de begeleidend docent bespreken. Ik kan mij voorstellen dat hij zegt: gebruik voor de hoofd-test geen 'native' sorteer methoden/functies, maar je kan ze eventueel wel opnemen in de scriptie als zijnde mogelijkheden (en eventueel zelfs testen!).

In eerste instantie wilde ik mij beperken tot het meten van de CPU-tijd. Echter, het kan zo zijn dat een taal sneller is door van te voren meer geheugen te reserveren of bij het uitvoeren meer geheugen te gebruiken (zit verschil in toch?).

[ Voor 5% gewijzigd door ToFast op 22-04-2009 18:46 ]

[RobIII]

ToFast schreef op woensdag 22 april 2009 @ 18:44:
(zit verschil in toch?).

Ja, nog los van alle andere zaken die ik dus al aan kaart. En native images v.s. interpreted v.s. IL enz. enz., multi- v.s. singlethreaded, OS/platform factoren, verschillende soorten CPU's/caches/geheugen enz. enz. Ik kan uren doorgaan

Appels en peren.

[ Voor 17% gewijzigd door RobIII op 22-04-2009 18:50 ]

[ToFast]

RobIII schreef op woensdag 22 april 2009 @ 18:46:
[...]

Ja, nog los van alle andere zaken die ik dus al aan kaart. En native images of interpreted enz. enz. Ik kan uren doorgaan

Appels en peren.

Beloofd nog interessant te worden , allerlei correctiefactoren. Aan lang niet alle genoemde zaken had ik gedacht, of teminste zo uitvoerig, als dat ze in dit topic naar boven komen.

Tot zover eerst, ik voorzie morgen een leuk gesprek!

[bomberboy]

ToFast schreef op woensdag 22 april 2009 @ 17:54:
@bomberboy ~ No way dat ik een dergelijke bench-mark applicatie (eromheen?) zelf maak. Het blijft bij het maken en runnen van de codes voor de verscheidene talen en zet deze gegevens bijvoorbeeld in Excel (grafiekjes).

Ik doelde er niet op dat je dit zou zelf zou gaan namaken. Maar eerder dat de testresultaten reeds beschikbaar zijn. Op bovenstaande locatie vind je immers al standaard bechmarks, allen geïmplementeerd in verschillende talen en uitgeveord op verschillende configuraties.

Als ik het goed begrijp is dat min of meer de inputdata die jij ook wil verkrijgen voor je werk, maar dan met je eigen bechmark die je zelf gaat implementeren (dus het zoeken van woorden in een tekst).

Daarnaast is dit de praktische kant van de scriptie. Een veel groter deel is de taalkundige kant, wat in het (ondersteunende) theoretisch gedeelte van de scriptie aan de orde komt.

Ik ben niet echt vertrouwd met je studie Informatiekunde, maar als ik het goed begrijp ligt de nadruk niet hoofdzakelijk op de IT-kant, maar eerder de interactie tussen mens en IT en het verwerken en visualiseren van data enz.

Je zou dan eventueel een deel van die data kunnen gebruiken en analyseren binnen je werk. Zeker omdat je ook aangeeft dat de taalkundige kant een groter deel van je scriptie uitmaakt. Als technische component zou je dan een analyse kunnen doen van de verschillende implementaties, bv qua complexiteit van de code, regels code etc.
Zeker omdat de eigenlijke vergelijking die je wil doen op zich zeer moeilijk is en zeer veel werk zal vragen, zoals RobIII al aangeeft.

Maar ik weet ook niet wat de vooropgestelde requirements zijn natuurlijk
In ieder geval veel succes!

[Woy]

Ik denk eerlijk gezegd dat het ondoenlijk is om verschillende talen op deze manier goed te vergelijken. Er is een wereld van verschil hoe bepaalde dingen geimplementeerd zijn.

Zelfs als je bijvoorbeeld alleen c++ pakt, zijn er een hoop compilers beschikbaar die elk weer andere optimalisaties hebben. Je kunt dus binnen 1 taal al verschillende resultaten gaan krijgen.

Natuurlijk valt er op sommige vlakken wel iets over performance te zeggen (zo heb je bij Java en C# bijvoorbeeld bij een array access ook bounds checks, die je bij c++ soms achterwege kunt laten), maar juist door dit soort kwesties zal je een bepaald algoritme in elke taal misschien weer net iets anders willen implementeren. Als je daar eenmaal aan begint zie je denk door de bomen het bos niet meer. Je zult je dan namenlijk al erg diep in alle talen ( of eigenlijk compilers/run-times ) moeten verdiepen om te achterhalen wat de beste manier is.

Het is dan echter niet echt een vergelijking van talen meer, maar meer een test met welke taal jij de beste implementatie kunt maken.

[roy-t]

om even terug te komen op je eerste vraag, als je java kan, kun je C# ook haast meteen doen en heb je meteen een leuke vergelijking van twee 'huidige generatie' interpreted talen.

Op welk OS ga je trouwens testen? Java/C/C++/C#/PERL/PHP draaien beide allemaal op zowel Windows als Linux. (*hoewel ik niet weet of het eerlijk is om C# op linux te doen, ik vermoed dat mono niet zo snel is als MS' .net interpreter)

[Zoijar]

Eerlijk gezegd vind ik het een beetje nutteloos vergelijk; kan je je tijd niet beter besteden? Zoek maar eens op het verschil in performance tussen C++ en Java... een chaos is dat. Bovendien zegt het ook vrij weinig, want voor het merendeel vaan de applicatie is alleen de complexiteit van de algoritmes van belang. De snelheid van de taal is tegenwoordig een hele kleine factor.

[leuk_he]

Naast response tijd wil je ook een soort van opstarttijd. Dus niet alleen het core algoritme testen, maar ook hoe lang het duurt voordat hij aan de eerste io/o begint.

btw, je gaat implementaties van talen meten, geen talen.

[KopjeThee]

Naast alle al genoemde facotren die een rol spelen, wil ik ook nog even aangeven dat je goed moet uitkijken hoe je de experimenten uitvoert. Als je niet oplet ben je caching gedrag van je CPU / harde schijf aan het meten.

[Haan]

Ben benieuwd wat de begeleider van de TS vandaag heeft te zeggen hierover, als het een beetje capabel persoon is, zal hij ook met de zelfde bezwaren komen als hier wordt genoemd denk ik. Ik betwijfel ten zeerste of hier iets zinnigs uit kan komen, zeker binnen de beperkte tijd die voor een bachelorscriptie hebt.
Zoals het er nu uit ziet ga je alleen enkele zoekalgoritmen beschrijven (dat is al lang door anderen uitgekauwd ) en vervolgens het kunstje in de praktijk uitvoeren. Praktisch gezien heeft dat erg weinig waarde, zeker omdat, zoals al werd opgemerkt, de resultaten worden beïnvloed door hoe goed jij bent in de verschillende programmeertalen. Talen die je nu nog nooit hebt gebruikt, gaan daar zeker nadelig door beïnvloed worden. Dan zou je eigenlijk de implementaties moeten laten doen door communities die bezig zijn met zo'n taal, dan kan je die factor uitsluiten (zo is het in gelinkt artikel ook gebeurd)

Het is natuurlijk vervelend om een leuk onderwerp te moeten laten schieten (zelf ook gehad dat een voorstel voor afstudeeronderzoek werd afgeschoten), maar het moet natuurlijk wel reëel blijven, anders heb je na een paar maanden werk een scriptie zonder nuttige resultaten..
dit is niet om het idee af te branden, maar om te behoeden voor eventuele teleurstelling later

[hamsteg]

Ik vind dit een uiterst vreemde vraag ... sorry.

JAVA, PERL en PHP

De laatste twee zijn in mijn beleving en omgeving geen programmeertalen maar Script-talen. Hiermee wil ik script-talen niets te kort doen want ze maken het werken voor bepaalde toepassingen en snel bewijzen eenvoudig en nemen veel controle werk uit handen, echter er zit een run-time interpreter in die tijd vreet. Deze scripttalen maken gebruik van applicaties die vaak in C geschreven zijn. Wil je snelheid dan zul je alles in een low-level taal (waar C/C++) toe wordt gerekend, moeten omzetten.

JAVA wordt zeker gezien als goede leertaal. Zolang er echter nog een Virtual Machine onder moet draaien (die in C geschreven is) wordt deze taal voor real-time toepassingen niet serieus genomen. Er zijn processoren die tegenwoordig Java Virtual Machine praten maar ik heb hier zelf geen ervaring mee.

Wellicht dat de ene taal meer processor-tijd nodig heeft voor een bepaald algoritme dan de andere.

Dit is een cruciale opmerking die je maakt. Het niet zozeer op het algoritme en je programmeervaardigheid die de snelheid bepaalt maar wel de manier waarop de (script)taal zijn gegevens verwerkt en omgeving gebruikt. Als je kijkt naar een C resultaat is deze klein in code en snel (logisch, is machinetaal). Kijk je naar PHP dan kan de source code ook klein zijn maar je hebt ook de PHP engine en misschien zelfs Apache nodig om te executeren. Omgekeerd, het schrijven van de C applicatie kost meer tijd dan dat van een PHP applicatie, je moet veel low-level acties zelf uitcoderen en je bent zelf verantwoordelijk voor fout detectie/recovery. (PHP lijkt in basis wel wat op C maar heeft een enorm grote en mooie set van libraries/objecten).

Er is ook geen goed en geen fout tussen de programmeertalen! Elk zijn toepassing. Ik moet er niet aan denken om een website in C op te gaan zetten ... dan moet ik eerst het hele HTTP protocol implementeren, vervolgens zelf een HTML interpreter maken en ... onzin. Omgekeerd moet je pace-maker software niet in PHP willen schrijven.

Terug naar je vraag ... die vind ik vreemd omdat je blijkbaar niet weet waarvoor je je software ontwikkelt. Je kunt talen niet even onderling vergelijken. Low level talen zijn duur in ontwikkeling en hebben branduren nodig om uitgebreid te testen, daarvoor terug krijg je betrouwbaarheid en snelheid terug. High Level talen, leveren snel resultaat op, door gebruik van standaard functionaliteiten is de kans op fouten aanzienlijk kleiner maar krijg je ook minder snelheid en is de betrouwbaarheid (=response tijd) beduidend lager.

Een testje met I/O acties is voorspelbaar voor de talen die jij noemt, gokje: van snel naar iets minder snel: C C++, C#, PERL, JAVA, Python, Visual Basic, Delphi, PHP.

Deze conclusies zijn algemeen bekend en zorgen voor hoofdbrekens bij bedrijven. Waarom kies je voor welk platform en taal (platform is ook cruciaal, een PC processor is weer anders als een PLC processor)? Wat wordt de toegevoegde waarde van je scriptie aan deze bekende informatie?

[Woy]

hamsteg schreef op donderdag 23 april 2009 @ 15:51:
De laatste twee zijn in mijn beleving en omgeving geen programmeertalen maar Script-talen. Hiermee wil ik script-talen niets te kort doen want ze maken het werken voor bepaalde toepassingen en snel bewijzen eenvoudig en nemen veel controle werk uit handen, echter er zit een run-time interpreter in die tijd vreet. Deze scripttalen maken gebruik van applicaties die vaak in C geschreven zijn. Wil je snelheid dan zul je alles in een low-level taal (waar C/C++) toe wordt gerekend, moeten omzetten.

Ik vind de grens/het verschil tussen een script-taal en programmeer-taal anders helemaal niet zo duidelijk. Wie zegt er dat een php script niet gewoon gecompiled word, op het moment dat je hem opvraagt?

JAVA wordt zeker gezien als goede leertaal. Zolang er echter nog een Virtual Machine onder moet draaien (die in C geschreven is) wordt deze taal voor real-time toepassingen niet serieus genomen. Er zijn processoren die tegenwoordig Java Virtual Machine praten maar ik heb hier zelf geen ervaring mee.

Dat de Java Virtual Machine in C geschreven is, is natuurlijk geen reden waarom het niet snel ( of zelfs sneller ) dan C code kan zijn. Een C compiler kan immers ook best in C geschreven zijn. Er zijn best valide argumenten te verzinnen waarom je op bepaalde punten in Java nooit de performance kan halen die je met C/C++ kan halen, maar het feit dat de JVM in C geschreven is is dat IMHO niet.

Dit is een cruciale opmerking die je maakt. Het niet zozeer op het algoritme en je programmeervaardigheid die de snelheid bepaalt maar wel de manier waarop de (script)taal zijn gegevens verwerkt en omgeving gebruikt. Als je kijkt naar een C resultaat is deze klein in code en snel (logisch, is machinetaal). Kijk je naar PHP dan kan de source code ook klein zijn maar je hebt ook de PHP engine en misschien zelfs Apache nodig om te executeren. Omgekeerd, het schrijven van de C applicatie kost meer tijd dan dat van een PHP applicatie, je moet veel low-level acties zelf uitcoderen en je bent zelf verantwoordelijk voor fout detectie/recovery. (PHP lijkt in basis wel wat op C maar heeft een enorm grote en mooie set van libraries/objecten).

Je hoeft in PHP natuurlijk niet perse gebruik te maken van de library, en er is geen reden waarom PHP niet eerst naar machinetaal gecompileerd kan worden.

Een testje met I/O acties is voorspelbaar voor de talen die jij noemt, gokje: van snel naar iets minder snel: C C++, C#, PERL, JAVA, Python, Visual Basic, Delphi, PHP.

IO is natuurlijk een van de punten waar je een stuk minder afhankelijk bent van de programmeer omgeving. Het is meer hardware afanhkelijk. Je code staat waarschijnlijk het grootste deel van de tijd gewoon te wachten. Dus ik verwacht dat de verschillen niet extreem groot zullen zijn.

[hamsteg]

Woy schreef op donderdag 23 april 2009 @ 16:38:
[...]
IO is natuurlijk een van de punten waar je een stuk minder afhankelijk bent van de programmeer omgeving. Het is meer hardware afanhkelijk. Je code staat waarschijnlijk het grootste deel van de tijd gewoon te wachten. Dus ik verwacht dat de verschillen niet extreem groot zullen zijn.

Ik kan al je argument gaan bestrijden maar dat doe ik niet want voor een groot deel zijn je opmerkingen valide. Ik heb hier en daar zwart-wit stellingen neergelegd die inderdaad verfijningen zouden kennen ...

Met IO verschil ik waarschijnlijk nog het meest met jou van mening maar dat komt omdat ik een beetje ervaring heb in die hoek (heb jarenlang drivers geschreven) maar die discussie daar gaat het helemaal niet om. De uitkomst van deze discussie is bekend en bezorgt bedrijven verschrikkelijke hoofdbrekens.

Wat is de toegevoegde waarde van dit onderzoek?

De omgekeerde vraag is waarschijnlijk wel interessant.

1. Ik heb als idee applicatie XYZ, wat zijn criteria om te komen tot een optimale oplossing (optimaal hoeft niet snelheid gerelateerd te zijn, kan ook eenvoud van programmeren zijn).
2. Wat zijn de karakteristieken van bepaalde talen? <-- dit is alleen al heel moeilijk !!

Weet die in een flow-chart te gieten en hussel-de-hussel: de beste keuze voor programmeertaal voor dit probleem is ... <antwoord>.

Veel bedrijven kiezen regelmatig automatisch ... het vorige.

edit:
Het gaat mij nog niet om het antwoord maar om hoe de parameters worden geformuleerd en gematched. Mocht je dit een in goed model (future proof) weten te gieten dan wordt je heel snel rijk.

[ Voor 6% gewijzigd door hamsteg op 23-04-2009 16:58 ]

[Woy]

hamsteg schreef op donderdag 23 april 2009 @ 16:53:
[...]
Ik kan al je argument gaan bestrijden maar dat doe ik niet want voor een groot deel zijn je opmerkingen valide. Ik heb hier en daar zwart-wit stellingen neergelegd die inderdaad verfijningen zouden kennen ...

Je bent niet de enige hoor

Met IO verschil ik waarschijnlijk nog het meest met jou van mening maar dat komt omdat ik een beetje ervaring heb in die hoek (heb jarenlang drivers geschreven) maar die discussie daar gaat het helemaal niet om. De uitkomst van deze discussie is bekend en bezorgt bedrijven verschrikkelijke hoofdbrekens.

Er is natuurlijk een verschil tussen het verwerken van data in je cache og geheugen, en het IO van bijvoorbeeld de harde schijf of netwerk. Puur IO van je HD of netwerk zal waarschijnlijk niet zo snel gelimiteerd worden door de programmeer omgeving.

Wat is de toegevoegde waarde van dit onderzoek?

De omgekeerde vraag is waarschijnlijk wel interessant.

1. Ik heb als idee applicatie XYZ, wat zijn criteria om te komen tot een optimale oplossing (optimaal hoeft niet snelheid gerelateerd te zijn, kan ook eenvoud van programmeren zijn).
2. Wat zijn de karakteristieken van bepaalde talen? <-- dit is alleen al heel moeilijk !!

Weet die in een flow-chart te gieten en hussel-de-hussel: de beste keuze voor programmeertaal voor dit probleem is ... <antwoord>.

Veel bedrijven kiezen regelmatig automatisch ... het vorige.

Daar ben ik het wel mee eens hoor, zie mijn eerdere post in het topic. Maar ik vond sommige punten nogal vreemd.

[hamsteg]

Woy schreef op donderdag 23 april 2009 @ 16:57:
[...]
Daar ben ik het wel mee eens hoor, zie mijn eerdere post in het topic. Maar ik vond sommige punten nogal vreemd.

Stond al zoveel tekst, om dan ook nog alle mitsen en maren mee te gaan schrijven ...

Dat de Java Virtual Machine in C geschreven is, is natuurlijk geen reden waarom het niet snel ( of zelfs sneller ) dan C code kan zijn

Klopt, veel te kort door de bocht. Als ik alles even snel kon opschrijven als dat ik denk ... C heeft er op zich niets mee te maken, ik wilde aangeven dat Java bovenop een C implementatie, de VM, nog wat extra's moet doent. Het aanspreken van de VM zorgt voor extra stack op- en af-bouw wat daardoor op eenzelfde machine nooit een sneller resultaat kan geven als dat alles in een (1) applicatie geschreven is. Kompleet foute zinsconstructie 500 gedachten in drie zinnen ...

[ Voor 49% gewijzigd door hamsteg op 23-04-2009 17:11 ]

[_js_]

Maar de JIT compiler betekent weer dat sommige zaken die in C programma altijd uitgevoerd moeten worden (omdat de compiler vooraf niet weet in welke omstandigheden welke delen uitgevoerd worden) in Java achterwege kunnen blijven, omdat de optimizer heeft bedacht dat iets op een bepaald moment niet nodig is.

[TheBorg]

RobIII schreef op woensdag 22 april 2009 @ 18:28:
Appels en peren. Wat ik je brom

Je hebt 100% gelijk, maar dat is helemaal niet erg. Als dat de conclusie is van de scriptie en de onderbouwing is goed dan zou ik niet weten waarom het geen interessant onderzoek kan zijn waarvoor je een dikke vette voldoende kan halen.

[HuHu]

Ik zou het voor de grap ook nog op de GPU implementeren met CUDA en AVT. Als je het toch al over appels en peren hebt, dan kunnen de mandarijnen er nog best bij.

[roy-t]

hamsteg schreef op donderdag 23 april 2009 @ 15:51:
Ik vind dit een uiterst vreemde vraag ... sorry.

[...]

Een testje met I/O acties is voorspelbaar voor de talen die jij noemt, gokje: van snel naar iets minder snel: C C++, C#, PERL, JAVA, Python, Visual Basic, Delphi, PHP.

Deze conclusies zijn algemeen bekend en zorgen voor hoofdbrekens bij bedrijven. Waarom kies je voor welk platform en taal (platform is ook cruciaal, een PC processor is weer anders als een PLC processor)? Wat wordt de toegevoegde waarde van je scriptie aan deze bekende informatie?

Leuk verhaal maar C# en Visual Basic worden beide gecompiled naar I.L. voor zoek algoritmes zullen in de gecompilde I.L. code maar minimale verschillen zitten (weinig te optimaliseren). dus je mag in snelheid rustig C# en VB naast elkaar zetten. Voor de rest ben ik het wel compleet me je eens.

(Of nouja is Python niet sneller? Maargoed dat is irrelevant voor wat je wilt vertellen).

Edit: ik bedoel met leuk verhaal echt een leuk goed verhaal/stukje text, maar het staat er zo een beetje lullig, excuses!

[ Voor 5% gewijzigd door roy-t op 23-04-2009 22:02 ]

[RobIII]

TheBorg schreef op donderdag 23 april 2009 @ 20:54:
[...]

Je hebt 100% gelijk, maar dat is helemaal niet erg. Als dat de conclusie is van de scriptie en de onderbouwing is goed dan zou ik niet weten waarom het geen interessant onderzoek kan zijn waarvoor je een dikke vette voldoende kan halen.

Onder het mom van bezigheidstherapie ofzo dan? Doe dan wat nuttigs/leerzaams met je tijd (of geld; ik zie het vaak zat dat bepaalde instanties met de meest nutteloze rapporten komen... zoals (echt waar!) de gemiddelde kerstman wordt steeds dikker... WTF? )

[TheBorg]

RobIII schreef op donderdag 23 april 2009 @ 22:10:
Onder het mom van bezigheidstherapie ofzo dan? Doe dan wat nuttigs/leerzaams met je tijd (of geld; ik zie het vaak zat dat bepaalde instanties met de meest nutteloze rapporten komen... zoals (echt waar!) de gemiddelde kerstman wordt steeds dikker... WTF? )

Onzin, wat de conclusie is weet ik 5 van de 10 keer voordat een student bij ons een scriptie komt schrijven. De vraagstelling en onderbouwing is veel belangrijker. Het is een scriptie, geen proefschrift.

[Gomez12]

TheBorg schreef op donderdag 23 april 2009 @ 22:31:
[...]

Onzin, wat de conclusie is weet ik 5 van de 10 keer voordat een student bij ons een scriptie komt schrijven. De vraagstelling en onderbouwing is veel belangrijker. Het is een scriptie, geen proefschrift.

Tja, als ik zo'n scriptie van een IT-student zou krijgen ( zal ik nooit krijgen, maar stel even ) dan kan er wmb nog zo'n goede onderbouwing onder zitten, de vraagstelling is wmb gewoon fout.

Er wordt helemaal niet gekeken naar verschillen in responstijd tussen verscheidene programmeer / script talen, er wordt hooguit gekeken naar de kennis van diegene die het geimplementeerd heeft in die taal.

Alles wat naar dezelfde I.L. kan compilen kan 100% even snel zijn ( zelfde I.L. kan 100% zelfde code zijn ), elk verschil wordt veroorzaakt door externe factoren ( compiler settings, keuze wel of geen assembly erin te zetten etc etc ). Elk verschil is een fout van de programmeur ( fout als het gaat over 100% snelheid, complexiteit / devtijd tellen blijkbaar niet mee )

[hamsteg]

_js_ schreef op donderdag 23 april 2009 @ 19:34:
Maar de JIT compiler betekent weer dat sommige zaken die in C programma altijd uitgevoerd moeten worden (omdat de compiler vooraf niet weet in welke omstandigheden welke delen uitgevoerd worden) in Java achterwege kunnen blijven, omdat de optimizer heeft bedacht dat iets op een bepaald moment niet nodig is.

Hoe kun je een realtime compile programma vergelijken met een already compliled programma? Het niet callen van functioneel zeldzame code kost echt minder tijd als dit run-time te moeten constateren, bij JIT draait er continue een compile proces en dat zou voordeliger zijn als een programma dat al volledig gecompileerd is?

Dit is weer appels met peren vergelijken. JAVA achtige talen gebruiken JIT omdat de karakteristiek van hun executie bestaat uit een run-time interpreter. Run time nog compileren kost tijd maar deze talen hebben vaak als enorm voordeel dat ze machine onafhankelijk kunnen werken. Bij een C gecompileerd programma is dit omgekeerd, het programma is geschreven voor specifieke hardware / OS maar heeft als voordeel dat er niets extra's nodig is.

Je kunt niet zomaar 1 ding eruit lichten en benoemen als voordeel want dat is het niet in een andere situatie. Je hebt van die pacemakers die alleen wat doen als het hart stil staat. Stel dat je hart het al 10 jaar goed doet maar ineens stopt. Ik moet er niet aan denken dat er dan eerst besloten wordt om de shock module te gaan compileren ...

[Hydra]

hamsteg schreef op vrijdag 24 april 2009 @ 09:47:
[...]
Hoe kun je een realtime compile programma vergelijken met een already compliled programma? Het niet callen van functioneel zeldzame code kost echt minder tijd als dit run-time te moeten constateren, bij JIT draait er continue een compile proces en dat zou voordeliger zijn als een programma dat al volledig gecompileerd is?

Ja. Dat kan inderdaad voordeliger zijn. Er draait trouwens niet 'continue' een compile proces in de zin dat er een thread volle bak aan het compilen is. De state wordt in de gaten gehouden, en als blijkt dat een bepaalde state niet te bereiken is, wordt de code die ervanuit gaat dat die state wel bestaat verwijderd. Dit gebeurt vooral at class load time. Dus stel je hebt een JAR met Class A, die een if-else statement heeft op basis van output van een Class B in een andere JAR. Als de compiler erachter komt op het moment dat die class geladen wordt dat Class B als resultaat nooit de "else" waarde op kan leveren, wordt dat stuk code gehercompileerd en wordt die branch verwijderd.

Veel mensen hebben het idee dat Java interpreted is, dat is gewoon niet zo. Het wordt uiteindelijk gecompileerd naar machinecode. Het voordeel van de JVM architectuur is dat er op een erg laat moment optimalisaties toegepast kunnen worden, zelfs als de applicatie al draait. Maar dit betekent niet dat de JVM volcontinue classes zit te hercompileren.

Dit is weer appels met peren vergelijken. JAVA achtige talen gebruiken JIT omdat de karakteristiek van hun executie bestaat uit een run-time interpreter.

Nogmaals, Java is GEEN interpreted taal.

Als je wil weten hoe het allemaal wel werkt;
http://java.sun.com/javase/technologies/hotspot/

[ Voor 8% gewijzigd door Hydra op 24-04-2009 13:42 ]

[hamsteg]

Hydra schreef op vrijdag 24 april 2009 @ 13:35:
Nogmaals, Java is GEEN interpreted taal.

Als je wil weten hoe het allemaal wel werkt;
http://java.sun.com/javase/technologies/hotspot/

Hoef je mij niet te vertellen, JAVA ken ik heel goed. Maar er staat ook "JAVA achtige talen". Neem Javascript als fysieke invulling. Met betrekking tot puur JAVA heb jij gelijk.

[Woy]

hamsteg schreef op vrijdag 24 april 2009 @ 13:51:
[...]
Hoef je mij niet te vertellen, JAVA ken ik heel goed. Maar er staat ook "JAVA achtige talen". Neem Javascript als fysieke invulling. Met betrekking tot puur JAVA heb jij gelijk.

Ik vind javascript nou niet echt een voorbeeld van "JAVA achtige talen". Op de naam, en de gelijkende syntax is het compleet wat anders.

[Hydra]

hamsteg schreef op vrijdag 24 april 2009 @ 13:51:
Hoef je mij niet te vertellen, JAVA ken ik heel goed. Maar er staat ook "JAVA achtige talen". Neem Javascript als fysieke invulling. Met betrekking tot puur JAVA heb jij gelijk.

Sorry hoor, maar als iemand meldt "Java heel goed te kennen" (ter info: Java is geen acroniem, je schrijft het gewoon als Java) en het dan over een kam scheert met JavaScript, heb ik moeite die persoon nog serieus te nemen. Java en JavaScript hebben NIKS met mekaar te maken behalve dat ze kwa syntax lijken op C. Dan kun je Java en JavaScript beter C-achtige talen noemen.

[hamsteg]

Hydra schreef op vrijdag 24 april 2009 @ 13:59:
[...]
Sorry hoor, maar als iemand meldt "Java heel goed te kennen" (ter info: Java is geen acroniem, je schrijft het gewoon als Java) en het dan over een kam scheert met JavaScript, heb ik moeite die persoon nog serieus te nemen. Java en JavaScript hebben NIKS met mekaar te maken behalve dat ze kwa syntax lijken op C. Dan kun je Java en JavaScript beter C-achtige talen noemen.

Wat jij wil, jij hebt gelijk.

[Boudewijn]

Inderdaad hebben zij gelijk.

Maar even een heel andere vraag:

Hoe wil je hier een wetenschappelijke ( en vernieuwende, dat is iig een eis bij mijn MSc. thesis software engineering waar ik nu mee bezig ben) onderzoeksvraag en conclusie aan verbinden?

[Hydra]

hamsteg schreef op vrijdag 24 april 2009 @ 14:21:
[...]
Wat jij wil, jij hebt gelijk.

Zolang je met niks anders komt dan "ik weet veel van Java" en dit soort zwakke comebacks ga ik daar even vanuit ja.

Boudewijn schreef op vrijdag 24 april 2009 @ 14:43:
Hoe wil je hier een wetenschappelijke ( en vernieuwende, dat is iig een eis bij mijn MSc. thesis software engineering waar ik nu mee bezig ben) onderzoeksvraag en conclusie aan verbinden?

Het is een bachelor scriptie volgens de TS.

[ Voor 39% gewijzigd door Hydra op 24-04-2009 15:12 ]

[Boudewijn]

Ja dus? Moet dat niet wetenschappelijk zijn dan? .
Ik heb dat trouwens ook gelezen hoor ,en daarom meld ik dat het voor een MSc. scriptie ook vernieuwend moet zijn.

[Haan]

De eisen voor een master scriptie zijn iha wel een stuk strenger dan voor een bachelor scriptie.

[Hydra]

Boudewijn schreef op vrijdag 24 april 2009 @ 15:26:
Ja dus? Moet dat niet wetenschappelijk zijn dan? .

In mijn ervaring niet Dergelijke scripties zijn vaak meer om aan te tonen dat je scripties kunt schrijven

[Boudewijn]

Okay, dan heb ik niets gezegd. IIg wilde ik mijn zorgen uitdrukken over de wetenschappelijke-scriptie-schrijf mogelijkheden van deze vraag.
Zou het zonde vinden als de TS een onderzoekje doet en er dan achterkomt dat het niet aan de eisen voldoet .

offtopic:
Heb zelf nooit een wo-bachelorscriptie geschreven nml.

[Hydra]

Boudewijn schreef op vrijdag 24 april 2009 @ 15:36:
Okay, dan heb ik niets gezegd. IIg wilde ik mijn zorgen uitdrukken over de wetenschappelijke-scriptie-schrijf mogelijkheden van deze vraag.
Zou het zonde vinden als de TS een onderzoekje doet en er dan achterkomt dat het niet aan de eisen voldoet .

offtopic:
Heb zelf nooit een wo-bachelorscriptie geschreven nml.

Zelf een HBO afstudeerscriptie moeten schrijven, en ik verwacht dat dit een beetje hetzelfde niveau heeft. Hoewel het wel een bepaalde mate van onderzoek nodig heeft (was bij ons een eis, dat er zowel een onderzoeks als uitvoerend deel in zat) moet je 'onderzoek' in dit geval vaak meer lezen als 'uitzoek', hoewel daar ook een groot grijs gebied tussen zit natuurlijk.

[hamsteg]

Boudewijn schreef op vrijdag 24 april 2009 @ 14:43:
Inderdaad hebben zij gelijk.

Misschien wel, het is maar hoe je naar iets kijkt.

Maar even een heel andere vraag:

Hoe wil je hier een wetenschappelijke ( en vernieuwende, dat is iig een eis bij mijn MSc. thesis software engineering waar ik nu mee bezig ben) onderzoeksvraag en conclusie aan verbinden?

Deze discussie dus! Ik probeer weg te blijven van uitspraken over talen maar wordt er keer op keer aan de haren bijgesleept omdat iemand zijn heilig huisje een deukje krijgt. Javascript is geen Java (schrijf ik het nu goed, toen ik het leerde was het nog in hoofdletters, sorry dat ik zo oud ben), Javascipt is functioneel en Java is OO. Java gebruikt JIT maar een goede cross-compiler zorgt voor hetzelfde resultaat etc.etc.

Te veel wordt de taal vooropgesteld en hoe goed deze wel niet is. Te weinig wordt het product beoordeeld en de keuze van de taal daarop afgesteld. Hoe kom je tot een goede keuze? Wat zijn de positieve en negatieve karakteristieken voor een taal. Welke technische en niet technische criteria zijn er? De niet technische criteria zijn vaak doorslaggevend!

TS doet hetzelfde. Neemt een uitgangspunt en gaat vervolgens kijken hoe dit elders werkt. Alsof je een motorrijder met helm op op de fiets zet, in mini drukt of in een F1 auto zet. Alle drie is niet optimaal (fietsen met een helm is echt een ramp, in de mini zul je waarschijnlijk bijna niets zien omdat je geen bewegingsvrijheid hebt, in F1 kun je niet vol gas want een motorhelm is echt wat anders als een F1 helm met HANS). Je moet eerst weten wat je omgeving is (stad/snelweg/race circuit/lucht), dan weten wat er van je verlangt wordt (snel, gegarandeerd overkomen, veel of weinig te vervoeren), je kiest je hardware (fiets, vrachtauto, motor, vliegtuig) en als laatste ga je keuzes maken in wie het voertuig bestuurt (taalkeuze) met welke veiligheidsuitrusting (niet-goed weer scenario's, rijbewijs/certificaten leren).

[Hydra]

hamsteg schreef op vrijdag 24 april 2009 @ 15:42:
Te veel wordt de taal vooropgesteld en hoe goed deze wel niet is. Te weinig wordt het product beoordeeld en de keuze van de taal daarop afgesteld. Hoe kom je tot een goede keuze? Wat zijn de positieve en negatieve karakteristieken voor een taal. Welke technische en niet technische criteria zijn er? De niet technische criteria zijn vaak doorslaggevend!

Aangezien de doelstelling is vast te stellen welke taal het 'snelst' is in het uitvoeren van vastgestelde scenario's doen de "niet technische" criteria niet ter zake. de TS wil niet vaststellen wat de 'beste' taal is voor bijvoorbeeld een grote webapplicatie. Het gaat hier om synthetische performance tests. Ik snap niet waarom je, als de TS wil testen wat de zoeksnelheden in tekst zijn in verschillende talen, "niet technische" criteria (ik verwacht dat je het hier over kostenposten als onderhoudbaarheid enzo hebt) er bij de haren bijsleept.

[hamsteg]

Hydra schreef op vrijdag 24 april 2009 @ 15:48:
[...]
Aangezien de doelstelling is vast te stellen welke taal het 'snelst' is in het uitvoeren van vastgestelde scenario's doen de "niet technische" criteria niet ter zake. de TS wil niet vaststellen wat de 'beste' taal is voor bijvoorbeeld een grote webapplicatie. Het gaat hier om synthetische performance tests. Ik snap niet waarom je, als de TS wil testen wat de zoeksnelheden in tekst zijn in verschillende talen, "niet technische" criteria (ik verwacht dat je het hier over kostenposten als onderhoudbaarheid enzo hebt) er bij de haren bijsleept.

Ik dacht dat we al hadden geconcludeerd dat deze onderzoeken al gedaan zijn en dat zijn onderzoek niets nieuws zal opleveren. Wil TS niet een 13 in een dozijn rapport opleveren die meer vragen als antwoorden oproept dan zul je toch wat anders moeten gaan zoeken.

"niet technische" criteria, kunnen kosten zijn, maar ook inleer effecten (tijd = ook weer kosten uiteindelijk), cursus, wetgeving (bijv. privacy), strategische beslissingen, beschikbaarheid van support, cultuur als we-hebben-het-altijd-zo-gedaan, fabriek kan nieuwe techniek niet aan, processen ... een aantal gaan te ver om in een model te gieten maar een aantal komen met grote regelmaat terug.

Als je een goede aanzet weet te maken voor een simpel model (hou het simpel want er zijn duizenden keuzes te maken, pak uit de verschillende categorieën een paar belangrijke) en pas die toe op een twee-, drietal praktijkvoorbeelden, dan zie ik TS slagen met vlag en wimpel. Iemand die beslissingen gefundeerd ter discussie durft te stellen kan bij ons meteen beginnen.

[Boudewijn]

Tsja als een bachelor scriptie een HBO achtig ding is, is dit onderzoek leuk... maar waarom een onderzoek als dit doen als je HBOer bent? (ik heb nml ook HBO gedaan).
Als wetenschappelijk onderzoek twijfel ik aan de kwaliteit op het gebied van vernieuwing. Het is dus vlees noch vis.

Ik laat me buiten de java vs. javascript discussie, maar heb zo wel mijn mening (die ook al door anderen is geventileerd hier).

[RayNbow]

hamsteg schreef op vrijdag 24 april 2009 @ 15:42:
Javascipt is functioneel en Java is OO.

JavaScript heeft een prototype-based OO model. Verder zou ik het label functioneel alleen gebruiken voor talen als Haskell, Clean, F#, etc.

Neemt niet weg dat je functioneel kunt programmeren in JS, maar de onderstaande Church encoding van een pair vind ik niet zo heel erg makkelijk leesbaar:

JavaScript:

pair  =  function(x,y) { return function(f) { return f(x,y) } }
fst   =  function(p) { return p( function(x,y) { return x } ) }
snd   =  function(p) { return p( function(x,y) { return y } ) }

Zeker niet als je het vergelijkt met Haskell:

Haskell:

pair x y = \f -> f x y
fst p = p (\x y -> x)
snd p = p (\x y -> y)

Java gebruikt JIT maar een goede cross-compiler zorgt voor hetzelfde resultaat etc.etc.

Ik zou eerder JIT vergelijken met PGO dan louter je code voor meerdere platformen te compileren.

Boudewijn schreef op woensdag 22 april 2009 @ 17:19:
Ook omdat puur functionele talen niet voor IO gemaakt zijn (en, laten we eerlijk zijn monads ook wat raar zijn).

Ten eerste, monads zijn niet de enige manier om IO te modeleren in een puur functionele taal. Clean bijvoorbeeld gebruikt uniqueness typing.

En monads zijn verre van raar. Ik raad je aan om Brent Yorgey's Typeclassopedia artikel te lezen in The.Monad Reader 13.

[ Voor 21% gewijzigd door RayNbow op 24-04-2009 16:57 ]