Hoe neem ik een programmeertaal serieus?

[Verwijderd]

Hey!

Oke ik probeer het kort maar krachtig te houden, hier dus mijn 'probleem':
Ik zit nu in het tweede jaar toegepaste informatica in het hoger met het oog om applicatieontwikkeling te kiezen als 3de/eind/specialisatie-jaar. Op school houden wij ons bezig met 3 programmeertalen, namelijk VB.NET, C# en Java. (En PHP voor zover dit ook als programmeertaal beschouwd kan worden.)

De lessen verlopen (voorlopig omdat ze pas gestart zijn) redelijk vlot. Hieronder mag je verstaan dat hetgeen wat we die les gezien hebben tegen volgende les geen probleem meer vormt, ik weet dus voor wat iets dient en hoe het gebruikt wordt. Maar aangezien ik maar 2 uurtjes in de week elk van deze programmeertaal heb gaat het wat traag of minder 'uitgediept' naar mijn goesting. En in het derde jaar komt daar niet direct verandering in want dan draait alles eerder om een eindproject en stage.

Daarom heb ik besloten om zelfstandig mezelf bij te scholen zodat ik iets meer het gevoel heb dat ik ook werkelijk iets kan met deze programmeertalen. Want nu sta ik nergens en zie mezelf totaal nog niet werken in een omgeving waar professioneel geprogrammeerd moet worden. Voor elk van deze programmeertalen beschik ik over een e-book maar deze zijn zodanig groot dat ik door de bomen het bos niet zie.

In welke volgorde hoor je een programmeertaal nu aan te leren?
Moet je nu echt een heel boek hoofdstuk per hoofdstuk gaan verwerken of zijn er zaken waarvan jij zegt, zorg dat je eerst deze dingen onder de knie krijgt en begin daarna pas aan iets anders. (En dan heb ik het over bepaalde constructies of methodes leren te gebruiken, niet verschillende programmeertalen).

Je moet me nu dus ook niet gaan zeggen dat ik eerst variabelen moet leren declareren, en gaan spelen met operators, lussen leer opbouwen, enz... Dat is allemaal van zelf sprekend. Wat ik wil weten is, welke onderdelen of constructies zijn belangrijk of zelfs noodzakelijk voor het bouwen van een correct werkend programma?

Sites die mij verder helpen zijn ook altijd welkom!
Websites waar opensource projecten op staan die ik kan 'ontleden' zouden bv heel nuttig zijn.
Of geavanceerde tutorials waar uitgelegd wordt WAAROM een bepaald iets een bepaalde output geeft, geen sites waar gewoon voorbeeld code wordt geplakt om bv objecten in arrays te steken.


Ik wil een programmeertaal begrijpen en hoe het in zijn werk gaat en op die manier onder de knie krijgen. Dus niet door papegaai te spelen die af en toe zelf is een woordje verzint.

Alvast bedankt! En mijn excuses mocht mijn vraagstelling wazig zijn gebleven. Aarzel niet om verdere vragen te stellen, aangezien ik van programmeren mijn beroep wil maken sta ik open voor alle hulp!

[Avalaxy]

Mijn tip: stop met zoveel talen tegelijk leren. Meerdere talen leren is absoluut goed, en aan te raden, maar voor een beginner is het denk ik gewoon verkeerd je zo hard te focussen op alles door elkaar doen maar zou je beter een solide basis kunnen krijgen in de hele workflow. Denk aan ERD's maken, UML, design patterns, Scrum, unit testen, version control, datastructuren, etc. en dat gewoon in één taal te doen. Zodra dat lukt ga je wat spelen met andere talen en leer je weer leuke dingen waar je nog niet eerder van gehoord had.

Het voordeel van werken met één taal is dat je dan veel productiever bent omdat je niet eindeloos zit te zoeken op basale dingen terwijl daar de opdracht helemaal niet eens om draait. Tevens raak je dan niet zo in de war omdat alles nét iets anders is in de verschillende talen.

[ Voor 6% gewijzigd door Avalaxy op 28-09-2011 20:50 ]

[Verwijderd]

Goed leren programmeren is meer er achterkomen hoe de technieken werken en wanneer je deze moet toepassen. Als je dit eenmaal doorhebt dan kun je zonder veel moeite verschillende talen oppakken en heen en weer switchen wanneer dit nodig is.

[Nvidiot]

Wat mij een goed inzicht heeft gegeven in wat er allemaal komt kijken bij een wat groter project is het boek "Code Complete". Dat beschrijft het hele proces van grote structuren totaan dingen als "hoe lang zou een functie moeten zijn" of "in welke volgorde zet ik mijn code als de volgorde niet uit maakt voor het resultaat"

[Verwijderd]

En Code Complete heeft inderdaad veel goed/fout voorbeelden maar gaat niet specifiek over 1 taal. (beetje lang geleden dat ik die heb gelezen).

[ Voor 19% gewijzigd door Verwijderd op 28-09-2011 20:57 ]

[Verwijderd]

Avalaxy schreef op woensdag 28 september 2011 @ 20:49:
Mijn tip: stop met zoveel talen tegelijk leren. Meerdere talen leren is absoluut goed, en aan te raden, maar voor een beginner is het denk ik gewoon verkeerd je zo hard te focussen op alles door elkaar doen maar zou je beter een solide basis kunnen krijgen in de hele workflow. Denk aan ERD's maken, UML, design patterns, Scrum, unit testen, version control, datastructuren, etc. en dat gewoon in één taal te doen. Zodra dat lukt ga je wat spelen met andere talen en leer je weer leuke dingen waar je nog niet eerder van gehoord had.

Het voordeel van werken met één taal is dat je dan veel productiever bent omdat je niet eindeloos zit te zoeken op basale dingen terwijl daar de opdracht helemaal niet eens om draait. Tevens raak je dan niet zo in de war omdat alles nét iets anders is in de verschillende talen.

Ik denk er ook zo over, maarja ik kan moeilijk 2 talen in school laten vallen natuurlijk.
En welke taal is dan het beste of het meest belonend om mee te beginnen? Omdat ik enkel Java, C# en VB.NET krijg in school lijkt me het dus best een van deze 3 te kiezen als eerste echte taal. Mijn voorkeur gaat uit naar Java of C#, ze lijken wat op elkaar en heb de indruk hier mee te kunnen doen dan dat ik met VB.NET kan. (Of het terecht is of niet, aan jullie om mij daarop te wijzen)

Verwijderd schreef op woensdag 28 september 2011 @ 20:54:
Goed leren programmeren is meer er achterkomen hoe de technieken werken en wanneer je deze moet toepassen. Als je dit eenmaal doorhebt dan kun je zonder veel moeite verschillende talen oppakken en heen en weer switchen wanneer dit nodig is.

En hoe kan ik er dan achterkomen en wanneer weet ik wanneer wat te gebruiken? Is het puur de techniek door en door kennen of zijn er bepaalde 'indelingen' van als je dat soort probleem hebt ga je voor optie A, heb ja dit soort probleem opteer dan optie B?

Eventueel sites waar zo technieken worden ontleed of uitgelegd?

Nvidiot schreef op woensdag 28 september 2011 @ 20:54:
Wat mij een goed inzicht heeft gegeven in wat er allemaal komt kijken bij een wat groter project is het boek "Code Complete". Dat beschrijft het hele proces van grote structuren totaan dingen als "hoe lang zou een functie moeten zijn" of "in welke volgorde zet ik mijn code als de volgorde niet uit maakt voor het resultaat"

Lijkt me interessant, ga er zeker is voor kijken!

[Avalaxy]

Verwijderd schreef op woensdag 28 september 2011 @ 21:13:
[...]


Ik denk er ook zo over, maarja ik kan moeilijk 2 talen in school laten vallen natuurlijk.
En welke taal is dan het beste of het meest belonend om mee te beginnen? Omdat ik enkel Java, C# en VB.NET krijg in school lijkt me het dus best een van deze 3 te kiezen als eerste echte taal. Mijn voorkeur gaat uit naar Java of C#, ze lijken wat op elkaar en heb de indruk hier mee te kunnen doen dan dat ik met VB.NET kan. (Of het terecht is of niet, aan jullie om mij daarop te wijzen)

VB.NET kun je denk ik met een gerust hart laten vallen, dat is niet zo'n heel populaire taal. Ik zou zelf C# zeggen omdat ik het .NET platform zelf briljant makkelijk en krachtig vind om mee te werken. De meningen zijn echter verdeeld, dus met Java kun je ook heel ver komen.

[...]

En hoe kan ik er dan achterkomen en wanneer weet ik wanneer wat te gebruiken? Is het puur de techniek door en door kennen of zijn er bepaalde 'indelingen' van als je dat soort probleem hebt ga je voor optie A, heb ja dit soort probleem opteer dan optie B?

Eventueel sites waar zo technieken worden ontleed of uitgelegd?

Heb je misschien een voorbeeld? Er zijn vaak wel 'standaardoplossingen' in de vorm van design patterns, waarin bepaalde problemen met een terugkerend patroon worden opgelost, maar dat gaat meer over de architectuur van je applicatie en niet over kleine dingen van 'welke loop gebruik ik hier'.

[...]

Lijkt me interessant, ga er zeker is voor kijken!

Kijk dan wel voor Code Complete 2, de geupdate versie. Verder kan ik zelf ook dat boek aanraden voor beginnend programmeurs.

[Verwijderd]

Avalaxy schreef op woensdag 28 september 2011 @ 21:19:
[...]


VB.NET kun je denk ik met een gerust hart laten vallen, dat is niet zo'n heel populaire taal. Ik zou zelf C# zeggen omdat ik het .NET platform zelf briljant makkelijk en krachtig vind om mee te werken. De meningen zijn echter verdeeld, dus met Java kun je ook heel ver komen.


[...]


Heb je misschien een voorbeeld? Er zijn vaak wel 'standaardoplossingen' in de vorm van design patterns, waarin bepaalde problemen met een terugkerend patroon worden opgelost, maar dat gaat meer over de architectuur van je applicatie en niet over kleine dingen van 'welke loop gebruik ik hier'.


[...]


Kijk dan wel voor Code Complete 2, de geupdate versie. Verder kan ik zelf ook dat boek aanraden voor beginnend programmeurs.

1.
Ik heb gelezen dat de C talen 'moeilijker' zijn omdat wanneer je deze beheerd een beter beeld hebt van hoe de computer dingen verwerkt, klopt dat? Behoord C# dan ook tot de groep van C / C++? Buiten dat C# met de .NET omgeving werkt en de andere C talen niet.
En als ik voor Java zou kiezen zou ik eventueel later problemen hebben om een C taal aan te leren omdat de C taal net iets meer 'computer gericht' is. Kloppen deze uitspraken of zijn ze verwaarloosbaar?

2.
Blackspot had het over achterkomen hoe technieken werken. Maar bedoeld hij dan hoe je een techniek gebruikt of hoe een bepaalde techniek in elkaar steekt? En waar kan ik zo dingen achterhalen?

Wat je zegt over design patterns lijkt me al heel interessant.

3.
Merci voor de tip, zal de e-book binnenkort eens aanschaffen.

[Gomez12]

Wat ik me altijd afvraag bij dit soort topics : Is het al niet per definitie een fail als je het extern aan onbekenden moet vragen?

Als je zelf gezocht had dan had je imho makkelijk tig best-practices kunnen vinden, tig design paters, tig online leermethodes etc. etc.

[Verwijderd]

Gomez12 schreef op woensdag 28 september 2011 @ 21:33:
Wat ik me altijd afvraag bij dit soort topics : Is het al niet per definitie een fail als je het extern aan onbekenden moet vragen?

Als je zelf gezocht had dan had je imho makkelijk tig best-practices kunnen vinden, tig design paters, tig online leermethodes etc. etc.

Dat is allemaal goed en wel, maar hier vraag ik hoe mensen met ervaring er over denken. En ik denk dat die mij enorm kunnen helpen door mij de juiste richting in te sturen.

En zoals ik in mijn eerste post zei kan ik door de bomen het bos niet meer zien, daarom dat ik met die 'tig best-practices kunnen vinden, tig design paters, tig online leermethodes etc. etc.' niet altijd even hard geholpen ben.

[Avalaxy]

Verwijderd schreef op woensdag 28 september 2011 @ 21:32:
[...]

1.
Ik heb gelezen dat de C talen 'moeilijker' zijn omdat wanneer je deze beheerd een beter beeld hebt van hoe de computer dingen verwerkt, klopt dat? Behoord C# dan ook tot de groep van C / C++? Buiten dat C# met de .NET omgeving werkt en de andere C talen niet.
En als ik voor Java zou kiezen zou ik eventueel later problemen hebben om een C taal aan te leren omdat de C taal net iets meer 'computer gericht' is. Kloppen deze uitspraken of zijn ze verwaarloosbaar?

C# en Java zijn beiden gebaseerd op C++. Ze zijn in syntax dan ook nagelijk gelijk aan elkaar. Hoe de computer dat oplost heeft er verder niet zo heel veel mee te maken, zo wordt F# in dezelfde Intermediate Language omgezet als C# en therefore in dezelfde native code, maar dat doet de (JIT) compiler allemaal voor je.

C en C++ zijn dan weer wat anders, die zijn meer low-level (oftewel: er zit niet nog een managed schil omheen) waardoor je zelf dingen als memory management moet opknappen. Ja, dat geeft je meer inzicht in wat er gebeurt, maar dat hoeft niet beter te zijn. Zeker voor snel ontwikkelen in C# beter.

2.
Blackspot had het over achterkomen hoe technieken werken. Maar bedoeld hij dan hoe je een techniek gebruikt of hoe een bepaalde techniek in elkaar steekt? En waar kan ik zo dingen achterhalen?

Wat je zegt over design patterns lijkt me al heel interessant.

Hoe je het gebruikt met name, Code Complete gaat verder niet echt in op hoe een computer werkt.

[Gomez12]

Verwijderd schreef op woensdag 28 september 2011 @ 21:32:
[...]
1.
Ik heb gelezen dat de C talen 'moeilijker' zijn omdat wanneer je deze beheerd een beter beeld hebt van hoe de computer dingen verwerkt, klopt dat? Behoord C# dan ook tot de groep van C / C++? Buiten dat C# met de .NET omgeving werkt en de andere C talen niet.
En als ik voor Java zou kiezen zou ik eventueel later problemen hebben om een C taal aan te leren omdat de C taal net iets meer 'computer gericht' is. Kloppen deze uitspraken of zijn ze verwaarloosbaar?

Hangt ervanaf wat je jezelf aanleert. Leer jij jezelf C#-codekloppen aan dan wordt het problematisch, ik zeg zelf altijd dat ik in elke taal kan programmeren. Geef me alleen even de syntax...

Per taal heb je een aantal optimaliseerpunten waardoor je dit of dat beter net iets anders kan doen in taal x of y. Maar over het algemeen is ongeveer 90% verwaarloosbaar in de praktijk. Die 10% die je dan op taal-specialisatie mist die kan je imho weer goedmaken door meer algemene kennis.

2.
Blackspot had het over achterkomen hoe technieken werken. Maar bedoeld hij dan hoe je een techniek gebruikt of hoe een bepaalde techniek in elkaar steekt? En waar kan ik zo dingen achterhalen?

Begin eens bij een msdn / java online etc. etc. Staat er echt niets in jouw boeken qua google-bare termen?

Verwijderd schreef op woensdag 28 september 2011 @ 21:36:
[...]
Dat is allemaal goed en wel, maar hier vraag ik hoe mensen met ervaring er over denken. En ik denk dat die mij enorm kunnen helpen door mij de juiste richting in te sturen.

En zoals ik in mijn eerste post zei kan ik door de bomen het bos niet meer zien, daarom dat ik met die 'tig best-practices kunnen vinden, tig design paters, tig online leermethodes etc. etc.' niet altijd even hard geholpen ben.

Ok, google eens naar design paters, lees je daarover in. Daarna google je naar best practicus voor design pattern x (waar je je net over ingelezen hebt) etc. etc.

Er is geen 1 gouden regel die altijd opgaat bij programmeren, programmeren is zo divers dat er tig tegenstellingen zijn die allemaal waar zijn mits op de juiste plek/tijd toegepast.

Wil je bijv voor performance programmeren, dan gelden de meeste aanpakken niet meer (want die zijn veelal breed en log, met veel fall-backs)
Wil je bijv voor minimaal geheugen gebruik programmeren, dan gelden de meeste aanpakken niet.
Wil je bijv enkel onder extreme tijdsdruk programmeren dan gelden de meeste aanpakken niet meer.

Het zijn allemaal afwegingen die compleet afhankelijk zijn van situatie / tijd / geld etc. Het kan per project, maar ook per projectdeel verschillen.

[ Voor 32% gewijzigd door Gomez12 op 28-09-2011 21:44 ]

[Nactive]

Eerst Beetje lezen over Design Paterns en zorgen dat je de syntax van je taal goed kent.

Maar indien je dit allemaal onder de knie hebt is de beste methode voor een taal te leren toch nog altijd iets zelf programmeren.
Verzin een projectje dat je zelf wilt maken en begin er gewoon aan, zo heb ik toch het meeste van programmeren geleerd (Al is het wel belangrijk dat je de basis effectief eerst leest anders ga je waarschijnlijk op een slechte manier werken).

[Gomez12]

Nactive schreef op woensdag 28 september 2011 @ 21:47:
Maar indien je dit allemaal onder de knie hebt is de beste methode voor een taal te leren toch nog altijd iets zelf programmeren.
Verzin een projectje dat je zelf wilt maken en begin er gewoon aan, zo heb ik toch het meeste van programmeren geleerd (Al is het wel belangrijk dat je de basis effectief eerst leest anders ga je waarschijnlijk op een slechte manier werken).

Besef je wel dat als je blind begint je heel erg veel leert, maar daarna ook weer heel erg veel moet afleren.

Best practicus zijn veelal het duidelijkste als je ze eerst fout doet en in de knoei komt

Goto is zo'n leuk voorbeeld, het is in 99,99% van de gevallen verkeerd gebruik, maar in 0,01% van de gevallen is het juist perfect te gebruiken en daarom bestaat het ook nog steeds.
Een simpele regel als : goto is fout, die is dan ook waardeloos. Maar goto is goed, die is net zo waardeloos

[Verwijderd]

Allemaal bedankt voor jullie input! Ik ga er mij er de komende dagen mee bezighouden om alle genoemde termen uit te pluizen en alles wat er achter steekt!

Nog een klein (voorlopig) laatste vraagje, is het het waard om een programmeer boek door te nemen van A tot Z? Of moet je zo een boek eerder diagonaal lezen?

[Avalaxy]

Soms wel, soms niet. Pro ASP.NET MVC3 heb ik van kaft tot kaft doorgelezen, Java the Complete Reference heb ik maar voor de helft gelezen (net als C# 4.0 in a nutshell). Referentieboeken zijn vaak niet echt doorleesbaar. Vaak weet je al wat je moet weten als je de helft leest, de rest kun je opzoeken.

[Kwastie]

Verwijderd schreef op woensdag 28 september 2011 @ 22:14:
Nog een klein (voorlopig) laatste vraagje, is het het waard om een programmeer boek door te nemen van A tot Z? Of moet je zo een boek eerder diagonaal lezen?

Het ligt heel erg aan het soort boek, bijvoorbeeld de "Head First" boeken zijn bijvoorbeeld prima om van A-Z door te lezen (steker nog, ze zijn er voor gemaakt om dat doen ). Maar er zijn ook genoeg boeken die alleen bedoeld zijn als referentie.

Persoonlijk hou ik meer van de "A-Z" boeken omdat ze (alleen) de belangrijke dingen behandelen.

Tip: Focus je niet zozeer op syntax van een taal, maar probeer de concepten te snappen, ze zijn namelijk bij 99/100 van alle talen hetzelfde.

[roy-t]

Ik kan voor C# het boek PRO C# 2008 and the .net 3.5 framework aanraden, dik boek maar ook eentje die je wel zo door kan lezen. (Er is ondertussen vast een 2010 / .net.4.0 versie uit).

Wat ik niet snap van je school is waarom ze voor C#+VB.NET + JAVA kiezen. Zowel C# als VB.NET gebruiken compleet het zelfde framework en zijn (op een paar kleine obscure features na) alleen verschillend in syntax. Java is dan net iets anders (technisch gezien) maar heeft wel precies dezelfde ideeen (Zowel, C#, VB.NET en Java zijn Object Oriented managed garbage collected talen die naar een intermediate taal compileren en draaien in een runtime ipv direct op het systeem) en JAVA lijkt qua syntax zo op C# dat je vaak gewoon code heen en weer kunt copy pasten.

Meerdere talen leren is handig, maar alleens als je dan ook verschillende skills leert. (Bijvoorbeed C als imperatieve taal zonder garbage collection. C# als bovengenoemde voorbeeld en Haskell of F# als functionele taal om weer iets compleet anders te zien).

Anyway daar kun jij niets aan doen maar ik vind het maar vreemd. Misschien heeft de school gewoon opgezocht wat de meest populaire talen zijn en geeft het daarom die.

Maar ik zou me er niet te druk over maken welke taal je je specifiek op richt. Alle code die je in C# schrijft kun je bijna copy-pasten naar Java en het werkt ook en het zal ook meteen werken in VB.NET als je de syntax even omschrijft (idee blijft hetzelfde).

[ Voor 3% gewijzigd door roy-t op 28-09-2011 23:26 ]

[Niemand_Anders]

Ik raad beginnende programmeurs meestal eerder C# aan dan Java. In java ontbreekt namelijk een belangrijk item in de OOP toolkit, namelijk de property. In Java worden properties gesimuleerd via getX en setX methodes en daardoor vervaagd nogal snel het verschil van een property (eigenschap/instelling) en een methode (aktie).

En waar Microsoft probeert zijn talen VB.net en C# te laten evolueren, lijkt Java al jaren redelijk stil te staan.
Hoewel C# via Mono ook op Linux, BSD een OSX kan draaien, is de taal duidelijk geoptimaliseerd voor de Microsoft platforms. Java draait op bijna alles en voordat smartphones hun intreden deden, was het de meest populaire taal voor apps. Echter vanwege het zeer nadrukkelijk cross platform karakter van Java kun je helaas ook niet (of zeer lastig) van platform specifieke functies gebruik maken.

Mogelijk probeert de school de student in het eerste jaar kennis te laten maken met verschillende talen en daarmee een bredere horizon te creëren voordat de school voornamelijk zal terug vallen op een enkele taal.

Zelf vind ik C# fijn omdat ik dan vanuit Visual Studio goede support heb voor zowel service (services, WCF en EMB) development, desktop development (Winforms en WPF), Web development (webforms en MVC), database applicaties (reporting services, analysis- en integration projecten en CLR object support in tables), game development (Windows en XBox), mobile app development (Windows Phone) en embedded programming in de vorm van .NET Micro framework/.NET Gadgeteer en robotics..

Pro C# 2008 is inderdaad een zeer goed en vlot geschreven boek. Echter de concepten van Java en .NET zijn zeer goed uitwisselbaar. Ook de Microsoft Press boeken voor certificeringen zijn van goede kwaliteit echter zijn deze wel toegespitst op een specifiek onderdeel (zoals desktop of web development in C#).

Naast OOP talen is het ook niet verkeerd naar procedurele talen zoals Cobol, Pascal en C te kijken.
Grote instellingen (banken, verzekeraars, etc) welke met (IBM) mainframes werken, maak nog steeds vaak gebruik van Cobol en zijn eigenlijk altijd op zoek naar goede Cobol programmeurs..

[roy-t]

Hoewel ik als MS evangelist altijd C# zal kiezen boven Java snap ik het property argument niet. Een property in C# is alleen maar een shorthand voor een getter en setter methode (die worden ook netjes gegenereerd) en Java's properties zijn ook echt gewoon methodes dus het is meer een syntactische shortcut dan een OO design principe.

[Caelorum]

roy-t schreef op woensdag 28 september 2011 @ 23:25:
Ik kan voor C# het boek PRO C# 2008 and the .net 3.5 framework aanraden, dik boek maar ook eentje die je wel zo door kan lezen. (Er is ondertussen vast een 2010 / .net.4.0 versie uit).

Naast dit boek kan ik ook "Essential C# 4.0" van Mark Mchaelis aanraden. Howel af en toe nogal droog wordt er wel goed ingegaan op diverse taalspecifieke zaken. Daarnaast ook handig is dat hij af en toe een vergelijking trekt met java en c++ (als er verwarring mogelijk is), waardoor je ook wat meer inzicht krijgt in die talen.

Daarnaast met de andere dat de taal keuzes niet ideaal zijn. Zelf baal ik er ook ontzettend van dat ik niet ook een functionele taal heb geleerd toen ik begon met programmeren. Om dit na jaren van Java en C# nog fatsoenlijk te leren is echt een ramp.

Handig is om een extra taal te pakken waarbij je funcitoneel moet programmeren en een extra taal te gaan leren waarbij je aan memory management moet doen. Het hebben van inzicht in deze zaken gaat je enorm helpen bij het kunnen begrijpen van andere talen en het begrijpen wat er onderwater bij C#, java en vb.net gebeurt. Het begrijpen wat er onderwater gebeurt gaat je dan weer helpen begrijpen waarom bepaalde algoritmen niet of slecht werken en welke aanpassingen je kan doen om dit te verbeteren.

[Remus]

roy-t schreef op donderdag 29 september 2011 @ 08:25:
Hoewel ik als MS evangelist altijd C# zal kiezen boven Java snap ik het property argument niet. Een property in C# is alleen maar een shorthand voor een getter en setter methode (die worden ook netjes gegenereerd) en Java's properties zijn ook echt gewoon methodes dus het is meer een syntactische shortcut dan een OO design principe.

Sterker nog: in Java kan je dus properties hebben die geen field zijn in je object, als je de Javabeans syntax gebruikt worden methods met getXXX/isXXX en setXXX gezien als een property xXX, terwijl je niet noodzakelijk een field xXXX in je class hoeft te hebben.

[YopY]

In mijn ervaring: Pak een boek of website en leer de basis van een programmeertaal (algemene concepten e.d.) en ga gewoon aan het werk. Voor een werkgever met een bepaalde programmeertaal werken om iets te bouwen is (imho) gewoon de beste manier om een programmeertaal te leren, zeker als je met iemand samenwerkt die de taal al kent.

Bij mij gaat dit natuurlijk wat vlotter / makkelijker omdat ik al enkele programmeertalen ken / enkele jaren ervaring heb (alhoewel ik me nog best wel junior vind, in vergelijking met de heren van 30+ bij m'n werkgever ), dan heb je sneller door hoe iets in elkaar zit en wat bepaalde termen betekenen.

[Zoijar]

C++ leren met pointers en templates. Daarna is alles vrij simpel. Andersom is het veel lastiger. Dan verschillende data structuren implementeren als oefening; dan design patterns lezen van begin tot eind. Weten wanneer welke data structuur te gebruiken is een groot deel van het programmeren.

(en of iets nou een get/set method is of een property, meh, dat interesseert eigenlijk niemand echt Staar je niet blind op dat alles perfect OOP moet zijn. Dan zie je de mooiste, en meest ingewikkeld/onleesbare, klasse structuren, en dan draait de kern in O(n^2) ip O(n log n) omdat de verkeerde data structuur wordt gebruikt)

[ Voor 36% gewijzigd door Zoijar op 29-09-2011 10:48 ]

[Janoz]

roy-t schreef op donderdag 29 september 2011 @ 08:25:
Hoewel ik als MS evangelist altijd C# zal kiezen boven Java snap ik het property argument niet. Een property in C# is alleen maar een shorthand voor een getter en setter methode (die worden ook netjes gegenereerd) en Java's properties zijn ook echt gewoon methodes dus het is meer een syntactische shortcut dan een OO design principe.

Grappig, ik ben meer de Java evangelist, en snap het argument juist wel . In java is er, puur naar de code gekeken, geen verschil tussen een gewone methode en getters/setters. Om dat te begrijpen moet het je uitgelegd worden. Bij C# is het gelijk aan de code te zien.

[ Voor 6% gewijzigd door Janoz op 29-09-2011 11:10 ]

[matthijsln]

Janoz schreef op donderdag 29 september 2011 @ 11:09:
[...]
Grappig, ik ben meer de Java evangelist, en snap het argument juist wel . In java is er, puur naar de code gekeken, geen verschil tussen een gewone methode en getters/setters. Om dat te begrijpen moet het je uitgelegd worden. Bij C# is het gelijk aan de code te zien.

Java heeft wel zeker properties. Zie de JavaBeans spec. In hoofdstuk 7 worden expliciet properties gedefinieerd. Puur naar de code kijkend is het verschil natuurlijk op te maken uit de naam van de methode. Java heeft inderdaad alleen geen speciale keywords in de syntax voor properties.

[ Voor 5% gewijzigd door matthijsln op 29-09-2011 11:45 ]

[Pykow]

Bij grote projecten heb je meestal ook meerdere programmeurs met taakverdeling.
Ik werk nu zelf in een bedrijf die software maakt voor de verhuur branche, Denk aan Audio/video verhuur, Horeca, sanitair,Stroom,units,Tenten en podia,Led boarding (alles wat met entertainment en festivallen te maken heeft)

Wij zijn een klein team, maar hebben onze taken goed verdeeld.
Zo hebben wij 2 technische programmeurs, die voorals de Classes,procedures,Functies (inzowel SQL als in onze ontwikkelomgeven WinDev),Triggers,Toolkit.

en 2 applicatieontwikelaars. Die vooral bezig houden met de frontend en gadgets maken ( Koppeling met Unit4) Gebruiksvriendelijk maken van de applicaties, Export/import programma's en alle soorten update schermen en rapportages.

Je moet je vooral richten op het denkwerk en niet op de taal zelf.
Probeer de database te begrijpen (alle Queries)
Probeer je in te leven in een klant achter jou applicatie. (gebruiksvriendelijk maken)
Standaard dingen zoals, hoe werkt nou een FOR lus, While lus, IF THEN ELSE .
Hoe ga ik om met variabele. Public variabele die je door heel het pakket gaat gebruiken.
Denk bijvoorbeeld aan je inloggegevens of andere default instellingen.
Vervolgens probeer functies en classes te begrijpen en toetepassen.

Focus je niet zozeer op 1 taal.
ik heb mijn opleiding KW1C Applicatie ontwikkelaar N4 gevolgd (1,5 jaar afgestudeerd)
Daar kreeg ik C#,Java,Actionscript3,LUA

[Janoz]

matthijsln schreef op donderdag 29 september 2011 @ 11:44:
[...]


Java heeft wel zeker properties. Zie de JavaBeans spec. In hoofdstuk 7 worden expliciet properties gedefinieerd. Puur naar de code kijkend is het verschil natuurlijk op te maken uit de naam van de methode. Java heeft inderdaad alleen geen speciale keywords in de syntax voor properties.

Dat is mijn punt juist. Je ziet niet aan de code dat een getX() iets anders is als een doeY() om dat er niks speciaal aan de code is. Het zal je verteld moeten zijn. Iemand die geen/nauwelijks feedback krijgt en geen documentatie of specificaties leest zal heel ver kunnen komen zonder dat hij ook maar 1 keer hier expliciet tegenaan loopt.

[matthijsln]

Janoz schreef op donderdag 29 september 2011 @ 11:57:
[...]
Dat is mijn punt juist. Je ziet niet aan de code dat een getX() iets anders is als een doeY() om dat er niks speciaal aan de code is. Het zal je verteld moeten zijn. Iemand die geen/nauwelijks feedback krijgt en geen documentatie of specificaties leest zal heel ver kunnen komen zonder dat hij ook maar 1 keer hier expliciet tegenaan loopt.

Tja de les aan de OP is dan dat je niet kan leren programmeren zonder ook eens een keer specs of manuals door te nemen

Maar een argument van C# boven Java vind ik dit nog steeds niet.

[Janoz]

De werkelijke les aan de OP is dat hij zich minder op de specifieke taal moet richten, maar meer op de algoritmiek. Ik vergelijk het vaak met natuurlijke taal. Een taal goed kennen betekent nog niet dat je ook een goede roman kunt schrijven. Echter, wanneer je in staat bent een goed roman te schrijven is het nauwelijks een probleem om dat in een andere taal te doen.

[Hydra]

Ik ben zelf in m'n eerste jaar Informatica redelijk losgegaan met Java omdat ik programmeren gewoon leuk vond. Er is niks mis met zelf aan de slag gaan, maar welke taal je daar voor kiest maakt an sich niet heel veel uit. Zowel Java als C# zijn veel gevraagd en bovendien lijken niet alleen de talen maar ook de API's enorm op elkaar. Als je in Java een chatservertje kunt bouwen kun je dat ook in C# bijvoorbeeld.

Ik ben overigens niet met een boek aan de slag gegaan maar ben gewoon in de API reference gaan grasduinen om uit te vogelen hoe de socket classes e.d. bijvoorbeeld werken. Ik bedacht dus dat ik een chatservertje wou maken, en ben toen uit gaan vogelen hoe ik dat moest gaan doen. Dat leert je niet alleen de 'taal', maar nog veel belangrijker leert het je om oplossingen te zoeken. En dat is wat je als programmeur leert; hoe je oplossingen moet vinden voor problemen.

Bottomline:
- taal maakt weinig uit
- ga gewoon dingen proberen te bouwen

[Gorion3]

Op mijn opleiding (Technische Informatica, HBO) begonnen ze met java als eerste taal en hebben ze daarna geswitcht naar C++. Pas bij de switch naar C++ begon ik het pas echt te begrijpen wat je allemaal moet doen. Ik zelf raad dus ook aan om met C++ gewoon te gaan werken, je tilt eigenlijk al je kennis over (alleen specifieke taal dingetjes moet je daarna nog leren). Met C++ kan je uit eindelijk ook het meest imo

[Caelorum]

Gorion3 schreef op vrijdag 30 september 2011 @ 09:44:
[...]Met C++ kan je uit eindelijk ook het meest imo

Que? Dat is hetzelfde als zeggen dat je met assembly uiteindelijk het meest kan.
Wellicht in de absolute zin, maar als je dingen moet als "bouw twitter client in 1 uur met deze en deze grafische effecten" dan ga je al snel uit die domeinen en meer richting high level talen.
Verder ben ik het met je eens dat c++ een handige toevoeging is op de overige talen, maar zoals iedereen voor mij heeft verteld is het leren van een taal niet bijzonder boeiend. Het leren van programmeer concepte, algoritmes en het 'oplossen' van technische problemen wel.

[ Voor 23% gewijzigd door Caelorum op 30-09-2011 12:18 ]

[Rmg]

Verwijderd schreef op woensdag 28 september 2011 @ 20:45:

Je moet me nu dus ook niet gaan zeggen dat ik eerst variabelen moet leren declareren, en gaan spelen met operators, lussen leer opbouwen, enz... Dat is allemaal van zelf sprekend. Wat ik wil weten is, welke onderdelen of constructies zijn belangrijk of zelfs noodzakelijk voor het bouwen van een correct werkend programma?

Ik wil een programmeertaal begrijpen en hoe het in zijn werk gaat en op die manier onder de knie krijgen. Dus niet door papegaai te spelen die af en toe zelf is een woordje verzint.

Naar mijn mening is het helemaal niet interessant voor je om een programmeertaal van a tot z te leren. Leren programmeren is wat anders.

Het leren van een taal is het leren hoe een hamer werkt. Leuk en je moet de basis ook wel kennen anders sla je je er gegarandeerd mee op de vingers. Maar als je weet hoe je een hamer werkt bouw je nog geen huis

Het juist programmeren bestaat onder andere uit het maken/bedenken van de juiste architectuur voor je programma en het juist toepassen van programmeer technieken. Wat ik je persoonlijk zou aanraden is om die kant op te gaan kijken voor je 'bijscholing' naast school .

Kijk naar boeken over OO programmeren ( en niet de taal specifieke ) & Programmeer technieken toepassen (o.a design patterns & Architectural patterns) daar heb je (IMHO) meer aan.

[Remus]

Gorion3 schreef op vrijdag 30 september 2011 @ 09:44:
Met C++ kan je uit eindelijk ook het meest imo

Onderbouw dat eens. Ik ben namelijk van mening dat je met alle algemene talen in principe alles kan doen, sommige dingen zullen in de ene taal misschien makkelijker gaan dan in andere, maar er zijn eigenlijk geen beperkingen. Ikzelf heb dan de voorkeur voor een taal waar ik niet hoef na te denken over memory management ed en die beschikken over een rijke standaard library.

[Verwijderd]

Remus schreef op vrijdag 30 september 2011 @ 15:37:
Onderbouw dat eens.

Je kan er het meeste mee, in ieder geval voor wat betreft een vergelijking tussen de hogere talen, omdat je er de meeste controle over uit kunt oefenen. Je moet in het geval van C++ die controle inderdaad dan ook wel nemen, anders gaat het mis, maar als je die controle neemt en goed uitoefent is er zondermeer meer uit te halen dan bijvoorbeeld uit een C#.

Hetgeen geen punt van kritiek op C# is, trouwens. Ik vind C# een prachtige taal en het .NET framework een prachtig raamwerk.

[Zoijar]

Remus schreef op vrijdag 30 september 2011 @ 15:37:
Ikzelf heb dan de voorkeur voor een taal waar ik niet hoef na te denken over memory management ed

Dat lijkt mij dus juist niet goed om zo te leren programmeren. Je moet juist weten wat er precies gebeurt en hoe je geheugen moet managen. Ik ben meer van het bottom-up leren, maar tegenwoordig zie je steeds vaker dat men snel dingen top-down leert. De details komen dan nog wel eens -- en waarschijnlijk nooit.

[Caelorum]

Zoijar schreef op vrijdag 30 september 2011 @ 15:47:
[...]

Dat lijkt mij dus juist niet goed om zo te leren programmeren. Je moet juist weten wat er precies gebeurt en hoe je geheugen moet managen. Ik ben meer van het bottom-up leren, maar tegenwoordig zie je steeds vaker dat men snel dingen top-down leert. De details komen dan nog wel eens -- en waarschijnlijk nooit.

Ik heb zelf ook mogen ondervinden hoe frustrerend het is om via een opleiding een highlevel taal te leren en er een paar jaar later achter te komen dat ik gewoon basiskennis mis qua kennis van programmeer concepten. Dat gaat me jaren kosten om op te lossen.

[ZpAz]

Zoijar schreef op vrijdag 30 september 2011 @ 15:47:
[...]

Dat lijkt mij dus juist niet goed om zo te leren programmeren. Je moet juist weten wat er precies gebeurt en hoe je geheugen moet managen. Ik ben meer van het bottom-up leren, maar tegenwoordig zie je steeds vaker dat men snel dingen top-down leert. De details komen dan nog wel eens -- en waarschijnlijk nooit.

Aa, kijk, nog iemand die met ASM is begonnen

Alle gekheid op een stokje. Ik denk niet dat je perse moet beginnen bij een low level taal om goed te kunnen leren programmeren. Als je meer gevorderd bent kan je altijd alsnog kijken hoe het geheugen management in C zit. Of hoe het eigenlijk achter de schermen gaat in een computer door bijvoorbeeld de basis van ASM op te pakken.

[Zoijar]

ZpAz schreef op vrijdag 30 september 2011 @ 16:22:
Aa, kijk, nog iemand die met ASM is begonnen

Klopt Op de Commodore 64 en daarna i386. Ik heb als klein programmeurtje ooit de intel reference manual doorgelezen. Ik kon toen zelf paging en protected mode switches etc schrijven in ASM. Dat klinkt misschien zinloos, maar toen ik een aantal jaar later informatica ging studeren, had computer architectuur eigenlijk geen geheimen voor me, evenmin als pointers, interrupts, geheugen managment. Die ASM kennis heeft het me zo ontzettend veel makkelijker gemaakt later. Puur omdat ik gewoon wist wat je hardware deed; die talen en OS-en waren geen magische blackboxes.

Alle gekheid op een stokje. Ik denk niet dat je perse moet beginnen bij een low level taal om goed te kunnen leren programmeren. Als je meer gevorderd bent kan je altijd alsnog kijken hoe het geheugen management in C zit. Of hoe het eigenlijk achter de schermen gaat in een computer door bijvoorbeeld de basis van ASM op te pakken.

Het kan natuurlijk wel, maar ik denk als je de basis meteen snapt, het allemaal veel duidelijker is daarna.

[ZpAz]

Zoijar schreef op vrijdag 30 september 2011 @ 16:32:
Puur omdat ik gewoon wist wat je hardware deed; die talen en OS-en waren geen magische blackboxes.

Het idee van hogere talen is nu éénmaal dat je magische black boxes aan het werk kan zetten om voor jou veel werk uit handen te nemen, waarvan je geen weet hoeft te hebben hoe ze werken. Je kan prima leuke dingen maken zonder kennis van de lagere lagen.

Om de verkeerde auto-analogieën er maar eens weer bij te slepen:
Je kan prima autorijden door een interface aan te sturen (pedalen, stuur, versnellingspook) zonder te weten hoe de onderliggen 'black boxes' (alles onder de motorkap) werkt. Wil je echter het maximale er uit halen dan is het wel handig om te weten hoe het in elkaar steekt onder de motorkap. Dan kan je op bepaalde punten bijvoorbeeld tunen om betere performance te krijgen.

Maar je kan ook een mooi product in elkaar zetten zonder dat je weet hebt van wanneer iets op de stack wordt gegooid of in een register wordt geplaatst en welke CPU instructies daar bij nodig zijn.

[roy-t]

Remus schreef op donderdag 29 september 2011 @ 10:39:
[...]


Sterker nog: in Java kan je dus properties hebben die geen field zijn in je object, als je de Javabeans syntax gebruikt worden methods met getXXX/isXXX en setXXX gezien als een property xXX, terwijl je niet noodzakelijk een field xXXX in je class hoeft te hebben.

matthijsln schreef op donderdag 29 september 2011 @ 11:44:
[...]


Java heeft wel zeker properties. Zie de JavaBeans spec. In hoofdstuk 7 worden expliciet properties gedefinieerd. Puur naar de code kijkend is het verschil natuurlijk op te maken uit de naam van de methode. Java heeft inderdaad alleen geen speciale keywords in de syntax voor properties.

Ik kende deze feature niet, net even bekeken maar het is me niet helemaal duidelijk wanneer dit nu gebeurt (alleen als je een component model interface gebruikt?). Verder snap ik niet wat het nut van properties als een specifiek deel van de taal is als je uiteindelijk toch zelf een methode moet schrijven, er is toch geen speciale short hand syntax?

Java:

private int myInt = 0; //Hoeft niet altijd gegenereerd te worden, maar hoe dan?
public int getMyInt(){return myInt;}
public void setMyInt(int value){myInt = value;}

In C# hoeft een property, zolang deze simpel is, ook geen backing field te hebben trouwens. Daar is dit trouwens een universele language feature die dus altijd werkt .

C#:

public int MyInt {get; set;} //manier 1
public int MyInt2 {get; private set;} //manier 2

//manier 3
private int myInt3 = 0;
public int MyInt3 { get {return myInt3;} set {myInt3 = value;}}

Janoz schreef op donderdag 29 september 2011 @ 11:09:
[...]

Grappig, ik ben meer de Java evangelist, en snap het argument juist wel . In java is er, puur naar de code gekeken, geen verschil tussen een gewone methode en getters/setters. Om dat te begrijpen moet het je uitgelegd worden. Bij C# is het gelijk aan de code te zien.

Ik denk dat ik begrijp wat je bedoelt. Bedoel je dat het concept van information hiding belangrijk is en dat de manier om dat te doen voor fields properties zijn (onafhankelijk of daar shorthand syntax of niet voor is)?


Edit: btw ik zie zoiets triviaals als syntactic sugar voor properties niet als een doorslaggevende reden om C# boven Java te kiezen ofzo, het is gewoon een aspect wat nu ineens uitgelicht wordt door mijn eerdere post.

[ Voor 5% gewijzigd door roy-t op 30-09-2011 18:14 ]

[C.Hariri]

Doe jezelf een lol en leer Pascal. Een van de meest elementaire dingen die andere talen fout doen, doet Pascal goed. Ik suggereer btw niet dat Pascal een 'handige' taal is om te programmeren, maar educatief (voor niet OOP) is het een zeer goede taal. Daarna ligt het eraan wat je nodig hebt, elk taal heeft wel een voordeel of nadeel.

Bootloader ga je niet schrijven in C# of Java
Een database app niet in asm.

etc etc

Zou zelf daarna Java/c# of C leren.

[ Voor 22% gewijzigd door C.Hariri op 30-09-2011 18:29 ]

[RobIII]

C.Hariri schreef op vrijdag 30 september 2011 @ 18:20:
Een van de meest elementaire dingen die andere talen fout doen, doet Pascal goed.

Wil je dat "meest elementaire ding" dan ook even benoemen?

C.Hariri schreef op vrijdag 30 september 2011 @ 18:20:
Doe jezelf een lol en leer Pascal.
...
Zou zelf Java/c# of C leren.

O... K...

[ Voor 28% gewijzigd door RobIII op 30-09-2011 18:22 ]

[Exirion]

Zoijar schreef op vrijdag 30 september 2011 @ 16:32:
Klopt Op de Commodore 64 en daarna i386. Ik heb als klein programmeurtje ooit de intel reference manual doorgelezen. Ik kon toen zelf paging en protected mode switches etc schrijven in ASM. Dat klinkt misschien zinloos, maar toen ik een aantal jaar later informatica ging studeren, had computer architectuur eigenlijk geen geheimen voor me, evenmin als pointers, interrupts, geheugen managment. Die ASM kennis heeft het me zo ontzettend veel makkelijker gemaakt later. Puur omdat ik gewoon wist wat je hardware deed; die talen en OS-en waren geen magische blackboxes.

Herkenbaar Hier idem met een Atari 600XL en voor het eerst assembly op de 286. Jij kwam ook van de VU toch? Het practicum assembly was een eitje en de technische ervaring kwam bij alle practica op Tanenbaum's afdeling prima van pas. Je merkt dat Internet de manier waarop mensen leren heeft veranderd. Vroegah zat je afgesneden van de buitenwereld op je kamertje door boeken en tabellen te ploegen om uit te zoeken hoe je iets voor elkaar kon krijgen. Nu nemen mensen zelfs amper de moeite om de uitgebreide documentatie van iOS/Android classes even door te zoeken en ze pleuren de meest basic vragen online. Stackoverflow staat vol met "geniale" antwoorden die bijna letterlijk uit de documentatie te halen zijn.

Maar om op de vraag terug te komen: bij de basics beginnen met 1 taal en daarmee het hele ontwikkelproces onder de knie krijgen is beter dan van alles wat leren zonder iets ECHT goed te beheersen.

[C.Hariri]

RobIII schreef op vrijdag 30 september 2011 @ 18:22:
[...]

Wil je dat "meest elementaire ding" dan ook even benoemen?

Maar een voorbeeld dan he, greep uit het oneindige:

1. Bij veel talen voer je een assignment uit dmv "=". Bijv: A = A + 4;
Wiskundig gezien slaat dit nergens op. Met Pascal gebruik je dan ook expliciet de assigmnent operator ":=".

2. Omgekeerde geldt ook; bijv de expressie A != B. Stelt dit A faculteit is gelijk aan B voor? (A! = ?
Pascal: A <> B.

etc etc.

Bij het ontwerp van Pascal ging het er vooral om dat de taal zuiver is. Andere talen nemen liever een wat kortere formulering bij dingen die vaker voorkomen, wat opzich helemaal niet verkeerd is. Kan alleen soms wat verwarrend zijn als je de taal net leert.

Verbeterd: "Zou zelf Java/c# of C leren.", ik bedoelde natuurlijk daarna he. Pascal wordt tegenwoordig nauwelijks meer gebruikt.

[ Voor 7% gewijzigd door C.Hariri op 30-09-2011 18:31 ]

[Exirion]

C.Hariri schreef op vrijdag 30 september 2011 @ 18:29:
1. Bij veel talen voer je een assignment uit dmv "=". Bijv: A = A + 4;
Wiskundig gezien slaat dit nergens op. Met Pascal gebruik je dan ook expliciet de assigmnent operator ":=".

2. Omgekeerde geldt ook; bijv de expressie A != B. Stelt dit A faculteit is gelijk aan B voor? (A! = ?
Pascal: A <> B.

Ik moet je als vroegere Pascal-adept toch ongelijk geven. Je zit nu te miepen over syntaxverschillen terwijl er effectief geen verschil is. Bij C is er net zo goed onderscheid tussen assignment en evaluatie met "=" versus "==". Daarbij heb ik de A<>B eigenlijk altijd maar apart gevonden bij Pascal: het is veel logischer om te stellen dat iets "ongelijk" is dan "groter of kleiner", en het vraagteken staat in C gewoon voor een boolean (niet bitwise) NOT.

[Verwijderd]

RobIII schreef op vrijdag 30 september 2011 @ 18:22:
O... K...

/signed

[C.Hariri]

<> betekent groter en kleiner dan; wat altijd false is.
Je vergelijkt twee dingen met false, als een ervan ook false is heb je een dubbele ontkenning (=true).

Niet of, anders zou je ook (A>B || A<B) kunnen schrijven; wat iets anders is.

Zoals het voorbeeld eerder gegeven; A! is in de wiskunde "A faculteit".
5! = 5*4*3*2*1
en nu zie je het al

5!=120 (false in C, true in pascal)
5! == 120 (true)??

[ Voor 14% gewijzigd door C.Hariri op 30-09-2011 18:44 ]

[RobIII]

C.Hariri schreef op vrijdag 30 september 2011 @ 18:42:
<> betekent groter en kleiner dan; wat altijd false is.
Niet of, anders zou je ook (A>B || A<B) kunnen schrijven; wat iets anders is.

Zoals het voorbeeld eerder gegeven; A! is in de wiskunde "A faculteit".
5! = 5*4*3*2*1
en nu zie je het al

5!=120 (false in C, true in pascal)
5! == 120 (true)??

Zoals Exirion zegt; dat is puur syntactisch geneuzel. In de specs van een taal wordt gewoon afgesproken: "de inequality operator is <> (of != of !== of NE of....). De assignment operator is = (of := of ...)". Dat valt, voor mij althans, niet onder "Een van de meest elementaire dingen die andere talen fout doen"; dan denk ik eerder aan het paradigma e.d.. Maar goed, dat is mijn € 0.02

[ Voor 13% gewijzigd door RobIII op 30-09-2011 18:47 ]

[Verwijderd]

C.Hariri schreef op vrijdag 30 september 2011 @ 18:42:
<> betekent groter en kleiner dan; wat altijd false is.
Niet of, anders zou je ook (A>B || A<B) kunnen schrijven; wat iets anders is.

Zoals het voorbeeld eerder gegeven; A! is in de wiskunde "A faculteit".
5! = 5*4*3*2*1
en nu zie je het al

5!=120 (false in C, true in pascal)
5! == 120 (true)??

Er is en blijft toch echt een enorm groot verschil bestaan tussen:

A! = B
en
A != B

[matthijsln]

roy-t schreef op vrijdag 30 september 2011 @ 18:11:
[...]
Ik kende deze feature niet, net even bekeken maar het is me niet helemaal duidelijk wanneer dit nu gebeurt (alleen als je een component model interface gebruikt?). Verder snap ik niet wat het nut van properties als een specifiek deel van de taal is als je uiteindelijk toch zelf een methode moet schrijven, er is toch geen speciale short hand syntax?

Er is verder niks magisch aan JavaBean properties. Het is vergelijkbaar met c# properties alleen zonder de syntactic sugar. Elke Java IDE heeft shortcuts om sneller getters en setters te genereren dan dat je de shorthand C# syntax intypt.

Edit: btw ik zie zoiets triviaals als syntactic sugar voor properties niet als een doorslaggevende reden om C# boven Java te kiezen ofzo, het is gewoon een aspect wat nu ineens uitgelicht wordt door mijn eerdere post.

Het is inderdaad geen reden. Dat je zou moeten leren over properties in Java staat tegenover het feit dat je moet leren over de shorthand syntax keywords in c#, dus het gaat allemaal nergens over.

[Nactive]

Bestaat er zelfs wel een faculteit in C, C++ of in Java ?

[RobIII]

matthijsln schreef op vrijdag 30 september 2011 @ 18:49:
[...]


Er is verder niks magisch aan JavaBean properties. Het is vergelijkbaar met c# properties alleen zonder de syntactic sugar. Elke Java IDE heeft shortcuts om sneller getters en setters te genereren dan dat je de shorthand C# syntax intypt.

Hou 't dan wel even eerlijk; VS biedt sinds het jaar knoop ook shortcuts voor 't maken van properties*


* Even de eerste hit die ergens op leek; er zijn meer/andere manieren

[ Voor 15% gewijzigd door RobIII op 30-09-2011 18:53 ]

[matthijsln]

RobIII schreef op vrijdag 30 september 2011 @ 18:50:
[...]
Hou 't dan wel even eerlijk; VS biedt sinds het jaar knoop ook shortcuts voor 't maken van properties

Waarom is die syntax sugar er dan?

edit: NetBeans ondersteunt ook een boel Code Templates maar ik gebruik meestal de ALT+INSERT hotkey, kan je er ook meerdere tegelijk maken etc.

[ Voor 22% gewijzigd door matthijsln op 30-09-2011 18:59 ]

[Herko_ter_Horst]

C.Hariri schreef op vrijdag 30 september 2011 @ 18:42:
<> betekent groter en kleiner dan; wat altijd false is.
Je vergelijkt twee dingen met false, als een ervan ook false is heb je een dubbele ontkenning (=true).

Niet of, anders zou je ook (A>B || A<B) kunnen schrijven; wat iets anders is.

Zoals het voorbeeld eerder gegeven; A! is in de wiskunde "A faculteit".
5! = 5*4*3*2*1
en nu zie je het al

5!=120 (false in C, true in pascal)
5! == 120 (true)??

Leuk verzonnen, maar als je in Pascal aan het programmeren bent, ben je in Pascal aan het programmeren, geen wiskundige formules aan het opschrijven. Alle andere zaken die je in Pascal kunt, kunnen in een wiskundige formule/vergelijking ook niet.

Zoals gezegd: dit zijn geen fundamentele fouten om andere talen maar links te laten liggen. Verder is er qua relevantie in de markt of vanuit het oogpunt van toekomstgerichtheid danwel vooruitstrevende innovatie geen enkele reden om Pascal te leren.

[Zoijar]

Exirion schreef op vrijdag 30 september 2011 @ 18:28:
Herkenbaar Hier idem met een Atari 600XL en voor het eerst assembly op de 286. Jij kwam ook van de VU toch? Het practicum assembly was een eitje en de technische ervaring kwam bij alle practica op Tanenbaum's afdeling prima van pas.

Yep Master's computersystemen. Assembler van Evert Wattel, wat een baas Stelde idd niet heel veel voor. Het was alleen "programmeren" en weinig "hardware ASM".

C.Hariri schreef op vrijdag 30 september 2011 @ 18:29:
1. Bij veel talen voer je een assignment uit dmv "=". Bijv: A = A + 4;
Wiskundig gezien slaat dit nergens op. Met Pascal gebruik je dan ook expliciet de assigmnent operator ":=".

Weet je, eigenlijk is het in C/C++ logischer vanuit een programmeer-technisch aspect: namelijk l-values, post-condities (en sequence points). Je kan namelijk A niet definieren als A+4, iets dat de := operator doet in de wiskunde; je kan alleen de post-conditie (links) geven dat A na het uitvoeren de waarde van (nu) A plus 4 heeft.

[Remus]

roy-t schreef op vrijdag 30 september 2011 @ 18:11:
Ik kende deze feature niet, net even bekeken maar het is me niet helemaal duidelijk wanneer dit nu gebeurt (alleen als je een component model interface gebruikt?). Verder snap ik niet wat het nut van properties als een specifiek deel van de taal is als je uiteindelijk toch zelf een methode moet schrijven, er is toch geen speciale short hand syntax?

Het is een conventie waarvan sommige frameworks gebruik maken om informatie te verkrijgen. Als je een methode maken of genereren te veel werk vind, dan kan je altijd nog gebruik maken van Project Lombok: http://projectlombok.org/ om het compile-time te laten genereren.

Java:

private int myInt = 0; //Hoeft niet altijd gegenereerd te worden, maar hoe dan?
public int getMyInt(){return myInt;}
public void setMyInt(int value){myInt = value;}

In C# hoeft een property, zolang deze simpel is, ook geen backing field te hebben trouwens. Daar is dit trouwens een universele language feature die dus altijd werkt .

C#:

public int MyInt {get; set;} //manier 1
public int MyInt2 {get; private set;} //manier 2

//manier 3
private int myInt3 = 0;
public int MyInt3 { get {return myInt3;} set {myInt3 = value;}}

In al deze voorbeelden maak je nog altijd gebruik van een field met dezelfde naam als je property getters en setters. Met JavaBeans kan je de waarde ook ergens anders opslaan, in verwerken, afleiden uit andere waardes etc. Het feit dat er getters en setters zijn is betekent dus niet noodzakelijk dat er een overeenkomstig field is; by C# lijkt dat wel het geval te zijn (maar: ik heb me op wat kleine uitprobeersels nog niet echt verdiept in C#).

Ik denk dat ik begrijp wat je bedoelt. Bedoel je dat het concept van information hiding belangrijk is en dat de manier om dat te doen voor fields properties zijn (onafhankelijk of daar shorthand syntax of niet voor is)?

Ja, dat is idd wat ik bedoel.

[Caelorum]

Remus schreef op zaterdag 01 oktober 2011 @ 09:45:
Het feit dat er getters en setters zijn is betekent dus niet noodzakelijk dat er een overeenkomstig field is; by C# lijkt dat wel het geval te zijn (maar: ik heb me op wat kleine uitprobeersels nog niet echt verdiept in C#).

C#:

private int i = 2;
private int j = 4;

protected int IxJplus1 {
    get { 
        return i * j + 1;
    };
}

[Remus]

Caelorum schreef op zaterdag 01 oktober 2011 @ 11:48:
[...]

C#:

private int i = 2;
private int j = 4;

protected int IxJplus1 {
    get { 
        return i * j + 1;
    };
}

Voor zover ik kan zien definieer je dan nog steeds een field genaamd IxJplus1, je gebruikt hem alleen verder niet.

[roy-t]

Remus schreef op zaterdag 01 oktober 2011 @ 12:02:
[...]


Voor zover ik kan zien definieer je dan nog steeds een field genaamd IxJplus1, je gebruikt hem alleen verder niet.

Nee er is nu geen enkel field. Er wordt alleen automatisch een field gegenereerd als je de getters en setters beide niet invult (get; set;)