I am … • From functional programming I do • Clojure - Lispy, dynamic, server-side • LiveScript - Haskell-inspired, dynamic,client- side • Big fan of productivity (Agile&Scrum, GTD) and quality (TDD, refactoring)
Left to right, up to bottom • Code which you read bottom-up right-to-left is problematic (if you aren’t from culture which reads bottom-up right-to-left) ! • #1 use -> or ->> • #2 use let
Get rid of useless code: Compose for the great good! • The reason I started functional programming is to get rid of useless code, what was your reason? • #1 Use partial application • #2 Use function composition
Partial application and composition • Instead of (defn a [x] (b (c x))) do: • (def a (comp b c)) • Instead of (fn [x] (+ 3 x)) or #(+ 3 %) do: • (partial + 3) ; shame it is not automatic as in Haskell, you would need only (+ 3)
Partial application and composition • They combine together. • Instead of: (defn a [x] (b 11 (c 12 x))) • You can write: • (def a (comp (partial b 11) (partial c 12))) • (which is longer and not readable for some of you now but it helps in real code especially after you get used to it - or if you are interested in Haskell) • In Haskell (and LiveScript): • a = (b 11) . (c 12)
Partial application and composition example
Rule #1 of Macros: Don’t use macros • HOFs are extremely powerful • There is a lot of existing macros • Partial Application, Composition and HOFs take you long way without ever touching macros • Don’t tell anybody, I have 1 macro on hundreds of functions - and all my Clojure friends have similar codebases
Rule #2 of Macros: You can make language of your dreams • core.async is just group of macros • If you miss any feature, you can (and probably should) implement it
• But language design is hard (trust me, I designed one) • You need special set of skills, it isn’t just add operators, blocks here and there • Good syntax should improve code readability (or at least shouldn’t make it worse) • Good syntax compose with the rest
Will you spot a mistake?
Will you spot a mistake?
There are two, three, four, five … worlds! • While programming (especially in languages with macros) you are not only language user but language designer! • If you build business application, your language will be different from programmer building math application.
When designing language, there are steps to follow: 1. Find and describe the terminology of your domain 2. Use the terminology in your application 3. Find another relations (to other parts, check how many times were ‘abstract’ constructs used) 4. Learn something (where did you do mistakes) 5. recurse (GOTO considered harmful)
Pure FP vs. Real World • In pure-FP everything is expression • In pure-FP you don’t need sequential calling of functions • In pure-FP there’s no time • Non-pure programming needs some constructs and your language design must follow it and should make it readable.
Side-effects • You need sequences of calls (do (first) (second) …) • You will use for (again) • You will have problems with Clojure lazy sequences (doall to solve all known problems) • (take, map, filter and others return lazy sequence and do nothing automatically) • But, try (for [x some-collection] (save-to-table1 x) (save-to-another- table x) (and-show x)) • Hint: for expects only 1 expression (you must use (do…)) - which I see as a wrong design decision
Side-effects • When designing your operators, think of it: • what if user needs more operations? • what about concurrency? • how it will look with other operators? • where is application state? how it changes?
Don’t Repeat Yourself2 • See where you use similar code • Then decide if you want introduce new syntax with macros • (But please, try to do it another way, for example HOFs, existing macros etc.)
Cheatsheet • ¡Remember, it cannot be done without refactoring! • Is everything named properly • does it use users terminology? • application is collection of DSLs • Can you read your code L-to-R up-to-bottom? • Aren’t there any unnecessary duplications?