Programmeurs/ict'ers gezocht! Ik maak je huiswerk
 

Hey,

Ik zoek mbo/hbo/wo leerlingen/studenten die hun huiswerk met mij willen delen. Ik ben zelf een 21 jarige student diergeneeskunde, maar ik ben ook erg geïnteresseerd in programmeren. Het is erg moeilijk om passende opdrachten te vinden om mijn vaardigheden hier in te verbeteren, daarom wil ik graag jouw opdrachten maken.

Stuur mij je opdrachten of zet ze in deze thread, dan zal ik ze proberen te voltooien (dit gaat niet altijd even snel ivm privé leven en eigen studie).

Bij voorbaat dank!

Zo moeilijk kan het toch niet zijn om oefeningen te vinden? Welke taal probeer je te leren?

Kijk eens naar codeacademy of projecteuler. Of bedenk een project en leer al doende.

In wat voor taal probeer je te leren programmeren?

Ik hoop C# want dat is de enige taal die er toe doet.

Fortran in je kanus, deadlock.

Co in je bol, deadlock.

F#

Is goed. Kan ik hem mee helpen want wat vroeger Novell was is tegenwoordig de maker van visual cobol.

Dat slaat natuurlijk helemaal nergens op, er zijn legio programmeertalen met allemaal hun eigen voor- en nadelen. :')

Oh en even interessant doen, C# gaat natuurlijk nooit Haskell vervangen. <3

Kom maar terug als je verstand hebt van programmeren jochie.

C# kan Haskell compleet vervangen.

Is Haskell in de afgelopen 6 jaar nog geüpdatet trouwens?

Fijn dat je zo op deadlock ingaat, dit kan nog wat worden :D

Ik vind het echt bijzonder grappig dat je een GPPL vergelijkt met een GPPL en dan zegt dat A dingen kan die B niet zou kunnen trouwens, Fool_. Je doet je naam eer aan.

Dat zegt ie helemaal niet. "Allemaal hun voor- en nadelen" en "x gaat y niet vervangen" zegt niks over wat er mogelijk is in die talen.

En tenzij je helemaal losgaat met de dynamische en functionele trukendoos van c#, is die taal 98% hetzelfde als Java dus ach.

En Haskell ook. Dus ach.

Nee man.

Mijn punt was trouwens niet dat het een beter zou zijn dan het andere, mijn punt was; Wil je productief zijn. Je kan prima productief zijn in ASM maar of het echt heel erg veel zoden aan de dijk zet? Denk het niet. Ik denk dat je beter Java of C# kan leren en uitvoeren dan Haskell simpelweg vanwege de enorme installbase en de hoeveelheid beschikbare online kennis en libraries. Ik ben zelf nog steeds een enorme fan van VB (en VB.NET) en zelfs van Logo. En ik denk heel eerlijk gezegd niet dat er iets is wat je in Haskell kan doen wat je niet in VB kan.

Hé, dit is misschien een goed topic voor mijn eigen vraag (al moet ik toegeven dat ik nog maar weinig uitgebreide googleacties heb ondernomen, vergeef me): ik wil graag leren programmeren, maar ik hoef juist geen fancy dingen te kunnen, ben niet van plan software te schrijven of aan hackatons mee te gaan doen of wat dan ook. Ik wil wel -voor onderzoeksdoeleinden op een heel ander terrein- de basisprincipes begrijpen en dat gaat waarschijnlijk makkelijker door het te doen dan door erover te lezen (correct me if I'm wrong). Oh en ik ben dus een superleek, ik weet niks van hardware en nog minder van software en dat hoeft niet te veranderen. Het hoeft niet gratis te zijn. Tips over waar te beginnen?

Jawel. Daar is het general purpose voor.

Dat de syntax iets anders is doet daar niet zoveel aan af.

Python is wel goed voor beginners. Ik weet niet precies wat je er van hoopt te leren maar op internet zijn 10 miljard gratis tutorials te vinden.

Oh ok. :D
Ik wil het (beter dan nu) begrijpen omdat ik denk dat het een ander vakgebied, wat ik hier niet kan toelichten vanwege de googlebaarheid, erg kan helpen. Of in elk geval kan het mijn denken over dat vakgebied helpen, vermoed ik.

Opdracht 1: schrijf een programma dat "Hallo scholieren!" op het scherm laat verschijnen.

Dat kan ik in twintig talen.

Ik denk dat ik wel; kan claimen dat ik enigszins verstand van programmeren heb. Als 't goed is kan ik na de zomervakantie m'n bachelor technische informatica ophalen en alle programmeertechnische vakken zijn al behandeld.

Ik heb eventjes opgezocht wat C# voor implementatie van functioneel programmeren heeft en wat mij zo snel opvalt is:

- Lazy evaluatie met als resultaat een functie, lazy evaluatie schijnt alleen te kunnen door er een nieuwe functie voor te bouwen en yield te gebruiken, daar kunnen geen ongeëvalueerde functies in. Iteraterators over oneindige lijsten zijn niet lazy?

- Datatypes en pattern recognition. Het enige alternatief voor pattern recognition zijn enge matches binnenin je functie.

- Currying, oftewel deels ingevulde functies die dus een nieuw typ functie worden.

- C# heeft niet standaard enkel immutable data types, als je écht een functionele taal wilt vervangen en niet enkele handige trucjes overnemen is dat vrij belangrijk.

- Type interferencing in C# is infertieur aan die van echte funtionele talen.

- Aangezien C# verschillende programmeerparadigma's aanhoud is het per definitie niet-puur en dus geen vervanger van Haskell. Je kunt er immers niet vanuit gaan dat geen enkele functie side-effects heeft.

- C# doet niet aan tail call optimalisation, dat betekend dat je met programma's die erg veel recursie gebruiken(best veelvoorkomend bij functioneel programmeren) een hele grote stack krijgt, mogelijk te groot en/of traag bij het uitbreken van alle recursie.

- Haskell heeft geen .NET framework nodig. :)

Ja hoor, het algemene platform heeft een halfjaarlijks release schema, de nieuwste versie kun je hier vandaan toveren. Daarnaast is er een vrij actief package uitwissel systeem, waar bijvoorbeeld vandaag al 20 nieuwe 'pakketten' op zijn gezet.

Was dat dom? :P

Als ik zeg dat C# Haskell niet gaat vervangen dan bedoel ik natuurlijk niet dat je niet dezelfde input en output in je programma kan krijgen, alle talen zijn turingcompleet, dus in principe kun je gewoon een turingmachine simuleren die het equivalent van een andere taal draait. :) Ik bedoel echter dat het niet altijd praktisch is. Ik ga in PHP ook geen aansturing voor een microcontroller of een complexe webserver schrijven, terwijl je PHP prima kunt compileren naar C++ en daarna naar executable.

Dat is mijn punt ook niet, voor elk doel heb je een ander middel. Ik probeerde ook zeker niet te suggereren dat TS maar moest beginnen met Haskell leren, dat lijkt me zeker niet verstandig.
Het voordeel van Haskell is echter ook niet dat je iets niet in een andere taal voor elkaar kan krijgen, maar dat hij vrij is van bij-effecten, geen mutabele variabelen heeft en veel directer relaties kan beschrijven. Bij risicovolle processen kan dat dus een voordeel bieden ten opzichte van andere programmeertalen, waar veel vaker bugs in voorkomen die niet opvallen. Zie hier een mooie lijst van voorbeelden. :)


Als je onderzoeksprincipes vooral algoritmes e.d. inhouden is Python misschien geen slechte keuze. :)

____________________________________
Ik heb hier echt teveel tijd ingestopt. :')

Perl leren, WORBN-taal: Write Once, Read by None. Niemand weet wat je doet en je kan vaak je eigen code niet eens teruglezen.

Ik pak er één uit. Ik ben geen informaticus of programmeur (alhoewel ik woon in een Eclipse-omgeving).
Klopt. Dat is voornamelijk vanwege backward compatibiliteit maar soms zijn ze nodig.

Nee maar is niet compleet platformonafhankelijk en streeft daar ook niet naar, waar C# dat wel doet.

Behalve dan dat het een van de traagste talen op aarde is.

Helemaal waar en ook helemaal prima voor een taal die zijn programmeur wilt laten kiezen uit verschillende opties van verschillende programmeerparadigma's, maar mede daardoor dus niet altijd een goede vervanger van Haskell. Daarmee raak je namelijk de puurheid van de taal kwijt. :)

Wel een beetje vreemd om te claimen dat ze hetzelfde zijn als je zelf niet echt een programmeur bent?

Je hebt een aantal 'backends' van de compiler, die platformspecifieke optimalisaties doen. Maar als je platform niet ondersteund wordt kun je Haskell gewoon compileren naar C en dan met GCC naar je eigen platform assemblere/compileren.
https://downloads.haskell.org/~ghc/l...ative-code-gen

Zo hebben er onderzoekers een tool ontwikkeld om haskell te compileren naar programmeerbare hardware (FPGA), zie http://www.clash-lang.org/ .
Natuurlijk binnen de grenzen die die chips fysiek hebben.

Dat klopt, met algoritmes is de complexiteit van je algoritme echter veel belangrijker dan de taal waarin je deze programmeert. Aldus mijn docent algoritmes&data structuren.

Fool is een aanwinst voor het forum.

Ghehe, thanks :)

Geen idee waar jullie het inhoudelijk over hebben (dit is geen uitnodiging voor uitleg) maar :lief: voor jullie kennis

Volgens mij zit er iets verkeerd om in je redenering. Als je heel specifiek iets wil doen is er altijd wel een taal die het beter kan dan een ander maar met puurheid heeft het niets te maken en in dit geval ben je volgens mij aan het zeggen dat taal A beter is omdat het minder functionaliteit heeft kort door de bocht gezegd.

Alleen chauffeurs kunnen het weggedrag van auto's beoordelen?

Dat is theoretisch te doen met een hele massa talen. Je krijgt er nog steeds andere binaries van die niet op ieder platform in te zetten zijn. Voor een goed voorbeeld van C# verwijs ik je naar Microsoft Singularity. Maar voor specifieke FPGA's zorgt volgens mij voor minder platformonafhankelijkheid en niet voor meer.

Klopt helemaal en Python is een hele praktische taal om heel veel concepten in te kunnen leren en vanwege de gigantische community die er beschikbaar is. Toch heb ik er een beetje moeite mee dat dit soort talen gebruikt worden voor deze doeleinden. Ik heb twee vrienden die Top500 HPC's (Universität Regensburg en UGA) beheren en die hebben de grootste moeite met uitbreidingsverzoeken voor hun machines omdat ze vinden dat processorcapaciteit inefficiënt benut wordt. Berekeningen duren vele cycles langer dan ze zouden moeten duren vanwege de inzet van dit soort programmeertalen waar eigenlijk C/C++ of ASM nodig is.

Nou lijkt het net alsof ik een Microsoft fanboy ben terwijl ik eigenlijk alleen SQL Server, SMB (needs disableable oplocks though), Office, IIS en Visual Studio en PowerShell leuk en goed vind :bloos:

De puurheid van Haskell betekend dat er geen onvoorziene side-effects ontstaan. Elke functie is een los geheel en beïnvloed op geen enkele (onvoorziene)manier ander deel van de code. De kracht van Haskell zit hem juist hierin, er is een heel scala een bugs die je niet meer programmeert. Ook ziet het er vaak een stuk gestructureerder en overzichtelijker uit. Zie ook: https://en.wikipedia.org/wiki/Referential_transparency
Zonder side-effect heb je bijvoorbeeld geen run-time crashes van je programma, dat soort geintjes valt allemaal compile-time al te controleren. :)

Point taken, ik realiseerde me ook nu pas dat Eclipse C# ondersteund. Ik vond het eventjes niet logisch dat ik aan het discusseren was met iemand over Haskell en C#, terwijl je je eigen ervaring beschreef als Java. My bad! :bloos:

Yup, dat is theoretisch te doen met elke taal, bij Haskell hebben echter mensen de moeite genomen het ook te regelen en te documenteren. :)

Grappig project trouwens, die Singluarity, maar lijkt het je zelf ook niet een beetje onpraktisch om alleen nog maar vast te zitten aan Microsoft z'n JIT? :P

Volgens mij kun je VHDL op elk zelf-respecterende FPGA laden hoor. Maar hoe zorgt dat in dit geval voor minder platformonafhankelijkheid? Het lijkt me juist aangeven dat veel van de concepten niet afhangen van en bepaald platform, maar juist prima geport kunnen worden?

Ja dat geloof ik direct hoor, voor het meeste modeleer en rekenwerk is Python imo best praktisch. Maar zodra je inderdaad bezig gaat met dergelijke computers en je alle complexiteitsverbeteringen al gedaan hebt is het inderdaad geen slecht idee om op een snellere taal over te stappen. :)

Het is je vergeven! :)

Hallo!

Maak van een lijst getallen intervallen:
1
2
3
5
7
8

Moet worden

1-3
5-5
7-8

Zeker waar.

(y)

Dat is denk ik nog maar kort vanaf nu. De meuk is vorige maand samen met een leuk iets genaamd Visual Studio Code een pak meer open source geworden en ik vermoed dat Mono uitgebreid gaat worden met volledige functionaliteit voor alle ondersteunde platformen.

Nou jah, dat weet ik eigenlijk wel zeker aangezien ik vorige week de developers heb gesproken.

Is die meuk tegenwoordig zo gestandaardiseerd?

Beetje het BASIC principe; Doe het daarin om het door te krijgen maar vergeet het dan heel snel en ga naar iets snellers. Want zelfs Python->BASIC is geloof ik minimaal een snelheidsverdubbeling. Zie voor meer info http://benchmarksgame.alioth.debian....hon3&lang2=gpp maar er zijn nog veel meer benchmarks waaronder een hele massa aan py scripts die we hebben omgebouwd naar onder andere ruby omdat het itereren door enkele miljoenen LDAP-objecten en een SHA2 hash berekenen met Python echt veel te lang duurde.

Mijn tip is een lijstje maken met welke 'basisprincipes' je wil begrijpen. Dit soort zaken zijn een aardig startpunt, gezien ongeacht de programmeertaal er veel terugkerende concepten zijn:

http://holowczak.com/programming-con...l-programmers/

Ik weet verder niet in welke richting je wil gaan: wil je meer begrijpen hoe bijvoorbeeld het web en browsers werken (http, html, css, javascript, server-client side), of hoe een programmeertaal zich uiteindelijk vertaald naar machinetaal (runtimes, compiling) hoe je optimaal veel data kan raadplegen ((relationele)databases, queries); er zijn nogal wat mogelijkheden.

Dank voor het meedenken allemaal. :)
Dat eerste niet en dat laatste ook niet. Dat tweede misschien. Kijk hier wreekt zich dus dat ik écht niet weet waarover ik het heb en dus ook moeilijk kan uitleggen wat ik wil. Toch nog een poging, ik wil, in mijn woorden, het denkproces van een ict-er begrijpen, de beslisbomen van een taal, hoe zo'n taal is opgebouwd en hoe je die dus kunt beheersen.

Misschien zoek ik het ook helemaal in de verkeerde richting hoor, en moet ik eerst verder met (formele) logica. Maar als ik een ict-er op werk spreek (en dan niet eentje van de helpdesk die een vastgelopen account fixt, maar eentje die de bezig is met het ontwerpen van de ict-kant van ons project) dan begrijpen we elkaar opvallend goed, terwijl we van totaal verschillende disciplines komen en er traditioneel juist vaak heel veel onbegrip is. Intussen zie ik steeds meer overlap tussen wat ik doe/wil doen, en ict, maar ik ook niet in het wilde weg allerlei dingen gaan vergelijken zonder wat beter te begrijpen wat ik dan aan het vergelijken ben. (En ja, ik moet ook op werk kijken of er geen ruimte is dat ik eens de stagiair ga uithangen bij zo iemand, maar gezien de onnoemelijke tijdsdruk achter ons project zal daar het komende jaar geen tijd voor zijn).

Hier is het vast niet begrijpelijker op geworden. :o

Mjah, het 'programmeren' is vaak maar een (relatief natuurlijk) klein deel van de werkzaamheden bij IT-projecten. Het is de oplossing om een bepaald (informatie)probleem mee aan te pakken. Het meeste werk zit doorgaans in het goed identificeren van alle processen en informatiestromen; en de bewerkingen die nodig zijn om iets in een bepaalde vorm van A naar B te krijgen en vice versa. Daar zit ook vaak het onbegrip, vragen in de hoek van 'waarom kan dat niet'; dat heeft meestal te maken met gebrek aan kennis van de betreffende informatiesystemen. Als je eenmaal weet wat je nodig hebt is de feitelijke implementatie vaak wat minder spannend (in mijn ervaring).

Ja, dat snap ik. En toch gaat het me om het programmeren.

Nou, daar zijn gelukkig tienmiljardmiljaar tutorials voor te vinden (y)

Het gaat natuurlijk nog verder dan dat. In principe kan je van zo'n beetje alles in Haskell wiskundig bewijzen dat het correct is en dat het doet wat het moet doen en da's vanwege de wortels in de lambda calculus. Bewijs dmv inductie is op de meeste functies prima uit te voeren.

@Quis: als het je puur gaat om het programmeren, dan kan je met de meeste willekeurige talen al een heel eind komen, omdat de meeste principes, zoals de flow van het programma wel hetzelfde zijn. Om in de .NET sfeer te blijven, Visual Studio Community is gratis. De reden dat ik die aanhaal, is omdat ik zelf erg gecharmeerd ben van Visual Studio, maar ook omdat je er in meerdere talen mee kunt programmeren.

Al-in-al vind ik het wel één van de betere IDEs waar ik mee gewerkt heb.

Het ligt wel aan wat je het beste ligt. Kan je prima wiskundig zaken benaderen en schroom je niet om deze als functies of proposities op te schrijven, dan zijn Haskell, Scala, Caml en Prolog leuke talen om mee te spelen. Heb je wat meer 'flow' nodig of wil je het wat meer in natuurlijke taal uitgedrukt hebben (if, while, not, etc.) dan zijn talen zoals Java, VB(.NET) en C# wat geschikter. Die talen hebben ook redelijk wat tooling en zijn zo in te komen vanwege de vele tutorials.
C en C++ kan je doen, maar dan moet je wel zin hebben in rekening houden met pointers en ik geloof dat dat wat meer afleidt van wat je wilt bereiken.

Is dat zo'n probleem ja? In ieder geval in de natuurkunde wordt er voor high performance-toepassingen louter C/C++ en Fortran gebruikt (of CUDA en zo voor GPU's, maar laten we het daar maar niet over hebben). Tenminste, ik heb nog nooit gehoord van iemand die iets anders naar een supercomputer heeft gestuurd.

Het klinkt wel als een cool principe, maar ik denk dat ik vriendelijk bedank. :P

Toen ik er vorig jaar op school mee moest werken leken ze de indruk te wekken dat dat vrij standaard was ja, maar sindsdien heb ik zo'n kreng ook niet meer aangeraakt. Misschien heb ik er wel een heel vertekend beeld van. :P

Wel jammer dat ze C++ compileren buiten de tijdsmeting mét extra optimalisaties, maar dat ze python tijdens de meting laten compileren om daarna gelijk uitgevoerd te worden. :P

Zeker waar, ik kan nog wel een heel betoog over Haskell gaan houden, maar volgens mij had ik het punt dat ik wou maken er al wel neergezet. (En het was al veel te laat :()

Yep. Het probleem is vaak dat programmeren gebeurt door de wetenschappers zelf en goed leren programmeren is een kunst opzich die losstaat van de opleiding. Vooral GPGPU's worden totaal kneuterig gebruikt. Een van die twee jongens is zelf de vakken gaan volgen omdat hij het leuk vindt en kan in de code gewoon aanwijzen wanneer er een fout wordt gemaakt waardoor het distributed echt totaal geen zin gaat hebben. Gelukkig worden de tools die nVidia en AMD en Intel leveren ook wel beter waardoor de code wordt geoptimaliseerd voor de platformen maar het is nog steeds lang niet zo efficiënt als het zou kunnen zijn.

Even voor de goede orde, de helft van de woorden die je aan me richt zijn abracadabra voor me. Maar dank voor het meedenken, ik zet alles op een rijtje en ga gewoon bij een van de dingen die jullie aanraden beginnen!

Ja, het klopt wel wat je zegt in de zin dat er in de opleiding relatief weinig aandacht wordt besteed aan programmeren, dus het is iets dat wetenschappers vooral al doende leren, en slechte gewoontes worden niet noodzakelijkerwijs gecorrigeerd. Ik ben zelf natuurlijk ook verre van een programmeerwhizzkid.