mboost-dp1
Eight important books for software developers
Hvis man skal snakke om bøger der ændrer måden man tænker om software konstruktion, mener jeg at der også bør være andet end blot imperative metodlogier repræsenteret.
Design mønstre bogen er eksempelvis ikke særlig anvendelig med et rent funktionelt sprog som Haskell, da der ofte er bedre måder at løse de samme problemer på.
Nu er jeg ikke synsk men jeg kunne godt forstille mig at funktionelle programmører bliver en mangelvare i 2011. Fordelene vil, efterhånden som antallet af kerner øges (i desktop og mobile computere), blive gjort meget synlige, imo.
Design mønstre bogen er eksempelvis ikke særlig anvendelig med et rent funktionelt sprog som Haskell, da der ofte er bedre måder at løse de samme problemer på.
Nu er jeg ikke synsk men jeg kunne godt forstille mig at funktionelle programmører bliver en mangelvare i 2011. Fordelene vil, efterhånden som antallet af kerner øges (i desktop og mobile computere), blive gjort meget synlige, imo.
Listen er skrevet til/af Java programmører, så da de ikke har mulighed for funktionel programmering direkte i Java, så bliver det sikkert ignoreret.zook (3) skrev:Hvis man skal snakke om bøger der ændrer måden man tænker om software konstruktion, mener jeg at der også bør være andet end blot imperative metodlogier repræsenteret.
Tror det er et spørgsmål om perspektiv.
Kan anbefale følgende præsentation(hvis min påstand virker meget fremmed): [url= 2010: Rob Pike, "Public Static Void"[/url]
og følgende læsning: Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson
Der er også andet på vej i horizonten, spørgsmålet er selvfølgelig om tidspunktet er nu for at lære noget andet. Men det vil jeg mene er enhver udviklers eget ansvar selv at vurdere.
Kan anbefale følgende præsentation(hvis min påstand virker meget fremmed): [url= 2010: Rob Pike, "Public Static Void"[/url]
og følgende læsning: Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson
Der er også andet på vej i horizonten, spørgsmålet er selvfølgelig om tidspunktet er nu for at lære noget andet. Men det vil jeg mene er enhver udviklers eget ansvar selv at vurdere.
#12
Rob Pike gentog sin kritik af imperative sprogs boilerplate på JAOO, men hvad han ikke tager med er at vi slet ikke skriver eller bekymre os om den del.
Udviklingsværktøjer gør at imperative sprog i høj grad skriver sig selv, hvor modsat de funktionelle sprog, stadigvæk mangler værktøjer, og derfor tvinger programmøren til at bruge mere tid på at skrive selve koden.
F# er dog en undtagelse.
Min erfaring er nærmere at Java programmører normalt er ligeglade med det funktionelle paradigm, hvor at det i C# trives mere. (F# virker mere kendt hos C# udviklere, end Scala gør det hos Java udviklere).
Rob Pike gentog sin kritik af imperative sprogs boilerplate på JAOO, men hvad han ikke tager med er at vi slet ikke skriver eller bekymre os om den del.
Udviklingsværktøjer gør at imperative sprog i høj grad skriver sig selv, hvor modsat de funktionelle sprog, stadigvæk mangler værktøjer, og derfor tvinger programmøren til at bruge mere tid på at skrive selve koden.
F# er dog en undtagelse.
Har du nogen tal på det? Jeg har lidt svært ved at tro på at Scala (som er multi-paradigm, ikke purt funktionelt) er "den foretrukne platform" for funktionel programmering.arne_v (9) skrev:Og hvis man med Java mener Java platform i modsætning til Java sproget, så er det den foretrukne platform for funktionel programmering.
Min erfaring er nærmere at Java programmører normalt er ligeglade med det funktionelle paradigm, hvor at det i C# trives mere. (F# virker mere kendt hos C# udviklere, end Scala gør det hos Java udviklere).
#12 & 13
Det er værd at huske på at funktionel programmering er gammel. Den er faktisk ældre end objekt orienteret programmering.
Men den har aldrig slået rigtigt igennem.
Nu er der en vis forventning om at:
multi core CPU => multi threaded programmer => funktionel programmering
Men det er indtil videre kun en teori.
Der ses en øget brug af funktionel programmering specielt i Scala, men det er stadig kun special formål ikke mainstream formål.
Det er værd at huske på at funktionel programmering er gammel. Den er faktisk ældre end objekt orienteret programmering.
Men den har aldrig slået rigtigt igennem.
Nu er der en vis forventning om at:
multi core CPU => multi threaded programmer => funktionel programmering
Men det er indtil videre kun en teori.
Der ses en øget brug af funktionel programmering specielt i Scala, men det er stadig kun special formål ikke mainstream formål.
Windcape (13) skrev:Har du nogen tal på det? Jeg har lidt svært ved at tro på at Scala (som er multi-paradigm, ikke purt funktionelt) er "den foretrukne platform" for funktionel programmering.
En søgning på dice.com siger:
Scala 42
Clojure 17
F# 3
Erlang 25
Lisp 18
Haskell 5
OCAML 4
Windcape (13) skrev:Min erfaring er nærmere at Java programmører normalt er ligeglade med det funktionelle paradigm, hvor at det i C# trives mere. (F# virker mere kendt hos C# udviklere, end Scala gør det hos Java udviklere).
F# fik en masse omtale. Og jeg tror at en masse C# udviklere har snuset lidt til det.
Men hvem bruger det?
Scala liver måske nok et diskret liv, men det bliver brugt.
Alle ved at Twitter bruger det til deres backend.
Version2 havde en historie omkring hvordan en energi børs migrerer til Scala:
http://www.version2.dk/artikel/11389-energiboers-d...
Novell bruger det til deres cloud baserede collaboration platform.
LinkedIn, Siemens og Sony bruger også Scala til nogle (vistnok mindre) ting.
Det kan fortolkes på 2 måder.arne_v (16) skrev:En søgning på dice.com siger:
Enten at Scala er meget populært, eller det er *ved* at blive populært, hvor at de gængse platforme som Erlang og Haskell, mister popularitet.
Men Haskell kunne jo sagtens stadigvæk være mere populært.
I sig selv, ja. Men rent konceptmæssigt har introduktionen af LINQ, gjort at næsten alle .NET programmører jeg har snakket med, har kigget dybere ind i funktionel programmering.arne_v (17) skrev:Nu skal der lidt mere end brug af LINQ (eller XSLT eller SQL) til for at jeg vil kalde noget for FP.
Helt rigtigt, det er svært at sige.arne_v (16) skrev:F# fik en masse omtale. Og jeg tror at en masse C# udviklere har snuset lidt til det.
Men hvem bruger det?
Måske mere i USA end i Europa. Specielt i Danmark virker det ikke særlig "in".arne_v (16) skrev:Scala liver måske nok et diskret liv, men det bliver brugt.
Windcape (18) skrev:Det kan fortolkes på 2 måder.
Enten at Scala er meget populært, eller det er *ved* at blive populært, hvor at de gængse platforme som Erlang og Haskell, mister popularitet.
Men Haskell kunne jo sagtens stadigvæk være mere populært.
Generelt må man formode at de skills der efterspørges i job annoncer afspejler det arbejde der skal laves (nyudvikling eller vedligehold).
Det afspejler åbenlyst ikke eksisterende kode mængde.
Men hvis ikke ny kode vil dominere gammel kode indenfor FP, så bliver FP ikke en success!
Windcape (18) skrev:Måske mere i USA end i Europa. Specielt i Danmark virker det ikke særlig "in".
Energi børsen er fransk.
Siemens og Sony koncernerne er heller ikke amerikanske, men jeg kan naturligvis ikke udelukke at deres Scala udvikling sker i USA.
Jeg tror på at Scala ikke er populært i Danmark. Men det overlever Scala nok.
Jeg tror ikke at funktionelle sprog behøver erstatte eksisterende løsninger. Fordelene ved at bruge et funktionelt som et lim sprog mellem eksisterende teknologier, er en øget produktivitet (mindre kode, mere produktivitet) og en øget tiltro til at ens kode rent faktisk virker når først compileren har accepteret det.
Men jeg benægter ikke at det er et svært paradigme skift. Jeg har selv brugt det sidste års tid på at lære Scheme og Haskell. Jeg startede som teenager med at programmere i maskinkode og har siden været alle de almindeligt anvendte imperative sprog igennem. Personligt har springet været større end jeg husker Object Orientering var i sin tid. Kan varmt anbefale Structure and Interpretation of Computer Programs som en teoretisk introduktion med fokus på MIT Scheme(som er et overraskende simpelt sprog). Jeg valgte Haskell som supplement da det som et rent funktionelt sprog tvinger en til at danne nye vaner som programmør. Der er ganske enkelt ikke ret meget genkendeligt at falde tilbage på. Hvilket når man snakker om paradigme skift, er en god ting.
Når det så er sagt, så har det for mig handlet om at genfinde glæden ved at programmere. Hvilket jeg nok må indrømme var noget jeg i C++ og Java for længst havde mistet. Jeg arbejder stadig med begge sprog, i kraft af at jeg udvikler til Android, men jeg arbejder næsten udelukkende med dem fra Haskell af.
Men jeg benægter ikke at det er et svært paradigme skift. Jeg har selv brugt det sidste års tid på at lære Scheme og Haskell. Jeg startede som teenager med at programmere i maskinkode og har siden været alle de almindeligt anvendte imperative sprog igennem. Personligt har springet været større end jeg husker Object Orientering var i sin tid. Kan varmt anbefale Structure and Interpretation of Computer Programs som en teoretisk introduktion med fokus på MIT Scheme(som er et overraskende simpelt sprog). Jeg valgte Haskell som supplement da det som et rent funktionelt sprog tvinger en til at danne nye vaner som programmør. Der er ganske enkelt ikke ret meget genkendeligt at falde tilbage på. Hvilket når man snakker om paradigme skift, er en god ting.
Når det så er sagt, så har det for mig handlet om at genfinde glæden ved at programmere. Hvilket jeg nok må indrømme var noget jeg i C++ og Java for længst havde mistet. Jeg arbejder stadig med begge sprog, i kraft af at jeg udvikler til Android, men jeg arbejder næsten udelukkende med dem fra Haskell af.
Haskell er nok ikke det ideele sprog, da det er et meget komplekst sprog.
Jeg vil hellere anbefale folk F#, da de fleste alligevel har haft et kursus i ML/OCalm på uni, på et eller andet tidspunkt.
Personligt synes slet ikke springet var særlig stort. At vende sig til 50 nye ASCII operators er langt sværerer end at forstå konceptet bag funktionel programmering.
Og når man bare een gang har lavet tail-recursion i et funktionelt sprog, så bliver man fusteret hver eneste gang det skal gøres i et imperativt sprog :p
Jeg vil hellere anbefale folk F#, da de fleste alligevel har haft et kursus i ML/OCalm på uni, på et eller andet tidspunkt.
Personligt synes slet ikke springet var særlig stort. At vende sig til 50 nye ASCII operators er langt sværerer end at forstå konceptet bag funktionel programmering.
Og når man bare een gang har lavet tail-recursion i et funktionelt sprog, så bliver man fusteret hver eneste gang det skal gøres i et imperativt sprog :p
Tja, jeg vil nu mene at C++ er endnu mere komplekst. I sær hvis du vil anvende templates. Hvilket i dag nærmest er et krav i form af boost og andre vigtige biblioteker.
Jeg vil ikke mene der er nogen årsag til bekymring omkring operatorer i Haskell.
Sproget stiller de faciliteter til rådighed som er nødvendig for at gøre operatorer brugbare.
Ifølge http://www.cs.ut.ee/~varmo/MFP2004/PreludeTour.pdf så definerer Prelude modulet 22 polymorfiske operator. Prelude er opstarts miljøet i Haskell. Kigger man på hvilke operatorer der er tale om, vil jeg nødig være uden de fleste af dem, i et hvilket som helst sprog.
Som Rob Pike nævner ville man nok, hvis man havde kendt til ordet design mønstre, have kaldt et funktions kald for et design mønster tilbage da den slags var betragtet som værende udfordrende.
Heldigvis har funktions kald siden hen vist sig at være så nyttige at de er at finde i næsten alle sprog i dag.
Men kan godt se at newz.dk er det forkerte sted for en sådan diskussion :)
Jeg vil ikke mene der er nogen årsag til bekymring omkring operatorer i Haskell.
Sproget stiller de faciliteter til rådighed som er nødvendig for at gøre operatorer brugbare.
Ifølge http://www.cs.ut.ee/~varmo/MFP2004/PreludeTour.pdf så definerer Prelude modulet 22 polymorfiske operator. Prelude er opstarts miljøet i Haskell. Kigger man på hvilke operatorer der er tale om, vil jeg nødig være uden de fleste af dem, i et hvilket som helst sprog.
Som Rob Pike nævner ville man nok, hvis man havde kendt til ordet design mønstre, have kaldt et funktions kald for et design mønster tilbage da den slags var betragtet som værende udfordrende.
Heldigvis har funktions kald siden hen vist sig at være så nyttige at de er at finde i næsten alle sprog i dag.
Men kan godt se at newz.dk er det forkerte sted for en sådan diskussion :)
C++ er et kapitel for sig selv. Jeg synes kun det er værd at fokusere på Java og C# når det handler om at kombinere mainstream imperativ programming med funktionel programmering.zook (24) skrev:Tja, jeg vil nu mene at C++ er endnu mere komplekst. I sær hvis du vil anvende templates. Hvilket i dag nærmest er et krav i form af boost og andre vigtige biblioteker.
Hvorfor?zook (24) skrev:Men kan godt se at newz.dk er det forkerte sted for en sådan diskussion :)
Derudover skal diskussionen være ærke-pragmatisk. Alle som forsøger at lede funktionel programmering tilbage ind på den akademiske tankegang, vil bare bevise hvorfor funktionel programmering stadigvæk ikke er "in".
Men problemet med f.eks. Haskell og mange andre funktionelle sprog, er at de mangler grund-funktionalitet som alle imperative (eller ihvertfald object-orienterede) sprog har i dag.
Derfor er multi-paradigm sprog som Scala og F# nødvendige for at få ordenligt udnyttelse. Og jeg mener derfor de er bedre at lære, frem for de pure sprog, da man i Scala og F# faktisk kan lave noget brugbart, frem for rene akademiske øvelser uden mening.
FP handler ligeså meget om at sikre sig mod side-effekter, og have clean, easy-readable, maintainable code. Og det kan man sagtens opnå med paradigmet i sprog som f.eks. C#.
(Java og C++ mangler nogle småting, som f.eks. generators, for at opnå samme effekt som C#, men det er tæt på.)
Derfor er multi-paradigm sprog som Scala og F# nødvendige for at få ordenligt udnyttelse. Og jeg mener derfor de er bedre at lære, frem for de pure sprog, da man i Scala og F# faktisk kan lave noget brugbart, frem for rene akademiske øvelser uden mening.
FP handler ligeså meget om at sikre sig mod side-effekter, og have clean, easy-readable, maintainable code. Og det kan man sagtens opnå med paradigmet i sprog som f.eks. C#.
(Java og C++ mangler nogle småting, som f.eks. generators, for at opnå samme effekt som C#, men det er tæt på.)
Windcape (25) skrev:C++ er et kapitel for sig selv. Jeg synes kun det er værd at fokusere på Java og C# når det handler om at kombinere mainstream imperativ programming med funktionel programmering.
Fair nok. Kender dog ikke noget til C#.
Windcape (25) skrev:Hvorfor?
Fordi diskussionen bærer præg af manglende erfaring med funktionelle sprog.
Windcape (25) skrev:Derudover skal diskussionen være ærke-pragmatisk.
Vil nu nok mene jeg er pragmatisk i min tilgang. Derfor har jeg stadig valgt at prioritere at lære et funktionelt sprog, til trods for at meget af litteraturen er tiltænkt dataloger.
Dog vil jeg mene at der med bøger som Real World Haskell og Haskell School of Expression også er noget for pragmatikere.
Jeg er ikke datalog, men jeg har taget nogle enkelte af de fag som jeg har fundet nødvendige for min egen forståelses skyld.
Windcape (25) skrev:Alle som forsøger at lede funktionel programmering tilbage ind på den akademiske tankegang, vil bare bevise hvorfor funktionel programmering stadigvæk ikke er "in".
Jeg er sådan set ikke ude på at bevise noget. Du kan tage mine meninger eller råd som du har lyst.
Windcape (26) skrev:Men problemet med f.eks. Haskell og mange andre funktionelle sprog, er at de mangler grund-funktionalitet som alle imperative (eller ihvertfald object-orienterede) sprog har i dag.
Måske. Jeg valgte Haskell for at slippe for den "grund-funktionalitet" og lære nogen andre måder at løse problemer på.
Funktionelt programmering kræver et andet sæt af mentale værktøjer og når først disse er lært, er det ikke min oplevelse at der mangler noget i sproget, nærmest tværtimod.
Windcape (26) skrev:Derfor er multi-paradigm sprog som Scala og F# nødvendige for at få ordenligt udnyttelse.
Nødvendige, bestemt. Bedre at lære? Det kommer nok an på hvad man håber på at få ud af det.
Windcape (26) skrev:Og jeg mener derfor de er bedre at lære, frem for de pure sprog, da man i Scala og F# faktisk kan lave noget brugbart, frem for rene akademiske øvelser uden mening.
Synes det er ærgeligt du ikke formår at adskille tingene. Ja, funktionelle sprog har deres oprindelse og primære udbredelse blandt dataloger. Det gør det altså ikke til en meningsløs akademisk øvelse at lære dem, eller at programmere i dem. Men man er givet vis mere på bar bund når man skal starte forfra. Sådan er det.
Windcape (26) skrev:FP handler ligeså meget om at sikre sig mod side-effekter, og have clean, easy-readable, maintainable code. Og det kan man sagtens opnå med paradigmet i sprog som f.eks. C#.
(Java og C++ mangler nogle småting, som f.eks. generators, for at opnå samme effekt som C#, men det er tæt på.)
Interessant. Jeg er dog ikke helt enig.
Du udelader at nævne compileren, som er langt mere intelligent i et sprog som Haskell (algebraic data types, lazy evaluation, pattern matching).
Som pragmatiker, har jeg det ganske fint med at compileren/fortolkeren fra start er tiltænkt en hjælpe rolle modsat f.eks. Java. Det er en væsentlig egenskab, som ærligt talt får Java (og beslægtede sprog) til at virke forældet.
Men som sagt, så lyder du som du ved alt hvad du har brug for om funktionelle sprog og fred være med det.
#26
Mit største irritationsmoment ved F# er deres svage generics.
Lektien fra Haskell er (om noget) at FP giver nogle meget gode muligheder for at lave type checks, som F# endnu ikke udnytter. Håber at det kommer i næste version.
Mit største irritationsmoment ved F# er deres svage generics.
Lektien fra Haskell er (om noget) at FP giver nogle meget gode muligheder for at lave type checks, som F# endnu ikke udnytter. Håber at det kommer i næste version.
#27 Du taler meget om at være pragmatiker. Umiddelbart handler pragmatik indenfor "udvikling", meget om at komme fra A til B hurtigst/billigst muligt, evt. krydret med fremtidig betragtninger om efterfølgende vedligehold. Hyppig brug af sætningen "Who gives a shit" forventes.
Funktionel programmering er muligvis det pragmatiske valg i nogle tilfælde (performance), men pragmatisk set er det jo statistisk ikke det første valg man bør overveje. Alene pga. udbredelse, hvis man ikke kan finde på andre modargumenter.
Og med antallet af eksisterende kode-linier, så vil der nok gå rigtig mange år før funktionelle sprog bliver det "pragmatiske" valg. Desværre.
Funktionel programmering er muligvis det pragmatiske valg i nogle tilfælde (performance), men pragmatisk set er det jo statistisk ikke det første valg man bør overveje. Alene pga. udbredelse, hvis man ikke kan finde på andre modargumenter.
Og med antallet af eksisterende kode-linier, så vil der nok gå rigtig mange år før funktionelle sprog bliver det "pragmatiske" valg. Desværre.
zook (27) skrev:Du udelader at nævne compileren, som er langt mere intelligent i et sprog som Haskell (algebraic data types, lazy evaluation, pattern matching).
Windcape (29) skrev:Måske fordi man sjældent/aldrig har brug for det :p
Man skal bestemt ikke undervudere static proving og informative warnings. Windcape, du bruger helt sikkert også FxCop o.l. (Som forøvrigt er på top10 over værktøjer som .NET-folk *skal* kende.) Og functionelle sprog har langt bedre betingelser, end hvad FxCop må arbejde med.
Det var nu ikke for at anbefale FP som et første sprog. Mener nu iøvrigt heller ikke at bøgerne på listen er særligt egnet til første gangs læsning.
Angående pragmatik. Jeg sidder pt. og arbejder med et projekt som involverer flere C og C++ biblioteker som jeg benytter gennem haskell med FFI. Dog er der visse mangler ved FFI som gør det vanskeligere end det formenligt kunne være at snakke direkte med C++. Tror til dels noget af arbejdet kan automatiseres med output fra gcc-xml. Der er ikke de store problemer med bruge biblioteker med et C api. Det er bestemt muligt at integrere eksisterende løsninger med eksempelvis Haskell, som er hvad jeg arbejder med.
Jeg går udfra de fleste andre funktionelle sprog har lignende muligheder for at snakke med omverdenen. Ser ihvertfaldt hyppigt at der også findes bindings mellem populære biblioteker og sprog som erlang, occaml, scheme osv.
Angående pragmatik. Jeg sidder pt. og arbejder med et projekt som involverer flere C og C++ biblioteker som jeg benytter gennem haskell med FFI. Dog er der visse mangler ved FFI som gør det vanskeligere end det formenligt kunne være at snakke direkte med C++. Tror til dels noget af arbejdet kan automatiseres med output fra gcc-xml. Der er ikke de store problemer med bruge biblioteker med et C api. Det er bestemt muligt at integrere eksisterende løsninger med eksempelvis Haskell, som er hvad jeg arbejder med.
Jeg går udfra de fleste andre funktionelle sprog har lignende muligheder for at snakke med omverdenen. Ser ihvertfaldt hyppigt at der også findes bindings mellem populære biblioteker og sprog som erlang, occaml, scheme osv.
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
- ⟨
- Tagwall
Gå til bund