Hvilket programmerings-språk bør man begynne med?

[scav-]

Jeg progger Elm på jobb og liker det, men selv med det vil jeg påstå det er en rar plass å begynne. Rare argumenter du kommer med også.

Du er selvsagt velkommen til å utdype hva du reagerer på og hvorfor.

[LangtGjesp]

Du er selvsagt velkommen til å utdype hva du reagerer på og hvorfor.

 

Vel, jeg skjønner litt av hva Matsemann mener. Jeg tror du selv burde utdype noe av det du sier:

 

alle «objekt orienterte» språk som er main stream i dag ikke aner hva OO faktisk innebærer

 

Hvis OO faktisk innebærer noe annet enn det man finner i objekt-orienterte språk, tror jeg det er flere her som klør seg i hodet.

 

Ellers hadde det vært morsomt å se litt diskusjon omkring funksjonell programmering.

[scav-]

Hvis OO faktisk innebærer noe annet enn det man finner i objekt-orienterte språk, tror jeg det er flere her som klør seg i hodet.

De fleste språk som er «OO» og mainstream i dag, gjør mye mer en å holde state og utveksle meldinger. Jeg er usikker på hvor mye jeg behøver utdype her — litteraturen er allerede temmelig klar på dette. For å sette det veldig på spissen: Akka er ironisk nok det nærmeste OOP vi har vært på flere tiår. Java, C# o.l. er språk som blander sammen en haug med forvirrende konsepter som introdusere unødvendig mye kompleksitet i det at et hver problem kan løses med et sammensurium av paradigmer.

[Emancipate]

Hvis OO faktisk innebærer noe annet enn det man finner i objekt-orienterte språk, tror jeg det er flere her som klør seg i hodet.

Uten at jeg skal si noe om hva som er best, så impliserer OO "actor model", mens dagens "objektorienterte" språk, som Java og C++, faktisk bruker en vanlig imperativ paradigme, med "klasser" som en måte å hindre "name clashes" på. Disse "klassene" er egentlig "struct", mens OO impliserer at klasser er "actors".

 

"Actors" er asynkrone (kjører i hver sin virtuelle tråd), og "actor model" forbyr "aliasing". "Struct" er synkrone (kjører i samme tråd).

 

"Aliasing" er at mer enn en peker/reference (eller en klasse) peker til den samme datastrukturen. F.eks. kan ikke to actors ha en referanse til samme hash-table.

 

OO/actor model bruker uttrykket "message passing", dette er asynkrone "meldinger" som med parametre som alltid sendes "by value".

 

I Java/C++ sendes parametre ofte "by reference". Dette bryter regelen om "no aliasing". Videre beskiver "sending a message to an instance" bare et prosedyrekall med det første parameteret plassert før navnet på funksjonen. Eksempel:

 

my_struct_type self1;

my_class_type self2;

MemberFunction(self1, parameters ...) // Struct

self2.MemberFunction(parameters ...) // Class

 

Kompilatoren genererer den samme maskinkoden. Dette er kun en forskjell i syntax, ikke en annen modell.

 

Erlang bruker "actor model". (Disclaimer: Jeg har aldri brukt Erlang.)

[Emancipate]

Jeg prøvde meg på et sammendrag. Noen vil sikkert vurdere enkelte ting annerledes, men jeg gjorde så godt jeg kunne.

            Procedural  Coroutines  Threads     Actors  Struct  Java-class  Functional
Parallel    -           -           +           +****   -       -           +
Concurrent  -           +           +           +       -       -           -/+ ***
Name hiding +/-*        +           -           +       -       +           +/-*
Aliasing    +           +           +           -       +       +           +
Mutation    +           -**         +           +       +       +           -

* Yes, if the language implements "modules".
** The coroutine construct facilitates not doing mutation
on local variables, but does not have to forbid it.
*** Using thunks or closures, or using parallelism.
**** Made natural by the actor model, but not required.

If a language forbids aliasing or mutation (or both), data races can not occur, 
making concurrent programming safer. Includes to "actor model" and "functional
programming".

[Ernie]

Uten at jeg skal si noe om hva som er best, så impliserer OO "actor model", mens dagens "objektorienterte" språk, som Java og C++, faktisk bruker en vanlig imperativ paradigme, med "klasser" som en måte å hindre "name clashes" på. Disse "klassene" er egentlig "struct", mens OO impliserer at klasser er "actors".

 

"Actors" er asynkrone (kjører i hver sin virtuelle tråd), og "actor model" forbyr "aliasing". "Struct" er synkrone (kjører i samme tråd).

 

"Aliasing" er at mer enn en peker/reference (eller en klasse) peker til den samme datastrukturen. F.eks. kan ikke to actors ha en referanse til samme hash-table.

 

OO/actor model bruker uttrykket "message passing", dette er asynkrone "meldinger" som med parametre som alltid sendes "by value".

 

I Java/C++ sendes parametre ofte "by reference". Dette bryter regelen om "no aliasing". Videre beskiver "sending a message to an instance" bare et prosedyrekall med det første parameteret plassert før navnet på funksjonen. Eksempel:

 

my_struct_type self1;

my_class_type self2;

MemberFunction(self1, parameters ...) // Struct

self2.MemberFunction(parameters ...) // Class

 

Kompilatoren genererer den samme maskinkoden. Dette er kun en forskjell i syntax, ikke en annen modell.

 

Erlang bruker "actor model". (Disclaimer: Jeg har aldri brukt Erlang.)

Dette er en særdeles spenstig kommentar. Har du noen kilder som støtter opp under at «actor model» er den reneste form av objektorientert programmering? Jeg synes iallfall det er ganske merkelig siden «actor model» er beskrevet først i 1973, mens objektorientering stammer tilbake til 50-60-tallet. Simula har tradisjonelt vært anerkjent som det første primært objektorienterte språket, og ble standardisert i 1967. Jeg tviler veldig på at det du beskriver holder vann. I stedet vil jeg heller si at «actor model» har fint lite med objektorientering å gjøre, men er mer en egen måte å programmere på. Å påstå Java og C++ ikke er objektorientert på grunn av «actor model» anser jeg iallfall for å være fullstendig på bærtur.

[Emancipate]

Husk det berømte sitatet: "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind."

 

Jeg skal ikke utelukke at jeg tar feil. Spesielt er det kanskje ikke nødvendig at "messages" er asynkrone. Men les dette:

 

https://ovid.github.io/articles/alan-kay-and-oo-programming.html

 

http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

[Ernie]

Husk det berømte sitatet: "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind."

 

Jeg skal ikke utelukke at jeg tar feil. Spesielt er det kanskje ikke nødvendig at "messages" er asynkrone. Men les dette:

 

https://ovid.github.io/articles/alan-kay-and-oo-programming.html

 

http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

Jeg har ikke tid til å les igjennom det, men først og fremst er "agent model" første gang beskrevet her. Jeg har bare skumlest meg igjennom det, og det fremstår for meg som mer en modell for parallellkjøring enn noe annet. Jeg registrerer også at dette i følge wikipedia kan implementeres i blant annet C (https://en.wikipedia.org/wiki/Actor_model#Actor_libraries_and_frameworks). Det tilsier med all tydelighet at objektorientering og "actor model" på ingen måter er bundet opp i hverandre.

Ift. den siste linken din, så ser jeg at Alan Kay nevner Smalltalk og LISP som OOP språk. Meg bekjent har ingen av de innebygget støtte for "Actor model". Det må vel bety at det er en distinkt forskjell her?

Endret 2. august 2019 av Ernie

[Emancipate]

Det er nok en forskjell. Jeg kan ikke så mye om Actor model, men det virker mye mer presist og formalisert enn det vage begrepet OO.

 

Fra wiki: It was also influenced by the programming languages Lisp, Simula, and early versions of Smalltalk.

Alt kan implementeres i C.

[Bing123]

Lær deg Elm, så slipper du å kaste bort flere år på å innse at alle «objekt orienterte» språk som er main stream i dag ikke aner hva OO faktisk innebærer og at også disse språkene blir bedre om du tar en mer funksjonell tilnærming til det hele.

Mene du virkelig at _nybegynnere_ skal starte med et språk som "transpilerer" til javascript, istedenfor feks javascript?

Det var et grusomt råd.

[danielhoifodt]

Hei,

 

ville lært meg javascript og php til å begynne med. Dette er da hvis du ønsker å bli dyktig innen web-utvikling. Og selvfølgelig html, css og det der.

[quantum]

Kan ikke svare noe mer, er lenge siden jeg brukte det. Vet ikke hva du mener med preview men du kan kompilere og kjøre kode i eclipse.

 

Ellers er det noen andre som bør svare deg.

Jeg skjønner heller ikke spørsmålet helt, men svaret er definitivt IntelliJ fremfor Eclipse for IDE. Bygg med Maven eller Gradle, alt annet er galskap når man er forbi hello-world-nivået.

[quantum]

Hei,

 

ville lært meg javascript og php til å begynne med. Dette er da hvis du ønsker å bli dyktig innen web-utvikling. Og selvfølgelig html, css og det der.

PHP har den ene fordelen at det tilbys rimelig hosting. PHP har alltid ligget i bakevja i forhold til alternativene. Det ligger mye tutorials på nett som viser hvordan man gjør ting på "gal" måte (ex. gammel databaseconnection-kode)

 

I dag bygger man front i React el. (spa) og backend basert på rest, da er man mye bedre tjent med Java/jvm eller .net på serveren. PHP er vel fortsatt interpretert, så til små prosjekter eller prototyper kan sikkert den dynamikken gi en fordel, dog.

[Anzure]

Hei dere

Hva burde kan lære først av React, Vue, og Angular?

Hva er mest populært i Norge?

[Taggi]

waremanu skrev (På 13.12.2019 den 14.07):

Hei dere

Hva burde kan lære først av React, Vue, og Angular?

Hva er mest populært i Norge?

React er det mest brukte.

[danielhoifodt]

Det er et interessant spørsmål. Men det kommer mer an på hva du skal kode. På internett idag finner du materiale for å lære deg nesten alt innen programmering. Da er valget stort, og lett å forville seg. Har du ikke noe formening om hva du skal kode er det likegyldig hva du begynner å lære. 

[quantum]

danielhoifodt skrev (På 19.12.2019 den 16.49):

Har du ikke noe formening om hva du skal kode er det likegyldig hva du begynner å lære. 

På ett vis riktig, så lenge man ikke skal kode noe kan det umulig bli galt. I så tilfelle ville jeg heller anbefalt å spare seg det hele.

I praksis, hvis man har intensjon om å kode "noe" men ikke vet hva, ville jeg gått for noe av det som er vanlig og utbredt, java, Javascript, C#, etc. 

[danielhoifodt]

quantum skrev (På 2.1.2020 den 21.40):

På ett vis riktig, så lenge man ikke skal kode noe kan det umulig bli galt. I så tilfelle ville jeg heller anbefalt å spare seg det hele.

I praksis, hvis man har intensjon om å kode "noe" men ikke vet hva, ville jeg gått for noe av det som er vanlig og utbredt, java, Javascript, C#, etc. 

ja, start med noe som er kjent, og lett å finne dokumentasjon på.

[aanundo]

Er det noen som har erfaring med Forth?

Brukte dette språket i en PC som het Jupiter Ace på 80-tallet. Når PC-en fikk strøm var det bare å sette i gang å skrive for å styre lys eller andre ting. Jeg laget en kasse hvor jeg kunne styre 230 V, og den hadde 4 utganger og 16 innganger.

: lampe1pa 1 9 out ; Tente lampen nr. 1, : lampe1av 2 9 out ; så sluknet den. : lampe2pa 8 9 out ; tente lampe 2, og : lampe2av 4 9 out ; slukket den.

Ved å legge det samme inn i et program jeg døpte "Blink" fikk jeg lampene til å blinke, men da måtte jeg først lage en forsinkelse.

: forsinkelse 1 10000 do loop ; betyr 0,5 s opphold.

: blink lampe1pa forsinkelse lampe1av forsinkelse lampe2pa forsinkelse lampe2av forsinkelse ;

Skrev jeg da blink, blinket disse 2 lampene 1 gang. 

For å få dette til å fortsette 100 ganger  kunne jeg bruke loop og lage et ord som het 100blink.

: 100blink 1 100 do blink loop ;

 

[Feynman]

20 minutes ago, aanundo said:

Er det noen som har erfaring med Forth?

Forth?! Nymotens greier. Da jeg var ung simulerte vi atombomber med hullkort!