(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
;; | |
;; NS CHEATSHEET | |
;; | |
;; * :require makes functions available with a namespace prefix | |
;; and optionally can refer functions to the current ns. | |
;; | |
;; * :import refers Java classes to the current namespace. | |
;; | |
;; * :refer-clojure affects availability of built-in (clojure.core) | |
;; functions. |
(ns ^{ :doc "Base64 Encoding/Decoding in Clojure" | |
:author "Yannick Scherer" } | |
base64) | |
;; ## Conversion Functions | |
(def ^:private base64-chars | |
"Base64 Characters in the right order." | |
(vec | |
(concat |
/* LightTable themes are just CSS. LightTable, CodeMirror, and plugins apply | |
classes to tokens within the text. Most of these classes are undocumented. I | |
had to go fishing with the dev inspector and apply brightly colored rules to | |
figure it out. Hopefully I can save you the trouble by documenting the default | |
theme. Please comment if you find any errors or omissions. */ | |
/* These #multi rules apply to tabsets. Active means currently selected and dirty | |
means that the file has been edited since the last save. */ | |
#multi.theme-default .tabset .list .active { color:var(placeholder-fg); } | |
#multi.theme-default .tabset.active .list .active { color:var(highlight-fg); } |
(defn flip [function] | |
(fn | |
([] (function)) | |
([x] (function x)) | |
([x y] (function y x)) | |
([x y z] (function z y x)) | |
([a b c d] (function d c b a)) | |
([a b c d & rest] | |
(->> rest | |
(concat [a b c d]) |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
type BusyBuilder(blockUi, unblockUi) = | |
member this.Bind(x, f) = async.Bind(x, f) | |
member this.Combine(e1, e2) = async.Combine(e1, e2) | |
member this.Delay(f) = | |
async { | |
blockUi () | |
let! result = async.Delay f | |
unblockUi () | |
return result | |
} |
const I = x => x | |
const K = x => y => x | |
const A = f => x => f (x) | |
const T = x => f => f (x) | |
const W = f => x => f (x) (x) | |
const C = f => y => x => f (x) (y) | |
const B = f => g => x => f (g (x)) | |
const S = f => g => x => f (x) (g (x)) | |
const S_ = f => g => x => f (g (x)) (x) | |
const S2 = f => g => h => x => f (g (x)) (h (x)) |
I got inspired to answer the questions posed to F# experts on "Why F#?". I have no claims to be an F# expert but I thought the questions were interesting.
I believe I started to look at F# around 2008. I am a language-curious person and was at the time working as a .NET developer so I naturally was excited when discovering F#.
How long did it take before you could code real world apps as much or more productively as in C#?
This blog created for F# Advent 2016 (English)
Full source code can be found here
if [ ! -f .env ] | |
then | |
export $(cat .env | xargs) | |
fi |