Messages

Hehe!

PHP har sina riktigt trevliga sidor med. Vill man enkelt skapa dynamiska hemsidor är det ett jättetrevligt verktyg. Kraftfullt och lätt att jobba med.
Men lätt, förutsatt att man har lite koll på programmering

Som skolspråk däremot, nej. Det finns nog de som inte håller med.

Har precis gjort mitt första riktiga projekt i PHP och det är definitivt inget bra nybörjarspråk. Man kan göra lite hur som helst utan att det riktigt framgår varför och möjligheten till att debugga är minimal. Dessutom måste man, förutom att förstå PHP också kunna grundläggande HTML samt förstå hur en webbserver fungerar. Dåligt med "förlåtande"  språk, varför.? Språk som sväljer inkonsekvens eller fel lämnar lite utrymme för förståelse och insikt i hur det funkar.

C# är en bra kandidat. Gratis utvecklingsmiljö, mycket med exempel online, ett hyfsat enkelt språk i sig med en mycket enkel men kraftfull editor., Jag kan gräva fram några bra länkar.

Dessutom har undertecknad jobbat med det de närmaste 6 åren så hjälpen är nära.

Kul!

Ja, Ariane är intressant exempel. Sen kraschade den inte, man valde att spränga den när man konstaterade att man inte hade kontroll över den. Alla (?) raketer har den möjligheten - bättre spränga den när man själv väljer det än att låta den åka lite som den själv vill och sen landa på någons stortå.

Finns andra intressanta exempel på problem och problemlösning inom programmering. Hörde nån gång att Saab (tror jag) hade problem med en bugg i mjukvaran för ABS-systemet. ABS-systemet är (rimligtvis) ett realtidssystem där livscykeln för vad programmen gör är väldigt väldigt kort. Man noterade att buggen uppstod efter en "tids körning". Den mest kostnadseffektiva lösningen på problemet var att starta om operativsystemet som körde ABS-programvaran X gånger i sekunden så att det aldrig hann köras så länge att buggen uppstod. Uppstartstid av operativsystemet var uppenbarligen inget problem. Fult? Dumt? Smart? Well, jag vet till att börja med hur sant det är, än mindre vad som faktiskt gällde. Men om vi leker med tanken att det är sant. Jag tycker det är en öppen fråga. Som programmerare tycker jag självklart inte om lösningen, men om man är lite pragmatisk... kanske?...

En sak som dagens mer avancerade/funktionella utvecklingsmiljöer ger är faktiskt sämre programmerare. Nu talar jag tyvärr för mig själv. Jag har blivit så van vid att kunna debugga kod att jag hellre gör det när nåt inte funkar än att jag varken före eller efter buggen skrivits funderar på *varför* det kan vara fel. Lättare att bara starta en debugsession och sätta en brytpunkt och se vad variabeln får för värde än att tänka efter.

Samtidigt finns det många system, hemsidor och program som inte skulle vara hälften så stabila och funktionella (om de alls fanns) om inte kompilatorer och utvecklingsverktyg har utvecklats och förfinats över åren. Mels situation är som sagt inte längre applicerbar på hårdvara längre (i de flesta fall) men väl på verktyg och programmeringsspråk.

Sitter med handhållna enheter på jobbet. Det ironiska är att med det har man tagit några steg bakåt. Minne, begränsad upplösning på skärmen etc är återigen en faktor Däremot är verktygen för att hantera detta klart mer mogna nu än för 10-20 år sen.

Stabil kniv. Ballistic missiles from 100 m. Jojo, det är ett bra säljargument onekligen

Apråpå verktyg. För att fortsätta använda liknelser. En mekaniker måste ju förvisso någon gång lära sig hur man använder t.ex. en skiftnyckel eller en ODB-läsare. Men viktigare är att lära sig att förstå NÄR han eller hon behöver använda den och varför. Att sen lära sig handgreppet är i sammanhanget en "småsak". Så vill man bli mekaniker är det inte rätt väg att gå genom att signa upp sig på kurseb "praktisk skiftnyckelsanvändning" och sen tro att man är mekaniker.

Problemet är ju att många erbjuder den typen av kurser och får folk att tro att då är allt grönt. =)

Det tror jag! Att skapa lärande är en gåva i sig och något som tyvärr många av dina kollegor verkar sakna eller ha förlorat på vägen.

En sak du direkt kan tillämpa som "end user" av rang är vikten av att vara kritisk (gäller ju iofs allt) på ett konstruktivt sätt. Ställa frågor. Inte nöja sig med ett svar om det inte verkar vettigt eller förståeligt.

Programmering, i min värld åtminstone, handlar om problemlösning. Det är lite som attt bygga lego. Man har en låda med bitar och man har något man vill bygga. Sen gäller det att inte bara hitta rätt bitar (vilka ÄR rätt bitar?) utan sätta ihop dem på ett sätt så att resultatet blir det önskade (och vad är det?). Som yrkesverksam programmerare så bygger man saker andra vill ha istället. Och oftast utan att de kan beskriva vad de vill ha, bara vad de inte vill ha - i bästa fall.

Programmeringsspråk är just vad de låter som. Språk. Med syntax och grammatik. Däremot, till skillnad från talade språk, är deras syntax och semantik striktare, mer begränsad och lämnar lite eller inget utrymme för "utsvävningar". Många som vill programmera fokuserar för mycket på språket och för lite på vad det är för problem man ska lösa. Om problemet är att någon vill ha en kopp kaffe, kanske inte lösningen är att bygga en kaffebryggare utan köpa en kopp kaffe i fiket? Eller blanda lite snabbkaffe eftersom det finns i skåpet? Ser så många exempel där man förespråkar sitt "favoritspråk" för det har fördel X eller Y. Och det är bra: har man ett favoritspråk kanske man också är bra på det. Och hellre lösa ett problem med verktyg man är van vid än att göra ett sämre jobb med verktyg man inte kan (alls). Samtidigt måste man som programmerare våga ifrågasätta valet av verktyg ibland också.

En sak du definitivt kan ta med dig till dina elever om de är intresserade av programmering är följande (och ta det från en som undervisat i programmering och gjort datorspel professionellt): vill man lära sig programmering ska man välja ett språk som är någorlunda enkelt att förstå sig på, utan att det för den skull gör "allt" jobb åt en (då lär man sig ju inte heller). Ser så många tragiska exempel på folk som i sin iver att göra t.ex. häftiga spel börjar med C++, som är det vanligaste språket för 3D-spel av rang. Det är helt absurt. Det är som att sätta nån som är intresserad av att lära sig köra bil i en Formel-1 bil, ge dom en klapp på ryggen och säga åt dem att dra tre varv på Monza. C++ och 3D-spel kräver något av en formel-1-förare för att inte sluta i en krasch, faktiskt. Och några blir bra formel-1-förare men de började med enklare prylar först...

Nej, att börja programmera handlar om att lära sig lösa små problem först. Att lära sig att val av verktyg är en del av programmeringen. Att man kan lösa samma problem på många olika sätt, där vissa är långsamma, andra är enkla att underhålla och några är kanske fula/dåliga men tillräckliga för den uppgift de är tänkta att lösa. Etc etc. När jag pluggade datavetenskap nötte vi mycket att se programmeringen som just problemlösning och sen på labbtid fick vi tillämpa det på olika programmeringsspråk. Men då var de just verktyg. Många jämställer programmering och programmeringsspråk men då lurar man sig själv lite.


Lång utläggning men det är något jag brinner för. Undervisning och programmering. Kanske därför jag jobbar med båda dessa saker =)

Skulle styrsystem till avancerade flygplan skrivas i maskinkod hade vi haft betydligt fler krascher.

Hela poängen med att tillämpa mångårig forskning i kompilatorer är att vi kan automatisera mycket som ja, i begränsad skala kan göras bra av specifika personer, men det finns helt enkelt inte tillräckligt många "Mel" för att täcka behovet.

Militär eller civil hårdvara, självklart är tillförlitligheten a och o. Därför bör man inte lämna det åt mänskliga faktorn - som bekant står för ganska många katastrofer. Däremot bör inte heller systemen som du säger vara för komplexa heller - för då finns återigen fler felkällor. Men det handlar nog mer om prestanda egentligen. Mer beräkningar -> sämre prestanda. Något man i vissa lägen måste väga mot annat. Ett bra system måste nog framför allt vara *testbart*. Det måste gå att verifiera kodens (och maskinvarans) beteende, vare sig det är man eller maskin som åstadkommit den.

En inte helt grundlös gissning är att vi finner Ada, Fortran och kanske en del C i många flygplan. Och bilar med för den delen. När det gäller hårdvaran så är väl de som har tekniska kunnandet att svara på det belagda med munkavle. Men jag tror Gripen i större utsträckning än sina föregångare använder "standardkomponenter" för att hålla nere kostnaden. Tror dock inte vi hittar överdrivet många i7:or med nVidia kort i den ändå.

Det finns flera exempel (vissa verifierat sanna, andra mer mytbetonade) på detta. Ett exempel är Arianeraketen som kraschade på grund av dålig testning av programvara. Kortkort: man gjorde felaktiga antaganden istället för att testa och verifiera. Ett annat exempel är Eriksson, som använde "lågnivå"-språket C++ för ett jätteprojekt (typ AXE-växeln eller nåt liknande). Det projektet höll på att haverera för att det gick inte att ro ihop ett projekt av den magnituden med ett språk som C++ med så många personer. Det blev för rörigt. Man fick uppfinna ett nytt språk som löste uppgiften och var så pass enkelt att man kunde ha så många personer inblandade. Ett språk som var lätt att förstå och programmera men tillräckligt snabbt och bra för att lösa uppgiften helt enkelt. Detta är dock något av en myt, men det finns med all sannolikhet en hel del sanning bakom med. Språket blev Erlang, som idag används för "mjuka realtidssystem". Och det vet jag, för jag har jobbat med det.

Vet inte om hastighet på dagens datorer är en faktor, men förutom att försöka svara på din fråga:

I teorin borde det bli snabbare med hand knackade även idag. I praktiken tror jack det blir svårt är en förutsättning någon riktigt begåvad typ med. Det är helt enkelt så komplicerad hårdvara i jämförelse med dåtidens, samtidigt som det har skett massor i forskningen kring kompilatorer (de program som översätter programmerarens önskemål till maskinkod).

Däremot finns det programmeringsspråk och miljöer som tillåter Meltyper att leva ut men då på en annan nivå.