Det finns ju olika nivåer av språk. Nu har jag ingen koll på Swift, är det nåt liknande Scratch? Sånt är ju kanske inget man skriver en ordbehandlare eller ett CAD-program i, men det är ju en bra ersättare för enklare scriptspråk. Sänker inlärningströskeln en del.
Idag kan ju 7-åringar göra egna spel i Scratch, jag tror inte det hade gått lika bra om de behövt skriva spelen i perl...
Hur många språk behöver vi?
Re: Hur många språk behöver vi?
Det finns ju gott om exempel i detta forum över vad vi kan kalla "dålig kodningsstil". En del av dessa beror på att det saknas erfarenhet/kunnande och att personen är i en inlärningsprocess, något jag anser är helt OK.
Ett fåtal andra lider kraftigt av Dunning-Kruger effekten och där är hjälp och råd ju som att kasta vatten på en gås (alt. Spildte Guds ord på Balle-Lars).
Men det jag mest ser i båda programmering och generell konstruktion är planlöshet. Ett projekt är ju som sådan definierat av att man vill uppnå en specifik funktionalitet på vilket sätt man än kan göra det - men riktigt många planerar inget alls!
Jag minns mitt första kommersiella projekt: styrning av 3 laboratorieugnar i en klinkersfabrik.
Vi fick en 7 sidors beskrivning av vad systemet skulle göra i beställningen. Vi läste på den i 3 dagar och diskuterade utan att fatta ett skvatt. För att hugga den gordiska knuten föreslog jag chefen att anordna ett inspektionsmöte vid den enhet som skulle styras för att hjälpa oss "få ett totalt överblick och kanske snappa upp detaljer som ville hjälpa senare".
Det blev fixat snabbt och medan chefen pratade med chefer hann jag slinka till dom som faktisk jobbade där och fråga hur det fungerade och vad de behövde. Jag fick mycket tydlig, konkret och mycket användbar information som kunde formuleras på få rader och som gav mening. Jag noterade detta vid återkomst till kontoret och vi jämförde med de 7 sidor och det var inte många rätt där kan vi säga.
Nåväl, vi byggde det vi skulle, programmerade och min paranoia fick mig att räkna på allt som kunde gå fel och sedan säkra mot det. Vid uppstart var det 1(!) bugg som rent faktisk var för att det var kopplat fel temperatursensor till fel ingång men det var enklare att lösa i mjukvaran.
Vi hann inte med att skriva manual innan driftstart så chefen skulle åka dit dagen efter monteringen och förklara, vi höll på att skriva som en galen på manualen just då. Då han kom dit 10:00 körde alla 3 ugnar i full drift och då han kollade om det var problem fick han veta att det var ju så enkelt att använda ett det hade tagit dom 5 minuter att starta den första ugnen, det tog 3 minuter av de 5 att mata in siffrorna som beskrev bränningskurvan.
Vi skrev aldrig manualen, behövdes inte. Projektet körde oändrad i 5 år varefter de ville ha en ändring: fler platser i biblioteket till kurvor. Det klarade chefen vid att leta upp källkoden, ändra "10" till "25" (antal kurvor i minnet) och kompilera. I kommentaren stod det att det maximalt var plats för 401 kurvor...
Och vad är då allt detta pladder? Jo, planering!
Man ska definiera ett projekt! Visst, många hobbyprojekt växer fram eftersom man skaffar grejer, lär sig mer eller liknande vilket betyder att det hela kan bli mycket virrigt i slutändan - och det är egentligen OK under utvecklingsstadiet och "proof of concept"-fasen.
Men för sin egen sinnesfrids skull ska man rensa/strukturera program ordentligt och skriva kommentarer medan man minns vad och varför ("MISO: PORTA1, MOSI: PORTA0 pga. xxx hårdvaruproblem/hade lödd så, kan bytas.").
En del verkar tro att man ska skriva kommentar för varje rad men en kort beskrivning av vad en funktion är till för är alldeles utmärkt.
I projektet jag beskrev ovan började jag med att tänka ut hur uppgiften kunde lösas.
Sedan skrev jag källkod i form av en massa delfunktioner som jag kunde räkna ut behövdes (<läsa knappsats>, <1-sek interrupt>, <räkna ny temperatur baserat på gammal temperatur, lutning och tid> osv.). För varje delfunktion skrev jag namnet på den och lite kommentarer om vad den skulle göra - och sedan gick jag vidare till näste, ingen programmering just då.
På det vis kunde jag hålla en översikt utan att tappa bort mig i detaljer, något mitt handikapp annars gör mig benägen att göra.
Att en enhet fungerar betyder inte att man har en chans att minnas vad/hur om 6 månader och det MÅSTE man veta för även hobbyprojekt kan vara värdefulla - och gå sönder. Och då kan man behöva göra ny eller liknande.
Samma sak är det med programmeringsspråk: vad behöver man egentligen?
* Är det ett språk till en begränsat hårdvara eller är det mycket kraft av alla former i systemet?
* Administrativt eller blinka LED?
* Tunga uträkningar?
* Speciella optimeringar?
Att utnämna C till att vara <SPRÅKET> är fel, det finns andra språk som ger andra fördelar där de behövs.
Har inte läst igenom MISRA men ja, C är ett kraftfullt språk där man kan skjuta sig i foten på ett subtilt sätt så det kräver en del egenkontroll av att variabler rent faktisk kan klara de värden man vill peta i dom eller som uträkningar kan ge osv.
Lika starkt det är, lika effektivt kan man såga av grenen man sitter på. Men det betyder inte att andra språk är "bättre", de kan dock vara skyddad bättre mot de normala fel man gör.
Så i projektplaneringen ska ingå krav på en utvärdering av om språket klarar jobbet utan trix.
Ett fåtal andra lider kraftigt av Dunning-Kruger effekten och där är hjälp och råd ju som att kasta vatten på en gås (alt. Spildte Guds ord på Balle-Lars).
Men det jag mest ser i båda programmering och generell konstruktion är planlöshet. Ett projekt är ju som sådan definierat av att man vill uppnå en specifik funktionalitet på vilket sätt man än kan göra det - men riktigt många planerar inget alls!
Jag minns mitt första kommersiella projekt: styrning av 3 laboratorieugnar i en klinkersfabrik.
Vi fick en 7 sidors beskrivning av vad systemet skulle göra i beställningen. Vi läste på den i 3 dagar och diskuterade utan att fatta ett skvatt. För att hugga den gordiska knuten föreslog jag chefen att anordna ett inspektionsmöte vid den enhet som skulle styras för att hjälpa oss "få ett totalt överblick och kanske snappa upp detaljer som ville hjälpa senare".
Det blev fixat snabbt och medan chefen pratade med chefer hann jag slinka till dom som faktisk jobbade där och fråga hur det fungerade och vad de behövde. Jag fick mycket tydlig, konkret och mycket användbar information som kunde formuleras på få rader och som gav mening. Jag noterade detta vid återkomst till kontoret och vi jämförde med de 7 sidor och det var inte många rätt där kan vi säga.
Nåväl, vi byggde det vi skulle, programmerade och min paranoia fick mig att räkna på allt som kunde gå fel och sedan säkra mot det. Vid uppstart var det 1(!) bugg som rent faktisk var för att det var kopplat fel temperatursensor till fel ingång men det var enklare att lösa i mjukvaran.
Vi hann inte med att skriva manual innan driftstart så chefen skulle åka dit dagen efter monteringen och förklara, vi höll på att skriva som en galen på manualen just då. Då han kom dit 10:00 körde alla 3 ugnar i full drift och då han kollade om det var problem fick han veta att det var ju så enkelt att använda ett det hade tagit dom 5 minuter att starta den första ugnen, det tog 3 minuter av de 5 att mata in siffrorna som beskrev bränningskurvan.
Vi skrev aldrig manualen, behövdes inte. Projektet körde oändrad i 5 år varefter de ville ha en ändring: fler platser i biblioteket till kurvor. Det klarade chefen vid att leta upp källkoden, ändra "10" till "25" (antal kurvor i minnet) och kompilera. I kommentaren stod det att det maximalt var plats för 401 kurvor...
Och vad är då allt detta pladder? Jo, planering!
Man ska definiera ett projekt! Visst, många hobbyprojekt växer fram eftersom man skaffar grejer, lär sig mer eller liknande vilket betyder att det hela kan bli mycket virrigt i slutändan - och det är egentligen OK under utvecklingsstadiet och "proof of concept"-fasen.
Men för sin egen sinnesfrids skull ska man rensa/strukturera program ordentligt och skriva kommentarer medan man minns vad och varför ("MISO: PORTA1, MOSI: PORTA0 pga. xxx hårdvaruproblem/hade lödd så, kan bytas.").
En del verkar tro att man ska skriva kommentar för varje rad men en kort beskrivning av vad en funktion är till för är alldeles utmärkt.
I projektet jag beskrev ovan började jag med att tänka ut hur uppgiften kunde lösas.
Sedan skrev jag källkod i form av en massa delfunktioner som jag kunde räkna ut behövdes (<läsa knappsats>, <1-sek interrupt>, <räkna ny temperatur baserat på gammal temperatur, lutning och tid> osv.). För varje delfunktion skrev jag namnet på den och lite kommentarer om vad den skulle göra - och sedan gick jag vidare till näste, ingen programmering just då.
På det vis kunde jag hålla en översikt utan att tappa bort mig i detaljer, något mitt handikapp annars gör mig benägen att göra.
Att en enhet fungerar betyder inte att man har en chans att minnas vad/hur om 6 månader och det MÅSTE man veta för även hobbyprojekt kan vara värdefulla - och gå sönder. Och då kan man behöva göra ny eller liknande.
Samma sak är det med programmeringsspråk: vad behöver man egentligen?
* Är det ett språk till en begränsat hårdvara eller är det mycket kraft av alla former i systemet?
* Administrativt eller blinka LED?
* Tunga uträkningar?
* Speciella optimeringar?
Att utnämna C till att vara <SPRÅKET> är fel, det finns andra språk som ger andra fördelar där de behövs.
Har inte läst igenom MISRA men ja, C är ett kraftfullt språk där man kan skjuta sig i foten på ett subtilt sätt så det kräver en del egenkontroll av att variabler rent faktisk kan klara de värden man vill peta i dom eller som uträkningar kan ge osv.
Lika starkt det är, lika effektivt kan man såga av grenen man sitter på. Men det betyder inte att andra språk är "bättre", de kan dock vara skyddad bättre mot de normala fel man gör.
Så i projektplaneringen ska ingå krav på en utvärdering av om språket klarar jobbet utan trix.
Re: Hur många språk behöver vi?
Menade mer att fruktföretaget har en vana att hitta på något (flåt, knycka något) och måla ut det som lösningen på alla problem, och sen följer hela fårskocken med och predikar världens frälsning, i detta fallet för objective C, sen ett par år senare så kommer sektled^h^h..företaget med något annat (i detta fallet swift) som ska ersätta det tidigare ofelbara och rätta alla problem (som nyss inte fanns), och fårskocken jublar i takt.. ..tills nästa innovation (nåja) kommer och blir det rätta<tm>hummel skrev:Objective-C utvecklades på ITT Corp i början av 80-talet. Hur som, Swift verkar vettigt och även Google verkar gilla det. Passar säkert inte alla människor eller plattformar liksom andra språk.Glenn skrev:
Skulle inte objective C slå allt på marknaden, lösa alla problem, bota skallighet och vara framtiden<tm> för ett par år sedan ? ..sen kom swift.. vad kommer om två år som ersätter det ?
Jag tror det blir med swift som med objective C, de enda som använder det är en bunt människor som bara kodar för apple, sen ersätts det av något annat igen..
Det gör att man är minst sagt skeptisk till allt som släpps från just det företaget.
Och google, tja, det ät väl mest äppeltidningar som verkar fantisera om att google ska skifta till en swift-runtime, finns det någonting som ens tyder på det förutom att äppeltidningar och användare hoppas det ? ..Eller syftar du på något helt annat än de rykten om swift på android som finns ?
Angående språket i sej självt.. har jag ingen aning
Re: Hur många språk behöver vi?
Det som Icecap pratar om är ju en lite annan diskussion, men jag håller med om det mesta där.
Jag brukar säga att det är skillnad på att "programmera" och "koda".
Att programmera är att beskriva hur ett program ska fungera, att koda är att implementera detta i något programspråk.
Jag har många gånger börjat med att beskriva hur programmet ska fungera i kommentarer, och sen mellan kommentarerna skrivit in koden som utför detta. Att skriva koden först och kommentera den sen brukar sällan ge lika bra resultat.
Sen är det klart att man även man "programmera" på bra och dåliga sätt, programmera på "fri hand" eller enligt en plan.
Jag brukar säga att det är skillnad på att "programmera" och "koda".
Att programmera är att beskriva hur ett program ska fungera, att koda är att implementera detta i något programspråk.
Jag har många gånger börjat med att beskriva hur programmet ska fungera i kommentarer, och sen mellan kommentarerna skrivit in koden som utför detta. Att skriva koden först och kommentera den sen brukar sällan ge lika bra resultat.
Sen är det klart att man även man "programmera" på bra och dåliga sätt, programmera på "fri hand" eller enligt en plan.
-
Lennart Aspenryd
- Tidigare Lasp
- Inlägg: 12607
- Blev medlem: 1 juli 2011, 19:09:09
- Ort: Helsingborg
Re: Hur många språk behöver vi?
Tack Icecap för ditt belysande inlägg. Det är dit jag egentligen vill komma md min TS .
Om man kan klargöra Målet, vet vart man står! Då bör det gå att klara ut resurser för att bugga vägen.Skall vara bygga. Freudianskt.
Om man kan klargöra Målet, vet vart man står! Då bör det gå att klara ut resurser för att bugga vägen.Skall vara bygga. Freudianskt.
Re: Hur många språk behöver vi?
Håller helt med Icecap. Jag brukar säga att i många fall är det lämpligt
att designa "top-down" och koda "bottom-up". D.v.s att designen normalt
behöver utgå från det övergripnade medan kodningen ofta behöver (så som
Icecap beskrev det) utgå från botten för att verifiera de kritiska delarna.
Jag skriver ofta några "proof-of-concept" för de kritiska delarna så att jag
vet att det fungerar innan helheten sätts samman.
Många börjar ett projekt med att koda "överdelen", och det är väl OK om
man är övertygad om att alla "grundstenarna" finns på plats, så att säga,
men annars är riskerna stora att en "road-bump" stjälper hela projektet...
att designa "top-down" och koda "bottom-up". D.v.s att designen normalt
behöver utgå från det övergripnade medan kodningen ofta behöver (så som
Icecap beskrev det) utgå från botten för att verifiera de kritiska delarna.
Jag skriver ofta några "proof-of-concept" för de kritiska delarna så att jag
vet att det fungerar innan helheten sätts samman.
Många börjar ett projekt med att koda "överdelen", och det är väl OK om
man är övertygad om att alla "grundstenarna" finns på plats, så att säga,
men annars är riskerna stora att en "road-bump" stjälper hela projektet...
Re: Hur många språk behöver vi?
> Ett fåtal andra lider kraftigt av Dunning-Kruger effekten...
Speciellt tycker jag att "andra sidan" är viktig:
"Samtidigt tenderar personer med hög kompetens underskatta sin relativt
höga kompetens gentemot andra, vilket leder till antagandet att det som
är lätt för den kompetente också är lätt för andra."
*Det* är mycket vanligt här... Det förekommer "lösningar" på vardagsproblem
som är fullständigt orimliga för den otekniske eller ej datorintresserade, men som
av den som kom med förslaget upplevs som helt självklara.
Hög teknisk kompetens betyder självklart inte att man förstår helheten.
Speciellt tycker jag att "andra sidan" är viktig:
"Samtidigt tenderar personer med hög kompetens underskatta sin relativt
höga kompetens gentemot andra, vilket leder till antagandet att det som
är lätt för den kompetente också är lätt för andra."
*Det* är mycket vanligt här...
Det förekommer "lösningar" på vardagsproblemsom är fullständigt orimliga för den otekniske eller ej datorintresserade, men som
av den som kom med förslaget upplevs som helt självklara.
Hög teknisk kompetens betyder självklart inte att man förstår helheten.
Re: Hur många språk behöver vi?
Alan Kay: "Probably the most disastrous thing you can ever learn is your first programming language..."
Intressant och tankeväckande presentation som bl.a. visar att det kan vara motiverat att skapa helt nya språk för komplicerade uppgifter:
http://www.tele-task.de/archive/lecture/overview/5819/
alternativt även på youtube:
Intressant och tankeväckande presentation som bl.a. visar att det kan vara motiverat att skapa helt nya språk för komplicerade uppgifter:
http://www.tele-task.de/archive/lecture/overview/5819/
alternativt även på youtube:
-
lillahuset
- Gått bort
- Inlägg: 13969
- Blev medlem: 3 juli 2008, 08:13:14
- Ort: Norrköping
Re: Hur många språk behöver vi?
OK, jag dristar mig att säga ett till... Minst. Även om jag är totalt ointresserad.
Re: Hur många språk behöver vi?
Sodjan: "Speciellt tycker jag att 'andra sidan' är viktig".
Jeps - och vi faller alla i den sida rimligt ofta. Men jag anser mig ha märkt att de projekt som blir presenterat på ett tydligt sätt mindre ofta spårar ut i rådgivningen.
Ibland får jag en aning om att vissa roar sig med att göra saker och ting så besvärliga som möjligt för en person med begränsade kunnande inom området, bara för skoj skull.
Men vi ser ju alla livet och dess lösningar med de "skygglappar" vi har så vad jag anser som mycket enkelt kan för andra vara mycket komplicerat medan det motsatta kan gälla för andra områden.
Själv anser jag att är något värd att göra är det värd att göra ordentligt - vilket såklart betyder att jag kan fördröja ett projekt i evighet medan jag filer och putsar i tid och evighet på detalj efter detalj. Just detta i min karaktär har lett till att jag har skapat ett omfattande mjukvarabibliotek som jag kan hämta ifrån, då släpper jag att finputsa evighet med de färdiga rutiner, jag har redan gjort det, alltså kan ett projekt startas upp rimligt enkelt och komma i mål inom överkomlig tid.
Ett exempel är detta är rogerk8's skivspelarbygge. H*n är total säker på att all styrning ska vara analog per definition och det kan jag respektera, jag kan ha mina idéer också. Men samtidig vet jag att vissa delar fungerar mycket bättre med en digital styrning - men det förkastas. Och då slår det mig direkt: varför lägga energi på projektet? Ska det byggas halvdant med tveksam kvalitet är det väl lika bra att köpa en skivhyvel till 250:- och vara nöjd med den!
Men det är mitt sätt att se det på och jag kan stå för det, det betyder dock inte att alla andra ser likadan på saken, något jag ofta får påminna mig själv om.
Och detta gäller också programmerinsspråk: att jag gillar C väldigt mycket betyder inte att det är bra till allt, C är i själva verket lika uselt till allt - eller superbt till allt, allt efter vilken programmeringsstil man har. Detta gäller nog alla programmeringsspråk: styrkan sitter i hur man använder språket och till vilken uppgift.
Jeps - och vi faller alla i den sida rimligt ofta. Men jag anser mig ha märkt att de projekt som blir presenterat på ett tydligt sätt mindre ofta spårar ut i rådgivningen.
Ibland får jag en aning om att vissa roar sig med att göra saker och ting så besvärliga som möjligt för en person med begränsade kunnande inom området, bara för skoj skull.
Men vi ser ju alla livet och dess lösningar med de "skygglappar" vi har så vad jag anser som mycket enkelt kan för andra vara mycket komplicerat medan det motsatta kan gälla för andra områden.
Själv anser jag att är något värd att göra är det värd att göra ordentligt - vilket såklart betyder att jag kan fördröja ett projekt i evighet medan jag filer och putsar i tid och evighet på detalj efter detalj. Just detta i min karaktär har lett till att jag har skapat ett omfattande mjukvarabibliotek som jag kan hämta ifrån, då släpper jag att finputsa evighet med de färdiga rutiner, jag har redan gjort det, alltså kan ett projekt startas upp rimligt enkelt och komma i mål inom överkomlig tid.
Ett exempel är detta är rogerk8's skivspelarbygge. H*n är total säker på att all styrning ska vara analog per definition och det kan jag respektera, jag kan ha mina idéer också. Men samtidig vet jag att vissa delar fungerar mycket bättre med en digital styrning - men det förkastas. Och då slår det mig direkt: varför lägga energi på projektet? Ska det byggas halvdant med tveksam kvalitet är det väl lika bra att köpa en skivhyvel till 250:- och vara nöjd med den!
Men det är mitt sätt att se det på och jag kan stå för det, det betyder dock inte att alla andra ser likadan på saken, något jag ofta får påminna mig själv om.
Och detta gäller också programmerinsspråk: att jag gillar C väldigt mycket betyder inte att det är bra till allt, C är i själva verket lika uselt till allt - eller superbt till allt, allt efter vilken programmeringsstil man har. Detta gäller nog alla programmeringsspråk: styrkan sitter i hur man använder språket och till vilken uppgift.
Re: Hur många språk behöver vi?
Det där du skriver om kan ju liknas lite vid fenomenet "the lazy sysadmin".
The lazy sysadmin är en admin som är så lat att så fort det är nåt som kan lösas av ett script, ett cron-jobb eller liknande så skriver man ett sånt.
En sån sysadmin pysslar med "roligare saker" 90% av tiden, men samtidigt är det arbete som de lägger ner ovärderligt just eftersom de automatiserar så mycket.
http://www.independent.co.uk/life-style ... 47771.html
The lazy sysadmin är en admin som är så lat att så fort det är nåt som kan lösas av ett script, ett cron-jobb eller liknande så skriver man ett sånt.
En sån sysadmin pysslar med "roligare saker" 90% av tiden, men samtidigt är det arbete som de lägger ner ovärderligt just eftersom de automatiserar så mycket.
http://www.independent.co.uk/life-style ... 47771.html
