Functioneel Programmeren

[Qqwy]

@NMe: Een van de argumenten die de laatste tijd steeds sterker wordt, is het feit dat Moore's Law niet meer van toepassing is; Vanwege de fysieke limieten aan hoe klein transistoren in CPU's gemaakt kunnen worden, worden CPU's niet langer sneller (in de mate waarin dat eerder het geval was, namelijk een snelheidsverdubbeling elke 18 maanden). De oplossing hiervoor is om computers te maken die meer cores hebben. Maar de enige manier om deze cores te kunnen gebruiken is om software te maken die daadwerkelijk tegelijkertijd op meerdere cores kan draaien ('parallel computing').

Concurrency is iets waar OOP niet goed in is, omdat het geen enkele beveiliging biedt tegen het 'per ongeluk aanpassen van iets terwijl een andere thread ook bezig was'. Locks en mutexes zorgen voor hele complexe systemen, waarbij het nagenoeg onmogelijk is om fouten op te sporen.

Op het moment dat je data-structuren vanaf het begin af aan immutable zijn, kun je niet per ongeluk data overschrijven terwijl een ander thread er nog mee bezig was, omdat je niet tegelijk in dezelfde data kunt zitten werken. Er bestaan twee systemen, het Actor Model en Software-Transactional Memory die een andere benadering hebben tot concurrency, die deze problemen niet hebben.

Dit is natuurlijk niet de enige reden die er bestaat, maar wel één van de belangrijkste redenen, die een oplossing beschrijft voor een probleem waar veel mensen bekend mee zijn.

Het is natuurlijk niet mijn bedoeling om iedereen hier te converteren naar functioneel programmeren (Dat zou nooit lukken, hihi), maar ik ben wel van mening dat het goed is om zo veel mogelijk verschillende talen en stijlen uit te proberen, zodat je problemen van zo veel mogelijk verschillende referentiepunten kunt benaderen, en je niet verandert in een blub-programmeur.

---

Ik ben zelf ook groot fan van Elixir en naast dat ik een aantal packages geschreven heb die op Hex.pm te vinden zijn, zijn we het nu voor een paar interne projectjes aan het gebruiken bij mijn werk. Heel gaaf!

kraades schreef op zondag 30 oktober 2016 @ 18:46:
Ik ben bekend met Elixir en Phoenix.
Verplichte literatuur:

...

Vergeet ook vooral Saša Jurić's boek 'Elixir in Action' niet!.

[ Voor 6% gewijzigd door Qqwy op 30-10-2016 18:55 . Reden: toevoegen boek ]

[NMe]

Qqwy schreef op zondag 30 oktober 2016 @ 18:53:
@NMe: Een van de argumenten die de laatste tijd steeds sterker wordt, is het feit dat Moore's Law niet meer van toepassing is; Vanwege de fysieke limieten aan hoe klein transistoren in CPU's gemaakt kunnen worden, worden CPU's niet langer sneller (in de mate waarin dat eerder het geval was, namelijk een snelheidsverdubbeling elke 18 maanden). De oplossing hiervoor is om computers te maken die meer cores hebben. Maar de enige manier om deze cores te kunnen gebruiken is om software te maken die daadwerkelijk tegelijkertijd op meerdere cores kan draaien ('parallel computing').

Concurrency is iets waar OOP niet goed in is, omdat het geen enkele beveiliging biedt tegen het 'per ongeluk aanpassen van iets terwijl een andere thread ook bezig was'. Locks en mutexes zorgen voor hele complexe systemen, waarbij het nagenoeg onmogelijk is om fouten op te sporen.

Er is in een OOP-taal niks dat je tegenhoudt om bepaalde delen procedureel te schrijven.

[technorabilia]

Dat wil nog niet zeggen dat dit dan ook efficiënt wordt uitgevoerd. Elixir heeft Erlang als basis. Die heeft die dingen in de core ingebouwd.

Wikipedia: Erlang (programming language)

@qqwy
Dat boek heb ik ook.

[ Voor 6% gewijzigd door technorabilia op 30-10-2016 19:02 ]

[BCC]

NMe schreef op zondag 30 oktober 2016 @ 18:57:
[...]

Er is in een OOP-taal niks dat je tegenhoudt om bepaalde delen procedureel te schrijven.

Klopt, alle programmeer talen zijn turing-compleet dus je kan alles in alle talen schrijven; dat is niet het punt.
Elixir en Erlang hebben een hele handige library (OTP), waardoor een heleboel problemen waar je nu tegen aanloopt bij het ontwikkelen van webapplicaties met OOP wegvallen. OTP maakt hiervoor gebruik van functioneel programmeren om zaken als schaalbaarheid en concurrency op een voor de ontwikkelaar eenvoudige en robuuste manier op te lossen.

Standaard heb ik bijvoorbeeld bij een grote Rails app (met meerdere applicatie servers) draaien: Haproxy, Keepalived Nginx, Passenger, Rails, Memcache, Sidekiq, Redis, Mysql, God (process monitoring) draaien, Rbenv, Ruby en mijn app. De meeste onderdelen zijn er om schaling en concurrency te managen.

Met Elixir en Phoenix is deze stack terug gebracht tot: Mijn binary en Mysql. Dit scheelt me dus gewoon veel tijd!

Verder is het in Functioneel programmeren eenvoudiger om je edge-cases af te handelen, wat je app natuurlijk ook alleen maar ten goede komt.

[ Voor 31% gewijzigd door BCC op 30-10-2016 19:20 ]

[Qqwy]

NMe schreef op zondag 30 oktober 2016 @ 18:57:
[...]

Er is in een OOP-taal niks dat je tegenhoudt om bepaalde delen procedureel te schrijven.

Ignoratio elenchi. Netzomin is er in een Functonele taal iets dat je tegenhoudt om bepaalde delen imperatief of object-georienteerd te schrijven. Op dezelfde manier: Kun je de procedurele code in een OOP-programma dan nog wel object-georienteerd noemen?

Aan de andere kant, een taal waar bepaalde functionaliteit in de core, de compiler of in de virtuele machine ingebouwd zit kan bepaalde aanames maken over de correctheid van de code, en het op deze manier bijvoorbeeld versnellen.

Een paar voorbeelden:
- Functionele talen met static typing hebben geen 'null', maar gebruiken een type genaamd 'Maybe'(Haskell) of 'Option'(Clojure, Scala) (dit kan gezien worden als een doosje dat leeg is of niet). Alle code die zo'n type gebruikt is verplicht om bewerkingen voor beide varianten (gevuld en leeg) te defineren, of anders zal de compiler klagen. Dit betekent dat je er veel zekerder van kunt zijn dat je programma goed werkt in uitzonderingssituaties.
- de BEAM (de virtuele machine waar Erlang en Elixir op gebouwd zijn) doet intern de communicatie tussen verschillende onderdelen van je programma voor je. Dit betekent dat je als gebruiker je niet druk hoeft te maken over hoe je programma zich over meerdere cores verdeeld. En dit werkt nog steeds (zonder je programma ook maar hoeven te wijzigen!) precies hetzelfde wanneer je je programma op een supercluster van computers verspreid over de hele wereld uitvoert.
- Compilers zoals die van bijv. Haskell en Rust kunnen, vanwege het gebruik van static typing en immutability je programma rigoreus herschrijven, de compiler kan bewijzen dat de omgeschreven variant nog steeds precies dezelfde eigenschappen vertoont. Hierdoor zijn ze voor veel probleem-domeinen even snel (of sneller) en vaak leesbaarder dan imperatieve of object-georienteerde varianten.
- Omdat er ingebouwd gebruik gemaakt wordt van structural typing ipv. nominative typing kan functionaliteit die werkt op bepaalde data-structuren heel eenvoudig worden hergebruikt.
- Pattern-matching. Wanneer je eenmaal gewend bent aan de leesbaarheid en begrijpbaarheid die dit met zich meebrengt, wil je dat alle talen dit zouden hebben.

Nog een leuk fenomeen is trouwens dat meer en meer andere talen bepaalde features van functionele talen overnemen. Dit is mooi, want zo worden nog meer mensen blootgesteld aan deze ideeën.

[Bigs]

Ik heb in het verleden wel met Clojure gespeeld. Ik vond het in theorie fantastisch, maar in de praktijk vond ik het heel lastig om resultaat te bereiken met pure functies. Sinds kort ben ik met Elixir aan de slag en dat bevalt me een stuk beter. De performance ten op zichte van Ruby (maar zelfs ten opzichte van bijvoorbeeld Go) is verbazingwekkend. Desondanks merk je wel dat je jezelf al 20 jaar wijs hebt gemaakt dat OOP de meest logische manier van programmeren is. Ik denk dat dat nog wel even afkicken is en misschien zelfs wel nooit weggaat.

[technorabilia]

Jullie kunnen wel al opdrachten vinden waar je Elixir kunt toepassen?

[BCC]

Yes, 1 klant vroeg er expliciet om, 1 boeit de tech niet, als het maar werkt.

[Qqwy]

kraades schreef op zondag 30 oktober 2016 @ 19:57:
Jullie kunnen wel al opdrachten vinden waar je Elixir kunt toepassen?

Het gaat op dit moment nog erg moeizaam.
Ik weet van een paar bedrijven die over zijn gestapt van Rails->Elixir+Phoenix die nog geen moment spijt hebben vanwege de lagere code-debt en vele malen hogere en voorspelbaardere app-snelheid. Wij bij Panache, waar ik werk, proberen hard om de taal verder bekend te maken, omdat we zelf erg onder de indruk zijn van deze technologie, en hopen dat meer mensen het zullen gaan gebruiken.


En inderdaad, wanneer je het privilege hebt om met een greenfield aan de slag te gaan (wanneer je dus vanaf het begin iets nieuws gaat opzetten), is Elixir en de BEAM een fantastische basis .

[BCC]

De grote Rails shops in Nederland: Holder en Kabisa zijn beide erg actief in de Elixir community NL dus dat zegt wel wat over de toekomstige apps in NL.

[Caelorum]

Qqwy schreef op zondag 30 oktober 2016 @ 19:23:
[...]
- Functionele talen met static typing hebben geen 'null', maar gebruiken een type genaamd 'Maybe'(Haskell) of 'Option'(Clojure, Scala) (dit kan gezien worden als een doosje dat leeg is of niet). Alle code die zo'n type gebruikt is verplicht om bewerkingen voor beide varianten (gevuld en leeg) te defineren, of anders zal de compiler klagen. Dit betekent dat je er veel zekerder van kunt zijn dat je programma goed werkt in uitzonderingssituaties.[...]

Dat is niet iets wat alleen maar aan puur functionele talen voorbehouden is. Een OOP taal kan net zo goed een non-nullable type hebben (en sommige hebben het ook tot op zekere hoogte). Dan ben je net zo goed verplicht om de cases waarbij je mogelijk null assigned op te lossen. Dus dat kan geen argument zijn voor functionele talen.
En zo is het ook voor pattern-matching (komt gedeeltelijk in C#7 en dan 'volledig' in 8. En zelfs immutable types staat op de lange termijn planning voor na versie 8.

[...]
Nog een leuk fenomeen is trouwens dat meer en meer andere talen bepaalde features van functionele talen overnemen. Dit is mooi, want zo worden nog meer mensen blootgesteld aan deze ideeën.

Dat dus, alleen zijn dit ook niet echt features die alleen in de context van functioneel programmeren handig zijn. Wat dat betreft vind ik het ook niet echt in een topic over functioneel programmeren thuis horen ^^

[Qqwy]

Veertig jaar geleden was het makkelijk; Toen kon je zeggen:

Imperatieve talen zijn ontstaan uit assembly; ze zijn een nauwe laag om de hardware van een computer.
Functionele talen zijn ontstaan uit de wiskunde;

In de huidige tijd is het echter zo dat de al bestaande programmeertalen sterke invloed gehad hebben op de talen die er nu bij komen, en bovenstaande vergelijking flink verwaterd is.

Caelorum schreef op zondag 30 oktober 2016 @ 22:15:
[...]

Dat is niet iets wat alleen maar aan puur functionele talen voorbehouden is. Een OOP taal kan net zo goed een non-nullable type hebben (en sommige hebben het ook tot op zekere hoogte). Dan ben je net zo goed verplicht om de cases waarbij je mogelijk null assigned op te lossen. Dus dat kan geen argument zijn voor functionele talen.
En zo is het ook voor pattern-matching (komt gedeeltelijk in C#7 en dan 'volledig' in 8. En zelfs immutable types staat op de lange termijn planning voor na versie 8.

Fantastisch! Dat vind ik superfijn om te horen! Qua OOP-talen met een non-nullable type ben ik op de hoogte van Crystal, een statically-typed OOP-taal met een syntax die erg lijkt op Ruby.

En ik heb er zelf geen ervaring mee, maar mij is verteld dat het LINQ dat in C# (en de andere .NET talen) ingebouwd zit ook een fantastische uitvinding is wat het leven gemakkelijker maakt. LINQ is een functioneel concept.

Caelorum schreef op zondag 30 oktober 2016 @ 22:15:
[...]

Dat dus, alleen zijn dit ook niet echt features die alleen in de context van functioneel programmeren handig zijn. Wat dat betreft vind ik het ook niet echt in een topic over functioneel programmeren thuis horen ^^

Het is helemaal waar dat veel van deze features ook nuttig zijn buiten een functonele context. Het is heel mooi dat er meer en meer talen zijn die lambdas/closures, currying en immutability ondersteunen.

Dat haalt niet weg dat deze features oorspronkelijk uit de functonele wereld komen. Dat ze nu van een grotere exposure genieten is geen reden om ze niet te benoemen.

Ook is het uiteindelijk erg moeilijk om talen in 'perfecte vakjes' te stoppen, en in mijn mening ook oninteressant; Afhankelijk van hoe serieus je een definitie van OOP neemt, zouden Java en C++ hier bijvoorbeeld buitenvallen omdat ze primitieven hebben die zelf geen objecten zijn. Veel talen zijn tegenwoordig multi-paradigm, wat betekent dat je als programmeur vrij(er) bent in je keuzes van hoe je een probleem benadert.

Dus ik denk dat het niet erg nuttig is om naar absolute verschillen te kijken, want dit is vaak erg moeilijk en subjectief, maar in plaats daarvan proberen de verschillende denkvormen te stimuleren, want ons probleemoplossend vermogen is uiteindelijk waar we het als programmeurs van moeten hebben .

[farlane]

Zolang "C achtigen" nog de standaard zijn in mijn vakgebied, zie ik het als super interessant, maar niet meer dan dat.

[Verwijderd]

NMe schreef op zondag 30 oktober 2016 @ 18:35:
Natuurlijk kennen we allemaal functionele talen, maar ik ken geen enkel goed argument om ze te gebruiken tenzij er hardwarelimitaties of andere heel specifieke wensen zijn.

Ik weet niet wie "we" allemaal zijn, maar tot een jaar of twee geleden kende ik geen functionele taal, ik had er alleen over gelezen. Hetzelfde geldt voor het merendeel van de programmeurs die ik ken die werken met de taal waarin ik programmeerde. Sinds bijna een jaar werk ik volop met elixir en het phoenix framework (een webframework gebaseerd op elixir), na een jaar of achttien procedureel en object-georienteerd programmeren aan administratieve applicaties in verschillende branches (logistiek, levensverzekeringen, zorg, justitie, retail). Dit op eigen initiatief, ik ben ZZP-er en zit niet vast aan de spullen die bij het bedrijf waar ik werk worden gebruikt. Als je niet gewerkt hebt binnen een bepaald paradigma wordt het lastig oordelen erover: "As long as our hypothetical Blub programmer is looking down the power continuum, he knows he’s looking down. Languages less powerful than Blub are obviously less powerful, because they’re missing some feature he’s used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub." (http://www.smashcompany.c...e-disaster-which-must-end). Ik ben van mening dat de applicaties waaraan ik met mijn oude expertise heb gewerkt beter zouden kunnen worden gebouwd met een functionele taal in de backend. Wat ik wilde vinden is een taal waarmee ik efficient kan programmeren; recht op mijn doel afgaan zonder de franje en omwegen die object-orientatie afdwingen, geen "verbose" taal dus. Ook procedureel programmeren is mij veel te beperkt, nu ik andere mogelijkheden heb leren kennen. Bovendien wil ik gebruik kunnen maken van real-time mogelijkheden zoals bijvoorbeeld node.js biedt, alleen dan niet met javascript op de backend. Phoenix heeft daarvoor de "channels" die niet de nadelen hebben van node.js (http://joearms.github.io/...-and-Green-Callbacks.html). Ik wilde de mogelijkheid van concurrency eenvoudig kunnen gebruiken. Daarvoor is immutabilty (http://queue.acm.org/detail.cfm?id=2884038) nodig. Ooit was de beschikbaarheid van geheugen een probleem, om dit probleem zo klein mogelijk te maken werd gebruik gemaakt van de mogelijkheid telkens stukjes geheugen te wijzigen, waarmee echter concurrent programmeren lastiger werd. Dat heeft Wiebe-Marten (Qqwy) al aangestipt. Ook de mogelijkheden van relatief eenvoudig gedistribueerd werken (je applicatie over meerdere communicerende servers laten werken) is mooi als je zou willen opschalen. En dan is er nog de fault-tolerance waarin erlang / elixir excelleren, applicaties hebben een ongekend lage downtime. Erlang is geschreven met fault-tolerance als een van de belangrijkste use-cases, voor telecom systemen. Je wilt aan de telefoon gewoon door kunnen praten, zelfs terwijl er een software-update plaatsvindt (voor een demo met een drone waarbij terwijl hij vliegt zo'n update - van firmware in erlang - wordt gedaan zie YouTube: Drone In-flight Firmware Upgrade.
Mijn ervaring in gebruikersgroepen met OOP voorstanders in mijn oude expertise is merendeels die van discussies met harde werkers die erg hechten aan hun vertrouwde omgeving. Een beetje onvriendelijk gezegd:
"Proponents of OOP are arguing against reality itself, and they continue to do so, year after year, with an inflexibility that must have either non-rational or cynically financial sources. I’ve come to believe that OOP is now a “Zombie Idea”. I am borrowing the phrase from the economist Paul Krugman:
Zombie ideas — a phrase I originally saw in the context of myths about Canadian health care — are policy ideas that keep being killed by evidence, but nonetheless shamble relentlessly forward, essentially because they suit a political agenda." (http://www.smashcompany.c...e-disaster-which-must-end)
Uiteindelijk is mijn conclusie dezelfde als die van Dave Thomas: "I think there's no longer any debate, the future has to be functional, immutable data, and it has to be concurrent. It's the only way to grow." (http://www.drdobbs.com/ar...ption-of/240166688?pgno=3).

[Verwijderd]

BCC schreef op zondag 30 oktober 2016 @ 20:41:
De grote Rails shops in Nederland: Holder en Kabisa zijn beide erg actief in de Elixir community NL dus dat zegt wel wat over de toekomstige apps in NL.

Er is ook een meetup groep voor elixir: http://www.meetup.com/Amsterdam-Elixir/. Hier zijn regelmatig interessante presentaties, er loopt momenteel ook een workshop georganiseerd door kabisa. De meeste bezoekers zijn ook te vinden bij de rails meetup hoorde ik van een bezoekende RoR ontwikkelaar die graag met elixir / phoenix wil werken.

[Hydra]

Ik zit zelf 'in' het JVM ecosysteem en daar zie je een sterke adoption van in ieder geval een hoop FP paradigma's. Ik geloof ook zeker dat een tijdje werken met een functionele taal je een betere OO programmeur maakt. Met Java 8 en talen als Kotlin wordt geprobeerd een beetje het beste van 2 werelden te pakken.

Scala vind ik zelf erg cool om mee te werken (heb er niet professioneel mee gewerkt maar wel euler achtige dingen in gedaan) maar Scala is als taal bijna te krachtig: veel libraries misbruiken de mogelijkheden compleet eigen DSLs te bouwen.

In de big-data wereld waar veel problemen parallelisatie vereisen zie je dat functional programming en reactive programming flink populair zijn. In data-science clubs zijn talen als Scala al gemeengoed. Als je als dev in dit soort projecten mee wil draaien is ervaring met functionele talen een enorm pre. Als je dagelijks werk bestaat uit 't beheer van PHP CMSen, not so much.

[oeLangOetan]

Hydra schreef op maandag 31 oktober 2016 @ 10:50:
Scala vind ik zelf erg cool om mee te werken (heb er niet professioneel mee gewerkt maar wel euler achtige dingen in gedaan) maar Scala is als taal bijna te krachtig: veel libraries misbruiken de mogelijkheden compleet eigen DSLs te bouwen.

Als je je iets meer verdiept in FP concepten merk je snel dat Scala de enige JVM taal met statische types is die FP serieus neemt. Zonder goede ondersteuning voor type-classes, generieke pattern matching, higher-kinded types en monads is het moeilijk om de krachtige FP "patronen" te gebruiken.

Bij Java 9+ en Kotlin is FP er min of meer opgeplakt om de expressiviteit van de taal oppervlakkig te verbeteren. Bij Scala is het een fundamenteel deel van de taal. Het blijft wel een compromis van FP&OO, dus complexer dan Java en minder krachtig dan Haskell.

[MSalters]

Het grote probleem wat ik met Scala had, toe ik het rond 2009 eens probeerde, was dat het Hello, World voorbeeld simpelweg niet werkte. Als in, de toolchain weigerde een output te genereren, en gaf geen googlebare meldingen. Life's too short for that. Wat een taal succesvol maakt is niet de syntax of Turing completeness, maar de toolchain. Als ik nog eens naar een FP taal ga kijken, wordt het daarom F#. CLI is simpelweg een beter ondersteund ecosysteem.

[pedorus]

MSalters schreef op dinsdag 01 november 2016 @ 18:44:
Het grote probleem wat ik met Scala had, toe ik het rond 2009 eens probeerde, was dat het Hello, World voorbeeld simpelweg niet werkte. Als in, de toolchain weigerde een output te genereren, en gaf geen googlebare meldingen. Life's too short for that. Wat een taal succesvol maakt is niet de syntax of Turing completeness, maar de toolchain.

Tsja, mijn eerste ervaring met Scala was iets wat een collega had gemaakt.

Ik: Leuk, maar hoe build en run je dat?
Hij: sbt run
Ik: wow, het werkt in een keer

Als ik nog eens naar een FP taal ga kijken, wordt het daarom F#. CLI is simpelweg een beter ondersteund ecosysteem.

Hoe combineer je dat met iets als Spark dan? CLI is een vrij gebrekkig ecosysteem..

https://www.quora.com/Why...e-Spark-Storm-Flink-for-F

Dus als je dan de keuze hebt tussen Python (mooi, helaas untyped/traag), Java (verbose, geen type interference, exception mess) of Scala, dan weet ik mijn keuze wel.

[H!GHGuY]

Sinds enkele maanden werk ik met OCaml en het functioneel programmeren bevalt wel.

OCaml als taal is OK (F# leunt er nauw bij aan - niet omgekeerd), maar kent toch enkele beperkingen (single-threaded run-time maar er zijn 2 cooperative multi-threading libraries, optimalisaties kunnen ook nog wat beter hoewel flambda een behoorlijke stap vooruit is). Anderzijds doet de taal ook OO en imperatief programmeren (o.a. for/while loops en gewoon imperatief 'opsommen' )
Mar in realiteit is de nood voor OO en imperatief quasi nihil. De cases waarin je dit wil zijn gewoon zeldzaam en hier merk je ook dat inheritance eigenlijk een veel zeldzamere construct is dan waar het in OOP talen in de realiteit voor gebruikt wordt.

In theorie kunnen functionele talen harder geoptimaliseerd worden dan OOP, hoewel je merkt dat ook in bvb C++ ze hard proberen om de zaken die dit mogelijk maken (bvb constexpr functies) aan de spec toe te voegen.
De moeilijkheid bij C++ is dan weer dat const/constexpr niet de default zijn, wat in functionele talen typisch wel zo is. Ik denk dat dit de adoptie van fast-by-design code enorm beperkt.

De type inference en strong typing zijn ook een blessing. Geen gedoe met een int bij een long optellen en toekennen aan een double, met alle (potentieel: security) issues tot gevolg.
Anderzijds is de krachtige type inference soms ook een nadeel aangezien iemand die de code leest niet altijd weet welk type iets is.

1 van de fijne gevolgen is dat wanneer je code eindelijk compileert, je zo goed als zeker bent dat de mogelijk overgebleven bugs ook echte logica bugs zijn (i.e developer doet echt iets fout) en niet zomaar een issue ten gevolge van de taal mis te verstaan, bvb:

C++:

bool IsValid(enum some_type var) {
  switch(var) {
    st_1:
    st_2:
    st_3:
       return true
  }
  return false;
}

int value = read_int_from_file();
some_type e = (some_type)value;
if (!IsValid(e)) ...

(bovenstaand voorbeeld is uit de realiteit genomen...)

Een andere toffe feature (als gevolg van variants) is dat error-handling strongly typed kan gemaakt worden. Excepties zijn loosely typed (want alle excepties leiden af van 1 base) en de klassieke C/C++ integer error codes zijn al even los gedefinieerd. In FP talen kun je al gauw:

OCaml:

type module_a_errors =
  | error_1 of string
  | error_2 of int * string
  | error_3
  | error_4

... waarna je een error-type (bvb: (string, module_a_errors) Result.t) kunt maken die een string of een strongly typed error geeft. Je calling code is verplicht er iets mee te doen op een veelal slimmere manier dan in C/C++.

Ik ben alleszins overtuigd van het nut en de voordelen van FP talen. Ik kan maar toejuichen dat de principes in meer talen toegang vinden, al is retrofitten voor sommige talen misschien niet ideaal.

[bwerg]

H!GHGuY schreef op dinsdag 01 november 2016 @ 19:35:
1 van de fijne gevolgen is dat wanneer je code eindelijk compileert, je zo goed als zeker bent dat de mogelijk overgebleven bugs ook echte logica bugs zijn (i.e developer doet echt iets fout) en niet zomaar een issue ten gevolge van de taal mis te verstaan

Ik zit nu in haskell en python te programmeren, en daar zie ik dat inderdaad, tot in het uiterste: in python hack je er in 10 seconden iets in waarna je een runtime-exception krijgt omdat je een typo hebt gemaakt in je variabelenaam, in haskell ben je een half uur bezig met alle types aan elkaar knopen en als het eenmaal compileert dan werkt het meestal ook meteen zoals je bedoeld had.

Toen ik een beetje FP had gedaan was ik best enthousiast over het "FP" in Java 8, maar na een beetje heen en weer te schuiven tussen verschillende talen lijkt mij de FP van Java ongeveer net zo subtiel als de OO van C (met functies op structs heb je ook een soort objecten, toch? )

[ Voor 15% gewijzigd door bwerg op 01-11-2016 20:51 ]

[Rutix]

pedorus schreef op dinsdag 01 november 2016 @ 19:23:
[...]

Tsja, mijn eerste ervaring met Scala was iets wat een collega had gemaakt.

Ik: Leuk, maar hoe build en run je dat?
Hij: sbt run
Ik: wow, het werkt in een keer

Ik heb juist hele slechte ervaringen met de toolchains van Functionele Talen. Haskell was een drama een aantal jaren geleden en bij Scala vond ik het ook niet echt simpel om te beginnen. Dit is allemaal gebaseerd op ervaringen van een poosje terug dus wellicht dat het nu allemaal beter is hoor .

[b]pedorus schreef op dinsdag 01 november 2016 @ 19:23:
[...]

Hoe combineer je dat met iets als Spark dan? CLI is een vrij gebrekkig ecosysteem..

https://www.quora.com/Why...e-Spark-Storm-Flink-for-F

Dus als je dan de keuze hebt tussen Python (mooi, helaas untyped/traag), Java (verbose, geen type interference, exception mess) of Scala, dan weet ik mijn keuze wel.

Voor F# en C# heb je nu Prajna (http://msrccs.github.io/Prajna/index.html en https://github.com/MSRCCS/Prajna) wat een beetje het antwoord is op Spark.

[ Voor 20% gewijzigd door Rutix op 01-11-2016 22:17 ]

[pedorus]

Rutix schreef op dinsdag 01 november 2016 @ 22:15:
[...]

Ik heb juist hele slechte ervaringen met de toolchains van Functionele Talen. Haskell was een drama een aantal jaren geleden en bij Scala vond ik het ook niet echt simpel om te beginnen. Dit is allemaal gebaseerd op ervaringen van een poosje terug dus wellicht dat het nu allemaal beter is hoor .

Het moet ook niet te makkelijk worden he, anders komt er een stortvloed van programmeurs die je niet wil

JDK + Intellij + Scala plugin + SBT plugin werkend krijgen onder Windows kan al iets lastiger zijn.

Voor F# en C# heb je nu Prajna (http://msrccs.github.io/Prajna/index.html en https://github.com/MSRCCS/Prajna) wat een beetje het antwoord is op Spark.

Ziet er helaas meer uit als phd-ware:
https://github.com/MSRCCS/Prajna/graphs/contributors vs https://github.com/apache/spark/graphs/contributors

Dacht dat zelfs MS inzette op Spark + R bijvoorbeeld op dit moment.

[mulder]

Ik ben zelf ter lering en vermaak wat naar F# aan het kijken, ik ben eigenlijk nieuwsgierig geraakt doordat er enkele podcasts van http://www.dotnetrocks.com/ over F# gingen en gasten vaak erg enthousiast over de taal konden vertellen. Ook heeft uncle bob een presentatie over fp (YouTube: Robert C Martin - Functional Programming; What? Why? When? die mij meer en meer geïnteresseerd maakten. Ik heb verder geen ervaring met functioneel programmeren en heb verder ook nooit een informatica opleiding oid gedaan, ik ben van mening dat dit mijn kwaliteit als programmeur alleen maar goed kan doen.

Tja en nu nog de tijd ervoor vinden....

[Lethalis]

Ik vind functioneel programmeren zeker interessant.

Op mijn werk gebruik ik veel LINQ met C# en probeer ik me aan bepaalde functionele principes te houden, zoals dat een functie geen neveneffecten mag hebben.

Voor de rest heb ik nog gespeeld met Scala, Java 8, Kotlin en Haskell. Maar dat waren elke keer meer van die "hoe werkt het in deze taal" tests

Ik ben nog steeds van plan om een keer serieus Haskell te leren, but time is not on my side.

pedorus schreef op dinsdag 01 november 2016 @ 19:23:
[...]
Tsja, mijn eerste ervaring met Scala was iets wat een collega had gemaakt.

Ik: Leuk, maar hoe build en run je dat?
Hij: sbt run
Ik: wow, het werkt in een keer

Totdat je meerdere versies van de Scala runtime en SBT op 1 machine hebt staan. Dan gaat het tricky worden Als je bovendien ook het Play framework gebruikt, dan blijft er van dat "light weight" niks meer over. Er worden echt verschrikkelijk veel dependencies binnen gehaald.

Uiteindelijk ben ik voor mijn hobby projecten toen maar terug naar Java en Spring gegaan. KISS

Zodra .NET Core wat volwassener is, is het voor mij C# all the way denk ik. Het is alleen jammer dat er nog zoveel aan ontbreekt (csproj support, System.Drawing, System.Net.Mail, etc).

[ Voor 48% gewijzigd door Lethalis op 02-11-2016 14:34 ]

[Rutix]

pedorus schreef op woensdag 02 november 2016 @ 08:49:
[...]

Het moet ook niet te makkelijk worden he, anders komt er een stortvloed van programmeurs die je niet wil

JDK + Intellij + Scala plugin + SBT plugin werkend krijgen onder Windows kan al iets lastiger zijn.

[...]

Ziet er helaas meer uit als phd-ware:
https://github.com/MSRCCS/Prajna/graphs/contributors vs https://github.com/apache/spark/graphs/contributors

Dacht dat zelfs MS inzette op Spark + R bijvoorbeeld op dit moment.

Komt ook af van MSRCCS ( Microsoft Research: Cloud Computing and Storage ), dus misschien is "antwoord op" misschien te naive nog .

Lethalis schreef op woensdag 02 november 2016 @ 14:21:
Zodra .NET Core wat volwassener is, is het voor mij C# all the way denk ik. Het is alleen jammer dat er nog zoveel aan ontbreekt (csproj support, System.Drawing, System.Net.Mail, etc).

Beetje offtopic: Nu nog wel ze zijn in iedergeval hard aan het werk om al die support er netjes in te bouwen

[Swedish Clown]

bwerg schreef op dinsdag 01 november 2016 @ 20:49:
[...]

Ik zit nu in haskell en python te programmeren, en daar zie ik dat inderdaad, tot in het uiterste: in python hack je er in 10 seconden iets in waarna je een runtime-exception krijgt omdat je een typo hebt gemaakt in je variabelenaam, in haskell ben je een half uur bezig met alle types aan elkaar knopen en als het eenmaal compileert dan werkt het meestal ook meteen zoals je bedoeld had.

Erlang FTW! Let it crash! Als de dev het ergens goed verkloot en het wordt niet afgevangen in de tests gaat dat proces ergens op z'n bek en lossen we het via een hot code upgrade wel op

Ik werk nu een jaar fulltime met Erlang en moet zeggen dat Pattern Matching, hot code upgrades, de "let it crash"-mentaliteit en de Erlang shell mij het meeste aanspreken.

Door middel van goed gebruik te maken van Pattern Matching wordt je code zoveel cleaner en makkelijker te volgen. Gaat het ergens op z'n bek vanwege een missende function clause, hot code upgrade en doorgaan. Wij doen dan ook nooit reverts maar enkel rolling forward upgrades. Ideaal!

Vanuit een LiveOps perspectief is de Erlang shell een geweldige tool! Wij kunnen data changes, config changes en live schoon verzoeken doen en hop zo de shell in en gaan! Op onze replica kunnen we door middel van Redbug live het systeem debuggen indien het nodig is en direct actie ondernemen.

Ik wil niet meer terug!

Er zijn binnen Erlang zeker nadelen met name t.a.v de tooling maar daar valt redelijk makkelijk omheen te werken. Open Sources is i.v.m. andere talen een drama maar dat geeft tevens een hoop ruimte voor optimalisaties binnen ons systeem.

[Bigs]

@Brakkie41 wat vinden jullie als Erlang gebruikers nu van Elixir? Elixir lijkt best veel mensen aan te trekken uit o.a. de Ruby wereld, maar ik heb het idee dat Erlang ontwikkelaars er niet echt warm voor lopen.

Misschien voegt Elixir ook niet zoveel toe als je al aan de Erlang syntax gewend bent…

[Swedish Clown]

Bigs schreef op woensdag 02 november 2016 @ 20:49:
@Brakkie41 wat vinden jullie als Erlang gebruikers nu van Elixir? Elixir lijkt best veel mensen aan te trekken uit o.a. de Ruby wereld, maar ik heb het idee dat Erlang ontwikkelaars er niet echt warm voor lopen.

Misschien voegt Elixir ook niet zoveel toe als je al aan de Erlang syntax gewend bent…

Ik loop er inderdaad niet warm voor. Heb er even mee gespeeld maar het voelt voor mij niet production-ready. Er gebeurt nog teveel in Elixer IMHO. Ondanks dat er langzaamaan meer Elixer projecten komen en het een en ander stabiliseert voelt het nog erg "jong". Maar dat lijkt hip te zijn tegenwoordig om met jonge technologie te werken om even hard over te komen

Er wordt mee "gespeeld" vanuit andere teams aangezien de EVM bij ons goed bekend is maar productie is er bij lange na nog niet. Met name Ruby teams tonen interesse in Elixer en dat is een trend wat ik veel zie.

Wel tof om te zien dat de Erlang User Conference in Stockholm dit jaar ook in het teken van Elixer stond! Jong en er werden veel grappen over gemaakt maar de aandacht is er zeker!

[mindcrash]

Rutix schreef op dinsdag 01 november 2016 @ 22:15:
Voor F# en C# heb je nu Prajna (http://msrccs.github.io/Prajna/index.html en https://github.com/MSRCCS/Prajna) wat een beetje het antwoord is op Spark.

Microsoft ondersteund Spark in C# en F# via Mobius. Maar als je een 100% .NET native Spark-like oplossing wil hebben, en toegang hebt tot Azure of AWS zou ik ook zeker even naar MBrace kijken, wat ook in het wild wordt uitgerold.

[Verwijderd]

Als ik naar de voordelen van de BEAM vm kijk wat Erlang en Elixir gebruik van maakt zie ik toch gave toepassingen ook in de industrie!
Volgens wiki:

• Distributed
• Fault-tolerant
• Soft real-time,
• Highly available, non-stop applications
• Hot swapping, where code can be changed without stopping a system.

Ja sommige dingen kun je ook in andere talen. Maar het is niet de basis uitgangspunt, en daardoor vaak veel lastiger te bereiken.

Veel van deze onderwerpen worden de laatste tijd steeds belangrijker wanneer je verticaal en horizontaal wil schalen. En ik zit in de industrie waarbij bepaalde systemen ook met hotswappable code kan vervangen. En geloof me, dat is zoo handig. Je applicatie of machine draait gewoon, en je update even bepaalde delen van de code. En je hebt geen downtime! En geloof me, in sommige systemen is dat gewoon killing.
Tevens soft-realtime. Ik zou willen dat er ook een vorm van hard-realtime was op een bepaalde manier door bijvoorbeeld Linux met een RT patch. Dat zou het helemaal compleet maken voor mij.

Tevens is fout tollerantie en high availability e.d. ook zeer belangrijk. En ik denk dat dit allemaal ook ten goede komt voor back ends voor websites. Al deze punten zijn denk ik van belang voor back-ends. Daar wil je ook geen downtime hebben bij grote webshops bijvoorbeeld.

Ik snap niet dat mensen hier niet de voordelen van in zien. En ik ben een noob in dit soort zaken.
Ik zie inderdaad mensen in OO talen distributed systemen zitten te programmeren en zitten te kloten met threading en locks. Daar krijg je toch hoofdpijn van?

Tevens omdat alles functioneel is lijkt het me ook makkelijk te unit testen en te debuggen... maar of dat ook zo is weet ik niet zeker hierbij. Dat is gewoon puur gevoel, maar wie ben ik.. ik heb der geen verstand echt van.

[technorabilia]

Wat ik mooi vind is dat Erlang uit 1986 stamt. En nu zo goed aansluit bij de huidige stand van techniek. Fantastisch.

Verwijderd schreef op zaterdag 05 november 2016 @ 14:36:
Tevens omdat alles functioneel is lijkt het me ook makkelijk te unit testen en te debuggen... maar of dat ook zo is weet ik niet zeker hierbij. Dat is gewoon puur gevoel, maar wie ben ik.. ik heb der geen verstand echt van.

Dat lijkt mij ook. input |> function |> output.
Kan iemand hier iets over zeggen? Praktijkervaring? TDD mogelijk zonder de developer te kwellen?

[ Voor 67% gewijzigd door technorabilia op 05-11-2016 19:38 . Reden: Typo ]

[FRidh]

Sinds ongeveer een jaar draai ik het NixOS operating system wat gebaseerd is op de Nix package manager, waarbij pakketten worden gebouwd volgens expressies geschreven in de functionele programmeertaal Nix. Bij NixOS worden niet alleen de pakketten maar ook de services beschreven middels de Nix taal. Het was even wennen, aangezien dit compleet anders is dan andere OS's, maar het werkt geweldig.

Tot dan was ik niet echt bekend met FP (zelf gebruik ik als wetenschapper voornamelijk Python) maar ik was al enige tijd benieuwd naar Haskell, en nu ik bekend ben met Nix wil ik binnenkort toch echt eens aan de gang gaan met Haskell. Voor de soort simulaties die ik doe (audio-gerelateerd) zijn ook domein-specifieke talen zoals Faust (FP) en SuperCollider (OO) maar die zijn net ietwat te gelimiteerd. Een generieke taal zoals Haskell lijkt me dan een betere uitkomst.

Rutix schreef op dinsdag 01 november 2016 @ 22:15:
[...]

Ik heb juist hele slechte ervaringen met de toolchains van Functionele Talen. Haskell was een drama een aantal jaren geleden en bij Scala vond ik het ook niet echt simpel om te beginnen. Dit is allemaal gebaseerd op ervaringen van een poosje terug dus wellicht dat het nu allemaal beter is hoor .

Hoe GHC wordt gebouwd is ook best wel interessant aangezien het in Haskell zelf is geschreven. Bij NixOS moet je, als je de laatste versie van GHC wilt hebben, volgens mij eerst twee oudere versies bouwen, waarbij de eerste daarvan een binary blob gebruikt

[Qqwy]

Bigs schreef op woensdag 02 november 2016 @ 20:49:
@Brakkie41 wat vinden jullie als Erlang gebruikers nu van Elixir? Elixir lijkt best veel mensen aan te trekken uit o.a. de Ruby wereld, maar ik heb het idee dat Erlang ontwikkelaars er niet echt warm voor lopen.

Misschien voegt Elixir ook niet zoveel toe als je al aan de Erlang syntax gewend bent…

Ik ben zelf ook geen langetijds Erlang-gebruiker (ik ben het gaan leren via Elixir), maar heb nu al wel bijna een jaar ervaring met Elixir. De drie grote voordelen die Elixir heeft over Erlang zijn:

1) Metaprogramming. Je kunt functies schrijven die als input de nog niet geëvalueerde AST(Abstract Syntax Tree, in andere woorden de broncode) nemen. Hierdoor kun je erg gemakkelijk Domain Specific Languages toevoegen, en zijn ook projecten zoals de Unicode-support in Elixir ingebouwd: Dit is een lijst van functie-varianten die niet handmatig is opgeschreven, maar gedefineerd wordt door een macro die intern textbestanden met de Unicoderegels leest.

2) Er zijn een aantal dingen in Erlang die om backwards-compatibility redenen 'raar' zijn. Elixir probeert, waar mogelijk, zich hier niet door te laten beïnvloeden. Een belangrijk voorbeeld waar ik nu snel op kom is bijvoorbeeld het verschil tussen Erlang strings (linked lists gevuld met characters; dit kost dus vier bytes per char) en binaries (een blob; gewoon een array van bytes dus.).
Veel Erlangfuncties verwachten nog steeds de argumenten als 'strings', terwijl, vanwege bijvoorbeeld unicode-compatibiliteit, het veel beter zou zijn als er zo veel mogelijk met binaries gewerkt wordt. Elixir probeert dit te doen.

3) First-class documentation. Zowel Elixir zelf als de meeste veelgebruikte libraries hebben de beste en uitgebreidste documentatie die ik ooit heb gezien. De bovengenoemde metaprogramming zorgt er daarnaast voor dat je zogenaamde 'doctests' kunt schrijven, die zowel een mooi voorbeeld in de documentatie zijn, alswel een regressietest: zodra de output van de uitgevoerde code niet meer overeenkomt met wat je in het voorbeeld zei, zal Elixir je hiervan op de hoogte brengen.
Documentatie is geschreven in (Github-Flavoured) Markdown, en dit maakt de code erg toegankelijk. Omdat de huidige community al zo'n grote waarde hecht aan goede documentatie zie je dat nieuwe mensen dit overnemen, en dat is erg mooi om te zien :-).

---

quote: Texamicz

Tevens omdat alles functioneel is lijkt het me ook makkelijk te unit testen en te debuggen... maar of dat ook zo is weet ik niet zeker hierbij. Dat is gewoon puur gevoel, maar wie ben ik.. ik heb der geen verstand echt van.

Functionele programmas zijn makkelijker te debuggen en te refactoren omdat je niet bang hoeft te zijn dat je
onder water ergens staat aanpast. In andere woorden: De volledige context van een lap code is de functie waar die in staat. In een OOP-taal dien je rekening te houden met alle globale objecten, het huidige object waar de huidige function(of correcter: method) een deel van uitmaakt, en bij welke informatie van elders je op dit moment invloed kunt uitoefenen.

Dus: Ja, functionele talen zijn inderdaad makkelijker te refactoren en te debuggen.


Aan de andere kant is het wel mogelijk om, als je iets bedrevener wordt in bijv. Haskell, code te schrijven die voor iemand die nog niet zo ver is onmogelijk is om te lezen: The Evolution of a Haskell Programmer...

---

Over Test-Driven Development:

Ik heb het gevoel dat in de huidige wereld er vaak aan het oorspronkelijke concept van TDD voorbijgegaan wordt. '100% coverage' is ongeveer net zo'n slechte indicatie van code-kwaliteit als dat 'regels code geschreven' een indicatie is van programmeur-skill. Coverage zegt namelijk niks over of je de edge cases wel of niet benoemd hebt in je tests.

Het belangrijke doel van TDD is, in mijn opzicht, dat je eerst probeert het probleem zo duidelijk mogelijk te formuleren, zodat je daarna zeker weet dat de code die je schrijft ook daadwerkelijk dat probleem (volledig) oplost.
En wanneer dit gelukt is kunnen deze tests vervolgens regressie voorkomen.
Het is mij op de werkvloer helaas al meerdere keren overkomen dat er meer dan honderd tests waren die verouderde aspecten van de code controleerden. Te veel tests maakt het erg moeilijk om je code snel uit te breiden. Ergens is een gouden middenweg.

Ik ben nu bezig een boek te lezen over de programmeertaal Idris, die dependently typed is. Dat houdt in dat je types van objecten 'uit kunt rekenen', en vervolgens kun je in feite wiskundige bewijzen over je code loslaten, omdat je zeker weet dat bepaalde dingen waar zijn. Een voorbeeld (schaamteloos van de engelse wikipediapagina geplukt): 'Een paar van twee integers' is een type. "Een paar van twee integers waar de rechter groter is dan de linker" is een dependent type.
Op het moment dat ik dat type gebruik weet ik dus zeker dat het nooit voor zal komen dat ik een paar van waarden heb waar de rechterwaarde kleiner is. Wanneer je dan wel ergens bijv. per ongeluk dit omdraait, zal de compiler schreeuwen dat wat je probeert te doen niet klopt met het type. Op die manier kun je dus heel veel (in theorie alle) bugs oplossen.

Heel interessant, maar ook best wel even wennen .

[bwerg]

Qqwy schreef op zondag 06 november 2016 @ 15:29:
'100% coverage' is ongeveer net zo'n slechte indicatie van code-kwaliteit als dat 'regels code geschreven' een indicatie is van programmeur-skill. Coverage zegt namelijk niks over of je de edge cases wel of niet benoemd hebt in je tests.

offtopic:
Ik zag laatst een presentatie van iemand die onderzoek had gedaan naar wat de gangbare maten van code coverage nou echt zeggen over de kwaliteit van tests. Hij nam wat open-source projecten met unit tests, bekeek de code coverage van die tests, en de kwaliteit ervan. Er was één project dat 80+% coverage haalde, maar als hij gewoon willekeurige methodes leeghaalde (alle code weggooien en return null o.i.d. in de plaats, dat werd nooit door de tests ontdekt...

[Verwijderd]

Voor wat betreft tdd en unit testen kunnen jullie hier nog wat info uit halen: https://elixirforum.com/t/bdd-tdd-criticized/759

[Verwijderd]

Maar kan iemand ook vertellen waarom Functioneel programmeren dan weer helemaal "hot" is? Terwijl het eigenlijk al heel oud is.

Heeft dat te maken met functioneel programmeren gewoon heel netjes aansluit op de huidige tijdperk?
Ik zelf denk namelijk dat het komt doordat er steeds meer computers moeten samenwerken, meerdere cores en threading belangrijker worden. Is dat het enige? Of zijn er meer dingen waarom het populair begint te worden?

Ik zelf zat al met bewondering te kijken naar RiakDB en hoe ze dat zo mooi voor elkaar krijgen. Blijkt dus dat onderliggend gewoon Erlang gebruikt is.

Een mooie webstack die ik wel voor me zie is: RiakDB - Elixir - Phoenix - ELM maar ik kan nergens een mooie voorbeeld met deze stack vinden.

[BCC]

Ja en verder is (zoals al gezegd) het eenvoudiger om robustere programma's ter schrijven omdat je eingenlijk altijd gedwongen wordt om de excepion cases fatsoenlijk af te handelen. Daarnaast is de ingebouwde monitoring ook erg handig.

En RiakDB voegt weinig toe als je Elixir en Phoenix draait imho.

[Bigs]

Functioneel programmeren past zeker bij deze tijd. Ik werk zelf uitsluitend aan web applicaties (server side). Daar is elk request in principe een functie die een HTTP verzoek transformeert naar een antwoord. Dus ja, dan spreekt het voor zich dat FP zich goed leent voor die problemen

[Swedish Clown]

BCC schreef op woensdag 09 november 2016 @ 08:59:
Ja en verder is (zoals al gezegd) het eenvoudiger om robustere programma's ter schrijven omdat je eingenlijk altijd gedwongen wordt om de excepion cases fatsoenlijk af te handelen.

[...]

Niet helemaal waar, zeker in Erlang niet. (Met Haskell weinig ervaring maar die schijnen een stuk strikter te zijn). In Erlang is het heel normaal om exception/edge-cases te laten liggen en in een dergelijk geval de boel te laten crashen.

Erlang:

SomeUserId = proplists:get_value(some_user_id, UserIds),
SomeUser = users:read_d(SomeUserId).

In het geval dat some_user_id niet geset is in je proplist van UserIds en je dus undefined terugkrijgt, is het heel acceptabel om je read_d te laten crashen. Net als wanneer de UserId=<<"Brakkie41">> niet bestaat.

Het is even wennen maar dergelijke situaties niet afvangen mar de boel op ze bek te laten gaan is een enorm fijne manier van werken en zorg niet alleen voor nette code, het zorgt tevens voor code welke impliciet aan een bepaalde set condities voldoet zonder elk van deze condities expliciet te hoeven checken.

Bigs schreef op woensdag 09 november 2016 @ 09:06:
Functioneel programmeren past zeker bij deze tijd. Ik werk zelf uitsluitend aan web applicaties (server side). Daar is elk request in principe een functie die een HTTP verzoek transformeert naar een antwoord. Dus ja, dan spreekt het voor zich dat FP zich goed leent voor die problemen

Wat is de webserver stack waar jullie op draaien? Yaws?

[Qqwy]

@Brakkie41: Misschien wel goed om hierbij te vermelden dat wanneer een Erlanger of Elixirist 'let it Crash' zegt, dat dat dan absoluut niet 'let it Burn' betekent.

Het idee is om in plaats van te veel tijd te besteden aan het voorkomen van uitzonderingsgevallen (en je zult zien dat je er altijd een paar mist, vanwege het fenomeen Hindenbug; hoe onderdelen van complexe systemen elkaar beïnvloeden is nagenoeg onmogelijk perfect te voorspellen.), dat er tijd word besteed aan hoe te zorgen dat wanneer een uitzonderingssituatie plaatsvind, de impact voor de rest van het systeem zo klein mogelijk blijft, en het systeem zichzelf weer herstelt naar een correcte staat. Hiermee heb je zowel de je bekende edge cases, en de nog onbekende edge cases afgevangen.

Dit is wat er bedoeld wordt met 'fault-tolerance', en is waarom sommige van deze applicaties jaren kunnen lopen zonder ooit offline te (hoeven) gaan.

[P_Tingen]

Verwijderd schreef op woensdag 09 november 2016 @ 04:27:
Maar kan iemand ook vertellen waarom Functioneel programmeren dan weer helemaal "hot" is? Terwijl het eigenlijk al heel oud is.

Heeft dat te maken met functioneel programmeren gewoon heel netjes aansluit op de huidige tijdperk?
Ik zelf denk namelijk dat het komt doordat er steeds meer computers moeten samenwerken, meerdere cores en threading belangrijker worden.

Dit, en dat functioneel programmeren stateless is. Dit maakt het - in ieder geval in theorie - gemakkelijker om een proces te parallelliseren. Omdat cpu's niet persé steeds sneller worden maar wel steeds meer cores gaan bevatten is het behalen van een hogere performance gemakkelijker te bereiken via parallelle processen. Als je afhankelijk bent van state, zoals veel talen, dan wordt dat een stuk lastiger omdat je dan extra communicatie nodig hebt tussen de cores.

Ik heb zelf geen ervaring met functionele talen, ik kom net als minimaal 2 andere leden in deze discussie uit de Progress 4GL wereld. Dat is een databasetaal die zeker niet functioneel is (als in: functionele taal). Wel kun je daarin op slechte en goede manieren programmeren, net als in vele andere talen. Door functies en procedures zoveel als mogelijk stateless te maken, heb ik al veel problemen kunnen oplossen. De meeste bugs die ik tegenkom in de programmatuur hebben te maken met niet netjes programmeren, zodat het in sommige gevallen (lees: bij bepaalde 'states') mis gaat. Het verbaast me dan ook niet dat functioneel programmeren hot is. Het nodigt kennelijk wat meer uit / dwingt meer af om netjes te programmeren.

[Caelorum]

P_Tingen schreef op zaterdag 12 november 2016 @ 19:55:
[...] Door functies en procedures zoveel als mogelijk stateless te maken, heb ik al veel problemen kunnen oplossen. De meeste bugs die ik tegenkom in de programmatuur hebben te maken met niet netjes programmeren, zodat het in sommige gevallen (lees: bij bepaalde 'states') mis gaat. Het verbaast me dan ook niet dat functioneel programmeren hot is. Het nodigt kennelijk wat meer uit / dwingt meer af om netjes te programmeren.

Mwoah, ik ben nu met elixir bezig en ik zie daar wel mogelijkheden om alsnog state bij te houden. Functionele talen op zichzelf zijn daar nou niet perse beter in. Dat aan de functies zelf altijd alle variabelen worden meegegeven waarop ze opereren wordt wel beter geforceerd dan in de meeste andere talen, maar is niet perse uniek aan functionele talen.
Zelf ben ik van een imperative taal naar OOP talen gegaan. Na daar nu een kleine 10 jaar rond te hebben gehangen ga ik voor privé projecten maar eens het komende jaar alleen maar functionele talen gebruiken. Eens zien hoe goed dat werkt ^^ Tot nu toe ben ik redelijk gecharmeerd van Elixir en zie ik wel voordelen in deze aanpak, maar zie ook wat nadelen tov talen als C# en Java (maar dat kan mijn huidige OOP mindset nog zijn)

[technorabilia]

Welke nadelen zijn dat dan?

[Caelorum]

Mja, soms wil je state even tijdelijk ergens opslaan om er later weer mee aan de slag te gaan. In een ideale wereld zou je die state de hele tijd door kunnen geven van functie naar functie, maar dan moet je op een gegeven moment zoveel bijhouden dat het gewoon niet meer te doen is. In Elixir is het dan zviw de bedoeling om een process te starten dat functioneert als een in-memory datastore. Dit soort state bijhouden lijkt in bijv. C# of c++ een stuk eenvoudiger te realiseren.
Dat ik nu nadelen zie zegt overigens nog niet veel hoor. Ik ben er nu net een week mee bezig en ik verwacht dat ik in de komende maanden en aan het eind van het jaar nog wel van mening kan veranderen Ik zag namelijk in het begin ook niet heel veel voordelen in OOP..

Ik mis overigens ook nog wel een goede IDE voor elixir.

[technorabilia]

GenServer heeft veel meer functionaliteit. Je kunt de Agent module goed hiervoor gebruiken.

Spacemacs/Alchemist en de IntelliJ plugin ziet er wel aardig uit. Maar ik ben ook slechts een beginner.

[Verwijderd]

Mijns inziens is het de wijze van omgang met geheugen in een systeem die functionele talen een voordeel geeft. Die wijze is anders dan in een imperatieve taal. Een van die voordelen is dat het foutloos gelijktijdig laten uitvoeren van instructies gemakkelijker wordt. En dat is tegenwoordig van belang omdat zoals anderen al schreven performance- en schaalbaarheid winsten kunnen worden gehaald uit het gebruik maken van de groeiende aantallen cores in processoren. Wat het omhooggaan van de kloksnelheid betreft is de "gratis lunch" is voorbij: http://www.gotw.ca/publications/concurrency-ddj.htm
In een functionele taal is wordt gebruik gemaakt van niet-wijzigbare datastructuren. Eigenlijk is de naam variabele in een functionele taal bedrieglijk. Uiteraard heb je binnen de taal wel te maken met een buitenwereld, die met wijzigbare datastructuren werkt: je zult bijvoorbeeld naar bestanden moeten schrijven, of naar een traditionele database (er is overigens tenminste één database die niet met wijzigbare datastructuren werkt: datomic).
Als je naar stukjes elixir code kijkt kan het lijken alsof je wel degelijk te maken hebt met wijzigbare datastructuren. Zo kun je tegenkomen
a = 1
a = 2
Er zijn nu echter twee verschillende geheugenadressen gebruikt, het label "a" verwijst na de laatste declaratie naar de toestand op het tweede adres. Bij een niet-functionele taal declareer je een variabele waarvoor het benodigde aantal geheugenadressen worden gereserveerd. De naam van de variabele verwijst naar die adressen. Als nu de bovenstaande code uitgevoerd wordt na de declaratie van a dan worden dezelfde geheugenadressen herbruikt. Het geheugen op die adressen wordt gemuteerd.
Hetzelfde geldt in elixir voor agents en genservers, deze maken gebruik van niet wijzigbare datastructuren. Agents en genservers zijn beide genserver processen (geen os processen maar licht gewicht "green threads") die, als ze gestart zijn, in de wacht gaan staan voor berichten. Als er bij dat bericht data moeten worden weggeschreven dan wordt gebruik gemaakt van niet wijzigbare datastructuren. Uiteraard zijn deze data middels andere berichten weer te lezen.
Nog een interessant stuk, "immutability changes everything" (er zijn zelfs filesystemen die werken met niet-wijzigbare data als het Google File System):
http://cidrdb.org/cidr2015/Papers/CIDR15_Paper16.pdf
En nog een van Rich Hickey: http://clojure.org/about/state .Bij zijn redenen om niet gebruik te maken van het actor model in clojure valt wel het een en ander op te merken: https://elixirforum.com/t...he-play-framework/1504/14

[ Voor 6% gewijzigd door Verwijderd op 13-11-2016 14:18 ]

[Verwijderd]

Volgens mij is het enige grote nadeel aan functioneel programmeren is dat wanneer je OO talen gewend bent je mindset helemaal moet omgooien. En dat is voor veel mensen een behoorlijke investering, vooral als je wat ouder bent. Leeftijd zorgt er gewoon voor dat je hersens minder kunnen leren.

De meeste kritiek komt dan vaak ook uit de hoek van mensen die OO gewend zijn en zich er waarschijnlijk nooit echt in verdiept hebben.

Ik heb in dit draadje nog geen enkele nadeel gehoord wat met iets anders te maken heeft dan "mindset". Of kan iemand toch wat zwaar negatieve dingen opnoemen?
We worden op school eigenlijk al geïndoctrineerd met OO talen. Juist omdat het zo makkelijk te reflecteren is op de werkelijke wereld. Denk aan een class als voertuig (Auto's, vrachtwagens enz enz OOP 101). Makkelijk te leren aan mensen met voorwerpen die je dagelijks gebruikt. Maar dit betekend nog niet dat het voor de computer ook goed is. Mensen zijn geen computers.

Doordat je met erlang/elixir werkt met het actor model kun je dus elke actor zijn eigen process geven(Dit is geen OS process maar een beam vm process welke in de gaten wordt gehouden) Door de actor model kun je dus message passing doen tussen verschillende processen.
Als iets faalt, herstart je het en wordt de fout gerapporteerd. Fix je deze bug en kan je tijdens het runnen gewoon je code updaten zonder dat je hele server plat hoeft! Gewoon online. Gaaf toch? Dit heeft dan weer niks te maken met functioneel programmeren maar wel met Erlang/Elixir en de BEAM vm.

Elixir is niet beter als Erlang, het zorgt er alleen voor dat het makkelijk is in te stappen en de documentatie is gewoon super. Daarnaast draait het om het ecosysteem en dus een beetje hypen helpt om de package management een beetje te vullen met handige libraries en frameworks waar er gewoon niet veel van zijn. (HEX)

Elixir probeert het oude stoffige imago van Erlang op te krikken terwijl Erlang eigenlijk hele mooie techniek heeft. Men weet ook wel dat een goed product ook niet goed kan ontvangen worden wanneer de marketing niet helemaal hip is. Dit is de bedoeling van Elixir. Denk dat de Ruby community straks met z'n allen naar Elixir gaat rennen en daar de community gaat verstevigen en de HEX package manager lekker gaat aanvullen met moderne technologie bovenop Elixir.

En als je kijkt naar populaire bedrijven die vertrouwen op Erlang en de BEAM vm zijn dat er best veel. Ook al hoor je er niet veel over, ze zijn er en gebruiken gigantisch veel clients. Ze komen allemaal uit bij Erlang.
Denk aan Whatsapp, en games met veel clients zoals Legue of Legends?
Elixir zorgt ervoor dat het toegankelijker zal worden. Maar steeds meer online game platforms gebruiken Erlang ook.

[ Voor 8% gewijzigd door Verwijderd op 13-11-2016 15:53 ]

[Verwijderd]

Dat omgooien van je mindset valt mee, is mijn ervaring. Ik ben in januari begonnen, ik ben nu 54. Ook iemand als Dave Thomas is pas laat begonnen met functioneel programmeren denk ik. Hij ziet elixir voor zichzelf als een soort verjongingsdrank (niet schrikken als je de titel van dit filmpje ziet, haha): YouTube: YOW! 2015 - Dave Thomas - Rigor Mortis (Avoiding). De weerstand die je ziet komt vaak voort uit vooroordelen en conservatisme. Behoudzucht is op zich niet moeilijk te verklaren.
Veel kennis uit procedureel / oo programmeren kun je blijven gebruiken. Gelukkig kun je ook veel moeilijk gedoe achter laten.
Het is ook goed om te weten - wat de vooroordelen die ik gezien heb betreft - dat je niet alleen voor veel programmeurs "exotische" (en dus nutteloze ;-) dingen kunt bouwen als games / chatapplicaties (realtime dingen) en weet ik wat, maar ook "doodgewone" administratieve applicaties. Waarbij je dan ook nog eens op een eenvoudige manier gebruik kunt maken van al die extra mogelijkheden / voordelen. Een en ander is daarbij dan ook nog eens uitzonderlijk bedrijfszeker. Daar staat de erlang VM bekend om.

[ Voor 37% gewijzigd door Verwijderd op 13-11-2016 20:03 ]

[juanita]

Ja hier ook iemand die enthousiast is over functioneel programmeren. Op de universiteit een cursus Haskell gevolgd en bij mijn vorige baan ben ik door toeval weer met FP in contact gekomen. Bij mijn huidige werkgever werk ik veel in Python maar ook daarin kan je goed FP. List comprehension helpt hierbij enorm.

FP is af en toe een beetje puzzelen, maar dat maakt het naar mijn mening veel leuker. Daarnaast denk ik dat je robuustere code krijgt die bovendien veel makkelijker te debuggen is. Ook geen onbelangrijke aspecten.

Het is alleen jammer dat er zo weinig banen in te vinden zijn. Mijn vorige werkgever wist niet eens dat ze aan FP deden. Als iemand daarom nog wast suggesties kan doen, dan hou ik me aanbevolen. Erlang lijkt me wel mooi, maar ja, waar vind je dat nou? Misschien maar eens naar Zweden verhuizen.

Het enige nadeel wat ik kan bedenken bij FP zijn geneste if-then-else constructies.

[ Voor 5% gewijzigd door juanita op 04-01-2017 21:56 ]

[Swedish Clown]

juanita schreef op woensdag 4 januari 2017 @ 21:15:
Het is alleen jammer dat er zo weinig banen in te vinden zijn. Mijn vorige werkgever wist niet eens dat ze aan FP deden. Als iemand daarom nog wast suggesties kan doen, dan hou ik me aanbevolen. Erlang lijkt me wel mooi, maar ja, waar vind je dat nou? Misschien maar eens naar Zweden verhuizen.

Het enige nadeel wat ik kan bedenken bij FP zijn geneste if-then-else constructies.

Er is genoeg werk te vinden hoor in de Erlang of Elixer wereld Ericsson, Nokia, T-Mobile, Heroku, Amazon, Whatsapp, CouchDB, Riak, RabbitMQ, Klarna en Bet365 om maar even een paar van de grotere namen te noemen. Ik zit in het centrum van Stockholm en binnen een straal van 1km zitten hier 3 bedrijven die met Erlang en Elixer bezig zijn.

Indien je een contactpersoon zoekt, ik ben bekend met een hele goede recruiter (Ja ze bestaan! ) die nagenoeg enkel Erlang en Elixer werk regelt.

[justVR]

Brakkie41 schreef op donderdag 5 januari 2017 @ 12:53:
[...]


Er is genoeg werk te vinden hoor in de Erlang of Elixer wereld

Goed om te horen! Hoe zit dat met scala?

[Swedish Clown]

justVR schreef op donderdag 5 januari 2017 @ 17:08:
[...]

Goed om te horen! Hoe zit dat met scala?

Durf ik niet te zeggen. Wij hebben hier een man of 15 rondlopen die in Scala ontwikkelen. Hoe dat verder in de "scala-wereld" zit heb ik geen kijk op. Ik zou eens voor je kunnen rondvragen.

[juanita]

Brakkie41 schreef op donderdag 5 januari 2017 @ 12:53:
[...]


Er is genoeg werk te vinden hoor in de Erlang of Elixer wereld Ericsson, Nokia, T-Mobile, Heroku, Amazon, Whatsapp, CouchDB, Riak, RabbitMQ, Klarna en Bet365 om maar even een paar van de grotere namen te noemen. Ik zit in het centrum van Stockholm en binnen een straal van 1km zitten hier 3 bedrijven die met Erlang en Elixer bezig zijn.

Indien je een contactpersoon zoekt, ik ben bekend met een hele goede recruiter (Ja ze bestaan! ) die nagenoeg enkel Erlang en Elixer werk regelt.

Dank je, goed om te horen. Ik zat echter eigenlijk meer aan Nederland zelf te denken voor op dit moment.

[Swedish Clown]

juanita schreef op donderdag 5 januari 2017 @ 21:27:
[...]


Dank je, goed om te horen. Ik zat echter eigenlijk meer aan Nederland zelf te denken voor op dit moment.

Dat snap ik, ik wilde enkel aangeven dat er genoeg bedrijven zijn die in Erlang/Elixer ontwikkelen. Ik heb met name zicht op hoe dat er hier aan toe gaat en heb niet veel kennis van hoe het er in Nederland voor staat. Ik ga eens rondsnuffelen want wie weet kom ik op een gegeven moment weer terug naar Nederland

[juanita]

Om even aan te haken op een eerdere reactie in deze thread, ik durf eveneens wel te bevestigen dat FP zich uitstekend leent voor administratieve klussen. Bij dit soort klussen is het toch vaak data van de ene vorm omzetten naar een andere vorm volgens voorgeschreven richtlijnen. Denk dat hier echt kansen liggen.

[ Voor 5% gewijzigd door juanita op 06-01-2017 09:23 ]

[justVR]

Brakkie41 schreef op donderdag 5 januari 2017 @ 18:04:
[...]
Durf ik niet te zeggen. Wij hebben hier een man of 15 rondlopen die in Scala ontwikkelen. Hoe dat verder in de "scala-wereld" zit heb ik geen kijk op. Ik zou eens voor je kunnen rondvragen.

Dank! Het punt is dat ik voornemens ben (als C# developer) mij flink te gaan verdiepen in FP. Buiten het leren van algemene aspecten van een FP taal, wil ik mij richten op 1 specifieke taal. Ik neig op dit moment naar Elixir, maar weet niet hoe die taal zich qua populariteit/potentie verhoud tot andere FP talen.

[Bigs]

justVR schreef op vrijdag 6 januari 2017 @ 10:36:
[...]


Dank! Het punt is dat ik voornemens ben (als C# developer) mij flink te gaan verdiepen in FP. Buiten het leren van algemene aspecten van een FP taal, wil ik mij richten op 1 specifieke taal. Ik neig op dit moment naar Elixir, maar weet niet hoe die taal zich qua populariteit/potentie verhoud tot andere FP talen.

De Elixir community richt zich sterk op web toepassingen, waar dat bij andere talen wat minder het geval lijkt te zijn. Er is ook een beweging die Elixir inzet op embedded toepassinge (middels http://nerves-project.org) maar als ik kijk naar de ondersteunde platformen (Raspberry Pi en andere dev bordjes) dan is dat op dit moment allemaal nog wel een beetje hobby niveau. Ik zou gewoon kijken welke taal veel gebruikt wordt voor jouw toepassingsgebied.

[Arite]

Wij zijn het met bedrijf ook actief bezig met Elixir, eerste projecten zijn inmiddels ook al opgevelerd. Met of zonder Phoenix.

Ik heb steeds minder de neiging om terug naar Ruby te grijpen voor web applicaties, en met ons huidige project komen de voordelen echt om de hoek kijken van Elixir/OTP. Veel realtime data, veel achterground processen en dynamische supervisors om productiegegevens te monitoren.

Elke dag leer ik nog bij, begin steeds meer in de mindset van het hele OTP gebeuren te komen, en het bevalt supergoed.

[Verwijderd]

Interessant! Wat voor soort applicaties bouwen jullie? En bij welk bedrijf zit je als ik vragen mag?

[ard1998]

A, ik mag gaan overstappen van globals naar pointers, ook leuk

[FastFox91]

Ik heb http://elm-lang.org/ leren kennen en sindsdien doe ik regelmatig aan functioneel programmeren. Soms probeer ik geleerde technieken toe te passen in andere talen, wat hobbymatig goed uit pakt, maar wat bij collega's voor verwarring zorgt.

[juanita]

In een Excel werkblad cellen invullen is natuurlijk ook gewoon functioneel programmeren. Dus in dat opzicht wordt FP juist wijdverbreid toegepast.

[Verwijderd]

Ik heb mij een beetje verdiept in Elixir en vindt het een erg interessante taal. Echter vraag ik mij af of er mensen zijn die deze taal al wat langer programmeren en wat het precies biedt boven conventionelere talen?

[BCC]

De voordelen van Erlang - stabiliteit, OTP, snelheid, foutafhandeling minus de nadelen van Erlang - Lastige syntax, slechte tooling, gebrek aan packages, kleine comunity.

[Swedish Clown]

BCC schreef op vrijdag 17 november 2017 @ 13:42:
De voordelen van Erlang - stabiliteit, OTP, snelheid, foutafhandeling minus de nadelen van Erlang - Lastige syntax, slechte tooling, gebrek aan packages, kleine comunity.

Ben het op een paar punten niet helemaal met je eens met name wbt de nadelen. Zowel Elixer als Erlang hebben een quirky syntax. Beiden wennen echter snel en zodra je door de quirks heen bent, denk je niet meer anders

Tooling is voor beide enigszins ruk. Editor is in principe geen probleem. EDTS voor Emacs, Erlang plug-in voor IntelliJ (wij hebben intern scripts voor hot code reload vanuit editor en het draaien van tests vanuit de editor) en voor VIM zijn ook tooltjes te vinden

Packages wordt langzaam beter maar erbij nog een hoop te doen!

Community is groter dan je denkt, probleem is enkel dat het veel enterprise en closed source is. Hoop grote spelers die op de BEAM zitten. Jammer dat er relatief weinig ge-open sources wordt.

Toegegeven, ik werk de hele dag met Erlang en ben dus enigszins bevooroordeeld. Er zijn genoeg nadelen te noemen en Erlang is zeker niet de geschikte taal voor elk project. Hot code reloads FTW though!

[BCC]

Mijn eerdere antwoord was uitgebreider: BCC in "Functioneel Programmeren"

[Verwijderd]

Ik ben redelijk thuis in FP, maar was nog niet bekend met Elixir. Het komt op mij over als de next big thing for web development...?

[scosec]

Wat mij opvalt is dat ik nog niets gelezen heb over Golang in dit bericht.

Hoe staan jullie tegenover deze taal?

[Bigs]

Verwijderd schreef op zaterdag 18 november 2017 @ 10:56:
Ik ben redelijk thuis in FP, maar was nog niet bekend met Elixir. Het komt op mij over als de next big thing for web development...?

Ik heb niet het idee dat dat gaat gebeuren, de community en het ecosysteem groeien maar heel langzaam en in de verzadigde markt van nieuwe programmeertalen krijgt Elixir amper voet aan de grond. Er ontstaat ook een soort kip en ei probleem: bedrijven ontwikkelen niet in Elixir want er zijn amper mensen voor te vinden en programmeurs leggen zich niet vast aan Elixir omdat er geen werk in is.

Wij zagen zelf Elixir met Phoenix wel als goede opvolger van Ruby on Rails, met name omdat we met die laatste regelmatig performance problemen hebben. De twee projecten die we in Elixir hebben gedaan kenden vele 'wow' momenten, maar het functionele aspect blijft toch ongemakkelijk aanvoelen. Om die reden en de hierboven genomenden blijven wij voor nu dus lekker bij Ruby voor ons web projecten.

[Hydra]

scosec schreef op woensdag 22 november 2017 @ 09:38:
Wat mij opvalt is dat ik nog niets gelezen heb over Golang in dit bericht.

Hoe staan jullie tegenover deze taal?

Aangezien Go geen functionele taal is, is het nogal logisch dat je hier niks over gelezen hebt in een FP topic.

Maar als je m'n mening wil weten: Go is waardeloos. Het is een simplistische taal die primair gemaakt is om de hordes net afgestudeerde programmeurs bij Google zo snel mogelijk aan de slag te hebben en dan ook nog eens een flink stukje 'skill lock-in' te creeeren. Voor een 'moderne' taal mist het een enorme hoeveelheid zaken die nu algemeen aangenomen worden als must-haves.

Een statically typed taal die geen generics kent, geen method overloading, geen inheritance, geen interfaces (Go heeft geen interfaces ondanks dat ze het zo noemen; het is duck-typing), geen exceptions, waardeloze tooling, etc. Bouw een niet triviale REST service in Go versus een in Java en je zult zien dat Go het voor elkaar krijgt meer verbose te zijn dan Java. Schrijf en nu nog eens 2 en je zult zien dat Go's manier van code-reuse is gewoon domweg copy-pasten.

Wat Go brengt, compilen naar native, is iets wat andere talen ook aan het overnemen zijn en m.i. het enige voordeel. Ik gebruik het regelmatig voor command line tooltjes maar zelfs daar erger ik me al aan de bar slechte API (mede veroorzaakt door bovenstaande hiaaten).

Wat nog het ergste is aan Go is de community. The maintainers daar zijn bijzonder arrogant; dus als er suggesties komen wat betreft waarom generics e.d. wel erg handig zijn om te hebben reageren de maintainers daarop door een lang paper te schrijven over waarom ze het niet gaan doen. De "Go aanhangers" nemen die houding aan; dus krijg je mensen die zonder blikken of blozen zeggen dat generics of exceptions 'evil' zijn en dat code copy-pasten beter is.

[ Voor 18% gewijzigd door Hydra op 22-11-2017 11:05 ]

[drm]

Ik denk dat er nog een groot verschil is tussen Functioneel vs OO Programmeren als concept of paradigma enerzijds en de verschillen in de talen anderzijds; nog afgezien van de compiler features en/of virtual machine features die ook weer sterk verschillen.

Je zou best kunnen stellen dat sterk OO-gerichte talen betere ondersteuning bieden voor OO programmeren en analoog FP-gerichte talen betere ondersteuning bieden voor functioneel programmeren. Desondanks zijn het concepten die uitwisselbaar zijn. Je kunt best object-georiënteerd programmeren in Haskell en functioneel programmeren in Java. Het is alleen niet erg praktisch, omdat de taal er niet altijd de juiste tools voor biedt (de aandachtige lezer herkent hier een understatement ). Bij wijze van voorbeeld: we weten allemaal dat het gebruik van globals niet zo handig is, en dat je liever inversion of control toepast door dependencies expliciet te maken. In veel implementaties volgt er dan een declaratieve DSL o.i.d. die sterk lijkt op hoe je in een functionele wereld altijd expliciet moet zijn, omdat puur functioneel zijn betekent dat er geen side effects op kunnen treden en er dus altijd alleen maar sprake is van een local scope (of beter gezegd: function parameters). Die paradigma's groeien dus naar elkaar toe, en dat zie je vooral in Scala gebeuren. Het nadeel van Scala (is ook al eerder genoemd) is vervolgens dat je kunt mixen en matchen en je dus heel goed in staat wordt gesteld totaal onleesbare en ononderhoudbare code te schrijven. Je wordt er zelfs een beetje toe aangemoedigd, lijkt het wel ...

Daarom denk ik dat de discussie beter zou kunnen gaan over wat FP-concepten zijn die zinvol zijn om te doorgronden (Monads, declarativeness, pure functions vs side effects, pattern matching) tegenover OO-concepten (inheritance, encapsulation, design-by-contract) en dat af te zetten tegen praktische overwegingen (lazy evaluation, parallel execution, modularity, maintainability, conciseness, enz) om een idee te krijgen over wanneer je wat toepast.

Ik ben momenteel veel bezig met React in de browser en merk dat ik daar toch vooral FP-oplossingen verkies boven OO-oplossingen (hoewel het allebei in JS is) omdat je in mijn beleving met functioneel programmeren meer een insteek hebt van explicit over implicit en met OO juist de neiging krijgt om dingen te "verstoppen" en "weg te abstraheren". Zeker met het eventloop-model waar je in de browser mee te maken hebt is het heel onverstandig om op allerlei verschillende plekken state bij te gaan houden en is het dus juist heel verhelderend als je in principe een functionele aanpak verkiest boven een OO aanpak. Immers, state is wat een object anders maakt dan een functie. En zodra je geen state meer hebt (die buiten de functie plaatst), waarom zou je nog OO bezig zijn, behalve om een soort namespacing toe te passen?

Kortom: ik ben wel benieuwd naar de vraag: wat zijn functionele paradigma's waar je blij van wordt en waarom dan? En aan de andere kant idem dito voor OO?

A propos: ik ben ook wel benieuwd of iemand al praktische ervaring heeft met Frege, een JVM implementatie van Haskell.

[scosec]

Hydra schreef op woensdag 22 november 2017 @ 11:01:
[...]


Aangezien Go geen functionele taal is, is het nogal logisch dat je hier niks over gelezen hebt in een FP topic.

Maar als je m'n mening wil weten: Go is waardeloos. Het is een simplistische taal die primair gemaakt is om de hordes net afgestudeerde programmeurs bij Google zo snel mogelijk aan de slag te hebben en dan ook nog eens een flink stukje 'skill lock-in' te creeeren. Voor een 'moderne' taal mist het een enorme hoeveelheid zaken die nu algemeen aangenomen worden als must-haves.

Een statically typed taal die geen generics kent, geen method overloading, geen inheritance, geen interfaces (Go heeft geen interfaces ondanks dat ze het zo noemen; het is duck-typing), geen exceptions, waardeloze tooling, etc. Bouw een niet triviale REST service in Go versus een in Java en je zult zien dat Go het voor elkaar krijgt meer verbose te zijn dan Java. Schrijf en nu nog eens 2 en je zult zien dat Go's manier van code-reuse is gewoon domweg copy-pasten.

Wat Go brengt, compilen naar native, is iets wat andere talen ook aan het overnemen zijn en m.i. het enige voordeel. Ik gebruik het regelmatig voor command line tooltjes maar zelfs daar erger ik me al aan de bar slechte API (mede veroorzaakt door bovenstaande hiaaten).

Wat nog het ergste is aan Go is de community. The maintainers daar zijn bijzonder arrogant; dus als er suggesties komen wat betreft waarom generics e.d. wel erg handig zijn om te hebben reageren de maintainers daarop door een lang paper te schrijven over waarom ze het niet gaan doen. De "Go aanhangers" nemen die houding aan; dus krijg je mensen die zonder blikken of blozen zeggen dat generics of exceptions 'evil' zijn en dat code copy-pasten beter is.

Dan heb ik vermoedelijk verkeerde bronnen gelezen. Ik was namelijk echt in de veronderstelling dat Go een functionele taal is. Excuses.

Veel van je genoemde argumenten ben ik vaker tegen gekomen op diverse fora. Go lijkt vooral geprezen te worden vanwege ontwikkelingssnelheid en concurrency. Concurrency wordt natuurlijk ook in andere talen aangeboden, dat is niet specifiek iets voor Go.

In elk geval dank voor je duidelijk mening, daar kan ik iets mee!

[Hydra]

scosec schreef op donderdag 23 november 2017 @ 09:48:
Dan heb ik vermoedelijk verkeerde bronnen gelezen. Ik was namelijk echt in de veronderstelling dat Go een functionele taal is. Excuses.

Dan ben ik wel benieuwd naar die bronnen. Go is, zoals C, een volledig imperatieve (of procedurele) taal. Geen OO en zeker geen FP.

Veel van je genoemde argumenten ben ik vaker tegen gekomen op diverse fora. Go lijkt vooral geprezen te worden vanwege ontwikkelingssnelheid en concurrency. Concurrency wordt natuurlijk ook in andere talen aangeboden, dat is niet specifiek iets voor Go.

Go heeft een specifieke manier, fibers. Dat is wat anders dan threads. Maar ook fibers worden in veel andere talen, vaak als externe library, aangeboden. Het is niks nieuws of bijzonders.

Dat Go sneller developed is onzin helaas.

[whoami]

Qqwy schreef op maandag 31 oktober 2016 @ 07:48:


Fantastisch! Dat vind ik superfijn om te horen! Qua OOP-talen met een non-nullable type ben ik op de hoogte van Crystal, een statically-typed OOP-taal met een syntax die erg lijkt op Ruby.

En binnenkort hebben we dan ook non-nullable reference types in C#:
klik

[kenneth]

whoami schreef op donderdag 23 november 2017 @ 11:59:
[...]
En binnenkort hebben we dan ook non-nullable reference types in C#:
klik

Nu het er eindelijk echt komt (or is it?) ben ik wel blij dat ze toch voor deze aanpak gegaan zijn en niet een parallel type hebben geintroduceerd. Warnings as errors, bite the bullet en dan genieten van robuustere code.

Gelukkig krijgen we al Reference semantics with value types. Readonly structs

---

Ik houd erg van compiler errors in ieder geval meer dan van runtime errors. Dus functionele talen met sterke typesystemen (ML-familie, Haskell) vind ik erg fijn. Ik hoop later als ik groot ben Haskell ooit te begrijpen maar voor nu zorgt F# er in ieder geval voor dat ik anders ga denken over code en daardoor ook mijn C#-code helderder wordt. Vooral doordat mijn code declaratiever is en ik explicieter ben over state. Het teruglezen van oude code geeft mij minder wtf-momenten dan vroeger.

[juanita]

@drm Op zich hoeven OO en func prog elkaar niet uit te sluiten. Mutaties aan bestaande objecten zullen bijvoorbeeld een nieuw object terug geven.

[djc]

kenneth schreef op donderdag 23 november 2017 @ 14:34:
Ik houd erg van compiler errors in ieder geval meer dan van runtime errors. Dus functionele talen met sterke typesystemen (ML-familie, Haskell) vind ik erg fijn. Ik hoop later als ik groot ben Haskell ooit te begrijpen maar voor nu zorgt F# er in ieder geval voor dat ik anders ga denken over code en daardoor ook mijn C#-code helderder wordt. Vooral doordat mijn code declaratiever is en ik explicieter ben over state. Het teruglezen van oude code geeft mij minder wtf-momenten dan vroeger.

Zou je toch eens wat Rust moeten proberen, die is pas goed in compiler errors! (En in declaratieve code.)

[Bigs]

Rust is geen functionele programmeertaal..

[H!GHGuY]

Na nu al enkele jaren OCaml te doen en de geest nog wat gerijpt is omtrent FP, is het misschien tijd om dit topic nog eens een schopje te geven met wat nieuwer inzicht.

In de OP staan tal van voordelen van FP, maar volgens mij slaat die opsomming de bal mis. Die zaken zijn allemaal nuttig en zijn voordelen tov imperatieve talen, maar voor mij is het allerbelangrijkste voordeel van FP decomposeerbaarheid.

Letterlijk alles kun je composeren:
- functies -> hogere-orde functies
- data types -> compositie
- modules -> functors

Voor mij is dit de echt kracht van FP. Je kan letterlijk alles uitdrukken "in functie van". De verschillende aspecten hiervan zijn ook interessant:
- Je doet dit op een manier die voelt als duck-typing maar toch de kracht heeft van statically en strongly typed.
- De development cost (i.e. hoeveel syntax moet ik hieraan spenderen) is meestal minimaal.
- Je kan ze ook afzonderlijk composeren. Dit is misschien nog het belangrijkste punt.

Dit versterkt code reuse, verbetert modularisatie (o.a. single-responsibility) en zorgt voor betere code over het algemeen. Je gebruikt namelijk abstracte concepten die je dan aan elkaar plakt mbv compositie om ze concreet te maken.

Bij OO heb je dit eigenlijk niet:
- Voor data types heb je wel compositie, maar daar sleur je meteen ook je behavior bij.
Dus: data en behavior niet afzonderlijk composeerbaar
- Functie compositie was/is beperkt of zeer verbose (i.e. development overhead)
Dit is wel verbeterd met de toevoeging van lambda's in veel talen, maar het blijft door de legacy soms wel wat 'behelpen' met syntax (std::function of FnOnce(...) -> ..., single-method classes/interfaces in java). Zeker ook de nood om functie-types uit te schrijven in zware syntax doet soms best pijn.
Dus: zware syntax die afraadt om dit vrijelijk te gebruiken
- module compositie bestaat nauwelijks. Je kan generics/templates er voor aanzien, maar dan doe je FP modules oneer aan.

In OO steunt elke vorm van compositie op classes en objecten (vandaar ook de term OO natuurlijk) en is het ook de enige mogelijkheid om dit te doen. Zelfs generics en templates zijn maar een kleine uitbreiding hiervan. In FP, heb je meer vrijheid met minder syntax.

En om terug te komen op de OP: leuk dat je immutability, pattern matching, currying, structural typing of memoization hebt, maar wat mij betreft zit de echte kracht in het composeren van elk aspect van de taal en de mogelijkheid om dit voor elk aspect afzonderlijk te doen.

Hoe kijken anderen hier tegen aan? Kun je je hierin vinden of denk je dat een andere eigenschap van FP nog belangrijker is?

[Sandor_Clegane]

Belangrijkste argument voor mij om F# te gebruiken is dat ik er blij van wordt.

[Batavia]

Sandor_Clegane schreef op zondag 27 januari 2019 @ 13:23:
Belangrijkste argument voor mij om F# te gebruiken is dat ik er blij van wordt.

Ik wou dat er meer 'echte banen' waren met F#. Bij mij blijft het in het hobby stadium zitten

[ Voor 8% gewijzigd door Batavia op 27-01-2019 13:34 ]

[Sandor_Clegane]

peltco schreef op zondag 27 januari 2019 @ 13:33:
[...]


Ik wou dat er meer 'echte banen' waren met F#. Bij mij blijft het in het hobby stadium zitten

Yup, same here. Maar ja neemt niet weg dat als ik de keuze heb ik toch voor F# kies.

Voor mij is het grootste voordeel van FP ten opzichte van andere talen dat ik veel meer bezig ben met code te schrijven ipv na te denken over hoe de code te schrijven, de expressiviteit van het type system is ook geweldig om een domein te modelleren.

De cognitive load is een stuk lager heb ik het idee omdat je niet verzand in allerlei patterns, OO concepten en boilerplate.

[ Voor 39% gewijzigd door Sandor_Clegane op 27-01-2019 14:05 ]

[Sircuri]

Ik maak beroepsmatig gebruik van F# en het heeft me wel ruim een half jaar geduurd voor het kwartje viel. Daarbij kwam wel het probleem dat de code waar ik in viel, geschreven was door iemand die als motto had: "die code kan veel korter!!" Dat resulteerde in niet leesbare code wat de leer curve erg stijl maakte.

Ik ben zelf voornamelijk blij met immutabillity en dat functies geen bij-effect hebben. Natuurlijk kan je in F# ook heel lelijk imperatief programmeren, maar het is toch moeilijker om te doen

[Mugwump]

Sircuri schreef op zondag 27 januari 2019 @ 19:40:
Ik maak beroepsmatig gebruik van F# en het heeft me wel ruim een half jaar geduurd voor het kwartje viel. Daarbij kwam wel het probleem dat de code waar ik in viel, geschreven was door iemand die als motto had: "die code kan veel korter!!" Dat resulteerde in niet leesbare code wat de leer curve erg stijl maakte.

Ik ben zelf voornamelijk blij met immutabillity en dat functies geen bij-effect hebben. Natuurlijk kan je in F# ook heel lelijk imperatief programmeren, maar het is toch moeilijker om te doen

Is dat dan iets wat je hoofdzakelijk solo doet of heb je dan ook echt een team dat samen aan een FP codebase werkt?
Ik heb namelijk toch altijd wel het idee dat de drempel voor FP een stuk hoger ligt dan voor imperatief programmeren.Als ik al zie hoeveel mensen moeten hebben om basale imperatieve concepten onder de knie te krijgen, dan vermoed ik dat FP toch een stapje te ver is. Al is dat wat mij betreft niet direct een nadeel. Ik ken heel wat ontwikkelaars in imperatieve talen die ze wat mij betreft per direct hun toetsenbord mogen afpakken.

[Sandor_Clegane]

Sircuri schreef op zondag 27 januari 2019 @ 19:40:
Ik maak beroepsmatig gebruik van F# en het heeft me wel ruim een half jaar geduurd voor het kwartje viel. Daarbij kwam wel het probleem dat de code waar ik in viel, geschreven was door iemand die als motto had: "die code kan veel korter!!" Dat resulteerde in niet leesbare code wat de leer curve erg stijl maakte.

Dit is wel een ding. Look at me being smart.........

Ik hou wel van keep it simple.

[ Voor 3% gewijzigd door Sandor_Clegane op 27-01-2019 20:17 ]

[H!GHGuY]

Mugwump schreef op zondag 27 januari 2019 @ 19:48:
[...]

Ik heb namelijk toch altijd wel het idee dat de drempel voor FP een stuk hoger ligt dan voor imperatief programmeren.

Ik zou het omgekeerde durven beweren. De drempel ligt hoger omdat ze opgeleid zijn in OO en ze eerst al die *kuch* nonsense *kuch* moeten afleren...
Na het gechargeer, even wat naunce toevoegen. In de OP staat zo'n vergelijkingsfiguurtje waarbij de tegenhangen van de OO patterrns/principle allemaal functies zijn. Mijns inziens is dat een foute vergelijking en is wat ik eerder opschreef veel zinvoller. Vertrekkend vanuit FP aantonen dat OO eigenlijk het minderbedeelde achterneefje is.

Dan zie je meteen ook dat de noodzaak van al die patterns komt door het hebben van slechts 1 hamer om op elk probleem te kloppen: classes. En net omdat die slecht composeerbaar zijn, heb je nood aan patterns om Joe Coder enigzins degelijke code te laten schrijven voor een set van veel weerkerende problemen. De oplossingen zijn door het gebrek aan de juiste tools niet triviaal te ontdekken, dus moeten ze er ingedramd worden.
Daarnaast hebben die classes het bijkomende probleem van de enorme verbosity. Constructors, destructors, copy-constructors, etc. Vergelijk een visitor pattern maar eens met wat je nodig hebt voor een fold/map/iter.

Dat wil niet zeggen dat alles perfect is in FP. Een ondermaats presterende FP developer kan evenzeer kwaad doen als in OO talen. Eigenlijk krijg je een hoop meer tools in handen waar je dan ook de juiste dingen mee moet doen.

De elegantie spreekt soms boekdelen:

OCaml:

// module Socket
type unbound
type bound
type listening
type connected

type family = ...
type socket_type = ...
type protocol = ...

val new: family -> socket_type -> protocol -> new
val bind: new -> addr -> bound
val listen: bound -> listening
val accept: listening -> connected
val connect_anon: new -> addr -> connected
val connect_bound: bound -> addr -> connected
val listen: listening 
val read: connected -> int -> buffer
val write: connected -> buffer -> int

De code gaat hem niet zozeer om het socket aspect (dit zou ik zelf ook anders doen), maar om het typing-aspect. Hier heb je zomaareven quasi voor niets een state pattern geimplementeerd met keurige transities, volledig type-safe en via de type-safety ook error-free: je kan geen read doen op een listening socket of een listen op een connected socket.
Doe je hetzelfde in C++, dan krijg je ofwel een pImpl waarbij alle functies excepties gooien als ze in de verkeerde staat aangeroepen worden (horror!) of krijg je hopen classes met bijhorend typwerk. Daar ben je wel een paar dagen mee bezig...


Off-topic:

OCaml:

// module Socket
type unbound
type bound
type listening
type connected

type 'a socket

val new: family -> socket_type -> protocol -> new socket
val bind: new socket -> addr -> bound socket
val listen: bound socket -> listening socket
val accept: listening socket -> connected socket
...

Leest zo mogelijk nog eenvoudiger en wanneer je met GADT's aan de slag gaat kun je nog common operaties toelaten op sockets in elke staat. (bijvoorbeeld setsockopt of fcntl).

Of als je dat te moeilijk vindt:

OCaml:

// module Socket
type all_states = [<'Unbound | `Bound | `Listening | `Connected ]

type 'a socket

val new: family -> socket_type -> protocol -> [<'Unbound] socket
val bind: [< 'Unbound] socket -> addr -> [<'Bound] socket
val listen: [< 'Bound] socket -> [< 'Listening] socket
val accept: [< 'Listening] socket -> [' Connected] socket
val select: [< 'Listening | 'Connected ] socket -> int -> select
...
val setsockopt_bool: all_states socket -> bool_option -> bool -> unit

Iets meer verbosity, maar laat wel makkelijker toe om in elke functie
de subset van valid source states te specifieren.
Die verbosity kan trouwens weg met iets als:

OCaml:

type unbound = [<'Unbound]

en dan krijg je het vorige terug met enkel nog de extra verbosity op de speciale functies.

En zo zijn er nog wel mogelijkheden afhankelijk van de noden...

[Mugwump]

@H!GHGuY Ik zal niet je hele post gaan citeren, maar mijn ervaring is toch iets anders.

Toen ik zo rond 2000 begon aan mijn studie kregen we als eerste vak functioneel programmeren in een voorganger van Haskell. Daar had echt iedereen forse moeite mee, of ze nou ervaring hadden met imperatieve talen of niet.
Het trimester daarop hadden we een OOP-vak. Dat ging vrijwel iedereen een stuk makkelijker af.

FP en CLP zijn heel elegant en als je echt alle aspecten van OOP meeneemt dan zijn ze waarschijnlijk ook nog wel eenvoudiger, maar heel veel mensen streven toch vooral naar iets in elkaar knutselen dat min of meer werkt.

Even wat klooien in JavaScript, Python of PHP is heel wat laagdrempeliger dan FP en dat is wat heel veel mensen toch doen.

Toevallig nog een stukje OOP in Python training gegeven laatst met een collega die een stukje FP in Python deed. In beide gevallen krijg je dan toch vooral wazige blikken van de aanwezige scriptkloppers.

[H!GHGuY]

Haskell(-like) is idd van een net iets steviger kaliber. Al zou ik hopen dat er bij een opleiding ook aandacht besteed wordt aan lambda calculus zodat de overgang voor zo'n vak makkelijker is.

"Laagdrempelig" ga ik mee akkoord. Maar dat is niet iets waar de baas voor betaalt. Die wil kwaliteitsvolle software op een zo kort mogelijke tijd. En dat is iets wat je met de aangehaalde talen veel moeilijker bereikt dan met de meeste FP talen.

Ik deed recent wat "Advent Of Code" dingetjes mee. Op de tiental opdrachten die ik deed heb ik slechts 1 keer een foutje eruit moeten halen en het was dan nog tijdens de string-parsing, het meest imperatieve deel van de code die ik schreef.
Al de rest was: write, compile, run. Correct! Dat deed ik mezelf niet na in pakweg C++.

[Mugwump]

H!GHGuY schreef op zondag 27 januari 2019 @ 21:45:
Haskell(-like) is idd van een net iets steviger kaliber. Al zou ik hopen dat er bij een opleiding ook aandacht besteed wordt aan lambda calculus zodat de overgang voor zo'n vak makkelijker is.

"Laagdrempelig" ga ik mee akkoord. Maar dat is niet iets waar de baas voor betaalt. Die wil kwaliteitsvolle software op een zo kort mogelijke tijd. En dat is iets wat je met de aangehaalde talen veel moeilijker bereikt dan met de meeste FP talen.

Ik deed recent wat "Advent Of Code" dingetjes mee. Op de tiental opdrachten die ik deed heb ik slechts 1 keer een foutje eruit moeten halen en het was dan nog tijdens de string-parsing, het meest imperatieve deel van de code die ik schreef.
Al de rest was: write, compile, run. Correct! Dat deed ik mezelf niet na in pakweg C++.

Ik ben het met je eens hoor dat FP vele voordelen heeft en zeker niet per definitie complexer is dan full blown OOP vol met AbstractProxyFactories en meer van die ongein.

Er is echter wel heel veel meer dan dergelijke complexe softwaredevelopment. De gemiddelde PHP-websitebouwer maakt zich daar namelijk niet zo druk om. De data scientist of BI'er die wat data wrangling of ETL werk moet doen ook niet.

[Swedish Clown]

Mugwump schreef op zondag 27 januari 2019 @ 19:48:
[...]


Is dat dan iets wat je hoofdzakelijk solo doet of heb je dan ook echt een team dat samen aan een FP codebase werkt?

In mijn huidige baan zit een team van 40 engineers in dezelfde codebase. Over 3 weken switch ik van baan en ga ik bij een bedrijf aan de slag waar “slechts” 8 man aan dezelfde codebase werken. Beide is Erlang en er zijn genoeg bedrijven hier in Stockholm die Erlang / Elixer in huis hebben

Sandor_Clegane schreef op zondag 27 januari 2019 @ 20:16:
[...]


Dit is wel een ding. Look at me being smart.........

Ik hou wel van keep it simple.

Er zij altijd uitzonderingen Laatst een collega die een dubbele lists:map in z’n PR had zitten. Was prima leesbaar en niks mis mee maar een dubbele list comprehension paste netjes ik 2 regels en was uiteindelijk leesbaarder.

Korte code schrijven voor het korte code schrijven heb ik een hekel aan maar er zijn genoeg momenten waar korte code zowel korter als beter leesbaarder is. (Even afgezien van het feit er soms nog een performance winst mee te behalen valt ook )

[H!GHGuY]

Mugwump schreef op zondag 27 januari 2019 @ 21:57:
[...]
Er is echter wel heel veel meer dan dergelijke complexe softwaredevelopment. De gemiddelde PHP-websitebouwer maakt zich daar namelijk niet zo druk om. De data scientist of BI'er die wat data wrangling of ETL werk moet doen ook niet.

En dat zijn soms de doelgroepen die het meest baat zouden hebben bij een taal die wat extra garanties kan geven.

Mits een goed framework, zou de hele miserie die PHP had/heeft met unicode/ASCII strings niet bestaan. Dan had je voor elk een type en had je conversie-functies. Dan was het ook duidelijk wat elke functie aanvaardde.

In BI ben ik minder thuis, maar zou ik gelijkaardige voordelen verwachten. Met name code schrijven die makkelijker wiskundig te verifiëren valt is een voordeel.

Net die groepen die niet zo thuis zijn in S/W development kunnen het meest geholpen zijn met een taal die hun handje vast houdt. Natuurlijk is omkadering (e.g. goed opgezette frameworks) nodig, maar dat is nu niet anders.

[HawVer]

Iemand ook ervaring met Elm of Purescript? Elm is wel een mooie taal, maar de hele architectuur is nogal dwingend. Purescript geen ervaring mee.. Ik zit er over te denken om daar wat mee te spelen voor een prive project.. Of zal ik het veilig bij Typescript houden?

[mulder]

Elm is wel grappig, maar ben er niet echt in gedoken aangezien ik meer met F# ben gaan doen. F# is ook wel fan van de Elm architectuur trouwens, kijk maar naar Fabulous en Fable.Elmish. Fable dwingt je niet tot Elmish btw.

[Sandor_Clegane]

Elm is leuk, het idee van Model View Update is wel elegant. Een stuk eleganter dan MVVM in mijn optiek.

Fable Elmish is in mijn optiek een mooi systeem, je kan gewoon F# schrijven en dan compileert alles naar JavaScript. Het werken met webpack en Hot Module Reloading is echt een mooie vlotte manier van ontwikkelen. Hierdoor werkt je browser zich on the fly bij als je je file saved.

[mcdronkz]

HawVer schreef op donderdag 4 april 2019 @ 10:09:
Iemand ook ervaring met Elm of Purescript? Elm is wel een mooie taal, maar de hele architectuur is nogal dwingend. Purescript geen ervaring mee.. Ik zit er over te denken om daar wat mee te spelen voor een prive project.. Of zal ik het veilig bij Typescript houden?

Elm, ClojureScript, ReasonML... op hun eigen manier allemaal prachtige talen. Zeker de moeite waard om tijd mee door te brengen, al is 't maar vanwege de intellectueel uitdagende, perspectief-verruimende ervaringen.

De nieuwe concepten die je leert en ideeën die je opdoet kunnen vervolgens in TypeScript worden toegepast dat in veel gevallen de betere keuze is voor mission-critical projecten, ook al is 't op ontwerp-technisch vlak inferieur aan de eerdergenoemde talen.

[ Voor 6% gewijzigd door mcdronkz op 07-04-2019 17:02 ]

[Immutable]

Vanuit C/C++ en Rust gezien. (Systeem talen)

Weet iemand een functionele programmeertaal ZONDER garbage collector zodat je deze kan gebruiken voor o.a. embedded systemen? Zaken waar hard real-time van groot belang zijn?

Of is dat gewoon onmogelijk om zonder GC te werken met Functioneel Programmeren? Dat zou best jammer zijn omdat Functioneel Programmeren gewoon veel voordelen bied qua correctheid en voorspelbaarheid en testen.

Hoe zit het verder met typesafety, deterministisch gedrag en memory leaks?

[ Voor 39% gewijzigd door Immutable op 09-04-2019 18:04 ]

[HawVer]

Immutable schreef op dinsdag 9 april 2019 @ 18:01:
Vanuit C/C++ en Rust gezien. (Systeem talen)

Weet iemand een functionele programmeertaal ZONDER garbage collector zodat je deze kan gebruiken voor o.a. embedded systemen? Zaken waar hard real-time van groot belang zijn?

Of is dat gewoon onmogelijk om zonder GC te werken met Functioneel Programmeren? Dat zou best jammer zijn omdat Functioneel Programmeren gewoon veel voordelen bied qua correctheid en voorspelbaarheid en testen.

Hoe zit het verder met typesafety, deterministisch gedrag en memory leaks?

Je kan Rust op een functionele manier gebruiken. Rust heeft geen GC. Misschien dat je daar wat mee kan? De overige details (typesafety, etc.) weet ik niet. Dat zul je zelf even moeten bekijken.

[ Voor 61% gewijzigd door HawVer op 09-04-2019 18:22 ]

[Immutable]

HawVer schreef op dinsdag 9 april 2019 @ 18:22:

[...]

Je kan Rust op een functionele manier gebruiken. Rust heeft geen GC. Misschien dat je daar wat mee kan? De overige details (typesafety, etc.) weet ik niet. Dat zul je zelf even moeten bekijken.

Maar bij hard real-time systemen wil men altijd Tail Call Elimination in plaats van Tail Call Optimization wat je gebruikt in FP. Volgens mij heeft Rust geen Tail Call Optimization of staat het in de kinderschoenen? Misschien dat het tegen wat zaken in gaat betreft de doelstelling van de taal zelf.

Is FP dan gewoon uitgesloten voor hard real-time systemen? Is FP niet deterministisch? En loop je gewoon tegen het punt aan betreft je stack?

[ Voor 12% gewijzigd door Immutable op 09-04-2019 18:47 ]

[BCC]

Gezien de hoeveelheid elixir die nu gebruikt wordt voor embedded systemen lijkt me dat dit niet direct een probleem meer is . https://nerves-project.org/

[ Voor 10% gewijzigd door BCC op 10-04-2019 18:23 ]