
Tanker om Arduino
For de af jer der endnu ikke har opdaget hvad Arduino er, er det på tide at I læser om det.
Jeg venter imens.
Godt så.
Hvis I kigger ovre i PHloggen på ing.dk, vil I se et eksempel på hvad Arduino bliver bliver brugt til:

Lige nu, sidder min 13 årige datter foran iMac'en og jeg citerer ordret: Citat:
Nej hvor er det her fedt mand! ... så skal 3,7 være gul ... og 5,0 være rød...
Arduino har lavet et objektivt set forkvaklet sprog, skrevet compileren i Java og der kan rejses 521 andre faglige kritikpunkter af projektet, langt hen ad vejen de samme kritikpunkter som ramte BASIC, bare opdateret med 30 år.
Men Arduino bliver, ligesom BASIC. brugt.
Hvis I laver en google billedsøgning efter arduino, vil ordet "misbrugt" hurtigt komme på tale.
Folk der ellers "ikke kan programmere" bruger pludselig Arduino til at styre deres spisekammerlamper, vækkeure, robotter og raketter.
Programmering er basalt set ikke vanskeligt: Gør dette, gør hint. Alle der kan følge en opskrift på risengrød har bestået Programmering 101 og alle der kan nedskrive en opskrift har bestået 102 også.
Jep, 99.99% af den kode der bliver skrevet med/i Arduino er ustruktureret klytkode, uden arkitektur, struktur eller blot nogenlunde gennemførte tanker.
Men det er kode der får microcontrollere til at gøre hvad folk vil have dem til, kode der frigør folk fra "fagfolkenes tyrani" i form japanske video/harddisk recordere og andet brugerfjendtligt skrammel.
Eller i min datters tilfælde blot en smiley:

Hvis vores IT uddannelser havde virket, havde Arduino været dansk...
phk
Kommentarer (13)
Det eneste magiske ved Arduino er en bootloader og børnevenlig indpakning af toolchain'en, selv sproget man bruger er C med støttehjul.
Det er nemt at skifte de børnevenlige komponenter (sprog, IDE, bootloader, hardware) en af gangen efterhånden som man får brug for mere kontrol og før man ved af det har man et professionelt system og en karriere;)
Lad os håbe at der er flere der bliver hooked.
Er jeg den eneste der tænker Lego Mindstorms?
Uanset, jeg har tit tænkt over forskellen på de "børnevenlige" og de "rigtige" programmeringsværktøjer. Det er svært at finde noget værktøj som er begge dele, men jeg kan ikke se nogen grund til at det skulle være eksklusive egenskaber.
De børnevenlige værktøjer falder typisk igennem på eksekveringshastighed, hvilket stort set udelukkende skydes compileren eller mangel på samme, og så ting som debugging muligheder, dårlige objekter og manglende variabeltyper.
De rigtige værktøjer fejler typisk i dokumentationen, den basale introduktion er der ikke, eller der er et stykke kvalmende markedsføringsmateriale som fortæller hvor godt produktet er, og den faktiske info drukner i information som en nybegynder alligevel ikke har mulighed for at tage stilling til. En computerspilsagtig tutorial fulgt op med eksempelrig dokumentation kunne virkelig gøre en forskel for mange udviklingsmiljøer. Der kan også være problemer med krav om eksplicitte deklarationer af alt muligt, for os andre er det bare irriterende at skulle skrive offentlig-statisk-intethed-hoved (eller hvad det nu måtte hedde på dansk), men for en nybegynder kan for meget af den slags volapyk være forvirrende, og det øger mulighederne for syntaksfejl, og så kan kryptiske fejlmeddelelser fra compileren ellers sørge for at det kan tage lang tid at finde små syntaksfejl.
Et andet ret så udbredt "fordummende" "sprog" er Processing. Min opfattelse er at det mest bliver brugt af folk med hang til at lave udstillinger og visuelle eksperimenter, men også lidt til undervisning.
Uanset, jeg har tit tænkt over forskellen på de "børnevenlige" og de "rigtige" programmeringsværktøjer. Det er svært at finde noget værktøj som er begge dele, men jeg kan ikke se nogen grund til at det skulle være eksklusive egenskaber.
Ikke direkte. Men hvis du ruller ressource-dimensionen hen over, så kan tiden og pengene kun anvendes én gang, og optimering af det ene vil tage ressourcer fra optimering af det andet.
Læg dertil at jo mere "rigtige" tingene skal være, des mere kompleksitet vil der tilføjes - flere muligheder indebærer at der også er flere muligheder for at ryge ud i hegnet - og det er ikke "børnevenligt".
Jeg har selv introduceret Arduino hjemme, sammen med et par byggesæt fra Brinck. Det har resulteret i en elektronikkasse og der kommer til at være mange sjove timer med det - sammen med sønnen på 10 år.
Og så kom jeg også til at købe en Xilinx spartan 3AN FPGA til mig selv i julegave, så det bliver et nørdet år i 2010.
Husk også Labitat.dk hackerspace der er på vej!
Husk også Labitat.dk hackerspace der er på vej!
Jeg meldte mig ind i december for at støtte det gode initiativ.
Poul-Henning
Er jeg den eneste der tænker Lego Mindstorms?
Nej!
En lille smule off-topic anbefales også Scratch (se http://scratch.mit.edu), som er et Mindstorms-inspireret miljø med erklæret fokus dels at lære børn den konstruktionsorienterede side af komputter-brug og dels at fremme en sharing-orienteret kultur.
Citat fra datteren på 9½ efter at have kigget mig over skulderen i 3-4 minutter: "Ejjjj, sejt! Flyt dig, jeg vil også prøve!". Så var hun hooked.
Scratch's målsætning og foreløbige resultater er beskrevet i CACM vol.52 issue 11, findes i ACM dig. lib. her: http://portal.acm.org/citation.cfm?id=1592761.1592779&coll=portal&dl=ACM... (kræver ACM-medlemskab samt adgang til digital library).
Ikke direkte. Men hvis du ruller ressource-dimensionen hen over, så kan tiden og pengene kun anvendes én gang, og optimering af det ene vil tage ressourcer fra optimering af det andet.
Det er selvfølgelig en grund, jeg synes bare at der burde være merværdi nok i et sprog som falder i begge kategorier til at nogen skulle kunne finde ressourcer til begge dele.
Læg dertil at jo mere "rigtige" tingene skal være, des mere kompleksitet vil der tilføjes - flere muligheder indebærer at der også er flere muligheder for at ryge ud i hegnet - og det er ikke "børnevenligt".
Nu er det selvfølgelig lidt bredt generelt vi diskuterer, så det kommer nok lidt an på tilfældet, men behøver den kompleksitet at være der? Og kan det ikke være valgfrit om man vil bruge den kompleksitet?
Pris 199,-
Jeg har kigget en del efter diverse IO produkter.
Dem jeg har fundet, er væsentlig dyre og har lang færre features. Specielt produkter rettet mod alarm markedet og mod home automation markedet.
Sådan et par Arduino ligger snart i min indkøbskurv !
phk: Kan du løfte sløret for hvilke førstehåndserfaringer du har med de danske IT-uddannelser?
Uanset, jeg har tit tænkt over forskellen på de "børnevenlige" og de "rigtige" programmeringsværktøjer. Det er svært at finde noget værktøj som er begge dele, men jeg kan ikke se nogen grund til at det skulle være eksklusive egenskaber.
Jeg tror ikke "børnevenligt" versus "rigtigt" er en god modstilling her. Men der er en ægte modstilling mellem "komme hurtigt i gang" og "bygge store komplekse systemer". Det ene kan næppe siges at være rigtigere end det andet, men jeg tror det er indbyrdes modstridende mål.
Et sprog til at komme hurtigt i gang med er et der underforstår en masse. Idet mange valg er taget for programmøren på forhånd, kan man nøjes med at skrive temmelig lidt for at få noget interessant til at ske. Dette er en God Ting, så længe ens ønsker kan rummes indenfor standardvalgene.
Sproget kan naturligvis sagtens give mulighed for at overstyre standardvalgene -- men det indebærer i sagens natur at man må bruge en mere kompleks grænseflade end den lette hvor valgene var truffet på forhånd.
Når man bygger større og mere komplekse systemer, begynder den nemme syntaks til standardtilfældene (eller globale defaults så man ikke skal specificere alting hver gang man gør noget, eller lignende komme-let-igang features) til at være en dødvægt i stedet for en lettelse. I store systemer støder man (fordi de er store!) på langt flere abstraktioner som er programmørskabte, end det endelige antal primitive abstraktioner sproget giver en speciel let understøttelse for. Så er de "nemme" tilfælde efterhånden blevet irriterende særtilfælde som man ikke kan behandle på samme måde som hele resten af systemet.
For den enkelte programmør er dette måske ligegyldigt. Man kan jo bare lade være med at bruge de simple (men ikke-ortogonale) muligheder. Men implementører af udviklingsværktøjer har ikke den frihed, og jo flere særtilfælde sproget har for at gøre det let at komme i gang, desto mere komplekst bliver det at skrive værktøjer til sproget.
Alt andet lige vil et sprog der er tynget af færre børnevenlige særtilfælde, have bedre chance for at få: Mere end én implementation. Plugins til dit yndlings-IDE. Gode debuggere og profilere. Værktøjer til statisk analyse. Flere tredjepartsbiblioteker. Altsammen væsentlige parametre når man vil bygge noget stort, men nærmest ligegyldigt når man bare skal have et lille program til at køre i en fart.
Jeg tror der er mange der har lavet sprog til alverdens formål, fordi de lige havde et problem de skulle løse eller ville se om det kunne lade sig gøre. Jeg har i studietiden lavet en rimelig avanceret pl0 oversætter til z80 (rcursive descent), udvidet en standard prommed BASIC fortolker med Semaforer for udførelse a co-rutiner, samt lavet et sprog til generering af sql-baserede testdatabaser af en hver størrelse med alle slags relationer (Gnu, Bison), fortolkning af skriftligt sprog, awk baseret sprog til mønsteranalyse af store datasæt, mmm.
Problemet er ikke at lave de specielle ting, problemet er at finde nogen det kan se mulighederne i det og sælge det.
