:strip_exif()/u/25166/new-ico.gif?f=community)
putStr $ map (x -> chr $ round $ 21/2 * x^3 - 92 * x^2 + 503/2 * x - 105) [1..4]
/u/2046/pooh2.png?f=community)
Jij zult zeker vervelende ervaringen hebben met Java en ik geloof ook zeker dat meer mensen die zullen hebben.
LOL
. Heel erg fijn dat je jouw persoonlijke visie als feiten verspreid. Java Servlets bieden toch wel een wat andere omgeving dan PHP. Bovendien zie ik geen bewijzen dat Java server-side steeds minder in gebruik zijn. Wil je serieus beweren dat een taal zonder multi-threading, goede object-orientatie, polymorphisme in diverse vormen een serieuze vervanger is voor Java 
.Verder is je opmerking dat Java op win32 binnen een paar jaar verdwenen is helemaal een persoonlijke visie van jou. Java is helemaal niet gerelateerd aan wat voor platform dan ook. In de opkomende markt van desktop operating systems kan Java wellicht een belangrijke rol spelen.
Het punt is dat jij niets anders doet dan negatieve opmerkingen maken. Je maakt onjuiste vergelijkingen, presenteert ongeldige bewijzen die veel lijken op middeleeuwse bewijzen dat God bestaat. Ik weet genoeg negatieve aspecten van Java te noemen. Java is niet perfect. Het idee achter Java is wel perfect.
De manier waarop jij discussieerde is zeer onaangenaam. Jij probeert voortdurend argumenten te maken door te zeggen dat je mede discussie genoten er niets vanaf weten. Dat ik daarbij noem dat ik een degelijk opleiding heb genoten is niet meer dan logisch.
Ik bezit behoorlijk wat kennis van Java en het Java Platform. In discussies zet ik die kennis in om dingen uit te leggen over de punten die ter discussie komen. Mag dat? Toevallig zijn er erg veel mensen geinteresseerd in deze ontwikkelingen.
Ik spreek wat betreft de run-time optimalisaties ook voortdurend over de toekomst. Ik vermoed dat deze in de toekomst na een lange ontwikkeling een pluspunt kunnen zijn. Ik noemde de 3D demo omdat dit aantoont dat de nieuwe ontwikkelingen toepassingen met grote data-sets mogelijk maakt. Mag dat niet?
Dit is weer zo'n stelling-name: ik ben beter dan jullie. Ik weet alles, waar jullie mee bezig zijn, ben ik allang overheen. Beste Otis, zo voer je geen discussie. Ik word er ook een beetje moe van om je daar steeds op te moeten wijzen, dus ik zal het vanaf nu niet meer doen.
Naast Sun zijn er nog veel andere grote Java supporters. Heb je weleens op de site van IBM gekeken? Ben je weleens bij alle uitermate interessante projecten van Apache geweest? Weleens gekeken naar JBoss? Ik noem zo maar een paar zaken uit mijn hoofd.
Het punt is dat jij jouw persoonlijk mening ziet als de volledige waarheid. Denk er eens bij na dat ik jouw posts op dezelfde manier kan zien als jij mijn posts.
Je gaat op veel van mijn concretere antwoorden geeneens in. Vind je het dan niet interessant meer? Als ik geen antwoord krijg op mijn reacties op jouw stellingen ga ik er van uit dat ik gelijk heb.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Wow. Java discussie, dus mbravenboer en wasigh verkondigen het grote J woord weer! Dat mag ook wel met al die heidenen die er blijkbaar niet zo veel vanaf weten hehehe... Hoe heette God in het Hebreeuws ook al weer, Jahwe ofzo? Komt al best in de buurt toch lol 
Anyway Java is cool, Java is flexibel, en Java is langzaam. Als je toch duffe business logic maakt dan kun je dat het beste in java doen denk ik, dan snap je het over 2 maanden nog, dat is in c++ wel anders. Maarre, Doom 3, dat gaat dus nevernooit op java draaien.
Conclusie: als je lekker object georienteerd, snel gemakkelijk, uitbreidbaar en platformonafhankelijk je programma's in elkaar wilt zetten, dan pak je java, want die forceert dat allemaal, altijd goed dus. En als het echt real time moet, spelletjes en hartbewaking enzo, of een kritische memory management, dan pak je c++. Een echte bikkel kan het toch allebei, enne, een echte loser kan niet zonder COM components hahaha wat een non argumenten allemaal zeg.
Zo lekker vaag maar het is al vroeg
Dat mag ook wel met al die heidenen die er blijkbaar niet zo veel vanaf weten hehehe... Hoe heette God in het Hebreeuws ook al weer, Jahwe ofzo? Komt al best in de buurt toch lol Anyway Java is cool, Java is flexibel, en Java is langzaam. Als je toch duffe business logic maakt dan kun je dat het beste in java doen denk ik, dan snap je het over 2 maanden nog, dat is in c++ wel anders. Maarre, Doom 3, dat gaat dus nevernooit op java draaien.
Conclusie: als je lekker object georienteerd, snel gemakkelijk, uitbreidbaar en platformonafhankelijk je programma's in elkaar wilt zetten, dan pak je java, want die forceert dat allemaal, altijd goed dus. En als het echt real time moet, spelletjes en hartbewaking enzo, of een kritische memory management, dan pak je c++. Een echte bikkel kan het toch allebei, enne, een echte loser kan niet zonder COM components hahaha wat een non argumenten allemaal zeg.
Zo lekker vaag maar het is al vroeg
Verwijderd
En over wie had je wat te piepen?
Ik heb erg veel tekst gepost in deze thread, om nu dat te herkauwen in kleine beetjes als antwoorden op jouw antwoorden lijkt me wat onnodig. Ik blijf erbij dat zodra 'java' valt en je iets negatiefs zegt daarover, je door de advocates onder de zoden wordt gestopt. Lees dan je eigen posting hierboven eens na! Ik heb je en anderen gewezen op discussies zoals die al 2 jaar geleden zijn gevoerd in nl.comp.programmeren, waar ik een deel hier vanpostte, die over exact hetzelfde gingen. Puur als aanvulling. Tja.
Als ik dan 'alleen maar negatief' ben, so be it. Als ik negatief over java wil zijn dan doe ik dat, tenslotte heb ik kennis genoeg over de materie. Jij kennelijk ook en je hebt een ander oordeel.
En je mag van mij gelijk hebben hoor.
Advocates krijgen van mij altijd gelijk als de discussie op het punt beland van "als ik geen antwoord krijg op mijn 1500 regelig repliek heb ik gelijk" haha . Of je ook gelijk HEBT, is wat anders. Maar daarvoor verwijs ik graag terug naar een van mijn 1000 regelige postings in deze thread.Wat me wel stoort is het feit dat ik geprobeerd heb de discussie naar een wat meer analytisch niveau te tillen dan het niveau van "het is sneller welles/nietes want mijn app blabla". Enfin, dat was een vergissing. Veel plezier nog in deze 'discussie'.
.
Over jouOtis: En over wie had je wat te piepen?
. Ik ben heel concreet ingegaan op jouw argumenten tegen mijn opsomming van de voordelen van java en het Java Platform. Op geeneen ben je serieus ingegaan. Heb ik je nog of dynamic class loading, COM en Corba gehoord?Ik probeer de discussie naar een technische analyse van Java en het Java Platform te leiden zonder vage uitspraken te doen. Dat lukt ook niet
.HeheEnfin, dat was een vergissing. Veel plezier nog in deze 'discussie'.
. Hier stond net iets over vakgenoot. Wat dacht je? Oops, I did it again?
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
:strip_exif()/u/18993/logo.gif?f=community){kind=logo}
Otis, lees ff je eigen reacties door en kijk eens in de spiegel.
Het is nl nogal een pot verwijt de ketel verhaal.
Voor de laatste keer:
verder voor de 100* _daar ging dit topic niet over_
Het is nl nogal een pot verwijt de ketel verhaal.
Voor de laatste keer:
Onder de zoden gestopt? Mbravenboer en ik zijn de 1-sten die toegeven dat Java ook negatieve kanten heeft (ja echt waar staat in dit topic!) verder is wat jij doet meer een poging tot onder de zoden stoppen dan een poging tot een discussie. Als je discussie begint zonder open te staan voor andere ideeen, wat je duidelijk niet doet. begin dan ook niet aan een discussie.
Die gingen niet over exact hetzelfde
Kijk dat is nog eens een intelligent inzicht
mmm, heb je het nu over jezelf? als er iemand is die veel blaat zonder wol ben jij het tot nu toe geweest. Je hebt meningen als feiten gepresenteerd en als het al feiten waren dan miste elke bewijs.En je mag van mij gelijk hebben hoor.
Je bedoelt die posting over dat c++ altijd sneller als java, daar is volgens mij al genoeg kritiek op geweest. Als ze dadelijk een java chip uitbrengen hangt je hele hypothese
verder voor de 100* _daar ging dit topic niet over_imo heb je alleen je gelijk proberen te halen door tehcnische termen aan te halen. Misschien moet je eens leren open te staan voor andere denkwijzenWat me wel stoort is het feit dat ik geprobeerd heb de discussie naar een wat meer analytisch niveau te tillen dan het niveau van "het is sneller welles/nietes want mijn app blabla". Enfin, dat was een vergissing. Veel plezier nog, 'vakgenoot'
Einde zinloze discussie. Laten we het eens op een objectieve, technische en duidelijke manier over Java en het Java Platform hebben. Voor de liefhebbers wil ik graag nog even wat grote nadelen van het Java en het Java Platform vermelden . Ik hoop dat hieruit een zinvolle en interessante discussie kan ontstaan .
Allereerst over de taal Java:
* Java maakt onderscheid tussen primitieven en objecten. Hierdoor kan je geen ints gebruiken in generieke code zoals verzamelingen. De int moet hiervoor geconverteerd worden naar een Integer object om hem in een verzameling te kunnen stoppen.
* Generics (ook wel geparameterizeerde typen genoemd) zullen pas komen in een latere versie van Java. Dit was voor versie 1 eigenlijk een onmisbare functie geweest. Nu moeten er enorm veel concessies gedaan worden om de code compatible te houden met oudere Java VMs. Dit zorgt ervoor dat generics niet op een fraaie manier geimplementeerd zijn (maar ondanks dat wel op een fraaie manier gebruikt kunnen worden).
* De reflectie implementatie is in feite een hack. Dit is een grote vergissing geweest en het had zeker een onderdeel moeten zijn van de eerste Java specificaties.
* Java heeft geen ondersteuning voor constanten, tenzij via een verwarrende syntax gedeclareerd. Vooral de mogelijkheid om final variabelen in een klasse op te nemen en ze daarna in de constructor een waarde te geven is verwarrend. Uberhaupt is het verwarrend dat je klasse variabelen zowel in de constructor als in de declaratie een waarde kunt geven.
* Java heeft geen ondersteuning voor contravariante argument type, waar theoretisch absoluut geen bezwaar tegen te maken is.
* Java heeft geen ondersteuning van enumeraties. Op zich is dat geen probleem omdat het op een fraaie object-georienteerde manier valt te realizeren, maar feit is dat dit niet gebeurt. De Java API zelf wemelt van de constante integers om zogenaamd als enumeratie vervangen te dienen. Ik weet niet of je weleens bent begonnen met tellen bij 0 totdat je moe was, maar ik kan je garanderen dat dat een behoorlijke enumeratie is!
* Java's systeem van constructor overerving is ongelukkig. Vaak bieden klassen veel constructor varianten. Als je deze klasse extend, moet je voor al deze gevallen opnieuw een constructor aanmaken. Daar word je niet blij van.
* Java heeft geen override aanduiding, waardoor het onduidelijk kan zijn of je daadwerkelijk iets override of niet. Zeker kan de compiler dit niet voor je controleren.
* java.lang.Object bevat wat merkwaardige methoden die daar naar mijn mening niet thuis horen. Allereerst is er een standaard equals methode. Dat vind ik niet prettig, want sommige objecten zijn gewoon niet vergelijkbaar. Bovendien is er geen mogelijkheid om af te dwingen dat een klasse een goede implementatie van een equals methode heeft. Eigenlijk zou de equals eruit moeten en vervangen moeten woorden door een interface. Hetzelfde verhaal geldt in feite voor hashCode en clone. Verder vind ik die methoden voor multi-threading in java.lang.Object niet fraai. Ook hiervoor zou eigenlijk een apart systeem gemaakt moeten worden, zodat niet alles een lock is. Laten we het maar helemaal niet gaan hebben op de uitermate obscure manier van serializatie via de Serializable interface.
* public static void main(String[] ps) is antiek. Java is OO, laten we dan ook applicaties op een OO manier starten. Het volgende idee:
Weg magie. Weg onduidelijkheid.
Dat was een aardig lijstje niet? Ik weet zeker dat ik nog ergernissen ben vergeten, maar helaas kan ik ook niet door blijven denken. Ik ga even over op Java als Platform. Ik ga niet in op de massa design fouten in de Java bibliotheken, want dan zou ik een perpetuum mobile moeten zijn.
* Java bytecode is veel te veel Java bytecode. Java bytecode is duidelijk opgezet als bytecode voor gecompileerde Java. Dat is een ongelukkige beslissing, want Java staat al behoorlijk op een eiland doordat het in een VM draait. JNI is ook nogal een gevaarte, wat niet erg prettig werkt. Java bytecode zou een grotere instructieset moeten hebben, waardoor andere talen makkelijker naar Java bytecode kunnen worden gecompileerd. In feite komt het er op neer dat wanneer een taal op het Java Platform wil draaien, hij gecompileerd moet kunnen worden naar de taal Java.
* De Java VM is nogal vaak bezig met het opnieuw uitvinden van het wiel. Allereerst wordt elke applicatie in een aparte VM gedraaid (nog). Dit is uitermate ongelukkig. Ten tweede wordt code die naar native code gecompileerd is niet opgeslagen. Dit is begrijpelijk omdat dit zeer veel complicaties zou veroorzaken, maar het zou misschien wel mogelijk moeten zijn als je dit zelf expliciet aangeeft.
* Doordat Java zo enorm afhankelijk is van het Java Platform gaan er in de toekomst grote problemen komen. Als Java vervangen gaat worden door een beter alternatief en de implementaties van Virtual Machines langzaam stopt, wat gebeurt er dan met al je Java code? Een groot deel van de software die nu draait is nog steeds in Cobol geschreven. Hoe zal Java functioneren als verouderde taal?
* Een Java Virtual Machine zou eigenlijk verschillende modussen moeten hebben voor andere versies van Java (bijvoorbeeld 1 versus 2). Ooit komt er een tijd dat methodens en klassen die deprecated zijn, ook daadwerkelijk verwijderd gaan worden. Wat gebeurt er met alle bestaande applicaties die daar nog steeds gebruik van maken? Die werken gewoon niet meer.
Goed, dat was nogal een lijst he? Ik kan nog wel even doorgaan, maar helaas heb ik ook geen nachten de tijd . Ondanks alles is Java als taal en Java als Platform voor mij nog steeds een goede keuze. Ik kijk uit naar een omgeving die Java perfectioneert. Misschien wordt het in de toekomst tijd voor een grondige herziening van Java en het Java Platform, om de lessen van de afgelopen jaren te verwerken. Hierbij zou absoluut geen rekening gehouden moeten worden met oudere Java versies. Je zult zeggen, wel daar is .NET, maar daar ben ik het dan weer niet helemaal mee eens.
Voordat een grondige herziening moet plaatsvinden zijn we echter nog wel 5 - 7 jaar verder. Eerst moet het Java Platform stabiliseren. Dit zal zeker nog 2 a 3 jaar duren naar mijn mening.
. Ik hoop dat hieruit een zinvolle en interessante discussie kan ontstaan .Allereerst over de taal Java:
* Java maakt onderscheid tussen primitieven en objecten. Hierdoor kan je geen ints gebruiken in generieke code zoals verzamelingen. De int moet hiervoor geconverteerd worden naar een Integer object om hem in een verzameling te kunnen stoppen.
* Generics (ook wel geparameterizeerde typen genoemd) zullen pas komen in een latere versie van Java. Dit was voor versie 1 eigenlijk een onmisbare functie geweest. Nu moeten er enorm veel concessies gedaan worden om de code compatible te houden met oudere Java VMs. Dit zorgt ervoor dat generics niet op een fraaie manier geimplementeerd zijn (maar ondanks dat wel op een fraaie manier gebruikt kunnen worden).
* De reflectie implementatie is in feite een hack. Dit is een grote vergissing geweest en het had zeker een onderdeel moeten zijn van de eerste Java specificaties.
* Java heeft geen ondersteuning voor constanten, tenzij via een verwarrende syntax gedeclareerd. Vooral de mogelijkheid om final variabelen in een klasse op te nemen en ze daarna in de constructor een waarde te geven is verwarrend. Uberhaupt is het verwarrend dat je klasse variabelen zowel in de constructor als in de declaratie een waarde kunt geven.
* Java heeft geen ondersteuning voor contravariante argument type, waar theoretisch absoluut geen bezwaar tegen te maken is.
* Java heeft geen ondersteuning van enumeraties. Op zich is dat geen probleem omdat het op een fraaie object-georienteerde manier valt te realizeren, maar feit is dat dit niet gebeurt. De Java API zelf wemelt van de constante integers om zogenaamd als enumeratie vervangen te dienen. Ik weet niet of je weleens bent begonnen met tellen bij 0 totdat je moe was, maar ik kan je garanderen dat dat een behoorlijke enumeratie is!
* Java's systeem van constructor overerving is ongelukkig. Vaak bieden klassen veel constructor varianten. Als je deze klasse extend, moet je voor al deze gevallen opnieuw een constructor aanmaken. Daar word je niet blij van.
* Java heeft geen override aanduiding, waardoor het onduidelijk kan zijn of je daadwerkelijk iets override of niet. Zeker kan de compiler dit niet voor je controleren.
* java.lang.Object bevat wat merkwaardige methoden die daar naar mijn mening niet thuis horen. Allereerst is er een standaard equals methode. Dat vind ik niet prettig, want sommige objecten zijn gewoon niet vergelijkbaar. Bovendien is er geen mogelijkheid om af te dwingen dat een klasse een goede implementatie van een equals methode heeft. Eigenlijk zou de equals eruit moeten en vervangen moeten woorden door een interface. Hetzelfde verhaal geldt in feite voor hashCode en clone. Verder vind ik die methoden voor multi-threading in java.lang.Object niet fraai. Ook hiervoor zou eigenlijk een apart systeem gemaakt moeten worden, zodat niet alles een lock is. Laten we het maar helemaal niet gaan hebben op de uitermate obscure manier van serializatie via de Serializable interface.
* public static void main(String[] ps) is antiek. Java is OO, laten we dan ook applicaties op een OO manier starten. Het volgende idee:
code:
1
2
3
4
| public interface Application
{
public void start(List<String> parameters);
} |
Weg magie. Weg onduidelijkheid.
Dat was een aardig lijstje niet? Ik weet zeker dat ik nog ergernissen ben vergeten, maar helaas kan ik ook niet door blijven denken. Ik ga even over op Java als Platform. Ik ga niet in op de massa design fouten in de Java bibliotheken, want dan zou ik een perpetuum mobile moeten zijn.
* Java bytecode is veel te veel Java bytecode. Java bytecode is duidelijk opgezet als bytecode voor gecompileerde Java. Dat is een ongelukkige beslissing, want Java staat al behoorlijk op een eiland doordat het in een VM draait. JNI is ook nogal een gevaarte, wat niet erg prettig werkt. Java bytecode zou een grotere instructieset moeten hebben, waardoor andere talen makkelijker naar Java bytecode kunnen worden gecompileerd. In feite komt het er op neer dat wanneer een taal op het Java Platform wil draaien, hij gecompileerd moet kunnen worden naar de taal Java.
* De Java VM is nogal vaak bezig met het opnieuw uitvinden van het wiel. Allereerst wordt elke applicatie in een aparte VM gedraaid (nog). Dit is uitermate ongelukkig. Ten tweede wordt code die naar native code gecompileerd is niet opgeslagen. Dit is begrijpelijk omdat dit zeer veel complicaties zou veroorzaken, maar het zou misschien wel mogelijk moeten zijn als je dit zelf expliciet aangeeft.
* Doordat Java zo enorm afhankelijk is van het Java Platform gaan er in de toekomst grote problemen komen. Als Java vervangen gaat worden door een beter alternatief en de implementaties van Virtual Machines langzaam stopt, wat gebeurt er dan met al je Java code? Een groot deel van de software die nu draait is nog steeds in Cobol geschreven. Hoe zal Java functioneren als verouderde taal?
* Een Java Virtual Machine zou eigenlijk verschillende modussen moeten hebben voor andere versies van Java (bijvoorbeeld 1 versus 2). Ooit komt er een tijd dat methodens en klassen die deprecated zijn, ook daadwerkelijk verwijderd gaan worden. Wat gebeurt er met alle bestaande applicaties die daar nog steeds gebruik van maken? Die werken gewoon niet meer.
Goed, dat was nogal een lijst he? Ik kan nog wel even doorgaan, maar helaas heb ik ook geen nachten de tijd
. Ondanks alles is Java als taal en Java als Platform voor mij nog steeds een goede keuze. Ik kijk uit naar een omgeving die Java perfectioneert. Misschien wordt het in de toekomst tijd voor een grondige herziening van Java en het Java Platform, om de lessen van de afgelopen jaren te verwerken. Hierbij zou absoluut geen rekening gehouden moeten worden met oudere Java versies. Je zult zeggen, wel daar is .NET, maar daar ben ik het dan weer niet helemaal mee eens. Voordat een grondige herziening moet plaatsvinden zijn we echter nog wel 5 - 7 jaar verder. Eerst moet het Java Platform stabiliseren. Dit zal zeker nog 2 a 3 jaar duren naar mijn mening.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Verwijderd
Wat verwijt ik de pot dan, als ketel zijnde? beetje ongenuanceerde opmerking.
Erm... ik ben veelal negatief geweest over java. Nu mag je jezelf op de borst slaan dat juist JIJ negatief bent over java, go ahead, maar wat is dan je probleem mbt mijn postings? Zijn ze te positief oid? En welke andere ideeen moet in omarmen? Die open deuren die ik al jaren zie in allerlei java publicaties? Die beloftes dat de 'volgende' JVM wel alles veel sneller zal doen e.d.? Als iemand mij oud nieuws vertelt, waarom moet ik daar dan nog op in gaan? omdat het voor jou NIEUW nieuws is? Dat is toch niet mijn probleem?
Mja, dat jij niet snapt wat ik bedoel met mn theoretische onderbouwing is niet mijn probleem hoor. Dat ik blaat zonder wol (?) is jouw constatering. Als iemand aankomt met zo'n verhaal over 3D rendering en ik zet daar mn vraagtekens bij, tja. Dat jij dat dan niet trekt, dat is OOK jouw probleem. Ik wil best daar ook een theoretische onderbouwing voor neerleggen maar ik denk dat dat verspilde moeite is. Sorry hoor, maar je gepiep hierboven is pure flamebait: AL mn meningen zijn als feiten gedeponeerd ZONDER ENIG bewijs. Tja:
Jehova: God bestaat!
Atheist: God bestaat NIET!
Jehova: Je levert geen enkel bewijs!
Welke kritiek? in de newsgroup bedoel je of hier? Het is een beschrijving van een theoretische situatie. En ja als de javachip er OOIT komt dan is het overbodige kost. Net zoals het niet opgaat als je java naar native code compileert en draait buiten de JVM om.[..]
Je bedoelt die posting over dat c++ altijd sneller als java, daar is volgens mij al genoeg kritiek op geweest. Als ze dadelijk een java chip uitbrengen hangt je hele hypothese
[..]
Tja... als je iets zegt wat niet waar is en ik toon aan dat dat niet waar is, en jij begint dan dat ik iets roep zonder enig bewijs, houdt het voor mij op hoor. Als jij denkt dat ik van niets weet en pas kom kijken heb je het mis. Ik hoor al jaren allerlei denkwijzen over het topic 'java', sommigen hebben gelijk, anderen niet. Het is maar een tool, een taal EEN platform. Niets meer. Daar lyrisch over doen is het meer ophemelen dan wat het feitelijk waard is. Dat is mn doel geweest in deze thread. Dat jij dat als aanval ziet op jouzelf is niet mijn probleem, ik heb helemaal niets tegen jou of jouw denkwijze. Wat me alleen stoort is dat ik geen negatief beeld mag schetsen van Java zonder dingen als:imo heb je alleen je gelijk proberen te halen door tehcnische termen aan te halen. Misschien moet je eens leren open te staan voor andere denkwijzen
naar mn kop te krijgen. En dan ga JIJ mij verwijten dat ik niet open sta voor andermans denkwijze. Laser toch op!
Verwijderd
Ik hoop dat ze genoeg diskspace hebben gereserveerd voor GoTOp vrijdag 31 augustus 2001 01:52 schreef mbravenboer het volgende:
Einde zinloze discussie. Laten we het eens op een objectieve, technische en duidelijke manier over Java en het Java Platform hebben. Voor de liefhebbers wil ik graag nog even wat grote nadelen van het Java en het Java Platform vermelden
Vaak gehoord als nadeel en OO-fetisjisten zeuren hier al jaren over: Java is niet puur OO want sommige basistypes zijn geen objects. Het is ook een lapmiddel geweest, om de JVM sneller te maken bij aritmetic operaties. Echter er valt wel wat voor te zeggen: als je gaat definieren wat een object is, dan kun je beredeneren dat (bv) een integer een vastomlijnd iets is, waar je, ookal creeer je derived classes, geen karakterwijzigingen aan kunt doen. In feite dus een base-class. Immers, je zou wel kunnen denken aan: baseclass number -> class integer, maar dan?
Dit is het aloude verhaal: "in C++ kun je wel X doen, in Java niet... Java sux". Generics lijken me hetzelfde toe als templates in C++. Op zich een krachtig instrument om taaltechnisch je expressiekracht te verhogen, echter noodzakelijk zijn ze geensinds. De theorie van OO/inheritance/polymorphism vereist geen generic types/templates. De enige reden dat templates/generic types er zijn / komen is het feit dat men middels taaltechnische truuks de hoeveelheid typewerk wil verkleinen. (want templates verlagen de hoeveelheid typewerk enorm, maar je kunt altijd om ze heen). Echter, als je kijkt naar hoe je je OO structuur ontwerpt, bv middels een NIAM/ER-model methodiek, dan is al wat rest die te implementeren en zodra je iets wijzigt, doe je dat eerst in het model, daarna genereer je de class definities opnieuw en DAARNA wijzig je de implementatie. Dat kun je doen met java 1.0. Daar heb je geen geparametriseerde types voor nodig.
Templates in C++ verlagen overigens drastisch de leesbaarheid van je code, daar code gegenereerd wordt middels de waarden van parameters. Een mens is erg slecht in het interpreteren van computertaal en heeft gem. gezien moeite met het interpreteren van dit soort constructies: wat is de class die wordt gegenereerd, bij inputparameters van deze en deze waarden?
Op zich is het niet raar dat er geen constantes in zitten. C++ heeft die ook niet. #define is in theorie een obsolete keyword, men wordt geacht enums te gebruiken. De reden hiervoor is is dat enums een type hebben en constants niet. Constants op zich zijn ook niet meer dan een taaltruuk: ipv '10' schrijf je "MAX_INTEGER_FOR_THIS_PURPOSE" oid. Als je nu variables gebruikt ipv de constante, ben je ook typesafe bezig. Vandaar dat final int MYMAXVALUE=3; op zich een betere keuze is dan #define MYMAXVALUE 3.
Dat de declaratie en de constructor variabele waarden toekenning toelaten is iets van C++ denk ik. Ik heb ook nooit begrepen waarom mensen in C++ bv in .h files allerlei dingen gaan verwoorden die in de .cpp thuis horen en vice versa.
Enums zijn in theorie alleen nodig indien je non-typesafe constantes toelaat, C++ doet dat dus wel, want #define mag bv. Java heeft al final type var=value dus op zich hoeft enum niet. Tuurlijk is het handig dat je een rijtje kunt genereren, maar als je goed kijkt naar wat een enum is, dan is het niets anders dan een class met het type van het enum met daarin de final variables.
Ikzelf gebruik enums nauwelijks, alleen in mn DemoGL scriptparser, in de lexical analyser tables. Maar je kunt goed zonder is mn ervaring.
Dit is denk ik het resultaat van de single inheritance: er is geen taalelement noodzakelijk om aan te geven dat je een bepaalde baseclass parent wilt instantieren, zoals bij C++ het geval is. Kennelijk heeft java de filosofie dat je altijd de uiterste leaf van een inheritance-hierarchie wil instantiaten (wat logisch klinkt
), ipv een class in het midden. Roep je een constructor aan van een baseclass van een zekere class, wat voor object krijg je dan? de baseclass of de zekere class?main is toch gewoon een default method van je .class of snap ik iets niet? je applicatie is toch het object, dus mag je een method daarin hebben die alles start, of je dat nu doet door een interface te implementeren of niet, is niet zo belangrijk. Als je nl. het via een interface doet, geef je daarmee aan dat er andere interfaces zijn die wellicht ook mogen. Waardoor executielogica extra complex wordt.
* filename.class moet hetzelfde zijn als de classname. Ik vind hoe het is opgelost in .NET een stuk fraaier en flexibeler.
Bytecode is een ouder idee hoe je VM's maakt. Per definitie ging men er van uit dat je dan bytecode behappende VM's moest maken en dat als target moest nemen voor je taal/compiler. Dat de java bytecode aan de taal is vastgeklonken is niet vreemd: java is gepositioneerd jaren terug als alternatief platform voor windows, op thin clients. Dat is ook de reden geweest dat Sun tegen MS is gaan procederen mbt MS' truukje in J++ 6 dat java-p (platform) van java-t (taal) is losgesneden: java-t werd gebruikt om COM objects (elegante manier overigens, echt intens jammer dat dat niet meer kan) te bouwen en naar native x86 te compileren...
De filosofie was: java-t is de toegang tot java-p. Dus promoot java-t en omdat java-p nodig is, wordt java-p wijdverspreid, wat de bedoeling was. Ga je java-p open stellen voor andere talen, is java-t overbodig en mis je je drive voor java-p (want waarom een vm targeten als je ook native kunt compileren met die taal?) en java-t naar andere platforms laten vertalen levert niet de gewenste verspreiding van java-p op.
aparte VM's is een security issue, de 'sandbox', en is een overblijfsel van de applet-crap. Applets leken de initiator tot de java-overwinning maar werden de uiteindelijke ondergang op de desktop. Overigens is het gebruikelijk dat VM's in aparte sandboxes draaien. de MSDos VM die in NT/win2k zit draait ook alles in aparte processes. De JIT output opslaan zou nuttig kunnen zijn, mar dan alleen als je veelvuldig dezelfde handelingen doet. Maar aangezien je alles toch realtime optimized is opslaan overbodig.
Niet. Java is een 3rd generation language. Op den duur gaan die er allemaal uit. Hoe het gaat worden wordt een beetje aangegeven door bv Bizztalk server en Office XP developer: dmv diagrammen teken je de flow en de events in je programmatuur, of beter: je tekent de functionaliteit in de vorm van flow control en events. Dan implementeer je NU nog die events in 3rd generation language (office xp developer) maar in bizztalk server bv genereert de server zelf de XML parameters voor de engine. Programmeren hoeft niet meer.
Alles inkloppen is in feite een raar iets: kost erg veel tijd, levert erg veel fouten op en is erg complex. De komende jaren zal er een verschuiving plaatsvinden naar talen die expressief veel beter zijn. En face it: Cobol is erg goed in het kort opschrijven van wat er gedaan moet worden. Wil je dat doen in 3GL's dan ben je meer tijd kwijt. Het is het lot van elke 3GL op den duur, het hangt af van de grootte van de groep fetisjisten hoelang een taal het nog uithoudt. Tenslotte zijn er nog steeds mensen die het fijn vinden om in assembler te programmeren.
Klopt. Maar dat is de tand des tijds. Software heeft net als elk product een lifecycle. Is die ten einde dan is het einde verhaal, vervangen. Tuurlijk zijn er mensen die vast blijven houden aan oude spullen, net zoals er mensen zullen blijven die de DOS versie van Exact blijven gebruiken zullen er mensen blijven die in oude auto's rond rijden. Maar het blijven uitzonderingen. En deprecated is niet ambigu: 'it's dead, get over it': pas aan of blijf met oude troep werken.
De les die .NET en de CLR leert is dat Java-p en java-t niet verbonden KUNNEN blijven. En Rational Rose, die de java-t compiler voor .NET gaat maken bewijst ook dat het beter is die 2 zaken los te laten. Sun echter houdt vast aan de koppeling want het is de enige manier om macht te houden over de gebruiker van java-t, maar ironisch genoeg is het ook de enige levensader van java-t: zodra java-t losgelaten wordt van java-p is java-t dead, en java-p al helemaal. Het wordt dan 'just another 3GL language', en daar zijn er al zoveel van (python, VB, C++, Pascal/delphi etc etc).Goed, dat was nogal een lijst he? Ik kan nog wel even doorgaan, maar helaas heb ik ook geen nachten de tijd
Als je de .NET documentatie doorneemt, zie je ook dat er een erg open architectuur is mbt native api/platform calling, het werken met win32 components etc. Java heeft dat niet, althans niet zo open.
Ik denk dat java-t in .NET wel succesvol zal zijn en dat (IMHO) zal blijken dat java-t mbv .NET beter zal functioneren (lees: naar de developer toe krachtiger zal zijn) dan met een native JVM.
over 5 a 7 jaar hoop ik toch echt niet dat men nog 3GL's gebruikt voor het schrijven van software
Wellicht voor low level zaken, maar zeker niet voor de bulk. Dat zal lijmcode worden, veelal gegenereerd door tools, die objects aan elkaar knoopt. Lijm + objects functioneren weer als object, en voila Generatoren van code, daar gaan we naar toe. Zitten we nu mbv compilers (generatoren van assembler) in 3GL die generatoren te sturen, ik denk dat binnen een aantal jaren de generatoren voor 3GL's meer en meer de overhand krijgen. Immers: het blijft implementeren van functionaliteit en wat een developer doet is een afbeelding maken van de functionaliteit op de computer, zodat de computer begrijpt hoe de functionaliteit werkt. Wat je wilt is een zo makkelijk mogelijke manier om die afbeelding te maken. Het ultieme in die situatie is je functionele beschrijving in leesbare taal gebruiken, dus een generator die dat begrijpt is wat je uiteindelijk wilt. Als je daar naar kijkt zijn 3GL's inmens primitief en cryptisch en is er niet 1 2 3 een verband te zien tussen code en functionaliteit. Slimmere generatoren die omschrijvingen van de functionaliteit die dichter bij de oorspronkelijke leesbare tekst staan, kunnen behappen zijn de toekomst. Hoe naar dat wellicht ook klinkt
Das beter . . Als ik de lengte van jouw post zie belooft dat niet veel goeds .
Ik was trouwens nog 1 belangrijk punt vergeten waar vast veel mensen over vallen:
* Methode parameters zouden standaard final moeten zijn (Gelukkig kent Java uberhaupt al geen out parameters).
De rest van je reacties over het Java Platform komt later. Ik moet eerst ff weg .
.Hehe
. Als ik de lengte van jouw post zie belooft dat niet veel goeds .Ik zie het punt niet helemaal waarom dit een argument voor een andere benadering van primitieve typen zou moeten zijn. Er zijn al klassen in java.lang die precies doen wat jij zegt. Door de klassen Integer, Long, Double, Float etc final te verklaren kunnen ze niet meer uitgebreid worden. Probleem opgelost. Helaas worden deze klassen dus niet gebruikt vanwege performance redenen (wat waarschijnlijk dus maar goed is ook) maar toch is het uitermate onprettig. Auto-boxing van C# vind ik eerlijk gezegd ook geen goed alternatief, dan doe ik het nog liever zelf. Dit auto-boxing zou wel eens hele ondoorzichtige performance problemen op kunnen gaan leveren.
Qua functionaliteit inderdaad wel, qua implementatie absoluut niet. Er wordt geen code gegeneerd voor elk type parameter, het zijn dus geen 'templates'.
Mee eens, maar ze dragen wel zeer sterk bij aan de prettige werking van de taal. Als er geen generics zijn moet je voortdurend kiezen tussen twee alternatieven die je eigenlijk allebei niet wilt: generieke klassen met casts of voor elk type een andere verzameling. Samen met het ontbreken van covariante return typen was dit werkelijk een nacht-merrie.
Mee eens, het punt is echter dat door de zeer drastische inperking van de hoeveelheid typewerk generics enorm bijdragen aan het ontwikkelen van generieke code. Vroeger offerde ik regelmatig vele regels op om casts te vermijden. Dat is nu niet meer nodig. Uiteraard levert dit theoretisch geen verrijking op, maar fijn is het wel.
Dit is ook 1 van de redenen geweest waarom de JSR een andere aanpak heeft gekozen. Als ik het goed begrepen heb is het de bedoeling dat C# vrijwel hetzelfde systeem gaat bevatten.
Maar dragen wel sterk bij aan de onderhoudbaarheid van de code.
Enigszins mee eens, maar toch ook weer niet helemaal. Uiteraard zouden constanten allereerst type-safe moeten zijn, maar het hoofdpunt is dat je op deze manier taal-technisch aan kunt duiden wat het doel is van de variabele. Final variabelen zijn niet per definitie bedoeld als constanten (wel, dat ligt er uiteraard aan wat je onder een constante verstaat).
Ik was trouwens nog 1 belangrijk punt vergeten waar vast veel mensen over vallen:
* Methode parameters zouden standaard final moeten zijn (Gelukkig kent Java uberhaupt al geen out parameters).
Uiteraard, zo implementeer ik enums ook altijd. Het punt is echter dat het gros van de programmeurs dit niet doet (naar voorbeeld van de Java API). Wellicht dat het daarom een onverstandige keuze is geweest om er geen aparte taal-constructie voor te maken. Uiteraard is die taal-technisch gezien absoluut overbodig en misschien zelfs lelijk. In de praktijk kan het misschien net de stap zijn waardoor mensen 'int enums' gaat vermijden.
Hoezo? Ik zie niet in waarom Java deze filosofie zou moeten hebben?
Als je vanuit een sub class de super constructor aanroept krijgt 'this' een instantie van de klasse van de subclass. In de super klasse is 'this' ook altijd van het type van de subklasse. Als je gewoon vanuit een methode de constructor van een klasse aanroept die ook nog extenties heeft, is dat geen enkel punt. Je krijgt dan gewoon een instatie van die klasse.
Ik vind dat een programma voldoet aan een bepaald type. Hij kan namelijk opgestart worden. Dit gebeurt nu door een static main methode, wat een conventie is. Door de main methode geef je aan dat deze klasse gestart kan worden als een applicatie. Voor dergelijke aanduidingen zijn nu echter juist interfaces uitgevonden! Via een interface (en de nodige methoden daarin) kan je op een standaard OO manier aangeven dat iets een applicatie is. Dat vind ik persoonlijk een stuk mooier.
Dat hoeft niet percee. Er kan gewoon in java.lang een interface Application opgenomen worden. Deze interface moet geimplementeerd worden door een applicatie. Dit komt in feite op hetzelfe systeem neer als bij Applets en Servlets.
De rest van je reacties over het Java Platform komt later. Ik moet eerst ff weg
.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
is die gare discussie van jullie nou nog niet afgelopen? kom op heej, wat moet de t.net server wel niet denken van al die gigantische teksten
.edit: oh ik zie dat jullie al het punt hebben bereikt waarop jullie elkaar niet meer 'uitschelden'
.edit: oh ik zie dat jullie al het punt hebben bereikt waarop jullie elkaar niet meer 'uitschelden'
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
zie het als een got benchmark
De discussie begint pas net interressant te worden op naar de 300 reactie's
De discussie begint pas net interressant te worden
op naar de 300 reactie's
code:
1
2
3
4
5
6
7
| idletime t.net servers normaal: 70% discussie*: 1% *) de discussie in kwestie gaat tussen mbravenboer en otis, over de plus en minpunten van Java (en C) |
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Het is gewwon onzinnig om ellenlang te discussieren over programmeertalen, elke taal heeft zijn voor- en nadelen! Java is bijv. heel mooi voor os-onafhankelijke niet of nauwelijks GUI georienteerde programma's of applets, terwijl C++ en Delphi bijvoorbeeld veel krachtiger zijn m.b.t. GUI-ontwerp en performance. Dan hebben we nog functionele programeertalen die m.b.t. AI ver boven Java, C++ en Delphi uitsteken. Aan de andere kant hebben die functionele talen (zoals Prolog) ook hun beperkingen m.b.t. GUI, complexiteit etc.Op vrijdag 31 augustus 2001 16:20 schreef OiSyN het volgende:
code:
DE ideale taal en development environment die voor alle soorten toepassingen geschikt is bestaat eenvoudig niet... Het is onzin dat Java C++ verslaat, beide zullen naast elkaar blijven bestaan, hooguit de vorm van een van beide of beide zal veranderen...
Cogito Ergo Credo
:strip_exif()/u/22119/ch.gif?f=community)
Mag ik even?!
Paar puntjes
• Java is een veel nettere taal dan C++. De standaard C++ is verdwenen, er zijn te veel "toevoegingen" in de syntax gekomen in de loop der tijden (denk bijv. aan namespaces) wat de portabiliteit niet ten goede komt.
• De syntax van C++ is in opzet compacter (vind ik persoonlijk mooier).
• De OO van C++ is verder doorgevoerd. (denk bijv. aan multiple inheritance) Dat soort functionaliteit mis je in Java echter niet als je C++ niet gewend ben.
• De snelheid van Java zal alleen maar toenemen, de toekomst zal het leren of het voor real-time applicaties geschikt gaat worden
• Tot nog toe is C++ een taal die in elke laag van een PC-systeem tot zijn recht kan komen,
• Deze discussie is een welles-nietes verhaal geworden Laten we daar maar dus mee ophouden
Daarmee bedoel ik vooral mbravenboer, Otis en wasigh (alfabetische volgorde, expres).
Het komt er op neer dat iedereen zijn eigen voorkeur heeft. Je kunt ook een discussie gaan voeren of een Ferrari beter is dan een Lamborghini. Dat is allemaal zo betrekkelijk dat de discussie een smaak-discussie wordt, en over smaak valt niet te twisten zoals wij allemaal donders goed weten
Mijn voorstel is
kiss and make up
Paar puntjes
• Java is een veel nettere taal dan C++. De standaard C++ is verdwenen, er zijn te veel "toevoegingen" in de syntax gekomen in de loop der tijden (denk bijv. aan namespaces) wat de portabiliteit niet ten goede komt.
• De syntax van C++ is in opzet compacter (vind ik persoonlijk mooier).
• De OO van C++ is verder doorgevoerd. (denk bijv. aan multiple inheritance) Dat soort functionaliteit mis je in Java echter niet als je C++ niet gewend ben.
• De snelheid van Java zal alleen maar toenemen, de toekomst zal het leren of het voor real-time applicaties geschikt gaat worden
• Tot nog toe is C++ een taal die in elke laag van een PC-systeem tot zijn recht kan komen,
• Deze discussie is een welles-nietes verhaal geworden Laten we daar maar dus mee ophouden
Daarmee bedoel ik vooral mbravenboer, Otis en wasigh (alfabetische volgorde, expres).
Het komt er op neer dat iedereen zijn eigen voorkeur heeft. Je kunt ook een discussie gaan voeren of een Ferrari beter is dan een Lamborghini. Dat is allemaal zo betrekkelijk dat de discussie een smaak-discussie wordt, en over smaak valt niet te twisten zoals wij allemaal donders goed weten
Mijn voorstel is
kiss and make up
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
Verwijderd
/me heeft nog geen FOX in de discussie langs zien komen....
De ulitmate gui-toolkit al zeg ik het zelf...
www.fox-toolkit.org
De ulitmate gui-toolkit al zeg ik het zelf...
www.fox-toolkit.org
/u/3106/crop601874b34ff83_cropped.png?f=community)
Verwijderd
Beetje oftopic-ish... maar een paar kleine correcties Heb je het const voorvoegsel gemist? C++ heeft wel constanten. Kan gerust const int whatever = 1 zeggen. #define is AFAIK niet obsolete. Is deel van de preprocessor die van C is meegenomen. Compleet met #ifdef stuff etc.
#define is inderdaad niet 'the way' voor constanten.
That aside. Enum is verder ook leuk omdat de betere compilers ook warnings kunnen geven als je niet de hele enum range behandeld in een switch.
Discussie loopt wel leuk afgezien van de occasional welles/nietes geemmer
Vind ik eigenlijk niet. Hangt er een beetje vanaf hoe je dermee omgaat. Door op de juiste punten typedefs toe te passen hou je het geheel lekker overzichtelijk. En een andere container gebruiken is daarna helemaal peanuts.
Uhm??
Heb je het const voorvoegsel gemist? C++ heeft wel constanten. Kan gerust const int whatever = 1 zeggen. #define is AFAIK niet obsolete. Is deel van de preprocessor die van C is meegenomen. Compleet met #ifdef stuff etc.#define is inderdaad niet 'the way' voor constanten.
That aside. Enum is verder ook leuk omdat de betere compilers ook warnings kunnen geven als je niet de hele enum range behandeld in een switch.
Deel programming style, deel luiheid (gok ik) en het kan noodzakelijk zijn voor inlining.
Ik niet volg niet? Zou het eerder omgekeerd doen. Enums zijn leuk voor typesafe constanten en variabelen die alleen waarden uit de enum mogen hebben. Laat ik hier wel bij zeggen dat sommige compilers hier niet zo netjes mee omspringen.
Je kunt inderdaad zonder. Maar in sommige situaties zijn ze iets handiger (vind ik) zie ook mijn opmerking hierboven. Verder is het minder typen dan tig #defines's of const int's.
Discussie loopt wel leuk afgezien van de occasional welles/nietes geemmer
Ondertussen gaat de discussie meer over technische, vrij principiele voor of nadelen van Java. Het is absoluut geen krachtmeting tussen twee talen.
Volwassen he?
.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Uiteraard, altijd leuk als mensen meedoen.
</li>
Dit valt onder "mag ik mijn mening even verkondigen"
. Ik ben het wel met je eens, maar dat doet er niet toe.Dat vind ik wel een leuke opinie. Ik vraag me af of ik het daar mee eens moet zijn. Ik denk het niet eigenlijk
. Multiple inheritance van klassen is een zeer discutabel punt waar iedereen een andere mening over heeft. Feit is echter wel dat het complexiteit veroorzaakt. Java heeft multiple inheritance van interfaces. C# heeft precies dezelfde keuze gemaakt en dat geeft denk ik toch minstens aan dat de ontwikkelaars van die taal de gemaakte keuzes bij Java ondersteunen.Vind ik wel meevallen. Na mijn verhaal over de negatieve aspecten van Java, is Otis daar goed op in gegaan. Daar heb ik weer op gereageerd zonder dat dit een welles nietes discussie is geworden. Het is een interessante discussie over de keuzes die bij Java genomen zijn.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Verwijderd
typedefs mogen strict genomen van straustrupp ook nietOp vrijdag 31 augustus 2001 17:12 schreef izniegoed het volgende:
Beetje oftopic-ish... maar een paar kleine correcties
[templates suck volgens otis]
Vind ik eigenlijk niet. Hangt er een beetje vanaf hoe je dermee omgaat. Door op de juiste punten typedefs toe te passen hou je het geheel lekker overzichtelijk. En een andere container gebruiken is daarna helemaal peanuts.
Maar waar ik op doelde was: templates genereren code, maar welke is pas duidelijk zodra je de templates doorneemt. Dat kan lastig zijn (idem voor operator overloads). Te pas en te onpas gebruiken kan leesbaarheid verlagend zijn.
*oef*[voor constantes gebruik je enums in C++]
Uhm??
#define is inderdaad niet 'the way' voor constanten.
inderdaad.
ik zat te slapen. #define is volgens straustrupp wel obsolete overigens, daar het bv macro's in de hand werkt (yuck) en constante definities op z'n 'C'-s.Als je typesafe constantes toelaat heb je geen enums nodig, want alle constante's hebben al een type. Enums zijn dan alleen 'handig' voor rijtjes. Meer niet.
Verwijderd
Hieruit concludeer ik dat jij de discussie wilt stoppen, puur en alleen omdat jij er geen nut inziet en omdat jij het niet interessant vindt.
This proves my point.
Ik kan nu alle FAQs wel voor je opnoemen maar daar zit niemand op te wachten. In short: als jij de discussie niet interessant vindt dan doe je och gewoon niet mee? Sim-pel.
rot op man, een Lamborghini heeft dus echt wel meer PK'tjes dan zo'n zielig ferraritje, bovendien zijn ze nog mooier ook
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Over het algemeen is het gebrek aan ervarenheid en kennis die de zogenaamde nadelen van een platform veroorzaken. Met behulp van de juist bibliotheken kan je in C++ prachtige OS-onafhankelijke GUIs schrijven. Met behulp van voldoende kennis en ervaring kan je met Swing zeer goede userinterfaces schrijven in Java. Dat vrijwel alle userinterfaces in Java brak zijn wordt veroorzaakt door:
1. Gebruik van AWT
2. Onvoldoende kennis bij gebruik van Swing.
Diegene waarop je reageert deed helemaal geen uitspraak over voor en nadelen van talen. Hij beweerde dat C++ en Java voor een groot deel in het dezelfde ontwikel-domein voorkomen. Misschien heeft hij daar wel gelijk in.
Ik begrijp niet dat de geachte lezers dit nog als een dom welles nietes verhaal ervaren. In het begin is er nogal een oninteressant gezeur ontstaan tussen Otis/Wasigh/mij maar daarna zijn er enkele reacties geweest waarin een duidelijke technische bespreking van Java is geweest. Dat jij die niet interessant vind, vind ik weer niet interessant
.Ik denk overigens dat je niemand in deze thread hebt horen beweren dat of C++ of Java de ultieme taal is zonder voor- of nadelen. De opmerkingen die je daarom maakt over kortzichtigheid vallen daarom volgens mij een beetje in de categorie 'standaard wijze mannen opmerkingen', zoals je die ook vaak tegenkomt op de front-page van Tweakers.net.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
/u/1830/acm.png?f=community)
:strip_icc():strip_exif()/u/23243/icon2.jpg?f=community)
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
Zoeken op D schiet ook niet zo op he?
. Het stond een tijdje geleden op Slashdot geloof ik.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
tomato is ook niet voor niets Google spammer .
Zo fantastisch is D trouwens niet... Heb behoorlijk wat kritiek erop gelezen. Volgens mij wordt het ook niet echt serieus ondersteund door een of andere bedrijf of instelling.
.Zo fantastisch is D trouwens niet... Heb behoorlijk wat kritiek erop gelezen. Volgens mij wordt het ook niet echt serieus ondersteund door een of andere bedrijf of instelling.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
ExactlyOp zondag 02 september 2001 19:39 schreef mbravenboer het volgende:
tomato is ook niet voor niets Google spammer
Same here.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Misschien niet goed genoeg mijn best gedaan ?Op zondag 02 september 2001 19:35 schreef tomato het volgende:
http://www.digitalmars.com/d
Waarom schiet zoeken op D niet op?
Interessant linkje. ff doorspitten...
Tja, je zal het toch ff de tijd moeten gunnen. Hoe lang bestaat Java nou al? Toch al wel een jaartje of 7, zo niet langer (exact weet ik het niet, er zijn er vast wel een paar die het wel weten).
Was sun toen al zo bekend? Het duurt gewoon een tijdje voor zoiets echt van de grond komt. En als de programmers-community het een goede uitweg vindt, dan is het binnen no-time een veel-gebruikte taal (om maar ff een open deur in trappen)
iig ga ik er even wat over lezen.
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
Ik kom wel een paar rare dingen tegen, zeg:
• Types:
een ; achter een while is gewoon leesbaar
• Statements:
Goto? Goto wilden we toch niet meer? Geeft toch ontraceerbare code
• Arrays
Wat is nou het verschil tussen "Pointers" en "Dynamic arrays"?
oftewel:
Zie evt. ook "Rectangular Arrays":
Waarom zou je de get- en set-methods achterwege laten?
Verlies je op deze manier niet behoorlijk wat structuur? Waar trek je nu de lijn tussen methode en eigenschap
• Embedding D in HTML
drm.setFacialExpression ( 6 x )
of moest het nou drm.facialExpression = 6 x zijn?
• D Class Library
• Acknowledgements
Hierbij wil ik even zeggen dat ik trots ben op mijn neef, Jan Knepper (afgezien van zijn 
website)
------------------------------------------------------
Ik geef verder dit project, deze taal erg veel kans. De robuustheid, het accent op X-platform, X-OS en X-systeem implementatie, de zachte compatibiliteit met C en C++ en de eigenschappen van Java die D ondersteunt, stemmen mij gerust dat deze taal absoluut voeten aan de grond gaat krijgen.
------------------------------------------------------
Vergeef mij mijn off-topic geblaat
* drm pleads guilty
• Types:
• Empty Statement
een ; achter een while is gewoon leesbaar
• Statements:
Goto? Goto wilden we toch niet meer? Geeft toch ontraceerbare code
• Arrays
Wat is nou het verschil tussen "Pointers" en "Dynamic arrays"?
oftewel:
code:
1
2
| int[] a; // is a nou niet gewoon een pointer? int *p; // net als dat je p kan laten wijzen naar het eerste element in een array? |
Zie evt. ook "Rectangular Arrays":
• Classes
Waarom zou je de get- en set-methods achterwege laten?
code:
1
2
3
4
5
6
7
8
9
10
11
12
| class Abc
{ int myprop;
void property(int newproperty) { myprop = newproperty; } // set'er
int property() { return myprop; } // get'er
}
/*
which is used as:
*/
Abc a;
a.property = 3; // equivalent to a.property(3)
int x = a.property; // equivalent to int x = a.property() |
Verlies je op deze manier niet behoorlijk wat structuur? Waar trek je nu de lijn tussen methode en eigenschap
• Embedding D in HTML
drm.setFacialExpression ( 6 x
)of moest het nou drm.facialExpression = 6 x
zijn?• D Class Library
hmmm...
• Acknowledgements
Hierbij wil ik even zeggen dat ik trots ben op mijn neef, Jan Knepper
(afgezien van zijn website)------------------------------------------------------
Ik geef verder dit project, deze taal erg veel kans. De robuustheid, het accent op X-platform, X-OS en X-systeem implementatie, de zachte compatibiliteit met C en C++ en de eigenschappen van Java die D ondersteunt, stemmen mij gerust dat deze taal absoluut voeten aan de grond gaat krijgen.
------------------------------------------------------
Vergeef mij mijn off-topic geblaat
* drm pleads guilty
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
Verwijderd
Omdat alleen de algemene ideeen over de taal nog maar zijn bedacht. Er is nog geen praktische implementatie, protype model of zelfs maar een prototype-API te vinden.Op zondag 02 september 2001 19:39 schreef mbravenboer het volgende:
tomato is ook niet voor niets Google spammer
Zo fantastisch is D trouwens niet... Heb behoorlijk wat kritiek erop gelezen. Volgens mij wordt het ook niet echt serieus ondersteund door een of andere bedrijf of instelling.
Daar kan je dus als bedrijf nog niks mee.
Als het echt interessant is dan komt D vanzelf wel opzetten. Ik denk echter dat het voorlopig (komende 5 jaar) nog niks wordt. Het is namelijk door een persoon bedacht, niet door een standaard-/ISO-organisatie. Dan maak je niet veel kans vrees ik, in de grote wereld.
Tijdje geleden was er overigens ook een topic over D (geopend door /me *
)
hah, mijn eigen bedachte taal, C *= 6, is veel beter dan D
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
O ja op welke punten??Op maandag 03 september 2001 12:15 schreef OiSyN het volgende:
hah, mijn eigen bedachte taal, C *= 6, is veel beter dan D
Welke eigenschappen zou een perfecte taal hebben?
Alles in templates. Zelfs de syntax 
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
Je kunt er zo iig voor kiezen of je het wilt gebruiken of niet.Op maandag 03 september 2001 10:07 schreef drm het volgende:
Ik kom wel een paar rare dingen tegen, zeg:
• Statements:
Goto? Goto wilden we toch niet meer? Geeft toch ontraceerbare code
Het verschil lijkt mij dat bij "Dynamic arrays" het geheugenmanagement voor je geregeld wordt.
properties vind ik ook behoorlijk evil, maar je kunt natuurlijk gewoon nog get/set functies kunt gebruiken als je wilt.• Classes
Waarom zou je de get- en set-methods achterwege laten?
Verlies je op deze manier niet behoorlijk wat structuur? Waar trek je nu de lijn tussen methode en eigenschap
inderdaad nogal• Embedding D in HTML
drm.setFacialExpression ( 6 x
of moest het nou drm.facialExpression = 6 x
Ik vind het verder wel een mooie taal.
Uiteraard. Maar is het niet verstandig om dat soort dingen gewoon achterwege te laten. Leer jezelf gestructureerd te coden, waarbij (dacht ik) goto het evilste van het evilste was.
Zit wat in....Sterker nog, je hebt gelijk
Uiteraard. Eigenlijk zelfde verhaal als "goto"
Als iemand me het uit kan leggen wat ze daar bedoelen, graagover embedded HTML
inderdaad nogal
Ik absoluut ook. Wat mij betreft introduceren ze het liever gister dan vandaag
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_exif()/u/7759/red_cat.gif?f=community)
Euhhh, ten 1e: (zoals curry684 al zei) je kan op het moment dat er iets is gevonden returnen.
En als je dat niet wilt is er na de goto opeens niet meer duidelijk of het nou gevonden was of niet. Dat is dus het probleem met goto:
Waar blijft nou het hele idee van beslissingen maken op grond van variabelen? Je mag NOOIT je informatie verliezen op basis van assumpties! Grootse fout in programmeren!
edit:typo
code:
1
2
3
4
5
6
7
8
9
| for ( int i = 0; i < numElements1; i++)
{
for ( int j = 0; j < numElements2; j++)
{
if (elements1[i] == elements2[j])
return true;
}
}
return false; |
En als je dat niet wilt is er na de goto opeens niet meer duidelijk of het nou gevonden was of niet. Dat is dus het probleem met goto:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| int i, j, k;
for (i = 0; i < numElements1; i++)
{
for (j = 0; j < numElements2; j++)
if (elements1[i] == elements2[j])
goto gevonden;
for (k = 0; k < numElements3; k++)
if (elements1[i] == elements3[j])
goto gevonden;
/*
etcetera (afgezien van code efficientie, maar goed)
*/
}
// hier code voor geval niet gevonden
...
/* Stel nou dat ik hier nog niet wil returnen... */
gevonden:
/* was het hier nou gevonden of niet? En wat was er gevonden? How the h*ll ga je dat traceren? */ |
Waar blijft nou het hele idee van beslissingen maken op grond van variabelen? Je mag NOOIT je informatie verliezen op basis van assumpties! Grootse fout in programmeren!
Amen
Zit wel wat in, maar vind ik ietwat overdreven. In grotere functies kan je idd beter aan de bools, maar in kleine overzichtelijke functies kun je net zo goed meerdere returns hebben.
edit:typo
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
Verwijderd
Debatable....
Ik blijf goto een zinnig functie vinden zolang de programmeur weet waar ie mee bezig is.
Als je niet weet waar je mee bezig bent is goto inderdaad niet altijd zinnig maar om het dan meteen algemeen te verdoemen...
Ach, die discussie is al eerder geweest, doe maar niet
Maar daarom zit die functie toch juist in de taal?!? Ik vind het behoorlijk conservatief om vanuit puristisch oogpunt functies in een taal niet te gebruiken. Liever tien returns dan vijftienhonderd zinloze booleans. Dan verlies ik pas het overzicht!
:strip_exif()/u/4143/crop673c629560e43_cropped.gif?f=community)
misschien is M$'s C# wat voor je.. eerste lezingen waren veelbelovend. Soort Java voor op de proc.Op maandag 03 september 2001 10:30 schreef beelzebubu het volgende:
[..]
Omdat alleen de algemene ideeen over de taal nog maar zijn bedacht. Er is nog geen praktische implementatie, protype model of zelfs maar een prototype-API te vinden.
Daar kan je dus als bedrijf nog niks mee.
Als het echt interessant is dan komt D vanzelf wel opzetten. Ik denk echter dat het voorlopig (komende 5 jaar) nog niks wordt. Het is namelijk door een persoon bedacht, niet door een standaard-/ISO-organisatie. Dan maak je niet veel kans vrees ik, in de grote wereld.
Tijdje geleden was er overigens ook een topic over D (geopend door /me *
(Jaja, M$ zijn na apers, ik weet het 
)
IOTDomotica op YT. Podcast bij Kophi: ook op YT.
Nee, want die booleans hebben namelijk functie, dus zolang jij ze op een slimme c.q. gestructureerde manier gebruikt zijn ze altijd beter dan de goto.beelzebubu:
[..]
Debatable....
Ik blijf goto een zinnig functie vinden zolang de programmeur weet waar ie mee bezig is.
Als je niet weet waar je mee bezig bent is goto inderdaad niet altijd zinnig maar om het dan meteen algemeen te verdoemen...
Ach, die discussie is al eerder geweest, doe maar niet
[..]
Maar daarom zit die functie toch juist in de taal?!? Ik vind het behoorlijk conservatief om vanuit puristisch oogpunt functies in een taal niet te gebruiken. Liever tien returns dan vijftienhonderd zinloze booleans. Dan verlies ik pas het overzicht!
En ik begrijp er helemaal niets van, dat goto nog in C, C++ en dus ook in D zit. Het verleidt je tot ongestructureerd programmeren. Het is gewoon een ongeschreven regel om geen goto te gebruiken. En er is geen enkele programmeur die het nodig heeft. Het is gewoon een lame uitkomst in alle gevallen.
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
Je kunt natuurlijk 1 bool declareren die EndLoop heet en deze 1500 keer recyclen...
Just a thought...
Verwijderd
""""ik heb geen mening over C#""""Op dinsdag 04 september 2001 10:17 schreef nigelator het volgende:
[..]
misschien is M$'s C# wat voor je.. eerste lezingen waren veelbelovend. Soort Java voor op de proc.
ofzo.....
(anders gaat dit topic dicht wegens overmatig geflame)
Verwijderd
Klopt op zichOp dinsdag 04 september 2001 10:50 schreef curry684 het volgende:
[..]
Je kunt natuurlijk 1 bool declareren die EndLoop heet en deze 1500 keer recyclen...
Just a thought...
Maar ook dan, dat sommige mensen "goto" irritant vinden, okee, kan ik inkomen. Maar return, daar kan ik dan ook echt niet iets van snappen.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| int search_in_array(int value, int array[], int array_length)
{
int i;
for (i=0;i<array_length;i++)
if (array[i]==value)
return i;
return -1; /* not found */
}
of
int search_in_array(int value, int array[], int array_length)
{
int i, j=-1;
for (i=0;i<array_length;i++)
if (array[i]==value)
{
j = i;
break;
}
return j;
} |
Dat is toch beiden 100% gestructureerd en duidelijk? Ik zie niet in wat er fout is met meerdere returns in een functie. De functie wordt er korter van en verder niet minder zinnig ofzo....
Nogmaals, in goto zie ik ook niets fout mits je het goed gebruikt, iets wat veel programmeurs niet kunnen. Maar ik zie wel in dat je het ongestructureerd zou kunnen vinden. Okee. Maar dat zie ik hier niet... Ik vind dat tweede voorbeeld onoverzichtelijker dan het eerste door de overmaat aan dubbele variabelen.
Of is "break" gebruiken ook onoverzichtelijk? En what about "continue"? Zeflde soort functies.....
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Het argument van de purist in deze is dat de eenduidige structuur verloren gaat: tegenover een single point of entry moet volgens deze leer EEN single point of exit staan. An sich voor sequence- en flowdiagrammen bepaald niet onlogisch overigens. Wel kut om te programmeren, en soms pijnlijk voor je performance.
Continue is een stuk onduidelijker als break, en voor de puristen ook verboden terrein. Break is legaal bij gratie van switch, waar je niet zonder kunt...
Overigens mag het ook bekend zijn dat puristen enkel en alleen langzame bank- en DB-applicaties schrijven en geen benul van snelheid hebben.
Verwijderd
Niet echt een overtuigend argument imhoOp dinsdag 04 september 2001 12:23 schreef curry684 het volgende:
Continue is een stuk onduidelijker als break, en voor de puristen ook verboden terrein. Break is legaal bij gratie van switch, waar je niet zonder kunt...
Dat zal ik lekker als excuss aanvoeren om heerlijk eigenwijs en antipuristisch gewoon lekker continue, break en return door de hele functie heen te gebruiken.Overigens mag het ook bekend zijn dat puristen enkel en alleen langzame bank- en DB-applicaties schrijven en geen benul van snelheid hebben.
Overigens, ik heb weleens geprobeerd me aan het "een return per functie" te houden maar de functie werd echt een ramp.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| functie()
{
if (...)
{
bladieblo();
if (...)
{
nogmeerbla();
if (...)
{
enzovoorts();
if (...)
{
en_hier_doet_de_functie_pas_wattie_moet_doen();
}
}
}
}
} |
al die if()s zijn nodig om het volgen van lege pointers enzo tegen te gaan. if (variable != NULL)... if (variable->bla > waarde).... enzovoorts. Ik kon ze ook niet echt in een if() kwijt....
Heel irri en onoverzichtelijk werd het allemaal. Uiteindelijk dus maar gewoon weer teruggegaan naar het heel-veel-returns-per-functie gebeuren, werd er een stuk overzichtelijker van
code:
1
2
3
4
5
6
7
8
9
10
11
12
| functie()
{
if (!...) return;
bladieblo();
if (!...) return;
nogmeerbla();
if (!...) return;
enzovoorts();
if (!...) return;
en_hier_doet_de_functie_pas_wattie_moet_doen();
} |
Ik bedoel maarOp dinsdag 04 september 2001 12:23 schreef curry684 het volgende:
Overigens mag het ook bekend zijn dat puristen enkel en alleen langzame bank- en DB-applicaties schrijven en geen benul van snelheid hebben.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
Op dinsdag 04 september 2001 12:23 schreef curry684 het volgende:
Break is legaal bij gratie van switch, waar je niet zonder kunt...
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| boolean = FALSE;
switch (value)
{
case 1:
if (!boolean)
{
boolean=TRUE;
bla1();
}
case 2:
if (!boolean)
{
boolean=TRUE;
bla2();
}
case 3:
if (!boolean)
{
boolean=TRUE;
bla3();
}
} |
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
Ik ben eigenlijk wel benieuwd naar de reden van deze afschuw van C# (althans, dat maak ik op uit je woordenbeelzebubu: """"ik heb geen mening over C#""""
(anders gaat dit topic dicht wegens overmatig geflame)
). Er ik al verscheidene mensen horen zeggen dat ze een hekel C# hebben, zonder dat ik er ooit over in discussie ben gegaan. Als je zware argumenten (met taal-details kan je altijd oneens zijn) kunt noemen ben ik daar erg benieuwd naar.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
:strip_exif()/u/6809/meshuggah.gif?f=community)
Je kunt je D-code in HTML zetten en hiermee "mooi" opmaken, en functies/methodes kun je links van maken naar andere classes (dus andere HMTLfiles) en deze HTML files kun je laten compilen, de compiler haalt dan alle HTML zooi weg.Op maandag 03 september 2001 14:08 schreef drm het volgende:
over embedded in HTML
Als iemand me het uit kan leggen wat ze daar bedoelen, graag
[..]
denk ik
interessant draadje btw
/edit
en toen zag ik de datum van de reply voor mij
A Breakbeat A Day Keeps Religion Away.
/u/27299/hoofd.png?f=community)
Beide fout.
Moet zijn code:
1
| std::find( array, array+array_length, value ); |
En ja, als ik een collega jouw oplossingen zie gebruiken dan laat ik hem dat wijzigen.
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
Typedefs mogen best van Stroustrup. Ik heb hem ze zelf zien gebruiken...Op vrijdag 31 augustus 2001 18:05 schreef Otis het volgende:
[..]
typedefs mogen strict genomen van straustrupp ook niet
Maar waar ik op doelde was: templates genereren code, maar welke is pas duidelijk zodra je de templates doorneemt. Dat kan lastig zijn (idem voor operator overloads). Te pas en te onpas gebruiken kan leesbaarheid verlagend zijn.
[..]
En teveel van alles gebruiken is slecht voor de leesbaarheid. Bv. (((((((((1)))))))))
Dat is nou net de ellende, dat alle constantes hetzelde type hebben. Waarom zou enum filetype( file, dir ) en enuminderdaad.
[..]
Als je typesafe constantes toelaat heb je geen enums nodig, want alle constante's hebben al een type. Enums zijn dan alleen 'handig' voor rijtjes. Meer niet.
accesstype( read, write ) hetzelfde type moeten hebben?
Als dat allebei ints zijn, dan kan ik file+read*2 doen.
Da's onzin. enum's zijn (ook) handig voor bitflags.
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
/u/19474/avatar2015.png?f=community){kind=avatar}
/u/2305/crop653618cca8542_cropped.png?f=community)
Verwijderd
Wat een negatieve sfeer hangt er om de postings heen zeg Voor mijn gevoel krijg ik het idee alsof jullie zwaar pissed off jullie replies intikken. Het zal vast aan de toon liggen, maar echt vriendelijk is het allemaal niet.
Voor mijn gevoel krijg ik het idee alsof jullie zwaar pissed off jullie replies intikken. Het zal vast aan de toon liggen, maar echt vriendelijk is het allemaal niet.
:strip_icc():strip_exif()/u/22964/amd.jpg?f=community)
Tja, dingen als dynamic allocation enzo, dat kent VB nou eenmaal niet, maar grote address spaces wel. Je kunt zonder problemen 4GB aan strings aanmaken. Als je tenminste genoeg geheugen hebt.
Ik weet niet precies hoe ODBC werkt (met directe function calls of met callbacks oid) maar als het met callbacks zou werken dan zou de bottleneck zitten in het feit dat een VB-engine een stukje tussencode moet gebruiken, terwijl C++ dat niet hoeft (VB hoort volgens M$ geen callbacks te ondersteunen, blijkbaar).
.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?
:strip_icc():strip_exif()/u/40949/polarwolf.jpg?f=community)
Verwijderd
Incorrect, er is een limitatie in het standaard win32 platform wat je adress space limiteerd tot 2GB, in de enterprise versie van NT4 is dit nog op te hogen naar 3GB maar dan dient de applicatie in z'n pe header wel aan te geven dat ie hier op voorbereid is. in de w2k versies (datacenter enzo) ligt deze limiet nog hoger maar ook daar geld dat je applicatie er op voorbereid moet zijn,in VB zit je gewoon aan max van 2GB.Op vrijdag 07 december 2001 13:30 schreef Xenophage het volgende:
Tja, dingen als dynamic allocation enzo, dat kent VB nou eenmaal niet, maar grote address spaces wel. Je kunt zonder problemen 4GB aan strings aanmaken. Als je tenminste genoeg geheugen hebt.
Juist, 2 GB, sorry Yarvieh, kwas ff beetje wazig. Jij niet blijkbaar, hoe doe je dat toch na een hele week?
Uhm maar ff weer on-topic, address space, hoe ging dat ook alweer, per thread, process of applicatie?
.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?
Verwijderd
Dat is geen punt, IPC mechnismen genoeg, gezien het hier over VB gaat ga je denk ik uit komen op (D)COM. Ander intresant punt is waarom zou iemand die applicaties maakt die zo geheugen intensief zijn VB gebruiken?!
Hum... you got me beat.Op vrijdag 07 december 2001 14:12 schreef Yarvieh het volgende:
[..]
Dat is geen punt, IPC mechnismen genoeg, gezien het hier over VB gaat ga je denk ik uit komen op (D)COM. Ander intresant punt is waarom zou iemand die applicaties maakt die zo geheugen intensief zijn VB gebruiken?!
Maar goed het ging mij erom dat je in VB gewoon de hele address space kunt gebruiken. Zowiezo zou ik voor geheugenintensieve programma's C/C++ gebruiken. VB is gewoon voor heej-ik-heb-binnen-2-dagen-een-programma-nodig-dat-ik-niet-zo-snel-in-C++-kan-bouwen oplossingen.
.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?