Domain-driven design in FP. For the last couple of years, I have… | by Naveen Negi | Geek Culture | Medium
Maybe you are convinced that domain driven design is the best way to tame complexities in software applications — even when those are written in functional languages. You have searched over internet looking for way to achieve it, but felt disappointed with dearth of resources. Even when you found one, It lacked true essence of functional programming, It lacked power of composition, It stubbornly a
Functional Go
Functional Programming by Wikipedia:“Functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data”. In other words, functional programming promotes code with no side effects, no change of value in variables. It opposes imperative programming, which empathizes change of state”. What does this mean?No mutable d
Promises + FP = Beautiful Streams
W’ve seen that Futures/Promises emerge as a logical meaning for asynchronous functions like in this Node example : fs.readFile(‘…’) // => a Future/PromiseSimilarly, we w’d like to represent the meaning of functions like this someEventSource.on('event', ...) // => ?The second code shares the asynchronous semantics of the first, hence the use of callbacks in both cases. But instead of a single futur
Functional Programming should be your #1 priority for 2015
You probably have heard expressions like “Clojure”, “Scala”, “Erlang” or even “Java now has lambdas”. And you might know it has something to do with "Functional Programming". If you’re participating to any Programming Community, this subject probably has popped up already. If you'd google "Functional Programming", you'll see there's nothing new. One of the first language created already embraces i
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Elixir Intermediate — The Hard Code Behind Smooth Code
