Gå til innhold

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


Anbefalte innlegg

Videoannonse
Annonse

Nå der påstår at nesten alle programmer som utvikles , utvikles ute GUI brukergrensesnitt

så må jeg spørre

1 hvor kan man da bruke programmet når de flest os bruker GUI ?

2 hvorfor finnes det da et flertall av programmer med GUI brukergrensesnitt ?

 

spill har jo også et GUI

Hadde du jobba med programvareutviling de siste 20 åra så ville du forstått at nesten alle betalte jobber er innefor web-utvikling. Desktop programmer er døde. I dag er GUI html/css/javascript.

Lenke til kommentar

Tøv .Det er mange programmer som kjøres på pcer uten å være avhengig av en nettleser for å fungere

 

mange vil faktisk påstå at seriegrensesnittet er en belastning

 

går man et hakk videre og sammenligner store programmer med desktop og web så er det office programmet man kjøre på desktop mer anvendelig en det som finnes på nettet

 

Microsoft tilbyr en stor pakke for desktopp , en mindre pakke for desktop beregnet studenter og hjemme brukere og en gratis utgave på nettet

Nett utgaven har en del begroninger som de profesjonelle ikke vil ekseptere

 

så har man jo selvsagt alle gratisprogrammene men laster ned og bruker

her er det faktisk få man kjører fra nettet

 

Om du påstår at mesteparten av programmer går gjennom nettet så har du forhandsberegnet begivenheten

Lenke til kommentar

diverse om GUI kontra kommandlinja

 

Det kan virke som om du ikke er så komfortabel med kommandolinja, Elgen?! Da vil jeg anbefale deg i å gjøre et forsøk på å bli det. Det gir normalt følgende fordeler:

  1. At man får en bedre forståelse for hvordan verktøyene en bruker egentlig fungerer
  2. At man blir mere produktiv! Det oppnår man fordi man finner en rekke små verktøy som gjør ting mere effektivt enn man kan klare det i et GUI, og fordi man lærer seg å scripte kommandolinjeverktøyene (kombinere verktøy og logikk) for å automatisere tidkrevende oppgaver.

Den tredje effekten vil så kunne bli en litt mere interessant diskusjon her på forumet ;)

  • Liker 1
Lenke til kommentar

jeg tar det for det dere skriver.

 

det er det at man nesten finner bare programmer med GUI og så påståes det at det nesten ikke utvikles programmer med GUI jeg ikke får til å gå i hop.

 

Og det er fordi du ikke forstår, eller ikke vil forstå, det som skrives. Det er såpass uryddige påstander du kommer med at jeg syns du skal tenke deg litt om før du fortsetter.

Lenke til kommentar

 

jeg tar det for det dere skriver.

 

det er det at man nesten finner bare programmer med GUI og så påståes det at det nesten ikke utvikles programmer med GUI jeg ikke får til å gå i hop.

 

Og det er fordi du ikke forstår, eller ikke vil forstå, det som skrives. Det er såpass uryddige påstander du kommer med at jeg syns du skal tenke deg litt om før du fortsetter.

 

Støttes, får en følelse av at man ikke har skrevet så veldig mange programmer når man begynner å si at GUI er veldig viktig og noe man må bruke mye tid på, som regel så er GUI noe som jeg tegner før jeg lager programmet. (gitt at det er ett program som skal ha GUI) For så å skrive de forskjellige delene som ligger bak (som kanskje skal brukes direkte av GUI'et). Tester disse for deretter å sy de sammen med selve GUI'et. Jeg har gjerne flere testscenarioer som ikke involverer GUI for å sjekke at alt fungerer slik som det er tiltenkt før jeg overhodet begynner å tenke på å bruke GUI'et.

 

Jeg foreslår at du enten starter med å programmere, eller leser deg mer opp på programmering før du fortsetter. For å ta ett eksempel: NginX (jeg tviler på at du har hørt om dette programmet) brukes for å vise websider, ligger på top 3 av de mest brukte programmene som viser websider rundt omkring. Ved interesse, så er top 3: Apache, NginX og IIS. Poenget med dette er at dette er program som kjører uten GUI. Ikke nødvendigvis programmer som sluttbrukere ser, eller tenker på. (Eller for den sags skyld har behov for å tenke på) men likefullt nyttige programmer. Det skrives og brukes utrolig mange programmer som ikke bruker GUI, som aldri har behov for GUI. At programmer for sluttbrukere trenger GUI er jeg helt med på, men jeg personlig bruker ikke å legge inn GUI på webservere etc. Det er en grunn til at microsoft (endelig) har laget en server med minimalt med GUI. Man vil ha minst mulig eksponert ut mot internett på en server, så hvis man kan kjøre servere uten gui, så gjør man det. Program som kjører på serversiden er gjerne uten GUI. Så neste gang du tenker på at det skrives mange programmer uten GUI, så tenk på at det er langtifra alle programmer som er skrevet for direkte bruk av en "sluttbruker" det finnes mange programmer som kun kjøres på serversiden, der man vil ha høyest mulig bruk av automasjon, noe som ikke nødvendigvis er forenelig med ett GUI.

  • Liker 1
Lenke til kommentar

Støtter det Lock-Ace sier - veldig mange programmer er IKKE beregnet for bestemor sekretærsluttbruker direkte (det betyr ikke at h*n ikke merker om det slutter å vire), og har veldig ofte ikke noe GUI. Mye av grunnen til dette er at ikke-GUI programmer er langt enklere for en (litt avansert) bruker å automatisere - det er mye lettere å skrive et skript som hekter sammen et par kommandoer, enn det er å skrive noe som automatisk klikker på knapper i et GUI. For å automatisere bruken av et GUI-program, så er man egentlig avhengig av at det eksisterer et TUI (Text User Interface) eller API i tillegg til GUI'et (museklikkescript er langt inni hack-land imho).

Så ja, en del programmer har GUI, og den største anndelen av de programmene en *sluttbruker ser* har GUI - men jeg vil tro den største anndelen programmer som blir skrevet ikke har det. Jeg ser også at kun et lite mindretall av de programmene jeg skriver har en egen GUI - dog har jeg en del som kaller på biblioteker som tegner en standard-GUI (plotting med matplotlib).

Jeg vil også påstå at det å lære seg GUI-programmering er langt uti prioriteringsrekka når man lærer programmering - start med syntax, enkle algoritmer, og vanlige datastrukturer.

GUI kan dog være en fin måte å lære event-driven programmering på (noe som også er applikabelt når man gjør parallelisering med MPI), og da er "skjemategnings"-programmene (VB 6.0 hadde en slik en, sikkert flere - lenge siden jeg har holdt på med slikt...) fine / enkle å komme i gang med - det er ofte mye skriving å kode opp en GUI fra scratch med GTK/SWING/TK/etc.

  • Liker 1
Lenke til kommentar

 

Det finnes massevis av tilfeller der en webapplikasjon ikke er en ønskelig løsning på problemet.

Men er det web scale?

 

Det er vel sannsynligvis flere websider som utvikles i dag enn desktop-programmer. Men jeg vet ikke om jeg ville turt å påstå at "nesten alle betalte jobber er innefor web-utvikling". Vi er mange som utvikler programmer som overhodet ikke er ment på sluttbruker.

Lenke til kommentar

web programmer har jo også et GUI , men det er jo innebygget i web systemet .

da er det jo ikke rart at man slipper unna dette når man programmerer

 

scrpting eller kommandolinje parameter er jo så 80 talle det går an å komme.

rart at så mange driver med det enda

 

hvis man er så avhengig av kommandolinje parameter så har man et dårlig tilnærmet bruker grensesnitt.

 

alle programmer jeg har vær borti eller hørt om ( også Apps) har innebygd GUI .

da er det noen få prosenter igjen som kan være avhengig av kommandolinje parameter

 

jeg kjenner meng rett og slett ikke igjen der dere trehoder a 90% eller noe der omkring av alle programmer er uten GUI.

 

kommandolinje parameter er forøvrig ikke noen ( ekte ) brukergrensesnitt

Lenke til kommentar

web programmer har jo også et GUI , men det er jo innebygget i web systemet .

da er det jo ikke rart at man slipper unna dette når man programmerer

 

scrpting eller kommandolinje parameter er jo så 80 talle det går an å komme.

rart at så mange driver med det enda

Igjen, det kommer ann på hva man vil gjøre. Når jeg skriver et program for å regne ut ett-eller-annet, så består grensesnittet til programmet stort sett av en eller flere inputfiler + et par komandolinje-argumenter for velge inputfil og kanskje et par andre ting. Ekstra nyttig når programmet stort sett kjører på en Linux-server ett-eller-annet sted, ofte i screen eller bak et kø-system alá Torque.

 

Denne typen programmer er det utrolig mange av - hver av oss som skriver dem skriver typisk 1-3 "store" i året + maaaange flere <1000 linjer for å analysere noe data etc.

 

Enkelte av dem har GUI - i mitt eget tilfelle så kan du søke opp AcdOpti på GitHub - men dette er gjerne styringsprogrammer, dvs. "enkle" programmer som kontrollerer de faktiske regneprogrammene.

 

hvis man er så avhengig av kommandolinje parameter så har man et dårlig tilnærmet bruker grensesnitt.

Det kommer ann på hva målet er. I mange tilfeller er et GUI i beste fall unødvendig jobb, og ofte kun i veien. Et annet eksempel er at kommandolinjeprogrammer er lette å kjede sammen i scripts.

 

alle programmer jeg har vær borti eller hørt om ( også Apps) har innebygd GUI .

da er det noen få prosenter igjen som kan være avhengig av kommandolinje parameter

 

Noen få prosenter av *brukere* har ikke behov for kommandolinjen - gi dem en nettleser og en diger link til facebook, finn.no, og nettbanken så er de fornøyd. Men de fleste *programmer* er ikke skrevet for bestemor (eller for deg).

 

jeg kjenner meng rett og slett ikke igjen der dere trehoder a 90% eller noe der omkring av alle programmer er uten GUI.

 

kommandolinje parameter er forøvrig ikke noen ( ekte ) brukergrensesnitt

Hva er det da?

Lenke til kommentar

Uansett, GUI blir på mange måter en spesialisering, på linje med MPI (Message Passing Interface, brukes for å kommunisere mellom prosesser i paralellprogrammering). Å insistere på at en nybegynner MÅ begynne med GUI blir like dumt som å insistere på at h*n MÅ begynne med MPI/OpenMP eller matriseknusing/MonteCarlo (de fleste programmer jeg bruker gjør jo slikt på ett eller annet nivå, ergo finnes ikke webprogrammering og kontorstøtteverktøy...). Eller for å ta Lycantrope - å insistere på å starte med funksjonell programmering blir litt som å insistere på å starte med assembly - ja, det er mulig, og ja det gir en god forståelse, men det er likevel ikke stedet jeg ville startet en nybegynner.

 

Forøvrig, kjære Elg: Det finnes interaktive tekstgrensesnitt som er langt kraftigere og mer brukervennlige enn DOS. Bare å ha readline hjelper sinnsykt. Dersom du lærer deg f.eks. BASH, så tror jeg du vil innse at det er et utrolig kraftig verktøy som ikke har en direkte analog/erstattning blant musepekerstyrte programmer. Ettersom du tydeligvis ikke vet dette - det er lov å innrømme at man ikke kan/vet - og i allefall unngå å uttale seg så innmari bastand om ting man ikke kan noe om (og dermed til det kjedsommelige demonstrere akkurat dette)!

 

Jeg har i allefall få problemer med å innrømme at jeg kan heller lite om f.eks. webprogrammering ut over HTML4 og www_docs, men jeg kjører ikke på med bastante påstander alá "GOPHER er best, ingen protest!" heller...

Lenke til kommentar

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

Lenke til kommentar
...

scrpting eller kommandolinje parameter er jo så 80 talle det går an å komme.

rart at så mange driver med det enda

 

hvis man er så avhengig av kommandolinje parameter så har man et dårlig tilnærmet bruker grensesnitt.

...

jeg kjenner meng rett og slett ikke igjen der dere trehoder a 90% eller noe der omkring av alle programmer er uten GUI.

 

kommandolinje parameter er forøvrig ikke noen ( ekte ) brukergrensesnitt

 

For å gi et litt annet perspektiv på "diskusjonen":

 

Har du tenkt gjennom det faktum at det ultimate, kraftigste brukergrensesnittet du har mot datamaskinen din er .... trommevirvel .... programmeringsspråket ditt!

 

Et GUI er - fordi det er så lite fleksibelt / så ressurskrevende å lage - det mest spesialisterte og derfor enten "lite kraftig" eller enormt dyrt. Nyttig for "casual users". Et programmeringsspråk er det minst spesialiserte brukergrensesnittet, og derfor enormt kraftig - du kan gjøre alt - men det krever også mye kunnskap. Kommandolinja befinner seg et sted i mellom disse to ytterpunktene.

  • Liker 1
Lenke til kommentar

Eller for å ta Lycantrope - å insistere på å starte med funksjonell programmering blir litt som å insistere på å starte med assembly - ja, det er mulig, og ja det gir en god forståelse, men det er likevel ikke stedet jeg ville startet en nybegynner.

Det er nesten provoserende at du setter likhetstegn mellom funksjonell programmering og assembly.

 

Det er ikke noe umiddelbart vanskeligere med funksjonell programmering. Jeg har ganske god tro på at det faktisk kan være lettere i en del tilfeller - spesielt når det kommer til å forstå avstanden mellom språket og faktisk kjøring på maskinen. De fleste funksjonelle språk har hvertfall en sunn distanse mellom lavnivå og høyvinå - det er noe jeg ikke kan gi til verken python, javascript, java, C# eller annen cancer.

  • Liker 1
Lenke til kommentar

 

Eller for å ta Lycantrope - å insistere på å starte med funksjonell programmering blir litt som å insistere på å starte med assembly - ja, det er mulig, og ja det gir en god forståelse, men det er likevel ikke stedet jeg ville startet en nybegynner.

Det er nesten provoserende at du setter likhetstegn mellom funksjonell programmering og assembly.

 

Det er ikke noe umiddelbart vanskeligere med funksjonell programmering. Jeg har ganske god tro på at det faktisk kan være lettere i en del tilfeller - spesielt når det kommer til å forstå avstanden mellom språket og faktisk kjøring på maskinen. De fleste funksjonelle språk har hvertfall en sunn distanse mellom lavnivå og høyvinå - det er noe jeg ikke kan gi til verken python, javascript, java, C# eller annen cancer.

 

Jeg satt ikke likhetstegn mellom ASM og funksjonelle språk. Poenget var at det å starte en nybegynner med et "sært" språk, en kategori hvor de fleste rene funksjonelle språk havner (i allefall LISP og Haskell), sannsynligvis ikke er ideelt, mye av samme grunn som det neppe er særlig ideelt å starte vedkommende med ASM, selv om dette også kan hevdes å ha pedagogiske fordeler.

 

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.

- 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.

- Det viktigste en nybegynner lærer, er å sette opp en algoritme, dvs. å forstå hvor utrolig dum datamaskinen er, 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.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...