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

[quantum]

Ja, du driver og gjentar det, men å forklare hva i all verden du mener med det vil du visst ikke.

Endret 5. april 2014 av quantum

[sinnaelgen]

Ja, du driver og gjentar det, men å forklare hva i all verden du mener med det vil du visst ikke.

det får jeg jo ikke lov for du har jo allerede bestem hva jeg mener

 

dessuten så har jeg forsøkt å forklare men du godtar det jo ikke

[quantum]

Jaha? Jeg vil altså både at du skal forklare hva du mener og samtidig at du ikke skal forklare hva du mener, mens du på din side ikke har noe annet valg enn å følge min vilje? Det må være frustrerende ...

 

Beklager, jeg har falt av lasset for lenge siden, elgen, jeg kan bare si at du selvfølgelig må ha dine egne meninger.

[sinnaelgen]

fint . da har vi avklart dette

 

 

hvorfor er { lettere å lese / skille ut fra mengden en Begin ?

hvorfor er } lettere å skille fra mengden enn End ?

[quantum]

fint . da har vi avklart dette

 

Klart som blekk ...

[GeirGrusom]

hvorfor er { lettere å lese / skille ut fra mengden en Begin ?

hvorfor er } lettere å skille fra mengden enn End ?

Fordi det er ett symbol istedet for 5 og 3. Jeg får ihvertfall heller ikke den indre stemmen som sier "Begin" når jeg ser { noe jeg gjør med "Begin" og "End" så det går litt fortere å lese.

[quantum]

Skillet mellom naturlige og formelle språk ligger vel ikke akkurat i hvilke symboler de tillater brukt...

[sinnaelgen]

 

hvorfor er { lettere å lese / skille ut fra mengden en Begin ?

hvorfor er } lettere å skille fra mengden enn End ?

Fordi det er ett symbol istedet for 5 og 3. Jeg får ihvertfall heller ikke den indre stemmen som sier "Begin" når jeg ser { noe jeg gjør med "Begin" og "End" så det går litt fortere å lese.

 

Men et symbol som brukes i flere sammenhenger har rett for å drukne i teksten / koden

 

symbolene { } brukes i pascal for marker kommenterer .

Da kan man også bruk dem til å "koble ut " koden

 

problemet er dog at av og til sliter man med å finne feil i koden fordi disse symbiosene er vanskelig å oppdage blant resten av koden

 

jeg kan ikke se at det er bedre i andre språk selv om symbolene skulle ha li andre betydninger for koden

[torbjørn marø]

 

 

hvorfor er { lettere å lese / skille ut fra mengden en Begin ?

hvorfor er } lettere å skille fra mengden enn End ?

Fordi det er ett symbol istedet for 5 og 3. Jeg får ihvertfall heller ikke den indre stemmen som sier "Begin" når jeg ser { noe jeg gjør med "Begin" og "End" så det går litt fortere å lese.

 

...

 

Er det lettest å finne begin og end her:

 

Bacon ipsum dolor sit amet meatball short ribs venison frankfurter. Meatball shank pork chop flank. Pastrami t-bone salami begin shoulder ham hock, tail chicken kevin prosciutto. Tri-tip chicken turducken ground round, prosciutto swine ham hock flank ribeye leberkas beef end pork loin drumstick turkey biltong. Kevin pork loin beef ribs leberkas, swine flank fatback porchetta filet mignon strip steak.

 

eller { og } her:

 

Bacon ipsum dolor sit amet meatball short ribs venison frankfurter. Meatball shank pork chop flank. Pastrami t-bone salami { shoulder ham hock, tail chicken kevin prosciutto. Tri-tip chicken turducken ground round, prosciutto swine ham hock flank ribeye leberkas beef pork loin } drumstick turkey biltong. Kevin pork loin beef ribs leberkas, swine flank fatback porchetta filet mignon strip steak.

 

Jeg antar du er enig i at { og } var lettest. Ikke mye lettere, men nok til at det gir en verdi. Med begin og end må hjernen din tolke ordene, mens hjernen mye raskere klare å finne en krøllklamme.

 

I praksis hjelper det det selvsagt at man strukturerer koden sin på en bestemt måte, sånn at topologien gir deg et hint om hvor blokker starter og stopper. Hvis jeg byttet ut en Begin med en Begjn et sted i Pascal-koden din så hadde det nok tatt litt tid før du oppdaget det, men strukturen hadde du sett like bra likevel.

[quantum]

function max beginparanthesis num1 comma num2 colon integer rightparanthesis colon integer semicolon
var
result colon integer semicolon
begin
if beginparanthesis num1 greaterthan num2 endparanthesis then
result colon equals num1
else
result colon equals num2 semicolon
max colon equals result semicolon
end semicolon

"Natural pascal" ser for meg ikke ut som veien å gå. De matematiske operatorene + - / * er glimrende eksempler på effektiv og forståelig symbolbruk.

 

Skal man holde på med programmering i et språk utover lærestadiet må symboler være internalisert, slik at man ikke må stoppe opp og tenke seg om før man vet hvilket symbol man skal bruke i enhver situasjon. Dette gjør koden både raskere å lese og skrive.

 

Det formelle språket (en term elgen kan ha nytte av å sette seg inn i) blir ikke mer eller mindre formelt om man avstår fra å bruke tokens bestående av kun enkeltsymboler eller for eksempel begrenser alfabetet til kun å bestå av bare bokstaver og tall.

[GeirGrusom]

symbolene { } brukes i pascal for marker kommenterer .

Da kan man også bruk dem til å "koble ut " koden

 

problemet er dog at av og til sliter man med å finne feil i koden fordi disse symbiosene er vanskelig å oppdage blant resten av koden

 

jeg kan ikke se at det er bedre i andre språk selv om symbolene skulle ha li andre betydninger for koden

I C-språk bruker en /* og */ for kommentarer.

 

Her er en C# fil fra prosjektet mitt Platform.Invoke.

[tomsi42]

Det som jeg synes er størst problem med bruk av { } er at de i mange skrifttyper er vanskelig å skille fra ( ). I C/C#/Java osv er det til å leve med, men så fort en begynner å rote i TCL, så blir koden tungvindt å lese.

[sinnaelgen]

 

symbolene { } brukes i pascal for marker kommenterer .

Da kan man også bruk dem til å "koble ut " koden

 

problemet er dog at av og til sliter man med å finne feil i koden fordi disse symbiosene er vanskelig å oppdage blant resten av koden

 

jeg kan ikke se at det er bedre i andre språk selv om symbolene skulle ha li andre betydninger for koden

I C-språk bruker en /* og */ for kommentarer.

 

Her er en C# fil fra prosjektet mitt Platform.Invoke.

 

pascal bruker det også man da med '//' i stedet for '/*'

 

Problemet her er det da bare gjelder for en linje

 

forresten hvorfor bruker du trippel '/' for å markere kommentarer i koden din ?

Endret 6. april 2014 av den andre elgen

[torbjørn marø]

forresten hvorfor bruker du trippel '/' for å markere kommentarer i koden din ?

 

 

/// er spesielle kommentarer som du kan bruke verktøy for å generere dokumentasjon fra. Visual Studio bruker dem også til å gi popup-tips til brukeren av klassene og metodene.

Endret 6. april 2014 av torbjørn marø

[torbjørn marø]

Det som jeg synes er størst problem med bruk av { } er at de i mange skrifttyper er vanskelig å skille fra ( ). I C/C#/Java osv er det til å leve med, men så fort en begynner å rote i TCL, så blir koden tungvindt å lese.

 

Hvorfor er det et større problem i TCL? Jeg har ikke gjort så mye TCL selv, men har forstått at { og } egentlig definerer strenger som går over flere linjer.

 

Et eksempel:

proc sreverse {str} {
  join [loop i 0 [string length $str] {
    string index $str end-$i
  }] ""
}

Koden over er et kall til prosedyren som heter "proc". Den tar tre argumenter, strengen "sreverse", strengen "str", og en lengre streng som starter på første linje og slutter på siste. Når man senere kaller prosedyren man har fått laget (sreverse) så tolkes den siste strengen (som også inneholder flere strenger).

 

Jeg synes dette er ganske så kult - få en skikkelig Lisp-følelse av det.

 

PS: Luke 12 i julekalenderen min i fjor handlet om TCL.

Endret 6. april 2014 av torbjørn marø

[tomsi42]

Hvorfor er det et større problem i TCL?

Sett opp en litt avansert if struktur, så ser du at det kan bli rotete, særlig når du samtidig bruker [] for å hente et resultat fra en funksjon ...

 

Jeg synes dette er ganske så kult - få en skikkelig Lisp-følelse av det.

Det kommer sikkert ikke som en bombe, men jeg liker ikke lisp heller

 

Jeg har lang bakgrunn fra språk som Pascal, C, C++ og Java. De språkene er bygd opp slik at de passer min måte å løse problemer på; jeg finner at tankengangen bak språk som lisp har en helt annen vinkling som ikke passer meg. Eller de problemene jeg jobber med ...

 

Det er jo de som sverger til HP sine RPN kalkulatorer også

[Lycantrophe]

Kan det være at du tenker sånn fordi du er opplært i C og Pascal? Kan det være at du hadde tenkt annerledes om det første språket ditt var, say, Common Lisp?

[tomsi42]

Kan det være at du tenker sånn fordi du er opplært i C og Pascal? Kan det være at du hadde tenkt annerledes om det første språket ditt var, say, Common Lisp?

Det er alltids mulig, men jeg tror ikke det. Jeg kjenner folk som begynte med lisp tidlig, og de liker det fortsatt ikke. Og trives med C++, Java og lignende.

[GeirGrusom]

Jeg vil våge meg å påstå at ihvertfall funksjonelle språk egner seg bedre for nybegynnere enn imperative til tross for imperative språk sin utbredelse.

 

Selv om en ikke bruker et funksjonelt språk så er bortimot alt en lærer av et funksjonel språk nyttig i imperative språk.

 

Haskell synes jeg er et godt utgangspunkt, fordi det er sterkt, statisk typet uten at en trenger å bruke så mye tid på å eksplisitt oppgi typer i de fleste tilfeller. At det er veldig strent med tanke på muteringer fører også til at en må tenke på en måte som viser seg at faktisk også er viktig i imperative språk: ikke muter data uhemmet.

[Lycantrophe]

Men monads er så vanskelig.

 

:------------(