[Java/C] Programmeertaal leren - Java of C?

[Mithrandir]

Ik wil een programmeertaal gaan leren waarbij ik applicaties kan maken voor de lol.
Nu heb ik even rondgekeken, maar ik weet niet welke ik moet kiezen: C of Java?
Eerst zat ik ook nog te denken over Delphi, maar die taal trekt me niet echt. Ik weet niet waarom, maar ik vond 't nogal behelpen. Maf gevoel.

Wat ik al kan: ik prog wat PHP, en dus wat Delphi geprogd. Ook Basic geprobeerd, maar das geen win (32) programma.

Dus: wat zouden jullie mij aanraden? C(++/#?) of Java?
En welke boeken?

[edit]
Ik heb al gezocht, maar Java C leren had geen enkele hit.

[D2k]

[topic=374529/1/25]

[Mithrandir]

Op maandag 18 maart 2002 20:52 schreef D2k het volgende:
[topic=374529/1/25]

Dat is voor de boeken. Enig idee voor de taal?

[Verwijderd]

sja, wat wil je maken...

[Blue-eagle]

Ik zou beginnen met Java, omdat dat al wel object georienteerd is, en C is imo moeilijker te leren.

Daarbij, Java heeft iets meer dat exotische Maar dat moet niet toedragen aan je beslissing..

[Mithrandir]

Op maandag 18 maart 2002 20:53 schreef fladder het volgende:
sja, wat wil je maken...

Weet niet precies, maar inspiratie komt wel

Ik kan het ook anders zeggen: welke taal is goed all-round? Op veel vlakken inzetbaar? Ik ken de beginselen van PHP, maar aangezien ik er niets voor kan bedenken wil ik ook een client-side taal leren. C of Java dus.

[Mithrandir]

Op maandag 18 maart 2002 20:53 schreef Blue-eagle het volgende:
Ik zou beginnen met Java, omdat dat al wel object georienteerd is, en C is imo moeilijker te leren.

Daarbij, Java heeft iets meer dat exotische Maar dat moet niet toedragen aan je beslissing..

Exotische? Hmmz. Wat zijn de grote verschillen? Ja, Java is Objectgeorienteerd, maar verder?

Wat wordt eigenlijk het meest gebruikt? C toch?

[Orphix]

Op maandag 18 maart 2002 20:56 schreef DinoRaptor het volgende:

[..]

Exotische? Hmmz. Wat zijn de grote verschillen? Ja, Java is Objectgeorienteerd, maar verder?

Wat wordt eigenlijk het meest gebruikt? C toch?

Als je 'applicaties voor de lol' wilt maken ga ik uit van window applicaties. Dus een venster, buttons, enz.
In dit geval zou ik met Java aan de slag gaan, de taal is 'netter' en veel makkelijker icm met gebruik van een GUI. Bovendien heeft deze taal veel meer ingebouwde functies (of classes ) die het leven vergemakkelijken.

Wil je toch echt native win32 applicaties gaan maken dan moet je niet aan C maar eerder aan C++ gaan denken. Deze taal is icm met bv de MFC (relatief) makkelijker te gebruiken en ook heel krachtig. Voordeel is dat je direct de OO denkwijze aanleert. Nadeel is wel dat de taal een stuk complexer is dan Java en bovendien is 'ff' een GUI maken niet zo makkelijk.

[Mithrandir]

Op maandag 18 maart 2002 21:10 schreef Orphix het volgende:

[..]

Als je 'applicaties voor de lol' wilt maken ga ik uit van window applicaties. Dus een venster, buttons, enz.
In dit geval zou ik met Java aan de slag gaan, de taal is 'netter' en veel makkelijker icm met gebruik van een GUI. Bovendien heeft deze taal veel meer ingebouwde functies (of classes ) die het leven vergemakkelijken.

Wil je toch echt native win32 applicaties gaan maken dan moet je niet aan C maar eerder aan C++ gaan denken. Deze taal is icm met bv de MFC (relatief) makkelijker te gebruiken en ook heel krachtig. Voordeel is dat je direct de OO denkwijze aanleert. Nadeel is wel dat de taal een stuk complexer is dan Java en bovendien is 'ff' een GUI maken niet zo makkelijk.

Ja, ik bedoelde inderdaad windows applicaties.
GUI? ... User Interface?

Ik dacht dat Java vooral OO is. Waarom leer je dan met C de OO denkwijze dan sneller?

[Stephan Oudmaijer]

als je toch wat gaat leren leer dan C# en leer net .NET werken.

- c# lijkt veel op java
- is snel
- is de toekomst

Ik ben atm java programmeer @ een IT bedrijf, hoe graag ik java ook gebruik, C# gaat 'HET' worden vrees ik. En helemaal voor consumenten programma`s.

[Blue-eagle]

Op maandag 18 maart 2002 21:14 schreef DinoRaptor het volgende:

[..]

Ja, ik bedoelde inderdaad windows applicaties.
GUI? ... User Interface?

Ik dacht dat Java vooral OO is. Waarom leer je dan met C de OO denkwijze dan sneller?

* kruipt er ff tussen *
Omdat de syntax van C(++) naar mijn mening makkelijker te begrijpen is, vooral tegenover Java.
Maar het lijkt allemaal op elkaar. En zoals Orphix al zegt: Java heeft meer standaard classes tot z`n beschikking waarmee je heel veel relatief makkelijk kunt doen.

Maar het ligt helemaal aan hetgeen je wilt maken.

Waarom kies je eigenlijk niet voor .NET?

[Mithrandir]

Op maandag 18 maart 2002 21:17 schreef Blue-eagle het volgende:

[..]

* kruipt er ff tussen *
Omdat de syntax van C(++) naar mijn mening makkelijker te begrijpen is, vooral tegenover Java.
Maar het lijkt allemaal op elkaar. En zoals Orphix al zegt: Java heeft meer standaard classes tot z`n beschikking waarmee je heel veel relatief makkelijk kunt doen.

Maar het ligt helemaal aan hetgeen je wilt maken.

Tsjah... Welke dingen zijn nou specifiek die je kunt maken met de ene taal en welke met de andere? (Misschien wordt Wasigh zometeen ff wakker, of zo'n andere JavaHova )

[edit]
.net Ken 't van naam, niet van gezicht

[Blue-eagle]

Heb je al gepost op javahova?

[Orphix]

Op maandag 18 maart 2002 21:14 schreef DinoRaptor het volgende:

[..]

Ja, ik bedoelde inderdaad windows applicaties.
GUI? ... User Interface?

Ik dacht dat Java vooral OO is. Waarom leer je dan met C de OO denkwijze dan sneller?

Graphical User Interface

En het verschil was tussen C en C++, niet tussen C++ en Java (die beiden OO zijn)

Op maandag 18 maart 2002 21:18 schreef DinoRaptor het volgende:

[..]

Tsjah... Welke dingen zijn nou specifiek die je kunt maken met de ene taal en welke met de andere? (Misschien wordt Wasigh zometeen ff wakker, of zo'n andere JavaHova )

Nou in beide talen kan je heel veel dingen maken. Je kan netwerk-utilitys maken, spelletjes, calculator, webservice, html-editor,site-generator,CMS,etc,etc. Het enige wat in het nadeel van Java werkt is dat de GUI (en daarom bv ook minder geschikt voor games) trager is dan een app in C++. Dit komt omdat Java cross-platform werkt en een windows app (uiteraard) niet.

Ik wou in 1e instantie de keuze tussen Java en C uitleggen, maar nu het toch al genoemd is .. kijk ook naar .NET. Je hebt hier in
- Een moderne OO taal die veel op Java lijkt
- Een moderne ontwikkel omgeving (.NET framework)
- Je kan op het windows platform (makkelijk) COM objecten gebruiken en daardoor bv een HTML browser of een Mediaplayer _in_ je applicatie gebruiken.
- Je leert makkelijk om te gaan met XML, webservices en databases

Tja ik programmeer nu ook al een tijdje in C# en eerlijk is eerlijk, het staat als een dijk. Een genot om mee te werken.

Op maandag 18 maart 2002 21:19 schreef Blue-eagle het volgende:
Heb je al gepost op javahova?

lekker objectief ja

[Mithrandir]

Op maandag 18 maart 2002 21:19 schreef Blue-eagle het volgende:
Heb je al gepost op javahova?

nee. Zit wel op 't forum daar te kijken. Maar heb geen zin 2 topics bij te houden. En Wasigh & co komen hier ook

[Mithrandir]

Op maandag 18 maart 2002 21:26 schreef Orphix het volgende:

[..]

Graphical User Interface

En het verschil was tussen C en C++, niet tussen C++ en Java (die beiden OO zijn)
[..]

Nou in beide talen kan je heel veel dingen maken. Je kan netwerk-utilitys maken, spelletjes, calculator, webservice, html-editor,site-generator,CMS,etc,etc. Het enige wat in het nadeel van Java werkt is dat de GUI (en daarom bv ook minder geschikt voor games) trager is dan een app in C++. Dit komt omdat Java cross-platform werkt en een windows app (uiteraard) niet.

Ik wou in 1e instantie de keuze tussen Java en C uitleggen, maar nu het toch al genoemd is .. kijk ook naar .NET. Je hebt hier in
- Een moderne OO taal die veel op Java lijkt
- Een moderne ontwikkel omgeving (.NET framework)
- Je kan op het windows platform (makkelijk) COM objecten gebruiken en daardoor bv een HTML browser of een Mediaplayer _in_ je applicatie gebruiken.
- Je leert makkelijk om te gaan met XML, webservices en databases

Tja ik programmeer nu ook al een tijdje in C# en eerlijk is eerlijk, het staat als een dijk. Een genot om mee te werken.
[..]

lekker objectief ja

Hmmz... Ik heb het gevoel dat .net erg gehyped wordt. Er zijn toch ook nog niet (veel) boeken (en guru's ) voor? Dat is dus niet zo 'veilig' als de andere 2 talen.

Dat over spelletjes is wel belangrijk ja, want dat zijn natuurlijk leuke dingen om te maken.

[Blue-eagle]

Even een aanvulling op Orphix:

.NET ROELEERD!

Zo.. nu een paar random argumenten toevoegen :

• Visual Studio.NET heeft alles wat je wilt om goed aan de slag te kunnen
• Het is van Microsoft, ga er dus maar vanuit dat ze hun concept lekker doordrukken in deze wereld.. dit kan zowel een voor als een -nadeel zijn.
• Je hebt de keuze uit verschillende 'talen', bijvoorbeeld C# (c sharp) en VB.NET. Een ruime keuze uit syntax dus. Ikzelf ga voor VB. Omdat ik die via m`n ASP achtergrond gewend ben, met ASP progde ik ook altijd in VB. In jouw geval zal je C# willen, vanwege je PHP achergrond, lijkt me.
• Het is (bij mij tenminste) retesnel.
• Je leert goed werken met webservices en gestructureerde data, XML inderdaad. En in dit punt geloof ik dat MS heel goed bezig is.
• Mocht je ooit dat hele .NET je de keel uit komen, of mocht het enorm floppen (ik roep maar wat!) dan heb je genoeg ervaring om goed met andere talen (C,C++ etc) verder te kunnen gaan.

Ik zou het zeker even overwegen om naar te kijken. Het werkt gewoon erg goed. En niet dat C++ niet goed werkt, helemaal niet! Maar als je dan toch een keuze maakt, neem dan ook .NET in overweging.

[elnino]

Het verschil tussen C en Java is best groot, aangezien C een veel 'primitievere' taal is dan Java. Je hebt soms echt het idee dat je op hardwareniveau zit te programmeren (en dat is eigenlijk ook zo). Als je met pointers bezig bent, moet je wel heel erg precies gaan werken, zeker als je pointers met array's gaat combineren en dan adressen bij elkaar gaat optellen...

Java is daarentegen een taal waar je veel meer bezig bent met het probleem op te lossen dan overal met pointers werken. Voor beginners raad ik dan ook zeker eerder Java aan dan C.

Als je dan toch kiest voor C, dan kan je beter C++ gebruiken, want dat is 'verder ontwikkeld' en object-georiënteerd. Zeker voor het programmeren van GUI's raad ik Java aan, met C of C++ kan dat soms nog een heel gedoe worden.

Daarnaast kun je ook nog denken aan C#, de nieuwe taal van Microsoft voor het .NET-framework. Dat lijkt heel erg op (lees: is een kopie van) Java en sommige mensen vinden het beter dan Java. Ik heb er zelf nog niet mee gewerkt, dus ik kan hierover geen mening geven.

De .NET-strategie is vooral gebaseerd op XML-structuren en XML-Web Services en voor grote enterprise toepassingen is dat een grotere verbetering. Of de huis/tuin/keuken-programmeur er ook gebruik van zal gaan maken, weet ik niet. Veel mensen blijven dan liever bij het 'oude vertrouwde' VB, Delphi, C++ of Java.

Het hangt er dus vooral vanaf welke kant je op wilt gaan...

[MisterData]

* MisterData is completely into Java
Java = schoner dan C# imho, en makkelijker dan C(++).
Ach waarom niet gelijk ASM

[Verwijderd]

Java, absoluut. C is moeilijk om in één keer te leren en is voor "simpele applicaties" (warbij ik dan denk aan een schermpje met knopjes e.d.) overkill... C is handig voor realtime applicaties, maar voor het simpele werk is java vaak wat makkelijker en mooier...

Overigens, /me is C zealot Maar ik heb ook eerst java geleerd en daarna pas C, en daar heb ik veel van geleerd. Vooral OO leren denken is verschrikkelijk belangrijk en handig.

[stylee]

MisterData: Java = schoner dan C# imho

IMHO is juist DIT het grote nadeel van java. Puur de reden dat ik de taal C kies boven Java is dat ik in C precies kan doen wat ik wil, wanneer ik wil zonder me druk hoeven te maken om een of andere VM die persé iets op een bepaalde manier gedaan wil hebben, of zonder dat ik allerlei gekke truukjes (zoals interfaces) moet gaan toepassen om allerlei vage combinaties van classes en geheugenblokjes (owja zo mag ik ze niet noemen in java ) aan elkaar te lijmen.

Lees wel: ik heb het over de taal C, en niet over het platform (ja ik weet dat C geen platform heeft zoals java maar voor nu houden we het maar ff op de standaard C-library). Java heeft zo een uitgebreide klassenbibliotheek dat het in deze dagen gewoon *dom* is om eromheen proberen te draaien.

No offence aan de hardcode OOP'ers, maar slimme programmeurs schrijven mooie code en hebben hier geen 'schone' taal voor nodig. Wil dit zeggen dat ik je aanraad om C te gaan leren ipv. Java? Nee, integendeel.

Maar ik ben wel sterk van mening dat je zoiezo een goede kennis van C (pointers, arrays, structures) moet hebben als programmeur, omdat dit toch wel de basis is waar het gros van alle talen op doorbouwt (en ook Java dus).

Persoonlijke mening: mijn persoonlijke advies zou zijn om C# te gaan leren. Het is een prachtige taal van MS en biedt IMO de 'schoonheid' van java met de 'ruwheid' van C (er zitten zelfs pointers bij, alhoewel niet echt nodig). Kiezen voor C# (dus: .NET) is best verstandig omdat je dan niet alleen een bepaalde taal leert maar ook technieken zoals werken met XML, webservices, etc (zoals *Orphix* al zei).

edit: nu ik dit doorlees ziet het er een beetje als spaghetti uit maar ik hoop dat ik mijn punt duidelijk heb gemaakt

[Orphix]

Op maandag 18 maart 2002 21:58 schreef stylee het volgende:
No offence aan de hardcode OOP'ers, maar slimme programmeurs schrijven mooie code en hebben hier geen 'schone' taal voor nodig. Wil dit zeggen dat ik je aanraad om C te gaan leren ipv. Java? Nee, integendeel.

Wat is mooie code, probeer jij maar eens elegant een event-based GUI te maken in C. Dit zal er niet elegant uit komen te zien. Maar tuurlijk is het wel mogelijk om elegant matrix verwerkingen (en waarschijnlijk ook efficienter) te doen in C.

Maar ik ben wel sterk van mening dat je zoiezo een goede kennis van C (pointers, arrays, structures) moet hebben als programmeur, omdat dit toch wel de basis is waar het gros van alle talen op doorbouwt (en ook Java dus).

Ik ben zelf ook na basic en heel summier delphi op C en zodoende pointers e.d. geleerd. Het kan heel nuttig zijn om te weten hoe iets intern werkt, of dat je weet wat je mist. Ik heb nooit assembly geleerd en ik merk dat het in sommige gevallen (in C) best handig zou kunnen zijn om te bepalen hoe je dingen zo efficient (vooral met caching en pipelining in het oog houdend) kan schrijven.
Maar het is niet noodzakelijk. De VB programmeur kan zich absoluut redden en de functionaliteit van een programma wordt er niet minder op als je geen pointers zou gebruiken.

Kiezen voor C# (dus: .NET) is best verstandig omdat je dan niet alleen een bepaalde taal leert maar ook technieken zoals werken met XML, webservices, etc (zoals Otis al zei).

edit: nu ik dit doorlees ziet het er een beetje als spaghetti uit maar ik hoop dat ik mijn punt duidelijk heb gemaakt

Maakt niet uit, dat zijn we gewend van C-programmeurs (NOFI)

[farlane]

Op maandag 18 maart 2002 22:09 schreef Orphix het volgende:
Maakt niet uit, dat zijn we gewend van C-programmeurs

Haahahahahahhaaaa..... (soz, kon het niet laten )

[stylee]

Orphix: Wat is mooie code, probeer jij maar eens elegant een event-based GUI te maken in C. Dit zal er niet elegant uit komen te zien. Maar tuurlijk is het wel mogelijk om elegant matrix verwerkingen (en waarschijnlijk ook efficienter) te doen in C.

Uiteraard, maar met elegantere code bedoelde ik meer iets in deze (no offence Alarmnummer, puur ter illustratie ) manier van programmeren. Dit zie je erg vaak bij java programmeurs. Een nette en elegante oplossing proberen te bedenken voor een probleem waarvoor je evengoed een 3 regelige spaghetti-oplossing had kunnen bedenken die een beetje programmeur toch wel snapt. Hier komt het voorbeeld van de iteratievariabele in me op. Waarom zou je dit schrijven:

code:

while (myCounterVar++ < 10) { ; }

ipv.

code:

while (i++ < 10) { ; }

Iedereen snapt toch wel dat die i een simpele counter-var is

Ik heb nooit assembly geleerd en ik merk dat het in sommige gevallen (in C) best handig zou kunnen zijn om te bepalen hoe je dingen zo efficient (vooral met caching en pipelining in het oog houdend) kan schrijven.

Idem ditto, hier doelde ik dus op toen ik zei dat je toch een stukje C-basiskennis dient te hebben.

Maar het is niet noodzakelijk. De VB programmeur kan zich absoluut redden en de functionaliteit van een programma wordt er niet minder op als je geen pointers zou gebruiken.

Helemaal mee eens. Maar feit blijft dat ik behoorlijk wat huis-tuin-en-keuken VB programmeurs ken die niet weten wat een stack of een buffer is (ze kennen het principe wel, maar hebben niet door dat het zo heet). Toch wel een paar van de basisdingetjes die je als programmeur moet bezitten. Beginnen met een taal als C dwingt je om dit soort kennis tot je te nemen, en vaak schrijf je zelfs je eigen simpele implementatie ervan om te gebruiken in je eigen code (goede oefening).

Je moet niet vergeten dat waar C staat je het beter kan vervangen door C++. Alhoewel in essentie hetzelfde zijn er toch wat fundamentele verschillen (nee ik heb het niet over OOP, maar puur de taal). En C++ is backwards compatible dus elke C programma is in feite een C++ programma (volgens de standaard dan.. )

[Alarmnummer]

Op maandag 18 maart 2002 21:58 schreef stylee het volgende:
MisterData: Java = schoner dan C# imho

IMHO is juist DIT het grote nadeel van java. Puur de reden dat ik de taal C kies boven Java is dat ik in C precies kan doen wat ik wil, wanneer ik wil zonder me druk hoeven te maken om een of andere VM die persé iets op een bepaalde manier gedaan wil hebben

Wil je ons uitleggen wat de vm dan zo graag gedaan wil hebben? Daar ben ik zeer nieuwschierig na. Garbage collection is fijn, omdat ik me bezig kan houden met de echte problemen ipv te zoeken naar memory leaks.

of zonder dat ik allerlei gekke truukjes (zoals interfaces) moet gaan toepassen om allerlei vage combinaties van classes en geheugenblokjes (owja zo mag ik ze niet noemen in java ) aan elkaar te lijmen.

Dat komt omdat je java benaderd op een c manier en dus schijnbaar niets afweet van object georienteerd programmeren. In c++ heb je multiple inheritance en dat brengt een aantal nadelen met zich mee. In java hebben ze multiple inheritance ingebouwd dmv interfaces, en ik bewonder nog steeds de schoonheid van een interface. Dus aub geen gezeur over interfaces als je er niets over weet.

No offence aan de hardcode OOP'ers, maar slimme programmeurs schrijven mooie code en hebben hier geen 'schone' taal voor nodig.

Met een schone taal kan een programmeur zich bezig houden met de echte problemen ipv de problemen van de taal. Ga jij maar eens proberen om een pointer fout in je c code op te zoeken.

Maar ik ben wel sterk van mening dat je zoiezo een goede kennis van C (pointers, arrays, structures) moet hebben als programmeur, omdat dit toch wel de basis is waar het gros van alle talen op doorbouwt (en ook Java dus).

Dat ben ik wel met je eens. De meeste beginnende java proggers die gaan meteen aan de ActionListeners, Buttons en Server terwijl ze nog niet eens het minste afweten van de basis kennis. Ik zou dan ook iedere beginner pascal aanraden

Persoonlijke mening: mijn persoonlijke advies zou zijn om C# te gaan leren. Het is een prachtige taal van MS en biedt IMO de 'schoonheid' van java met de 'ruwheid' van C (er zitten zelfs pointers bij, alhoewel niet echt nodig). Kiezen voor C# (dus: .NET) is best verstandig omdat je dan niet alleen een bepaalde taal leert maar ook technieken zoals werken met XML, webservices, etc (zoals *Orphix* al zei).

In de meeste talen zijn intussen wel XML libraries te krijgen. Als je met XML aan de slag wilt kun je met bijna iedere taal wel uit de voeten. En XML moet je pas doen nadat je normaal hebt leren proggen.

Ik denk dat het in principe niet zoveel uitmaakt in welke taal je gaat leren proggen. In eerste instantie moet je de basis dingen leren, functies/procedures forlusjes/while lusjes if else statements, arrays etc etc. En deze basis principes vind je in iedere taal weer terug. Ik raad je eerlijk gezegd c af omdat dit onnodig cryptisch is persoonPtr->voornaam (c) tov persoon.voornaam (java). En ik zou in het begin ook niet meteen met oo aan de slag gaan. Je hebt tenslotte om oo te leren programmeren ook kennis nodig over procudureel te leren proggen. Ik zou dan gaan voor pascal afzo. Deze taal is speciaal ontwikkeld om studenten te leren proggen.

ps: ik heb vroeger veel in pascal,c en wat asm geprogged en ik zou van mijn levensdagen daar geen regel weer in willen proggen. Maar om een basis te leggen is vooral pascal een erg goeie kandidaat (alhoewel het niet echt motiverend is omdat het een vrij dooie taal is). Maar zonder goeie basis ben je nergens! Dus laat je niet verleiden tot allerlei zoetsappigheden van allerlei talen maar leer eerst de basis dingen.

[stylee]

Alarmnummer: ...

Het schijnt dat je het aanhalen van die ene posting van jou toch nog ietsje persoonlijker opvat. Mijn excuses hiervoor.

Ik reageer liever niet op jouw vragen simpelweg omdat we hier jarenlang over kunnen discussiëren en dit dan toch weer ontaard in een Java vs C(++) topic, dat is niet de bedoeling. Wat is schreef is puur persoonlijke voorkeur, niks meer, niks minder.

[mbravenboer]

of zonder dat ik allerlei gekke truukjes (zoals interfaces) moet gaan toepassen om allerlei vage combinaties van classes en geheugenblokjes (owja zo mag ik ze niet noemen in java ) aan elkaar te lijmen.

Wat is er mis met interfaces (taal-onafhankelijk)

Interfaces zijn niet alleen een work-around voor een al dan niet gebrek aan multiple-inheritance van implementatie... Interfaces vormen voor een groot deel de basis van polymorphisme in een OO-programmeertaal.

Ze zouden imho veel meer gebruikt moeten worden, zeker 'atomaire' interfaces met bijvoorbeeld maar 1 of 2 functies. In de Java library zou ik bijvoorbeeld veel meer interfaces willen zien en ik gruwel van de opmerking in Microsoft's C# coding-guidelines dat je in veel gevallen tbv onderhoud beter abstracte klassen dan interfaces kan gebruiken....

[Alarmnummer]

Op maandag 18 maart 2002 23:46 schreef stylee het volgende:
Alarmnummer: ...

Het schijnt dat je het aanhalen van die ene posting van jou toch nog ietsje persoonlijker opvat. Mijn excuses hiervoor.

Ik reageer liever niet op jouw vragen simpelweg omdat we hier jarenlang over kunnen discussiëren en dit dan toch weer ontaard in een Java vs C(++) topic, dat is niet de bedoeling. Wat is schreef is puur persoonlijke voorkeur, niks meer, niks minder.

Ik vond c ook een prachtige taal en java vond ik bagger (zelfde categorie als delphi en vb ) Maar door de tijd heen ben ik er er *moet even slikken* verliefd op geworden

Ik heb het verder niet persoonlijk opgevat maar ik maakte een paar opmerkingen over wat je zei en wat ik vroeger (voor ik verlicht was) ook over java zei. Ik ben nu op een hele andere manier met proggen bezig dan een paar jaar geleden, en ik doe dingen waar ik een tijd geleden het nut totaal niet van inzag en moest lachen om de omslachtige aanpak. Tegenwoordig vind ik zo nu een potje bitneuken wel leuk om te doen, maar voor het grote werk (en dan bedoel ik applicatie ontwikkeling) vind ik c te ouderwets. Maarja.. dat is mijn mening.

[Alarmnummer]

Op dinsdag 19 maart 2002 00:09 schreef mbravenboer het volgende:
In de Java library zou ik bijvoorbeeld veel meer interfaces willen zien en ik gruwel van de opmerking in Microsoft's C# coding-guidelines dat je in veel gevallen tbv onderhoud beter abstracte klassen dan interfaces kan gebruiken....

*rolt van zijn stoel af van verbazing*

Interfaces zijn geweldig omdat je niet vast zit aan een basis classe en je dus alles kan inrichten zoals jij het wil hebben. Ik vind dit niet echt (lees: echt niet) een slimme zet van ms.

[mbravenboer]

Alarmnummer: *rolt van zijn stoel af van verbazing*

Om het verhaal duidelijker te maken nog even de reden die in dat docje staat: als je een interface uitbreidt zijn alle implementaties de lul: zij moeten ook de nieuwe methoden gaan implementeren. Dat vormt een probleem voor onderhoud. Als je abstracten klassen gebruikt kan je een implementatie opnemen.

Das dus onzin imho. Er is helemaal niets op tegen (zelfs aan te bevelen) om van een interface een abstracte of default implementatie te maken die wat standaard functionaliteit implementeert. Je kunt daarom veel beter profiteren van de voordelen van beide systemen: overerving van implementatie via de abstracte klasse en daarbij gelijk implementatie van een interface. Als implementaties toch alleen de interface implementeren, moeten ze uitbreidingen van de interface zelf maar oplossen: kennelijk is het vereiste gedrag zo afwijkend dat overerving van een abstracte of default implementatie sowieso kansloos was geweest.

IMHO is polymorphisme via een interface sowieso veel fraaier dan polymorphisme via het implementeren van abstracte klassen of overriding van methoden. Generieke operaties opereren namelijk niet op basis van een implementatie, maar op basis van generiek te behandelen objecten. Hoe je deze objecten kunt behandelen, druk je uit in een interface...

C vind ik overigens een prachtige taal, maar dan voornamelijk om naar te compileren ipv assembly .

[reinouts]

[edit]
Ik heb al gezocht, maar Java C leren had geen enkele hit.

http://www.leren.nl/rubriek/computers_en_internet/software_ontwikkelen/

[Alarmnummer]

Op dinsdag 19 maart 2002 00:35 schreef mbravenboer het volgende:

[..]

Om het verhaal duidelijker te maken nog even de reden die in dat docje staat: als je een interface uitbreidt zijn alle implementaties de lul: zij moeten ook de nieuwe methoden gaan implementeren. Dat vormt een probleem voor onderhoud. Als je abstracten klassen gebruikt kan je een implementatie opnemen.

Daarvoor maak ik tegenwoordig soms gebruik van adapters. En ik laat een hulp object extenden van die adapter en dan ben ik ook af van extra functies in je interface. (Ik doe het vooral bij het visitor design pattern ivm toegevoegde 'types').

C vind ik overigens een prachtige taal, maar dan voornamelijk om naar te compileren ipv assembly .

hmmm...
int **p;
hier doen we het voor

[Bobco]

Op maandag 18 maart 2002 21:35 schreef Blue-eagle het volgende:

• Visual Studio.NET heeft alles wat je wilt om goed aan de slag te kunnen
• Het is van Microsoft, ga er dus maar vanuit dat ze hun concept lekker doordrukken in deze wereld.. dit kan zowel een voor als een -nadeel zijn.
• Je hebt de keuze uit verschillende 'talen', bijvoorbeeld C# (c sharp) en VB.NET. Een ruime keuze uit syntax dus. Ikzelf ga voor VB. Omdat ik die via m`n ASP achtergrond gewend ben, met ASP progde ik ook altijd in VB. In jouw geval zal je C# willen, vanwege je PHP achergrond, lijkt me.
• Het is (bij mij tenminste) retesnel.
• Je leert goed werken met webservices en gestructureerde data, XML inderdaad. En in dit punt geloof ik dat MS heel goed bezig is.
• Mocht je ooit dat hele .NET je de keel uit komen, of mocht het enorm floppen (ik roep maar wat!) dan heb je genoeg ervaring om goed met andere talen (C,C++ etc) verder te kunnen gaan.

Wat kost VS.NET nu eigenlijk? Niet dat ik roomser dan de paus ben voor wat betreft licenties, maar het is wel een punt van overweging. Als je voor Java kiest is het mogelijk om een complete ontwikkelomgeving in te richten zonder ook maar een cent aan licenties uit te geven.

Verder is misschien platform-onafhankelijkheid ook wel leuk. Op dit moment is Java de enige serieuze kandidaat als het gaat om het ontwikkelen van Java-apps. We doen het hier ook: ontwikkelen op NT en draaien op Solaris.

Verder zijn er voor Java een paar open source projecten bezig om je vingers bij af te likken. Kijk maar eens bij Jakarta.

Webservices en dat soort dingen kun je prima implementeren in Java, maar dat zou niet het eerste zijn om te proberen als je net een nieuwe taal leert.

Sterk punt van Java vind ik ook de tooling er omheen: JavaDoc is voor mij onmisbaar en het maakt veel indruk op managers als je binnen 30 seconden een enorme bak documentatie weet te genereren die ook nog klopt.

Maar goed, ieder z'n smaak, en zeker als het gaat om programmeertalen/ontwikkelomgevingen.

[Verwijderd]

Op maandag 18 maart 2002 22:09 schreef Orphix het volgende:
Wat is mooie code, probeer jij maar eens elegant een event-based GUI te maken in C. Dit zal er niet elegant uit komen te zien. Maar tuurlijk is het wel mogelijk om elegant matrix verwerkingen (en waarschijnlijk ook efficienter) te doen in C.

Dit is gelul. Gtk+ en XFree86, beiden puur C, zijn event-based en die gebruik ik al jaren om mijn GUIs in te progselen. Tuurlijk heeft C events, we zijn niet gek! 't zit alleen niet in de standaard ANSI C lib, maargoed, wat verwacht je dan, die is miljoen keer kleiner dan die van java (en miljoen keer sneller )

[edit]
Zie de CVS of je de code mooi vind, ik vind de code prachtig mooi

[whoami]

DinoRaptor:Hmmz... Ik heb het gevoel dat .net erg gehyped wordt. Er zijn toch ook nog niet (veel) boeken (en guru's ) voor? Dat is dus niet zo 'veilig' als de andere 2 talen

Er zijn al heel wat resources beschikbaar over .Net. Zowel boeken als online tutorials. Dan is er nog het belangrijk gegeven dat .Net van Microsoft is, en MS nu eenmaal het grootste software bedrijf is en de belangrijkste leverancier van besturingssystemen voor op de desktop en die zullen dus in hun latere versies van Windows het .Net framework wel integreren.
Microsoft staat volledig achter .Net en is machtig genoeg om ervoor te zorgen dat andere softwarebedrijven zich ook op .Net zullen richten.

elnino:Daarnaast kun je ook nog denken aan C#, de nieuwe taal van Microsoft voor het .NET-framework. Dat lijkt heel erg op (lees: is een kopie van) Java en sommige mensen vinden het beter dan Java. Ik heb er zelf nog niet mee gewerkt, dus ik kan hierover geen mening geven.

C# lijkt inderdaad op Java maar het is wel wat overdreven om te zeggen dat het een kopie is. Er zijn heel wat zaken anders geimplementeerd in C#. Bv het eventmodel, de mogelijkheid om pointers in uw code te gebruiken (wat dan wel de zogeheten 'unsafe code' oplevert), ... Je kunt C# eerder beschouwen als een mix van C++, Java en Delphi.

De .NET-strategie is vooral gebaseerd op XML-structuren en XML-Web Services en voor grote enterprise toepassingen is dat een grotere verbetering. Of de huis/tuin/keuken-programmeur er ook gebruik van zal gaan maken, weet ik niet. Veel mensen blijven dan liever bij het 'oude vertrouwde' VB, Delphi, C++ of Java.

Je kan ook perfect .Net applicaties ontwikkelen zonder gebruik te maken van XML. Alles wat je mbhv het oude VB, Delphi, Java... kunt, is ook mogelijk in .Net (C#, VB.NET).

Stylee:Maar ik ben wel sterk van mening dat je zoiezo een goede kennis van C (pointers, arrays, structures) moet hebben als programmeur, omdat dit toch wel de basis is waar het gros van alle talen op doorbouwt (en ook Java dus).

Hier ben ik het wel mee eens. Het is belangrijker dat je eerst leert programmeren en dat je kennis hebt van de basisstructuren. Dat is veel belangrijker dan eerst één bepaalde taal te leren en die volledig onder te knie te hebben. Als je leert programmeren en de basisbeginselen kent, zul je veel sneller een taal aanleren en ook gemakkelijker kunnen overstappen naar een andere taal.

Alarmnummer:In c++ heb je multiple inheritance en dat brengt een aantal nadelen met zich mee.

Welke nadelen? Ik vind dit eigenlijk wel jammer dat ze multiple inheritance uit Java en C# gestript hebben. Ik zie er niet direct nadelen in. Het kan alleen maar handig zijn.

mbravenboer:Interfaces zijn niet alleen een work-around voor een al dan niet gebrek aan multiple-inheritance van implementatie... Interfaces vormen voor een groot deel de basis van polymorphisme in een OO-programmeertaal.

Hoezo? Polymorphisme is toch gewoon 'late binding'? Er wordt at runtime bepaald welke functionaliteit er moet uitgevoerd worden. Mbhv interfaces kun je wel verschillende functionaliteit aan functies gaan geven per class, maar je hebt toch niet perse interfaces nodig om tot polymorphisme te komen. Ik zie dit niet als de basis voor polymorphing. Inheritance en virtual functions zijn de basisblokken voor polymorphisme.
(Na het lezen van uw 2de post ivm polymorphisme mbhv inheritance van abstract classes en polymorphisme mbhv interfaces snap ik nu wel meer wat je bedoelt.


En nu nog even mijn mening:
Ik zou niet gaan voor C, omdat je hier niet OO kunt programmeren en je dus 'vast' zit in een procedurele taal. Je kan dan natuurlijk voor C++ opteren, omdat je hier volgens mij het meest kunt leren qua programmeren, Classes, structures, pointers, ... Het nadeel van C++ tov Java/C# is dan wel dat je je ook meer met de taal zelf moet bezig houden dan met het oplossen van het probleem waarvoor je uw programma schrijft.
Als je twijfelt tussen Java en C#, dan zou ik voor C# opteren als je enkel voor het Windows platform wilt ontwikkelen. Wil je ook voor Linux/Unix ontwikkelen dan zou ik Java verkiezen.
Zelf ben ik momenteel bezig met .Net en C# en daarvoor heb ik eventjes van Java geproefd.
Persoonlijk hou ik meer vn C# dan van Java. Zo vind ik bv het event-model in C# beter/mooier dan dat in Java maar dat komt waarschijnlijk door m'n Delphi achtergrond.

.Net zal voor de Windows-ontwikkeling zeer belangrijk gaan worden. In de toekomst zullen de meeste Windows applicaties op het .net platform gaan draaien.

[Alarmnummer]

vb vervelende multiple inheritance.

code:

class Persoon{
   public void doIets(){
     System.out.println("eet");
   }
}

class Raket{
   public void doIets(){
     System.out.println("ontplof");
   } 
}

class RaketPersoon extends Persoon,Raket{
}

RaketPersoon raketPersoon = new RaketPersoon();
raketPersoon.doIets(); //wat krijg je nu op je scherm?

[Mithrandir]

Ik heb nu alle posts gelezen, en heel veel dingen gezien waar ik niets van snap (polyformisme ), maar de algemene lijn is dus: C(++) -- Java? Java kiezen. C# -- Java? C# kiezen.

Ik denk dat ik me ga verdiepen in C#: ook omdat dat beter geschikt is voor het programmeren van spellen.

* Mithrandir gaat nu op zoek naar info. Danx voor een link die iemand hierboven heeft gegeven.

[Alarmnummer]

Je moet eerst goed leren proggen (zoals iedereen opmerkt). Dus for lusjes, while lusjes, if else commando`s. Dan functies en procedures, geheugen structuren: records en arrays en dan dynamische structuren.

Daarna pas oo... als je geen goeie basis hebt dan ben je echt nergens. Ik zou me dus nog niet meteen toeleggen op het maken van spelletjes, maar eerst simpele dingen zoals tafels afdrukken.

[Verwijderd]

Op dinsdag 19 maart 2002 11:19 schreef DinoRaptor het volgende:
C# -- Java? C# kiezen.

Dan heb je het niet goed gelezen

Ik denk dat ik me ga verdiepen in C#: ook omdat dat beter geschikt is voor het programmeren van spellen.

Dan is het goed

edit: Wat Alarmnummer zegt is natuurlijk ook waar.

[Verwijderd]

Op dinsdag 19 maart 2002 11:14 schreef Alarmnummer het volgende:
vb vervelende multiple inheritance.

code:

code code code // wat krijg je nu op je scherm?

In C++ een ambiguity error bij het compilen. Netjes toch?

[Alarmnummer]

Op dinsdag 19 maart 2002 11:59 schreef Sneechy het volgende:

[..]

In C++ een ambiguity error bij het compilen. Netjes toch?

dat is heel netjes, maar als je het toch zou willen?? Hoe krijg je het dan voor elkaar?

[whoami]

Op dinsdag 19 maart 2002 12:02 schreef Alarmnummer het volgende:

[..]

dat is heel netjes, maar als je het toch zou willen?? Hoe krijg je het dan voor elkaar?

Zo :

code:

raketPersoon.Raket::doeIets();

of

code:

raketPersoon.Persoon::doeIets();

[Verwijderd]

Op dinsdag 19 maart 2002 12:02 schreef Alarmnummer het volgende:
dat is heel netjes, maar als je het toch zou willen?? Hoe krijg je het dan voor elkaar?

Als aanvulling op de methode die whoami hierboven noemt, is het uiteraard ook mogelijk om in de (derived) class body aan te geven welke inherited method by default gebruikt moet worden.

[PromWarMachine]

Om weer even ontopic te gaan, zou ik kiezen voor C in plaats van JAVA, omdat C(++) in mijn ogen de basis is voor het latere JAVA. Mede daarom krijgen wij namelijk eerst C++ op school en later pas JAVA.

Als je C gaat leren, zou ik geen C meer nemen, maar eerder C++, hier zijn vele verbeteringen in ingevoerd. Alles om het de mens makkelijker te maken.

Succes in ieder geval!

[Verwijderd]

Op dinsdag 19 maart 2002 12:14 schreef PromWarMachine het volgende:
Mede daarom krijgen wij namelijk eerst C++ op school en later pas JAVA.

Java is heel acceptabel als eerste taal. C++ is veel gecompliceerder, en daarom lijkt het me niet verstandig C++ te leren als 'voorbereiding' op Java.

[whoami]

Dit is nog een interessante link, C# ivgl met Java

http://genamics.com/developer/csharp_comparative.htm

[Mithrandir]

Op dinsdag 19 maart 2002 11:27 schreef Alarmnummer het volgende:
Je moet eerst goed leren proggen (zoals iedereen opmerkt). Dus for lusjes, while lusjes, if else commando`s. Dan functies en procedures, geheugen structuren: records en arrays en dan dynamische structuren.

Daarna pas oo... als je geen goeie basis hebt dan ben je echt nergens. Ik zou me dus nog niet meteen toeleggen op het maken van spelletjes, maar eerst simpele dingen zoals tafels afdrukken.

Dat tafels afdrukken, if else statements, allerhande loopjes enzovoorts heb ik dus al gedaan in PHP. Daarom wou ik wat "moeilijkers" doen.

Dat over die spelletjes was maar een snel voorbeeldje, dat was niet echt serieus. Ik weet dat een spelletje maken VEEL werk is. Ik bedoelde ook eerder iets van Pacman, of boter, kaas en eieren.

Niet UT 3 of Q 4 ofzo

Verder ga ik vandaag/morgen even kijken naar een boek. Bol & amazon hebben er ook een paar, en die cursus hierboven ga ik ook nog lezen.

Maar verdere commentaren/adviezen op mijn keuze zijn nog wel welkom, hoor!

[igmar]

als je toch wat gaat leren leer dan C# en leer net .NET werken.

- c# lijkt veel op java
- is snel
- is de toekomst

Ik ben atm java programmeer @ een IT bedrijf, hoe graag ik java ook gebruik, C# gaat 'HET' worden vrees ik. En helemaal voor consumenten programma`s.

Eerst zien, dan geloven. Het hele platform moet zich nog bewijzen. JAVA is platformonafhankelijk, .NET (nu) nog niet.

Ten tweede ben ik niet graag van M$ afhankelijk.

[stylee]

Bobco: Als je voor Java kiest is het mogelijk om een complete ontwikkelomgeving in te richten zonder ook maar een cent aan licenties uit te geven.

Earth to Bobco: de .NET SDK is gratis te downloaden van microsoft's website

Het klopt idd dat VS.NET behoorlijk wat $$$ kost maar ik kan je garanderen dat er genoeg Java ontwikkelomgevingen zijn die evenveel kosten. Je bent totaal niet verplicht om VS.NET aan te schaffen als je C# wilt gaan proggen.

Verder is misschien platform-onafhankelijkheid ook wel leuk. Op dit moment is Java de enige serieuze kandidaat als het gaat om het ontwikkelen van Java-apps. We doen het hier ook: ontwikkelen op NT en draaien op Solaris.

Waar in zekere zin. Maar je moet niet vergeten dat .NET als primary doel het Microsoft (Windows) platform heeft. Ik ben ook idd van mening dat aangezien Microsoft de enterprise markt ook probeert te targetten het idd handig zou zijn om bepaalde applicaties op een UNIX-achtige omgeving te kunnen draaien, vandaar dat ze waarschijnlijk die CLR voor FreeBSD ontwikkelen. Maar verwacht alvast niks in de trant van WinForms of ADO.NET op andere platformen dan windows (van Microsoft tenminste).

Verder zijn er voor Java een paar open source projecten bezig om je vingers bij af te likken. Kijk maar eens bij Jakarta.

Beetje lastig he om een aantal grote open-source projecten klaar te stomen als het hele platform net de hoek om komt kijken Maar ik verwacht eerlijk gezegd niet al te veel open-source dingetjes van de .NET kant te zien. Nooit zo geweest op een Microsoft platform. Maar wie weet...

Sterk punt van Java vind ik ook de tooling er omheen: JavaDoc is voor mij onmisbaar..

code:

csc /doc:<source_file>.xml <source_file>.cs

wat wil je nog meer?

[Mithrandir]

Danx voor die laatste post; ik wou net gaan vragen wat het eea kost . Hoeft nu dus niet meer.

Ik heb ook een wel redelijke inleiding voor C# gevonden, denk ik:

Csharp-station Tuts

Nu nog iemand met snelle internetverbinding vragen of 'ie de ontwikkelomgeving voor me wil downen, en ik ben klaar!

[whoami]

Op dinsdag 19 maart 2002 16:07 schreef DinoRaptor het volgende:

Nu nog iemand met snelle internetverbinding vragen of 'ie de ontwikkelomgeving voor me wil downen, en ik ben klaar!

Hmmm, niet echt. Dan begint het pas. Leren, leren, leren.

[Verwijderd]

Ik sanp het niet hoor, als je een beginnende programmeur bent kies je toch echt zeker weten Java. De topic starter heeft al aangegeven dat hij GUI's wil gaan schrijven. Daar is java toch uitermate geschikt voor...

Waarom zou je het wiel opnieuw uitvinden en terug gaan naar C++??? Ben je tevens (zichtbaar) de pointers kwijt.

[whoami]

Op woensdag 20 maart 2002 15:59 schreef markvleth het volgende:
Ik sanp het niet hoor, als je een beginnende programmeur bent kies je toch echt zeker weten Java. De topic starter heeft al aangegeven dat hij GUI's wil gaan schrijven. Daar is java toch uitermate geschikt voor...

Waarom zou je het wiel opnieuw uitvinden en terug gaan naar C++??? Ben je tevens (zichtbaar) de pointers kwijt.

Als beginnende programmeur leer je het best eerst programmeren vooraleer je te focussen op 1 taal. Of je dat nu doet in Pascal, Java, C/C++ of C# maakt niet uit.
Het belangrijkste is dat je basisprincipes aanleert.

Trouwens, met C++ (Builder), C#, pascal (Delphi) kan je ook gemakkelijk GUI's maken.

[MisterData]

Op woensdag 20 maart 2002 16:41 schreef whoami het volgende:

[..]
Trouwens, met C++ (Builder), C#, pascal (Delphi) kan je ook gemakkelijk GUI's maken.

GUI's kun je met alle talen die GUI ondersteunen makkelijk maken als er een sleur-en-pleur programmeeromgeving voor wordt gebruikt
Ik denk dat je niet moet kijken naar hoe goed je met een bepaalde taal GUI's of wat dan ook kan maken, maar wat de taal nog meer kan. Ik ben eigenlijk per toeval bij Java terechtgekomen, en als ik in plaats van het boek "java voor dummies" het boek "C++ voor dummies" had gekocht was ik waarschijnlijk nu een c(++) progger. Wat ik hiermee wil zeggen is dat beide talen goed zijn en hetzelfde kunnen, en het vooral afhangt van of je "Write Once, run anywhere" wilt hebben of dat je alleen voor een bepaald platform wilt proggen. Als het aantal platformen niet uitmaakt, maar je alleen snelheid wil, kies dan C++. Als je multiplatform wilt programmeren en je vind de extra traagheid van Java niet erg, kies dan java.

[mbravenboer]

MisterData: Als je multiplatform wilt programmeren en je vind de extra traagheid van Java niet erg, kies dan java.

Peter Donald: The interaction between Isolate API and Sharing facets will be interesting. I really look forward to the time when Swing apps (those slow bloated inneficient beasts) actually start-up *faster* than a native GUI app!! This will be possible with sharing JVMs and will be much easier to implement via the Isolate API. (bron)

Runtime analyse van code staat op dit moment nog aardig in de kinderschoenen. Statisch analyse zal denk ik op steeds meer punten te beperkt blijken te zijn...

[Verwijderd]

Op woensdag 20 maart 2002 15:59 schreef markvleth het volgende:
Waarom zou je het wiel opnieuw uitvinden en terug gaan naar C++??? Ben je tevens (zichtbaar) de pointers kwijt.

Sinds wanneer is gebruikmaken van een andere taal achteruitgang

Dat is niet het wiel opnieuw uitvinden, dat is simpelweg "elk probleem heeftzijn eigen perfecte taal" of hoe je dat ook wilt zeggen. Als iemand liever in C++ dan in Java progselt dan mag ie dat zelf weten Dat wil niet zeggen dat Java of C++ ondergeschikt aan elkaar zijn of dat 1 van hen absoluut beter is

[Mithrandir]

Op woensdag 20 maart 2002 15:19 schreef whoami het volgende:

[..]

Hmmm, niet echt. Dan begint het pas. Leren, leren, leren.

Ik wou eigenlijk zeggen, dan ben ik klaar met voorbereiden. Was beetje brakke zin

Op woensdag 20 maart 2002 17:48 schreef mbravenboer het volgende:

[..]

[..]

Runtime analyse van code staat op dit moment nog aardig in de kinderschoenen. Statisch analyse zal denk ik op steeds meer punten te beperkt blijken te zijn...

<-- Waar heeft die gast 't over?

[MisterData]

Op woensdag 20 maart 2002 17:48 schreef mbravenboer het volgende:

[..]


[..]

Runtime analyse van code staat op dit moment nog aardig in de kinderschoenen. Statisch analyse zal denk ik op steeds meer punten te beperkt blijken te zijn...

Swing apps die SNEL laden Dat klinkt best wel interressant Over VM sharing had ik al gehoord, maar wat is die Isolate API dan ? en wat bedoel je met Runtime Analyse

[mbravenboer]

MisterData: Swing apps die SNEL laden Dat klinkt best wel interressant Over VM sharing had ik al gehoord, maar wat is die Isolate API dan ? en wat bedoel je met Runtime Analyse

Hum, ik kwam duidelijk erg onduidelijk over .

Een paar korte uitlegjes maken het denk ik wel duidelijk:

Isolation: Dankzij de JSR 121: Application Isolation API Specification zal het mogelijk zijn om binnen 1 JVM meer gescheiden processen te hebben. Op dit moment is er maar verdacht weinig onderverdeling in een JVM, behalve wat thread gebeuren. Via de Isolation APIs zal het mogelijk zijn om een duidelijk afgescheiden proces te starten in een JVM, die andere processen in deze JVM minder tot niet kan beinvloeden. Ik quote even de JSR:

This API provides a uniform mechanism for managing Java application life cycles that are isolated from each other, at least with respect to object reachability, but that can potentially share underlying implementation resources. It provides a means of deploying new Java implementation features that enable and enhance scalability while providing an alternative to ad hoc control schemes.

Ik denk dat de Isolation API's ook zeer belangrijk zullen zijn voor de ontwikkeling van Servlet Containers. Op dit moment is het draaien van een JVM voor meerdere web-applicaties op de machine van een hoster een vrij groot probleem. De meeste 'echte' hosters gebruiken daarom een eigen JVM voor elke klant, wat uiteraard een vrij dure aangelegenheid is.

VM Sharing: Dankzij VM Sharing zal het mogelijk worden dat instanties van JVMs resources met elkaar delen. Hierbij kan je denken aan geladen libraries en dergelijke. Als je op dit moment bijvoorbeeld twee Swing applicaties in twee JVMs draait worden al de aan Swing gerelateerde bibliotheken apart ingeladen en ook JIT apart naar native code gecompileerd. Het lijkt mij duidelijk dat dat geen erg aantrekkelijke situatie kan zijn .

De kick-ass JVM van Apple in Mac OS X doet overigens al aan sharing. Op welke punten precies weet ik echter niet...

Statische analyse: Met statische analyse doel ik op de analyse die een compiler kan uitvoeren at-compile-time. De enige informatie die een compiler hier beschikbaar heeft is de source-code. Hij heeft dus geen informatie over het gebruik van deze code... Optimalisatie-beslissingen kunnen daarom ook slechts genomen worden op basis van de source-code.

Runtime analyse: Bij runtime analyse gaat het uiteraard over analyse tijdens het gebruik van een applicatie. Naast de source-code heeft een optimizer heeft hier dus een extra stukje kennis over het gebruik van de code. Het kan op basis hiervan beslissingen nemen die statisch (at-compile-time) noot mogelijk waren geweest. Op basis van dit gebruik kunnen er bijvoorbeeld veel extra methoden geinlined worden.

[MisterData]

Op woensdag 20 maart 2002 18:25 schreef mbravenboer een verhaal dat duidelijk veel duidelijker was dan zijn vorige post

Ik snappen En wanneer zal dit in de JVM te vinden zijn dan

_{Tsjah niet echt meer ontopic btw}

[mbravenboer]

MisterData: En wanneer zal dit in de JVM te vinden zijn dan

Men is er al een tijd druk mee bezig in het JCP... Ik denk dat 1.5 (eind 2003) behoorlijk wat zaken op dit punt zal introduceren.

1.4.1 (Hopper) wordt ook genoemd als eerste Sun JVM met sharing van resources, maar dat durf ik eigenlijk wel te betwijfelen. Java Generics worden ook genoemd voor 1.4.1, maar dat lijkt mij nog sterker. 1.5 dus .

Er komt trouwens binnen 1 a 2 weken wel een update van de Java Generics prototype compiler heb ik vernomen..... .

_{ach, off-topic... wat is off-topic}

[MisterData]

Op woensdag 20 maart 2002 18:32 schreef mbravenboer het volgende:

[..]

Men is er al een tijd druk mee bezig in het JCP... Ik denk dat 1.5 (eind 2003) behoorlijk wat zaken op dit punt zal introduceren.

1.4.1 (Hopper) wordt ook genoemd als eerste Sun JVM met sharing van resources, maar dat durf ik eigenlijk wel te betwijfelen. Java Generics worden ook genoemd voor 1.4.1, maar dat lijkt mij nog sterker. 1.5 dus .

Er komt trouwens binnen 1 a 2 weken wel een update van de Java Generics prototype compiler heb ik vernomen..... .

_{ach, off-topic... wat is off-topic}

Eeeeehm wat is Java Generics

_{en eind 2003, dat duurt nog verrekte lang}

[Orphix]

Op woensdag 20 maart 2002 18:25 schreef mbravenboer het volgende:
Statische analyse: Met statische analyse doel ik op de analyse die een compiler kan uitvoeren at-compile-time. De enige informatie die een compiler hier beschikbaar heeft is de source-code. Hij heeft dus geen informatie over het gebruik van deze code... Optimalisatie-beslissingen kunnen daarom ook slechts genomen worden op basis van de source-code.

Runtime analyse: Bij runtime analyse gaat het uiteraard over analyse tijdens het gebruik van een applicatie. Naast de source-code heeft een optimizer heeft hier dus een extra stukje kennis over het gebruik van de code. Het kan op basis hiervan beslissingen nemen die statisch (at-compile-time) noot mogelijk waren geweest. Op basis van dit gebruik kunnen er bijvoorbeeld veel extra methoden geinlined worden.

Ik zie statisch analyse niet zo snel verdwijnen eigenlijk. Een compiler kan op compile-time ook heel goed bepalen of een object gemuteerd wordt in een functie en aan de hand daarvan bv een reference meegeven ipv een copy-by-value.
dmv templates kunnen veel functies een statische binding krijgen ipv een dynamische (=trager). Ook inlining kan heel goed gedaan worden bij het compileren.

Impliceert de mogelijkheid tot run-time optimalisatie niet direct een performance verlies?

Ik snap niet goed op welke optimalisatie mogelijkheden je doelt.. Het sharen van dezelfde VM? Ik vind dat niet echt een optimalisatie van het programma, maar meer van de environment waar het in draait.

[mbravenboer]

MisterData: Eeeeehm wat is Java Generics

Dat mag je lekker zelf opzoeken . Is hier al vaak besproken in P&W .

[mbravenboer]

Orphix: Ik zie statisch analyse niet zo snel verdwijnen eigenlijk.

Je hebt mij ook niet horen zeggen dat statische analyse zal verdwijnen . Ik zei alleen dat runtime analyse meer mogelijkheden biedt, waardoor er een positief aspect van een VM/CLR kan ontstaan .

Een compiler kan op compile-time ook heel goed bepalen of een object gemuteerd wordt in een functie en aan de hand daarvan bv een reference meegeven ipv een copy-by-value.

Er zijn ook zeker wel zeer zinvolle optimalisaties die statische uitgevoerd kunnen worden (denk aan constante-propagatie, inlining, dead-code eliminatie, loop optimaisaties en dergelijke).

Ook inlining kan heel goed gedaan worden bij het compileren.

Inlining kan maar in een OO omgeving maar in een beperkt aantal gevallen gedaan worden bij statische analyse. Bij runtime analyse beschik je over meer informatie en kan je veel efficienter aan inlinen slaan. Bij runtime analyse en JIT compilatie zijn er wat dat betreft veel meer mogelijkheden. De JVM inlined nu al methoden die bij statische analyse niet geinlined zouden mogen worden.

Eliminatie van array-bounds checking (wat natuurlijk nogal zinvol is in Java) kan in bepaalde situaties ook beter bij runtime analyse worden uitgevoerd...

Impliceert de mogelijkheid tot run-time optimalisatie niet direct een performance verlies?

Het sharen van dezelfde VM? Ik vind dat niet echt een optimalisatie van het programma, maar meer van de environment waar het in draait.

Dat is inderdaad zo en staat ook los van de vraag of runtime optimalisatie zinvol is. Het begrip VM is echter wel vrij noodzakelijk voor runtime optimalisaties en sharing kan ervoor zorgen dat een VM efficienter kan functioneren...

[Mithrandir]

Ehrm, zouden jullie zo goed willen zijn zelf een topic te openen? Ik snap hier niets van, en het heft weinig te maken met het onderwerp -- Java vs. C

[whoami]

Op woensdag 20 maart 2002 18:35 schreef Orphix het volgende:


Impliceert de mogelijkheid tot run-time optimalisatie niet direct een performance verlies?

Ik ging net hetzelfde vragen.
Als je aan run-time optimalisatie doet, impliceert dit dan niet dat dit enkel mogelijk is bij talen zoals Java/C# die door een Just In Time compiler van hun respectievelijke byte code/IL naar native code gecompileerd worden?

Volgens mij gaat dat JIT compile proces de performance naar beneden brengen en de optimalisatie die dan nog eens gebeurt zorgt er ook voor dat de compilatie van byte-code/IL naar native code wat langer duurt.
Weegt dit allemaal wel op tegen de voordelen van de dynamische optimalisatie?

[MisterData]

Op woensdag 20 maart 2002 19:05 schreef mbravenboer het volgende:

[..]

Dat mag je lekker zelf opzoeken . Is hier al vaak besproken in P&W .

Je zoekactie naar 'java generics' leverde geen resultaten op. Resultaten 1 - geen.

[whoami]

Op woensdag 20 maart 2002 19:37 schreef MisterData het volgende:

Je kan ook eens op die link in mbravenboer zijn signature klikken....
Trouwens, ik kan moeilijk geloven dat uw zoekresultaat 0 was. Je zult niet goed gezocht hebben. Java Generics is hier idd al enkele malen gepasseerd.

[D2k]

Op woensdag 20 maart 2002 19:37 schreef MisterData het volgende:
[afbeelding]

Je zoekactie naar 'java generics' leverde 22 resultaten op. Resultaten 1 - 22.
en nu weer ontopic voor DinoRaptor ajb

[Orphix]

Op woensdag 20 maart 2002 19:16 schreef mbravenboer het volgende:
Inlining kan maar in een OO omgeving maar in een beperkt aantal gevallen gedaan worden bij statische analyse. Bij runtime analyse beschik je over meer informatie en kan je veel efficienter aan inlinen slaan. Bij runtime analyse en JIT compilatie zijn er wat dat betreft veel meer mogelijkheden. De JVM inlined nu al methoden die bij statische analyse niet geinlined zouden mogen worden.

forgive my ignorance, maar ik kan eigenlijk zo snel niks bedenken..

zie de post van whoami

Eliminatie van array-bounds checking (wat natuurlijk nogal zinvol is in Java) kan in bepaalde situaties ook beter bij runtime analyse worden uitgevoerd...

stel een JIT compiler gaat checken of het wel nodig is om array-bound checking te doen ... ik betwijfel of de uiteindelijke performance nou zo denderend is.

[marcusk]

Op woensdag 20 maart 2002 19:43 schreef Orphix het volgende:
forgive my ignorance, maar ik kan eigenlijk zo snel niks bedenken..

Bij java worden alle klassen gecompileerd naar aparte class files die onafhankelijk van elkaar moeten kunnen werken, terwijl er bij bv. C++ maar 1 executable gegenereerd wordt waarbij er helemaal geen onderscheid in klassen hoeft te zijn. Ik kan me dus voorstellen dat de jitter er achter kan komen waarvoor klassen worden gebruikt en er zo dus bv. functie methode inlining gedaan kan worden.

[Orphix]

Op woensdag 20 maart 2002 19:55 schreef marcusk het volgende:
Bij java worden alle klassen gecompileerd naar aparte class files die onafhankelijk van elkaar moeten kunnen werken, terwijl er bij bv. C++ maar 1 executable gegenereerd wordt waarbij er helemaal geen onderscheid in klassen hoeft te zijn. Ik kan me dus voorstellen dat de jitter er achter kan komen waarvoor klassen worden gebruikt en er zo dus bv. functie methode inlining gedaan kan worden.

Ik versta onder methode inlining dat er geen functie wordt aangeroepen maar in plaatst daarvan wordt de functie-code als het wate op de plek van aanroep 'ingevuld'.

Ik kan me dit prima voorstellen bij het compileren naar .class bestanden van een enkel java bestand.

Echter, je mag bij het gebruik van anderen klassen er _niet_ vanuitgaan dat ze niet zullen veranderen en dus zul je op dat moment geen inlining toe kunnen passen. Er moet dus idd run-time het desbetreffende code segment opgehaald worden.
Denk je dat het veel sneller wordt wanneer de JIT eerst gaat kijken of er misschien ge-inlined kan worden, ohja dat kan, dan op een of andere manier geen argumenten op de stack e.d. gooit maar rechtstreeks de benodige argumenten aan de code meegeeft?
Ik zie dat dus niet.
Of zit ik nu op een heel verkeerd spoor

[marcusk]

Op woensdag 20 maart 2002 20:04 schreef Orphix het volgende:
Ik versta onder methode inlining dat er geen functie wordt aangeroepen maar in plaatst daarvan wordt de functie-code als het wate op de plek van aanroep 'ingevuld'.

idd, ik ook

Ik kan me dit prima voorstellen bij het compileren naar .class bestanden van een enkel java bestand.

Echter, je mag bij het gebruik van anderen klassen er _niet_ vanuitgaan dat ze niet zullen veranderen en dus zul je op dat moment geen inlining toe kunnen passen. Er moet dus idd run-time het desbetreffende code segment opgehaald worden.

precies.

Denk je dat het veel sneller wordt wanneer de JIT eerst gaat kijken of er misschien ge-inlined kan worden, ohja dat kan, dan op een of andere manier geen argumenten op de stack e.d. gooit maar rechtstreeks de benodige argumenten aan de code meegeeft?
Ik zie dat dus niet.
Of zit ik nu op een heel verkeerd spoor

Het optimalizeren hoeft natuurlijk maar 1 keer te gebeuren - bij het laden van het programma. Verder is inlining natuurlijk maar een voorbeeld. mbravenboer weet er vast wel meer

[mbravenboer]

Ik wil er best op in gaan, maar er zijn al een paar vragen geweest om on-topic te blijven.... Als je het echt interessant vind moet je maar eens rondkijken naar wetenschappelijke artikelen over bijvoorbeeld inlining in OO-talen (zijn er een hoop) en eventueel een nieuw topic beginnen .

[mbravenboer]

Hier kwam ik een goed stukje tegen over Hotspot en runtime inlining. Het een en ander wordt daar wel duidelijk .

http://www.artima.com/designtechniques/hotspotP.html

Hier trouwens een verrot goed boek over de interne werking van het Java Platform, vrijwel volledig online te lezen (met dank aan Alarmnummer ). Monster-tip.

http://www.artima.com/insidejvm/ed2/index.html