mboost-dp1
Funktionelle Sprog - Hvorfor?
Jeg har i det sidste stykke tid kigget lidt på funktionelle sprog, som Nermele, F#, Haskell og Lisp.
Og hvor jeg godt kan se at de er smarte til at implementere matematiske former som f.eks. QuickSort, så kan jeg ikke se meningen med dem i den virkelige verden, da de er besværlige at arbejde med, og ikke særlig effiktive til at arbejde med OOAD projekter med.
Folk snakker om at det skal kunne bruges til at arbejde med flere cores, men jeg kan ikke se hvorfor at funktionelle sprog er bedre til det end f.eks. C#
RunOnTwoCores(delegate() { ... core A work ... }, delegate() { ... core B work ... });
Er der nogen som kan give indsigt i hvad meningen med funktionelle sprog er i den virkelige verden, og altså ikke bare matematik og formler på en professors tavle på et universitet.
Og hvor jeg godt kan se at de er smarte til at implementere matematiske former som f.eks. QuickSort, så kan jeg ikke se meningen med dem i den virkelige verden, da de er besværlige at arbejde med, og ikke særlig effiktive til at arbejde med OOAD projekter med.
Folk snakker om at det skal kunne bruges til at arbejde med flere cores, men jeg kan ikke se hvorfor at funktionelle sprog er bedre til det end f.eks. C#
RunOnTwoCores(delegate() { ... core A work ... }, delegate() { ... core B work ... });
Er der nogen som kan give indsigt i hvad meningen med funktionelle sprog er i den virkelige verden, og altså ikke bare matematik og formler på en professors tavle på et universitet.
Hmm, så vidt jeg husker fra mine dage på universitetet, så er funktionelle sprog gode til 2 ting. For det første, så ændrer de måden man tænker/programmerer på. Funktionelle sprog arbejder ved at man tænker på løsningen og hvordan denne laves (matematisk set). Aspekter som memory, variabler, OS, plads, klasser, performance, objekter, aktører, delegates, whatever, er overflødige. De har ikke noget at gøre med løsningen og er derfor irrelevante. Det er derfor også ret nemt, eg. at oversætte en matematisk formel direkte til SML.
Derudover så skulle funktionelle sprog også være ret nemme at "bevise". Eg. det skulle være nemt matematisk set, at kunne bevise at en given løsning er rigtig. (Så langt kom jeg nu aldrig.)
Btw. LISP er da ikke et funktionelt sprog? Det er blot funktions-orienteret (ligesom ANSI-C) og har forøvrigt verdens værste syntax.
Derudover så skulle funktionelle sprog også være ret nemme at "bevise". Eg. det skulle være nemt matematisk set, at kunne bevise at en given løsning er rigtig. (Så langt kom jeg nu aldrig.)
Btw. LISP er da ikke et funktionelt sprog? Det er blot funktions-orienteret (ligesom ANSI-C) og har forøvrigt verdens værste syntax.
Grunden til at funktionelle sprog er gode i forbindelse med flere cores, er sikkert at man med en funktionel funktion kan afvikle alle del-funktoner af denne, på samme tid. Og alle del-funktionerne kan ligeledes deles op på samme måde. Programmøren skal derfor ikke tænke på, hvad der skal afvikles seperat o.s.v. Smart, smart.
Men dette giver jo ikke mening i en typisk application hvor du netop har en række objekter der representere dit data.illishar (3) skrev:. For det første, så ændrer de måden man tænker/programmerer på. Funktionelle sprog arbejder ved at man tænker på løsningen og hvordan denne laves (matematisk set). Aspekter som memory, variabler, OS, plads, klasser, performance, objekter, aktører, delegates, whatever, er overflødige.
99% af alt arbejde er bare data in/out, og lidt manipulering / selektering oven på det.
Hvad forhindre os i at gøre det samme for objekt orienterede sprog?illishar (4) skrev:Grunden til at funktionelle sprog er gode i forbindelse med flere cores, er sikkert at man med en funktionel funktion kan afvikle alle del-funktoner af denne, på samme tid. Og alle del-funktionerne kan ligeledes deles op på samme måde. Programmøren skal derfor ikke tænke på, hvad der skal afvikles seperat o.s.v. Smart, smart.
#1
Grunden til at det antages at funktionelle sprog er bedre til ekstrem paralleliseret programmering er at rene funktionelle sprog ikke tillader side effects. Og det gør det meget nemmere at skrive thread safe kode.
Men jeg kan udmærket forstå din skepsis. Det er ikke specielt indlysende at et rent funktionelt sprog er velegnet til den typiske business app.
Og funktionelle sprog er da heller ikke rigtigt slået igennem endnu. Erlang og Scala er nok dem som har mest success.
Og der er ikke nogen garanti for at de nogensinde slår igennem. Funktionelle sprog er jo ikke ligefrem en ny opfindelse. Datalogi studerende har vel været tvunget til at lære dem i 30 år !!
Grunden til at det antages at funktionelle sprog er bedre til ekstrem paralleliseret programmering er at rene funktionelle sprog ikke tillader side effects. Og det gør det meget nemmere at skrive thread safe kode.
Men jeg kan udmærket forstå din skepsis. Det er ikke specielt indlysende at et rent funktionelt sprog er velegnet til den typiske business app.
Og funktionelle sprog er da heller ikke rigtigt slået igennem endnu. Erlang og Scala er nok dem som har mest success.
Og der er ikke nogen garanti for at de nogensinde slår igennem. Funktionelle sprog er jo ikke ligefrem en ny opfindelse. Datalogi studerende har vel været tvunget til at lære dem i 30 år !!
#5 Det er fordi du tænker på en typisk applikation, som en klassisk Database/Data-GUI-app. Hvis man er lidt grov, så kan man påstå, at der faktisk ikke er noget rigtig programmering i disse. (Dammit! Jeg har lige reduceret mig selv til tastatur-abe.)
"Rigtige" problemstillinger derimod kan være ting som "Givet det her netværk, hvordan får jeg så den korteste rute, uden at lave Dijkstra" eller "Det her tal 56468716 fylder jo alt for meget, hvis jeg gemmer det på disken. Hvordan får jeg det til at fylde mindre?". Når man vil arbejde med disse, så kan et funktionelt sprog hjælpe dig. (Hvis du er matematik-hat vel at mærke.)
Et lidt interessant scenarie, mht. de sprog som du selv nævner, er måske F#, som der er et .NET-sprog. Hvis du eksempelvis skal lave en database-app for en kunde, som der renderer dennes modeller, der ligger i databasen, i forskellige fotorealiske lys-situationer. Så kan du ansætte en matematik-super-geek (den slags er som regel ret dårlige til at lave database-apps), til at lave shaderne eller måske hele raytracingen. Dette vil han så lave i F#, som du derefter blot kan kalde fra dit hovedprogram, som der er skrevet i C#.
"Rigtige" problemstillinger derimod kan være ting som "Givet det her netværk, hvordan får jeg så den korteste rute, uden at lave Dijkstra" eller "Det her tal 56468716 fylder jo alt for meget, hvis jeg gemmer det på disken. Hvordan får jeg det til at fylde mindre?". Når man vil arbejde med disse, så kan et funktionelt sprog hjælpe dig. (Hvis du er matematik-hat vel at mærke.)
Et lidt interessant scenarie, mht. de sprog som du selv nævner, er måske F#, som der er et .NET-sprog. Hvis du eksempelvis skal lave en database-app for en kunde, som der renderer dennes modeller, der ligger i databasen, i forskellige fotorealiske lys-situationer. Så kan du ansætte en matematik-super-geek (den slags er som regel ret dårlige til at lave database-apps), til at lave shaderne eller måske hele raytracingen. Dette vil han så lave i F#, som du derefter blot kan kalde fra dit hovedprogram, som der er skrevet i C#.
Selve udviklingen er der vel ikke.illishar (8) skrev:Hvis man er lidt grov, så kan man påstå, at der faktisk ikke er noget rigtig programmering i disse.
Men programmører i dag er også mere system-designerer end kodeaber. Ihvertfald dem som kommer med en Datamatiker.
Datalogerne har nok højerere chance for at ende som matematiske nørder der koder raytracing modeller.
Men det som undre mig er stadigvæk grunden til at lære disse sprog hvis man IKKE er special hacker på et eller andet super matematisk projekt.
Fordi hvis vi kigger på virkeligeheden, så er det godt nok sjældent at du skal lave projekter i den stil. Og virksomheden vil nok hellere outsource det, end at oplære en medarbejder i endnu mere advanceret matematik.
Men som jeg forstår det, mener i altså at funktionelle sprog er gode til at lave udviklings værktøjer, til ikke funktionelle sprog.
Og problemet deri er at det er yderst sjældent at man kan lave noget som ikke allerede findes. Så derfor virker det så meningsløst at lære underlige sprog der ikke giver særlig meget mening når man læser dem.
Som udvikler i en virksomhed, så gælder det vel altid om at minimere udviklingstid og vedligehold. Hvis du er hjemmevant i et funktionelt sprog, så kan du forbedre begge dele, ved at implementere dine store algoritmer i dette. (Og at de automatisk så også er gode til at skalere, er jo også en bonus.)
Dog synes jeg personligt at denne omstilling er svær at foretage på kort tid. Hvis man nu havde en uge e.l. hvor man skulle arbejde på algoritmer, så kunne det dog godt være. Men ja, de er nok mest interessante hvis man arbejder indenfor datalogi-forskning.
Dog synes jeg personligt at denne omstilling er svær at foretage på kort tid. Hvis man nu havde en uge e.l. hvor man skulle arbejde på algoritmer, så kunne det dog godt være. Men ja, de er nok mest interessante hvis man arbejder indenfor datalogi-forskning.
Men hvor tit har du hjemmelavede algoritmer i din virksomhed?illishar (10) skrev:Hvis du er hjemmevant i et funktionelt sprog, så kan du forbedre begge dele, ved at implementere dine store algoritmer i dette. (Og at de automatisk så også er gode til at skalere, er jo også en bonus.)
Algoritmer til sortering er jo bygget standard ind i stort set alle frameworks, og typisk testet en del mere (og derfor mere reliable) end hvad du selv vil kunne kode.
Nu behøves en algoritme strengt taget ikke være til sortering. Og Algoritmer i frameworks er jo dejlige, men selv de har jo nogle begræsninger.
Og til mere specifikke problemer, f.eks. en eller anden motorcontrol af bestemt type og bla bla bla, så er det jo slet ikke sikkert den findes endnu.
Ps. Gider du lige definere en system designer? For det kan godt være at det med at "flette" applikationer idag er "slave" arbejde, men der er godt nok mange der er det. Og det er jo langt fra alle der kan være designeren af systemet. Vil bare høre om vi mener det samme :)
Og til mere specifikke problemer, f.eks. en eller anden motorcontrol af bestemt type og bla bla bla, så er det jo slet ikke sikkert den findes endnu.
Ps. Gider du lige definere en system designer? For det kan godt være at det med at "flette" applikationer idag er "slave" arbejde, men der er godt nok mange der er det. Og det er jo langt fra alle der kan være designeren af systemet. Vil bare høre om vi mener det samme :)
Tja, hvis man nu lige tager .NET som eksempel, så indeholder dette ikke nogle spatielle træer. (K-tree, R-tree, B-tree, Quad-tree, Octree.) Den har endnu heller ikke det jeg vil kalde en MultiDictionary. (Dictionary med flere values til hver index. Omend det nu ikke er så svært at lave.) Den indeholder heller ikke nogen afarter af Dijkstra-algoritmer. Deres sortering er vistnok bare en Quicksort. (Hvilket ikke den hurtigste til alle datasæt.) Den har ikke noget Linear Algebra-bibliotek. (Omend algoritmerne til disse ikke er så store. Det der er i DirectX.NET er ikke synderlig imponerende.) Den indeholder så vidt jeg ved heller ikke nogen komprimeringsalgoritme. (Men det kan være at jeg bare aldrig har søgt efter andet end SharpZipLib.) Den indeholder heller ikke værktøjer til Laplace, Fourier, Imaginære tal. O.s.v. Den indeholder heller ikke en pattern matching algoritme. (Det er ikke RegEx.)
Alle tingene kan naturligvis findes som tredjeparts-biblioteker, men så indtroducerer man jo så en vis grad af unreliable kode, der tilmed ikke kan vedligeholdes, eller som der er svært at vedligeholde.
(Men det er nu altså ikke fordi at jeg er vildt uenig med dig.)
Alle tingene kan naturligvis findes som tredjeparts-biblioteker, men så indtroducerer man jo så en vis grad af unreliable kode, der tilmed ikke kan vedligeholdes, eller som der er svært at vedligeholde.
(Men det er nu altså ikke fordi at jeg er vildt uenig med dig.)
F.eks. Dijkstra , der er jo et fint eksempel på hvordan den kan kodes på wikipedia.
Men jeg kan ikke se hvordan et funktionel sprog skulle kunne gøre det anderledes? For mig at se er det jo bare syntaks?
Jeg har tidligere implementeret Breadth-first search og Depth-first search i C#, hvilket jeg følte var relativt simpelt, og meget nemt at overskue ved brug af C# Objects og generics Lists.
Fordi man kan måske skrive en algoritme simpelt som matematik, men hvis man skal vælge properties ud fra forretningsspecifikke objekter, så kræver det pludselig meget kode, ligegyldigt hvilket sprog du vælger at kode det i.
Men jeg kan ikke se hvordan et funktionel sprog skulle kunne gøre det anderledes? For mig at se er det jo bare syntaks?
Jeg har tidligere implementeret Breadth-first search og Depth-first search i C#, hvilket jeg følte var relativt simpelt, og meget nemt at overskue ved brug af C# Objects og generics Lists.
Fordi man kan måske skrive en algoritme simpelt som matematik, men hvis man skal vælge properties ud fra forretningsspecifikke objekter, så kræver det pludselig meget kode, ligegyldigt hvilket sprog du vælger at kode det i.
Hvis du har tid og lyst, så er der de næste 6 tirsdage forelæsning i programmeringssprog på Daimi fra 11-14, hvor der specielt kigges på Scheme. Ved godt Scheme ikke udelukkende er funktionelt, men dog overvejende..
Edit: Lorte-links ;)
Edit: Lorte-links ;)
illishar (8) skrev:Det er fordi du tænker på en typisk applikation, som en klassisk Database/Data-GUI-app. Hvis man er lidt grov, så kan man påstå, at der faktisk ikke er noget rigtig programmering i disse.
I langt de fleste programmer udgør den slags imidlertid størstedelen af koden.
Windcape (9) skrev:
Men det som undre mig er stadigvæk grunden til at lære disse sprog hvis man IKKE er special hacker på et eller andet super matematisk projekt.
Fordi hvis vi kigger på virkeligeheden, så er det godt nok sjældent at du skal lave projekter i den stil. Og virksomheden vil nok hellere outsource det, end at oplære en medarbejder i endnu mere advanceret matematik.
Men som jeg forstår det, mener i altså at funktionelle sprog er gode til at lave udviklings værktøjer, til ikke funktionelle sprog.
Og problemet deri er at det er yderst sjældent at man kan lave noget som ikke allerede findes. Så derfor virker det så meningsløst at lære underlige sprog der ikke giver særlig meget mening når man læser dem.
Hvis du har fokus på dine job muligheder i nærmeste fremtid, så er der ikke nogen grund til at lære funktionelle sprog.
Men man lærer normalt altid noget nyttigt ved at lære en teknologi også selvom man ikke decideret skal bruge den teknologi.
Windcape (11) skrev:Men hvor tit har du hjemmelavede algoritmer i din virksomhed?.
Det er relativt almindeligt at skulle bruge lave algoritmer. Ikke matematisk orienterede algoritmer. Men forskellige business relaterede algoritmer.
Windcape (11) skrev:
Algoritmer til sortering er jo bygget standard ind i stort set alle frameworks, og typisk testet en del mere (og derfor mere reliable) end hvad du selv vil kunne kode.
Nu vil jeg mene at det hører med til almindlig IT dannelse at have programmeret QuickSort.
Men du har ret i at man stort set aldrig har behov for at programmer en QuickSort i den virkelige verden.
illishar (13) skrev:Tja, hvis man nu lige tager .NET som eksempel, så indeholder dette ikke nogle spatielle træer. (K-tree, R-tree, B-tree, Quad-tree, Octree.) Den har endnu heller ikke det jeg vil kalde en MultiDictionary.
Korrekt. Men et eller andet sted skal man jo stoppe.
illishar (13) skrev:Den har ikke noget Linear Algebra-bibliotek.
illishar (13) skrev:Den indeholder heller ikke værktøjer til Laplace, Fourier, Imaginære tal.
.NET har klart mere fokus på business computing end på scientific computing.
illishar (13) skrev:Den indeholder så vidt jeg ved heller ikke nogen komprimeringsalgoritme.
.NET fik System.IO.Compression namespace i 2005.
Windcape (14) skrev:F.eks. Dijkstra , der er jo et fint eksempel på hvordan den kan kodes på wikipedia.
Men jeg kan ikke se hvordan et funktionel sprog skulle kunne gøre det anderledes? For mig at se er det jo bare syntaks?
Jeg har tidligere implementeret Breadth-first search og Depth-first search i C#, hvilket jeg følte var relativt simpelt, og meget nemt at overskue ved brug af C# Objects og generics Lists.
Alle problemer kan løses i alle sprog.
Men nogle sprog har en syntax som giver kortere programmer (uvæsentligt) og/eller giver programmer med færre fejl (væsentligt).
Programmerings sprog er ikke one size fit all. Man vælger det rigtige værktøj til en given opgave.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund