Ik wil leren programmeren

[Amras]

incaz schreef op dinsdag 14 mei 2013 @ 14:07:
[...]

Is dat zo, ook bij een taal als C#, en zo ja wat? (Daar heb ik namelijk vrijwel geen ervaring mee.)

In C# kun je een property als volgt definieren:

C#:

public string Naam
{
    get;
    set;
}

wat syntactic sugar is voor:

C#:

private string _naam;

public string GetNaam()
{
    return _naam;
}

public void SetNaam(string naam)
{
    _naam = naam;
}

[BoringDay]

Amras schreef op dinsdag 14 mei 2013 @ 13:55:

Mee eens, geen side effects in properties, daar hebben ze methoden voor bedacht.

Het zijn absoluut geen side effects maar notify events.
Op het moment van een wijziging wil je dat er een bepaalde handeling wordt uitgevoerd.
Zo werkt het ook met edit object die bijvoorbeeld maximaal 10 tekens mogen hebben.
Iemand is aan het typen, edit.text krijgt een waarde en valideert of het maximaal aantal tekens lager is dan 10 en anders geeft hij een melding (bijv. statusbalk) dat het maximaal aantal tekens zijn bereikt.
Dat is gewoon een correcte methode.

[RobIII]

Amras schreef op dinsdag 14 mei 2013 @ 14:10:
[...]

In C# kun je een property als volgt definieren:

C#:

public string Naam
{
    get;
    set;
}

wat syntactic sugar is voor:

C#:

private string _naam;

public string GetNaam()
{
    return _naam;
}

public void SetNaam(string naam)
{
    _naam = naam;
}

Niet helemaal; in .Net zijn properties gewoon echt ("first class?") class members. Ergens, nog wat dieper (in de MSIL ofzo) zullen de GetNaam() en SetNaam() methods wel bestaan, maar de auto-implemented properties zijn dus eigenlijk syntactic sugar voor:

C#:

private string _naam;

public string Naam
{
    get { return _naam; }
    set { _naam = value; }
}

[Amras]

RobIII schreef op dinsdag 14 mei 2013 @ 14:20:
[...]

Niet helemaal; in .Net zijn properties gewoon echt ("first class?") members. Ergens, nog wat dieper (in de MSIL ofzo) zullen de GetNaam() en SetNaam() methods wel bestaan, maar de auto-implemented properties zijn dus eigenlijk syntactic sugar voor:

C#:

private string _naam;

public string Naam
{
    get { return _naam; }
    set { _naam = value; }
}

Er zit inderdaad een stapje tussen, jouw voorbeeld is dan weer syntactic sugar voor het stukje wat ik postte.

[RobIII]

BoringDay schreef op dinsdag 14 mei 2013 @ 14:17:
Het zijn absoluut geen side effects maar notify events.

WTF heeft dit met OOP te maken? Waarom gaat 't in hemelsnaam hierover? (Overigens moet je eens kijken naar AOP ofzo voor dat soort zaken).

BoringDay schreef op dinsdag 14 mei 2013 @ 14:17:
Op het moment van een wijziging wil je dat er een bepaalde handeling wordt uitgevoerd.

Helemaal niet; in de meeste gevallen wil je dat niet en als je dat wil maak je gebruik van een convention, zoals ik eerder aangaf, als INotifyPropertyChanged en niet om zelf "intern" zaken te gaan lopen triggeren (DB access ofzo). Daar zijn methods voor. Properties moeten, doorgaans, geen side-effects hebben.

Maar nogmaals: vorige paragraaf heeft helemaal geen zak met wel/niet OOP te maken. OOP is encapsulation, (data) abstraction, inheritance en polymorphism. Of je nou methods of properties gebruikt om een kleur van een car object te wijzigen heeft daar geen zak mee van doen.

Verder:

Creepy schreef op dinsdag 14 mei 2013 @ 13:52:

_{Ow: en wil je misschien niet zelfs enters in paragraven toevoegen? Het loopt vanzelf door naar de juiste regel}

Wil je daar even op letten?
Het leest nogal
vervelend als er
op arbitraire plaatsen
in je post(s) steeds
enters staan

Amras schreef op dinsdag 14 mei 2013 @ 14:22:
[...]

Er zit inderdaad een stapje tussen, jouw voorbeeld is dan weer syntactic sugar voor het stukje wat ik postte.

Uiteindelijk wel ja, dat was inderdaad 't punt (En dat je op die manier geen SetNaam() of GetNaam() op je object zult kunnen aanroepen, want je "ziet" ze niet)

[ Voor 33% gewijzigd door RobIII op 14-05-2013 14:57 ]

[NMe]

BoringDay schreef op dinsdag 14 mei 2013 @ 14:17:
[...]

Het zijn absoluut geen side effects maar notify events.
Op het moment van een wijziging wil je dat er een bepaalde handeling wordt uitgevoerd.
Zo werkt het ook met edit object die bijvoorbeeld maximaal 10 tekens mogen hebben.
Iemand is aan het typen, edit.text krijgt een waarde en valideert of het maximaal aantal tekens lager is dan 10 en anders geeft hij een melding (bijv. statusbalk) dat het maximaal aantal tekens zijn bereikt.
Dat is gewoon een correcte methode.

Events/triggers hangen aan je code om een statusbalk te updaten? Probeer dat zonder kennis van het systeem maar eens te debuggen dan...

Misschien dat het voor jou lekker werkt maar neem nou eens aan van anderen dat dat absoluut geen industriestandaard is.

[RobIII]

NMe schreef op dinsdag 14 mei 2013 @ 14:38:
[...]

Events/triggers hangen aan je code om een statusbalk te updaten?

Nou... ja. Eigenlijk wel. Dat is precies waar een event/callback (of observer pattern (ook wel publish/subscribe)) voor bedoeld is; maar niet op de manier zoals BoringDay dat doet (of zoals ik 't in ieder geval begrijp).

Wisten jullie trouwens dat Anders Hejlsberg aan de wieg van Delphi én C# heeft gestaan?

Anyway; dit topic is 't schoolvoorbeeld waarom we Welke programmeertaal moet ik leren? topics niet toestaan. Het verzandt altijd in een "mijn taal/IDE/framework/whatever is beter!". Daar heeft iedereen, ook een aantal "roden" waaronder ikzelf, zich toe laten verleiden (en 't is ook verdomd moeilijk niet te reageren op sommige zaken). Ik zou willen zeggen: ontopic maar weer. Het is echter de vraag wat "ontopic" bij een toch-al-niet-gewenst-topic is... Ik wil 't nog wel even aankijken, maar heb eigenlijk weinig goede hoop

[ Voor 38% gewijzigd door RobIII op 14-05-2013 15:18 ]

[BoringDay]

NMe schreef op dinsdag 14 mei 2013 @ 14:38:
[...]

Events/triggers hangen aan je code om een statusbalk te updaten? Probeer dat zonder kennis van het systeem maar eens te debuggen dan...

Misschien dat het voor jou lekker werkt maar neem nou eens aan van anderen dat dat absoluut geen industriestandaard is.

Als je object georienteerd programmeerd dan kan je toch dat prima achterhalen?
Daarnaast een applicatie van redelijke omvang doorgrond je nooit 1,2,3 ongeacht hoe ervaren je bent.
Hoe denk je componenten werken? die hebben toch events? in Delphi namelijk heeft praktisch elke component events. En veel properties getters en setters. Zo werkt het al meer dan 10 jaar.
Wat heb je anders aan OOP?

Stel dat ik een item selecteer in een listbox,
Dat is het toch prachtig dat ik alleen maar die listbox hoef te selecteren en te kijken naar de event OnSelected(item)? Als dat geen goede methode is ga ik me wel een beetje zorgen maken.

[ Voor 13% gewijzigd door BoringDay op 14-05-2013 15:22 ]

[RobIII]

BoringDay schreef op dinsdag 14 mei 2013 @ 15:19:
Hoe denk je componenten werken? die hebben toch events? in Delphi namelijk heeft praktisch elke component events. En veel properties getters en setters. Zo werkt het al meer dan 10 jaar.
Wat heb je anders aan OOP?

Laatste keer: WTF hebben events met OOP te maken? Het hele woord 'event' komt (in die context) niet eens voor op de wiki over OOP. Dat je in Delphi objecten (componenten) hebt die events exposen: leuk. Maar dat is niet wat OOP is.

Kunnen we nu, as said, hierover ophouden? Als je hierover door wil gaan, open dan even een eigen/nieuw topic.

[ Voor 64% gewijzigd door RobIII op 14-05-2013 15:48 ]

[EddoH]

Sorry BoringDay, maar ik denk dat jij OOP in een hele andere context ziet dan de meeste hier. Je haalt constant 'componenten' en 'events' aan. Beide hebben niets met OO an-sich te maken. Ik denk dat je een beetje geconditioneerd bent door je IDE, en de manier waarop je in Delphi componenten en dergelijke kan maken en aan elkaar knopen. Je zult vast veel aspecten van OO begrijpen, maar soms sla je de plank zo erg mis dat het bijna pijnlijk wordt, helemaal als je anderen van je gelijk probeert te overtuigen

On topic: volgens mij is de TS al tijden geleden afgehaakt, maar als ik dan een taal mag asanbevelen om het programmeren an sich onder de knie te krijgen dan zou ik met Java beginnen: relatief verbose, compleet OO, en genoeg tooling/voorbeelden.

[BoringDay]

RobIII schreef op dinsdag 14 mei 2013 @ 15:23:
[...]

Laatste keer: WTF hebben events met OOP te maken? Het hele woord 'event' komt (in die context) niet eens voor op de wiki over OOP. Dat je in Delphi objecten (componenten) hebt die events exposen: leuk. Maar dat is niet wat OOP is.

Kunnen we nu, as said, hierover ophouden? Als je hierover door wil gaan, open dan even een eigen/nieuw topic.

Nee dat is idd event-driven wat nauw samenhangt.
Anyway ieder zijn manier en kennis, I seal my lips

[Corniel]

De theoretische stellingen die worden ingenomen onderschrijven mijn eerdere vraag (die door de TS nog steeds niet beantwoord is): wat wil de TS bereiken met het leren programmeren?

Wat goed OO(P) is, is onderhevig aan discussie, en welke taal daarbij dat het beste faciliteert is onderhevig aan alleen maar meer discussie. Zonder verdere input is daar niets zinnigs over te zeggen.

Dan over wat C# onder water doet: probeer eens

C#:

var tp = typeof(MyClass);
var members = tp.GetMembers();
var methods = tp.GetMethods();

En je zal zien dat je daar al get_- en set_-methods zijn en members met de naam van de properties. Edoch dit terzijde.

[Laurens-R]

Back to topic: want ik kan me voorstellen dat door bovenstaande discussie de TS al helemaal niet meer weet wat hij moet doen.

My two cents:

Kies een taal waar je je gemakkelijk bij voelt. En hoewel de meer ervaren programmeurs ieder hun eigen voorkeur hebben en al meningen hebben gevormd over diverse design principes e.d. denk ik dat dit eerlijk gezegd nog niet iets is waar je je in het begin niet direct druk om moet maken, hoewel het geen kwaad kan (en aan te bevelen is) om je hier eens in te verdiepen.

Wat belangrijker is dat je eerst een taal vind die je ligt en dat je vanaf daar verder gaat. Raak eerst bekend met logisch redeneren e.d. en raak bekend met hoe je om kan gaan met bepaalde programmeer vraagstukken. Denk hierbij aan sorteerproblemen, datastructuren e.d. Meestal raak je dan ook al dingen aan die over OOP gaan. Of dat nou in een C# console app gedaan word, of in een (even vloeken) PHP pagina maakt niet zo gek veel uit.

Vanuit daar kan je een bredere basis uitbouwen en bekend raken met OOP, Design Patterns, Geavanceerdere datastructures en de diverse talen en frameworks die er bestaan.

Ik hoop dat je programmeren ook echt leuk vind om te doen, want anders word het een lange rit en zal je naar alle waarschijnlijkheid links en rechts ingehaald worden door mensen die er echt een passie voor hebben (als je dit ook carrièretechnisch ambieert)

[ Voor 15% gewijzigd door Laurens-R op 14-05-2013 16:51 ]

[Anoniem: 440534]

TS zal wel afgehaakt zijn, maar ik vind het nog wel nuttig. Ik ben begonnen aan Informatica en daar zijn ze me eerst java aan het leren. Maar dit artikel:

http://www.crosstalkonlin...8/200801/200801-Dewar.pdf met het stuk: "The Pitfalls of Java as a First Programming Language" heeft wel argumenten waar ik gevoelig voor ben.

"Students found it hard to write programs that did not have a graphic interface, had no feeling for the
relationship between the source program and what the hardware would actually do, and (most damaging) did not understand the semantics of pointers at all, which made the use of C in systems programming very challenging"

Uiteindelijk adviseren ze om met Python te beginnen. Nu ben ik eigenwijs genoeg om tegen de makers van mijn curriculum in te gaan en eerst python te gaan doen, maar ze doen het niet voor niks zo natuurlijk en jullie hier ook niet. Wat zou ik voor problemen tegenkomen als ik eerst Python doe en daarna verder ga met Java?

[NMe]

Geen. Met welke taal je begint is totaal niet relevant voor het leerproces. Wat wel belangrijk is, is dat je jezelf geen foute dingen aan moet leren en je dus heel zeker moet weten dat je zelfstudie een goede leerbron gebruikt.

Overigens is dat argument ook niet zo steekhoudend wat mij betreft. Juist in Java heb je een brede keuze aan RAD-omgevingen en IDE's (zelfs een speciaal voor studenten: BlueJ) waarin je uiteindelijk direct kan zien wat je wil. Python heeft dat weer niet. Hoe kunnen ze enerzijds zeggen dat niet direct grafische terugkoppeling krijgen een probleem is en anderzijds dat Python een goed plan is?

[Ozzie]

Ik kan in dat artikel ook niet terugvinden dat ze Python adviseren. Python word in het hele artikel niet genoemd.

Ik denk ook dat het niets uitmaakt welke taal je kiest. Al zou mijn voorkeur bij het leren programmeren wel liggen bij een strong-typed taal en het liefst eentje waarbij er ook hele duidelijke conventies zijn afgesproken, zoals bij Java of C#.
De basis van programmeren is in elke taal zo goed als hetzelfde. Als je in Java een for-loop kan maken dan kan je dat ook in C, C++, C#, etc. Als je wilt leren over pointers e.d. zal je toch C/C++ moeten leren maar voor de basis is dat momenteel helemaal niet meer nodig.

[Anoniem: 440534]

Oh, sorry. Ik zie dat ik een stapje overgeslagen heb. In een ander artikel adviseren ze Python, en om dat te onderschrijven geeft hij deze link als extra reden om het niet met Java te doen.

Ik zag dat het ook al redelijk 'oud' advies was en deze draad is van 2013, dus vandaar. Ik denk dat ik maar doorga met Java dan en de twijfels die het artikel me gaven maar even vergeet.

[NMe]

Java heeft in de afgelopen 15 jaar nogal een transformatie doorgemaakt maar zelfs in de beginjaren waren er best IDE's en RAD-omgevingen voor te vinden. Python heeft die bij mijn weten juist amper tot niet. Dus ik snap nog steeds de conclusie niet.

[supreme tweaker]

Ik ben ook ooit als programmeur met Java begonnen en dat is me eigenlijk meer dan prima bevallen! De argumenten dat je geen verstand hebt van pointers (vaak ook irrelevant, maar geen stretch vanaf Java) en dat je niet zou leren programmeren, enkel assembleren van code lijken me dan ook een beetje uit de lucht gegrepen. Ja, Java (en C# ook) moedigen aan tot het gebruiken van het onderliggende framework, maar dat doet niets af aan wat je hier van leert. Het is ook onzinnig om alle studenten weer een Math library in elkaar te laten zetten.

[ZpAz]

RobIII schreef op dinsdag 14 mei 2013 @ 13:45:
[...]

With all due respect; hoe goed ben jij eigenlijk bekend met OOP? Want ik zie je her-en-der toch aardig de plank mis slaan

Dat verschilt dan per taal volgens mij, want in bijvoorbeeld Objective-C is dit volgens mij een veelgebruikte praktijk. Het "synthesizen" van properties is daar niets meer dan de compiler of preprocessor vertellen dat hij de getters en setters voor jou moet genereren voor die property. Wil je dat er iets anders gebeurt dan maak je de betreffende methode's zelf. Doe je geen van beide krijg je een error.


Iets als this.foo = "baz" updated daar de instatie variabele _foo oid by default via de setter [this setFoo:"baz"]. Rechtstreeks _foo dan aanpassen is wel vragen om problemen.


@Hieronder, sorry inderdaad. We waren al weer wat berichtjes verder. Maar nergens stelde ik of het dan meer of minder OO was, enkel anders.

[ Voor 24% gewijzigd door ZpAz op 24-06-2013 17:02 ]

[Creepy]

ZpAz: lees ook even mijn post daar onder. Niet elke omgeving heeft dat, maar dat maakt die omgeving niet minder OO dan anderen. Dat werd echter wel zo gebracht en daar reageerde RobIII op. Dus kunnen we die discussie AUB achter ons laten?

[drm]

Ralmuski:
Oh, sorry. Ik zie dat ik een stapje overgeslagen heb. In een ander artikel adviseren ze Python, en om dat te onderschrijven geeft hij deze link als extra reden om het niet met Java te doen.

Ik zag dat het ook al redelijk 'oud' advies was en deze draad is van 2013, dus vandaar. Ik denk dat ik maar doorga met Java dan en de twijfels die het artikel me gaven maar even vergeet.

Java is een prima taal om veel van te leren. Het mooie is dat het namelijk een behoorlijk stricte taal is en er weinig sprake is van uitzonderingen, waardoor je goed leert snappen hoe de taal werkt, en op den duur waarom hij zo werkt. De strictheid helpt je om goed na te denken over een gedegen structuur, en zal je helpen om in objecten en verantwoordelijkheden te denken.

In Python (een fantastisch taaltje, overigens) word je daarin juist veel te vrij gelaten. Je kan alles fout doen wat je maar zou willen, wat enorme complexiteit, onbeheersbaarheid en ondoorzichtigheid van je code met zich mee kan brengen. Je gaat het dan meer over principiele keuzes hebben, in plaats van over compilerfoutmeldingen. Dat is voor een beginnende programmeur niet goed. Die moet op zijn kloten krijgen als 'ie iets niet goed doet en dat gebeurt in Java sneller. Geldt overigens ook voor C#. Python zou ik dus nooit als leertaal aanraden. Wel als leuk speelgoed.

---

offtopic:
Bizar dat niemand BoringDay op __get() en __set() gewezen heeft?

[Janoz]

Anoniem: 440534 schreef op maandag 24 juni 2013 @ 14:36:
http://www.crosstalkonlin...8/200801/200801-Dewar.pdf met het stuk: "The Pitfalls of Java as a First Programming Language" heeft wel argumenten waar ik gevoelig voor ben.

"Students found it hard to write programs that did not have a graphic interface, had no feeling for the
relationship between the source program and what the hardware would actually do, and (most damaging) did not understand the semantics of pointers at all, which made the use of C in systems programming very challenging"

"found it hard to write programs that did not have a graphic interface," deed mij fronsen. Java 'eist' helemaal geen GUI. Console applicaties zijn juist veel simpeler te implementeren dan applicaties met GUI's. Ik vermoed dan ook dat ze meer ageren tegen brakke Java cursussen dan tegen Java (misschien wel zonder dat ze het zelf doorhebben )

Les geven in programmeren kan in bijna elke taal. Vooral een college over datastructuren en bijbehorende algoritmen is heel nuttig en gewoon taalonafhankelijk. Een tree in python, pascal of C# werkt gewoon hetzelfde als in Java en Object C. Het collection framework van Java is immers ook gewoon in Java geschreven (en ik denk dat dat voor C# niet anders is). Ter leering ende vermaack kunnen studenten gewoon hun eigen implementatie maken. Goed, je leert geen pointers, maar de achterliggende concept (pass by reference en deep copy ed) komen dan wel gewoon aan bod.

Ja, alle talen behalve php dan, want die heeft geen arrays .

[Hydra]

Janoz schreef op dinsdag 25 juni 2013 @ 16:20:
[...]


"found it hard to write programs that did not have a graphic interface," deed mij fronsen. Java 'eist' helemaal geen GUI. Console applicaties zijn juist veel simpeler te implementeren dan applicaties met GUI's. Ik vermoed dan ook dat ze meer ageren tegen brakke Java cursussen dan tegen Java (misschien wel zonder dat ze het zelf doorhebben )

Vond ook dat het artikel zich daarmee al diskwalificeerde. Hoe goed een 'course' is, is m.i. vrijwel volledig afhankelijk van de kwaliteit van het materiaal en de docenten. Een taal die whatever aangeleerd wordt goed ondersteunt is daarin een must, maar wat exact maakt verder weinig uit.

Ze reageren op de dalende kwaliteit van CS courses en komen tot de verkeerde conclusie dat, omdat Java ongeveer in dezelfde tijd geintroduceerd is, dat het daar dan wel aan moet liggen. Dat de kwaliteit van dergelijke opleiding daalt klopt, maar dit heeft alles te maken met de vercommercialisering opleidingsinstituten (en overheden die dat maar laten gebeuren) en helemaal niks met de gebruikte taal.

[NC83]

Anoniem: 440534 schreef op maandag 24 juni 2013 @ 14:36:
TS zal wel afgehaakt zijn, maar ik vind het nog wel nuttig. Ik ben begonnen aan Informatica en daar zijn ze me eerst java aan het leren. Maar dit artikel:

http://www.crosstalkonlin...8/200801/200801-Dewar.pdf met het stuk: "The Pitfalls of Java as a First Programming Language" heeft wel argumenten waar ik gevoelig voor ben.

"Students found it hard to write programs that did not have a graphic interface, had no feeling for the
relationship between the source program and what the hardware would actually do, and (most damaging) did not understand the semantics of pointers at all, which made the use of C in systems programming very challenging"

Uiteindelijk adviseren ze om met Python te beginnen. Nu ben ik eigenwijs genoeg om tegen de makers van mijn curriculum in te gaan en eerst python te gaan doen, maar ze doen het niet voor niks zo natuurlijk en jullie hier ook niet. Wat zou ik voor problemen tegenkomen als ik eerst Python doe en daarna verder ga met Java?

Dan kun je beter met Delphi beginnen omdat daar wel pointers bestaan en als het te moeilijk is om daar een compiler voor te vinden kun je ook gewoon C# gebruiken en #unsafe regions gebruiken om wel met pointers te werken.

Python kent ook geen pointers dus dat probleem zul je nog steeds hebben zodra je in een stuk C/C++ code terecht komt dat performance critical is.

Ik zelf ben begonnen met Pascal>Delphi>C#>Java>C++>Python, ik gebruik nu voornamelijk alleen nog C++, C# en Python(omdat dat van het werk moet anders liet ik die ook snel vallen hoor).

Trouwens het zou ook eens goed zijn om beginnende programmeurs procedureel programmeren aan te leren zodat ze weten wanneer een functie deel is van een Object en wanneer het een globale functie moet zijn. Globale helper functies zijn nog steeds hardstikke handig en beter dan een static member method in een static class.

[ Voor 8% gewijzigd door NC83 op 25-06-2013 19:23 ]

[martin_v_z]

NC83 schreef op dinsdag 25 juni 2013 @ 19:20:
[...]

Dan kun je beter met Delphi beginnen omdat daar wel pointers bestaan en als het te moeilijk is om daar een compiler voor te vinden kun je ook gewoon C# gebruiken en #unsafe regions gebruiken om wel met pointers te werken.

Python kent ook geen pointers dus dat probleem zul je nog steeds hebben zodra je in een stuk C/C++ code terecht komt dat performance critical is.

Ik zelf ben begonnen met Pascal>Delphi>C#>Java>C++>Python, ik gebruik nu voornamelijk alleen nog C++, C# en Python(omdat dat van het werk moet anders liet ik die ook snel vallen hoor).

Trouwens het zou ook eens goed zijn om beginnende programmeurs procedureel programmeren aan te leren zodat ze weten wanneer een functie deel is van een Object en wanneer het een globale functie moet zijn. Globale helper functies zijn nog steeds hardstikke handig en beter dan een static member method in een static class.

Delphi was toch tegenwoordig ook in gratis varianten beschikbaar?

Welke taal je ook kiest het is voornamelijk het logisch denken dat je moet leren. Als je lang genoeg programmeerd zal je code als ware in je hoofd kunnen uitvoeren, welke taal je dan gebruikt is minder relevant. Je zal echt met de basis moeten beginnen, wat zijn variabelen if statements loopjes enz. Daarna leren OOP en zelf vind ik het belangrijk dat je goed leert omgaan met geheugen. Dat laatste is wel een beetje tricky want veel moderne talen hebben garbage collectors.

Zelf ben ik als tiener begonnen met Basic (ja veel meer had ik in die tijd niet) volgende stap was VB, Pascal, Delphi nu vooral Java. Maar ik in de jaren heb ik vanalles en nog wat moeten gebruiken van ASM, PHP, C# en noem het maar op. Feit is dat als je de basis begrijpt een andere taal vrij eenvoudig op te pakken is.

Delphi is wel een leuke start, maar het wijkt in de syntax wel weer veel af van andere talen. Wat wel goed is aan Delphi is dat jij verantwoordelijk bent voor het geheugen dat objecten gebruiken. Een klein voordeeltje ten opzichte van C++ is dat het geheugen voor Strings voor je wordt geregeld.

Basic en Visual basic raad ik af, de syntax is niet erg fijn en je zal meer moeite hebben om een overstap te maken naar een andere taal. PHP is al helemaal geen goede start, de taal niet strict genoeg en probeert veel werk uit jou handen te nemen waardoor je misschien niet altijd goed begrijpt wat er gebeurd,

C# is ook een leuke taal om te beginnen. Het leest iets makkelijker dan C++, maar net als Java heeft het een garbage collector. Ik vind dat echt een minpunt voor een startende programmeur. Ik geef meer de voorkeur aan een taal waarin je verplicht bent na te denken over het geheugen gebruik.

[Hydra]

martin_v_z schreef op woensdag 26 juni 2013 @ 12:42:
C# is ook een leuke taal om te beginnen. Het leest iets makkelijker dan C++, maar net als Java heeft het een garbage collector. Ik vind dat echt een minpunt voor een startende programmeur. Ik geef meer de voorkeur aan een taal waarin je verplicht bent na te denken over het geheugen gebruik.

Juist voor een beginnende programmeur is een GC helemaal prima. Niks frustrerender voor een beginner dan pointer/allocatie-gerelateerde fouten moeten debuggen.

[martin_v_z]

Hydra schreef op woensdag 26 juni 2013 @ 16:05:
[...]


Juist voor een beginnende programmeur is een GC helemaal prima. Niks frustrerender voor een beginner dan pointer/allocatie-gerelateerde fouten moeten debuggen.

Mjah misschien het echte begin als in variabelen leren, for loopjes case statements enz. Maar zodra je OOP gaat leren programmeren zou ik eerder kiezen voor een taal zonder garbage collector.

Ik denk dat starten met Pascal en daarna overstappen op Delphi een goede leerwijze zou zijn. De taal is overzichtelijk en je leert iets dichterbij de machine dan bijvoorbeeld Java of C#. Het leuke van Pascal draaien in een VM is ook dat je geen Windows GUI hebt om mee te spelen. Gewoon simpel output op het scherm, ideaal om ook wat graphics basis op te doen.

[Megamind]

martin_v_z schreef op woensdag 26 juni 2013 @ 16:20:
[...]

Ik denk dat starten met Pascal en daarna overstappen op Delphi een goede leerwijze zou zijn. De taal is overzichtelijk en je leert iets dichterbij de machine dan bijvoorbeeld Java of C#. Het leuke van Pascal draaien in een VM is ook dat je geen Windows GUI hebt om mee te spelen. Gewoon simpel output op het scherm, ideaal om ook wat graphics basis op te doen.

Misschien leuk om mee te rommelen, maar bestaat Delphi en Pascal nog dan

[martin_v_z]

Delphi wordt nog veel gebruikt voor database applicaties. Tot 2012 verdiende ik mijn brood er nog mee. Maar als ik zelf nu de keus zou hebben voor de taal voor een nieuwe applicatie zal mijn keus eerder op C# liggen. neemt niet weg dat Delphi een hele goede taal is om te leren met objecten en pointers om te gaan. De leercurve ligt lager dan C++. Daarna kan is het vrij gemakkelijk om over te stappen naar C#, C++ of Java

[Hydra]

martin_v_z schreef op woensdag 26 juni 2013 @ 19:44:
Delphi wordt nog veel gebruikt voor database applicaties.

Ja, vooral door bedrijven met ouwe kerels die geen nieuwe truukjes willen of kunnen leren.

[Zoijar]

Hydra schreef op woensdag 26 juni 2013 @ 16:05:
Juist voor een beginnende programmeur is een GC helemaal prima. Niks frustrerender voor een beginner dan pointer/allocatie-gerelateerde fouten moeten debuggen.

En niets leerzamers...

Ik zou ze meteen over pointers en geheugen leren. Dan over ontwerp, object lifetimes, resources en ownership. Er is eigenlijk geen basiskennis waar ik tijdens mijn hele studie meer aan heb gehad dan mijn toenmalige kennis van 80386 assembly programmeren.

GC maakt lui en is in de meeste gevallen gewoon niet nodig indien je op je ontwerp let. Ik vind de route van C naar C++ heel prima om te leren.

[martin_v_z]

Zoijar schreef op woensdag 26 juni 2013 @ 20:17:
[...]

En niets leerzamers...

Ik zou ze meteen over pointers en geheugen leren. Dan over ontwerp, object lifetimes, resources en ownership. Er is eigenlijk geen basiskennis waar ik tijdens mijn hele studie meer aan heb gehad dan mijn toenmalige kennis van 80386 assembly programmeren.

GC maakt lui en is in de meeste gevallen gewoon niet nodig indien je op je ontwerp let. Ik vind de route van C naar C++ heel prima om te leren.

Ik geef zelfs de voorkeur aan geen GC. Het voelt telkens alsof ik moet vertrouwen op een magisch mechanisme dat het geheugen wel vrij gaat geven. Sterker nog ik heb er vorige maand nog flink mee lopen worstelen, ik kreeg out of memory errors omdat de GC niet op tijd het geheugen vrij gaf.

[ZpAz]

Ik vertrouw zelfs niet op functies, het is alsof ik moet vertrouwen op een magisch mechanisme wat de scope van mijn variabelen beïnvloed.

Iets met juiste gereedschap en baan enzo.

[PrisonerOfPain]

Hydra schreef op woensdag 26 juni 2013 @ 16:05:
[...]


Juist voor een beginnende programmeur is een GC helemaal prima. Niks frustrerender voor een beginner dan pointer/allocatie-gerelateerde fouten moeten debuggen.

Goed maar die heb je zo onder de knie, en daarbij is low-level kennis (bitshiften is niet lowlevel) nooit verkeerd.

ZpAz schreef op woensdag 26 juni 2013 @ 21:59:
Ik vertrouw zelfs niet op functies, het is alsof ik moet vertrouwen op een magisch mechanisme wat de scope van mijn variabelen beïnvloed.

Iets met juiste gereedschap en baan enzo.

Hij heeft wel een punt, geheugen problemen worden door een GC meer verbloemdt en tegen de tijd dat je er tegenaan loopt zul je ook moeten weten hoe een GC werkt en dan moet je als nog weten hoe geheugen allocaties werken.

[Hydra]

PrisonerOfPain schreef op woensdag 26 juni 2013 @ 22:22:
Goed maar die heb je zo onder de knie, en daarbij is low-level kennis (bitshiften is niet lowlevel) nooit verkeerd.

Hij heeft wel een punt, geheugen problemen worden door een GC meer verbloemdt en tegen de tijd dat je er tegenaan loopt zul je ook moeten weten hoe een GC werkt en dan moet je als nog weten hoe geheugen allocaties werken.

Dat soort dingen leer je door goed onderwijs, niet door een antieke taal te gebruiken.

[PrisonerOfPain]

Hydra schreef op woensdag 26 juni 2013 @ 22:34:
[...]


Dat soort dingen leer je door goed onderwijs, niet door een antieke taal te gebruiken.

Mwa, je moet je taal kiezen op wat je er mee wilt doen. Of eigenlijk, wat voor problemen je op wilt lossen.

Persoonlijk ben ik heel erg te spreken van de voorspelbaarheid van C. Je weet wat precies wat er in je geheugen staat, je weet wat voor code er door de processor uitgevoerd word, je weet de welke registers je argumenten mee gegeven worden, wanneer je geheugen word vrijgegeven, je weet wat er gebeurd als je thread in het geheugen van een ander schrijft. Maar goed, ik los dan ook graag low-level problemen op

[Zoijar]

Hydra schreef op woensdag 26 juni 2013 @ 22:34:
Dat soort dingen leer je door goed onderwijs, niet door een antieke taal te gebruiken.

C++11 is nou niet echt een antieke taal te noemen En hoe onderwijs je dat dan? Moet je goed op letten, maar... je framework doet het verder zelf automagisch

[ Voor 18% gewijzigd door Zoijar op 26-06-2013 23:11 ]

[PatrickH89]

Ik denk persoonlijk dat het niet uitmaakt waar je mee begint, als je maar het juiste doel voor ogen hebt. Als je low-level bezig wilt gaan zijn in de toekomst kun je het prima alvast leren, maar als je doel is om voornamelijk in de iets higher-level talen te blijven werken (waarvan er veel zijn) kun je net zo goed het hele gebeuren overslaan tot je er daadwerkelijk mee te maken krijgt.

[Hydra]

Zoijar schreef op woensdag 26 juni 2013 @ 23:10:
C++11 is nou niet echt een antieke taal te noemen En hoe onderwijs je dat dan? Moet je goed op letten, maar... je framework doet het verder zelf automagisch

Een goeie opleiding geeft natuurlijk niet alleen onderwijs in Java, je leert ook andere aspecten kennen. Maar door correct OO te programmeren heb je als het goed is geen problemen met de lifespan van je objecten. Natuurlijk is het altijd mogelijk domme inefficiente zaken te doen maar een goeie docent zal je daar op afrekenen.

Pointer-math levert m.i. in grote applicaties meer problemen op dan dat het zin heeft. Het is niet voor niets dat grote enterprise-omgeving (en dat is waar de meeste developers toch echt terecht gaan komen, d'r zijn er niet zo veel die bij DICE aan de Frostbite engine gaan werken) meestal op VM talen als Java gebaseerd zijn.

Ik ben het er helemaal mee eens dat een developer ook in C++ en Assembly (en Fortran en Prolog etc.) aan de slag moet, maar dat is HEEL wat anders dan een beginnende programmeur met C++ laten beginnen. Dat is echt nergens voor nodig en leidt m.i. eerder tot rommelcode omdat C++ je een stuk vrijer laat dan (bijvoorbeeld) Java.

[PrisonerOfPain]

Hydra schreef op donderdag 27 juni 2013 @ 10:34:
Een goeie opleiding geeft natuurlijk niet alleen onderwijs in Java, je leert ook andere aspecten kennen. Maar door correct OO te programmeren heb je als het goed is geen problemen met de lifespan van je objecten. Natuurlijk is het altijd mogelijk domme inefficiente zaken te doen maar een goeie docent zal je daar op afrekenen.

Correct OO heeft niet zo veel met de life-time van objecten te maken, zodra je complexere object interacties hebt zul je daar over na moeten denken. In managed talen is het echter zo dat, omdat ze GC'd zijn, je je daar niet over druk hoeft te maken omdat je object gewoon zo lang mogelijk in leven gehouden word. In een native taal loop je wel tegen dit soort dingen aan; als een pointer op verschillende plaatsen gefree'd mag kan worden bijvoorbeeld.

Verder is er natuurlijk een veel fundamenteler probleem, namelijk dat niet in alle gevallen OO de juiste aanpak is.

Pointer-math levert m.i. in grote applicaties meer problemen op dan dat het zin heeft. Het is niet voor niets dat grote enterprise-omgeving (en dat is waar de meeste developers toch echt terecht gaan komen, d'r zijn er niet zo veel die bij DICE aan de Frostbite engine gaan werken) meestal op VM talen als Java gebaseerd zijn.

Ik heb een beetje het idee dat je je reactie nu alleen op mij richt, terwijl er een vrij groot aantal developers op tweakers rondloopt die geen "enterprise" applicaties maakt; sterker nog, ik ben positief verbaast over de hoeveelheid C++ developers die we hier rond hebben lopen. Maar goed, programmeren doe je om een bepaald probleem op te lossen, als dat een business probleem is heb je 9/10 keer een betere keus met een GC taal.

Ik ben het er helemaal mee eens dat een developer ook in C++ en Assembly (en Fortran en Prolog etc.) aan de slag moet, maar dat is HEEL wat anders dan een beginnende programmeur met C++ laten beginnen. Dat is echt nergens voor nodig en leidt m.i. eerder tot rommelcode omdat C++ je een stuk vrijer laat dan (bijvoorbeeld) Java.

Een beginnend programmeur schrijft altijd rommelcode, dat duurt gewoon een flink aantal jaar om dat er uit te krijgen, onafhankelijk van de taal.

[Hydra]

PrisonerOfPain schreef op donderdag 27 juni 2013 @ 10:55:
Ik heb een beetje het idee dat je je reactie nu alleen op mij richt, terwijl er een vrij groot aantal developers op tweakers rondloopt die geen "enterprise" applicaties maakt; sterker nog, ik ben positief verbaast over de hoeveelheid C++ developers die we hier rond hebben lopen. Maar goed, programmeren doe je om een bepaald probleem op te lossen, als dat een business probleem is heb je 9/10 keer een betere keus met een GC taal.

Het is niet aan jou gericht, maar aan al die 'beginnende programmeurs' die denken dat ze uiteindlijk voor een game company komen te werken

Ennuh, zo heel veel mensen komen hier niet die echt voor hun werk full-time programmeren. Relatief gezien is dit een heel erg kleine (en dus niet representatieve) community.

Een beginnend programmeur schrijft altijd rommelcode, dat duurt gewoon een flink aantal jaar om dat er uit te krijgen, onafhankelijk van de taal.

Tuurlijk. En ik ben het er 100% mee eens dat je als developer met C++ gewerkt moet hebben, maar ik vind het complete onzin mensen aan te raden daar mee te beginnen. Dan ben je een beetje blind geworden voor de leerdrempel t.o.v. simpelere talen.

[PrisonerOfPain]

Hydra schreef op donderdag 27 juni 2013 @ 11:09:
Het is niet aan jou gericht, maar aan al die 'beginnende programmeurs' die denken dat ze uiteindlijk voor een game company komen te werken

Wat dat betreft loopt dit forum meer over van beginnende "laat ik ook maar eens een CMS bouwen" programmeurs of wannabe- architects.

Ennuh, zo heel veel mensen komen hier niet die echt voor hun werk full-time programmeren. Relatief gezien is dit een heel erg kleine (en dus niet representatieve) community.

Tuurlijk. En ik ben het er 100% mee eens dat je als developer met C++ gewerkt moet hebben, maar ik vind het complete onzin mensen aan te raden daar mee te beginnen. Dan ben je een beetje blind geworden voor de leerdrempel t.o.v. simpelere talen.

Ik had het in eerdere posts dan ook expliciet over C. Een simpelere taal is moeilijk te vinden.

[martin_v_z]

Hydra schreef op donderdag 27 juni 2013 @ 10:34:
[...]


Een goeie opleiding geeft natuurlijk niet alleen onderwijs in Java, je leert ook andere aspecten kennen. Maar door correct OO te programmeren heb je als het goed is geen problemen met de lifespan van je objecten. Natuurlijk is het altijd mogelijk domme inefficiente zaken te doen maar een goeie docent zal je daar op afrekenen.

Pointer-math levert m.i. in grote applicaties meer problemen op dan dat het zin heeft. Het is niet voor niets dat grote enterprise-omgeving (en dat is waar de meeste developers toch echt terecht gaan komen, d'r zijn er niet zo veel die bij DICE aan de Frostbite engine gaan werken) meestal op VM talen als Java gebaseerd zijn.

Ik ben het er helemaal mee eens dat een developer ook in C++ en Assembly (en Fortran en Prolog etc.) aan de slag moet, maar dat is HEEL wat anders dan een beginnende programmeur met C++ laten beginnen. Dat is echt nergens voor nodig en leidt m.i. eerder tot rommelcode omdat C++ je een stuk vrijer laat dan (bijvoorbeeld) Java.

Omdat slechts een kleiner deel van de markt low level programmeertalen gebruikt is het natuurlijk niet direct slecht om te leren. Het gaat niet zo zeer om de taal maar wel om de kennis die je op doet van het werken in deze talen. Ik ben het met je eens dat goede onderwijs al veel kan leren, maar als ik naar mijzelf kijk leer ik toch het beste door daadwerkelijk zelf aan de slag te gaan. Als jij goede kennis hebt van geheugenbeheer dan is het weer beter te begrijpen wat een GC hoort te doen en hoe eventueel het gewenste resultaat kan bereiken.

Zoals ik schreef ben ik zelf als tiener begonnen met Basic, nou niet echt een mooie taal en zeker niet low level. Maar het heeft mij wel veel geholpen om de basis van prgrammeren te leren en veel kennis opgedaan voor grafische bewerkingen. Dit laatste heb ik nog steeds profijt van doordat ik makkelijk zelf routines schrijf om naar een canvas te tekenen, dit deden mijn collegas niet.

Doordat bij Delphi de VCL source code werd meegeleverd heb ik veel ervaring op gedaan met het lezen en debuggen in andermans source code. Dit helpt mij nu ook weer nu ik voor Android programmeer door bij problemen gewoon libraries of de source code van Android zelf te debuggen.

Je moet je niet blind staren op dat nieuwe talen altijd beter zijn. Ja het is zo dat ik zelf voor een groot nieuw database pakket eerder C# zal gebruiken. Maar in de wereld van game development is het weer meer gebruikelijk om C++ te schrijven.

De vraag in het topic was alleen niet welke taal nu suprieur is maar welke welke taal de beste start is om programmeren te leren. Ik blijf er bij dat als je echt goed wil kunnen programmeren sommige basis essensieel is. En begrip van geheugen beheer vindt ik zelf een belangrijke basis kennis. Ik had ook kunnen schrijven dat iemand maar x86 asm moet gaan leren om echt low level te begrijpen wat je programma doet. Maar dit heb ik niet gedaan omdat de leercurve veel groter is en de meerwaarde is vrij klein.

[PrisonerOfPain]

martin_v_z schreef op donderdag 27 juni 2013 @ 11:18:
Als jij goede kennis hebt van geheugenbeheer dan is het weer beter te begrijpen wat een GC hoort te doen en hoe eventueel het gewenste resultaat kan bereiken.

Het is de eeuwen oude discussie, wil je een GC maken of wil je 'm gebruiken. Ik snap het punt dat Hydra probeert te maken wel, in zijn omgeving kom je namelijk gewoon vrij weinig geheugen gerelateerde problemen tegen en ben je veel meer gefocussed op het oplossen van business problemen en het omgaan met klanten. Allemaal prima, maar er is gewoon een andere kant aan software development en het is niet als ik hier in m'n eentje BF4 zit in te kloppen

[Hydra]

martin_v_z schreef op donderdag 27 juni 2013 @ 11:18:
Omdat slechts een kleiner deel van de markt low level programmeertalen gebruikt is het natuurlijk niet direct slecht om te leren.

Jemig. Ik blijf me hier herhalen zeg. Ik vind het wel typisch 'des tweakers' dat dingen die je zegt telkens verdraaid worden en daar dan op gereageerd wordt.

Ik heb NOOIT gezegd dat iets als C niet goed is om te leren. Integendeel; dingen als C, C++ en assembly zijn m.i. een must. Maar niet om mee te beginnen; pas als je de basics door hebt is het m.i. een goed idee om met low-level te beginnen.

Zoals ik schreef ben ik zelf als tiener begonnen met Basic, nou niet echt een mooie taal en zeker niet low level. Maar het heeft mij wel veel geholpen om de basis van prgrammeren te leren en veel kennis opgedaan voor grafische bewerkingen. Dit laatste heb ik nog steeds profijt van doordat ik makkelijk zelf routines schrijf om naar een canvas te tekenen, dit deden mijn collegas niet.

Ik ben zelf in QuickBasic begonnen in 1993 en daar heb ik een hoop van geleerd. Maar mezelf ook een hoop verkeerde dingen in aangeleerd. Ik vind het wel grappig dat je nu over Basic begint want eerder hadden we het over low-level talen en Basic is alles behalve low-level.

Daarnaast is Basic gewoon geen goeie start-taal. De syntax is gewoon crap en onoverzichtelijk en het nodigt je uit tot het creeren van spaghettimonsters. Mijn eerste grote QB game kon ik een maandje later zelf niet meer ontcijferen.

Doordat bij Delphi de VCL source code werd meegeleverd heb ik veel ervaring op gedaan met het lezen en debuggen in andermans source code.

M.i. is ander mans sourcecode proberen te lezen gewoon een enorm slechte manier van leren. Leren software developen is het leren zien van wat de problemen en deelproblemen zijn en deze kunnen opdelen in hapklare blokjes. Als een beginner naar andermans sourcecode kijkt leer je 'em vooral zooi te copy-pasten, waarvan de kans groot is dat er spul meekomt dat je niet nodig hebt en/of niet begrijpt.

Dit gedrag zie je veel bij slechte developers: copy-paste werk dat rechtstreeks van stackoverflow afkomt.

En nogmaals: ik zeg absoluut NIET dat 'basiskennis' (assembly, geheugenbeheer) geen goede kennis is. Maar dit soort 'basiskennis' betekent NIET dat je daar mee moet beginnen! Leren hoe geheugenallocatie werkt is nogal nutteloos als de persoon niet weet wat een array is bijvoorbeeld. En leren waarderen wat een GC voor je doet werkt ook een stuk beter als je later leert wat je allemaal extra moet doen.

[ Voor 8% gewijzigd door Hydra op 27-06-2013 11:33 ]

[PrisonerOfPain]

Hydra schreef op donderdag 27 juni 2013 @ 11:31:
Daarnaast is Basic gewoon geen goeie start-taal. De syntax is gewoon crap en onoverzichtelijk en het nodigt je uit tot het creeren van spaghettimonsters. Mijn eerste grote QB game kon ik een maandje later zelf niet meer ontcijferen.

Dat lag niet aan de taal, dat lag aan jezelf. Je was een beginner, in iedere taal schrijf je dan dat soort dingen. Ik ook. En dat is prima, zolang je er niet in blijft hangen. Er zijn genoeg mensen die met 6502 assembly begonnen zijn en nu gewoon hartstikke nette software schrijven. Het duurt jaren voor dat je weet hoe je netjes en goed te onderhouden software schrijft. En zo lang je taal je niet actief tegenwerkt kun je dat gewoon leren.

Hydra schreef op donderdag 27 juni 2013 @ 11:31:
En nogmaals: ik zeg absoluut NIET dat 'basiskennis' (assembly, geheugenbeheer) geen goede kennis is. Maar dit soort 'basiskennis' betekent NIET dat je daar mee moet beginnen!

En ik zeg dat het niet zo veel uit maakt. En nu ga ik weer aan het werk.

[ Voor 18% gewijzigd door PrisonerOfPain op 27-06-2013 11:40 ]

[Hydra]

PrisonerOfPain schreef op donderdag 27 juni 2013 @ 11:38:
Dat lag niet aan de taal, dat lag aan jezelf. Je was een beginner

Tuurlijk, maar dat neemt niet weg dat een beginnen het beste een taal kan pakken die zelf behoorlijk consistent / simpel is en een beginner daarin ondersteunt. Dan is het bovendien ook nog eens mooi meegenomen als die taal zelf veel gebruikt wordt in de professionele markt, maar dat is niet leidend: een goeie dev kan zonder problemen overstappen op iets anders.

[PrisonerOfPain]

Hydra schreef op donderdag 27 juni 2013 @ 11:41:
[...]


Tuurlijk, maar dat neemt niet weg dat een beginnen het beste een taal kan pakken die zelf behoorlijk consistent / simpel is en een beginner daarin ondersteunt. Dan is het bovendien ook nog eens mooi meegenomen als die taal zelf veel gebruikt wordt in de professionele markt, maar dat is niet leidend: een goeie dev kan zonder problemen overstappen op iets anders.

Niet alleen Java en C# voldoen aan die criteria. Simpel en consistent is C's middle name.

[Hydra]

PrisonerOfPain schreef op donderdag 27 juni 2013 @ 11:43:
Niet alleen Java en C# voldoen aan die criteria. Simpel en consistent is C's middle name.

Ja, maar dan komen we terug bij pointergeneuzel. En daarnaast vind ik persoonlijk dat 'men' beter kan starten met OO programmeren. Nu kun je dat simuleren in C maar m.i. is dan een Java of C# een betere keuze.

[Spockz]

Ik ben er zelf voorstander van om iemand juist te laten beginnen in een taal dat *niet* alles voor je doet of andere duidelijke minpunten heeft. Dit forceert je namelijk om stil te staan bij de details van hoe software en hardware samenwerken. Hiermee kweek je in je hoofd een (diep) besef van hoe je programma zich gedraagt en het belangrijkst *waarom*. Als je op dat moment switch naar een taal die iets voor jou makkelijker maakt, in het geval van GC je memorymanagement, dan ben je je dus nog steeds bewust van wat er gebeurt en gebruik je de vrijgekomen capaciteit om na te denken over complexere algoritmen en/of implementaties.

Naar mijn idee heeft een goede programmeur daarnaast ook een drive om *goede* code af te leveren, om niet slordig te programmeren en te proberen om patronen in de code te herkennen en over deze patronen te abstraheren.

Maw: je wordt een goede programmeur door ervaring op te doen en een besef te kweken van hoe het geheel (hardware en software) werkt.

TL;DR; Begin lekker in PHP (loop je gauw genoeg tegen bepaalde problemen aan) en groei door naar een taal die jou fijner lijkt.

[martin_v_z]

Hydra schreef op donderdag 27 juni 2013 @ 11:31:
[...]


Jemig. Ik blijf me hier herhalen zeg. Ik vind het wel typisch 'des tweakers' dat dingen die je zegt telkens verdraaid worden en daar dan op gereageerd wordt.

Ik heb NOOIT gezegd dat iets als C niet goed is om te leren. Integendeel; dingen als C, C++ en assembly zijn m.i. een must. Maar niet om mee te beginnen; pas als je de basics door hebt is het m.i. een goed idee om met low-level te beginnen.


[...]


Ik ben zelf in QuickBasic begonnen in 1993 en daar heb ik een hoop van geleerd. Maar mezelf ook een hoop verkeerde dingen in aangeleerd. Ik vind het wel grappig dat je nu over Basic begint want eerder hadden we het over low-level talen en Basic is alles behalve low-level.

Daarnaast is Basic gewoon geen goeie start-taal. De syntax is gewoon crap en onoverzichtelijk en het nodigt je uit tot het creeren van spaghettimonsters. Mijn eerste grote QB game kon ik een maandje later zelf niet meer ontcijferen.


[...]


M.i. is ander mans sourcecode proberen te lezen gewoon een enorm slechte manier van leren. Leren software developen is het leren zien van wat de problemen en deelproblemen zijn en deze kunnen opdelen in hapklare blokjes. Als een beginner naar andermans sourcecode kijkt leer je 'em vooral zooi te copy-pasten, waarvan de kans groot is dat er spul meekomt dat je niet nodig hebt en/of niet begrijpt.

Dit gedrag zie je veel bij slechte developers: copy-paste werk dat rechtstreeks van stackoverflow afkomt.

En nogmaals: ik zeg absoluut NIET dat 'basiskennis' (assembly, geheugenbeheer) geen goede kennis is. Maar dit soort 'basiskennis' betekent NIET dat je daar mee moet beginnen! Leren hoe geheugenallocatie werkt is nogal nutteloos als de persoon niet weet wat een array is bijvoorbeeld. En leren waarderen wat een GC voor je doet werkt ook een stuk beter als je later leert wat je allemaal extra moet doen.

Ik denk dat we het wel in grote lijnen eens zijn en ik probeer zeker niet jouw woorden te verdraaien. Wat betreft Basic ik schreef zelf dat het juist geen low level taal is en al eerder gaf ik aan dat ik niemand in deze tijd aan raad om daar mee aan de slag te gaan. Het punt wat ik probeerde te maken was dat doordat ik een taal (Basic) had die totaal geen GUI voor mij maakte ik de basis kon leren over hoe het scherm werkt en hoe je iets op het scherm kan tekenen. Daarmee gaf ik aan dat juist door een taal te kiezen die wat minder voor je doet je bepaalde basis kennis kan op doen.

Ik zou niet aanraden om met een OOP taal te beginnen, juist omdat je dan een factor er bij krijgt. De charme van Basic was dat je 1 main procedure had om te beginnen, veel simpeler kan het niet als je nog moet leren wat een variabele arrays enz is. Maar liever zeg ik dan C of Pascal omdat het gewoon betere talen zijn. Daarna kan je altijd overstappen naar C++, Delphi of zelfs een taal als C# of Java.

En source code lezen is niet hetzelfde als source code kopieren. Je kan veel leren van het lezen van andermans source code, zolang je ook maar wel goed je best doet om het te begrijpen. Ik heb genoeg mensen gezien die totaal de draad kwijt raakte als ze source code van andere moesten debuggen, gewoon niet weten wat belangrijk is en wat je kan overslaan. Dit is in mijn oppinie juist belangrijk als je full time wil gaan programmeren, je werkt namelijk bijna altijd in een team. Natuurlijk moet je ook het inzicht hebben om zelf problemen op te lossen en niet alles overnemen wat je op internet kan vinden. Ik neem aan dat jij zelf ook in de tijd bent begonnen zonder internet en alles moet leren met een paar voorbeeldjes en vooral zelf de helpfile te lezen en uitproberen.

[Zoijar]

Spockz schreef op donderdag 27 juni 2013 @ 12:18:
Ik ben er zelf voorstander van om iemand juist te laten beginnen in een taal dat *niet* alles voor je doet of andere duidelijke minpunten heeft.
[...]

TL;DR; Begin lekker in PHP

(verder wel eens met je verhaal, daar niet van, alleen een wat vreemde conclusie... PHP is een gedrocht, een convoluted mess; dat zou ik niemand leren)

[ Voor 7% gewijzigd door Zoijar op 27-06-2013 13:32 ]

[_js_]

Juist door te beginnen met Java/C# en van te voren uitdenken wat voor klasses je nodig hebt zorg je ervoor dat mensen leren van te voren na te denken over wat hun programma moet doen en hoe het ontworpen moet zijn. Als je met een procedurele taal begint dan bestaat het maken van een programma vaak met beginnen met programmeren en zorgen dat er iets van uitvoer is, en verdere functionaliteit wordt er wel tussen geplaatst, waardoor je al snel verschillende taken in een functie krijgt, het moeten herschrijven van het programma omdat blijkt dat sommige functionaliteit niet makkelijk blijkt in te voegen, etc.

Natuurlijk zijn er plaatsen waar OOP-technieken overbodig zijn of zelfs hinderend werken, maar het vooraf moeten bedenken hoe een programma er uit komt te zien is wel altijd nuttig, en dat is toch iets wat bij OOP meer aandacht krijgt dan bij andere technieken. En ook het leren van een lowleveltaal als assembly voegt veel toe aan je kennis over hoe computers en programmeertalen werken, dus dat raad ik iedereen aan.

[Hydra]

martin_v_z schreef op donderdag 27 juni 2013 @ 12:36:
[...]

Welke opleiding heb je gedaan?

[Spockz]

Zoijar schreef op donderdag 27 juni 2013 @ 13:31:
[...]



(verder wel eens met je verhaal, daar niet van, alleen een wat vreemde conclusie... PHP is een gedrocht, een convoluted mess; dat zou ik niemand leren)

Ben je tevreden met PHP: prima blijf maar lekker daar. Gaan er dingen jeuken dan ga je vanzelf op zoek naar iets beters en congrats met jou kijk ik wel verder.

[martin_v_z]

Hydra schreef op donderdag 27 juni 2013 @ 15:19:
[...]


Welke opleiding heb je gedaan?

Geen, ik ben zelf begonnen met programmeren toen ik jong was en op mijn 18e gestart als junior ontwikkelaar.

Overigens als er een optie bestaat om een opleiding te volgen heeft dat altijd de voorkeur. Ik had denk ik wel profijt kunnen hebben van een goede leraar in die tijd. Maar wat ik begreep uit de OP was dat TS programmeren wou leren zonder een opleiding te volgen.

[Zoijar]

Spockz schreef op donderdag 27 juni 2013 @ 15:43:
Ben je tevreden met PHP: prima blijf maar lekker daar. Gaan er dingen jeuken dan ga je vanzelf op zoek naar iets beters en congrats met jou kijk ik wel verder.

Mwja, ik ben dus helemaal geen voorstander van leren door wat prutsen; ik heb veel liever dat mensen het meteen goed leren te doen.

[Spockz]

Zoijar schreef op donderdag 27 juni 2013 @ 16:00:
[...]

Mwja, ik ben dus helemaal geen voorstander van leren door wat prutsen; ik heb veel liever dat mensen het meteen goed leren te doen.

Ik zeg ook nergens dat ze geen begeleiding zouden krijgen hoor. Maar inderdaad het in een keer goed aanleren kan goed werken, maar je leert het het best door zelf op je plaat te gaan en door uit eerste hand te ervaren waarom dingen vervelend zijn.

edit: Het gaat er mij niet zozeer om of ze denken dat PHP ruk is of niet, maar dat ze in staat zijn te groeien en verder kijken dan hun neus lang is.

[ Voor 13% gewijzigd door Spockz op 27-06-2013 16:11 ]

[Hydra]

Zoijar schreef op donderdag 27 juni 2013 @ 16:00:
[...]

Mwja, ik ben dus helemaal geen voorstander van leren door wat prutsen; ik heb veel liever dat mensen het meteen goed leren te doen.

Daarom is een opleiding m.i. onontbeerlijk. Je hebt mensen nodig die je op de vingers tikken als je dingen verkeerd doet.

[Megamind]

Hydra schreef op donderdag 27 juni 2013 @ 16:09:
[...]


Daarom is een opleiding m.i. onontbeerlijk. Je hebt mensen nodig die je op de vingers tikken als je dingen verkeerd doet.

Amen. Ik heb geprutst met hobby in PHP en Delphi toen ik 13 jaar was, pas met een opleiding én werkevaring heb ik inzicht gekregen in beter programmeren.

De tijd van hobbyprogrammeurs is wel een beetje voorbij (tenzij je PHPer bent )

[phex]

Megamind schreef op donderdag 27 juni 2013 @ 16:12:
[...]

De tijd van hobbyprogrammeurs is wel een beetje voorbij (tenzij je PHPer bent )

Auw

Volgens mij de programmeur nog steeds verantwoordelijk van de kwaliteit, niet de taal.

Ik heb genoeg rotzooi gezien dat was geproduceerd met "professionele" talen.

[ Voor 28% gewijzigd door phex op 27-06-2013 16:16 ]

[Hydra]

phex schreef op donderdag 27 juni 2013 @ 16:13:
Auw

Volgens mij de programmeur nog steeds verantwoordelijk van de kwaliteit, niet de taal.

Ik heb genoeg rotzooi gezien dat was geproduceerd met "professionele" talen.

Yup. Meestal geproduceerd door self-taught amateurs

[Laurens-R]

Ik denk dat je zowel gedegen theorie nodig hebt alsmede het hobbymatige 'prutsen' (waarbij je theorie uiteraard toepast) want anders kom je nooit direct in contact met alle problemen die je kan tegen komen.

Wat je op school/de uni leert is meestal toch heel formeel en degelijk... De wereld daarbuiten is dat echter niet; daar loop je tegen vele systemen en protocollen aan, het werk van andere programmeurs (die ook vinden dat hun het allemaal perfect doen), legacy systemen, infra problemen die invloed hebben op de architectuur... etc etc etc... Dat vereist toch enige 'praktische' ervaring/inzicht.

edit: desalniettemin moet elke programmeur verantwoordelijk worden gehouden voor enige prutswerk in productiesystemen waar klanten last van hebben. De uitdagingen hierboven praten improvisatie/prutswerk natuurlijk niet goed.

[ Voor 15% gewijzigd door Laurens-R op 27-06-2013 16:22 ]

[Hydra]

Laurens-R schreef op donderdag 27 juni 2013 @ 16:20:
Ik denk dat je zowel gedegen theorie nodig hebt alsmede het hobbymatige 'prutsen' (waarbij je theorie uiteraard toepast) want anders kom je nooit direct in contact met alle problemen die je kan tegen komen.

Je moet 't wel leuk vinden ja. Elke goeie dev die ik ken doet 'thuis' ook dingen omdat het ook een hobby is.

Wat je op school/de uni leert is meestal toch heel formeel en degelijk... De wereld daarbuiten is dat echter niet; daar loop je tegen vele systemen en protocollen aan, het werk van andere programmeurs (die ook vinden dat hun het allemaal perfect doen), legacy systemen, infra problemen die invloed hebben op de architectuur... etc etc etc... Dat vereist toch enige 'praktische' ervaring/inzicht.

Het geeft je een enorm belangrijke basis. Het leert je patronen aan in hoe je problemen oplost, en het geeft je een brede basis als start voor nieuwe dingen. Ik zeg ook niet dat je zonder die basis niet succesvol kan zijn maar wat ik er van gezien heb 'in het wild' heb je 2 soorten autodidacten. Het eerste is erg slim, werkt goed in een team en leert in de loop van de tijd bij. De 2e categorie zit vastgeroest in verkeerd aangelegde patronen, leert niet bij (omdat alleen of omdat niet in een team) en blijft gewoon rommel opleveren. Heb met beide types veel samen moeten werken.

Neemt overigens niet weg dat tegenwoordig HBO-I nogal afgezwakt is en ook daar enorme dwazen toch hun papiertje halen.

[eL_Jay]

Ben zelf nu aan de slag gegaan met udacity (python) en codecademy (html/css)
Probleem waar ik als volslagen newbie tegen aanloop, is dat ik de logica erachter niet begrijp.
Als ik het met linguistische talen vergelijk leer ik met bovenstaande sites de vocabulaire, maar mis ik de grammatica/logica erachter om zelf iets te maken.

Iemand tips voor literatuur die hier wat inzicht in kan geven?

Of is de enige manier om zelfstandig te leren programmeren alles uit je kop knallen en reproduceren?

[phex]

Alles uit je hoofd leren is iets wat langzaam komt, hoe meer je schrijft hoe vaker je dingen tegenkomt en dus beter kan onthouden. Een boek is vooral goed om veel voorkomende problemen te omschrijven. Hier zijn oplossingen voor die vaak toegepast worden (Design patterns).

Wat je je zelf moet kunnen is je probleem formuleren.

Wat wil ik doen, welke elementen heb ik hier voor nodig.
Hoe werken die elementen met elkaar.
Hoe kan ik deze elementen zo simpel mogelijk omschrijven.

Althans dat zijn de stappen die ik maak als geen projectdocumentatie voor handen is.

[Janoz]

eL_Jay schreef op maandag 08 juli 2013 @ 12:53:
Of is de enige manier om zelfstandig te leren programmeren alles uit je kop knallen en reproduceren?

Absoluut niet. Wat belangrijk is is dat je de kunst van het opdelen onder de knie krijgt. Het opdelen van een ingewikkelde taak in meerdere simpelere subtaken welke je vervolgens wel op kunt lossen. Je kunt wel een bak design patterns in je hoofd gaan stampen, maar je leert het eigenlijk echt alleen maar door het te doen.

Een taal leren is verder eigenlijk alleen maar een manier om het idee van het algoritme uit te kunnen drukken.

[drm]

Janoz:
Een taal leren is verder eigenlijk alleen maar een manier om het idee van het algoritme uit te kunnen drukken.

Andersom geldt het ook: als je een taal (of meerdere) leert, ga je jezelf steeds beter leren uitdrukken in ideeën die in de taal opgesloten zitten. Een taal leren helpt dan ook om je probleemoplossend vermogen te vergroten. Het blijft daarom ook nuttig om nieuwe talen te leren.

[BikkelZ]

Tja je moet eerst een doel formuleren en dan kijken wat je daar voor nodig hebt:

- Webinterfaces: dynamische talen zoals Python, Ruby, JavaScript, PHP (waarbij Python het cleanste is en PHP het meest gebruikt maar ook de meeste rommelige taal is)
- Business logica: C# en Java (om te leren zijn ze 1:1 inwisselbaar, daarna specialiseren in een van de twee en daar op blijven)
- High performance zoals fast trading systemen of game engines: C en C++

[drm]

Is al eerder gezegd, maar PHP is echt geen goed idee om mee te beginnen. "Snel en makkelijk bruikbaar" is tegenwoordig niet echt een argument meer, vrijwel alle veelgebruikte talen kun je tegenwoordig snel mee starten om het te leren.

PHP als taal en engine zit vol met inconsistenties en dingen die extra uitleg nodig hebben. Je kunt beter een taal hebben die tot op het bot logisch is want dan leer je aanvoelen waarom die structuur nuttig is. Weer een parallel met natuurlijke talen: je leert meer over hoe westerse talen werken door Latijn te leren dan Nederlands.

Ik raad overigens ook iedereen aan om eens naar Haskell te kijken. Al is het maar voor het idee.

[Onbekend]

Ik ben van mening dat als je vanaf stap 1 het programmeren moet leren, de programmeertaal/scripttaal niet uitmaakt hoe slecht deze dan ook is.
De basisprincipes zijn gelijk en do-, while- en for-loops werken overal vrijwel het zelfde. Zolang je geen goto-commands gebruikt en geen programmeerfouten met een try en catch gaat opvangen ben je al zeer goed op weg.

Ik raadt vaak aan om als beginproject een klein spelletje te maken zoals snake, tetris of pong. Maak daarna een mogelijkheid om een spel op te slaan en weer te openen en hebt de eerste kennis opgedaan hoe je moet denken om een programma te schrijven.

Daarna zijn de andere punten aan de beurt zoals classes, nesten van classes, threads, memoryleaks, invoerfouten en grafische bewerkingen (snelheid). Voor deze punten is de keuze van de programmeertaal veel meer van belang, maar voor de basis maakt het nauwelijks iets uit.

[RayNbow]

Onbekend schreef op woensdag 10 juli 2013 @ 22:38:
Ik ben van mening dat als je vanaf stap 1 het programmeren moet leren, de programmeertaal/scripttaal niet uitmaakt hoe slecht deze dan ook is.
De basisprincipes zijn gelijk en do-, while- en for-loops werken overal vrijwel het zelfde.

Ook in Haskell en Prolog?

[Spockz]

drm schreef op woensdag 10 juli 2013 @ 22:10:
Is al eerder gezegd, maar PHP is echt geen goed idee om mee te beginnen. "Snel en makkelijk bruikbaar" is tegenwoordig niet echt een argument meer, vrijwel alle veelgebruikte talen kun je tegenwoordig snel mee starten om het te leren.

PHP als taal en engine zit vol met inconsistenties en dingen die extra uitleg nodig hebben. Je kunt beter een taal hebben die tot op het bot logisch is want dan leer je aanvoelen waarom die structuur nuttig is. Weer een parallel met natuurlijke talen: je leert meer over hoe westerse talen werken door Latijn te leren dan Nederlands.

Ik ben het met je eens dat er talen zijn met minder inconsistenties. (is dit geen anglicisme?) Maar niet met je stelling dat je daarom niet moet beginnen in een taal. Als je de juiste begeleiding hebt kun je juist al die inconsistenties meemaken en daardoor een beter begrip krijgen waarom dingen logisch moeten en wanneer ze dan wel logisch zijn. Net zoiets als dat je de zonneschijn niet waardeert als je niet eerst een poos regen hebt gehad, ofzo. Het gevaar zit hem erin dat je erin gaat berusten dat dingen niet logisch werken en dan niet verder kijkt of dat je het niet eens door hebt dat er dingen beter kunnen maar daar heb je je dan je begeleider voor.

Zoals al eerder aangegeven draait programmeren vooral ook om het kunnen opdelen van 1 probleem in een aantal deelproblemen. Dit is iets wat je moet leren en dat kan je in bijna elke taal.

drm schreef op woensdag 10 juli 2013 @ 22:10:
Ik raad overigens ook iedereen aan om eens naar Haskell te kijken. Al is het maar voor het idee.

[ Voor 13% gewijzigd door Spockz op 11-07-2013 07:57 ]

[begintmeta]

Zou het leren van fortran, ada, go of scheme/lisp zinvol kunnen zijn? (Met name fortran zie ik ook nog wel eens in het wild) Of is het dan zinvoller om zich op bijvoorbeeld C(++) te gaan richten?.

[raptorix]

Voor mensen die met c# willen starten (wat ik zelf een goede keuze vind) is dit een uiterst goed gratis boek: http://www.csharpcourse.com/

Een heel fijn boek, wat aan de hand van een simpele applicatie de basis van c# bespreekt.

Als je een klein beetje ervaring hebt met programmeren (niet noodzakelijk) werk je je zelf in 2 weken door het boek.

[Gomez12]

Spockz schreef op donderdag 27 juni 2013 @ 12:18:
Ik ben er zelf voorstander van om iemand juist te laten beginnen in een taal dat *niet* alles voor je doet of andere duidelijke minpunten heeft. Dit forceert je namelijk om stil te staan bij de details van hoe software en hardware samenwerken. Hiermee kweek je in je hoofd een (diep) besef van hoe je programma zich gedraagt en het belangrijkst *waarom*. Als je op dat moment switch naar een taal die iets voor jou makkelijker maakt, in het geval van GC je memorymanagement, dan ben je je dus nog steeds bewust van wat er gebeurt en gebruik je de vrijgekomen capaciteit om na te denken over complexere algoritmen en/of implementaties.

Hier zit wel een heel groot gevaar in wat ik bij veel mensen terugzie : NIH.

Iemand heeft ooit een memory-manager gemaakt en die moet het beter doen dan de GC dus de hele GC negeren we maar en het eigen brouwsel gooien we erin.
Zo weet ik genoeg interne ticket-systemen waar gewoon hele categorieeen zijn in de trant van : When Hell Freezes Over. Daar zitten alle uiterst theoretische randgevallen in van de taal / tooling en waarvoor de programmeur het beter denkt te kunnen doen dan de maker van de taal / tooling.

[Bill_E]

raptorix schreef op donderdag 11 juli 2013 @ 08:44:
Voor mensen die met c# willen starten (wat ik zelf een goede keuze vind) is dit een uiterst goed gratis boek: http://www.csharpcourse.com/

Een heel fijn boek, wat aan de hand van een simpele applicatie de basis van c# bespreekt.

Als je een klein beetje ervaring hebt met programmeren (niet noodzakelijk) werk je je zelf in 2 weken door het boek.

Goede tip, gisterenavond eens snel door gelezen

[Moi_in_actie]

Over tutorials en dergelijke gesproken, ik weet niet of deze website hier al een keer voorbij is gekomen, maar het heeft mij tijdens mijn afstuderen heel veel geholpen toen ik aan Android programming begon:

The New Boston

Van zo'n beetje alle gangbare programmeertalen, maar ook dingen als 3D modellingen, game development en zelfs standaard schoolvakken heeft hij, Bucky Roberts, wel tutorials. Naar mijn inziens kan hij heel duidelijk zaken uitleggen op een manier dat zelfs een complete computer-leek het nog begrijpt. Daarbij vind ik zelf kijken/luisteren naar dergelijke tutorials een stuk fijner dan een boek lezen.

[Bill_E]

The New Bosten was ook langs gekomen, maar ook daar heb ik veel hulp aan gehad.

[begintmeta]

begintmeta schreef op donderdag 11 juli 2013 @ 08:09:
Zou het leren van fortran, ada, go of scheme/lisp zinvol kunnen zijn? (Met name fortran zie ik ook nog wel eens in het wild) Of is het dan zinvoller om zich op bijvoorbeeld C(++) te gaan richten?.

Op het moment neig ik het meest naar Fortran, dat kom ik eigenlijk het vaakst tegen. Hoe dan ook moet ik mijn beperkte Python-etc skills weer eens updaten en oefenen. Fortran en C kom ik het vaakst tegen, is sowieso handig om het beter/sneller te begrijpen.

Is Fortran een verantwoorde keuze om tijd aan te besteden?

[PrisonerOfPain]

begintmeta schreef op maandag 15 juli 2013 @ 17:09:
Is Fortran een verantwoorde keuze om tijd aan te besteden?

Nee.

Waar kom je het in hemelsnaam vaak tegen?

[begintmeta]

Mij is opgevallen dat behoorlijk wat 'scientific computing'-libraries en modules in fortran zijn opgesteld.

[BikkelZ]

Het lijkt me wel belangrijk dat mensen die willen leren programmeren ook even uitleggen waarom ze willen leren programmeren en om welke doelen te bewerkstelligen. Als ik niet vertel dat het mijn droom is ooit nog eens een spel voor de Commodore 64 te maken weet niemand dat het juiste antwoord "eerst BASIC en dan 6510 assembler" is

begintmeta schreef op maandag 15 juli 2013 @ 17:16:
Mij is opgevallen dat behoorlijk wat 'scienific computing'-libraries en modules in fortran zijn opgesteld.

Dat klopt, daar had mijn zusje het ook al over (wiskunde/natuurkunde wo)

[ Voor 36% gewijzigd door BikkelZ op 15-07-2013 17:23 ]

[Daos]

Op de universiteit gebruikten wij Wikipedia: High Performance Fortran voor programmeren op een supercomputer/cluster.

De andere helft van het practicum was in C met Wikipedia: Parallel Virtual Machine


Zelf lijkt C# mij de beste keuze om te leren. Je kan er alles mee en het bespaart je een hoop gedoe want het heeft een garbage-collector.

Als dat te moeilijk is, is er nog SmallBasic

[begintmeta]

BikkelZ schreef op maandag 15 juli 2013 @ 17:18:
Het lijkt me wel belangrijk dat mensen die willen leren programmeren ook even uitleggen waarom ze willen leren programmeren en om welke doelen te bewerkstelligen. ...

Een goed punt uiteraard. Waar ik mee te maken heb vooral gerelateerd aan modelleren van eigenlijk vrij laag complexe zaken en statistiek. Mijn programmeerkennis en activiteit is momenteel vooral passief, maar ik wil graag eventueel wat actiever aan de slag.

Ik vroeg me af of Fortran daarbij intrinsiek een onverstandige keuze zou zijn of dat het nadeel meer zou zijn dat de taal te weinig flexibel of makkelijk uit te bouwen is (bijvoorbeeld koppeling met gtk (is er meen ik) of qt, of andere populaire application frameworks/libraries/toolkists) om ook buiten het gebied waar de taal nog redelijk frequent wordt gebruikt zinvol toepasbaar te zijn. Naast fortran denk ik ook aan c(++?) of python om (weer) wat tijd aan te besteden, of eventueel iets 'wilds' en dus wellicht sowieso niet verstandigs (ada, go of scheme/lisp). Uiteindelijk is het vooral ter lering en vermaak, maar de kans dat ik iets zinvols zou kunnen doen (eventueel ook met grafische interfaces) in die taal mag uiteraard zo groot mogelijk zijn.

[De_Bastaard]

Ik ben zelf nu ook bezig met het leren programmeren. Heb me het boek Head First C#.NET gekocht en daarmee begonnen.

Iedereen die ik de vraag stel: "Ik wil leren programmeren, where do I start?" Heeft een ander antwoord. Gisteren nog een discussie gehad met een aantal ontwikkelaars die ook Eve Online spelen, en daar zegt de een dat ik moet beginnen met C, de ander weer Python, etc. etc.

Het is volgens mij gewoon vooral belangrijk dat je de logica snel leert, of dat nu makkelijker gaat met C of met C# of Java zou ik niet weten. Persoonlijk vind ik C#.NET redelijk intuïtief/overzichtelijk terwijl C weer meer detail vereist (geheugen opschonen e.d.). Aan de andere kant kun je je natuurlijk afvragen of dat dan niet meteen een voordeel is, zodat je het "goed" leert?

[PrisonerOfPain]

begintmeta schreef op dinsdag 16 juli 2013 @ 00:25:
[...]

Een goed punt uiteraard. Waar ik mee te maken heb vooral gerelateerd aan modelleren van eigenlijk vrij laag complexe zaken en statistiek. Mijn programmeerkennis en activiteit is momenteel vooral passief, maar ik wil graag eventueel wat actiever aan de slag.

Dit maakt de keuze voor Fortran al een stuk logischer, in een hoop gebieden is het namelijk al redelijk uitgestorven maar er zijn inderdaad nog high-performance gebieden over waar het wel gebruikt word. (En een hoop oude boeken die het nog aanraden). Het klinkt als of je veel baat kunt hebben bij de taal, maar als je de performance niet nodig hebt zou je ook naar python (NumPy, SciPy) kunnen kijken.

[Caelorum]

De_Bastaard schreef op dinsdag 16 juli 2013 @ 08:16:
[...] Iedereen die ik de vraag stel: "Ik wil leren programmeren, where do I start?" Heeft een ander antwoord. Gisteren nog een discussie gehad met een aantal ontwikkelaars die ook Eve Online spelen, en daar zegt de een dat ik moet beginnen met C, de ander weer Python, etc. etc. [...]

De taal om in te beginnen hangt ook wel af van wat je precies wilt doen met het kunnen programmeren en hoe snel je dat wilt doen. Wil je richting de (3D) graphics kan je niet echt om C/C++ heen, wil je wetenschappelijke dingen doen is een functionele taal of java wellicht beter, business apps wellicht C# en voor de hippedippe dingen HTML/JS. Het probleem is alleen dat de meeste startende programmeurs nog niet een goed beeld (kunnen) hebben van wat ze leuk vinden om te ontwikkelen.
Uiteindelijk maakt de start taal niet zo heel veel uit, want je komt wel waar je moet zijn, maar het kan nogal wat tijd kosten. Als voorbeeld toen ik begon met 'programmeren' zo'n 13 jaar geleden begon ik in Actionscript 1, daarna de moeilijke overstap naar AS3 gemaakt. Toen kwam kort java en daarna C#, die overstap is nog wel te doen is. Anyways, het heeft mij zo'n 12 jaar gekost om erachter te komen wat ik echt leuk vind om te doen en erachter te komen dat c++ daaroovr het meest wordt gebruikt. Sinds 4 maanden werk ik voornamelijk in c++ en kan je vertellen dat de overstap van automatic garbage collection naar geen garbage collection erg moeizaam is. Ik worstel er nog elke dag mee en ben er van overtuigd dat als ik bij C was begonnen ik uiteindelijk een veel beter idee van de computer had gehad maar wel met een langere initiele leertijd.

Anyways kort door de bocht denk ik dat als je in je eentje zonder hulp moet beginnen (zoals ik) en business applicaties willen maken een 'managed' taal als C# of java het beste is. Mocht je echter hulp/les kunnen krijgen denk ik dat je met C en dan C++ het beste uit bent voor die dingen.
Maar dit is nog los van alle andere dingen die al gezegd zijn en het feit dat de starttaal niet eens zo heel erg uitmaakt. Vind in ieder geval een taal waarmee je of hulp kunt krijgen (bijv. code reviews van een ervaren programmer) of waar relatief veel fatsoenlijke tutorials/boeken over kunt vinden.

[farlane]

Caelorum schreef op dinsdag 16 juli 2013 @ 23:00:
Sinds 4 maanden werk ik voornamelijk in c++ en kan je vertellen dat de overstap van automatic garbage collection naar geen garbage collection erg moeizaam is. Ik worstel er nog elke dag mee en ben er van overtuigd dat als ik bij C was begonnen ik uiteindelijk een veel beter idee van de computer had gehad maar wel met een langere initiele leertijd.

Ik snap nooit zo goed wat mensen daar moeilijk aan vinden, uiteindelijk komt het er op neer dat resources die je alloceert ook weer moet opruimen. Dus als je iets alloceert gaat er direct een belletje rinkelen die je er toe zet om na te denken over wanneer dat ding weer opgeruimd gaat worden.

Bovendien hebben platformen met een GC zoals C# ook datzelfde probleem, als je iets meer doet dan triviale applicaties in elkaar draaien; het feit dat er een Dispose/Destructor/using/finally constructies bestaan geeft dat al aan ( en maakt het naar mijn idee alleen maar ondoorzichtiger )

[Hydra]

Caelorum schreef op dinsdag 16 juli 2013 @ 23:00:
De taal om in te beginnen hangt ook wel af van wat je precies wilt doen met het kunnen programmeren en hoe snel je dat wilt doen. Wil je richting de (3D) graphics kan je niet echt om C/C++ heen

Als je gewoon een 3D spelletje wil maken kan dat prima in Java (of whatever, voor elke taal zijn wel OpenGL bindings, 3D 'leren' is nauwelijks afhankelijk van je platform). Als je echt 'in de markt' aan de slag wil mag je achteraan de rij aansluiten en kun je 't zonder gedegen opleiding waarschijnlijk wel vergeten.

Anyways kort door de bocht denk ik dat als je in je eentje zonder hulp moet beginnen (zoals ik) en business applicaties willen maken een 'managed' taal als C# of java het beste is. Mocht je echter hulp/les kunnen krijgen denk ik dat je met C en dan C++ het beste uit bent voor die dingen.
Maar dit is nog los van alle andere dingen die al gezegd zijn en het feit dat de starttaal niet eens zo heel erg uitmaakt. Vind in ieder geval een taal waarmee je of hulp kunt krijgen (bijv. code reviews van een ervaren programmer) of waar relatief veel fatsoenlijke tutorials/boeken over kunt vinden.

M.i. zijn er voor een 'beginner' een aantal eisen:
- De taal moet je redelijk dwingen OO te programmeren (het is moeilijker dingen later af te leren dan gewoon meteen de 'juiste' manier te leren)
- Er moet een grote gebruikerscommunity zijn
- Er moet veel lesmateriaal in zijn
- De taal moet je niet te veel lastigvallen met low-level geneuzel en de onderliggende OS zaken voor je abstraheren

Wat dat betreft zijn C# en Java wat mij betreft dus ze beste kandidaten. M.i. leer je het snelst de juiste skills aan waardoor je later makkelijk over kunt stappen naar andere talen. Dit betekent dus niet dat je niet kunt beginnen met C++ of Python, maar dat het m.i. waarschijnlijk niet de beste keuze is. De gemiddelde Python tutorial begint met "hoe tel ik 1 en 1 op". Een gemiddeld Java boek begint met "wat is een object". Daar zit m.i. nogal een verschil in.

Zelf ben ik begonnen met basic en wat assembly en toen ik in '98 aan de HIO les kreeg in Java moest ik me ook gewoon een hoop dingen afleren. Jezelf OO aanleren is gewoon lastiger als je het al een hele tijd anders gedaan hebt.

farlane schreef op woensdag 17 juli 2013 @ 09:05:Ik snap nooit zo goed wat mensen daar moeilijk aan vinden, uiteindelijk komt het er op neer dat resources die je alloceert ook weer moet opruimen.

In de praktijk zijn er makkelijk fouten mee te maken die dan erg lastig te herleiden zijn naar de bron. Als voorbeeld: in mijn opleiding begon je in het 3e jaar met C++. In de oneindige wijsheid van de gemiddelde HBO manager hebben ze besloten om inplaats van een C++ vak met theorie en practicum het praktische deel los te koppen en te onderwijzen in de vakken "datastructuren" (bomen e.d.) en "algoritmen" (eigen LZW implementatie maken, etc.).

En toen werd dus de docent die het theoriedeel zou geven ziek en mochten we zonder het theoriedeel (zelf maar blokken op het dictaat) zelf het praktijkdeel gaan implementeren. Dit heeft ons dus HEEL veel tijd gekost omdat we gewoon met een texteditor onder Solaris zaten te werken en als je iets fout doen gewoon een segfault krijgt (bleek later dat ik op een of andere manier in een RO deel zat te schrijven). Het is me zelfs gelukt om een kernel panic te veroorzaken.

Vandaar dat ik dus sterk van mening ben dat beginnen in C++ geen goed idee is. Het is een must-learn taal, absoluut, maar niet als absolute beginner.

[ Voor 22% gewijzigd door Hydra op 17-07-2013 10:00 ]

[NMe]

Hydra schreef op woensdag 17 juli 2013 @ 09:53:
- De taal moet je redelijk dwingen OO te programmeren (het is moeilijker dingen later af te leren dan gewoon meteen de 'juiste' manier te leren)

Dat mensen gedwongen worden om OO te gebruiken wil helaas nog niet zeggen dat ze het goed doen. Ik heb echt de meest rampzalige classes gezien van mensen die totaal niet wisten wat ze aan het doen waren. OO forceren is dus niet heilig tenzij je daarbij ook een gedegen kennis van OO opdoet.

[Hydra]

NMe schreef op woensdag 17 juli 2013 @ 10:08:
Dat mensen gedwongen worden om OO te gebruiken wil helaas nog niet zeggen dat ze het goed doen. Ik heb echt de meest rampzalige classes gezien van mensen die totaal niet wisten wat ze aan het doen waren. OO forceren is dus niet heilig tenzij je daarbij ook een gedegen kennis van OO opdoet.

Joh.

Alsof ook maar de helft van de hobbyisten hier uberhaupt ooit doorzetten en het echt gaan snappen. De meesten lijkt het allemaal leuk om "spelletjes te maken" maar die haken af zogauw ze doorkrijgen hoeveel werk het wel niet is. Dat neemt niet weg dat je ze m.i. wel richting een OO taal moet duwen als ze om raad vragen.

[Caelorum]

Hydra schreef op woensdag 17 juli 2013 @ 09:53:
[...] Als je gewoon een 3D spelletje wil maken kan dat prima in Java (of whatever, voor elke taal zijn wel OpenGL bindings, 3D 'leren' is nauwelijks afhankelijk van je platform). [...]

Klopt helemaal, al ontkom je op een bepaald punt gewoon niet meer om op zijn minst c/c++ en alle daar gangbare constructies te kunnen lezen. Je zult toch op zijn minst ook bestaande render/game frameworks moeten doornemen. Tenzij je het complete wiel opnieuw wilt uitvinden.

Als je echt 'in de markt' aan de slag wil mag je achteraan de rij aansluiten en kun je 't zonder gedegen opleiding waarschijnlijk wel vergeten. [...]

Klopt helemaal. Dat wil niet zeggen dat het onmogelijk is. Er zijn verscheidene afgestudeerden van mijn master werkzaam in de game industrie in Nederland en de master is niet direct (serious) gaming gerelateerd. (Ook al zijn er een aantal sites die dit wel beweren)

[...] In de praktijk zijn er makkelijk fouten mee te maken die dan erg lastig te herleiden zijn naar de bron. <voorbeeld>
Vandaar dat ik dus sterk van mening ben dat beginnen in C++ geen goed idee is. Het is een must-learn taal, absoluut, maar niet als absolute beginner.

Dat is ook waarom ik aangaf dat het alleen verstandig is als je wordt ondersteund door een al ervaren c++ programmeur. Iemand die de code samen kan doornemen en die je in de juiste richting kan duwen als er een probleem optreed. Persoonlijk denk ik dat je eigen slechte ervaring met het onderwijs projecteert op de hele taal.

[ Voor 4% gewijzigd door Caelorum op 17-07-2013 11:13 ]

[NMe]

Hydra schreef op woensdag 17 juli 2013 @ 10:11:
[...]

Joh.

Alsof ook maar de helft van de hobbyisten hier uberhaupt ooit doorzetten en het echt gaan snappen. De meesten lijkt het allemaal leuk om "spelletjes te maken" maar die haken af zogauw ze doorkrijgen hoeveel werk het wel niet is. Dat neemt niet weg dat je ze m.i. wel richting een OO taal moet duwen als ze om raad vragen.

Jij bracht het alsof iedereen die uit zichzelf OOP aanleert, het meteen goed doet. Dat wilde ik even verduidelijken voor de onervaren mensen die (juist hier) meelezen. Dat jij dat zelf ook wel snapt weet ik ook wel.

[begintmeta]

Ik denk na lezing van [url]dit[/url] (biased uiteraard) praatje dat ik me maar ga richten op Python gecombineerd met Fortran. Uiteindelijk zijn dat (en matlab, etc) de talen waar in mijn omgeving de grootste ervaring mee is. Ook heb ik voor beide talen wel redelijk wat lesmateriaal opgeduikeld.

[ Voor 25% gewijzigd door begintmeta op 17-07-2013 12:30 ]

[DXaroth]

Uiteindelijk is de programmeer taal niet veel meer dan het gereedschap wat gebruikt wordt om de klus te klaren..

Python is leuk (en spendeer er ook veel tijd mee), maar als er een project komt waar python niet efficient is, gaan we gewoon over op wat anders wat wel werkt.

[Hydra]

begintmeta schreef op woensdag 17 juli 2013 @ 12:29:
Ik denk na lezing van [url]dit[/url] (biased uiteraard) praatje dat ik me maar ga richten op Python gecombineerd met Fortran. Uiteindelijk zijn dat (en matlab, etc) de talen waar in mijn omgeving de grootste ervaring mee is. Ook heb ik voor beide talen wel redelijk wat lesmateriaal opgeduikeld.

Ik hoop dat je ook snapt dat er nogal een verschil zit in de programmeer-paradigma's. Fortran is een imperatieve taal, Python is een OO taal die procedureel programmeren toelaat. Een andere taal leren dat hetzelfde paradigma (min of meer) aanhangt is relatief simpel; switchen naar een ander paradigma is nogal wat anders.

In de ontwikkeling van talen kunt je eigenlijk, kort door de bocht, spreken van een shift van imperatief naar procedureel (= imperatief met procedures, eigenlijk locale state) naar object georienteerd (= procedureel met encapsulation, inheritance en polymorfism).

De vraag is dus een beetje wat je wenst te bereiken. Ik zie persoonlijk het nut er niet van tijd te besteden aan Fortran tenzij je hele specifieke situaties voor je hebt waar je het nodig denkt te hebben.

[drm]

Hydra:
In de ontwikkeling van talen kunt je eigenlijk, kort door de bocht, spreken van een shift van imperatief naar procedureel (= imperatief met procedures, eigenlijk locale state) naar object georienteerd (= procedureel met encapsulation, inheritance en polymorfism).

Je vergeet imho nog de laatste stap, declaratief. shameless blog plug

[begintmeta]

Hydra schreef op woensdag 17 juli 2013 @ 13:17:
...
Ik hoop dat je ook snapt dat er nogal een verschil zit in de programmeer-paradigma's. Fortran is een imperatieve taal, Python is een OO taal die procedureel programmeren toelaat. Een andere taal leren dat hetzelfde paradigma (min of meer) aanhangt is relatief simpel; switchen naar een ander paradigma is nogal wat anders.

Als ik het heb begrepen begrijp zijn die grenzen met de laatste Fortran-incarnaties wat vervaagd.

...
De vraag is dus een beetje wat je wenst te bereiken. Ik zie persoonlijk het nut er niet van tijd te besteden aan Fortran tenzij je hele specifieke situaties voor je hebt waar je het nodig denkt te hebben.

Zoals gezegd: ik kom nog wel eens wat Fortran-code tegen. Dat sneller/beter begrijpen, kunnen aanpassen of erop kunnen voorborduren lijkt me potentieel handig te zijn. Python gebruik ik wel eens, het verbeteren van mijn vaardigheden met die taal lijkt me ook zijnvol (in principe zinvoller dan het toevoegen van Fortran). Bepaalde zaken eventueel in fortran (of c) kunnen doen als het met b.v. python niet handig gaat is dan misschien wel weer leuk had ik bedacht.