Archief - [PROG] [JAVA] galgje

Bubbling Zombie · 29 nov 2005

.Acku. zei:
Ben jij diegene die nog op school zit zonder professionele ervaring? Ja toch?

Ik zit ook op school, heb geen ervaring, en geef u gelijk. Dus nie veralgemenen e

Unzip Attack · 29 nov 2005

.Acku. zei:
Ben jij diegene die nog op school zit zonder professionele ervaring? Ja toch?

was jij degene die claimt dat wiskunde onbelangrijk is in informatica?

Unzip Attack · 29 nov 2005

killgore zei:
n/o, maar ik vraag me af wa gulle zit te kreften over String & StringBuffer. Qua gebruik zijn ze vrij evenwaardig, maar qua snelheid & geheugengebruik is StringBuffer zwaar de meerdere, daar kunde toch gewoonweg niet omheen ???

i don't give a damn fuck of da qua geheugengebruik sneller is, voor iemand die een BASIScursus java volgt is snelheid en geheugenverbruik gewoon het laatste waaraan gedacht moet worden

Bubbling Zombie · 30 nov 2005

Unzip Attack zei:
i don't give a damn fuck of da qua geheugengebruik sneller is, voor iemand die een BASIScursus java volgt is snelheid en geheugenverbruik gewoon het laatste waaraan gedacht moet worden

want? ge leert de persoon slechte gewoontes aan hoor :naughty:

.Acku. · 30 nov 2005

Unzip Attack zei:
was jij degene die claimt dat wiskunde onbelangrijk is in informatica?

Mooie nuance van je daar

DarkBone · 30 nov 2005

Unzip Attack zei:
i don't give a damn fuck of da qua geheugengebruik sneller is, voor iemand die een BASIScursus java volgt is snelheid en geheugenverbruik gewoon het laatste waaraan gedacht moet worden

Dan vraag ik u... wat ziet er logischer uit, zeker vanuit OO standpunt:

Code:

String str = new String ("Hello ");
str += "world!";

of

Code:

StringBuffer str = new StringBuffer ("Hello ");
str.append("world!");

Het gaat inderdaad wat ver om de bytecode te gaan uitspitten om aan te tonen dat er bij concatenatie van Strings intern een tijdelijke StringBuffer object wordt aangemaakt (en eigenlijk ook nog eens opnieuw een String object). Maar het kan toch heus geen kwaad om beginners op situaties als deze te wijzen en hen zo meteen de correcte manier aan te leren, het opent ogen.

Op zich vind ik het zelfs logischer dat er een methode wordt opgeroepen om te concateneren, dan dat er een operator gebruikt moet worden.

meeneemchinees · 30 nov 2005

Om toch even de bytecode te tonen :

Code:

String str = new String ("Hello ");
str += "world!";

Vertaalt zich als :

Code:

  L0
    NEW String
    DUP
    LDC "Hello "
    INVOKESPECIAL String.<init>(String) : void
    ASTORE 2: str
  L1 
    NEW StringBuffer
    DUP
    ALOAD 2: str
    INVOKESTATIC String.valueOf(Object) : String
    INVOKESPECIAL StringBuffer.<init>(String) : void
    LDC "world!"
    INVOKEVIRTUAL StringBuffer.append(String) : StringBuffer
    INVOKEVIRTUAL StringBuffer.toString() : String
    ASTORE 2: str

terwijl dit :

Code:

StringBuffer str = new StringBuffer ("Hello ");
str.append("world!");

vertaald wordt als

Code:

  L0
    NEW StringBuffer
    DUP
    LDC "Hello "
    INVOKESPECIAL StringBuffer.<init>(String) : void
    ASTORE 2: str
  L1
    ALOAD 2: str
    LDC "world!"
    INVOKEVIRTUAL StringBuffer.append(String) : StringBuffer
    POP

Unzip Attack · 30 nov 2005

DarkBone zei:
Dan vraag ik u... wat ziet er logischer uit, zeker vanuit OO standpunt:

Code:

String str = new String ("Hello "); str += "world!";

of

Code:

StringBuffer str = new StringBuffer ("Hello "); str.append("world!");

Het gaat inderdaad wat ver om de bytecode te gaan uitspitten om aan te tonen dat er bij concatenatie van Strings intern een tijdelijke StringBuffer object wordt aangemaakt (en eigenlijk ook nog eens opnieuw een String object). Maar het kan toch heus geen kwaad om beginners op situaties als deze te wijzen en hen zo meteen de correcte manier aan te leren, het opent ogen.

Op zich vind ik het zelfs logischer dat er een methode wordt opgeroepen om te concateneren, dan dat er een operator gebruikt moet worden.

Dat ziet er logischer uit :

Code:

String str = "hello";
str += "world!";

:ironic:

dat is de volgens mij de enige manier waarop imperatief proggen aangeleerd wordt. niet met objecten beginnen te prullen als je niet eens weet wat objecten zijn. beginners moeten zich niet bezig houden met de finesses, da's voor een volgende cursus. Spits je toe op de basis, dat is ,als je het perfect wil kunnen (inclusief recursie en heel de reutemeteut), al genoeg. Al die details kunnen later makkelijk nog aangeleerd worden. Stap per stap.

Nog een grappige opmerking van een vriend van mij, hij doet hogeschool en hij moest een oefening maken "bereken de absolute waarde van een getal". Eerst en vooral wist hij niet wat de absolute waarde was dus dat heb ik em eerst uitgelegd. Vervolgens probeerde hij maar hij slaagde er niet in :/ Anyway een andere vriend van hem komt binnen en reageert meteen "daar hebben we een functie voor gezien !"... Toen ik hun vroeg wat een algoritme was, kon geen van beiden een antwoord geven. Ze zijn nu sinds oktober bezig met java elke week 1 dag.
Dat bedoel ik met stap per stap, als je al gaat spreken over OO voor je nog maar weet wat een algoritme is en je al objecten gaat gebruiken nog voor je gewoon imperatief kan programmeren, ben je slecht bezig. Dat kun je draaien of keren hoe je wil, het blijft gewoon een feit.

Unzip Attack · 30 nov 2005

Bubbling Zombie zei:
want? ge leert de persoon slechte gewoontes aan hoor :naughty:

slechte gewoontes zitten ergens anders, in slechte commentaar, in slechte benamingen, in slechte algorimtes. Niet in het stap per stap leren.

DarkBone · 30 nov 2005

@Unzip Attack
Ik volg je redenering hoor, en mijn opmerking moet je inderdaad vanuit een OO perspectief bekijken. Maar ik ga akkoord dat eerst het imperatief programmeren moet aangeleerd worden. Zo is het trouwens ook exact gegaan in mijn hogeschool opleiding...

En terzijde, ik vind het maar erg gesteld dat men niet weet wat een absolute waarde is of dat men niet weet te verwoorden wat een algoritme is. Dan schort er ofwel iets aan de opleiding, ofwel aan de motivatie/bekwaamheid van de personen zelf... Ik heb het in ieder geval wel ooit als leerstof voorgeschoteld gekregen.

killgore · 30 nov 2005

Unzip Attack zei:
slechte gewoontes zitten ergens anders, in slechte commentaar, in slechte benamingen, in slechte algorimtes. Niet in het stap per stap leren.

Leer beginnende php-programmeurs aan dat ze gpc vars gewoon als gewone mogen gebruiken (dus $postvar ipv $_POST["postvar"] bv.) en ge krijgt dat er bijna niet meer uit (is dus grove fout).
Ik weet ook dat String<->Stringbuffer hier niet mee kan vergeleken worden, maar veralgemeen aub niet te snel

.

Ook vind ek de String-strinbuffer discussie wat verdraaid door de mensen die string gingen verdedigen

. Het ging eerst over algemeen gebruik en nu beginde over wat het beste is om java beginnen te leren.

Natuurlijk is String beter om gewoon te beginnen leren omdat het meer lijkt om een primitieve variabele. Wilt dit dan zeggen dat String beter is?
Totaal niet, in elke "gewone" toepassing zal iemand wel StringBuffer gebruiken.

En aan diegene die zei dat je je als beginnend programmeur niet druk moet maken over heap & zwaarte algoritme en zo. Voor wij nog maar 1 letter java hadden gezien hadden we al mooi hoofdstukje over algoritmes achter de rug waar complexiteit duidelijk werd in besproken. Zowel op vlak van uitvoeringstijd als van geheugengebruik (hoewel dat laatste minder

).

edit: dat van die absolute waarde en algoritme vind ek gewoon zielig. Als ge niet weet wat absolute waarde is kunde geen wiskunde (op die leeftijd toch) en dan moete ook geen informatica gaan doen imho.

Unzip Attack · 30 nov 2005

killgore zei:
Leer beginnende php-programmeurs aan dat ze gpc vars gewoon als gewone mogen gebruiken (dus $postvar ipv $_POST["postvar"] bv.) en ge krijgt dat er bijna niet meer uit (is dus grove fout).
Ik weet ook dat String<->Stringbuffer hier niet mee kan vergeleken worden, maar veralgemeen aub niet te snel .

die $postvar is puur syntax, dat werkt in sommige gevallen niet. Een string zal evengoed altijd werken. Nadien bij OO leren dat er een object is dat StringBuffer is en beter is, is toch helemaal geen ding dat je moet afleren ? gewoon een uitbreiding van je kennis, niets meer.

killgore zei:
Ook vind ek de String-strinbuffer discussie wat verdraaid door de mensen die string gingen verdedigen . Het ging eerst over algemeen gebruik en nu beginde over wat het beste is om java beginnen te leren.

wederom zever. Het ging over iemand die een oefening moest maken in een basiscursus en die we tips gaven. Het ging dus helemaal niet over algemeen gebruik, het ging over het feit wat je moet aanleren als eerste.
Ik zeg dat OO structuren niet thuishoren in imperatieve basiscursus.

killgore zei:
Natuurlijk is String beter om gewoon te beginnen leren omdat het meer lijkt om een primitieve variabele. Wilt dit dan zeggen dat String beter is?
Totaal niet, in elke "gewone" toepassing zal iemand wel StringBuffer gebruiken.

ik heb hier nergens beweerd, quote me als je tegendeel wil bewijzen, dat String technisch gezien beter is dan Stringbuffer. zodus jezelf nix inpraten...

killgore zei:
En aan diegene die zei dat je je als beginnend programmeur niet druk moet maken over heap & zwaarte algoritme en zo. Voor wij nog maar 1 letter java hadden gezien hadden we al mooi hoofdstukje over algoritmes achter de rug waar complexiteit duidelijk werd in besproken. Zowel op vlak van uitvoeringstijd als van geheugengebruik (hoewel dat laatste minder ).

dan kan ik voor 99% zeker zeggen dat je complexiteitscursus gewoon te vroeg kwam. da's in mijn ogen zowat de zwaarste cursus die er bestaat (niet voor nix dat em pas in 2de bach wordt gegeven en sommigen em 5a6 keer opnieuw doen.)
Hoe kun je in godsnaam gaan spreken over geheugenverbruik, complexiteit van algoritmen, bomen, heaps, grafen, np problemen en al die andere dingen zonder nog maar 1 zin uit een programmeercursus gehad te hebben.
Complexiteit is iets wat je achteraf moet leren, same for geheugenverbruik. Als je daar al in een 1ste basiscursus bent over aant spreken, ben je in mijn ogen gewoon verkeerd bezig. Wat is het probleem van zoiets achteraf te leren als je een globaler beeld hebt ?

edit: dat van die absolute waarde en algoritme vind ek gewoon zielig. Als ge niet weet wat absolute waarde is kunde geen wiskunde (op die leeftijd toch) en dan moete ook geen informatica gaan doen imho.

oh wat we hier horen, geen informatica gaan volgen als je geen wiskunde kan, vraag eens aan eerwaarde Acku wat hij daar van vindt...
*ik zie ze trouwens ook niet capabel om het te halen en vind het ook maar zielig, maar ik kan zeggen dat ze zeker geen uitzondering zijn...*

killgore · 30 nov 2005

Unzip Attack zei:
die $postvar is puur syntax, dat werkt in sommige gevallen niet. Een string zal evengoed altijd werken. Nadien bij OO leren dat er een object is dat StringBuffer is en beter is, is toch helemaal geen ding dat je moet afleren ? gewoon een uitbreiding van je kennis, niets meer.

Leer lezen: ik heb duidelijk gezegd dat ik het hier niet over string & stringbuffer had, maar zei dat je niet mocht veralgemenen

.
edit: ik bedoelde dus maar dat je wel degelijk verkeerde dingen kan aanleren die tot fout programmeren leiden. Ook al hebben ze niets met jouw zaken te maken. en gpc's als global var gebruiken is sinds php 4.2 al uit den boze & fout. maar spijtig genoeg kennen mensen de fout-afhandeler voor php niet

.

wederom zever. Het ging over iemand die een oefening moest maken in een basiscursus en die we tips gaven. Het ging dus helemaal niet over algemeen gebruik, het ging over het feit wat je moet aanleren als eerste.
Ik zeg dat OO structuren niet thuishoren in imperatieve basiscursus.

ik citeer:
"mijn soort code wordt TOEVALLIG door 95% van de programmeurs gebruikt,"
dit ging bij mijn weten niet over beginners :ironic:

ik heb hier nergens beweerd, quote me als je tegendeel wil bewijzen, dat String technisch gezien beter is dan Stringbuffer. zodus jezelf nix inpraten...

dan heb ik me toch zwaar mislezen en heel jullie discussie mis geïnterpreteerd

. Maar dat kan wel eens gebeuren in grotere discussies, dan zijn trouwens men bovenstaande argumenten ook niet meer relevant

.

dan kan ik voor 99% zeker zeggen dat je complexiteitscursus gewoon te vroeg kwam. da's in mijn ogen zowat de zwaarste cursus die er bestaat (niet voor nix dat em pas in 2de bach wordt gegeven en sommigen em 5a6 keer opnieuw doen.)
Hoe kun je in godsnaam gaan spreken over geheugenverbruik, complexiteit van algoritmen, bomen, heaps, grafen, np problemen en al die andere dingen zonder nog maar 1 zin uit een programmeercursus gehad te hebben.
Complexiteit is iets wat je achteraf moet leren, same for geheugenverbruik. Als je daar al in een 1ste basiscursus bent over aant spreken, ben je in mijn ogen gewoon verkeerd bezig. Wat is het probleem van zoiets achteraf te leren als je een globaler beeld hebt ?

Ik heb nooit gezeggd dat hij zo uitgebreid was als jij opnoemt, en geheugen hebben we (gelukkig

) vooral links laten liggen, onder het mom van: geheuge kost weinig

. Extra reden is dat geheugen nogal zwaar afhangt van prog-taal tot prog-taal.
We moeten echter van veel algoritmes een bovengrens e.d. gaan berekenen. Dit kwam echt niets te vroeg imho

. Mensen wisten nu tenminste wat programmeren is. Ipv ons idioot coden aan te leren hebben ze ons algoritmisch leren denken en daarna pas met de specifieke taal begonnen. En complexiteit van algoritmen (buiten geheugen dus) volgt hierop vrij logisch.
Met idioot coden bedoel ik: je krijgt probleem en begint als zot te coden ipv na te denken over het probleem

.

oh wat we hier horen, geen informatica gaan volgen als je geen wiskunde kan, vraag eens aan eerwaarde Acku wat hij daar van vindt...
*ik zie ze trouwens ook niet capabel om het te halen en vind het ook maar zielig, maar ik kan zeggen dat ze zeker geen uitzondering zijn...*

hiermee ga ik volledig akkoord

.

edit: ik wou me niet echt mengen in de discussie trouwens. Vond het gewoon belachelijk dat er gediscussieerd werd over String of StringBuffer nu beter is

, had echter geïnterpreteerd dat dit in het algemeen werd bedoelt.

En diegene die zei dat die .append() moest vermeden worden omdat je oop gebruikte zonder dat je echt aan het onderwerp zat: je hebt mssch gelijk, maar wat doe je dan met Math-functies, andere nodige string-functies waar geen overloaded operators voor zijn, ... ? Vind het uiteindelijk maar zwak argument aangezien je bij java zowat onmiddelijk al oop-elementen moet gaan gebruiken, ook al heb je nog niet expliciet oop gezien.

Unzip Attack · 30 nov 2005

killgore zei:
En diegene die zei dat die .append() moest vermeden worden omdat je oop gebruikte zonder dat je echt aan het onderwerp zat: je hebt mssch gelijk, maar wat doe je dan met Math-functies, andere nodige string-functies waar geen overloaded operators voor zijn, ... ? Vind het uiteindelijk maar zwak argument aangezien je bij java zowat onmiddelijk al oop-elementen moet gaan gebruiken, ook al heb je nog niet expliciet oop gezien.

Java kan je perfect imperatief zien, zonder ook maar 1 concept OO aan te raken.

Brando[n] · 1 dec 2005

Unzip Attack zou beter even zwijgen :ironic:

Unzip Attack · 1 dec 2005

Brando[n] zei:
Unzip Attack zou beter even zwijgen :ironic:

niet zolang er zever in pakskes wordt verkocht :ironic:

Massis · 1 dec 2005

Unzip Attack zei:
Nog een grappige opmerking van een vriend van mij, hij doet hogeschool en hij moest een oefening maken "bereken de absolute waarde van een getal". Eerst en vooral wist hij niet wat de absolute waarde was dus dat heb ik em eerst uitgelegd. Vervolgens probeerde hij maar hij slaagde er niet in :/ Anyway een andere vriend van hem komt binnen en reageert meteen "daar hebben we een functie voor gezien !"... Toen ik hun vroeg wat een algoritme was, kon geen van beiden een antwoord geven. Ze zijn nu sinds oktober bezig met java elke week 1 dag.

Xios Hogeschool in Diepenbeek, eerste jaar toegepaste informatica?

zit daar nu men 1e jaar TI ook, 4u praktijk java in de week en 2u theorie, mr het woord algoritme ben'k nog ni tegengekomen in mijne cursus...
('k heb wel ongeveer 'n idee wat het is mr om da precies uit te leggen...)

nu, hoe ge de absolute waarde van'n getal betekent weet'k wel nog net... zie het met abs() of gewoon wiskundig zelf...

Unzip Attack · 1 dec 2005

punkrockdude zei:
Xios Hogeschool in Diepenbeek, eerste jaar toegepaste informatica?

zit daar nu men 1e jaar TI ook, 4u praktijk java in de week en 2u theorie, mr het woord algoritme ben'k nog ni tegengekomen in mijne cursus...
('k heb wel ongeveer 'n idee wat het is mr om da precies uit te leggen...)

nu, hoe ge de absolute waarde van'n getal betekent weet'k wel nog net... zie het met abs() of gewoon wiskundig zelf...

weetje wat modulo is ? ook iets waar ze nog nooit van gehoord hadden... anyway ze zitte in phl

Bubbling Zombie · 1 dec 2005

Unzip Attack zei:
niet zolang er zever in pakskes wordt verkocht :ironic:

't grappige is dat de zever in pakjes alleen door jou als dusdanig ervaren werd, en de rest meestal akkoord gaat met de desbetreffende zever.

.Acku. · 1 dec 2005

Is vervelend dat je mijn commentaar over complexe hoger wiskunde veralgemeent naar alle wiskunde.
Is verzamelingenleer geen basisbeginsel van wiskundige logica?

Modulus, absolute waarden e.d zijn ASO kennis. Als mensen dat niet kennen is dat hun probleem, en dan zullen ze het aan de development kan van de informatica (kijk hoe ik R&D en analyse voor je vermijd).
De discussie ging hem bij over over complexe veldentheorie en andere theoretische ondingen waar wiskundigen spontaan van klaarkomen, maar ik niet, omdat ik het nut ervan niet zie voor de meerderheid van professionals in de ICT sector.

Als je het echt nodig hebt, zet er dan een wiskundige op. Het zal sowieso dan in de analytische fase zich bevinden, hij moet heus niet kunnen programmeren en zijn algoritmen kunnen makkelijk vertaald worden door echte informatici.
Ik betwijfel sowieso dat de grote geesten achter 3D-engines inforamtici zijn.

Archief - [PROG] [JAVA] galgje

Bubbling Zombie

Legacy Member

Unzip Attack

Legacy Member

Unzip Attack

Legacy Member

Bubbling Zombie

Legacy Member

.Acku.

Legacy Member

DarkBone

Legacy Member

meeneemchinees

Legacy Member

Unzip Attack

Legacy Member

Unzip Attack

Legacy Member

DarkBone

Legacy Member

killgore

Legacy Member

Unzip Attack

Legacy Member

killgore

Legacy Member

Unzip Attack

Legacy Member

Brando[n]

Legacy Member

Unzip Attack

Legacy Member

Massis

Legacy Member

Unzip Attack

Legacy Member

Bubbling Zombie

Legacy Member

.Acku.

Legacy Member