Wat kan je nu allemaal met deze talen ?

[not2secure4u]

Ik ben aan het overwegen om mss informatica te gaan studeren in Belgie. Ik heb geen ervaring met programmeertalen maar het interesseert mij wel. Nu vroeg ik me af , wat kan je ermee ?

Ik heb een cursus c++ van mijn school bekeken en daar zie ik op dat ik het eerste semester de basics leer maar ik kom "niet verder" dan zwarte kaders programmeren, ik bedoel dit niet kortzichtig maar ik zit met de prangende vraag wat ben je ermee in het begin?

Kunnen jullie mij een boeiend aspect laten zien ervan ? Wat vinden jullie er boeiend aan ? Hoe ervaarde jullie deze talen in het eerste jaar van je studie ? ( C++, SQL )


Ik hoop dat ik tot inzicht kan komen !

[AtleX]

Talen zijn niet echt belangrijk, wel de concepten die je ermee leert. Kennis van datastructuren, OOP, etc. is veel waardevoller dan iets leuks kunnen met slechts 1 taal.

Ik doe trouwens HBO Informatica (in Nederland dus), en mijn eerste jaar bestond qua programmeren vrijwel volledig uit Java met behulp van BlueJ. Grafisch gezien kan je dan niet eenvoudig gave dingen maken, maar voor de basis is het geweldig. Daarnaast deden we nog een blok (van 10 weken) C#, en een beetje PHP. SQL kwam natuurlijk ook voor, maar dat was erg gericht op MSSQL.

[ Voor 52% gewijzigd door AtleX op 26-04-2008 10:18 ]

[Adion]

"Wat ben je ermee" in het algemeen is natuurlijk wel duidelijk, kijk naar alle programma's en webtoepassingen die je dagelijks gebruikt, en je ziet wat je er mee zou kunnen.

Voor mij is dat ook steeds de motivatie geweest om te leren programmeren, gewoon het zien werken van iets dat je zelf gemaakt hebt.
Zeker in het begin kan het inderdaad wat moeilijker zijn om iets leuks te vinden dat je ermee kan, dan zijn vaak eenvoudige spelletjes nog het interessantste om te maken (mastermind, een textueel race-spelletje, ...)

Zelf ben ik lang voor m'n studie met programmeren begonnen (rond m'n 8 a 9 jaar geloof ik) en toen ben ik zelf begonnen met Basic. De eerste programmaatjes waren dan ook vooral overgetypt uit leerboekjes, maar uiteindelijk heb ik er toch bijvoorbeeld een programma mee geschreven om adressen bij te houden.
Later ben ik op de PC verder gegaan met QBasic en in windows Visual Basic, en daar heb ik onder andere Pong en een muziek-beheerprogramma gemaakt.

Ik denk dat zeker in het begin je motivatie dus toch vooral uit interesse zal moeten komen. Je zal waarschijnlijk niet direct iets maken dat al niet bestond, maar het moet gewoon leuk zijn om iets te zien werken dat je zelf in elkaar hebt geknutseld.

[Arjan]

Je kan een programeertaal analoog zien aan gereedschap.

redelijk low-level talen als C staan voor je hamer en zaag, terwijl de hogere talen gelijk staan aan bv. 2D frees. De beginner kan snel mooie dingen maken op een frees, maar zit vast aan de beperkingen van het apparaat.

Wie zich echter richt op de hamer/zaag kan in het begin weinig indrukwekkende dingen bouwen. Als je echter talent en doorzettingsvermogen hebt is er eigenlijk weinig dat je niet kan bouwen

Er geld dan ook, gebruik het juiste gereedschap. Weet je nog niet welk gereedschap bij je past? Ga voor low-level. Alles wat voor low-level val belang is, is dat ook voor de high-level talen. Andersom is dit niet altijd waar omdat sommige talen actief bepaalde gedeeltes afschermen voor de programmeur.

[Sebazzz]

Arjan schreef op zaterdag 26 april 2008 @ 10:39:
Andersom is dit niet altijd waar omdat sommige talen actief bepaalde gedeeltes afschermen voor de programmeur.

Zoals C# bijvoorbeeld geen pointers heeft
Aan de ene kant scheelt het veel gezeik, aan de andere kant mis ik het soms ook wel.

[ Voor 14% gewijzigd door Sebazzz op 26-04-2008 10:46 ]

[maxjuh]

Sebazzz schreef op zaterdag 26 april 2008 @ 10:46:
[...]

Zoals C# bijvoorbeeld geen pointers heeft
Aan de ene kant scheelt het veel gezeik, aan de andere kant mis ik het soms ook wel.

C# heeft zeker wel pointers! Je zal ze dan natuurlijk bijna nooit gebruiken in vergelijking met bijvoorbeeld C/C++

[Verwijderd]

Zoals eerder aangehaald is de taal alleen een werkmiddel. Je kan over het algemeen kiezen in welke taal je je specialiseert maar je zal wel altijd over meerdere talen kennis nodig hebben.

Wat je er mee kan doen is programma's schrijven. Al die programma's hebben tot doel een bepaalde handeling te automatiseren.

Een voorbeeld van een programma is dit forum. Zelf werk ik bv aan software die dokters en linguisten toelaat een medische ontology te beheren. Een vb van een toepassing op die ontology is dan bv doktersrapporten analyseren en die via de ontology kan koppelen aan ziekten en bijhorende medicijnen.

Merk wel op dat je als programmeur meer doet dan dergelijke oplossingen snel uittypen in code. Je moet eerst een vooral het probleem analyseren. Elk probleem heeft namelijk meerdere oplossingen 1 daarvan is de gunstigste oplossing voor uw situatie, probleem.

[MrBucket]

not2secure4u schreef op zaterdag 26 april 2008 @ 09:59:
Ik heb een cursus c++ van mijn school bekeken en daar zie ik op dat ik het eerste semester de basics leer maar ik kom "niet verder" dan zwarte kaders programmeren, ik bedoel dit niet kortzichtig maar ik zit met de prangende vraag wat ben je ermee in het begin?

Ik neem aan dat je met "zwarte kaders" een console-programma bedoelt? (een zwart vlak waar je alleen maar regeltjes tekst naartoe kunt schrijven). Klopt, die zien er niet zo spannend uit, maar ze zijn een stuk makkelijker te maken dan een 'echt' windows-programma met knoppen enzo. Het maken van een windows user interface is, zeker in C / C++, niet iets waar je mee wilt beginnen.

Maar ook met console applications kun je hele leuke dingen doen, denk aan simpele spelletje zoals galgje of mastermind ofzo. Geloof me, tegen de tijd dat je zoiets hebt geschreven dan is het echt kick-ass om te zien dat het werkt... ongeacht dat het 'maar' witte tekst op een zwart venster is...

[Verwijderd]

Sebazzz schreef op zaterdag 26 april 2008 @ 10:46:
[...]

Zoals C# bijvoorbeeld geen pointers heeft
Aan de ene kant scheelt het veel gezeik, aan de andere kant mis ik het soms ook wel.

Eigenlijk zijn alle non-value objecten (eigen geschreven klassen bijv.) ook al pointers (als je daar een instantie van aanmaakt)...of is er nog een heel essentieel verschil met de "C/++" pointers wat ik hiermee over het hoofd zie ?

[AtleX]

Er is een verschil tussen een pointer en een reference.

[curry684]

Sebazzz schreef op zaterdag 26 april 2008 @ 10:46:
[...]

Zoals C# bijvoorbeeld geen pointers heeft

Hoe kom je daarbij?

C#:

// cs_unsafe_keyword.cs
// compile with: /unsafe
using System;
class UnsafeTest 
{
   // unsafe method: takes pointer to int:
   unsafe static void SquarePtrParam (int* p) 
   {
      *p *= *p;
   }
   unsafe public static void Main() 
   {
      int i = 5;
      // unsafe method: uses address-of operator (&)
      SquarePtrParam (&i);
      Console.WriteLine (i);
   }
}

Het is niet aan te raden maar zeker wel mogelijk.

Verwijderd schreef op zaterdag 26 april 2008 @ 11:47:
[...]

Eigenlijk zijn alle non-value objecten (eigen geschreven klassen bijv.) ook al pointers (als je daar een instantie van aanmaakt)...of is er nog een heel essentieel verschil met de "C/++" pointers wat ik hiermee over het hoofd zie ?

Nou nee een instance is een instance, en daar kun je een pointer naar hebben. Zelf is het not even close to a pointer. Dat daargelaten is een C++ style (of C# unsafe style) pointer niets anders dan een simpel geheugenadres met een typedefinitie, en een C#/Java style object reference is referencecounted, lazy-copying, intelligent met concepten als boxing e.d.

In C++ kun je dit soort smart pointers zelf maken of uit een library als Boost gebruiken.

[ Voor 37% gewijzigd door curry684 op 26-04-2008 12:01 ]

[RayNbow]

Arjan schreef op zaterdag 26 april 2008 @ 10:39:
Je kan een programeertaal analoog zien aan gereedschap.

redelijk low-level talen als C staan voor je hamer en zaag, terwijl de hogere talen gelijk staan aan bv. 2D frees. De beginner kan snel mooie dingen maken op een frees, maar zit vast aan de beperkingen van het apparaat.

Beetje manke vergelijking. Hogere programmeertalen hebben meer abstracties, maar dat wil niet zeggen dat ze per se beperkend zijn. Hogere talen kunnen alsnog general purpose zijn.

Wie zich echter richt op de hamer/zaag kan in het begin weinig indrukwekkende dingen bouwen. Als je echter talent en doorzettingsvermogen hebt is er eigenlijk weinig dat je niet kan bouwen

Maar als je alleen leert denken in het verplaatsen van bitjes, dan kost het meer moeite om grotere en complexere dingen te bouwen. Probeer eens een wolkenkrabber te bouwen met een hamer en een zaag.

Er geld dan ook, gebruik het juiste gereedschap. Weet je nog niet welk gereedschap bij je past?

Gereedschap moet je eigenlijk matchen bij het probleem...

Ga voor low-level. Alles wat voor low-level val belang is, is dat ook voor de high-level talen.

Niet alles wat op een laag niveau van belang is is ook belangrijk op een hoger niveau. Moet ik per se weten hoeveel CPU instructies een vermenigvuldiging kost als ik bezig ben in een of andere Domain Specific Language bijvoorbeeld?

Tevens, waarom raad je iemand aan om low-level te gaan? Iemand die wil leren programmeren moet je leren om problemen op te lossen (op een handige manier). Het oplossen van een probleem betekent het in staat kunnen zijn van het formuleren van een oplossing. Bij zo'n formulering laat je meestal onbelangrijke details weg. Als ik iemand vraag hoe je kunt bepalen of een bepaald getal een priemgetal is, dan hoeft hij mij niet te vertellen hoe je een deling op papier uitvoert.

[Gomez12]

RayNbow schreef op zaterdag 26 april 2008 @ 11:59:
[...]

Beetje manke vergelijking. Hogere programmeertalen hebben meer abstracties, maar dat wil niet zeggen dat ze per se beperkend zijn. Hogere talen kunnen alsnog general purpose zijn.

Vind hem wel redelijk treffend, van de 2d frees kan ik ook een poot ( ervanuitgaande dat het op een tafel staat ) afhalen en dan de poot als hamer gebruiken, het kan en is niet erg als je ergens 1 spijker in wilt slaan. Moet je 1500 spijkers ergens inslaan dan is het toch makkelijker om een echte hamer te hebben.

[...]

Niet alles wat op een laag niveau van belang is is ook belangrijk op een hoger niveau. Moet ik per se weten hoeveel CPU instructies een vermenigvuldiging kost als ik bezig ben in een of andere Domain Specific Language bijvoorbeeld?

En in de meeste low-level toepassingen is dit soort info ook niet boeiend. Zit je voor een embedded device te proggen die altijd gelijk is, dan is dit boeiend.
Zit je voor een pc te proggen dan kan je er in 1e instantie vanuit gaan dat de klant-pc zowieso 20% sneller gemaakt kan worden door 1000 euro aan hardware uit te geven. Voor een pc zijn dit soort micro-optimalisaties nutteloos en te duur.

Tevens, waarom raad je iemand aan om low-level te gaan? Iemand die wil leren programmeren moet je leren om problemen op te lossen (op een handige manier). Het oplossen van een probleem betekent het in staat kunnen zijn van het formuleren van een oplossing.

Omdat een gedegen achtergrond ( de low-level kennis ) wel kan leiden tot een betere oplossing, je hoeft niet in een low-level taal alles te kunnen doen, maar een beetje achtergrond is alleen maar goed.

En met het formuleren van een oplossing dan ben je er nog lang niet, deze oplossing moet ook te onderhouden zijn. Hij moet uitbreidbaar zijn. Als jij een 100% letterlijke oplossing voor het probleem weet te creeeren dan heb je binnen een maand een probleem omdat mensen er altijd aanpassingen op willen hebben.

[RayNbow]

Gomez12 schreef op zaterdag 26 april 2008 @ 15:21:
En in de meeste low-level toepassingen is dit soort info ook niet boeiend. Zit je voor een embedded device te proggen die altijd gelijk is, dan is dit boeiend.

Ik nam dan ook de twee uitersten van low en high level .

[...]
Omdat een gedegen achtergrond ( de low-level kennis ) wel kan leiden tot een betere oplossing, je hoeft niet in een low-level taal alles te kunnen doen, maar een beetje achtergrond is alleen maar goed.

Ik zeg ook nergens dat kennis van low-level geen nut heeft. Verbreding van je kennis is altijd goed. Echter, het valt me op dat heel vaak low-level talen worden aangeraden wanneer mensen willen leren programmeren.

En met het formuleren van een oplossing dan ben je er nog lang niet, deze oplossing moet ook te onderhouden zijn. Hij moet uitbreidbaar zijn.

Die aspecten komen sowieso aan bod op een gedegen opleiding, maar pas nadat er 1 à 2 programmeervakken voorbij zijn geweest.

[Wolfboy]

Een betere vergelijking lijkt mij iets als een ikea meubelsetje (hoger niveau taal) waarmee je maar een beperkte hoeveelheid uitvoermogelijkheden hebt maar wel snel resultaat hebt vs. de boom die je zelf nog moet omzagen, schuren, etc...

Veel meer werk, maar je kan hetzelfde bereiken met de 2e.

[Gomez12]

RayNbow schreef op zaterdag 26 april 2008 @ 16:04:
Ik zeg ook nergens dat kennis van low-level geen nut heeft. Verbreding van je kennis is altijd goed. Echter, het valt me op dat heel vaak low-level talen worden aangeraden wanneer mensen willen leren programmeren.

Misschien omdat je dan ook iets van de basis ziet en een stuk begrip krijgt.

En sowieso, als je algoritmen / programmeerstructuren wilt leren dan is een mooie ide / intellisense alleen maar afleiding. En voor specifieke algoritmen zijn imho high level languages sowieso al minder geschikt, omdat je of kan kiezen uit de high-level language structures of je moet opeens in een low-level programmeertaal gaan werken die je nog nooit gezien hebt.

[The_Eternal]

Gomez12 schreef op zaterdag 26 april 2008 @ 17:06:
[...]
En sowieso, als je algoritmen / programmeerstructuren wilt leren dan is een mooie ide / intellisense alleen maar afleiding. En voor specifieke algoritmen zijn imho high level languages sowieso al minder geschikt, omdat je of kan kiezen uit de high-level language structures of je moet opeens in een low-level programmeertaal gaan werken die je nog nooit gezien hebt.

Sinds wanneer heeft een mooie ide te maken met een high of low level taal? Ik kan C++ netzogoed programmeren in een 'fancy' editor als C# (en omgekeerd, C# in notepad programmeren).
En hoe kom je er bij dat je in een high level taal geen (specifiek) algoritme kan schrijven ? Een algoritme is juist een 'generieke' definitie van de oplossing van een bepaald probleem, daar heeft programmeertaal niks mee te maken. De manier waarop je een algoritme omzet in een programmeertaal staat daar geheel los van.

Deze discussie begint trouwens redelijk offtopic te raken met dit high versus low level

Even voor not2secure4u:
Over het algemeen is een specifieke programmeertaal ondergeschikt aan het 'kunnen programmeren' in het algemeen. Ik raad zelf een wat higher level taal aan (C#, Java bijvoorbeeld) zodat je het concept van programmeren kan begrijpen zonder te veel moeite hoeven doen voor de kleinere onbelangrijkere dingen zoals het printen en formatteren van wat text om maar een voorbeeld te noemen.

Vooral C# en Java hebben bijvoorbeeld een grote basis library waarin een hele hoop nuttige functies/classes beschikbaar zijn die je in bijvoorbeeld C++ zelf mag schrijven (of er een externe library bij mag zoeken).

Als je eenmaal de basis van het programmeren snapt kan je vanzelf wat dieper gaan en eventueel 'dichter bij de CPU' gaan programmeren

[EnsconcE]

In het begin ben je er programmeur mee, je bent in staat denkwijzen om te zetten in een programmeertaal. Of je nu C++ leert, Java of C#, uiteindelijk gaat het erom dat je leert fietsen. Daarna is het afhankelijk van de situatie welke taal (fiets ) je inzet.

Ik ben in chronologisch in het programmeren gerold middels html, javascript en daarna php. Deze heb ik eigenhandig onder mijn eigen knie gestopt. Pas daarna heb ik OOP geleerd in Java op het HBO. Hierdoor was mijn perspectief op het programmeren in een klap veranderd. Het is voor mij nu eenvoudig om over te stappen op C++ of C# terwijl ik dat met PHP alleen niet kon. Het is ook meer dat je moet kijken naar de concepten die je leert dan dat je de speciefieke taal tot in de puntjes kent (wat opzich zijn voordelen ook wel heeft).

[flowerp]

AtleX schreef op zaterdag 26 april 2008 @ 11:54:
Er is een verschil tussen een pointer en een reference.

Nee dat verschil is er niet. Een pointer is primair een variable die naar iets wijst. Je kunt deze variable naar niets laten wijzen en je kunt de waarde van de variable toe kennen aan een andere (pointer) variable, met als gevolg dat er meerdere variablen zijn die naar dat ene iets wijzen.

Daarnaast zijn er een aantal wat meer high-level eigenschappen, zoals o.a. reference counting, garbage collection, extra indirection (zodat de heap manager b.v. memory allocaties kan 'compacten') en de onmogelijkheid om te kunnen rekenen met pointers.

De naam 'reference' is geen gedefinieerd concept. Het is de min of meer toevallige naam die Java en C# aan hun pointers gegeven hebben. Dat opeens hele volksstammen gaat denken dat die implementatie dan staat voor het begrip 'reference' en dat dat wat anders is als een 'pointer' is een beetje triest.

Er zijn talen die veel van bovengenoemde eigenschappen hebben en die het nog gewoon over pointers hebben. Soms maakt men b.v. het onderscheid puur op het feit of er een garbage collector is of niet. Nou, de taal C++ zegt niets over in de spec of er geen garbage collection zou mogen zijn, en zie daar... een C++ implementatie mag best garbage collection gebruiken.

Aan de andere kant zijn er ook talen die aan de term 'reference' een heel andere betekenis toe kennen. In C++ is een 'reference' b.v. een name alias, en iets totaal anders dan wat men in Java een reference noemt.

Veel mensen die deze begrippen niet kunnen of willen begrijpen gaan rare dingen zeggen zoals "Java heeft alleen call-by-reference', of ze gaan rare dingen doen zoals een pointer op null zetten vlak voor het eindigen van een method, omdat ze niet snappen dat het een pointer is die by-value is doorgegeven, etc.

[MrBucket]

De topicstarter besluit na het lezen van al deze posts waarschijnlijk dat glazenwasser toch ook best een leuk beroep kan zijn...

[not2secure4u]

Nee het maakt het er positiever op , bedankt voor alle info ... Ik ben méér geinteresseerd

[soulrider]

dan rust er nog een tip: heb zeker geen schrik zelf dingen uit te proberen.
(ook al is het al 6x geprogrammeerd door anderen, je leert het uiteindelijk zelf ook door dat zelf ook eens te proberen - ook al compileren de eerste 20 pobeersels niet en lopen de eerste 50 versie's vast na 'dummy input' - uiteindelijk komt er 'brouwsel achter brouwsel uit je keyboard' )

edit: wat extra:
wat eigen ervaring tijdens de programmatie lessen die ik (master in electronica optie ICT) had:
lessen zelf waren saai omdat ik - wegens 'mensen, volg aan eigen tempo het boek en we zien wel halfweg het jaar hoever jullie geraakt zijn, en gaan dan eventueel begeleid verder' - dat boek al ruim op tijd uit had, maar ondertussen al extra opdrachten had gevraagd en gekregen.
De logica zat er al in bij mij, ik moest enkel leren hoe dat "mee te delen aan de computer".

Resultaat is dat ik nu vrij snel een taal doorheb, de structuur kan inzien van door anderen ontwikkelde programma's, en daar ook fouten kan in vinden en uitvissen, maar het ook op leken-niveau kan uitleggen hoe iets in elkaar zit - alhoewel ik tijdens mijn extra 4 jaren studie slechts wat vba, c++, vb en assambler heb gezien. (excel-macro's, niet grafische programma's in c++, grafisch onder vb en assembler en c voor micro-processoren en een rtos-opdracht)
Web-programmatie in php heb ik mezelf geleerd (basis-niveau, maar goed genoeg om te scripten voor mezelf) en java + .net-varianten van c++ en vb lees ik zo.

Door te leren programmeren leer je ook vrij snel een probleem te ontleden naar zijn deelproblemen en zijn basis en ga je van daaruit beginnen denken aan een oplossing - wat weer goed toepasbaar is in het dagelijkse leven (al willen veel dat nog niet inzien en gaan ze liever symptomen ipv de echte oorzaken 'bevechten')

edit2: @onderbuur: ik ben zelf 5 jaar 't school uit, maar ik merk ook dat (zelfs hier in belgie) er meer "specialisatie's" zijn dan vroeger. Ik vind dat niet erg: meer werkzekerheid voor ons die nog een vrij brede opleiding hebben gehad. Het allernieuwste leer ik mezelf wel aan op een paar dagen/weken/maanden. En ik kan zo van sector wisselen als ik dat wil.
(hell, dat heb ik zelfs al gedaan - van Informatica-support naar Grafische wereld/ digitale pressen - installatie/support - basis is toch hetzelfde maar ipv gui's, pointers, registers en dergelijken zijn het nu spanningen, frequentie's en boutjes - en een hoop mechanica en electronica )

[ Voor 81% gewijzigd door soulrider op 26-04-2008 23:49 . Reden: wat eigen info/ervaringen/bedenkingen erbij ]

[0siris]

Ik ben al bijna 10 jaar klaar met school, maar de conclusies die ik trek na het lezen van alle reacties hier, is: HBO informatica == programmeren? Niets meer dan dat? Dat was in mijn tijd gelukkig anders

[Jungian]

offtopic:
Je mag kiezen (op de HvA in ieder geval). Het zou anders een beetje nutteloze programmeuruitpoep-opleiding worden nietwaar ?

Linkje naar "ons" verschrikkelijk lelijke en onpraktische intranet (de vorige versie was alleen maar antiek).

Toen ik begon met m'n opleiding was algemene kennis (alle vakgebieden werden behandeld, maar ook veel wiskunde) overigens nog onderdeel van het lesprogramma, nu proberen ze alleen nog maar "domme" eilandjes te creëren.

[ Voor 92% gewijzigd door Jungian op 26-04-2008 23:34 . Reden: more edits plox ]

[Verwijderd]

0siris schreef op zaterdag 26 april 2008 @ 23:20:
Ik ben al bijna 10 jaar klaar met school, maar de conclusies die ik trek na het lezen van alle reacties hier, is: HBO informatica == programmeren? Niets meer dan dat? Dat was in mijn tijd gelukkig anders

Nee joh, HBO ICT is Databases (ontwerpen, realiseren), Systeemontwikkeling, Software Engineering (UML, ontwerpen, modelleren, programmeren) en vast nog veel meer .

[AtleX]

Verwijderd schreef op zondag 27 april 2008 @ 01:52:...en vast nog veel meer .

Zo komt er bij ons nog wat bij als ontwikkelmethodes (SDM, DSDM, RUP, etc.), maar ook wat beheer (configuratiemanagement, helpdesk). Daarnaast worden er geregeld gastcolleges gegeven door mensen van bedrijven, zodat je ook eens hoort hoe het nu allemaal echt toegepast wordt.

[not2secure4u]

Bedankt voor de reacties al iedereen... Het helpt me enorm, kga wss eens wat cursussen uitpluizen en al wat proberen en zien waar het me brengt. Aangezien de school waar ik ga in het eerste jaar nog geen Java geeft, enkel C++ en SQL zal ik mss best met die talen beginnen.

[Herko_ter_Horst]

Denk erom dat SQL geen echte programmeertaal is. Het is een query taal voor (relationele) databases (SQL = Structured Query Language). Hiermee kun je bijvoorbeeld geen grafische user interface bouwen of iets dergelijks, de taal is puur bedoeld om databases mee te bevragen en te wijzigen.

Zonder meer nuttig om te leren, maar niet als "programmeertaal".

[phobosdeimos]

Ik denk dat je hier doelt op een hogeschool?
Want bijvoorbeeld beginnen aan een universitaire informatica opleiding, zonder enige voorkennis, komt keihard aan, en is een schok die de meeste niet zullen verwerken.
Op hogeschool niveau is voorkennis niet zo'n absolute must.

[maxjuh]

0siris schreef op zaterdag 26 april 2008 @ 23:20:
Ik ben al bijna 10 jaar klaar met school, maar de conclusies die ik trek na het lezen van alle reacties hier, is: HBO informatica == programmeren? Niets meer dan dat? Dat was in mijn tijd gelukkig anders

Er zijn ook vakken die zich bezig houden met netwerken, operating systemen, microcontrollers (ook wel weer programmeren ja in C, maar ook zelf dingen etsen), industriële automatisering (heel saai overigens) en vast nog een aantal die ik nu even vergeet. Maar dan heb ik het eigenlijk niet over informatica maar technische informatica (TI). Wat mij bekend is houd informatica zich veel meer bezig met zaken als ITIL maar ook zeker programmeren. Hun hebben dan ook wel weer netwerken. Later mengen die twee richtingen zich dan wel in het 3e en 4e jaar als je een minor en major kiest. Wat ik dan wel merk dat de programmeer kunsten bij de informatica studenten vaak om te huilen zijn. "Dat kunnen wij niet, is er geen alternatieve opdracht die we kunnen maken?" sta daar toch wel verbaasd van te kijken. Ze hebben het allemaal gehad en al gelijk in het eerste jaar maar er zijn er zoveel die het gewoon verdommen om het te leren (zijn overigens ook TI'ers die het verdommen). Zo moeilijk is het toch niet?

In het begin vond ik het lastig maar het is een bepaalde manier van logisch denken en als je die beheerd wordt het heel leuk en stap je makkelijk over op een andere taal. Wij hadden dan in het eerste jaar Java, tweede C en nu in de derde jaar C++. Als bijbaan loop ik op dit moment te programmeren in C# en daar stap je heel makkelijk op over (misschien is dat dan niet zo'n goede vergelijking omdat het heel erg op Java lijkt).

Maar ik denk dat het heel goed is als je als ICTer iets kan programmeren en vooral heel handig zo af en toe. En dan hoef je nog niet eens een GUI te kunnen schrijven zoals hierboven ook al gezegd om vette dingen te doen.
Als voorbeeld wanneer het erg handig kan wezen: waar ik van de zomer werkte hadden ze op een aantal locaties verschillende configuratie bestanden staan en het hiervan was eigenlijk een overzicht nodig, waren dacht ik zo'n 60 a 70 bestanden. Omdat die ook nog wel is zo af en toe veranderen en het een rot klus is om al die informatie uit die bestanden zelf bij elkaar te rapen en in een rapport te stoppen heb ik daar toen maar een simpel programmaatje voor geschreven die dat voor mij deed. Was binnen no time klaar met het schrijven en was echt verdomd handig!. Hebben ze nu vast nog steeds plezier van.

[Hydra]

Gomez12 schreef op zaterdag 26 april 2008 @ 17:06:
Misschien omdat je dan ook iets van de basis ziet en een stuk begrip krijgt.

En sowieso, als je algoritmen / programmeerstructuren wilt leren dan is een mooie ide / intellisense alleen maar afleiding.

Wat een onzin zeg. Zaken als intellisense zorgen d'r vooral voor dat je niet binnen de kortste keren aan de RSI zit, en bovendien werk je sneller. Volgens jou schrijf je dus betere code als je 't in notepad schrijft. Wat een kolder.

phobosdeimos schreef op zondag 27 april 2008 @ 10:43:
Op hogeschool niveau is voorkennis niet zo'n absolute must.

Kennis misschien niet (ik had al voordat ik begon veel geprogrammeerd, en heb juist een hoop (niet-OO) dingen uit mezelf moeten meppen), maar affiniteit zeker wel. Ik heb zelf 10 jaar terug HIO (nu HBO-I) gedaan, en we hadden in het eerste jaar 70% uitval van knuppels die maar HIO waren gaan doen omdat ze spelletjes spelen wel leuk vonden.

Ik maak trouwens uit de post van 0siris op dat hij ook HIO heeft gedaan, dus volgens mij zit een aantal van jullie voor de kat z'n viool uit te leggen wat die opleiding nu precies omvat.

[ Voor 38% gewijzigd door Hydra op 27-04-2008 12:03 ]

[Verwijderd]

Dit moeten wij, als 1e jaars Fontys Hogeschool ICT studenten, kunnen:
http://fhict.fontys.nl/St...-fase%20studentversie.doc

In bijlage 1 zie je welke competenties wij moeten beheersen na 1 jaar, waarvan er een algemeen deel is (A-competenties) en een profiel-specifiek deel (B-competenties).

Kijk dan vooral naar de profielen "Software Engineering" en "Technische Informatica".

Om kort samen te vatten wat de A- en B-competenties inhouden:
A: Professioneel Handelen, Methodisch Handelen en Samenwerken
B: Anlyseren, Adviseren, Ontwerpen, Realiseren en Beheren

Dus een HBO ICT studie is wel "iets" meer dan alleen programmeren (wat valt onder Realiseren) .

[ Voor 24% gewijzigd door Verwijderd op 27-04-2008 12:26 ]

[Herko_ter_Horst]

A+B is m.i. precies het verschil tussen "Software Engineering" en "programmeren": iedereen die met een online PHP tutorial achter de kiezen de standen van de plaatselijke dartclub op een website weet te zetten kan zichzelf wel een hele programmeur vinden, maar het zijn juist de aspecten eromheen die wat mij betreft het verschil maken.

Dit komt misschien wat negatief over naar "programmeren" toe, maar dat is meer omdat ik op diverse fora vaak "programmeurs" tegenkom die zichzelf nogal overschatten (na het lezen van een Java tutorial wel even in een paar weken een MMORPG in elkaar draaien, dat werk).

Uiteindelijk is het verschil in niveaus en disciplines denk ik vooral een teken dat het beroep/de beroepsrichting volwassen wordt. Waar het 10 jaar geleden zo was dat iemand met een "informatica" opleiding - onafhankelijk van of dat nou een paar AMBI modulen waren of een volledige universitaire opleiding - zo'n beetje overal wel aan de slag kon om "iets met computers" te doen, tegenwoordig worden er toch specifiekere eisen gesteld door een markt waarin plaats is voor zowel programmeurs, software engineers als architecten, die zich liefst nog gespecialiseerd hebben in een bepaalde discipline (bijv. embedded systemen, financiele systemen of gaming).

PS. nog een "10 jaar geleden de HIO gedaan"-er hier

[ Voor 66% gewijzigd door Herko_ter_Horst op 27-04-2008 13:14 ]

[flowerp]

Herko_ter_Horst schreef op zondag 27 april 2008 @ 12:58:
Waar het 10 jaar geleden zo was dat iemand met een "informatica" opleiding - onafhankelijk van of dat nou een paar AMBI modulen waren of een volledige universitaire opleiding - zo'n beetje overal wel aan de slag kon om "iets met computers" te doen, tegenwoordig worden er toch specifiekere eisen gesteld door een markt waarin plaats is voor zowel programmeurs, software engineers als architecten,

Toch valt dat ook wel tegen hoor. Je zou zeggen dat 10, 20 jaar geleden informatica nogal een comboy beroep was. Weinig bestaande richtlijnen, weinig officiële opleidingen, etc. Veel informatica toepassingen lagen destijds ook nog grotendeels in de hobby sfeer. Je zou zeggen dat een goede 20 jaar later, waarbij de maatschappij in bijna al haar facetten steeds meer vertrouwd op ICT en iets als internet en email volledig verweven is in onze samenleving, de boel wel wat serieuzer zou worden.

Echter, nog steeds zijn er ellenlange discussies (ook hier op got) over het feit dat een opleiding voor software development helemaal niet nodig is, en dat je gewoon die Java of PHP turtorial moet leren en gaan coden. "coden leer je toch alleen in de praktijk" (volgens de mensen zonder opleiding dan). Ook in het bedrijfsleven zie je dat er amper differentiatie is tussen mensen die als developer werken. Bij sommige bedrijven gaat het voornamelijk om leeftijd of tijd dat je bij het bedrijf werkt of je als junior, medior of senior wordt aangemerkt. Dit terwijl er toch wezenlijke verschillen zijn in capaciteiten tussen developers onderling.

In het algemeen valt software development toch onder de hoger opgeleiden beroepen. Maar waar het bij meer volwassen beroepen als advocaat, arts, architect etc volkomen geaccepteerd is dat je je papieren hebt en dat er eisen gesteld worden aan je kunnen en dat er onderscheid is tussen een top architect en een gewone architect, wordt dat bij software developers steeds in twijfel getrokken. Een arts moet dan papieren hebben omdat het over levens gaat, en aan advocaat omdat het over "serieuze dingen" gaat etc. Maar software development gaat toch alleen over spelletjes en vergelijkings website'tjes waarbij het niet uitmaakt als er eens even wat plat ligt? [/sarcasme]

[not2secure4u]

En dus veel van zo een flash games die je zo een uur kan spelen ( louter een voorbeeld Diner Dash ...) Zijn dan grafisch ineengestoken in Flash om dat dat zich ervoor leent en gecodeert in c++ omdat dit zich achter de mechanieken in het spel kan steken en minder in de interface of heb ik het nu fout op ?

[Herko_ter_Horst]

not2secure4u schreef op zondag 27 april 2008 @ 14:45:
En dus veel van zo een flash games die je zo een uur kan spelen ( louter een voorbeeld Diner Dash ...) Zijn dan grafisch ineengestoken in Flash om dat dat zich ervoor leent en gecodeert in c++ omdat dit zich achter de mechanieken in het spel kan steken en minder in de interface of heb ik het nu fout op ?

Ik denk dat je het "fout" hebt.

Flash spelletjes zijn meestal geheel in Flash geschreven. Het "ineensteken" van de interface gaat via een ontwerp/ontwikkeltool die ervoor zorgt dat je niet alle Flash code helemaal zelf hoeft in te kloppen: je sleept met wat venstertjes en de tool genereert de juiste Flash code om die venstertjes te tonen. Spel-specifieke zaken schrijf je dan wel "met de hand", maar de interface kun je tot op zekere hoogte zonder zelf een regel code te schrijven bouwen.

Het is wel zo dat Flash specifiek gemaakt is voor dit soort toepassingen. Maar er kan (met meer moeite) heel veel meer mee. Maar als jij tegen een bank zegt: we gaan jullie hele bancaire transactiesysteem in Flash maken, dan lachen ze je vierkant uit. Want hoewel het misschien theoretisch best zou kunnen, zijn er geschiktere talen en bewezen frameworks en libraries voor dat soort problemen.

C++, Java, C# e.d. zijn meer "general purpose" talen, waarbij er voor bepaalde oplossingsrichtingen weer specifieke extra frameworks en libraries te krijgen zijn. De taal zelf is maar een klein onderdeeltje van het programmeren. De standaard libraries en (al dan niet 3rd party) frameworks en libraries zijn veel belangrijker.

Maar nog belangrijker is je eigen probleemoplossend vermogen, gekoppeld aan theoretische kennis over software ontwikkeling. Tenminste, als je verder wilt komen dan "Flash games ineensteken" of een PHP siteje in elkaar fietsen.

[Herko_ter_Horst]

flowerp schreef op zondag 27 april 2008 @ 14:17:
[...]
In het algemeen valt software development toch onder de hoger opgeleiden beroepen. Maar waar het bij meer volwassen beroepen als advocaat, arts, architect etc volkomen geaccepteerd is dat je je papieren hebt en dat er eisen gesteld worden aan je kunnen en dat er onderscheid is tussen een top architect en een gewone architect, wordt dat bij software developers steeds in twijfel getrokken. Een arts moet dan papieren hebben omdat het over levens gaat, en aan advocaat omdat het over "serieuze dingen" gaat etc. Maar software development gaat toch alleen over spelletjes en vergelijkings website'tjes waarbij het niet uitmaakt als er eens even wat plat ligt? [/sarcasme]

Ik ben het tot op zekere hoogte met je eens voor zover het over "software development/engineering" gaat. Maar niet alle mensen die software schrijven hoeven software engineers te zijn, net zoals niet alle mensen in een ziekenhuis arts hoeven te zijn. Naast de universitair opgeleide arts zijn er ook HBO opgeleide verpleegkundigen en MBO opgeleide assistenten op allerlei gebieden. Er is m.i. dus best te differentieren naar bijv. "programmeurs" die netjes een door een "software engineer" aangeleverde, duidelijk omschreven specificatie in een bepaalde taal kunnen implementeren, ook zonder een hogere opleiding.

Overigens heb ik wel het idee dat er in (met name grotere) bedrijven toch wel wat meer gedifferentieerd wordt dan de topics hier op GoT doen vermoeden. Maar er is denk ik nog onvoldoende transparantie in de markt, waardoor de "PHP cowboys" nog steeds hun "dynamische" websites (waarbij echter voor elke update apart betaald moet worden) aan het MKB kunnen blijven verkopen.

Het "1337 |-|4x0r" syndroom zal echter waarschijnlijk moeilijk uit te roeien zijn, mede omdat het door goede tools relatief makkelijk is om "iets werkends" te krijgen, waardoor iemand al gauw het idee krijgt dat hij/zij heel wat in z'n mars heeft.

[not2secure4u]

Owja zo ...

Maar wat je aanhaalde van het probleemoplossend denken kan ik maar weten als ik de opleiding in ben ?

Dus als ik het goed versta gebruik je veel van de talen NIET voor iets specifieks als banksystemen omdat het zich daar gewoon niet voor leent?

[Herko_ter_Horst]

Eigenlijk omgekeerd: ik bedoelde te zeggen dat Flash ontworpen is voor een bepaald toepassingsgebied, namelijk "grafisch aantrekkelijke, interactieve, op eindgebruikers gerichte applicaties binnen een browser" (even kort door de bocht).

"General purpose" talen zoals Java, C++ etc. zijn juist NIET met een dergelijk doel ontworpen en zijn daardoor geschikt voor meer verschillende toepassingen. Hoe geschikt is dan meer afhankelijk van welke frameworks en libraries er beschikbaar zijn.

Zo zal je voor het back-end systeem van een bank geen Flash gebruiken omdat je functionaliteit nodig hebt voor beveiliging, database transacties en server-naar-server communicatie die in/voor Flash niet beschikbaar zijn. Dit betekent echter niet dat het strict onmogelijk is.

Wat ik bedoel te zeggen is dat een taal als Flash (maar ook bijvoorbeeld een taal als PHP) heel goed/makkelijk te gebruiken is in het toepassingsgebied waarvoor de taal bedacht is, maar dat je je vaak in heel veel bochten moet wringen als je buiten dat gebied komt. Dit in tegenstelling tot general purpose talen, waarbij je vaak wat meer moeite moet doen om die taal binnen een bepaald toepassingsgebied te gebruiken, maar je veel meer vrijheid hebt om uitstapjes te maken mocht dat nodig zijn.

Een deel van de kennis die je als "software engineer" moet hebben is te bepalen welke taal/welk framework het meest geschikt is voor een bepaald probleem. Ken je maar één taal of framework, dan ga die taal vaak zien als de meest geschikte oplossing voor alle problemen óf je beperkt jezelf tot problemen die bij die taal passen ("if all you have is a hammer, every problem starts to look like a nail").

Dat hoeft niet slecht te zijn, als je je er maar van bewust bent, zodat je niet bij die bank aankomt met een verhaal over Flash.

[ Voor 44% gewijzigd door Herko_ter_Horst op 27-04-2008 16:18 ]

[not2secure4u]

ohja zo. Dus het is de kunst je te verdiepen in een taal zodanig dat je dan makkelijk de ideen en syntax van andere talen kan eruit halen ?

[Herko_ter_Horst]

Ik denk dat je hetzelfde bedoeld, maar ik zou het iets anders zeggen: het is de kunst zover "boven" één bepaalde taal te staan dat je niet vastzit aan die taal, maar de algemene principes kunt toepassen met gebruik van eender welke taal én begrijpt waarom de ene taal meer geschikt is voor een bepaald probleem dan de andere.

Dat gezegd hebbende: ik heb inmiddels meer dan 10 jaar ervaring met "programmeren", waarvan 10 jaar met Java. Uiteraard ken ik de principes en zal ik (bijvoorbeeld) C++ code best snappen. Maar als ik ineens in C++ zou moeten gaan programmeren zou ik echt wel even wat tijd nodig hebben om weer net zo efficient en effectief te kunnen werken als nu met Java. Gewoon omdat ik de hele C++ wereld niet (meer) ken. Dat heeft niet zoveel te maken met de taal zelf, want daarin zitten niet zulke grote verschillen: C++ kent net als Java if-then-else constructies, for-loops, classes, etc. Het heeft veel meer te maken met alles bovenop en rondom de taal: best practices, frameworks, libraries, websites met informatie, communities.

Kortom: realiseer je dat een programmeertaal slechts een middel is om een doel te bereiken. Ga dus ook niet zozeer kijken of je een taal leuk vindt of niet, maar of je het oplossen van problemen met behulp van computerprogramma's leuk/interessant/uitdagend vindt.

[ Voor 11% gewijzigd door Herko_ter_Horst op 27-04-2008 16:40 ]

[Confusion]

Herko_ter_Horst schreef op zondag 27 april 2008 @ 15:35:
Maar niet alle mensen die software schrijven hoeven software engineers te zijn, [..]

Iedereen die software schrijft moet nadenken over de overzichtelijkheid en begrijpelijkheid van zijn code, omdat hij het zelf anders een jaar later ook niet meer snapt. Om code begrijpelijk en onderhoudbaar te kunnen schrijven moet je niet alleen fatsoenlijke variabele- en methodenamen gebruiken en commentaar schrijven, maar moet ook nadenken over een aantal aspecten die niet zuiver onder kunnen programmeren vallen, maar die horen bij het ontwerpen van code. Iemand die code schrijft dient minimaal na te denken over
• het opdelen van verantwoordelijkheden over klasses/scripts/code-onderdelen en
• de herbruikbaarheid van zijn code: welke code dreigt meerdere malen op net iets andere manieren herhaald te worden en moet in een losse, herbruikbare methode worden ondergebracht?

Wie code schrijft zonder die twee aspecten in de gaten te houden, produceert per definitie een nachtmerrie. (Waarmee ik niet beweer dat alleen die twee voldoende zijn om fatsoenlijke code te schrijven).

[not2secure4u]

Met welke motivatie zijn jullie er aan begonnen dan ? Ik interesseer er mij voor, maar op DIT moment kan ik mij nog geen toepassingsgebied inbeelden omdat ik er nog niets van ken ... Hoe lossen jullie dit probleem op ?

[Herko_ter_Horst]

Mijn motivatie was in het begin (en dan heb ik het over middelbare schooltijd) simpelweg luiheid Ik dacht dat ik de computer het allemaal wel kon laten doen. Oef, wat een vergissing

Maar ik bleef (en blijf) het ontzettend interessant vinden te proberen een computer te laten doen wat ik wil op een manier dat anderen (met minder technische kennis/interesse) zo'n computer effectief kunnen gebruiken.

Mijn blijvende frustratie/uitdaging is dat na al die jaren "automatisering" we op veel terreinen nog steeds zo ontzettend slecht zijn in het verbergen van hoe een computer werkt. Muizen, toetsenborden, windows, menu's, commando's intikken: allemaal waardeloos Allemaal zaken waarmee de mens wordt aangepast aan de machine, in plaats van andersom.

En dat allemaal omdat computers letterlijk te stom zijn voor woorden

Dus ben ik ook erg blij met mijn huidige werk op het gebied van het Semantic Web: weer een kleine stap naar waar ik vind dat het uiteindelijk naar toe moet: computers die ons echt verder helpen zonder ons te frustreren.

[flowerp]

Confusion schreef op zondag 27 april 2008 @ 20:20:
Iemand die code schrijft dient minimaal na te denken over
• het opdelen van verantwoordelijkheden over klasses/scripts/code-onderdelen en
• de herbruikbaarheid van zijn code: welke code dreigt meerdere malen op net iets andere manieren herhaald te worden en moet in een losse, herbruikbare methode worden ondergebracht?

Ik had het zelf niet beter kunnen zeggen Inderdaad, dit zijn 2 dingen die heel erg vaak verkeerd gaan. Of te wel bij beginners, of te wel bij mensen die gewoon wat minder talent hebben. De syntax van een taal kun je tot op zekere hoogte gewoon leren en onthouden, maar die 2 punten die Confusion noemt blijven toch dikwijls een combinatie van talent in abstract denken, kennis (b.v. bepaalde patterns gewoon kennen) en ervaring (snel situaties herkennen en een eerdere geslaagde oplossing herinneren).

Vooral dat eerste aspect (talent) heeft zoals gezegd lang niet iedereen. Het gevolg is code die gewoon niet te lezen is, niet te herbruiken is, en niet uit te breiden is.

Een concreet voorbeeld is iemand die b.v. een class in een algemene package stopt en die Updater.java noemt. Updater van wat? Zo'n persoon zit op dat moment bijvoorbeeld aan een ticket te werken om een personeels account up te daten. Hij of zij zit dan zo in die taak dat Updater een volstrekt logische naam lijkt. Echter, buiten de context van die taak is het een volstrekt onduidelijke naam. Als dit met 1 classe zo gebeurt dat valt er nog wel mee te leven, maar als 100 classes en 1000 variablen op deze manier van een naam zijn voorzien, dan wordt werken in die software een nachtmerrie.

Qua verantwoordelijkheden kun je b.v. denken dat zo'n Updater class van alles en nog wat gaat doen wat niet puur bij de kern taak van de class hoort. Bekend voorbeeld is als de class toevallig in een web omgeving werd gebouwd, dat er een http request object wordt mee gegeven en dat daar dan de benodigde parameters uitgehaald worden. Vervolgens gaat men dan binnen in de classe ook direct een DB aan roepen op een hardcoded URL, etc. De code is dan niet of zeer moeilijk herbruikbaar in een andere context.

Ook m.b.t. algoritmes zie je dit vaak. Ingewikkelde loops binnen loops met logaritmische complexiteit ( = ~executie tijd groeit meer dan evenredig bij het groeien van het probleem), terwijl het veel eenvoudiger en sneller op te schrijven is, gewoon omdat men alleen naar een specifiek geval kijkt en dan alle losse cases gaat zitten uit te programmeren, i.p.v. dat men het abstractie vermogen heeft om de algemene case en de constanten in het probleem te zien.

Ik heb mensen in m'n team zitten, eentje in het bijzonder, die dit gewoon niet uit zich zelf kunnen bedenken. Nadat ik het 10x heb uitgelegd doen ze precies na wat ik zeg, maar zodra er dan een iets andere situatie zich voordoet presteren ze het om het toch weer net verkeerd te doen. Het gaat dan o.a. om een persoon met maar liefst 8 jaar Java ervaring.

Misschien legt het aan de bedrijven waar ik kom en gewerkt heb, maar ik merk dat het zeer dikwijls not-done is om te zeggen dat iemand gewoon capaciteit en talent te kort komt. Je mag zeggen dat iemand nog niet voldoende ervaring heeft of eventueel dat iemand een wat lagere opleiding heeft, maar dat iemand gewoon geen talent heeft is bijna overal een taboe.

Dat is vreemd. Bij kunsten is het een zeer geaccepteerde stelling. Ik kan zelf bijvoorbeeld -absoluut- niet zingen. Geen enkele noot krijg ik er zuiver uit. Er is echter geen enkele taboe om te horen te krijgen dat ik geen talent voor zingen heb.

[curry684]

not2secure4u schreef op zondag 27 april 2008 @ 21:21:
Met welke motivatie zijn jullie er aan begonnen dan ? Ik interesseer er mij voor, maar op DIT moment kan ik mij nog geen toepassingsgebied inbeelden omdat ik er nog niets van ken ... Hoe lossen jullie dit probleem op ?

Ik programmeer gewoon al sinds m'n 6e, inmiddels 24 jaar

[maxjuh]

flowerp schreef op zondag 27 april 2008 @ 22:08:
[...]
Ook m.b.t. algoritmes zie je dit vaak. Ingewikkelde loops binnen loops met logaritmische complexiteit ( = ~executie tijd groeit meer dan evenredig bij het groeien van het probleem), terwijl het veel eenvoudiger en sneller op te schrijven is, gewoon omdat men alleen naar een specifiek geval kijkt en dan alle losse cases gaat zitten uit te programmeren, i.p.v. dat men het abstractie vermogen heeft om de algemene case en de constanten in het probleem te zien.

Ben benieuwd naar wat je hier precies bedoeld.

Zou me wel een situatie kunnen voorstellen waarbij je te maken hebt met een x aantal cases die worden bepaald door y aantal variabele. Waarbij dan de fout wordt gemaakt om elke mogelijke case uit te programmeren maar niet rekening wordt gehouden dat bepaalde cases nooit voor kunnen komen.

Moet ik aan dit soort fouten denken?


Zelf ben ik een aardige bekwaam in het programmeren maar als je soms code van andere mensen zie sta ik echt verbaasd hoe ze ooit op het idee zijn gekomen om het op die manier uit te schrijven.
Als voorbeeld weet ik nog wel dat iemand het had gepresteerd om 1000 regels code te schrijven voor een relatief simpel probleem. In dit geval was zoiets gedaan als het hele probleem op te lossen in een paar giga methodes en kwam het zelfde stukjes code constant tegen met een marginaal verschil. Heb die code toen dus ook niet geaccepteerd.

Een nog wel extremer voorbeeld is een project wat we hadden en ik was daarbij verantwoordelijk voor de back end code en iemand anders voor de hele weergave daarvan, front end. Als afspraak hadden we om MVC te gebruiken en had daarom ook alles keurig opgedeeld (wat je natuurlijk altijd doet) maar meneer leek het wel een goed idee om daar een grote main klasse tegenaan te gooien, weg dus het hele idee van MVC en haast niet te achterhalen waar de bugs zaten. Dan werd er een opgelost maar die mega main klasse was zo groot en verweven dat er gelijk weer een andere bug optrad.

Volgens mij heb ik mijn eigen vraag beantwoord door dit op te schrijven

[curry684]

Maxjuh: helaas is het normaal dat je dat soort dingen tegen komt, er is zelfs een website speciaal voor de ergste uitwassen

[flowerp]

maxjuh schreef op zondag 27 april 2008 @ 23:21:
[...]
Moet ik aan dit soort fouten denken?
[...]
en kwam het zelfde stukjes code constant tegen met een marginaal verschil. Heb die code toen dus ook niet geaccepteerd.

Zoiets ja. Bovenstaande uitleg was natuurlijk erg generiek, maar het uit zich dikwijls concreet in het telkens terug keren van dezelfde stukjes code. Neem b.v. een simpel voorbeeld als een loop die characters uit een file inleest, afhankelijk van herkende zinnen iets moet doen, en telkens moet controleren dat je niet voorbij het einde van de file leest. Stel dat de zinnen "aap noot mies", "aap noot pieter" en "bier eelco" zijn. Even los van een werkelijk goede oplossing met token parsing en grammatica's, zal een naief iemand hier eerst char voor char gaan lezen tot dat ie aap heeft gezien, en zodra ie aap heeft gezien een subloop starten waarbij ie weer char voor char gaat lezen en eof gaat lopen controleren totdat ie noot ziet. Ziet ie noot, dan gaat ie een 3rde nested loop beginnen om mies te herkennen. Voor de andere combinaties heeft ie ook aparte loops. Etc.

Iemand die ook maar een beetje abstract kan denken, maakt 1 loop waarbij er op 1 plek een char gelezen wordt en op 1 plek op eof gecontroleerd wordt. Naarmate wat je herkent hou je een state bij. B.v. je begint bij state 0. Na het herkennen van "aap" zit je in state 1. Komt er daarna wat anders dan "noot" dan reset je je state naar 0, anders zet je je state op 2. In b.v. een tabel hou je states en overgangen er tussen bij.

Het idee is dus dat je niet elke mogelijke combinatie apart gaat uit programmeren, met aparte loops en aparte if statements voor elke constructie. Met ook maar iets meer dan een paar cases explodeert je code dan qua complexiteit.

Het paradoxale is dat de naïeve, non-abstracte aanpak aanvankelijk simpeler is. Beginners of mensen met minder talent zullen dan ook klagen dat de abstracte oplossing nodeloos complex is. Zodra het probleem echter iets groter is dan triviaal wordt de naïeve oplossing echter steeds complexer en blijft de abstracte oplossing nog steeds goed te overzien.

Een valkuil is echter wel het principe van over engineering. Soms is je probleem triviaal en dan moet je het niet overdreven abstract gaan implementeren. Een kunde is het weten wanneer je welke mate van abstractie moet toepassen.

curry684 schreef op zondag 27 april 2008 @ 23:37:
Maxjuh: helaas is het normaal dat je dat soort dingen tegen komt, er is zelfs een website speciaal voor de ergste uitwassen

Mooie site dat Vroeger dacht ik dat zulke verhalen nogal overdreven waren en grotendeels verzonnen. Sinds een tijdje functioneer ik als lead programmer en is 1 van mijn taken dat ik code van team members controleer op excessen. Ook zit ik af en toe bij klanten om implementatie problemen op te lossen. Het trieste is dat ik anekdotes zoals op de dailywtf vermeld worden -echt- in de praktijk tegen kom.

[ Voor 12% gewijzigd door flowerp op 28-04-2008 00:12 ]

[Hydra]

not2secure4u schreef op zondag 27 april 2008 @ 21:21:
Met welke motivatie zijn jullie er aan begonnen dan ? Ik interesseer er mij voor, maar op DIT moment kan ik mij nog geen toepassingsgebied inbeelden omdat ik er nog niets van ken ... Hoe lossen jullie dit probleem op ?

Ik vond programmeren gewoon leuk. Ik heb in basic echt vanalles gemaakt, van grafische effecten (start-field e.d.) tot tekst-spelletjes e.d. En nog steeds is het schrijven van code leuk, omdat je problemen aan het oplossen bent.

Confusion schreef op zondag 27 april 2008 @ 20:20:
Iemand die code schrijft dient minimaal na te denken over
• het opdelen van verantwoordelijkheden over klasses/scripts/code-onderdelen en
• de herbruikbaarheid van zijn code: welke code dreigt meerdere malen op net iets andere manieren herhaald te worden en moet in een losse, herbruikbare methode worden ondergebracht?

Niet als dat allemaal 100% voorgekauwd wordt aangeboden door een SE in UML diagrammen e.d.

curry684 schreef op zondag 27 april 2008 @ 22:13:
Ik programmeer gewoon al sinds m'n 6e, inmiddels 24 jaar

Ik typte vanaf m'n 6e basic listings over maar dat wil ik nog geen programmeren noemen Daarmee ben ik op de middelbare school begonnen.

flowerp schreef op maandag 28 april 2008 @ 00:07:
Mooie site dat Vroeger dacht ik dat zulke verhalen nogal overdreven waren en grotendeels verzonnen. Sinds een tijdje functioneer ik als lead programmer en is 1 van mijn taken dat ik code van team members controleer op excessen. Ook zit ik af en toe bij klanten om implementatie problemen op te lossen. Het trieste is dat ik anekdotes zoals op de dailywtf vermeld worden -echt- in de praktijk tegen kom.

Wij hebben een paar keer code van een (nu ex-) collega ingediend. Dat was te triest voor woorden. Deze persoon was een 'ervaren' programmeur welke wij helaas in z'n eentje aan een tweetal tools hebben laten werken. Een van de twee is nogal belangrijk voor ons, en dus is het helaas noodzakelijk een totale rewrite te doen. Leermomentje voor ons management.

[Hielko]

flowerp schreef op maandag 28 april 2008 @ 00:07:
Het idee is dus dat je niet elke mogelijke combinatie apart gaat uit programmeren, met aparte loops en aparte if statements voor elke constructie. Met ook maar iets meer dan een paar cases explodeert je code dan qua complexiteit.

Dit doet me denken aan fantastische staaltje programmeerwerk van een 1e jaars student voor het vak 'orientatie informatica'. De opdracht was het schrijven van een programma'tje dat gegeven vier getallen vertelt of je hier 24 mee kan maken (bijv. (3+5)*2+8). De oplossing? Een +/- 1800 regels tellend programma waarin alle verschillende mogelijkheden geprobeerd worden:

if (a+b+c+d==24) {
System.out.print....
} else if (a+b+c-d==24) {
etc etc...

[Confusion]

Hydra schreef op maandag 28 april 2008 @ 10:03:
Niet als dat allemaal 100% voorgekauwd wordt aangeboden door een SE in UML diagrammen e.d.

Als je dat doet, dan had je het net zo goed zelf kunnen schrijven. Bovendien is software altijd een product van voortschrijdend inzicht. Het is me nog nooit gebeurd dat ik niet tijdens het schrijven van een stuk code even gas terug moest nemen om het ontwerp te heroverwegen. Soms om te concluderen dat het wel OK was, vaak om te concluderen dat we het vantevoren toch niet helemaal goed gezien hadden. Wie niet kritisch is over het ontwerp van hetgeen hij schrijft, die produceert geen goede code.

[Verwijderd]

Confusion schreef op maandag 28 april 2008 @ 13:37:
[...]
Het is me nog nooit gebeurd dat ik niet tijdens het schrijven van een stuk code even gas terug moest nemen om het ontwerp te heroverwegen.

Ik denk dat dat ook onmogelijk is. Je hoort wel eens zeggen dat WO'ers sluitende ontwerpen maken die MBO'ers dan 1:1 inkloppen. Of te wel; designen is voor WO'ers en programmeren is voor MBO'ers. Ongeveer gelijk aan de analogie met architecten en metselaars.

Dit is meestal onzin. Vaak werk je tijdens development in een soort spiraal waarbij je alle aspecten van development (requirements, design, coden, testen) steeds doorloopt. In het eerste rondje van de spiraal zul je veel requirements doen, maar ook wel wat design en coden. Bij het zoveelste rondje doe je meer coden, maar nog steeds af en toe requirements en wat design.

Wel kun je hebben dat een senior developer een junior begeleid en een design voor een project in grote lijnen uitzet; hoe worden de verantwoordelijkheden ongeveer verdeeld, hoe zit de externe API grofweg in elkaar. De junior kan hier dan mee aan de slag, maar zal nog -veel- beslissingen zelf moeten maken en af en toe met de begeleider over leggen waarbij het design dan weer iets aangepast of verscherpt wordt.

[Hydra]

Verwijderd schreef op maandag 28 april 2008 @ 14:10:
Ik denk dat dat ook onmogelijk is. Je hoort wel eens zeggen dat WO'ers sluitende ontwerpen maken die MBO'ers dan 1:1 inkloppen. Of te wel; designen is voor WO'ers en programmeren is voor MBO'ers. Ongeveer gelijk aan de analogie met architecten en metselaars.

Dit is meestal onzin.

Ik heb in m'n 6 jaar werkervaring dit ook nog nooit gezien eigenlijk. Wel high-level technische design documenten, maar daar stond ook de implementatie niet in uitgewerkt, dat is toch aan de individuele developer.