[Løst] Hvor burde jeg lære programmering og hvilket språk?

[kyrsjo]

dagens standard er jo GUI eller Internett applikasjoner

 

å først fulle inn flere felt , og trykke på knappen får å lager er mye mer anvendelig enn å må skrive alt på nytt med få endringer

f.eksem så er DOS sin kommandolinje hele tiden i overskriv modus som gjør dert lite anvendelig til registre data

 

så når dere hel tiden hevder at det kommandolinje som gjelder og er det beste så blir det fullstendig galt

 

Det flere dere kaller for program kaller jeg for (sub)rutiner

Det er fult mulig at det for noe kan fungere som program

jeg vill likevel ikke valgt å kalle det for noe program i den store sammenhengen , selv om det finnes nesten uendelig mange typer programmer

Når man skriver et litt større GUI-program, så starter man gjerne med å skrive noen subrutiner som kjører logikken man ønsker å implementere - og så legger man en enkel main()-funksjon oppå. Denne main()-fuksjonen har typisk ikke noe GUI. Så bygger man GUI'et opp som en alternativ main() som driver denne logikken.

 

I de fleste tilfeller jeg har vært borti, så ligger jobben i å pønske ut og implementere logikken - ikke å legge ut noen knapper for å drive den. Og i mange tilfeller så er grensesnittet temmelig begrenset - programmet trenger bare noen få input-variable, som så blir grundig kværnet. I slike tilfeller så holder det lenge med en input-fil, dvs. en ren tekstfil du setter opp i din favoritt-editor.

 

Databaseprogrammer funker mye på samme måte - bare at her er "backend" (selve databasen) ferdilaget, og logikken er i en del tilfeller så enkel at det ikke er så farlig å inkorporere den i GUI-koden. Det kan kanskje likevel være en god idé å lage et lag av subrutiner som er uavhengig av klikke-peke-grensesnittet, og som utfører logikken, sjekker at dataene som kommer inn gir mening etc. - og så eksponerer dette til et program (det være seg GUI eller ikke) som lager grensesnittet.

 

Ang DOS: Ja, DOS suger. Mange andre tekstgrensesnitt, f.eks. BASH, gjør det ikke. Det i seg selv er grunn nok for meg til å ikke bruke Windows...

 

Forøvrig takk til torbjørn marø for et bra innlegg #197

[Lycantrophe]

Grunnen er:

- En nybegynner er også nybegynner på å lese dokumentasjon og å hente informasjon. Å starte vedkommende med et språk hvor det finnes hauger av tutorials og man ofte har fysisk tilgang på personer kjenner språket og kan hjelpe deg å peke ut at DEN feilmeldingen, den du kanskje overså, den forteller deg hva som er galt, er ofte en stor fordel.

Nå er det ikke slik at det er lite dokumentasjon på nevnte språk. Hallo, folk har foreslått ting som Scratch og andre "lær-deg-å-programmere"-språk - der er det hvertfall mindre å ta av.

 

At det er lettere når du har en fysisk lærer eller mentor sier seg selv, men da har man valgt språket til noe han kan lære bort, ikke et språk som nødvendigvis er bedre for å lære seg å programmere. Som var topic.

 

- For at en nybegynner skal holde på motivasjonen, så er det for de fleste viktig å kjenne mestring tidlig. Dette er som regel lettere med et språk hvor man kan skrive et par linjer meget enkel kode i en enkel syntax, og øyblikkelig få et resultat.

Du får gjerne påpeke hvordan funksjonelle språk gjør det dårlig her.

 

- Det viktigste en nybegynner lærer, er å sette opp en algoritme, dvs. å forstå hvor utrolig dum datamaskinen er,

Allikevel diskvalifiserer du asm :---D

 

hvordan den gjør AKKURAT som du sier - og så hvordan man kan utnytte dette til sin egen fordel. Ikke fancy constructs som gjør ting enklere og mer elegant.

Jeg har ikke noe tro på at man må bygge seg (nesten bokstavelig) fra bunnen opp for å lære seg å programmere. Python har forøvrig alle feil du impliserer funksjonelle språk har og mer til, så da bør nesten python også ut av listen. Hva sitter vi igjen med da? Endret 25. mars 2014 av Lycantrophe

[Ko_deZ]

Dette har sklidd ut mer enn nødvendig. Foreslår å flytte diskusjonen til en litt annen tråd, da de siste 8 sidene har vært mer eller mindre irrelevant for trådstarter.

[quantum]

Det flere dere kaller for program kaller jeg for (sub)rutiner

 

Riktig.

 

Systemer og programmer utgjør en helthet satt sammen av ulike deler, som vi kaller subrutiner, komponenter, biblioteker, delsystemer og whatnot. Hver for seg gir det ikke nødvendigvis noen mening i å utstyre disse delene med eget gui, selv om helheten de inngår i har et gui.

 

En database kan være et eksempel. Den har ofte bare et CLI, men det fins gjerne alternative GUI-verktøy til dabasen også, og den brukes som en del av andre systemer, disse også med eller uten gui.

[sinnaelgen]

Nå er det nå slik at at grafisk bruker miljø har en stor fordel framfor tekstbaserte brukermiljø Spesialet når det er grafikk og bilder med.

 

turbo pascal brukte tekstbaser genisnitt.

i og for seg så er det et greit bruker grensesnitt selv om det ikke er like fleksibelt som det grafiske

og i en periode kunne man velge mellom begge 2

 

Nå er det grafiske som gjelder for alle mugger selv om noe er standhaftige o tyr til det dos lignede bruker grensesnittet eller det som ligner på turbo pascal sit tekst baserte grensesnitt

 

 

en nybegynner vil fortrekk det som er enkelt å forholde seg til , og gjerne et der man slipper å huske på en masse parametre

her vil det grafiske være favoritt for de fleste selv når det er enkel programmer som skal lages

det morsomme med det er at man ikke lager en kode selv for få få bruker grensesnittet frem

[kyrsjo]

Nå er det ikke "GUI i DOS", slik som Turbo-Pascal tydeligvis hadde, og også gamle EDIT, QBASIC, Norton Commander etc. vi siktet til når vi mente "tekstbasert grensesnitt". Det der er et GUI (eller rettere sagt et TUI ifl. Wikipedia), og virker ved å prosessere events, og er i dag ikke særlig mye enklere å lage enn GUI'er (nCurses er vel det vanligste "toolkit'et" for slikt i dag). TUIer kan dog være greie å ha når man fjerninnlogger til en maskin over SSH.

 

Det vi sikter til, er kommandolinjegrensesnitt. DOS er et slikt et (dog et horribelt dårlig et), BASH er et annet. MATLAB, interaktiv python, CINT (C INTerpreter = interaktiv C++) kan også i større og mindre grad kalles kommandolinjebaserte grensesnitt. Disse har alle til felles at de prosesserer kommandoer sekvensiellt - brukeren komponerer en kommando i form av tekst, og trykker på en knapp (typisk "enter") som får maskinen til å tolke kommandoen, utføre en operasjon, og vente på neste kommando. På en måte on-the-fly programmering. Disse grensesnittene har den fordelen at de er latterlig fleksible, da API'et består av programmene som er installert på maskinen, og de har gjerne mange "triks" for å kjede flere kommandoer etter hverandre.

 

Slike kommandolinjegrensenitt har også fordelen at de er veldig lette å programmere for - og er derfor et greit sted å begynne for en nybegynner. Når man er komfortabel med dette - gjerne ikke-interaktive programmer, hvor "grensesnittet" består av å endre i koden - så kan man begynne å tenke på eventløkker, kanskje threads, og andre ting som kan gjøre GUI-programmering komplisert.

[sinnaelgen]

Men da er man jo tilbake til noe alla LOGO programmering

 

som slet ikke er anvendelig annet en for hel spesielle tilfeller

 

jeg har prøv LOGO for mange år siden og det var alt for begrenset

 

man sitter heler ikke kjører programmet del for del manuelt

 

hvem driver å programmerer inne nye funksjoner mens programmet kjører ?

 

det enste stede man gjør slik i dag er når man vedlikeholder pcer eller større datasystemer

 

det blir feil måtte å gjøre det på for oss aller fleste

[Emancipate]

 

- For at en nybegynner skal holde på motivasjonen, så er det for de fleste viktig å kjenne mestring tidlig. Dette er som regel lettere med et språk hvor man kan skrive et par linjer meget enkel kode i en enkel syntax, og øyblikkelig få et resultat.

Du får gjerne påpeke hvordan funksjonelle språk gjør det dårlig her.

 

Etter å ha lest over halve boka om Haskell og gjort oppgavene selvsagt, har jeg fortsatt ingen peiling overhodet, ikke i nærheten av nærheten engang, på hvordan jeg skal bruke det jeg har lært til å gjøre noe nyttig i den virkelige verden (utover, kanskje, å forstå andre språk bedre, men det holder ikke hvis man skal bruke Haskell som første språk). Det har ikke vært noe problem med andre språk. Det er selvsagt mulig jeg er dum, men da blir jeg jo en utmerket representant for nybegynnerne.

[Lycantrophe]

"Boka om haskell"?

[GeirGrusom]

"Boka om haskell"?

Learn You a Haskell for Great Good! kanskje?

[quantum]

Nå er det grafiske som gjelder for alle mugger selv om noe er standhaftige o tyr til det dos lignede bruker grensesnittet eller det som ligner på turbo pascal sit tekst baserte grensesnitt

 

Bruker man f.eks.

 

Android SDK

Java SDK

MySQL

PostgreSQL

Apache httpd

git

svn

maven

ivy

gradle

...

 

... så er man altså "standhaftig"? Dette er helt moderne og ekstremt utbredte verktøy, elgen, og de kommer alle sammen uten gui. Det må man velge å anskaffe i tillegg hvis man vil bruke, noe mange selvfølgelig også gjør.

[Lock-Aze]

Men da er man jo tilbake til noe alla LOGO programmering

 

som slet ikke er anvendelig annet en for hel spesielle tilfeller

 

jeg har prøv LOGO for mange år siden og det var alt for begrenset

 

man sitter heler ikke kjører programmet del for del manuelt

 

hvem driver å programmerer inne nye funksjoner mens programmet kjører ?

 

det enste stede man gjør slik i dag er når man vedlikeholder pcer eller større datasystemer

 

det blir feil måtte å gjøre det på for oss aller fleste

 

Uhm, jo... Programmering i dag på større prosjekter fungerer akkurat slik. Man lager og kjører del for del av programmet manuelt, skriver tester og tester alle delene separat for deretter å implementere det i ett større prosjekt.

 

Noe som gjør at man skriver test cases for hver del av programmet. Når man skal lage mindre program, for seg selv. Så fungerer tankegangen din helt greit. Men, i større prosjekter, ikke nødvendigvis så godt.

 

Les deg opp på f.eks Scrum: http://no.wikipedia.org/wiki/Scrum (Det finnes flere såkalte agile metodikker, men dette er en helt vanlig måte å drive fram prosjekter på) Der målet ditt i praksis er å dele ett større prosjekt ned i mindre biter for så å gjøre ferdig bit for bit av programmet, før man syr det sammen.

 

Man skriver gjerne "ferdig" ett program, for deretter å legge til funksjonalitet etter at det er implementert, det er jo ett av poengene med å utvide ett program. Man vil da helst slippe å skrive hele programmet på nytt for å legge til ekstra funksjonalitet, vil man ikke? De fleste som jobber med systemer av litt størrelse, krever fort at man har testet hver funksjon individuelt og at testene og resultatet av testene ligger ved dokumentasjonen. (Skal man legge med en video av dette??) Se her, klikket jeg på knappen, åja, du ville at vi skulle teste hvordan programmet fungerer med 5000 samtidige brukere, la oss finne 20 stykker++ som kan trykke på knappen samtidig... (Eller skrive ett script som kjører funksjonen som knappen så og så mange ganger.)

 

Du må tenke litt utenfor dos og tenke litt større enn det du gjør, ofte skal man gjøre tester på om deler av programmet takler en belastning på så og så mange samtidige brukere, dette gjør man veldig enkelt med ett script som kjører inn autogenerert innhold av en gitt størrelse for å se om programmet takler belastningen, men via ett GUI? Vel, det er sikkert mulig.... Men, når man når en viss størrelse på prosjektet, så ikke nødvendigivis enklere enn å skrive en testcase som bare kjører for deg for å se om du får forventet resultat uten GUI.

 

Ofte er det ikke du som bestemmer hvordan programmet skal se ut eller fungere, det blir bestemt av kunde og ett annet firma som tegner hvordan de forventer at GUI skal se ut, så er din jobb å få GUI'et til å se så likt ut som tegninene og fungere slik som spesifikasjonene krever. Spesifikasjonene kan gjerne være, dette programmet skal kunne brukes av 2000 samtidige brukere som gjør spørringer av denne typen (sett inn type her) GUI er fint og flott, men veldig ofte bare en veldig liten del av ett program. Jeg ser hva du vil fram til, en nybegynner ønsker gjerne bare å få noe fint som bare fungerer. Men i litt større sammenhenger, så må man nesten ha kontroll på hva som skjer bak det fine GUI'et når det tryner (for tryne kommer det til å gjøre, tro meg) enten fordi brukere gjør ting som du aldri hadde tenkt de skulle gjøre, eller på grunn av last, eller at andre programmer som ditt program er avhengig av tryner.

[Lycantrophe]

Learn You a Haskell for Great Good! kanskje?

Min umiddelbare antagelse. Det er forøvrig en bok som er ment på folk som kan (litt) programmering og er nysgjerrige på hvordan fp er forskjellig.

[kyrsjo]

Men da er man jo tilbake til noe alla LOGO programmering

 

som slet ikke er anvendelig annet en for hel spesielle tilfeller

 

jeg har prøv LOGO for mange år siden og det var alt for begrenset

 

man sitter heler ikke kjører programmet del for del manuelt

 

hvem driver å programmerer inne nye funksjoner mens programmet kjører ?

 

det enste stede man gjør slik i dag er når man vedlikeholder pcer eller større datasystemer

 

det blir feil måtte å gjøre det på for oss aller fleste

Jeg har aldri brukt LOGO - så vidt jeg vet så er vel dette et verktøy for å lære bort enkle programmeringskonsepter?

 

Men jo, det er vanlig å teste programmet del-for-del - man skriver noen "subrutiner" + testkode for disse, og dokumenterer at det funker (akkurat den siste biten er det jeg holder på med i dag... Kjedelig :/). Så skriver man testkode som viser at de ulike subrutinene funker sammen. Og til sist skriver man selve applikasjonen.

 

Når det gjelder interaktive språk, så skriver man typisk ikke hele store funksjoner interaktivt - man laster opp et par biblioteker (="subrutiner"), og kjører disse. Ofte bruker man språket som en avansert "kalkulator". Og man kan kjapt og enkelt prøve seg fram med hvordan et bibliotek funker. De fleste slike språk støtter noe ala readline, tilbakesøking, og tab-completion, så det er ganske behagelig å bruke.

 

Vedlikeholder PC'r... Vel. Sysadmins er ofte glade i en skikkelig terminal ala BASH ja - en som kan skriptes, lett kan dokumenteres (det er lettere å notere "skriv denne kommandoen, sjekk at output er sånn", enn det er å notere "trykk på knappen merket BLÆH nummer 3 fra nedre høyre hjørne, trykk undermeny undermeny undermeny BLÆH, sjekk at vinduet ser ut som i Figur 13.8"). Det gir mer tid til kaffepauser, mindre frustrasjon, og bedre effektivitet

 

Så: Ingen her påstår at GUI'er er ubrukelige. Men de er ikke den eneste brukbare grensesnitt-typen for alle typer programmer, i alle stadier av utviklingen.

 

For å ta et kjapt eksempel: Printerdriveren på maskinen din. Jobben til en printerdriver er basically å implementere et API som programmer / operativsystemets printer-API kjenner, slik at de kan sende kommandoer ala "skriv tekst 'LOREM IPSUM' font blah posisjon blah", "tegn strek blah blah fra (x,y) -- (x2,y2) -- (x3,y3) -- etc.", "ferdig" på et standardisert grensesnitt. Programmet forventer så at driveren gjør noe fornuftig med disse kommandoene - det være seg å genere en PDF-fil eller å generere kommandoer til printeren ala "flytt blekkpatron til posisjon z, aktiver dyse 3 med 7 ml/mm mens beveger hode hastighet 5 m/s, step 1 mm arkmater, etc.". Hvor mye av dette trenger et GUI? Ja, fabrikanten slenger kanskje på et "kontrollpanel" for å sette innstillinger til driveren - dette er basically et tynt lite skall for å skrive en config-fil som driveren leser, og å sende noen spesial-kommandoer ala "hvor mye blekk igjen?" og presentere svaret med litt grafikk - men dette er en bitteliten og enkel bit med kode i forhold til selve driveren.

[Emancipate]

Det spiller ingen rolle hvilken bok det var, fakta er at IO er krøkkete i Haskell sammenlignet med imperative språk.

[Lycantrophe]

main = putStrLn "IO is hard"

Seems about right. IO er annerledes i Haskell. Om du ikke er innstilt på at IO-all-over fra før er ikke dette noe problem.

 

Faktisk tenkte jeg det samme til jeg prøvde litt. Det er et klart skille mellom IO og øvrige beregninger, men man pooler gjerne IO i andre språk og. Haskell har bare ekstra features på toppen.

 

edit: og siden når er det å kontrollere IO alt en nybegynner gjør? Når det er snakk om "triviell" IO (les en linje, skriv ut med noko attåt) er ikke Haskell vanskeligere og "kompilserte" ting i IO-monaden eksponeres aldri. Dessuten, når man skrive små, korte programmer á den typen gjøres alt innenfor main IO uansett, og ser nærmest imperativt ut.

Endret 26. mars 2014 av Lycantrophe

[sinnaelgen]

 

Men da er man jo tilbake til noe alla LOGO programmering

 

som slet ikke er anvendelig annet en for hel spesielle tilfeller

 

jeg har prøv LOGO for mange år siden og det var alt for begrenset

 

man sitter heler ikke kjører programmet del for del manuelt

 

hvem driver å programmerer inne nye funksjoner mens programmet kjører ?

 

det enste stede man gjør slik i dag er når man vedlikeholder pcer eller større datasystemer

 

det blir feil måtte å gjøre det på for oss aller fleste

 

Uhm, jo... Programmering i dag på større prosjekter fungerer akkurat slik. Man lager og kjører del for del av programmet manuelt, skriver tester og tester alle delene separat for deretter å implementere det i ett større prosjekt.

 

Noe som gjør at man skriver test cases for hver del av programmet. Når man skal lage mindre program, for seg selv. Så fungerer tankegangen din helt greit. Men, i større prosjekter, ikke nødvendigvis så godt.

 

Les deg opp på f.eks Scrum: http://no.wikipedia.org/wiki/Scrum (Det finnes flere såkalte agile metodikker, men dette er en helt vanlig måte å drive fram prosjekter på) Der målet ditt i praksis er å dele ett større prosjekt ned i mindre biter for så å gjøre ferdig bit for bit av programmet, før man syr det sammen.

 

Man skriver gjerne "ferdig" ett program, for deretter å legge til funksjonalitet etter at det er implementert, det er jo ett av poengene med å utvide ett program. Man vil da helst slippe å skrive hele programmet på nytt for å legge til ekstra funksjonalitet, vil man ikke? De fleste som jobber med systemer av litt størrelse, krever fort at man har testet hver funksjon individuelt og at testene og resultatet av testene ligger ved dokumentasjonen. (Skal man legge med en video av dette??) Se her, klikket jeg på knappen, åja, du ville at vi skulle teste hvordan programmet fungerer med 5000 samtidige brukere, la oss finne 20 stykker++ som kan trykke på knappen samtidig... (Eller skrive ett script som kjører funksjonen som knappen så og så mange ganger.)

 

Du må tenke litt utenfor dos og tenke litt større enn det du gjør, ofte skal man gjøre tester på om deler av programmet takler en belastning på så og så mange samtidige brukere, dette gjør man veldig enkelt med ett script som kjører inn autogenerert innhold av en gitt størrelse for å se om programmet takler belastningen, men via ett GUI? Vel, det er sikkert mulig.... Men, når man når en viss størrelse på prosjektet, så ikke nødvendigivis enklere enn å skrive en testcase som bare kjører for deg for å se om du får forventet resultat uten GUI.

 

Ofte er det ikke du som bestemmer hvordan programmet skal se ut eller fungere, det blir bestemt av kunde og ett annet firma som tegner hvordan de forventer at GUI skal se ut, så er din jobb å få GUI'et til å se så likt ut som tegninene og fungere slik som spesifikasjonene krever. Spesifikasjonene kan gjerne være, dette programmet skal kunne brukes av 2000 samtidige brukere som gjør spørringer av denne typen (sett inn type her) GUI er fint og flott, men veldig ofte bare en veldig liten del av ett program. Jeg ser hva du vil fram til, en nybegynner ønsker gjerne bare å få noe fint som bare fungerer. Men i litt større sammenhenger, så må man nesten ha kontroll på hva som skjer bak det fine GUI'et når det tryner (for tryne kommer det til å gjøre, tro meg) enten fordi brukere gjør ting som du aldri hadde tenkt de skulle gjøre, eller på grunn av last, eller at andre programmer som ditt program er avhengig av tryner.

 

Nå er jeg for så vidt ening med dere .

 

Nå er det slik at hvert enkelt programgrines verktøy har hvert sitt opplegg som er enklest å bruke

f.eks når det gjelder delphi så er det grafisk bruker grensesnittet med knapper , felter og andre elementer som er eklest i dette tilfellet

 

skriverdriveren har jo sitt eget bruker grensesnitt , særlig når man skal gjøre endringer .

og igjen så er det grafiske det som er mest praktisk

 

lager man f,eks bare et lite program som bare skal gjøre en oppgave uten å det haverkn krever innputt eller tilbakemeldinger så er det samme hvilke brukergrensesnitt man bruker , for det vil aldri bli brukt

 

Når jeg lager programmer så lager jeg mindre programmer inne det for å teste ut ideer som jeg skal bruke i det samme hoved-programmet .

 

for å starte de mindre programmene bruker en virtuell knapp

Da kan også legge inne tilbakemeldinger under veis som forteller om programmet har passert sjekkpunktet.

Når programmet stopper opp mellom 2 sjekkpunkter så har man også begrenset område der feilen oppstår.

en feil behøver ikke å oppstå før programmet har kjørt den samme program-løkken flere ganger

 

Hvis man så legger inn break punkter før feilen oppstår så kan mann debugge programmet ( kjøre en komando av gangen ) samtidig som man har en liste med variabler med verdien til variablene

 

Da ser man i samtid hvor det går galt

 

Det synes jeg er mest praktisk i et vindu som kan scrolles trinnløst , altså av grafisk forekomst

[kyrsjo]

 

 

Men da er man jo tilbake til noe alla LOGO programmering

 

som slet ikke er anvendelig annet en for hel spesielle tilfeller

 

jeg har prøv LOGO for mange år siden og det var alt for begrenset

 

man sitter heler ikke kjører programmet del for del manuelt

 

hvem driver å programmerer inne nye funksjoner mens programmet kjører ?

 

det enste stede man gjør slik i dag er når man vedlikeholder pcer eller større datasystemer

 

det blir feil måtte å gjøre det på for oss aller fleste

 

Uhm, jo... Programmering i dag på større prosjekter fungerer akkurat slik. Man lager og kjører del for del av programmet manuelt, skriver tester og tester alle delene separat for deretter å implementere det i ett større prosjekt.

 

Noe som gjør at man skriver test cases for hver del av programmet. Når man skal lage mindre program, for seg selv. Så fungerer tankegangen din helt greit. Men, i større prosjekter, ikke nødvendigvis så godt.

 

Les deg opp på f.eks Scrum: http://no.wikipedia.org/wiki/Scrum (Det finnes flere såkalte agile metodikker, men dette er en helt vanlig måte å drive fram prosjekter på) Der målet ditt i praksis er å dele ett større prosjekt ned i mindre biter for så å gjøre ferdig bit for bit av programmet, før man syr det sammen.

 

Man skriver gjerne "ferdig" ett program, for deretter å legge til funksjonalitet etter at det er implementert, det er jo ett av poengene med å utvide ett program. Man vil da helst slippe å skrive hele programmet på nytt for å legge til ekstra funksjonalitet, vil man ikke? De fleste som jobber med systemer av litt størrelse, krever fort at man har testet hver funksjon individuelt og at testene og resultatet av testene ligger ved dokumentasjonen. (Skal man legge med en video av dette??) Se her, klikket jeg på knappen, åja, du ville at vi skulle teste hvordan programmet fungerer med 5000 samtidige brukere, la oss finne 20 stykker++ som kan trykke på knappen samtidig... (Eller skrive ett script som kjører funksjonen som knappen så og så mange ganger.)

 

Du må tenke litt utenfor dos og tenke litt større enn det du gjør, ofte skal man gjøre tester på om deler av programmet takler en belastning på så og så mange samtidige brukere, dette gjør man veldig enkelt med ett script som kjører inn autogenerert innhold av en gitt størrelse for å se om programmet takler belastningen, men via ett GUI? Vel, det er sikkert mulig.... Men, når man når en viss størrelse på prosjektet, så ikke nødvendigivis enklere enn å skrive en testcase som bare kjører for deg for å se om du får forventet resultat uten GUI.

 

Ofte er det ikke du som bestemmer hvordan programmet skal se ut eller fungere, det blir bestemt av kunde og ett annet firma som tegner hvordan de forventer at GUI skal se ut, så er din jobb å få GUI'et til å se så likt ut som tegninene og fungere slik som spesifikasjonene krever. Spesifikasjonene kan gjerne være, dette programmet skal kunne brukes av 2000 samtidige brukere som gjør spørringer av denne typen (sett inn type her) GUI er fint og flott, men veldig ofte bare en veldig liten del av ett program. Jeg ser hva du vil fram til, en nybegynner ønsker gjerne bare å få noe fint som bare fungerer. Men i litt større sammenhenger, så må man nesten ha kontroll på hva som skjer bak det fine GUI'et når det tryner (for tryne kommer det til å gjøre, tro meg) enten fordi brukere gjør ting som du aldri hadde tenkt de skulle gjøre, eller på grunn av last, eller at andre programmer som ditt program er avhengig av tryner.

 

Nå er jeg for så vidt ening med dere .

 

Nå er det slik at hvert enkelt programgrines verktøy har hvert sitt opplegg som er enklest å bruke

f.eks når det gjelder delphi så er det grafisk bruker grensesnittet med knapper , felter og andre elementer som er eklest i dette tilfellet

 

skriverdriveren har jo sitt eget bruker grensesnitt , særlig når man skal gjøre endringer .

og igjen så er det grafiske det som er mest praktisk

 

lager man f,eks bare et lite program som bare skal gjøre en oppgave uten å det haverkn krever innputt eller tilbakemeldinger så er det samme hvilke brukergrensesnitt man bruker , for det vil aldri bli brukt

 

Når jeg lager programmer så lager jeg mindre programmer inne det for å teste ut ideer som jeg skal bruke i det samme hoved-programmet .

 

for å starte de mindre programmene bruker en virtuell knapp

Da kan også legge inne tilbakemeldinger under veis som forteller om programmet har passert sjekkpunktet.

Når programmet stopper opp mellom 2 sjekkpunkter så har man også begrenset område der feilen oppstår.

en feil behøver ikke å oppstå før programmet har kjørt den samme program-løkken flere ganger

 

Hvis man så legger inn break punkter før feilen oppstår så kan mann debugge programmet ( kjøre en komando av gangen ) samtidig som man har en liste med variabler med verdien til variablene

 

Da ser man i samtid hvor det går galt

 

Det synes jeg er mest praktisk i et vindu som kan scrolles trinnløst , altså av grafisk forekomst

 

 

Hva mener du med en "virituell knapp"? Dette høres ut som en delphi-spesifikk greie.

 

Å legge inn tilbakemeldinger, ofte kalt print statements, er en vanlig måte å debugge / sjekke at en algoritme kjører riktig. I python uten gui gjøres dette med koden

 print melding

f.eks.

 

print "starting XYZ loop, variable =", variable

Altså ingen vits å skrive sin egen kode hver gang for å printe ut ting. Terminalen du starter et program i blir heller ikke borte om programmet krasjer, noe som ofte er tilfelle for GUI-vinduer...

 

Terminalen er nettopp et "vindu som kan scrolles trinnløst". I mitt tilfelle ser den typisk ca. slik ut (for en random terminal jeg hadde liggende på en av de 24 virituelle skjermoverflatene mine + fysisk dobbeltskjermsoppsett ):

legg merke til scrollbar, at den kan resizes til akkurat den størrelsen som passer meg (i motsetning til DOS, så vidt jeg husker), og fargekoding. I tillegg støttes tab-completion, dvs. at jeg skrive de første par bokstavene i en kommando / filnavn, trykke på TAB (knappen over caps lock), og så fylles resten automatisk ut (om det er flere muligheter, så fyller den ut så langt det går, og så skriver den ut hvilke muligheter som gjenstår, slik at du kan trykke på den ene ekstra bokstaven som mangler + ny TAB). Så glem DOS - det blir som å insistere på at en trehjulssykkel og et jetfly er det samme, fordi de begge er et transportmiddel med hjul...

[sinnaelgen]

greit nok , men ikke optimal for alle forhold .

Nå trodde jeg først at bare var en avansert variant av den dos simuleringen man kan få til i windows , som ikker flere muligheter en det man hadde i MS-DOS

 

For å forklare hva jeg mente så må jeg gi et eksempel

Da passer det å fortell om hva jeg holder på med for tiden

 

Noen ganger når man skal kunne sette opp hvordan menyvalgene i et program skal fungere så ønsker man å kunne gjøre det gjennom valgene man foretar , ente ved parametre eller virtuelle knapper på skjermen ( som er GUI) .

 

Da er det snakk om en kombinasjon av knapper før valget blir utført , ikke direkte e valg med bare en knapp.

Det gjøres slik for begrense antall kna pepr som må til

 

For å få oversikt over alle mulige kombinasjoner så ønsker man å sette opp og teste det i en tabell

bruker man et vanlig regneark og skriver inn alt manuelt så blir det både tungvint og det er også store muligheter for at det blir feil under veis

Spesielt hvis man har 70 parametre som skal kombineres

så jeg lar pcen generere tabellen ved hjelp av mange mindre subrutiner som jeg kjøre etter en bestem rekkefølge

alt dette gjøres under ett når jeg trykker på ,en knapp

 

slik jeg gjør det er at jeg først plaserer alle parameterne i hver sine kolonne.i en slags rutenett

det er derimot ikke noe regneark

I første linje ( ROV) lagger jeg først inn verdien 0 i alle feltene

Man har jo da på forhand bestem hvile av valgene som skal være tilgjengelig og hvilke som skal bli tilgjengelig avhengig av andre parameter valg

 

Parametervalgene er også gruppert , slik at man bare kan velge et valg i en gruppe

 

f.eks velger man parameteren "flytte" i en gruppe og valgen "kolonne" ,"linje" , "felt" og "område" blir tilgjengelig

velger man derimot "NY" så er det bare "Kolonne" og " linje" som blir tilgjengelig , mens "felt" og " område " blir utilgjengelig

 

Nå vil jo disse valgene igjen gjøre nye parametre tilgjengelig

man kan altså flytte en linje som jeg velger ut innhold fra i en bestem retning . f.eks til opp

Da har man parameterne "flytt" , "linje" , "utvalg" ,"Opp" .

Man kunne også ha valgt "flytte" , "linje" "alle" , "ned"

eller "flytte" ,"linje" , "Utvalg" ,"ned"

 

For å marker at disse valgene skal være tilgjengelig legger jeg inn "*"

en subrutinene omgjør dette til en referanse til en annen linje i rutenettet

en subrutine finner også ut hvor mange referanser det er i den linjen

( hvor mange celler som har referanse )

 

Så er det bare å kopiere linje like mange ganger som det er referanser

Det neste blir endre litt på referansene på de kopierte linjen

jeg bruker " 1" for marker at det er en referanse og talen etter er selve referansen.

 

"1/ 10" betyr at det er en referanse til linje 10

"2 / 0" betyr at man er i samme linje som de ellers skulle referer til

"1" betyr at knappen , eller valget er tilgjengelig

mens "2" betyr at man har valgt knappen eller valget

 

Nå må jeg gå gjennom alle kombinasjonene har for få en komplett tabbell

 

når den er ferdig så har man en tabell der man kan styre valgene og hvilke muligheter man får videre

 

et eksempel

først velger man å valget "flytte"

Det er er det referanse til linje 10 , i samme kolonne

i en annen kolonne på linje 10 er det referanse til valget "felt"

Den referer da til linje linje 20

i linje 20 er kolonne for "flytte" og "Felt" merker som valgt

i en annen kolonne på linje 20 er det en referanse til " valget " alle"

 

til slutt har man en linje der både "Flytte", "Felt" ," alle" og "opp" er markert som valgt

Da utføres den handlingen som kombinasjonen av flytte , Felt , alle og opp skal gjøre

 

selv om der høres komplisert ut så håper jeg at dere forstod

 

Her ser jeg denne metoden som den eneste praktiske måten å gjene det på for å få tilstrekkelig oversikt over tabellen mens jeg jobber med den

[kyrsjo]

Det var litt komplisert like før midnatt ja Jeg tror jeg burde sett programmet og hva slags data det egentlig jobber med + jeg er ikke helt sikker på om jeg forstår hva som er dataene dine, hva som er representasjonen på skjermen, og hva som er GUI-elementene ut i fra forklaringen din... Men som sagt, seint og snart leggetid, og jeg tror ikke jeg orker å lage et nytt designforslag akkurat nå

 

Poenget var uansett ikke at alle programmer er best som terminalprogrammer. Det er de ikke - GUI er ofte også et nyttig paradigme (selv vil jeg påstå at AcdOptiGui*, som jeg har skrevet for å styre noen digre beregninger jeg holder på med, er et relativt avansert GUI-program. Så jeg er ikke helt ukjent med GUI'er.). Men det er ikke det eneste nyttige, og for en nybegynner så tar knappetegning og kompliserte if-setninger** ofte unødvendig mye av fokus vekk fra det å forstå algoritmene og datastrukturene.

 

*) https://github.com/kyrsjo/AcdOpti

http://accelconf.web.cern.ch/accelconf/IPAC2013/papers/mopwo011.pdf

**) Det er fort å falle i "if-if-if-ifelse"-fella når man ikke er vant til å tenke algoritmisk, og GUI-programmering gjør det lettere å snuble i den fella.