http://www.lispcast.com/ A blog about the simple joys of functional programming. en http://www.lispcast.com/clojure-and-types http://www.lispcast.com/clojure-and-types Thu 26 Oct 2017 04:45:17 PM CDT Rich Hickey explained the design choices behind Clojure and made many statements about static typing along the way. Share an interesting perspective and some stories from my time as a Haskell programmer. I conclude with a design challenge for the statically typed world. <p><center><a href="http://www.lispcast.com/clojure-and-types">Read full post</a></center></p> http://www.lispcast.com/procedural-paradox http://www.lispcast.com/procedural-paradox Wed 30 Aug 2017 14:07:44 AM CDT I break down two perspectives (their features and their methodologies) for the three most common paradigms. I also explore why paradigms are so easy to argue about, and what we can do about it. <p><center><a href="http://www.lispcast.com/procedural-paradox">Read full post</a></center></p> http://www.lispcast.com/fp-in-my-language http://www.lispcast.com/fp-in-my-language Tue 02 Aug 2017 02:24:20 PM CDT We address the question directly, but then look deeper to the beliefs behind the question. <p><center><a href="http://www.lispcast.com/fp-in-my-language">Read full post</a></center></p> http://www.lispcast.com/refactor-bottom http://www.lispcast.com/refactor-bottom Mon 26 Jun 2017 08:00:38 AM CDT We explore when it is safe to extract out an abstraction and when you need to go deeper and rebuild it from scratch. <p><center><a href="http://www.lispcast.com/refactor-bottom">Read full post</a></center></p> http://www.lispcast.com/what-is-abstraction http://www.lispcast.com/what-is-abstraction Sun 25 Jun 2017 16:50:44 AM CDT We explore some of the background behind the meaning of the word abstraction and why we do it. <p><center><a href="http://www.lispcast.com/what-is-abstraction">Read full post</a></center></p> http://www.lispcast.com/clojure-web-framework http://www.lispcast.com/clojure-web-framework Wed 21 Jun 2017 09:30:38 AM CDT After exploring why frameworks and why not frameworks, I dive into the design priorities I think a web framework should have. <p><center><a href="http://www.lispcast.com/clojure-web-framework">Read full post</a></center></p> http://www.lispcast.com/arguments-against-frameworks http://www.lispcast.com/arguments-against-frameworks Tue 20 Jun 2017 06:30:36 AM CDT We explore three arguments against frameworks, address them, then turn them into challenges to be overcome. <p><center><a href="http://www.lispcast.com/arguments-against-frameworks">Read full post</a></center></p> http://www.lispcast.com/why-web-frameworks http://www.lispcast.com/why-web-frameworks Mon 19 Jun 2017 08:15:33 AM CDT While contemplating a Clojure web framework, I explore the reasons we use web frameworks in general. I conclude that the framework should support a learnable development process. <p><center><a href="http://www.lispcast.com/why-web-frameworks">Read full post</a></center></p> http://www.lispcast.com/cognitect-clojure http://www.lispcast.com/cognitect-clojure Thu 25 May 2017 07:10:48 AM CDT Poor open-source development practices, neglect for the beginner experience, and lack of communication have come up as complaints against how Cognitect stewards Clojure. I address the complaints with a plea that we do more as a community. <p><center><a href="http://www.lispcast.com/cognitect-clojure">Read full post</a></center></p> http://www.lispcast.com/defn-podcast-transcript http://www.lispcast.com/defn-podcast-transcript Thu 11 May 2017 01:24:14 PM CDT I was on the Defn Podcast. We talked about Clojure, testing, and PHP :) Here is a transcript. <p><center><a href="http://www.lispcast.com/defn-podcast-transcript">Read full post</a></center></p> http://www.lispcast.com/bootstrapping-mindset http://www.lispcast.com/bootstrapping-mindset Tue 16 Mar 2017 06:48:01 AM CDT One of the great things about very robust and powerful abstractions is that they can give you tremendous leverage. The leverage can be so great that you can build something much greater than the sum of its parts. However, I worry that the web is an end to this kind of abstraction. I'd like to explore why that is and what we can do about it. <p><center><a href="http://www.lispcast.com/bootstrapping-mindset">Read full post</a></center></p> http://www.lispcast.com/idea-of-lisp http://www.lispcast.com/idea-of-lisp Tue 13 Dec 2016 06:41:42 AM CDT How a programming language can be an idea. <p><center><a href="http://www.lispcast.com/idea-of-lisp">Read full post</a></center></p> http://www.lispcast.com/building-composable-abstractions-3 http://www.lispcast.com/building-composable-abstractions-3 Sun 13 Nov 2016 03:36:36 PM CST My third rehearsal for my upcoming Clojure/conj talk. <p><center><a href="http://www.lispcast.com/building-composable-abstractions-3">Read full post</a></center></p> http://www.lispcast.com/clojure-conj-rehearsal http://www.lispcast.com/clojure-conj-rehearsal Sun 06 Nov 2016 08:30:54 PM CST My upcoming Clojure/conj talk is fast approaching. I recorded two rehearsals in two days. Watch them! <p><center><a href="http://www.lispcast.com/clojure-conj-rehearsal">Read full post</a></center></p> http://www.lispcast.com/new-orleans-clojure-workshop-oct-2016 http://www.lispcast.com/new-orleans-clojure-workshop-oct-2016 Sun 23 Oct 2016 08:46:35 PM CDT We organized a Clojure workshop. Here's what went right and what we should do next time. <p><center><a href="http://www.lispcast.com/new-orleans-clojure-workshop-oct-2016">Read full post</a></center></p> http://www.lispcast.com/concurrency-vs-parallelism http://www.lispcast.com/concurrency-vs-parallelism Mon 01 Aug 2016 06:20:00 PM CDT Concurrency and parallelism are concepts that we make use of every day off of the computer. I give some real world examples and we analyze them for concurrency and parallelism. <p><center><a href="http://www.lispcast.com/concurrency-vs-parallelism">Read full post</a></center></p> http://www.lispcast.com/hirable-in-clojure http://www.lispcast.com/hirable-in-clojure Fri 22 Jul 2016 11:25:39 AM CDT You actually need to learn nothing. But it's more complicated than that. This article will show you what can set you apart. <p><center><a href="http://www.lispcast.com/hirable-in-clojure">Read full post</a></center></p> http://www.lispcast.com/clojure.spec-vs-schema http://www.lispcast.com/clojure.spec-vs-schema Sat 11 Jun 2016 01:06:47 PM CDT Schema and clojure.spec aim to solve similar problems. There are significant differences, though, that might not be obvious at first. <p><center><a href="http://www.lispcast.com/clojure.spec-vs-schema">Read full post</a></center></p> http://www.lispcast.com/clojure-hashmaps http://www.lispcast.com/clojure-hashmaps Thu 17 Mar 2016 11:10:52 AM CDT Clojure hashmaps are one of the workhorse data structures in Clojure. There are two main patterns commonly used. We also discuss some interesting properties. <p><center><a href="http://www.lispcast.com/clojure-hashmaps">Read full post</a></center></p> http://www.lispcast.com/clojure-windows-8 http://www.lispcast.com/clojure-windows-8 Fri 11 Mar 2016 11:29:43 AM CST The ClojureBridge curriculum includes excellent instructions for installing Clojure on a variety of systems. They are well suited for beginners. I have adapted the Windows 8 instructions for my recommendations. <p><center><a href="http://www.lispcast.com/clojure-windows-8">Read full post</a></center></p> http://www.lispcast.com/clojure-mac http://www.lispcast.com/clojure-mac Fri 11 Mar 2016 11:28:57 AM CST The ClojureBridge curriculum includes excellent instructions for installing Clojure on a variety of systems. They are well suited for beginners. I have adapted the Mac OS X instructions for my recommendations. <p><center><a href="http://www.lispcast.com/clojure-mac">Read full post</a></center></p> http://www.lispcast.com/clojure-ubuntu http://www.lispcast.com/clojure-ubuntu Fri 11 Mar 2016 11:27:10 AM CST The ClojureBridge curriculum includes excellent instructions for installing Clojure on a variety of systems. They are well suited for beginners. I have adapted the Ubuntu instructions for my recommendations. <p><center><a href="http://www.lispcast.com/clojure-ubuntu">Read full post</a></center></p> http://www.lispcast.com/clojure-windows-7 http://www.lispcast.com/clojure-windows-7 Fri 11 Mar 2016 11:26:17 AM CST The ClojureBridge curriculum includes excellent instructions for installing Clojure on a variety of systems. They are well suited for beginners. I have adapted the Windows 7 instructions for my recommendations. <p><center><a href="http://www.lispcast.com/clojure-windows-7">Read full post</a></center></p> http://www.lispcast.com/clojure-and-blocks http://www.lispcast.com/clojure-and-blocks Thu 10 Mar 2016 03:38:14 PM CST My daughter's blocks taught her to match shapes with a lot of fast feedback. Fast feedback is a powerful tool to learn any skill. I analyze how the blocks helped my daughter learn and compare it to learning Clojure. <p><center><a href="http://www.lispcast.com/clojure-and-blocks">Read full post</a></center></p> http://www.lispcast.com/master-one-skill-at-a-time http://www.lispcast.com/master-one-skill-at-a-time Thu 10 Mar 2016 03:36:58 PM CST Research shows that developing mastery of a large skill is best done by mastering smaller skills that you can achieve 90% accuracy in very quickly. LispCast Introduction to Clojure has broken the skills you need down for you. <p><center><a href="http://www.lispcast.com/master-one-skill-at-a-time">Read full post</a></center></p> http://www.lispcast.com/start-practicing-soon http://www.lispcast.com/start-practicing-soon Thu 10 Mar 2016 02:56:26 PM CST Much of the difficulty of learning a new language is caused by knowing more than you are comfortable doing. It's so important to get started practicing real programming as soon as possible. <p><center><a href="http://www.lispcast.com/start-practicing-soon">Read full post</a></center></p> http://www.lispcast.com/interactive-baking http://www.lispcast.com/interactive-baking Fri 04 Mar 2016 08:48:52 PM CST LispCast Introduction to Clojure teaches Clojure with an "interactive bakery simulation". The reason is that metaphors that you can embody are a great way to learn abstract things like programming. <p><center><a href="http://www.lispcast.com/interactive-baking">Read full post</a></center></p> http://www.lispcast.com/imperative-intro http://www.lispcast.com/imperative-intro Thu 03 Mar 2016 09:58:50 PM CST LispCast Introduction to Clojure starts with 30 minutes of imperative programming. We write programs for their effects, so imperative is a great place to start. <p><center><a href="http://www.lispcast.com/imperative-intro">Read full post</a></center></p> http://www.lispcast.com/deftype-vs-defrecord http://www.lispcast.com/deftype-vs-defrecord Thu 03 Mar 2016 06:08:29 PM CST There are two commonly used ways to create new data types in Clojure, deftype and defrecord. They are similar but are intended to be used in two distinct use cases. deftype is for programming constructs and defrecord is for domain constructs. <p><center><a href="http://www.lispcast.com/deftype-vs-defrecord">Read full post</a></center></p> http://www.lispcast.com/what-are-macros http://www.lispcast.com/what-are-macros Thu 03 Mar 2016 05:45:27 PM CST Macros are one of the most talked about features of Lisp. They are a powerful way to extend the language without modifying the compiler. <p><center><a href="http://www.lispcast.com/what-are-macros">Read full post</a></center></p> http://www.lispcast.com/locks-v-concurrency-primitives http://www.lispcast.com/locks-v-concurrency-primitives Mon 29 Feb 2016 05:23:08 PM CST Many people have asked me why Clojure has concurrency primitives. Aren't locks good enough? A humorous metaphor is elaborated. <p><center><a href="http://www.lispcast.com/locks-v-concurrency-primitives">Read full post</a></center></p> http://www.lispcast.com/clojure-set http://www.lispcast.com/clojure-set Sun 29 Feb 2016 4:00:54 AM CST clojure.set is part of the standard library that comes with Clojure. It has functions for doing set operations and relational algebra. <p><center><a href="http://www.lispcast.com/clojure-set">Read full post</a></center></p> http://www.lispcast.com/what-is-clojure http://www.lispcast.com/what-is-clojure Sat 27 Feb 2016 10:19:45 AM CST Clojure is a general purpose programming language designed for the fast-approaching future. <p><center><a href="http://www.lispcast.com/what-is-clojure">Read full post</a></center></p> http://www.lispcast.com/more-layers http://www.lispcast.com/more-layers Sat 20 Feb 2016 06:19:12 PM CST It's common that adding more layers of abstraction or indirection will make things slower. However, React and ClojureScript make web pages faster than doing it by hand -- essentially programming the bare web. The lesson is that if you choose your layers well, they can actually make your system faster. <p><center><a href="http://www.lispcast.com/more-layers">Read full post</a></center></p> http://www.lispcast.com/reasoning-about-code http://www.lispcast.com/reasoning-about-code Sat 20 Feb 2016 04:37:09 PM CST Functional programmers often use the term "reason about code". It's not very well defined generally, but I use it myself to refer to our ability to use our real-world intuition in our own code. <p><center><a href="http://www.lispcast.com/reasoning-about-code">Read full post</a></center></p> http://www.lispcast.com/immutable-paper http://www.lispcast.com/immutable-paper Wed 10 Feb 2016 12:37:56 PM CST Immutable data appear to contradict our observations of the real world. Things in the world are mutable, so shouldn't our data be mutable, too? It may be counterintuitive, but immutable data does a better job of modeling many of our expectations of the real world. <p><center><a href="http://www.lispcast.com/immutable-paper">Read full post</a></center></p> http://www.lispcast.com/composable-parts http://www.lispcast.com/composable-parts Mon 08 Feb 2016 06:07:28 PM CST Composition is an important idea in programming, and Functional Programming brings it to the forefront. But what does it mean to say things are composable? <p><center><a href="http://www.lispcast.com/composable-parts">Read full post</a></center></p> http://www.lispcast.com/clojure-the-next-level http://www.lispcast.com/clojure-the-next-level Sun 24 Jan 2016 03:29:46 PM CST There are many classics of functional programming that can help you take your thinking to the next level. My recommendations are for making you think in a new way. <p><center><a href="http://www.lispcast.com/clojure-the-next-level">Read full post</a></center></p> http://www.lispcast.com/global-mutable-state http://www.lispcast.com/global-mutable-state Wed 06 Jan 2016 05:13:43 PM CST Global mutable state is one of the biggest drivers of complexity in software systems. We tackle a definition and how to reduce our reliance on it. <p><center><a href="http://www.lispcast.com/global-mutable-state">Read full post</a></center></p> http://www.lispcast.com/imperative-mindset http://www.lispcast.com/imperative-mindset Sat 12 Dec 2015 06:04:21 AM CST Functional programming, from one perspective, is just a collection of habits that affect our programming. I've identified the cues for those habits and a routine for replacing imperative code with functional code. <p><center><a href="http://www.lispcast.com/imperative-mindset">Read full post</a></center></p> http://www.lispcast.com/clojure-ruby-videos http://www.lispcast.com/clojure-ruby-videos Wed 03 Dec 2015 10:51:00 AM CST If you're a Rubyist and you've heard some buzz about Clojure, these videos and links will be just for you. Rubyists teaching Clojure, Clojurists introducing Clojure to Ruby programmers, and Rubyists pontificating on Clojure. <p><center><a href="http://www.lispcast.com/clojure-ruby-videos">Read full post</a></center></p> http://www.lispcast.com/clojure-editors http://www.lispcast.com/clojure-editors Sat 28 Nov 2015 12:00:45 AM CST Professional Clojure programmers rely on certain features of their editors to help them program. When choosing an editor, it's important to pick one that has these two important features: REPL integration and structural editing. <p><center><a href="http://www.lispcast.com/clojure-editors">Read full post</a></center></p> http://www.lispcast.com/100-most-used-clojure-expressions http://www.lispcast.com/100-most-used-clojure-expressions Sat 14 Nov 2015 05:43:51 AM CST Would you like to optimize your learning of Clojure? Would you like to focus on learning only the most useful parts of the language first? Take this lesson from second language learning: learn the expressions in order of frequency of use. <p><center><a href="http://www.lispcast.com/100-most-used-clojure-expressions">Read full post</a></center></p> http://www.lispcast.com/solid-principles-in-clojure http://www.lispcast.com/solid-principles-in-clojure Sun 09 Nov 2015 3:22:01 PM CST The SOLID principles are guidelines for writing good Object-Oriented code. It turns out that these principles are followed and embodied in Clojure. <p><center><a href="http://www.lispcast.com/solid-principles-in-clojure">Read full post</a></center></p> http://www.lispcast.com/where-to-find-time-to-learn-clojure http://www.lispcast.com/where-to-find-time-to-learn-clojure Wed 04 Nov 2015 02:44:41 PM CST Learning any new language is a challenge, and Clojure is no different. Finding the time to learn and practice is a real challenge, so we need to make the most of what time we have. These tips will help you immerse yourself in Clojure. <p><center><a href="http://www.lispcast.com/where-to-find-time-to-learn-clojure">Read full post</a></center></p> http://www.lispcast.com/parens-vs-brackets-in-clojure http://www.lispcast.com/parens-vs-brackets-in-clojure Mon 02 Nov 2015 10:05:06 PM CST Clojure uses both parentheses and square brackets as part of its syntax. It might at first appear to be arbitrary, but it's actually systematic. What's more, it reveals one of the coolest things about Clojure: expressions define how they interpret their arguments. <p><center><a href="http://www.lispcast.com/parens-vs-brackets-in-clojure">Read full post</a></center></p> http://www.lispcast.com/clj-refactor http://www.lispcast.com/clj-refactor Wed 28 Oct 2015 05:31:10 PM CDT I've made some cheatsheets to help me learn clj-refactor, some Emacs software that helps you make systematic changes to code. <p><center><a href="http://www.lispcast.com/clj-refactor">Read full post</a></center></p> http://www.lispcast.com/how-to-read-code-like-a-clojure-expert http://www.lispcast.com/how-to-read-code-like-a-clojure-expert Wed 14 Oct 2015 08:47:09 PM CDT As you get better with Clojure, it becomes easier to read. Why not jump ahead of the learning curve and read like an expert? Focus on the first thing, use the indentation, and read the evaluation order. <p><center><a href="http://www.lispcast.com/how-to-read-code-like-a-clojure-expert">Read full post</a></center></p> http://www.lispcast.com/clojurescript-externs http://www.lispcast.com/clojurescript-externs Sat 20 Sep 2015 01:00:02 PM CDT ClojureScript optimizes names by replacing them with shorter ones. Usually, that's a good thing. But it can get carried away. Externs are how you help it know what's unsafe to optimize. <p><center><a href="http://www.lispcast.com/clojurescript-externs">Read full post</a></center></p> http://www.lispcast.com/testing-clojurescript http://www.lispcast.com/testing-clojurescript Fri 19 Sep 2015 01:41:04 PM CDT Although it's still early, ClojureScript is rapidly maturing its testing story. There are a Leiningen plugin and a Boot task for autocompiling ClojureScript as it changes and running tests in a variety of engines. <p><center><a href="http://www.lispcast.com/testing-clojurescript">Read full post</a></center></p> http://www.lispcast.com/clojurescript-build-times http://www.lispcast.com/clojurescript-build-times Wed 17 Sep 2015 1:14:49 PM CDT ClojureScript builds can take a long time. But the extra time is worth it. It reduces the download size significantly. <p><center><a href="http://www.lispcast.com/clojurescript-build-times">Read full post</a></center></p> http://www.lispcast.com/building-clojurescript-process http://www.lispcast.com/building-clojurescript-process Wed 16 Sep 2015 03:52:12 PM CDT ClojureScript's official build process is a simple shell command. There is also integration into Leiningen and Boot. <p><center><a href="http://www.lispcast.com/building-clojurescript-process">Read full post</a></center></p> http://www.lispcast.com/cljs-dom-manipulation http://www.lispcast.com/cljs-dom-manipulation Tue 15 Sep 2015 01:04:20 PM CDT ClojureScript has some nice DOM manipulation options, including jQuery and more idiomatic libraries. <p><center><a href="http://www.lispcast.com/cljs-dom-manipulation">Read full post</a></center></p> http://www.lispcast.com/what-is-react http://www.lispcast.com/what-is-react Sun 14 Sep 2015 01:00:45 PM CDT React is a view library for web pages that makes DOM rendering in a functional style really easy. React makes web programming fun again. <p><center><a href="http://www.lispcast.com/what-is-react">Read full post</a></center></p> http://www.lispcast.com/clojurescript-fast-start http://www.lispcast.com/clojurescript-fast-start Sat 13 Sep 2015 01:51:28 PM CDT If you know Clojure already and just want to experiment writing ClojureScript, using Figwheel can really help get you there quickly. I show you how in a few commands. <p><center><a href="http://www.lispcast.com/clojurescript-fast-start">Read full post</a></center></p> http://www.lispcast.com/debugging-clojurescript http://www.lispcast.com/debugging-clojurescript Sat 12 Sep 2015 03:03:13 PM CDT Even though ClojureScript adds another layer of abstraction, the tooling makes it easier to debug that plain JavaScript. <p><center><a href="http://www.lispcast.com/debugging-clojurescript">Read full post</a></center></p> http://www.lispcast.com/what-is-clojurescript http://www.lispcast.com/what-is-clojurescript Fri 11 Sep 2015 01:07:15 PM CDT ClojureScript is Clojure that compiles to JavaScript. It combines the power of Clojure with the reach of JavaScript. <p><center><a href="http://www.lispcast.com/what-is-clojurescript">Read full post</a></center></p> http://www.lispcast.com/the-most-important-idea-in-computer-science http://www.lispcast.com/the-most-important-idea-in-computer-science Fri 28 Aug 2015 01:22:35 AM CDT Computer Science has ideas that are important to the broader world. The most important is the Universal Turing Machine. From one perspective, Lisp embodies the idea at its core. To really understand how, I ask you to implement your own Lisp interpreter. <p><center><a href="http://www.lispcast.com/the-most-important-idea-in-computer-science">Read full post</a></center></p> http://www.lispcast.com/lets-tdd-clojure-core-reduce http://www.lispcast.com/lets-tdd-clojure-core-reduce Mon 17 Aug 2015 09:53:32 PM CDT `clojure.core/reduce` is a powerful function, yet the code for it is so simple. It's four lines! We TDD our own implementation. <p><center><a href="http://www.lispcast.com/lets-tdd-clojure-core-reduce">Read full post</a></center></p> http://www.lispcast.com/reduce-example-explained http://www.lispcast.com/reduce-example-explained Mon 10 Aug 2015 09:46:29 PM CDT A deep-dive into a single reduce example shows how much can happen in a short bit of code. <p><center><a href="http://www.lispcast.com/reduce-example-explained">Read full post</a></center></p> http://www.lispcast.com/tdd-clojure-core-map http://www.lispcast.com/tdd-clojure-core-map Tue 04 Aug 2015 11:27:58 PM CDT Learning to write map is a good lesson because it has recursion, list building, and higher order functions. It's everything that makes Lisp great. <p><center><a href="http://www.lispcast.com/tdd-clojure-core-map">Read full post</a></center></p> http://www.lispcast.com/annotated-map http://www.lispcast.com/annotated-map Wed 29 Jul 2015 09:33:06 PM CDT map is one of the staples of functional programming. It's totally useful and also surprisingly simple. Let's look at some examples and annotated code. <p><center><a href="http://www.lispcast.com/annotated-map">Read full post</a></center></p> http://www.lispcast.com/annotated-clojure-core-reduce http://www.lispcast.com/annotated-clojure-core-reduce Tue 21 Jul 2015 10:40:39 PM CDT reduce is a very useful function. You can use it for many calculations over a collection. Code annotations are useful, as are physical metaphors. <p><center><a href="http://www.lispcast.com/annotated-clojure-core-reduce">Read full post</a></center></p> http://www.lispcast.com/reduce-complexity-with-variants http://www.lispcast.com/reduce-complexity-with-variants Wed 08 Jul 2015 11:09:35 PM EDT The structure of our data should match the relevant structures in the real world. And to ensure that our data is structured well, we should reduce the potential for incorrect structure. Variants provide a great solution for it. <p><center><a href="http://www.lispcast.com/reduce-complexity-with-variants">Read full post</a></center></p> http://www.lispcast.com/avoid-naming-at-all-costs http://www.lispcast.com/avoid-naming-at-all-costs Sun 05 Jul 2015 09:51:29 AM CDT If naming is one of the two hardest things in programming, it follows that every other possible solution (except those few involving cache invalidation) should be attempted before naming something. As a corrolary, bad names are a code smell. <p><center><a href="http://www.lispcast.com/avoid-naming-at-all-costs">Read full post</a></center></p> http://www.lispcast.com/mastering-client-side-routing-with-secretary-and-goog-history http://www.lispcast.com/mastering-client-side-routing-with-secretary-and-goog-history Wed 24 Jun 2015 11:27:14 PM CDT The Google Closure Library provides a nice interface to the HTML5 History API. Coupling it with Secretary is very easy. But not all browsers support HTML5 History. In this post I'll talk about one way to make sure you have client-side routing in all browsers. <p><center><a href="http://www.lispcast.com/mastering-client-side-routing-with-secretary-and-goog-history">Read full post</a></center></p> http://www.lispcast.com/clojure-database-test-faster http://www.lispcast.com/clojure-database-test-faster Wed 17 Jun 2015 05:12:05 PM CDT Setting up and tearing down a test database can be slow. Use a rolled back transaction to quickly reset the database to a known state. You can do that in an `:each` fixture to run each test in isolation. <p><center><a href="http://www.lispcast.com/clojure-database-test-faster">Read full post</a></center></p> http://www.lispcast.com/tdd-workflow-in-clojure-with-emacs-and-cider http://www.lispcast.com/tdd-workflow-in-clojure-with-emacs-and-cider Mon 08 Jun 2015 10:15:10 PM CDT TDD is about fast feedback. CIDER tightens the feedback loop with quick commands for running tests and a powerful test reporting system. <p><center><a href="http://www.lispcast.com/tdd-workflow-in-clojure-with-emacs-and-cider">Read full post</a></center></p> http://www.lispcast.com/lambda-abstraction http://www.lispcast.com/lambda-abstraction Sun 17 May 2015 11:40:36 PM CDT Lambda abstractions are always leaky, but some are leakier than others. Clojure programmers recommend keeping most of your functions pure and containing the leaks as much as possible. <p><center><a href="http://www.lispcast.com/lambda-abstraction">Read full post</a></center></p> http://www.lispcast.com/infinite-application http://www.lispcast.com/infinite-application Sun 17 May 2015 10:26:44 PM CDT Function application is a key concept in lambda calculus. While it is commonly expressed using parentheses in Clojure, it is also reified into a function which itself can be applied to another function. <p><center><a href="http://www.lispcast.com/infinite-application">Read full post</a></center></p> http://www.lispcast.com/the-world-is-mutable http://www.lispcast.com/the-world-is-mutable Mon 11 May 2015 11:46:58 PM CDT The world may be mutable, but people have been using the notion of immutability to build reliable systems for a long time. <p><center><a href="http://www.lispcast.com/the-world-is-mutable">Read full post</a></center></p> http://www.lispcast.com/clojure-test-cheatsheet http://www.lispcast.com/clojure-test-cheatsheet Sun 03 May 2015 10:59:22 PM CDT I made a clojure.test cheatsheet that you can get for free. <p><center><a href="http://www.lispcast.com/clojure-test-cheatsheet">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-ron-toland http://www.lispcast.com/pre-west-interview-ron-toland Tue 21 Apr 2015 10:10:26 AM CDT Ront Toland will talk about developing large Clojure applications. <p><center><a href="http://www.lispcast.com/pre-west-interview-ron-toland">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-nathaniel-smith-ruth-linehan http://www.lispcast.com/pre-west-interview-nathaniel-smith-ruth-linehan Tue 21 Apr 2015 10:10:14 AM CDT Nathaniel Smith and Ruth Linehan will talk about developing large applications in Clojure. <p><center><a href="http://www.lispcast.com/pre-west-interview-nathaniel-smith-ruth-linehan">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-leon-barrett http://www.lispcast.com/pre-west-interview-leon-barrett Sun 19 Apr 2015 10:46:07 AM CDT Leon Barrett will talk about parallel programming in Clojure. <p><center><a href="http://www.lispcast.com/pre-west-interview-leon-barrett">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-priyatam-mudivarti http://www.lispcast.com/pre-west-interview-priyatam-mudivarti Sun 19 Apr 2015 10:32:22 AM CDT Priyatam Mudivarti is giving a talk about grid systems in Garden. <p><center><a href="http://www.lispcast.com/pre-west-interview-priyatam-mudivarti">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-elango-cheran http://www.lispcast.com/pre-west-interview-elango-cheran Sun 19 Apr 2015 10:32:10 AM CDT Elango Cheran will talk about translating Clojure to other human languages. <p><center><a href="http://www.lispcast.com/pre-west-interview-elango-cheran">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-robert-krahn http://www.lispcast.com/pre-west-interview-robert-krahn Sun 19 Apr 2015 10:32:00 AM CDT Robert Krahn will talk about bringin Smalltalk features to Clojure. <p><center><a href="http://www.lispcast.com/pre-west-interview-robert-krahn">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-tom-faulhaber http://www.lispcast.com/pre-west-interview-tom-faulhaber Sat 18 Apr 2015 02:11:52 PM CDT Tom Faulhaber interview by Nola. <p><center><a href="http://www.lispcast.com/pre-west-interview-tom-faulhaber">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-tyler-tallman http://www.lispcast.com/pre-west-interview-tyler-tallman Sat 18 Apr 2015 01:59:13 PM CDT Tyler Tallman interview by Nola Stowe. <p><center><a href="http://www.lispcast.com/pre-west-interview-tyler-tallman">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-bruce-hauman http://www.lispcast.com/pre-west-interview-bruce-hauman Sat 18 Apr 2015 01:49:59 PM CDT Bruce Hauman will talk about Figwheel <p><center><a href="http://www.lispcast.com/pre-west-interview-bruce-hauman">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-christopher-small http://www.lispcast.com/pre-west-interview-christopher-small Thu 16 Apr 2015 09:09:46 AM CDT Christopher Small will talk about automating chicken coops with Clojure. <p><center><a href="http://www.lispcast.com/pre-west-interview-christopher-small">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-nathan-sorenson http://www.lispcast.com/pre-west-interview-nathan-sorenson Wed 15 Apr 2015 11:43:27 PM CDT Nathan Sorenson interview by Nola. <p><center><a href="http://www.lispcast.com/pre-west-interview-nathan-sorenson">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-james-macaulay http://www.lispcast.com/pre-west-interview-james-macaulay Wed 15 Apr 2015 11:43:16 PM CDT James MacAulay interview by Nola. <p><center><a href="http://www.lispcast.com/pre-west-interview-james-macaulay">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-zach-tellman http://www.lispcast.com/pre-west-interview-zach-tellman Wed 15 Apr 2015 11:43:01 PM CDT Zach Tellman interview by Nola. <p><center><a href="http://www.lispcast.com/pre-west-interview-zach-tellman">Read full post</a></center></p> http://www.lispcast.com/pre-west-nathan-sorenson http://www.lispcast.com/pre-west-nathan-sorenson Wed 15 Apr 2015 11:10:22 PM CDT Nathan Sorenson will talk about type systems and macros. <p><center><a href="http://www.lispcast.com/pre-west-nathan-sorenson">Read full post</a></center></p> http://www.lispcast.com/pre-west-james-macaulay http://www.lispcast.com/pre-west-james-macaulay Wed 15 Apr 2015 10:45:56 PM CDT James MacAulay will talk about Zelkova and FRP. <p><center><a href="http://www.lispcast.com/pre-west-james-macaulay">Read full post</a></center></p> http://www.lispcast.com/pre-west-zach-tellman http://www.lispcast.com/pre-west-zach-tellman Wed 15 Apr 2015 10:31:34 PM CDT Zach Tellman will talk about Queueing Theory. <p><center><a href="http://www.lispcast.com/pre-west-zach-tellman">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-fumiko-hanreich http://www.lispcast.com/pre-west-interview-fumiko-hanreich Wed 15 Apr 2015 09:30:06 PM CDT Fumiko Hanreich interview by Nola. <p><center><a href="http://www.lispcast.com/pre-west-interview-fumiko-hanreich">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-morgan-mullaney http://www.lispcast.com/pre-west-interview-morgan-mullaney Wed 15 Apr 2015 01:35:01 PM CDT Morgan Mullaney interview by Nola. <p><center><a href="http://www.lispcast.com/pre-west-interview-morgan-mullaney">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-elena-machkasova http://www.lispcast.com/pre-west-interview-elena-machkasova Wed 15 Apr 2015 01:17:55 PM CDT Elena Machkasova interview by Nola. <p><center><a href="http://www.lispcast.com/pre-west-interview-elena-machkasova">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-luke-vanderhart http://www.lispcast.com/pre-west-interview-luke-vanderhart Wed 15 Apr 2015 12:57:28 PM CDT Luke VanderHart interview by Nola. <p><center><a href="http://www.lispcast.com/pre-west-interview-luke-vanderhart">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-ryan-neufeld http://www.lispcast.com/pre-west-interview-ryan-neufeld Tue 14 Apr 2015 11:33:53 PM CDT Ryan Neufeld interview by Nola. <p><center><a href="http://www.lispcast.com/pre-west-interview-ryan-neufeld">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-john-hume http://www.lispcast.com/pre-west-interview-john-hume Tue 14 Apr 2015 01:39:07 PM CDT John Hume interview by Nola. <p><center><a href="http://www.lispcast.com/pre-west-interview-john-hume">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-yoko-harada http://www.lispcast.com/pre-west-interview-yoko-harada Fri 10 Apr 2015 09:35:05 PM CDT Yoko Harada interview by Nola. <p><center><a href="http://www.lispcast.com/pre-west-interview-yoko-harada">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-anthony-marcar http://www.lispcast.com/pre-west-interview-anthony-marcar Fri 10 Apr 2015 09:32:03 PM CDT Anthony Marcar will talk about large-scale production Clojure applications. <p><center><a href="http://www.lispcast.com/pre-west-interview-anthony-marcar">Read full post</a></center></p> http://www.lispcast.com/pre-west-luke-vanderhart http://www.lispcast.com/pre-west-luke-vanderhart Thu 09 Apr 2015 04:15:58 PM CDT Luke Vanderhart will talk about ReactJS. <p><center><a href="http://www.lispcast.com/pre-west-luke-vanderhart">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-brandon-bloom http://www.lispcast.com/pre-west-interview-brandon-bloom Thu 09 Apr 2015 04:00:45 PM CDT Brandon Bloom will talk about Om. <p><center><a href="http://www.lispcast.com/pre-west-interview-brandon-bloom">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-gary-fredericks http://www.lispcast.com/pre-west-interview-gary-fredericks Thu 09 Apr 2015 01:45:04 PM CDT Gary Fredericks interview by Nola. <p><center><a href="http://www.lispcast.com/pre-west-interview-gary-fredericks">Read full post</a></center></p> http://www.lispcast.com/pre-west-zachary-kim http://www.lispcast.com/pre-west-zachary-kim Thu 09 Apr 2015 09:28:16 AM CDT Zachary Kim will talk about mobile development in Clojure. <p><center><a href="http://www.lispcast.com/pre-west-zachary-kim">Read full post</a></center></p> http://www.lispcast.com/pre-west-tyler-tallman http://www.lispcast.com/pre-west-tyler-tallman Wed 08 Apr 2015 06:12:04 PM CDT Tyler Tallman will talk about modeling complex problems in Clojure. <p><center><a href="http://www.lispcast.com/pre-west-tyler-tallman">Read full post</a></center></p> http://www.lispcast.com/pre-west-soren-macbeth http://www.lispcast.com/pre-west-soren-macbeth Mon 06 Apr 2015 11:30:52 PM CDT Soren Macbeth will talk about data crunching in Clojure. <p><center><a href="http://www.lispcast.com/pre-west-soren-macbeth">Read full post</a></center></p> http://www.lispcast.com/pre-west-timothy-gardner-ramsey-nasser http://www.lispcast.com/pre-west-timothy-gardner-ramsey-nasser Mon 06 Apr 2015 11:30:52 PM CDT Timothy Gardner and Ramsey Nasser will talk about Arcadia. <p><center><a href="http://www.lispcast.com/pre-west-timothy-gardner-ramsey-nasser">Read full post</a></center></p> http://www.lispcast.com/pre-west-sean-johnson http://www.lispcast.com/pre-west-sean-johnson Mon 06 Apr 2015 11:29:45 PM CDT Sean Johnson will talk about pattern matching. <p><center><a href="http://www.lispcast.com/pre-west-sean-johnson">Read full post</a></center></p> http://www.lispcast.com/pre-west-tom-faulhaber http://www.lispcast.com/pre-west-tom-faulhaber Mon 06 Apr 2015 11:29:45 PM CDT Tom Faulhaber will talk about generating Excel sheets. <p><center><a href="http://www.lispcast.com/pre-west-tom-faulhaber">Read full post</a></center></p> http://www.lispcast.com/pre-west-ron-toland http://www.lispcast.com/pre-west-ron-toland Mon 06 Apr 2015 09:36:49 PM CDT Ron Toland will talk about large-scale Clojure systems. <p><center><a href="http://www.lispcast.com/pre-west-ron-toland">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-colin-fleming http://www.lispcast.com/pre-west-interview-colin-fleming Sun 05 Apr 2015 04:59:35 PM CDT Colin Fleming will talk about debugging in Cursive. <p><center><a href="http://www.lispcast.com/pre-west-interview-colin-fleming">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-melanie-mitchell http://www.lispcast.com/pre-west-interview-melanie-mitchell Sun 05 Apr 2015 04:26:48 PM CDT Melanie Mitchell will talk about computer systems that recognize visual situations. <p><center><a href="http://www.lispcast.com/pre-west-interview-melanie-mitchell">Read full post</a></center></p> http://www.lispcast.com/pre-west-ryan-neufeld http://www.lispcast.com/pre-west-ryan-neufeld Sun 05 Apr 2015 11:44:16 AM CDT Ryan Neufeld will talk about simulation testing. <p><center><a href="http://www.lispcast.com/pre-west-ryan-neufeld">Read full post</a></center></p> http://www.lispcast.com/pre-west-robert-krahn http://www.lispcast.com/pre-west-robert-krahn Sun 05 Apr 2015 11:14:03 AM CDT Robert Krahn will talk about cloxp. <p><center><a href="http://www.lispcast.com/pre-west-robert-krahn">Read full post</a></center></p> http://www.lispcast.com/pre-west-priyatam-mudivarti http://www.lispcast.com/pre-west-priyatam-mudivarti Sat 04 Apr 2015 10:54:48 PM CDT Priyatam Mudivarti will talk about generating CSS with Garden. <p><center><a href="http://www.lispcast.com/pre-west-priyatam-mudivarti">Read full post</a></center></p> http://www.lispcast.com/pre-west-nathaniel-smith-ruth-linehan http://www.lispcast.com/pre-west-nathaniel-smith-ruth-linehan Sat 04 Apr 2015 10:40:47 PM CDT Nathaniel Smith and Ruth Linehan will talk about Trapperkeeper. <p><center><a href="http://www.lispcast.com/pre-west-nathaniel-smith-ruth-linehan">Read full post</a></center></p> http://www.lispcast.com/pre-west-leon-barrett http://www.lispcast.com/pre-west-leon-barrett Sat 04 Apr 2015 02:55:03 PM CDT Leon Barrett will talk about parallelism in Clojure. <p><center><a href="http://www.lispcast.com/pre-west-leon-barrett">Read full post</a></center></p> http://www.lispcast.com/pre-west-morgan-mullaney http://www.lispcast.com/pre-west-morgan-mullaney Sat 04 Apr 2015 02:07:28 PM CDT Morgan Mullaney will talk about functional game programming. <p><center><a href="http://www.lispcast.com/pre-west-morgan-mullaney">Read full post</a></center></p> http://www.lispcast.com/pre-west-jeanine-adkisson http://www.lispcast.com/pre-west-jeanine-adkisson Fri 03 Apr 2015 11:49:08 PM CDT Jeanine Adkisson will talk about prototyping a language in Clojure. <p><center><a href="http://www.lispcast.com/pre-west-jeanine-adkisson">Read full post</a></center></p> http://www.lispcast.com/pre-west-elena-machkasova http://www.lispcast.com/pre-west-elena-machkasova Fri 03 Apr 2015 10:07:16 PM CDT Elena Machkasova will talk about teaching Clojure to novice programmers. <p><center><a href="http://www.lispcast.com/pre-west-elena-machkasova">Read full post</a></center></p> http://www.lispcast.com/pre-west-gary-fredericks http://www.lispcast.com/pre-west-gary-fredericks Fri 03 Apr 2015 10:07:16 PM CDT Gary Fredericks will talk about functional random number generators. <p><center><a href="http://www.lispcast.com/pre-west-gary-fredericks">Read full post</a></center></p> http://www.lispcast.com/pre-west-interview-alan-dipert-micha-niskin http://www.lispcast.com/pre-west-interview-alan-dipert-micha-niskin Fri 03 Apr 2015 10:07:08 PM CDT Alan Dipert and Micha Niskin will talk about Boot. <p><center><a href="http://www.lispcast.com/pre-west-interview-alan-dipert-micha-niskin">Read full post</a></center></p> http://www.lispcast.com/pre-west-fumiko-hanreich http://www.lispcast.com/pre-west-fumiko-hanreich Mon 30 Mar 2015 11:09:44 PM EDT Fumiko Hanreich will talk about HoneySQL. <p><center><a href="http://www.lispcast.com/pre-west-fumiko-hanreich">Read full post</a></center></p> http://www.lispcast.com/clojure-test-directory http://www.lispcast.com/clojure-test-directory Mon 30 Mar 2015 10:55:57 PM EDT Where to put your tests is a common question. You could put them anywhere, but you want to pick a place that makes it easy to find, easy to exclude from production, and work well with your tools. My recommendation is to follow what most projects do, which takes care of all of these requirements. <p><center><a href="http://www.lispcast.com/clojure-test-directory">Read full post</a></center></p> http://www.lispcast.com/pre-west-john-hume http://www.lispcast.com/pre-west-john-hume Sun 29 Mar 2015 07:18:19 PM CDT Life of a clojure expression: a quick tour of clojure internals <p><center><a href="http://www.lispcast.com/pre-west-john-hume">Read full post</a></center></p> http://www.lispcast.com/pre-west-yoko-harada http://www.lispcast.com/pre-west-yoko-harada Sun 29 Mar 2015 07:05:22 PM CDT Yoko Harada will be speaking on ClojureBridge and the challenges of writing a curriculum for beginner programmers. <p><center><a href="http://www.lispcast.com/pre-west-yoko-harada">Read full post</a></center></p> http://www.lispcast.com/clojure-test-launch http://www.lispcast.com/clojure-test-launch Sat 28 Mar 2015 01:36:41 PM CDT LispCast Intro to clojure.test will launch this week. <p><center><a href="http://www.lispcast.com/clojure-test-launch">Read full post</a></center></p> http://www.lispcast.com/unit-testing-in-functional-languages http://www.lispcast.com/unit-testing-in-functional-languages Thu 26 Mar 2015 11:36:28 AM CDT Unit testing in Clojure is straightforward. Here are a few testing ideas as they apply to Clojure. <p><center><a href="http://www.lispcast.com/unit-testing-in-functional-languages">Read full post</a></center></p> http://www.lispcast.com/conj-mental-bump http://www.lispcast.com/conj-mental-bump Mon 23 Mar 2015 11:18:42 PM CDT conj can be confusing if you're used to other languages. It is not a commonly defined operation. Most languages define common positional adding operations. conj, however, has more useful semantics. How do you use conj usefully if you can't guarantee the position? <p><center><a href="http://www.lispcast.com/conj-mental-bump">Read full post</a></center></p> http://www.lispcast.com/pre-west-elango-cheran http://www.lispcast.com/pre-west-elango-cheran Sat 21 Mar 2015 11:28:46 PM CDT Elango Cheran will talk about writing Clojure in other spoken languages. <p><center><a href="http://www.lispcast.com/pre-west-elango-cheran">Read full post</a></center></p> http://www.lispcast.com/pre-west-dan-lidral-porter http://www.lispcast.com/pre-west-dan-lidral-porter Sat 21 Mar 2015 10:33:56 PM CDT Dan Lidral-Porter will talk about computer-generated art in Clojure. <p><center><a href="http://www.lispcast.com/pre-west-dan-lidral-porter">Read full post</a></center></p> http://www.lispcast.com/pre-west-colin-fleming http://www.lispcast.com/pre-west-colin-fleming Sat 21 Mar 2015 09:35:14 PM CDT Colin Fleming will talk about debugging in Cursive. <p><center><a href="http://www.lispcast.com/pre-west-colin-fleming">Read full post</a></center></p> http://www.lispcast.com/pre-west-christopher-small http://www.lispcast.com/pre-west-christopher-small Fri 20 Mar 2015 11:01:14 PM CDT Christopher Small will speak about raising chickens with Clojure. <p><center><a href="http://www.lispcast.com/pre-west-christopher-small">Read full post</a></center></p> http://www.lispcast.com/pre-west-bruce-hauman http://www.lispcast.com/pre-west-bruce-hauman Fri 20 Mar 2015 10:28:55 PM CDT Bruce Hauman will speak about Figwheel. <p><center><a href="http://www.lispcast.com/pre-west-bruce-hauman">Read full post</a></center></p> http://www.lispcast.com/pre-west-brandon-bloom http://www.lispcast.com/pre-west-brandon-bloom Fri 20 Mar 2015 01:57:40 AM CDT Brandon Bloom will talk about Om. <p><center><a href="http://www.lispcast.com/pre-west-brandon-bloom">Read full post</a></center></p> http://www.lispcast.com/pre-west-boris-kourtoukov http://www.lispcast.com/pre-west-boris-kourtoukov Wed 18 Mar 2015 09:56:01 PM CDT Boris Kourtoukov will talk about Clojure and wearables. <p><center><a href="http://www.lispcast.com/pre-west-boris-kourtoukov">Read full post</a></center></p> http://www.lispcast.com/pre-west-anthony-marcar http://www.lispcast.com/pre-west-anthony-marcar Wed 18 Mar 2015 09:21:45 PM CDT Anthony Marcar will talk about Clojure in the enterprise. <p><center><a href="http://www.lispcast.com/pre-west-anthony-marcar">Read full post</a></center></p> http://www.lispcast.com/pre-west-alan-dipert-micha-niskin http://www.lispcast.com/pre-west-alan-dipert-micha-niskin Wed 18 Mar 2015 09:26:24 AM CDT Alan Dipert and Micha Niskin will talk about Boot. <p><center><a href="http://www.lispcast.com/pre-west-alan-dipert-micha-niskin">Read full post</a></center></p> http://www.lispcast.com/pre-west-melanie-mitchell http://www.lispcast.com/pre-west-melanie-mitchell Tue 17 Mar 2015 11:22:56 PM CDT Melanie Mitchell will talk about computer systems that recognize visual situations. <p><center><a href="http://www.lispcast.com/pre-west-melanie-mitchell">Read full post</a></center></p> http://www.lispcast.com/pre-west-2015 http://www.lispcast.com/pre-west-2015 Tue 17 Mar 2015 05:03:06 PM CDT Prepare for Clojure/West with media from around the web and interviews. <p><center><a href="http://www.lispcast.com/pre-west-2015">Read full post</a></center></p> http://www.lispcast.com/learning-is-about-skills http://www.lispcast.com/learning-is-about-skills Fri 13 Mar 2015 10:10:30 PM CDT Most technical writing is obtuse unless you already know the topic. Focus on the learner and their skills and it will clarify your writing. <p><center><a href="http://www.lispcast.com/learning-is-about-skills">Read full post</a></center></p> http://www.lispcast.com/exponential-backoff http://www.lispcast.com/exponential-backoff Fri 13 Mar 2015 02:01:59 PM CDT A common failure in distributed systems is a server with a rate limit or with no limit but begins failing due to load. A standard solution is to retry after waiting a small time, increasing that time after each failure. We create a macro to handle this waiting and retrying. <p><center><a href="http://www.lispcast.com/exponential-backoff">Read full post</a></center></p> http://www.lispcast.com/solarized-cheat-sheet http://www.lispcast.com/solarized-cheat-sheet Wed 11 Mar 2015 06:22:48 PM CDT Solarized is an awesome color scheme that I use all the time. I was tired of looking up the hex codes, so I made my own cheat sheet. You can download it. <p><center><a href="http://www.lispcast.com/solarized-cheat-sheet">Read full post</a></center></p> http://www.lispcast.com/object-function-duals-dispatch http://www.lispcast.com/object-function-duals-dispatch Wed 11 Mar 2015 02:56:53 PM CDT Object-oriented dispatch is contrasted with functional dispatch, but they are shown to be two one-dimensional projections of the same two-dimensional data. Clojure does not provide the two-dimensional representation, but does interesting things to transcend the one-dimensional views. <p><center><a href="http://www.lispcast.com/object-function-duals-dispatch">Read full post</a></center></p> http://www.lispcast.com/task-analysis http://www.lispcast.com/task-analysis Sat 07 Mar 2015 11:29:06 PM CST Many technical books skip very important skills you need to complete a task. To avoid skipping those skills, use task analysis to break a skill into steps. <p><center><a href="http://www.lispcast.com/task-analysis">Read full post</a></center></p> http://www.lispcast.com/try-three-times http://www.lispcast.com/try-three-times Thu 05 Mar 2015 03:44:38 PM CST Distributed systems fail in indistinguishable ways. Often, retrying is a good solution to intermittent errors. We create a retry macro to handle the retries in a generic way. <p><center><a href="http://www.lispcast.com/try-three-times">Read full post</a></center></p> http://www.lispcast.com/data-first-programming http://www.lispcast.com/data-first-programming Fri 27 Feb 2015 05:08:54 PM CST If something is important, you should deal with it sooner and more often. That's the approach Clojure takes to data representations. It means serialization of internal data is a non-issue. <p><center><a href="http://www.lispcast.com/data-first-programming">Read full post</a></center></p> http://www.lispcast.com/paper-metaphor http://www.lispcast.com/paper-metaphor Fri 27 Feb 2015 12:57:38 PM CST Functional programs follow a simple rule: never write on the same paper twice. Imperative programs are free to define their own rules. Both have interesting consequences. <p><center><a href="http://www.lispcast.com/paper-metaphor">Read full post</a></center></p> http://www.lispcast.com/intro-clojure-test-peap http://www.lispcast.com/intro-clojure-test-peap Fri 27 Feb 2015 09:06:45 AM CST LispCast Intro to clojure.test is on sale now for a limited time through the PurelyFunctional.tv Early Access Program. <p><center><a href="http://www.lispcast.com/intro-clojure-test-peap">Read full post</a></center></p> http://www.lispcast.com/purelyfunctional-tv-early-access-program http://www.lispcast.com/purelyfunctional-tv-early-access-program Wed 25 Feb 2015 12:43:10 PM CST The PurelyFunctional.tv Early Access Program is a way to make courses in a more iterative and interactive way. I'll be publishing Intro to clojure.test this week under PEAP. <p><center><a href="http://www.lispcast.com/purelyfunctional-tv-early-access-program">Read full post</a></center></p> http://www.lispcast.com/hiccup-tips http://www.lispcast.com/hiccup-tips Tue 24 Feb 2015 11:53:48 AM CST Hiccup is a Clojure DSL for generating HTML. If you're using it, you might like these tips. <p><center><a href="http://www.lispcast.com/hiccup-tips">Read full post</a></center></p> http://www.lispcast.com/announcing-lispcast-intro-to-clojure-test http://www.lispcast.com/announcing-lispcast-intro-to-clojure-test Mon 23 Feb 2015 09:37:54 PM CST The next course will be about clojure.test. Sign up to be notified when it is published. <p><center><a href="http://www.lispcast.com/announcing-lispcast-intro-to-clojure-test">Read full post</a></center></p> http://www.lispcast.com/new-course-format http://www.lispcast.com/new-course-format Fri 20 Feb 2015 03:01:08 PM CST LispCast video courses have a new, interactive format. It's easier for me to make courses (read: more, faster) and it's a better experience for learners. <p><center><a href="http://www.lispcast.com/new-course-format">Read full post</a></center></p> http://www.lispcast.com/parts-of-ring http://www.lispcast.com/parts-of-ring Wed 18 Feb 2015 11:12:29 PM CST Ring, the Clojure Web library, defines three main concepts that you use to construct web applications. <p><center><a href="http://www.lispcast.com/parts-of-ring">Read full post</a></center></p> http://www.lispcast.com/object-oriented-vs-functional-duals http://www.lispcast.com/object-oriented-vs-functional-duals Sun 08 Feb 2015 11:22:31 AM CST Object-Oriented Programming is often shown in contrast to Functional Programming. But they are so exactly opposite that they are duals, and so equivalent in important ways. Which one to use should be left up to the programmer, as is done in Clojure and Javascript. <p><center><a href="http://www.lispcast.com/object-oriented-vs-functional-duals">Read full post</a></center></p> http://www.lispcast.com/clojure-gazette-looking-forward-2015 http://www.lispcast.com/clojure-gazette-looking-forward-2015 Mon 19 Jan 2015 02:18:48 PM CST I am looking for more sponsors for the Clojure Gazette and I need your help. <p><center><a href="http://www.lispcast.com/clojure-gazette-looking-forward-2015">Read full post</a></center></p> http://www.lispcast.com/how-to-write-software http://www.lispcast.com/how-to-write-software Thu 08 Jan 2015 11:22:27 AM CST Writing software alone and in a long term sustainable manner requires a lot of discipline. Upfront planning and avoidance of feature creep can turn a stressful project into a pleasure. <p><center><a href="http://www.lispcast.com/how-to-write-software">Read full post</a></center></p> http://www.lispcast.com/data-functions-macros-why http://www.lispcast.com/data-functions-macros-why Tue 23 Dec 2014 11:29:44 PM CST "Prefer data over functions" is a common adage in Clojure circles. It is poorly debated because it is a terse statement in generalities. A valuable perspective is that data is transparent at runtime, while functions are not. This perspective gives a firm ground for discussion and design. <p><center><a href="http://www.lispcast.com/data-functions-macros-why">Read full post</a></center></p> http://www.lispcast.com/ultimate-guide-to-learning-clojure-for-free http://www.lispcast.com/ultimate-guide-to-learning-clojure-for-free Thu 11 Dec 2014 09:34:58 AM CST There are many great resources out there for learning Clojure. Some of the resources are paid, but fortunately many of the best resources are absolutely free. <p><center><a href="http://www.lispcast.com/ultimate-guide-to-learning-clojure-for-free">Read full post</a></center></p> http://www.lispcast.com/pre-conj-scheme-workshop http://www.lispcast.com/pre-conj-scheme-workshop Mon 17 Nov 2014 11:12:36 PM CST Jason Hemann talks about the Scheme Workshop. <p><center><a href="http://www.lispcast.com/pre-conj-scheme-workshop">Read full post</a></center></p> http://www.lispcast.com/elm-frp-clojure-core-async http://www.lispcast.com/elm-frp-clojure-core-async Fri 14 Nov 2014 04:15:34 PM CST Elm is an exciting FRP language. I implemented the FRP part in Clojure using core.async. <p><center><a href="http://www.lispcast.com/elm-frp-clojure-core-async">Read full post</a></center></p> http://www.lispcast.com/core-async-conveyor-belts-true-history http://www.lispcast.com/core-async-conveyor-belts-true-history Thu 13 Nov 2014 01:25:18 PM CST Conveyor belts are strikingly similar to Clojure core.async channels. While it could be a coincidence, there is speculation that conveyor belts were influenced by a deep understanding of core.async. <p><center><a href="http://www.lispcast.com/core-async-conveyor-belts-true-history">Read full post</a></center></p> http://www.lispcast.com/token-buckets-in-core-async http://www.lispcast.com/token-buckets-in-core-async Mon 10 Nov 2014 08:58:57 PM CST Token Bucket is a simple algorithm for rate limiting a resource. It's easy to understand because you can reason about it in terms of real-world objects. core.async makes this algorithm very clear and easy. <p><center><a href="http://www.lispcast.com/token-buckets-in-core-async">Read full post</a></center></p> http://www.lispcast.com/pre-conj-interview-steven-yi http://www.lispcast.com/pre-conj-interview-steven-yi Mon 27 Oct 2014 09:44:13 AM CDT Steven Yi interview about his music composition and synthesis systems. <p><center><a href="http://www.lispcast.com/pre-conj-interview-steven-yi">Read full post</a></center></p> http://www.lispcast.com/pre-conj-interview-bozhidar-batsov http://www.lispcast.com/pre-conj-interview-bozhidar-batsov Sun 26 Oct 2014 09:38:02 AM CDT Bozhidar Batsov interview about CIDER. <p><center><a href="http://www.lispcast.com/pre-conj-interview-bozhidar-batsov">Read full post</a></center></p> http://www.lispcast.com/pre-conj-interview-paul-degrandis http://www.lispcast.com/pre-conj-interview-paul-degrandis Sat 25 Oct 2014 09:59:39 AM CDT Paul deGrandis interview about data-driven systems. <p><center><a href="http://www.lispcast.com/pre-conj-interview-paul-degrandis">Read full post</a></center></p> http://www.lispcast.com/pre-conj-interview-anna-pawlicka http://www.lispcast.com/pre-conj-interview-anna-pawlicka Fri 24 Oct 2014 10:35:29 PM CDT Anna Pawlicka interview about Om. <p><center><a href="http://www.lispcast.com/pre-conj-interview-anna-pawlicka">Read full post</a></center></p> http://www.lispcast.com/pre-conj-interview-julian-gamble http://www.lispcast.com/pre-conj-interview-julian-gamble Fri 24 Oct 2014 10:34:36 PM CDT Julian Gamble interview about core.async and ClojureScript. <p><center><a href="http://www.lispcast.com/pre-conj-interview-julian-gamble">Read full post</a></center></p> http://www.lispcast.com/pre-conj-interview-zach-tellman http://www.lispcast.com/pre-conj-interview-zach-tellman Thu 23 Oct 2014 11:29:13 AM CDT Zach Tellman interview about his talk about composition. <p><center><a href="http://www.lispcast.com/pre-conj-interview-zach-tellman">Read full post</a></center></p> http://www.lispcast.com/pre-conj-interview-zach-oakes http://www.lispcast.com/pre-conj-interview-zach-oakes Wed 22 Oct 2014 09:11:47 AM CDT Zach Oakes interview about games in Clojure. <p><center><a href="http://www.lispcast.com/pre-conj-interview-zach-oakes">Read full post</a></center></p> http://www.lispcast.com/pre-conj-interview-colin-fleming http://www.lispcast.com/pre-conj-interview-colin-fleming Tue 21 Oct 2014 10:04:32 AM CDT Colin Fleming interview about Cursive Clojure. <p><center><a href="http://www.lispcast.com/pre-conj-interview-colin-fleming">Read full post</a></center></p> http://www.lispcast.com/pre-conj-interview-ashton-kemerling http://www.lispcast.com/pre-conj-interview-ashton-kemerling Mon 20 Oct 2014 09:36:09 AM CDT Ashton Kemerling interview about generative testing. <p><center><a href="http://www.lispcast.com/pre-conj-interview-ashton-kemerling">Read full post</a></center></p> http://www.lispcast.com/pre-conj-interview-steve-miner http://www.lispcast.com/pre-conj-interview-steve-miner Sun 19 Oct 2014 09:15:48 AM CDT Steve Miner talk about generating test.check generators. <p><center><a href="http://www.lispcast.com/pre-conj-interview-steve-miner">Read full post</a></center></p> http://www.lispcast.com/pre-conj-interview-jeanine-adkisson http://www.lispcast.com/pre-conj-interview-jeanine-adkisson Sat 18 Oct 2014 01:43:27 PM CDT Jeanine Adkisson interview about variants. <p><center><a href="http://www.lispcast.com/pre-conj-interview-jeanine-adkisson">Read full post</a></center></p> http://www.lispcast.com/pre-conj-interview-lucas-cavalcanti http://www.lispcast.com/pre-conj-interview-lucas-cavalcanti Fri 17 Oct 2014 10:59:24 AM CDT Lucas Cavalcanti interview about Datomic superpowers. <p><center><a href="http://www.lispcast.com/pre-conj-interview-lucas-cavalcanti">Read full post</a></center></p> http://www.lispcast.com/pre-conj-interview-david-pick http://www.lispcast.com/pre-conj-interview-david-pick Wed 15 Oct 2014 09:04:25 AM CDT David Pick interview about Kafka and Clojure. <p><center><a href="http://www.lispcast.com/pre-conj-interview-david-pick">Read full post</a></center></p> http://www.lispcast.com/pre-conj-zach-tellman http://www.lispcast.com/pre-conj-zach-tellman Mon 13 Oct 2014 12:50:39 PM CDT Zach Tellman will talk about building composable software. <p><center><a href="http://www.lispcast.com/pre-conj-zach-tellman">Read full post</a></center></p> http://www.lispcast.com/pre-conj-zach-oakes http://www.lispcast.com/pre-conj-zach-oakes Sun 12 Oct 2014 08:29:03 PM CDT Zach Oakes will talk about making games at runtime. <p><center><a href="http://www.lispcast.com/pre-conj-zach-oakes">Read full post</a></center></p> http://www.lispcast.com/pre-conj-paul-degrandis http://www.lispcast.com/pre-conj-paul-degrandis Sun 12 Oct 2014 08:28:45 PM CDT Paul deGrandis will talk about Data-Driven Systems. <p><center><a href="http://www.lispcast.com/pre-conj-paul-degrandis">Read full post</a></center></p> http://www.lispcast.com/pre-conj-steven-yi http://www.lispcast.com/pre-conj-steven-yi Fri 10 Oct 2014 02:40:26 PM CDT Steven Yi will talk about music systems on the JVM. <p><center><a href="http://www.lispcast.com/pre-conj-steven-yi">Read full post</a></center></p> http://www.lispcast.com/willy-wonka-core-async http://www.lispcast.com/willy-wonka-core-async Fri 10 Oct 2014 12:08:19 PM CDT There are a few conventions in core.async that are not hard to use once you've learned them. But learning them without help can be tedious. This article presents three guidelines that will get you through the learning curve. <p><center><a href="http://www.lispcast.com/willy-wonka-core-async">Read full post</a></center></p> http://www.lispcast.com/pre-conj-steve-miner http://www.lispcast.com/pre-conj-steve-miner Thu 09 Oct 2014 08:54:32 AM CDT Steve Miner will talk about generating test.check generators. <p><center><a href="http://www.lispcast.com/pre-conj-steve-miner">Read full post</a></center></p> http://www.lispcast.com/pre-conj-nathan-herzing-chris-shea http://www.lispcast.com/pre-conj-nathan-herzing-chris-shea Tue 07 Oct 2014 10:40:13 AM CDT Nathan Herzing and Chris Shea will talk about Pedestal, Om, Datomic, and core.async. <p><center><a href="http://www.lispcast.com/pre-conj-nathan-herzing-chris-shea">Read full post</a></center></p> http://www.lispcast.com/the-content-of-your-code http://www.lispcast.com/the-content-of-your-code Mon 06 Oct 2014 02:25:46 PM CDT Code style is important, but way less important than content. Yet everyone talks about style because it's easier. Let's talk about content. <p><center><a href="http://www.lispcast.com/the-content-of-your-code">Read full post</a></center></p> http://www.lispcast.com/pre-conj-michal-marczyk http://www.lispcast.com/pre-conj-michal-marczyk Mon 06 Oct 2014 10:50:02 AM CDT Michał Marczyk will talk about Persistent Data Structures. <p><center><a href="http://www.lispcast.com/pre-conj-michal-marczyk">Read full post</a></center></p> http://www.lispcast.com/pre-conj-julian-gamble http://www.lispcast.com/pre-conj-julian-gamble Sat 04 Oct 2014 06:26:54 PM CDT Julian Gamble will give a talk about core.async in ClojureScript. <p><center><a href="http://www.lispcast.com/pre-conj-julian-gamble">Read full post</a></center></p> http://www.lispcast.com/pre-conj-rich-hickey http://www.lispcast.com/pre-conj-rich-hickey Fri 03 Oct 2014 09:02:39 PM CDT Rich Hickey will talk about Transducers. <p><center><a href="http://www.lispcast.com/pre-conj-rich-hickey">Read full post</a></center></p> http://www.lispcast.com/pre-conj-jeanine-adkisson http://www.lispcast.com/pre-conj-jeanine-adkisson Fri 03 Oct 2014 09:13:42 AM CDT Jeanine Adkisson will give a talk about Variants in Clojure at the Clojure/conj 2014. <p><center><a href="http://www.lispcast.com/pre-conj-jeanine-adkisson">Read full post</a></center></p> http://www.lispcast.com/pre-conj-glenn-vanderburg http://www.lispcast.com/pre-conj-glenn-vanderburg Thu 02 Oct 2014 09:04:18 AM CDT Glenn Vanderburg will talk about implementing the TeX algorithms in Clojure. <p><center><a href="http://www.lispcast.com/pre-conj-glenn-vanderburg">Read full post</a></center></p> http://www.lispcast.com/pre-conj-lucas-cavalcanti-edward-wible http://www.lispcast.com/pre-conj-lucas-cavalcanti-edward-wible Wed 01 Oct 2014 02:25:56 PM CDT Lucas Cavalcanti and Edward Wible will talk about Datomic. <p><center><a href="http://www.lispcast.com/pre-conj-lucas-cavalcanti-edward-wible">Read full post</a></center></p> http://www.lispcast.com/pre-conj-ghadi-shayban http://www.lispcast.com/pre-conj-ghadi-shayban Wed 01 Oct 2014 09:31:49 AM CDT Ghadi Shayban will talk about the JVM. <p><center><a href="http://www.lispcast.com/pre-conj-ghadi-shayban">Read full post</a></center></p> http://www.lispcast.com/pre-conj-david-pick http://www.lispcast.com/pre-conj-david-pick Tue 30 Sep 2014 11:18:21 PM CDT David Pick will talk about using Kafka from Clojure. <p><center><a href="http://www.lispcast.com/pre-conj-david-pick">Read full post</a></center></p> http://www.lispcast.com/pre-conj-colin-fleming http://www.lispcast.com/pre-conj-colin-fleming Mon 29 Sep 2014 10:49:29 AM CDT Colin Fleming will talk about Cursive Clojure. <p><center><a href="http://www.lispcast.com/pre-conj-colin-fleming">Read full post</a></center></p> http://www.lispcast.com/pre-conj-brian-goetz http://www.lispcast.com/pre-conj-brian-goetz Sun 28 Sep 2014 10:45:08 AM CDT Brian Goetz will give the keynote at Clojure/conj. <p><center><a href="http://www.lispcast.com/pre-conj-brian-goetz">Read full post</a></center></p> http://www.lispcast.com/pre-conj-bozhidar-batsov http://www.lispcast.com/pre-conj-bozhidar-batsov Sat 27 Sep 2014 09:29:50 AM CDT Bozhidar Batsov will talk about CIDER, the Clojure IDE for Emacs. <p><center><a href="http://www.lispcast.com/pre-conj-bozhidar-batsov">Read full post</a></center></p> http://www.lispcast.com/pre-conj-ashton-kemerling http://www.lispcast.com/pre-conj-ashton-kemerling Fri 26 Sep 2014 07:20:33 AM CDT Ashton Kemerling will talk about Generative Integration Tests. <p><center><a href="http://www.lispcast.com/pre-conj-ashton-kemerling">Read full post</a></center></p> http://www.lispcast.com/pre-conj-anna-pawlicka http://www.lispcast.com/pre-conj-anna-pawlicka Thu 25 Sep 2014 09:00:28 AM CDT Anna Pawlicka will give a talk about Om. <p><center><a href="http://www.lispcast.com/pre-conj-anna-pawlicka">Read full post</a></center></p> http://www.lispcast.com/pre-conj-2014 http://www.lispcast.com/pre-conj-2014 Sat 20 Sep 2014 11:12:51 PM CDT Prepare for the Clojure/conj with media from around the web. <p><center><a href="http://www.lispcast.com/pre-conj-2014">Read full post</a></center></p> http://www.lispcast.com/four-features-javascript-can-steal-from-clojure http://www.lispcast.com/four-features-javascript-can-steal-from-clojure Wed 17 Sep 2014 11:52:22 AM CDT ClojureScript adds a lot of value on top of the Javascript platform. But some of that value can be had directly in Javascript without using a new language. <p><center><a href="http://www.lispcast.com/four-features-javascript-can-steal-from-clojure">Read full post</a></center></p> http://www.lispcast.com/convince-your-boss-to-use-clojure http://www.lispcast.com/convince-your-boss-to-use-clojure Tue 16 Sep 2014 04:29:06 PM CDT Clojure has been successfully adopted by many companies. There are many resources available by people who did the hard work of introducing Clojure to their team. <p><center><a href="http://www.lispcast.com/convince-your-boss-to-use-clojure">Read full post</a></center></p> http://www.lispcast.com/just-hack-something-together http://www.lispcast.com/just-hack-something-together Thu 04 Sep 2014 10:54:53 PM CDT Lisp is viewed as difficult and academic but it is a great language for hacking a solution together. <p><center><a href="http://www.lispcast.com/just-hack-something-together">Read full post</a></center></p> http://www.lispcast.com/atom-problem http://www.lispcast.com/atom-problem Thu 28 Aug 2014 05:43:39 PM CDT I go over a real-world example of how atoms and immutable values allow you to compose constructs in ways that are easy to reason about and less prone to error. <p><center><a href="http://www.lispcast.com/atom-problem">Read full post</a></center></p> http://www.lispcast.com/two-kinds-of-bootstrapping http://www.lispcast.com/two-kinds-of-bootstrapping Sat 23 Aug 2014 10:43:37 AM CDT I like languages with a small core that is extensible. The languages tend to be weird and require less code to bootstrap. <p><center><a href="http://www.lispcast.com/two-kinds-of-bootstrapping">Read full post</a></center></p> http://www.lispcast.com/clojure-is-imperative http://www.lispcast.com/clojure-is-imperative Fri 22 Aug 2014 11:51:19 PM CDT Clojure is an imperative language. Its operations are defined in terms of concrete actions. But those actions are often the same actions available to the programmer at runtime. This makes it easy to bootstrap. <p><center><a href="http://www.lispcast.com/clojure-is-imperative">Read full post</a></center></p> http://www.lispcast.com/complex-syntax http://www.lispcast.com/complex-syntax Tue 19 Aug 2014 09:48:13 AM CDT Lisps are revered for their simple syntax, but parens are complex. They complect function calls and macro calls, which have drastically different semantics. <p><center><a href="http://www.lispcast.com/complex-syntax">Read full post</a></center></p> http://www.lispcast.com/is-core-async-against-clojure-philosophy http://www.lispcast.com/is-core-async-against-clojure-philosophy Wed 06 Aug 2014 07:32:36 AM CDT Clojure core.async is a way to manage mutable state. Isn't that against functional programming? <p><center><a href="http://www.lispcast.com/is-core-async-against-clojure-philosophy">Read full post</a></center></p> http://www.lispcast.com/reification http://www.lispcast.com/reification Tue 05 Aug 2014 10:39:50 PM CDT Reification means making an abstraction into a concrete value that can be manipulated at runtime. Reification is the core of what makes a language dynamic. Three types of reification in Clojure are discussed. <p><center><a href="http://www.lispcast.com/reification">Read full post</a></center></p> http://www.lispcast.com/core-async-browser-motivation http://www.lispcast.com/core-async-browser-motivation Tue 29 Jul 2014 04:36:36 PM CDT Javascript's concurrency model forces code to give up control of when a callback will be called. `core.async` gives you back that control and hence lets you code in a more natural style. <p><center><a href="http://www.lispcast.com/core-async-browser-motivation">Read full post</a></center></p> http://www.lispcast.com/stop-refactoring-and-start-factoring http://www.lispcast.com/stop-refactoring-and-start-factoring Thu 24 Jul 2014 04:12:16 PM CDT Refactoring is focused on the quality of code, while factoring aims to uncover the underlying beauty of the problem domain, as expressed in code. Instead of cleaning up your code, try factoring. <p><center><a href="http://www.lispcast.com/stop-refactoring-and-start-factoring">Read full post</a></center></p> http://www.lispcast.com/ring-1-3 http://www.lispcast.com/ring-1-3 Tue 22 Jul 2014 11:53:00 PM CDT Ring is great because it closely models the HTTP message format using native Clojure data structures. It strictly defines a message format that any software can use and rely on. With Ring 1.3, the specification has gotten even closer to the HTTP spec. <p><center><a href="http://www.lispcast.com/ring-1-3">Read full post</a></center></p> http://www.lispcast.com/church-vs-curry-types http://www.lispcast.com/church-vs-curry-types Tue 15 Jul 2014 10:26:15 PM CDT Static vs dynamic typing debates often flounder because the debators see from two different perspectives without knowing it. Learning to identify the two perspectives can calm the discussion. The tension between the two perspectives has led to Gradual Typing and other technologies. <p><center><a href="http://www.lispcast.com/church-vs-curry-types">Read full post</a></center></p> http://www.lispcast.com/json-serialization-api-clojure http://www.lispcast.com/json-serialization-api-clojure Thu 10 Jul 2014 10:42:08 PM CDT Clojure is well-suited for processing JSON, but there are some decisions you have to make to suit your application. The major decisions are actually easy, though they took me a while to figure out. <p><center><a href="http://www.lispcast.com/json-serialization-api-clojure">Read full post</a></center></p> http://www.lispcast.com/what-is-functional-programming http://www.lispcast.com/what-is-functional-programming Tue 01 Jul 2014 10:47:20 AM CDT I prefer to define Functional Programming as making a distinction between pure and impure code. With this definition, you can program functionally in any language. What differentiates the functional languages is how much help they give you to make the distinction. <p><center><a href="http://www.lispcast.com/what-is-functional-programming">Read full post</a></center></p> http://www.lispcast.com/core-async-code-style http://www.lispcast.com/core-async-code-style Tue 10 Jun 2014 11:03:57 PM CDT If your functions return `core.async` channels instead of taking callbacks, you encourage them to be used within `go` blocks. Unchecked, this encouragement could proliferate your use of `go` blocks unnecessarily. There are some coding conventions that can minimize this problem. <p><center><a href="http://www.lispcast.com/core-async-code-style">Read full post</a></center></p> http://www.lispcast.com/clojure-regex http://www.lispcast.com/clojure-regex Thu 03 Jun 2014 08:45:37 PM CDT With a few functions from the standard library, Clojure lets you do most of what you want with regular expressions with no muss. <p><center><a href="http://www.lispcast.com/clojure-regex">Read full post</a></center></p> http://www.lispcast.com/lists-in-clojure http://www.lispcast.com/lists-in-clojure Tue 27 May 2014 08:31:51 PM CDT Lists are kind of warty in Clojure. Care should be taken, especially by those coming from other Lisps. <p><center><a href="http://www.lispcast.com/lists-in-clojure">Read full post</a></center></p> http://www.lispcast.com/css-and-the-lambda-calculus http://www.lispcast.com/css-and-the-lambda-calculus Fri 09 May 2014 10:58:51 AM CDT Using LESS, we can almost achieve the expressive power of the Lambda Calculus as applied to styling. The expressive power is enough to create reusable styles applied to reusable HTML components. <p><center><a href="http://www.lispcast.com/css-and-the-lambda-calculus">Read full post</a></center></p> http://www.lispcast.com/separation-of-presentation-and-content http://www.lispcast.com/separation-of-presentation-and-content Thu 17 Apr 2014 01:56:15 PM CDT One reason to separate style from content is to reuse HTML or CSS. Ultimately, we would like a solution where we can reuse both. <p><center><a href="http://www.lispcast.com/separation-of-presentation-and-content">Read full post</a></center></p> http://www.lispcast.com/clojure-web-security http://www.lispcast.com/clojure-web-security Sat 05 Apr 2014 04:35:56 PM CDT Use the OWASP Top Ten Project to minimize security vulnerabilities in your Clojure web application. <p><center><a href="http://www.lispcast.com/clojure-web-security">Read full post</a></center></p> http://www.lispcast.com/ring-spec-hang-on-wall http://www.lispcast.com/ring-spec-hang-on-wall Fri 28 Mar 2014 09:16:16 PM CDT The Ring SPEC is the core of the Clojure web ecosystem. The standard is small and a reference is handy. <p><center><a href="http://www.lispcast.com/ring-spec-hang-on-wall">Read full post</a></center></p> http://www.lispcast.com/what-web-framework-should-i-use http://www.lispcast.com/what-web-framework-should-i-use Sun 23 Mar 2014 05:03:04 PM PDT There are a number of web frameworks in Clojure, but beginners should roll their own server stack themselves to tap into the Ring ecosystem. <p><center><a href="http://www.lispcast.com/what-web-framework-should-i-use">Read full post</a></center></p> http://www.lispcast.com/when-to-use-a-macro http://www.lispcast.com/when-to-use-a-macro Fri 07 Mar 2014 03:45:07 PM CST Macros should be avoided to the extent possible. There are three circumstances where they are required. <p><center><a href="http://www.lispcast.com/when-to-use-a-macro">Read full post</a></center></p> http://www.lispcast.com/less-abstraction-combination http://www.lispcast.com/less-abstraction-combination Wed 12 Feb 2014 10:16:42 PM CST LESS has obviously better forms of abstraction and combination than CSS. It has recursive style definitions, which is enough to consider it a "powerful language". <p><center><a href="http://www.lispcast.com/less-abstraction-combination">Read full post</a></center></p> http://www.lispcast.com/css-abstraction-combination http://www.lispcast.com/css-abstraction-combination Sat 08 Feb 2014 01:44:44 PM CST According to the requirements proposed by Abelson and Sussman, CSS does not provide adequate means of combination and abstraction to be considered a powerful language. <p><center><a href="http://www.lispcast.com/css-abstraction-combination">Read full post</a></center></p> http://www.lispcast.com/Hindley-Milner-in-Clojure http://www.lispcast.com/Hindley-Milner-in-Clojure Mon 13 Jan 2014 08:48:37 AM CST I wrote a lambda-calculus interpreter and an implementation of Hindley-Milner to type check it. <p><center><a href="http://www.lispcast.com/Hindley-Milner-in-Clojure">Read full post</a></center></p> http://www.lispcast.com/react-another-level-of-indirection http://www.lispcast.com/react-another-level-of-indirection Tue 31 Dec 2013 01:01:25 PM CST React provides a better abstraction over the DOM than MVC frameworks ever can. React is the last piece of the puzzle for ClojureScript web frontend development. <p><center><a href="http://www.lispcast.com/react-another-level-of-indirection">Read full post</a></center></p> http://www.lispcast.com/deconstructing-functional-programming http://www.infoq.com/presentations/functional-pros-cons Sun 22 Dec 2013 04:33:32 PM CST <blockquote> <p>Because if you think about it, the stack itself is just an optimization. Right? There are these frames which contain information about each invocation. Each stack frame. Each activation record. And that's what they are--they're activation records. They're sort of objects. If you really have objects on the brain, like I do, then you realize that they're all just objects.</p> </blockquote> <blockquote> <p>And they should be treated uniformly. You can even build a language that works this way--as I have. If that's the case, this is really a garbage collection problem. Right? Your stack traces might go away if you don't need them. You do need them when it's not a tail call because you need to go back there and use that information. But if it's a tail call, you don't need them, you don't need a tail call back to that frame. You need a pointer back to the last frame that wasn't a tail call. And they might get collected.</p> </blockquote> <blockquote> <p>Which doesn't mean you actually have to implement it that way. Erlang sort of does. And there are many implementations that do that. They are not noted for their speed. If you can have real stacks, what happens when you run out of space? If you don't run out of space, it didn't really matter if you optimized the tail calls or not.</p> </blockquote> <blockquote> <p>When you run out of space, you should GC the damned stack. You shouldn't just throw up your hands and say you're dead. And for all the normal programs that people write where it didn't matter, they won't care. And for your tail recursive programs, well, they might be a bit slower, but they will work. And then it's a matter of flags to the garbage collector if in production you don't want to debug it if you're sure it's all going to be fine--then go ahead and tell it to don't bother and just slam it and overwrite those frames directly.</p> </blockquote> <p>Why is this so hard for implementers to do? Optimization is an optimization and should be optional.</p> <blockquote> <p>It's a cool algorithm, but there's nothing nice that I'm prepared to say about Hindley-Milner.</p> </blockquote> <p>He nails a lot of things I didn't like about Haskell.</p> <p>All in all, this talk gets a lot of things right.</p> <h3 id="you-might-also-like">You might also like</h3> <ul> <li><a href="http://www.lispcast.com/composable-parts">Composable parts</a></li> <li><a href="http://www.lispcast.com/fp-in-my-language">Can I do FP in my language?</a></li> <li><a href="http://www.lispcast.com/global-mutable-state">Global Mutable State</a></li> <li><a href="http://www.lispcast.com/hirable-in-clojure">What do I have to learn to be hirable in Clojure?</a></li> </ul> <p><center><a href="http://www.lispcast.com/deconstructing-functional-programming">Read full post</a></center></p> http://www.lispcast.com/how-to-use-new-relic-with-clojure-on-heroku http://www.lispcast.com/how-to-use-new-relic-with-clojure-on-heroku Tue 03 Dec 2013 10:02:23 AM CST New Relic lets you get more out of Heroku. Install it in 7 steps. <p><center><a href="http://www.lispcast.com/how-to-use-new-relic-with-clojure-on-heroku">Read full post</a></center></p> http://www.lispcast.com/what-to-look-for-in-validations http://logaan.github.io/clojure/validations/vlad/2013/11/25/what-to-look-for-in-validations.html Mon 25 Nov 2013 10:29:19 AM CST <p>Nice validation library plus very good motivational blog post.</p> <h3 id="you-might-also-like">You might also like</h3> <ul> <li><a href="http://www.lispcast.com/100-most-used-clojure-expressions">The 100 Most Used Clojure Expressions</a></li> <li><a href="http://www.lispcast.com/3-things-java-can-steal-from-clojure">3 Things Java Programmers Can Steal from Clojure</a></li> <li><a href="http://www.lispcast.com/annotated-clojure-core-reduce">Some Annotated clojure.core/reduce Examples</a></li> <li><a href="http://www.lispcast.com/annotated-map">Annotated map</a></li> </ul> <p><center><a href="http://www.lispcast.com/what-to-look-for-in-validations">Read full post</a></center></p> http://www.lispcast.com/healthcare-gov-gulf-between-planning-and-reality http://www.shirky.com/weblog/2013/11/healthcare-gov-and-the-gulf-between-planning-and-reality/ Sun 24 Nov 2013 12:31:04 AM CST <p>Clay Shirky nails it with nice, narrative style.</p> <h3 id="you-might-also-like">You might also like</h3> <ul> <li><a href="http://www.lispcast.com/arguments-against-frameworks">The arguments against web frameworks</a></li> <li><a href="http://www.lispcast.com/bootstrapping-mindset">The Bootstrapping Mindset</a></li> <li><a href="http://www.lispcast.com/cascading-separation-abstraction">Separation, Abstraction, and Cascading in CSS</a></li> <li><a href="http://www.lispcast.com/clojure-web-framework">What should a Clojure framework look like?</a></li> </ul> <p><center><a href="http://www.lispcast.com/healthcare-gov-gulf-between-planning-and-reality">Read full post</a></center></p> http://www.lispcast.com/on-type-unity http://www.lispcast.com/on-type-unity Sat 02 Nov 2013 04:52:12 PM CDT Languages with strong, dynamic types (like Scheme) are actually single-typed languages, not untyped languages. Some would say this is restrictive, but this unity of type is a source of their strength. <p><center><a href="http://www.lispcast.com/on-type-unity">Read full post</a></center></p> http://www.lispcast.com/maciej-ceglowski-pinboard-xoxo-2013 http://www.youtube.com/watch?v=eky5uKILXtM Fri 18 Oct 2013 05:52:16 PM CDT <iframe width="420" height="315" src="//www.youtube.com/embed/eky5uKILXtM" frameborder="0" allowfullscreen></iframe> <blockquote> <p>Henry David Thoreau was a content creator active in the 1850s.</p> </blockquote> <p>Classic.</p> <h3 id="you-might-also-like">You might also like</h3> <ul> <li><a href="http://www.lispcast.com/deconstructing-functional-programming">Deconstructing Functional Programming</a></li> </ul> <p><center><a href="http://www.lispcast.com/maciej-ceglowski-pinboard-xoxo-2013">Read full post</a></center></p> http://www.lispcast.com/sharp-and-gets-things-cut http://blog.fogus.me/2013/10/07/scala-sharp-and-gets-things-cut/ Tue 08 Oct 2013 11:47:58 PM CDT <p>Michael Fogus is right (as usual) about this one. Someone with Odersky's stature should not fear lack of humility but instead lack of confidence.</p> <h3 id="you-might-also-like">You might also like</h3> <ul> <li><a href="http://www.lispcast.com/church-vs-curry-types">Church vs Curry Types</a></li> <li><a href="http://www.lispcast.com/Hindley-Milner-in-Clojure">Hindley-Milner in Clojure</a></li> <li><a href="http://www.lispcast.com/on-type-unity">On Type Unity</a></li> <li><a href="http://www.lispcast.com/pre-west-nathan-sorenson">Pre-West Prep: Nathan Sorenson</a></li> </ul> <p><center><a href="http://www.lispcast.com/sharp-and-gets-things-cut">Read full post</a></center></p> http://www.lispcast.com/ambrose-interview-typed-clojure http://us4.campaign-archive2.com/?u=a33b5228d1b5bf2e0c68a83f4&id=c43c157edd Tue 08 Oct 2013 03:34:23 PM CDT <p>Way back in May 2012, Ambrose was beginning work on Typed Clojure for Google Summer of Code. I interviewed him to get an idea of what kind of type system we could expect. Since he's now running a very successful <a href="http://www.indiegogo.com/projects/typed-clojure">crowd funding campaign</a>, I thought I'd bring up this blast from the past.</p> <h3 id="you-might-also-like">You might also like</h3> <ul> <li><a href="http://www.lispcast.com/100-most-used-clojure-expressions">The 100 Most Used Clojure Expressions</a></li> <li><a href="http://www.lispcast.com/3-things-java-can-steal-from-clojure">3 Things Java Programmers Can Steal from Clojure</a></li> <li><a href="http://www.lispcast.com/annotated-clojure-core-reduce">Some Annotated clojure.core/reduce Examples</a></li> <li><a href="http://www.lispcast.com/annotated-map">Annotated map</a></li> </ul> <p><center><a href="http://www.lispcast.com/ambrose-interview-typed-clojure">Read full post</a></center></p> http://www.lispcast.com/lisp-with-macros-language-stack http://www.lispcast.com/lisp-with-macros-language-stack Tue 08 Oct 2013 10:47:27 AM CDT Lisp with macros can be seen as two languages, each with different semantics. The base language can be interpreted directly, whereas the result of interpreting the macro language is to produce a new program in the base language. <p><center><a href="http://www.lispcast.com/lisp-with-macros-language-stack">Read full post</a></center></p> http://www.lispcast.com/making-true-false-easy http://www.lispcast.com/making-true-false-easy Sat 21 Sep 2013 09:09:14 AM CDT <p>When I was training as a teacher, I gave a simple quiz with True/False (T/F) questions. The results were terrible. Worse than chance. On one question, <strong>about 20% of the class got it right</strong>.</p> <p>I had asked a simple question involving a logical AND:</p> <blockquote> <p>True or False?<br />A parallelogram has parallel opposite sides AND it has five sides.</p> </blockquote> <p>Eighty percent of the class chose 'True', even though all parallelograms have four sides. The other teachers told me the question was difficult because it was a T/F question. <strong>They said they never give T/F questions because they only confuse the kids.</strong> They said I should just forget about T/F and try a different type of question. But it was my class and my time to explore teaching and I knew that this question was not that hard. Several connections became clear in my mind: <a href="http://lispcast.com/why-technical-explanation-alone-is-not-enough">using the right part of their brains</a>, <a href="http://lispcast.com/tap-into-your-social-brain">making the problem about people</a>, and <a href="http://lispcast.com/use-your-imagination">using their imaginations effectively</a>. I wanted to give it a shot.</p> <p>I planned the next class around answering True/False questions. There would be an <strong>experiment</strong> to confirm my suspicion (that the kids were using the wrong part of their brains), a lesson using an <strong>imaginative process</strong>, and then a <strong>similar quiz</strong> to see how it worked.</p> <p>The next morning in class, I wrote the T/F question on the blackboard and called a student up to answer it. He read it and said 'True' (the wrong answer). I asked him &quot;what about this part?&quot;, pointing to the false part. He was clearly confused. The part about five sides was obviously false to him. He then began <em>looking around</em>^{<a href="#fn1" class="footnoteRef" id="fnref1">1</a>} through the question and stopped at the first part (the true part). He pointed at it and said 'True', as if it negated the fact that the other part was false. It's hard to describe, but I was convinced that he was simply looking for something that was true to make the whole question true. <strong>And he thought that it was the right answer.</strong> My hypothesis was confirmed: he was using a visual strategy when it was not called for.</p> <p>I then demonstrated an imagination process for solving True/False questions. It went like this:</p> <blockquote> <p>When solving a True/False question, I first imagine someone standing in front of me. He says the statement from the question to me. If he is lying, the answer is <em>False</em>. If he is telling the truth, the answer is <em>True</em>.</p> </blockquote> <p>I asked a couple of people to carry out the process while narrating it to me. They seemed to be able to do it (and they got it right). So then I gave the quiz.</p> <p>The result? Correct answers went <strong>from 20% to 80%</strong>. I felt like I was finally testing their knowledge of the material and not their understanding of test-taking strategies.</p> <p>How did it work? By <strong>converting the problem from a logic skill to a social skill</strong>, the students could totally bypass the need to process difficult symbolic rules. And we could solve it as a social problem by using a structured process of imagination.</p> <p>True/False questions are difficult because there are <strong>so many levels of binary confusion</strong>. First, you are looking for the correct (as opposed to the incorrect) answer. Then you must determine the truth value of the whole statement, which is a function of the truth values of the sub-statements. It's just a lot of levels to keep in your head.</p> <p>The imaginative process cuts through all of that and asks one question: is he lying. <strong>You are offloading the processing to the social part of your brain</strong>, which can easily do it if framed in the right way.^{<a href="#fn2" class="footnoteRef" id="fnref2">2</a>}</p> <h3 id="you-might-also-like">You might also like</h3> <ul> <li><a href="http://www.lispcast.com/100-most-used-clojure-expressions">The 100 Most Used Clojure Expressions</a></li> <li><a href="http://www.lispcast.com/interactive-baking">The Importance of Embodied Metaphors</a></li> <li><a href="http://www.lispcast.com/learning-is-about-skills">How to avoid &quot;Makes sense if you already understand it.&quot;</a></li> <li><a href="http://www.lispcast.com/new-orleans-clojure-workshop-oct-2016">New Orleans Clojure Workshop Retrospective</a></li> </ul> <div class="footnotes"> <hr /> <ol> <li id="fn1"><p>Looking indicates visual thinking. <a href="http://lispcast.com/why-technical-explanation-alone-is-not-enough">Use the right part of the brain.</a><a href="#fnref1">↩</a></p></li> <li id="fn2"><p>In my last post, I hinted at a better way to teach how to determine whether a function is a pure function. The better way is to imagine a robot in front of you. Can he run that function &quot;in his head&quot;? Or does he need to effect the outside world?<a href="#fnref2">↩</a></p></li> </ol> </div> <p><center><a href="http://www.lispcast.com/making-true-false-easy">Read full post</a></center></p> http://www.lispcast.com/use-your-imagination http://www.lispcast.com/use-your-imagination Tue 17 Sep 2013 10:22:44 PM CDT You can transfer the outline of a skill by guiding someone through a structured use of their imagination. <p><center><a href="http://www.lispcast.com/use-your-imagination">Read full post</a></center></p> http://www.lispcast.com/nil-punning http://www.lispcast.com/nil-punning Thu 12 Sep 2013 04:44:34 PM CDT Null pointers are still a problem in Clojure, but several design decisions have made them less problematic than other languages. <p><center><a href="http://www.lispcast.com/nil-punning">Read full post</a></center></p> http://www.lispcast.com/tap-into-your-social-brain http://www.lispcast.com/tap-into-your-social-brain Wed 11 Sep 2013 12:50:02 PM CDT We can solve social problems much more easily than logic problems, even when they are equivalent. Convert a logic problem into a social problem to make it easier to solve. <p><center><a href="http://www.lispcast.com/tap-into-your-social-brain">Read full post</a></center></p> http://www.lispcast.com/brave-clojure http://www.braveclojure.com/ Wed 11 Sep 2013 12:43:47 PM CDT <p>I am pretty excited about this project. Please check it out.</p> <h3 id="you-might-also-like">You might also like</h3> <ul> <li><a href="http://www.lispcast.com/100-most-used-clojure-expressions">The 100 Most Used Clojure Expressions</a></li> <li><a href="http://www.lispcast.com/3-things-java-can-steal-from-clojure">3 Things Java Programmers Can Steal from Clojure</a></li> <li><a href="http://www.lispcast.com/annotated-clojure-core-reduce">Some Annotated clojure.core/reduce Examples</a></li> <li><a href="http://www.lispcast.com/annotated-map">Annotated map</a></li> </ul> <p><center><a href="http://www.lispcast.com/brave-clojure">Read full post</a></center></p> http://www.lispcast.com/a-personal-lisp-crisis http://blog.jacius.info/2012/05/29/a-personal-lisp-crisis/ Wed 11 Sep 2013 12:20:58 PM CDT <blockquote> <p>There are other languages with healthier communities, more momentum, cleaner cores, and features on par with CL. So I have to ask myself, why bother with CL?</p> </blockquote> <p>I had a similar experience with Common Lisp. Great language, snobby community, little progress, needs more modern amenities.</p> <h3 id="you-might-also-like">You might also like</h3> <ul> <li><a href="http://www.lispcast.com/bootstrapping-mindset">The Bootstrapping Mindset</a></li> <li><a href="http://www.lispcast.com/idea-of-lisp">The Idea of Lisp</a></li> <li><a href="http://www.lispcast.com/infinite-application">Infinite Application</a></li> <li><a href="http://www.lispcast.com/just-hack-something-together">Just Hack Something Together</a></li> </ul> <p><center><a href="http://www.lispcast.com/a-personal-lisp-crisis">Read full post</a></center></p> http://www.lispcast.com/why-technical-explanation-alone-is-not-enough http://www.lispcast.com/why-technical-explanation-alone-is-not-enough Mon 09 Sep 2013 08:18:29 PM CDT <p>Here's a problem you might see on a standardized test:</p> <p><center> <img src="http://www.lispcast.com/img/logic-puzzle.png" alt="Choose the answer that makes the following statement FALSE: If the Triangle is Red, then the Square is Blue." /> </center></p> <p>Go ahead and try to solve it. Choose an answer.</p> <p>When people answer this question on a test, the most common answer is C. Yellow triangle and red square. They try to make the statement false by negating all of the colors.</p> <p>This is wrong. Actually, the correct answer is A. It is the only one that makes the statement false. Why?</p> <p>This is a propositional logic problem. The colors and shapes are a red herring. The rule for implication (if-then statement) is:</p> <blockquote> <p>An implication is false if the antecedant is true and the consequent is false.</p> </blockquote> <p>Kind of boring and therefore hard to understand if you don't already know the rule. It is unlikely that any amount of explanation will help, though you should try to understand if you don't already. Here, try this. If the triangle isn't red, then the statement doesn't apply, so it is true by irrelevance. That eliminates C and D. B obviously makes the statement true, so it must be A.^{<a href="#fn1" class="footnoteRef" id="fnref1">1</a>}</p> <p>Researchers found that explanations alone do not help. I read an article^{<a href="#fn2" class="footnoteRef" id="fnref2">2</a>} about a study where similar questions were asked to a group of students. The students were hooked up to <a href="http://en.wikipedia.org/wiki/Electroencephalography">EEG (Electroencephalography)</a> machines to measure what parts of their brains were active during each question. They also asked them to say which ones they thought they got right.</p> <p><center> <img src="http://www.lispcast.com/img/eeg.jpg" alt="EEG setup also labeling reasoning/visual areas." /> </center> Photo credit: <a href="http://en.wikipedia.org/wiki/File:EEG_recording.jpg">Petter Kallioinen</a> </p> <p>What they found was that most of the people who answered A were <em>using their frontal and temporal lobes</em>: the parts of the brain responsible for <em>logic, reasoning, and language</em>. Most of the people who answered C were using their <em>occipital lobes</em>, which is responsible for <em>vision</em>.</p> <p><strong>Moral #1:</strong> Recognize what type of problem you need to solve. If possible, use the right part of your brain for that problem.</p> <p>The people who used their vision centers were doing visual pattern matching, <em>looking for shapes and colors</em>. This is typical of a fight-or-flight response, where you are running from a tiger and need to quickly spot it in the jungle.</p> <p><strong>Moral #2:</strong> Don't get nervous during a test. Anxiety makes some parts of your brain more active--usually the wrong ones.</p> <p>In addition, the people who used their vision center to answer the question <em>thought they got the answer right</em> just as much as the people who actually got it right.</p> <p><strong>Moral #3:</strong> The different parts of your brain are good at different tasks. If you ask the occipital lobe to do pattern matching, it will, and it will think it did a good job--even if it is not a pattern matching task.</p> <p>The second part of the study tried to teach those who got it wrong to do it better next time. They broke them into a control group and an experimental group. The control group got an explanation like the boring one above on how to make an implication false. The experimental group got the same explanation plus they were trained with a little <em>bio-feedback to use the right part of the brain</em>.^{<a href="#fn3" class="footnoteRef" id="fnref3">3</a>}</p> <p>The result was that the control group didn't make any gains. And they <em>still</em> thought they got it right. The experimental group did significantly better. They scored higher and were more likely to say they got the wrong answer when they did get the wrong answer.</p> <p><strong>Moral #4:</strong> Explanation alone is basically worthless. Even practice is not enough. The key is to recognize what type of problem it is, use the right part of your brain, and don't listen to the rest of your brain. Only then is explanation useful.</p> <p>Now, this is easier said than done. I don't have an EEG machine. I've never done bio-feedback. But the <em>idea</em> has helped me tremendously when teaching math. <em>It is not hard to recognize when someone is using the wrong part of their brain.</em> First, they <em>confidently</em> get the wrong answer. Second, they are getting the basic mechanics of the problem wrong. They're <em>looking</em> for something. They find the closest thing to what they want. They're done.</p> <p><em>Logic problems aren't about looking.</em> They're more abstract. Common helpers for doing logic problems are mouthing words, making gestures, and looking <em>away</em> from the problem.</p> <p>Recognizing whether someone is using the right part of their brain is easy. But now you know explaining won't help. The hard part is to get them <strong>to use the correct part of the brain</strong>. That's what I'll talk about next time.</p> <h3 id="you-might-also-like">You might also like</h3> <ul> <li><a href="http://www.lispcast.com/100-most-used-clojure-expressions">The 100 Most Used Clojure Expressions</a></li> <li><a href="http://www.lispcast.com/interactive-baking">The Importance of Embodied Metaphors</a></li> <li><a href="http://www.lispcast.com/learning-is-about-skills">How to avoid &quot;Makes sense if you already understand it.&quot;</a></li> <li><a href="http://www.lispcast.com/making-true-false-easy">Making True/False Questions Easy</a></li> </ul> <div class="footnotes"> <hr /> <ol> <li id="fn1"><p>If you still don't get it, I'll share one more trick. Convert it into a purely symbolic puzzle to switch off your occipital lobe.</p> <p>Choose the answer that makes the following statement FALSE:</p> <pre><code>X -&gt; Y A. X &amp; ~Y B. X &amp; Y C. ~X &amp; ~Y D. ~X &amp; Y </code></pre> <a href="#fnref1">↩</a></li> <li id="fn2"><p>I read it back in 2002 and have lost the reference. I tried searching for it and could not find it. The reason I bring it up, even without a citation, is that it has been very important to my thinking about learning. If you know this or a similar study, please let me know.<a href="#fnref2">↩</a></p></li> <li id="fn3"><p>Yes, it was double-blind. In fact, if I remember correctly, they were all in the same classroom listening to the same lecture. The control group was moved to a room to practice. The experimental group was moved to a different room to practice with EEG bio-feedback machines. Then they took a similar test again.<a href="#fnref3">↩</a></p></li> </ol> </div> <p><center><a href="http://www.lispcast.com/why-technical-explanation-alone-is-not-enough">Read full post</a></center></p> http://www.lispcast.com/functors-applicatives-and-monads-in-pictures http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html Wed 22 May 2013 06:41:39 PM CDT <p>This is a nice, short post. It does the job well, though it might need a few readings if you have never seen these concepts before.</p> <p>Learn these ideas and get on with your life. The sooner we get over this Functor/Applicative/Monad obsession, the better.</p> <p><center><a href="http://www.lispcast.com/functors-applicatives-and-monads-in-pictures">Read full post</a></center></p> http://www.lispcast.com/3-things-java-can-steal-from-clojure http://www.lispcast.com/3-things-java-can-steal-from-clojure Sat 09 Mar 2013 03:38:24 PM CST Many of the cool parts of Clojure are written in Java. That means you can access those parts from any Java code. Just include the Clojure JAR, import the classes, and you've got better tools. <p><center><a href="http://www.lispcast.com/3-things-java-can-steal-from-clojure">Read full post</a></center></p> http://www.lispcast.com/java-learn-from-clojure http://www.lispcast.com/java-learn-from-clojure Wed 06 Mar 2013 09:34:48 PM CST <p>I was trained in Java at University. The OOP matrix was firmly implanted in my thinking. I wanted to share some things that I have learned from Clojure that were certainly possible in Java but never became fundamental to my programming practice.</p> <p>Clojure certainly has learned a lot from Java. It might be cool if the learning went both ways. These are universal principles. In fact, these principles are actually well known in the OOP world. You probably already know them, so learning Clojure is not required (but it is recommended!).</p> <h3 id="use-immutable-values">1. Use immutable values</h3> <p>One of Clojure's claim to fame is its immutable data structures. But immutable values were appreciated even in the very early days of Java. <code>String</code> is immutable and was a bit controversial when Java came out. Back then, C and C++ strings were simply arrays which could be changed. Immutable Strings were seen as inefficient.</p> <p>However, looking back, immutable Strings seem to have been the right choice. Many of the mutable Java classes are now seen as mistakes. Take, for example, <code>java.util.Date</code>. What does it mean to change the month of a date?</p> <p>Let's go a little further. Let's imagine that I'm an object. You ask me when my birthday is. I hand you a piece of paper with July 18, 1981. You take that home, store it somewhere, and even let other people access that piece of paper.</p> <p>One of those people says &quot;cool, a date!&quot; And changes it to his birthday, April 2, 1976 using <a href="http://docs.oracle.com/javase/6/docs/api/java/util/Date.html#setTime(long)"><code>setTime</code></a>. Now the next person who asks for my birthday actually gets that guy's birthday. What a disaster! Why did I give away that magic paper that changes my birthday?</p> <p>By making values mutable, this magical-changing-at-a-distance is always a possibility. One way to look at the reason it is actually wrong to use mutable values is that it breaks <em><a href="http://en.wikipedia.org/wiki/Information_hiding">the information hiding principle</a></em>. My birthdate is part of the state of my object. By giving direct access to the month, day, and year, I'm actually letting any class have direct access to my internal state.</p> <p>The answer, of course, is to not have any setters on an object. After construction, the object can't change. That way, my internal state remains encapsulated.</p> <p>This applies to collections as well. Have you ever read the docs for <code>Iterator</code>. Can you tell what happens when the underlying list changes? Neither can I. An immutable list would not have such a complicated interface.</p> <p><strong>Solution</strong>: Don't write setter methods. For collections, you have a couple of options. One easy thing to do is use the <a href="https://code.google.com/p/guava-libraries/">Google Guava</a> <code>Immutable...</code> classes. If using Guava is not an option, whenever you are returning a collection, make a copy, wrap it in a <code>java.util.Collections.unmodifiable...()</code>, and throw away the reference to the copy.</p> <pre><code>public static Map immutableMap(Map m) { return Collections.unmodifiableMap(new HashMap(m)); }</code></pre> <p>To learn more about immutable values, I suggest watching <a href="http://www.youtube.com/watch?v=-6BsiVyC1kM">The Value of Values</a>, a talk by Rich Hickey, the creator of Clojure.</p> <iframe width="900" height="506" src="http://www.youtube.com/embed/-6BsiVyC1kM" frameborder="0" allowfullscreen></iframe> <h3 id="do-no-work-in-the-constructor">2. Do no work in the constructor</h3> <p>Imagine this situation. Your <code>Person</code> class has a constructor that takes a bunch of information (first name, last name, address, etc.) and stores it in the object's state. Someone on your team needs to store that data to a file, so stores it as JSON. For convenience in creating a Person, you add a constructor that takes an <code>InputStream</code> and parses it as JSON, then sets up the state. Just because, you also add one that takes a <code>File</code>, reads in the file, then parses it. And then one that reads in a web request given a <code>URL</code>. Great! You've got a very convenient class.</p> <p>But wait! What is the responsibility of the <code>Person</code> class? Originally, it was &quot;represent personal information about a person&quot;. Now it is also responsible for:</p> <ul> <li>Parsing JSON</li> <li>Making web requests</li> <li>Reading files</li> <li>Handling errors</li> </ul> <p>What's more is that the class is now harder to test. How can you test the <code>File</code> constructor? First, you write a temporary file to the file system. Not too bad. How do you test the web request? Set up a web server, configure it to serve the file, then call the constructor.</p> <p>The problem is that <code>Person</code> violates <em><a href="http://en.wikipedia.org/wiki/Single_responsibility_principle">the single responsibility principle</a></em>. <code>Person</code> is about keeping bits of information together, not permanent storage or serialization. It should be a data object, no more.</p> <p><strong>UPDATE: Solution</strong>: Keep your constructor free of logic. Separate out convenience constructors (like the one that parses JSON) into static factory methods.</p> <p>To learn more about this idea (and more!), I suggest you watch <a href="http://www.youtube.com/watch?v=acjvKJiOvXw">OO Design for Testability</a> by Miško Hevery, the creator of <a href="http://angularjs.org/">AngularJS</a>.</p> <iframe width="900" height="675" src="http://www.youtube.com/embed/acjvKJiOvXw" frameborder="0" allowfullscreen></iframe> <h3 id="program-to-small-interfaces">3. Program to small interfaces</h3> <p>One thing that Clojure has done very well is to define a set of very powerful, small interfaces which abstract a pattern of access. The interface allows many different types to participate in an &quot;ecosystem&quot;. Any function which applies to the interface can act on any type that implements that interface. Any new type can take advantage of all of the existing functionality already built in.</p> <p>Take for instance the <code>Iterable</code> interface. It generalizes anything that can be accessed sequentially (such as a list or set). If all a method needs to do is operate on something sequentially, it only needs to know that it implements this interface. That means it can operate on types that were not known to the programmer when the method was written.</p> <p>This aspect follows from <em><a href="http://www.oodesign.com/dependency-inversion-principle.html">the dependency inversion principle</a></em> which states that high-level logic should be written in terms of abstractions instead of the details of the lower-level logic. Interfaces capture this principle well. High-level logic should operate on interfaces which are implemented by the lower-level logic.</p> <p><strong>Solution</strong>: Think hard about the access patterns for classes and see if you can't abstract out small interfaces which pinpoint those access patterns. Then program to those interfaces. Remember, it takes two to use an interface: the implementor and the client. Make sure you use them from both sides as much as possible.</p> <p>Nothing increases maintainability and the future cost of code more than good interfaces. To learn more about this, I suggest watching <a href="https://www.youtube.com/watch?v=aAb7hSCtvGw">How To Design A Good API and Why It Matters</a>. It's an older (but good) talk by Joshua Bloch.</p> <iframe width="900" height="675" src="http://www.youtube.com/embed/aAb7hSCtvGw" frameborder="0" allowfullscreen></iframe> <h3 id="represent-computation-not-the-world">4. Represent computation, not the world</h3> <p>When I was in college, the teacher taught us that you should use classes to model objects in the world. The quintessential modeling problem was students registering for courses.</p> <p>A course can have many students and a student can be registered in many courses. A many-to-many relationship.</p> <p>The obvious choice is to make a <code>Student</code> class and a <code>Course</code> class. Each has a list of the other. Inclusion in that list represents registration. Methods like <code>register</code> and <code>listCourses</code> let a Student register or list the courses he's registered in.</p> <p>Professors would present this problem in order to discuss the tradeoffs of different design choices. None of the configurations of Student and Course were ideal. An astute data modeler would see the pattern of the many-to-many relationship and abstract that out. You can create a class called <code>ManyToMany&lt;X,Y&gt;</code> that manages the relationship. You can create a <code>ManyToMany&lt;CourseID, StudentID&gt;</code> and it solves your problem exactly.</p> <p>The issue is that this directly contradicts the teacher's lesson. A relationship is not an object in the real world. At best it is an abstract concept.</p> <p>What's more is that it solves the more general abstract problem as well. The <code>ManyToMany</code> class can be reused anywhere it is suited. Even better would be to make <code>ManyToMany</code> an interface with many possible implementations.</p> <p>I think my professor was wrong. The Java standard library contains many classes that are purely computational. Why can't application programmers write them as well? Further, look at the <a href="http://www.amazon.com/gp/product/0201633612/ref=as_li_ss_tl?ie=UTF8&amp;camp=1789&amp;creative=390957&amp;creativeASIN=0201633612&amp;linkCode=as2&amp;tag=lisp0b-20">GOF Design Patterns Book</a>. Most (if not all) of the patterns are about abstracting computation, not &quot;objects in the real world&quot;. Take, for instance, <a href="http://en.wikipedia.org/wiki/Chain_of_responsibility_pattern">Chain-of-responsibility</a>, which Wikipedia describes as &quot;Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.&quot;</p> <p><strong>Solution</strong>: look for repetitive patterns of code and build classes that take care of those patterns. Use those classes instead of repeating the pattern over and over in code.</p> <p>One reason I like Clojure is that it has a lot to teach. If you'd like to learn Clojure, you might like my <a href="http://www.purelyfunctional.tv/intro-to-clojure">Introduction to Clojure video course</a>.</p> <div class="subscribe-form-wrapper"> <form action="https://www.getdrip.com/forms/1194631/submissions" method="post" data-drip-embedded-form="1194631" class="subscribe-form"> <h3 data-drip-attribute="headline"> Free Clojure Learning Resources </h3> <div data-drip-attribute="description"> <div style="float:right; width:250px; max-width:25%"> <img src="http://www.lispcast.com/img/clojure expr flashcard.png" style="width:100%"> <img src="http://www.lispcast.com/img/clj-refactor cheatsheet.png" style="width:100%"> </div> Sign up below and you'll get access to the <em>Clojure Resource Center</em> where I collect reference sheets and flashcards for learning Clojure, including the <b>Top 100 Clojure Expressions</b> flashcards and the <b>clj-refactor cheatsheet</b>. I'll also send you other information about learning Clojure and figuring out if Clojure is for you. </div> <br> <div> <label for="fields[email]">Email Address: </label> <input type="email" name="fields[email]" value="" id="fields[email]" placeholder="Email" /> <input type="submit" name="submit" value="Sign Up" data-drip-attribute="sign-up-button" class="subscribe-button"/> </div> </form> </div> <p><center><a href="http://www.lispcast.com/java-learn-from-clojure">Read full post</a></center></p> http://www.lispcast.com/clojure-screencasts http://www.lispcast.com/clojure-screencasts Sun 03 Mar 2013 06:19:49 PM CST <p>As you probably know, I am running a <a href="http://www.kickstarter.com/projects/376627045/lispcast-introduction-to-clojure-videos">Kickstarter project to create Introduction to Clojure videos</a>. The project is still going (it runs until March 14, 2013). Please support it if you want the videos.</p> <p>I know that there are many great videos out there that teach the basics of Clojure. Allow me to present my selection.</p> <p><a href="http://www.youtube.com/watch?v=P6S_1nCfjWA">Jim Slaterry is creating video walkthroughs</a> of the <a href="http://clojurekoans.com/">Clojure Koans</a>.</p> <p><a href="https://vimeo.com/channels/fulldisclojure">Full Disclojure was a long series of screencasts by Sean Devlin</a> that dives deep into Clojure. There are many lessons about Clojure and functional programming, screencasts explaining how to install editors, and a few explorations of katas. Most of the material should still be current.</p> <p><a href="http://www.youtube.com/watch?v=Aoeav_T1ARU&amp;list=PLAC43CFB134E85266">Brian Will created a series of videos introducing Clojure</a> back in 2009 which explains the basics of the language. The basics have changed somewhat, but this is still a good way to get into the language.</p> <p><a href="http://www.youtube.com/watch?v=dGVqrGmwOAw">Rich Hickey</a> gave <a href="http://www.youtube.com/watch?v=P76Vbsk_3J0">some talks</a> a long time ago teaching Clojure. Again, a little old, but I learned a lot from them when they were new.</p> <p><center><a href="http://www.lispcast.com/clojure-screencasts">Read full post</a></center></p> http://www.lispcast.com/clojuresphere http://www.clojuresphere.com/ Fri 01 Mar 2013 06:17:09 PM CST <p>Pretty cool.</p> <p><center><a href="http://www.lispcast.com/clojuresphere">Read full post</a></center></p> http://www.lispcast.com/why-functional-code-is-shorter http://pchiusano.blogspot.ca/2013/02/why-functional-code-is-shorter.html Mon 25 Feb 2013 01:24:12 PM CST <p>Paul Chiusano:</p> <blockquote> <p>The real decrease in code size when using FP comes from there being exponentially more code reuse possible due to the compositionality of pure code.</p> </blockquote> <p>I totally agree. John Carmack has it wrong.</p> <p><center><a href="http://www.lispcast.com/why-functional-code-is-shorter">Read full post</a></center></p> http://www.lispcast.com/interview-alex-konetchy http://www.alexkonetchy.net/2013/02/eric-normand.html Sun 24 Feb 2013 12:20:34 PM CST <p>I was interviewed last week by Alex Konetchy about my Kickstarter project.</p> <p><center><a href="http://www.lispcast.com/interview-alex-konetchy">Read full post</a></center></p> http://www.lispcast.com/the-highest-level-feature-of-c http://prog21.dadgum.com/166.html Sat 23 Feb 2013 10:17:13 PM CST <p>I like James Hague's writing. He writes concisely and offers a clear perspective on muddy subjects.</p> <p><center><a href="http://www.lispcast.com/the-highest-level-feature-of-c">Read full post</a></center></p> http://www.lispcast.com/monads-and-objects http://www.lispcast.com/monads-and-objects Fri 22 Feb 2013 11:28:45 PM CST <p>If you went back to 1990 and asked a random programmer what an object was (as in OOP) what would he say? I bet he'd say something like &quot;I don't know. I want to learn them but I don't know where to start.&quot; If you told him &quot;Well, they're easy. Each object has a class. The class defines methods. The object encapsulates state . . .&quot;, then his eyes would glaze over. He receives a maelstrom of concepts and their relationships. In the end, he would learn nothing. <strong>It actually took a long time for OO to become the norm.</strong></p> <p>This is analagous to what is happening currently with monads. <strong>People want to learn, they get some high-concept explanation, they are unsatisfied.</strong> People try to explain. They really do. I still remember when I did not get monads, so I have a lot of sympathy.</p> <p>Perhaps, like with OOP, <strong>it will take a generation to become understandable to the mainstream</strong>.</p> <p>The best way I can think of to teach monads to a programmer is <strong>jQuery</strong>. You have to know jQuery to understand this example. And frankly, if you don't know jQuery, it is easier to go learn it and come back than to go read a monad tutorial.</p> <p>Here's a (not-so-)secret: <strong>jQuery objects are a monad</strong>. When you do <code>$('div')</code>, you get an object which &quot;contains&quot; all of the <code>div</code> elements in the document. There are many methods on the jQuery object which modify the set of elements contained in the object and return it. That's what makes it a monad: the methods return a value of the same type.</p> <p>Without the jQuery object, you have to follow (and re-follow--potentially repeating code) the logic of collections. The jQuery object controls the logic by which operations on the contained set of elements gets executed. You call a method, it changes all of the elements. If there is no element, nothing happens. If there is one element, it alone is changed. If there are many elements, they are all changed. And you don't need to know. If you call <code>$('&lt;div /&gt;')</code>, even though you are constructing an object with only one element, jQuery internally turns it into a list. <strong>jQuery is making sure you don't have to know if you have 0, 1, or many elements.</strong> And this turns out to be a useful abstraction.</p> <p>This logic is simple. You write this code all the time when you are dealing with collections of objects. But <strong>you have to write this all the time, over and over</strong>. And you have to remember to write it. The jQuery object does that for you.</p> <p>That is the job of the monad. It gives you a single place to express the logic for access (in this case, a kind of collection logic). <strong>Now we are going to make a monad and show how we can write this logic in only one place.</strong></p> <p>To make a monad, you actually need two things. One is typically called <code>return</code>, but <strong>in OOP it's the constructor</strong>. We know that the jQuery constructor is the <code>$</code> function.</p> <p>The second thing you need is <strong>a way to chain methods</strong>. All you need is to return a value constructed with that constructor. Then you can chain. In Haskell, this is called <code>bind</code>.</p> <p>But I promised that monads got rid of repetition. If <strong>all of your jQuery methods have to contain this collection logic and return logic</strong>, how does that get rid of repetition? Well, if you did it the way it's done in Haskell, you'd get rid of the repetition.</p> <p>Let's do it that way. Let's define a method on the jQuery called <code>bind</code>.</p> <pre><code>jQuery.prototype.bind = function (f) { return $(f(this.get())); };</code></pre> <p>We construct a new jQuery object with the elements transformed by <code>f</code>. So I can write:</p> <pre><code>function filter_divs(els) { var arr = []; var i; for(i = 0; i &lt; els.length; i++) if(els[i].tagName === &#39;div&#39;) arr.push(els[i]); return arr; } $(&#39;.x&#39;).bind(filter_divs).addClass(&#39;hello&#39;);</code></pre> <p>Let's take it further. We can bind the function and store it in the prototype:</p> <pre><code>jQuery.prototype.bind_def = function (name, f) { jQuery.prototype[name] = function () { return $(f(this.get())); }; }</code></pre> <p>Now <strong>we can call it like a method</strong>.</p> <pre><code>$.bind_def(&#39;filter_divs&#39;, filter_divs); $(&#39;.x&#39;).filter_divs().addClass(&#39;hello&#39;);</code></pre> <p>So, now we can chain. <strong>We only have to write the logic once (in <code>bind</code> or <code>bind_def</code>).</strong> And we have a constructor. That's a monad.</p> <p>Now, imagine other bits of logic you could build into a method chain. What happens if a method returns <code>null</code>? If you call a method on it, it will throw an exception. <strong>You can capture the null check in a monad.</strong> That is called the Maybe Monad.</p> <p>There are other useful monads, but they all are simply <strong>structured ways of chaining</strong> by giving controlled access to the internals of the object.</p> <p>Thanks to <a href="http://www.youtube.com/watch?v=dkZFtimgAcM">Douglas Crockford</a> for some of these ideas.</p> <p>If you liked this essay, please check out the <a href="http://clojuregazette.org/">Clojure Gazette</a>.</p> <p><center><a href="http://www.lispcast.com/monads-and-objects">Read full post</a></center></p> http://www.lispcast.com/monads-and-gonads http://www.youtube.com/watch?v=dkZFtimgAcM Thu 21 Feb 2013 05:44:59 PM CST <p>Douglas Crockford gives his version of the obligatory monad tutorial. His version is in Javascript with hopes of needed demystification.</p> <p>I have to appreciate the freshness of his approach. He says a monad is just an object with certain properties (the monad laws). That's a great way to explain it in an object-oriented context. Objects are the unit of encapsulation. Monads serve the purpose of encapsulating state and allowing structured access to that state.</p> <p>There is one thing that bothers me about his presentation. He uses mutable objects. I guess that is to be expected in Javascript. But mutating state in a monad seriously limits their possibilities, as mutation does in most uses.</p> <p>Either way, it is an entertaining watch and a good explanation of monads. Perhaps the most down-to-earth I have seen.</p> <p><center><a href="http://www.lispcast.com/monads-and-gonads">Read full post</a></center></p> http://www.lispcast.com/redline-smalltalk http://www.indiegogo.com/projects/redline-smalltalk-v1-0?website_name=smalltalk Thu 21 Feb 2013 05:39:59 PM CST <p>I've been talking to James Ladd about this project and it looks really cool. If you don't know, Smalltalk was the language for which the term <em>Object Oriented</em> was coined. It has a rich history and is one of the most powerful languages ever written.</p> <p>Redline is an implementation of Smalltalk for the JVM. James and his team have some big plans for Redline, but first they want to get to v1.0 with a robust, professional distribution. By running on the JVM, Redline will be able to tap into the amazing ecosystem that is growing around the JVM. That means that interop is incredibly easy between Smalltalk, Java, and Clojure.</p> <p><a href="http://www.indiegogo.com/projects/redline-smalltalk-v1-0?website_name=smalltalk">Please check it out.</a></p> <p><center><a href="http://www.lispcast.com/redline-smalltalk">Read full post</a></center></p> http://www.lispcast.com/refactor-your-tests http://www.lispcast.com/refactor-your-tests Thu 21 Feb 2013 05:36:19 PM CST <p>Just a reminder, guys. I always forget. I thought you might, too.</p> <p><center><a href="http://www.lispcast.com/refactor-your-tests">Read full post</a></center></p> http://www.lispcast.com/screencasts http://www.lispcast.com/screencasts Tue 12 Feb 2013 01:56:54 PM CST <p>I would like to announce the launch of <a href="http://www.kickstarter.com/projects/376627045/lispcast-introduction-to-clojure-videos">my Kickstarter project</a>. It is a project to develop screencasts to introduce Clojure to programmers everywhere.</p> <p>Video is a great way to learn programming. For one, you get to watch the program being developed organically, not as a static artifact (as in a book). Also, a voiceover gives a direct stream into the thought process of the programmer as he types. Finally, you can stop and replay as much as you want to learn at your own pace. Those things, combined with video's ability to engage a large part of your brain make it a great learning tool.</p> <p>This blog was first created to host screencasts I made for Common Lisp, way back when. I transitioned to Clojure after watching a talk by Rich Hickey at <a href="http://lisp50.blogspot.com/">Lisp50</a> in 2008. I was very impressed and have not looked back.</p> <p>I have loved education ever since I taught math in the Peace Corps. I really enjoyed making those Common Lisp videos as well. I wanted to turn it into something like <a href="https://peepcode.com/">PeepCode</a>, but my day job interceded and I didn't have the comfort level with Clojure that I did with Common Lisp. The videos got put on hold.</p> <p>That was almost five years ago and I feel very confident with my ability to teach Clojure. Plus, video production has advanced a lot. I will be able to produce very high-quality videos much more easily than five years ago. And Kickstarter has provided a nearly risk-free way to test the market.</p> <p>If this project does well, I hope to make it into a profitable business and produce more and more videos, especially videos about deeper topics. But only if the project proves itself in the very large beginner's market. Let your friends know about this <a href="http://www.kickstarter.com/projects/376627045/lispcast-introduction-to-clojure-videos">great opportunity</a> to learn Clojure. You can find the Kickstarter project <a href="http://www.kickstarter.com/projects/376627045/lispcast-introduction-to-clojure-videos">here</a>.</p> <p>My ultimate goal, if the project proves out, is to provide exceptional educational materials to build a strong developer culture. <a href="http://clojuregazette.com/">Clojure Gazette</a> shares this same goal.</p> <p>One hour of video will cost $5 to the Kickstarter supporters. After that, the price will go up to $12. This is a very good value for one hour of instructional video. There is also a company sponsorship level. See the <a href="http://www.kickstarter.com/projects/376627045/lispcast-introduction-to-clojure-videos">Kickstarter page</a> for more details. The project ends March 14, 2013.</p> <p>Please support the project and let other people know.</p> <p>Thanks!</p> <p><center><a href="http://www.lispcast.com/screencasts">Read full post</a></center></p> http://www.lispcast.com/cascading-separation-abstraction http://www.lispcast.com/cascading-separation-abstraction Sat 29 Dec 2012 12:29:33 AM CST LESS and Sass (and similar solutions) have saved CSS for three reasons: separation, abstraction, and cascading. While I welcome them, CSS still has other problems which I believe can be solved. <p><center><a href="http://www.lispcast.com/cascading-separation-abstraction">Read full post</a></center></p> http://www.lispcast.com/the-case-against-curly-quotes http://www.lispcast.com/the-case-against-curly-quotes Mon 05 Nov 2012 01:52:46 PM CST <p>A lot of web software converts ASCII single- and double-quote characters into special, non-ASCII open and close versions. These are sometimes referred to as &quot;<a href="http://en.wikipedia.org/wiki/Quotation_mark_glyphs">smart quotes</a>&quot;. Their less intelligent ASCII equivalents are &quot;dumb quotes&quot;. Smart quotes undoubtedly look better.</p> <p>Here is an example.</p> <p>&quot;Some text&quot; becomes “Some text”.</p> <p>Very pretty, no? There is no smart quote key on your keyboard, so in order to make them, your software will convert them automagically. I say &quot;automagically&quot; because they are often converted incorrectly. There are no simple rules to convert them correctly.</p> <p>I used to upgrade my dumb quotes to smart, but a couple of years ago I decided against it. Although I would like to have prettier quotes, they annoy me on other people's sites, even when they are correctly chosen.</p> <p>Specifically, they <a href="http://stackoverflow.com/questions/1088506/smart-quotes-without-breaking-copy-and-paste">break copy-paste</a>. When you copy text with smart quotes (and smart apostrophes, smart dashes, and other smart characters), you get crap in your text. I like copy-paste and I do not want it broken on my site. In fact, I would love it if the world stopped using smart quotes.</p> <p><center><a href="http://www.lispcast.com/the-case-against-curly-quotes">Read full post</a></center></p> http://www.lispcast.com/google-common-lisp-style-guide https://google-styleguide.googlecode.com/svn/trunk/lispguide.xml Thu 11 Oct 2012 12:06:36 PM CDT <p>In April 2011, Google acquired ITA Software. ITA provides airline flight search for several of the major companies. The interesting thing is that ITA's search engine was written in Common Lisp.</p> <p>This style guide shows that Google is adopting the existing Lisp code base instead of rewriting it. Not so surprising since the code is, from what I have heard, well-engineered. But a bit surprising since Google chose Python over Lisp some time ago. Peter Norvig explains the choice a bit on <a href="http://www.youtube.com/watch?v=hE7k0_9k0VA#t=03m20s">Reddit</a> and <a href="http://news.ycombinator.com/item?id=1803815">Hacker News</a>.</p> <p>In addition, it also shows that Google is affecting ITA with its culture, to some degree. Google uses this format for <a href="https://google-styleguide.googlecode.com/svn/trunk/">all of its style guides</a>.</p> <p>Anyway, I love style guides!</p> <p><center><a href="http://www.lispcast.com/google-common-lisp-style-guide">Read full post</a></center></p> http://www.lispcast.com/clojure-clojurescript-one-language-to-rule-the-web https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=3242 Thu 11 Oct 2012 11:34:53 AM CDT <p>Nice intro to Clojurescript.</p> <p><center><a href="http://www.lispcast.com/clojure-clojurescript-one-language-to-rule-the-web">Read full post</a></center></p> http://www.lispcast.com/static-vs-dynamic-typing http://www.lispcast.com/static-vs-dynamic-typing Fri 05 Oct 2012 05:13:06 PM CDT <p>I was reading <a href="http://programmers.stackexchange.com/questions/167305/what-functionality-does-dynamic-typing-allow">this question</a> on Stack Exchange asking what is possible in a dynamically typed language that is impossible in a statically typed language. Most of the responses were terrible. It reminded me that <strong>the level of discussion surrounding the topic of types in general is very disappointing.</strong> Basically, most people do not know what they are talking about.</p> <p>Luckily, one of the answerers posted a link to <a href="http://blogs.perl.org/users/ovid/2010/08/what-to-know-before-debating-type-systems.html">this post about debating type systems</a>. I had never read it before and I am glad I have, now.</p> <p>The author takes the approach of describing how people generally use typing terms as opposed to prescribing a definition. His main point is that the terms are generally misunderstood so much that trying to discuss them is not productive. <strong>There is no agreed-upon definition in most contexts.</strong> I agree. I wish it were not the case, though.</p> <p>But there was also another gem in the article.</p> <blockquote> <p>Dynamic and static type systems are two completely different things, whose goals happen to partially overlap.</p> </blockquote> <p>I think this point is right on. Static type checking is only one possible form of static analysis. And the goal of static analysis is to detect errors as soon as possible. Dynamic typing is used more to perform dynamic type dispatch (that is, runtime polymorphism). Because they have such different goals, why are we even comparing them?</p> <p>I think a lot of it is C++'s fault. C++ took the idea of Classes and inheritance from OOP and conflated them into static types. But I'm not an expert. Maybe someone did that before C++. By the way, this is probably 90% of why people hate static typing. When static typing prevents something useful (like <a href="http://en.wikipedia.org/wiki/Duck_typing">duck typing</a>) but does not present an alternative to that use, you wish you did not have static typing.</p> <p>The real point is that <strong>static typing and dynamic typing are not inherently mutually exclusive</strong>. For instance, Java has static and dynamic typing. That is, you can ask for the type of an object at runtime, and the types of variables are checked at compile time. Clojure has some form of static analysis (no static type analysis) and inherits the runtime types from Java.</p> <p>The question &quot;which is a subset of the other?&quot; is actually meaningless. <strong>But the question &quot;if you had to choose a language that only had one, then add the other to it, which would you pick?&quot; is becoming increasingly relevant.</strong> <a href="http://www.lispcast.com/deferring-type-errors-to-runtime">Haskell recently added what some consider to be dynamic typing behavior (throwing type errors at runtime instead of at compile time).</a> <a href="http://us4.campaign-archive2.com/?u=a33b5228d1b5bf2e0c68a83f4&amp;id=c43c157edd">And people are working on static type systems for Clojure.</a></p> <p>I do not think that this is a subjective question. I think it has one possible answer in the general case. And I would like to present the argument to open up the discussion. I will use Haskell (with the most advanced static type system in the world) and Clojure (it is comparable to Haskell and dynamically typed).</p> <p>In Clojure, type information is purely informational. It does have Java's inheritance hierarchy, but that is a mere legacy to interoperate with Java. The important part of Clojure is that every value has a type and the program can know the type at runtime. This could be considered the minimal possible dynamic type system: present types at runtime and defer to the program to do what it wishes with them. <strong>The semantics of evaluation are independent of the type system.</strong></p> <p>In Haskell, type information exists only at compile time. That is, the compiler figures out the type of everything, decides whether to allow the program, then compiles it (if it is allowed). <strong>Types are complected with semantics.</strong> Types determine what code is run. Further, because the type checker has to be able to infer all types, the language has been limited to the subset of possible programs that are checkable. The semantics of the language are limited by the type system.</p> <p>So what we have is a semantics that is independent of types (Clojure) which we can augment with different static type analyses and potentially catch errors, or we have a language that has already compromised its semantics to the type system and add runtime type annotations, which are effectively useless.</p> <p>Just one last word: I am not a dynamic typing zealot. I use Haskell more than Clojure. And I am very excited to see static analysis come to Clojure. However, the static typing crowd seems to have the rhetorical upper hand at the moment. I just want to have better discussions.</p> <p><center><a href="http://www.lispcast.com/static-vs-dynamic-typing">Read full post</a></center></p> http://www.lispcast.com/the-impedance-mismatch-is-our-fault http://www.infoq.com/presentations/Impedance-Mismatch Fri 05 Oct 2012 01:43:26 PM CDT <p>Stuart Halloway continues the world-round campaign of iconoclastic and well-argumented presentations that spring from Clojure's programming model and now Datomic's architecture. Stuart gives hard-hitting, reasoned practices that make our software better in measurable ways.</p> <p>This is just one of the many ways Clojure is having (and will have) a huge impact on programming in any language. Immutable data by default is obvious. A model of time, while not so obvious, will seem like manual memory management does now. Sure, you can work with it, but who would give up garbage collection? Similarly, having a better model of state change (transactional or otherwise) enforced by the language will be something we will not want to live without.</p> <p>Separating data from code will take years, maybe a generation, to catch on. Our field has drilled the Java model of Object-Orientation into students for years. But the change has already started. Though not being led by Clojure, JSON is now a universal data format accepted by nearly every language, and the fact that the standard does not allow code in JSON is significant.</p> <p>But this talk goes a little further and proposes that we think of databases differently. Stuart does a good job of breaking down why OO and RDBMS don't fit well together, and proposes a solution that leaves them both in the dust.</p> <p>Enjoy.</p> <p><center><a href="http://www.lispcast.com/the-impedance-mismatch-is-our-fault">Read full post</a></center></p> http://www.lispcast.com/david-nolen-on-clojure.core.logic http://www.youtube.com/watch?v=A7de6pC-tnU Fri 28 Sep 2012 03:47:41 PM CDT <p>A bootleg video of a talk from Strange Loop 2012.</p> <p>I do not think the official videos are up yet. For those of us who could not make it to the conference, this is great, even though it was recorded with an iPhone. You can hear Nolen well and see the slides.</p> <p>The presentation starts with a short review of how to use <a href="https://github.com/clojure/core.logic">core.logic</a> before Nolen goes into the implementation details. I still need to spend some time understanding the code myself. core.logic is based on miniKanren, described in <a href="http://www.amazon.com/Reasoned-Schemer-Daniel-P-Friedman/dp/0262562146?tag=lisp0b-20"><em>The Reasoned Schemer</em></a>.</p> <p>Actually, I have just bought a copy of <a href="http://www.amazon.com/Little-Schemer-Daniel-P-Friedman/dp/0262560992?tag=lisp0b-20"><em>The Little Schemer</em></a>, the first book in the series of which <a href="http://www.amazon.com/Reasoned-Schemer-Daniel-P-Friedman/dp/0262562146?tag=lisp0b-20"><em>The Reasoned Schemer</em></a> is a part. I am trying to catch up on all of these Lisp classics. I will write a review when I am finished, but so far so good.</p> <p><center><a href="http://www.lispcast.com/david-nolen-on-clojure.core.logic">Read full post</a></center></p> http://www.lispcast.com/clojurescript-anatomy http://www.infoq.com/presentations/ClojureScript Thu 27 Sep 2012 10:53:24 AM CDT <p>Michael Fogus:</p> <blockquote> <p>What is the greatest limitation of Haskell's type system? The greatest limitation in Haskell's type system is it only does Haskell's type system.</p> </blockquote> <p>I totally agree. Almost two years of working in Haskell has convinced me of the benefit of static type analysis. It can catch a lot of bugs. But Haskell's type system also increases the amount of code and the surface area of your interface. The types become a point of coupling. They become hard to change without changing everything that uses them.</p> <p>This rigidity is where their power comes from, and also their annoyance. Well-chosen types can stabilize a system in a good way. Mistakes in the types, or changes in their requirements, stabilize the system in a bad way.</p> <p>I would love to see a type checker that could handle non-discriminated union types (Haskell has discriminated unions, which force you to box and unbox values, adding to code size and coupling to the types). It would be nice to have the type checker say &quot;Function foo takes either a String or a Number, but on line 34 you pass it a String or Number or HashMap.&quot;</p> <p>Another type of analysis I would like to see is whether a function is pure, does IO, or accesses mutable state. You can tag all basic IO operations as IO. Then anything that calls one of those operations also gets the tag IO. Similarly for mutable state. Haskell makes IO a type so that it can be statically checked, because Haskell only does type checking. It is not really a type, though, and does not need static type analysis.</p> <p>Another great advantage of static checking in a dynamic language is that the definition of functions can change at any time. So function foo could compile, but with a warning that it calls function bar incorrectly. When you correct function bar, the warning goes away automatically.</p> <p>Those are some ideas I had watching that video and thinking about static analysis in Clojure. I am quite excited.</p> <p><center><a href="http://www.lispcast.com/clojurescript-anatomy">Read full post</a></center></p> http://www.lispcast.com/douglas-crockford-amazing http://www.youtube.com/playlist?list=PL7664379246A246CB&feature=plcp Fri 21 Sep 2012 08:04:47 PM CDT <p>These are amazing. I learned so much about the browser and Javascript that I want to weep for the web.</p> <p><center><a href="http://www.lispcast.com/douglas-crockford-amazing">Read full post</a></center></p> http://www.lispcast.com/data-reusability http://www.lispcast.com/data-reusability Fri 21 Sep 2012 07:21:06 PM CDT <p>Rich Hickey recently commented (I cannot remember where) that there are a limited number of useful configurations of data. He claimed that the Clojure literal syntax is just about right. The one thing to add to it is the extensibility that we now have with 1.4.^{<a href="#fn1" class="footnoteRef" id="fnref1">1</a>}</p> <p>Part of the context was that we as programmers should be separating data from process. The separation makes our data more reusable. A string is a string in any language. An array is an array. Data is data and should be regarded as such. This allows for much more reuse than object oriented programming ever has. We can see the tremendous success of JSON as a case in point: a well-defined, constrained data language that gets it mostly right.</p> <p>But Hickey's point goes a little farther, I think. It is not just data that is reusable, but functions as well. Look at the enormous savings in the amount of code required to get a Swing app running when you use <a href="https://github.com/daveray/seesaw">Seesaw</a>. I am not just talking only about the incessant boilerplate anonymous class declarations Swing forces you to write. I am talking also about the fact that I can use any function to handle an event. I do not need to figure out what class the thing is expecting. Defining a subclass of a single class is inherently non-reusable.</p> <p>And it is not just that I don't need to know the class. I can use a function written in a library that has no dependencies on Swing or Seesaw at all. A function is just a function. It is universal and reusable, not because of some well-modeled domain classes, but because it is abstract and applies to no domain in particular.</p> <p>While Hickey is working on a universal, extensible data format, who is working on the universal function format?</p> <div class="footnotes"> <hr /> <ol> <li id="fn1"><p>See also <a href="https://github.com/edn-format/edn">EDN</a><a href="#fnref1">↩</a></p></li> </ol> </div> <p><center><a href="http://www.lispcast.com/data-reusability">Read full post</a></center></p> http://www.lispcast.com/class-abstractsingletonproxyfactorybean http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html Thu 20 Sep 2012 10:46:17 PM CDT <p>From the docs:</p> <blockquote> <p>Convenient proxy factory bean superclass for proxy factory beans that create only singletons.</p> <p>Manages pre- and post-interceptors (references, rather than interceptor names, as in ProxyFactoryBean) and provides consistent interface management.</p> </blockquote> <p>Good thing this is &quot;convenient&quot;.</p> <p><center><a href="http://www.lispcast.com/class-abstractsingletonproxyfactorybean">Read full post</a></center></p> http://www.lispcast.com/the-datomic-architecture-and-data-model https://vimeo.com/45136212 Thu 20 Sep 2012 06:36:36 PM CDT <p>Rich Hickey:</p> <blockquote> <p>This is not a schema<em>less</em> system. There's no such thing as a schema<em>less</em> system. There are systems where you write your schema down and ones where you don't. There's no such thing as a schemaless database. So we do require you to be explicit about this part of your database.</p> </blockquote> <p>The issue is not whether a database needs an explicit schema. The issue is whether the language you write down your schema in can express the data model you would like to use.</p> <p>That said, the <a href="http://docs.datomic.com/schema.html">Datomic schemas</a>, along with the &quot;datom&quot; model, do look expressive.</p> <p><center><a href="http://www.lispcast.com/the-datomic-architecture-and-data-model">Read full post</a></center></p> http://www.lispcast.com/the-dci-architecture-lean-and-agile-at-the-code-level http://www.infoq.com/presentations/The-DCI-Architecture Thu 20 Sep 2012 01:59:10 PM CDT <p>James Coplien's criticism of Java (that it cannot do proper object-oriented programming) is my essential criticism of static languages in general: <em>what if the model of programs that your language enforces does not allow you to program well?</em></p> <p>Coplien describes a style of programming that, although not especially encouraged by Smalltalk, was at least possible as an architectural convention. And listening to Alan Kay, I get the impression that the early Smalltalk group was programming with a concept like Roles in mind, though there was no explicit construct for it in the language.</p> <p>That concept was what we now refer to as &quot;duck typing&quot;. To fulfill a &quot;methodful role&quot;, you simply needed to have all of the required methods defined.</p> <p>Now, how would Clojure handle DCI? Well, quite naturally, actually. There are three building block concepts in DCI described in the video, each with a terrible name.</p> <ol style="list-style-type: decimal"> <li>Classes (data)</li> <li>Methodful Roles (interfaces)</li> <li>Methodless Roles (variables)</li> </ol> <p>In Clojure, &quot;classes&quot; are simply data, perhaps validated to conform to a schema, perhaps wrapped in a <code>ref</code> to get state. &quot;Methodful roles&quot; are groups of functions that can operate on data. If you're feeling frisky, you can use protocols. &quot;Methodless roles&quot; are variables in your program, each assigned to the data which will play that role.</p> <p>Let's look at the main example in Clojure.</p> <pre><code>;; money source role: debit and balance (defn debit [source amount] (update-in source [:balance] #(- % amount))) (defn balance [source] (:balance source)) ;; money destination role: credit (defn credit [dest amount] (update-in dest [:balance] #(+ % amount))) ;; the use case for doing a transfer (defn transfer [amount source destination] (dosync (when (&lt; (balance @source) amount) (throw (ex-info &quot;Insufficient funds.&quot; {:account @source :amount amount}))) (alter source debit amount) ;; debiting is not commutative if we check balance (commute destination credit amount))) ;; our two accounts (def savings (ref {:balance 1000})) (def checking (ref {:balance 25})) ;; we can transfer 20 bucks from savings to checking (transfer 20 savings checking)</code></pre> <p>I wrote this just to make sure I was not kidding myself that &quot;DCI&quot; is dead-obvious if your language does not get in the way. Object-oriented conventions today make this complicated enough that you need to read books on it to understand. How many files would you need to write in Java to do this?</p> <ol style="list-style-type: decimal"> <li>MoneySource interface</li> <li>MondeyDestination interface</li> <li>Transfer Use Case</li> <li>Account Class (or two, depending on the differences between savings and checking)</li> </ol> <p>If you can modify the account class(es) to implement the interfaces, you should be ok with those files. But if you can't, you'll have to use the &quot;Bridge&quot; pattern that I learned in school. Basically, you make a new class for each combination of class and interface. So you would have SavingsAccountMoneySource, SavingsAccountMoneyDestination, CheckingAccountMoneySource, and CheckingAccountMoneyDestination. And OOP was supposed to need less code!</p> <p>This video tells me that object-oriented programming as it is taught today has been going way down the wrong track. The lessons the static object-oriented languages have learned from the dynamic ones are the wrong lessons. Duck typing allowed programmers to elegantly implement these ideas without restrictions from the compiler. And inheritance was about reuse more than subtyping. Modern OO style takes and does not give back.</p> <p><center><a href="http://www.lispcast.com/the-dci-architecture-lean-and-agile-at-the-code-level">Read full post</a></center></p> http://www.lispcast.com/deferring-type-errors-to-runtime http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/defer-type-errors.html Fri 07 Sep 2012 06:23:40 PM CDT <p>Haskell just got a whole lot more useful for prototyping. One of my biggest gripes with Haskell was how much code had to be changed if a single type was altered^{<a href="#fn1" class="footnoteRef" id="fnref1">1</a>}, since the compiler was always looking for consistent types. There were ways to work around it^{<a href="#fn2" class="footnoteRef" id="fnref2">2</a>}, but they were always tedious and unsatisfactory.</p> <p>This new development in 7.6 lets you compile and run the code, changing type signatures many times, before you have to propagate the change through the rest of the code.</p> <div class="footnotes"> <hr /> <ol> <li id="fn1"><p>This is the classical definition of tight coupling. That's right: static typing introduces coupling.<a href="#fnref1">↩</a></p></li> <li id="fn2"><p>How to do it? Never change a type signature. Instead, create a new name with the same value, and modify that. Then, when it has settled into its permanent type signature, rename it to the old name, recompile, and let the error messages guide you.<a href="#fnref2">↩</a></p></li> </ol> </div> <p><center><a href="http://www.lispcast.com/deferring-type-errors-to-runtime">Read full post</a></center></p> http://www.lispcast.com/wat https://github.com/manuel/wat-js Fri 07 Sep 2012 07:52:03 AM CDT <p>A Lisp written in Javascript with first-class environments and first-class continuations. The README claims it starts in 50ms on modern browsers. Looks interesting.</p> <p><center><a href="http://www.lispcast.com/wat">Read full post</a></center></p> http://www.lispcast.com/liberator http://clojure-liberator.github.com/ Thu 06 Sep 2012 12:56:02 PM CDT <p>Writing HTTP compliant servers is hard in any language. There is a lot to do for each request: content type negotiation, handling the wide variety of problems with requests, and the rest of the HTTP spec goodness. Usually, we just ignore it and simplify down to three types of responses: 200 Ok and 404 Not Found and 500 Server Error. There is a lot more to the spec than this, but it often costs more to implement it correctly than to stick with this limited set of statuses.</p> <p>Liberator looks like it might have found the leverage point between navigating the essential complexity of HTTP and managing the requirements of your server.</p> <p>Two things look promising:</p> <ol style="list-style-type: decimal"> <li><p>There seems to be a lot of potential for reuse. That means you can<br /> decide server-wide policies instead of per-handler policies.</p></li> <li><p>Behavior can change incrementally. You can still get up and running<br /> using the defaults and adapt the server's behavior to suit the problem<br /> later.</p></li> </ol> <p>I look forward to trying it out.</p> <p><center><a href="http://www.lispcast.com/liberator">Read full post</a></center></p> http://www.lispcast.com/why-should-i-have-written-zeromq-in-c http://www.250bpm.com/blog:8 Thu 30 Aug 2012 01:45:04 PM CDT <p>In this post, Martin Sústrik makes a point about the performance of C compared to C++ (C++ is slower than C). While the performance point is valid, he makes some strong, dubious statements about Object-orientation and procedural programming.</p> <blockquote> <p>Object-orientedness is after all just a syntactic sugar on the top of procedural language, making the code more understandable to the human brain which seems to have evolved natural ability to deal with objects at the expense of dealing with entities such as flows, relations etc.</p> </blockquote> <p>Object-orientation is more than just syntactic sugar. OO uses message passing as its computational semantic, while procedural programming uses procedure calls.</p> <p>He then goes on to describe a scheme where one class can define fields in another class that only it can access, which he calls &quot;private in X&quot;. In this way, you can define a list which stores its pointers in the same memory as items of the list which still encapsulates the concerns.</p> <p>The benefit of OO is that by separating out concerns, you achieve more reuse. You write one list class and one person class, and now you can share persons in different lists. The problem with Sústrik's proposal is that it only allows for an item to be in one list at a time (or you have to write a new list class for every list you want them to be in). This is not Object-oriented. It is merely yet another feature bolted onto C++.</p> <p><center><a href="http://www.lispcast.com/why-should-i-have-written-zeromq-in-c">Read full post</a></center></p> http://www.lispcast.com/monads-in-pictures http://newartisans.com/2012/08/monads-in-pictures/ Wed 22 Aug 2012 12:29:57 PM CDT <p>Monads are not hard. But they are entirely abstract, and that makes them hard to grasp. Just as it requires a whole year of Algebra to accept that you can do math with letters instead of numbers, Monads usually defy written explanation.</p> <p>In this post, John Wiegly does a good job of explaining how Monads work with pictures. The visual explanation is slightly better than words. I think, though, that it just takes time, practice, and patience to build the necessary abstraction structures in your brain.</p> <p><center><a href="http://www.lispcast.com/monads-in-pictures">Read full post</a></center></p> http://www.lispcast.com/faith-evolution-and-programming-languages http://www.infoq.com/presentations/Faith-Evolution-Programming-Languages Tue 21 Aug 2012 12:24:48 PM CDT <p>Philip Wadler explains the relationship between logic and programming, why everything is discovered twice, and what a programming language in an alternate universe might look like. (Hint: it's lambda calculus).</p> <p><center><a href="http://www.lispcast.com/faith-evolution-and-programming-languages">Read full post</a></center></p> http://www.lispcast.com/dynamic-languages-wizards-series http://www.youtube.com/watch?v=agw-wlHGi0E Mon 20 Aug 2012 10:23:31 PM CDT <p>Cool talk on programming languages from 2001 featuring Paul Graham, John Maeda, Jonathan Reeves, and Guy Steele.</p> <p><center><a href="http://www.lispcast.com/dynamic-languages-wizards-series">Read full post</a></center></p> http://www.lispcast.com/introducing-playnice http://www.lispcast.com/introducing-playnice Mon 20 Aug 2012 06:24:30 PM CDT <h3 id="introduction">Introduction</h3> <p>Today I am happy to announce <a href="https://github.com/ericnormand/playnice"><code>playnice</code></a>, a Clojure library of tools to help build HTTP standards compliant servers.</p> <p>Existing libraries for developing web services focus mainly on ease. They try to make it easy to get started. They implement a naive, yet functional, version of the HTTP spec. It is basically the simplified understanding of HTTP that we all think in. A client makes requests to URLs, and the server responds with either an error or content.</p> <p>But the HTTP spec is more complete than merely matching URLs and methods. There are many error classes defined in the spec and much functionality dealing with the meta-level of the capabilities of the server itself. In addition, there are many <em>de facto</em> standards and workarounds that should be baked into the server.</p> <h3 id="philosophy">Philosophy</h3> <ol style="list-style-type: decimal"> <li>Make it easier to serve HTTP standard responses without confounding HTTP logic with business logic.</li> <li>Make it easier for limited or non-standard clients to access resources.</li> <li>As much as possible separate orthogonal functionality into composable chunks.</li> </ol> <p><code>playnice</code> was named because it plays nice with others. The Web is a wide world, and there are lots of clients out there. You should follow the spec as closely as possible, but accept that not all clients are so strict. Also, there is a variety of input and output formats. You should play nice with them, if you can. <code>playnice</code> is a library to help Clojure programs play nice with the rest of the web.</p> <h3 id="playnice-opinions"><code>playnice</code> Opinions</h3> <ul> <li><p><em>URL first, method second.</em></p> <p>HTTP is about resources, which are identified by URLs. Different resources accept different methods. If a GET at a URL responds 200, but a POST is not supported, a 405 should be returned, not a 404.</p></li> <li><p><em>Routes are values that do not exist in the global namespace.</em></p> <p>Routes are immutable and first-class.</p></li> <li><p><em>The order of defining routes should not matter.</em></p> <p>Reordering my routes should not change the behavior of my server. Routes are declarative.</p></li> <li><p><em>Servers should support the OPTIONS method and correct handling of unsupported methods.</em></p> <p>OPTIONS returns the methods that are defined for a given URL.</p></li> <li><p><em>Servers should support the Accept and Content-type headers of requests.</em></p> <p>The handler is the wrong place to parse the Content-type header to figure out what kind of data you have been given. <code>playnice</code> currently supports HTML, JSON, TXT, and Clojure literals. I hope to have XML soon.</p></li> <li><p><em>Servers should support <em>de facto</em> standards and common workarounds.</em></p> <p>&quot;Redirecting after form post&quot; is a <em>de facto</em> standard for browsers. IE does not support DELETE method in AJAX, so the workaround is to do a POST with a special query parameter set to DELETE.</p></li> </ul> <h3 id="status">Status</h3> <p><code>playnice</code> is still in early development, but it already contains the following components:</p> <ul> <li>Route + method dispatch (replacing Compojure).</li> <li>Middleware for abstracting away input and output formats.</li> <li>Middleware for handling &quot;redirect after form post&quot;.</li> <li>Middleware for working around browser limitations.</li> </ul> <p>Please check out <a href="https://github.com/ericnormand/playnice"><code>playnice</code></a> if you need an HTTP compliant web server.</p> <p><center><a href="http://www.lispcast.com/introducing-playnice">Read full post</a></center></p> http://www.lispcast.com/I-remember-the-time-before-monads http://www.free-variable.org/2012/08/i-remember-the-time-before-monads/ Fri 17 Aug 2012 07:07:10 PM CDT <p>Paul Callaghan:</p> <blockquote> <p>Callaghan’s 1st Law: the need for mutable state in a language is inversely proportional to its flexibility in manipulating data</p> <p>Put another way, mutable state is a lower-level idea and becomes less important when your language supports higher-level ways of working.</p> </blockquote> <p>Agreed.</p> <blockquote> <p>Experienced Haskell programmers know that the type system is a tool for getting work done, and a great language for playing with designs, and they exploit these aspects to help them get their work done.</p> </blockquote> <p>The key word in the sentence above is &quot;Experienced&quot;. It does take a long time to begin using the type system to your advantage.</p> <blockquote> <p>It was however a time of exploration, when researchers explored various ideas to find a good way of both having our cake and eating it. Monads are one of the solutions they found, and essentially gave us a small but flexible API for working with “computations” (like IO operations or state modifications, or various combinations thereof) as opposed to simple data values, and did so elegantly <em>within</em> the standard langage (ie. no ad hoc extensions needed). It got even better when syntactic sugar was added.</p> </blockquote> <p>Nice history lesson.</p> <p>The piece ends with some good advice:</p> <blockquote> <p>As a new explorer (very warm welcome, by the way!), when you look at Haskell material you may see some very unusual or scary-looking stuff. But do bear in mind that a lot of it is just playing around with abstractions on top of the core language, and probably does translate to something more intelligible. Try to work out what is being said about the data being manipulated, and then it might not look so bad.</p> </blockquote> <p><center><a href="http://www.lispcast.com/I-remember-the-time-before-monads">Read full post</a></center></p> http://www.lispcast.com/light-table-reaches-1.0 http://www.chris-granger.com/2012/08/17/light-table-reaches-010/ Fri 17 Aug 2012 06:55:50 PM CDT <p>Chris Granger:</p> <blockquote> <p>Clojure now has a true double click experience for getting started.</p> </blockquote> <p><center><a href="http://www.lispcast.com/light-table-reaches-1.0">Read full post</a></center></p> http://www.lispcast.com/how-the-jvm-spec-came-to-be http://www.infoq.com/presentations/gosling-jvm-lang-summit-keynote Fri 17 Aug 2012 02:32:57 PM CDT <p>James Gosling speaking about what influenced the JVM. Fascinating. The world was a different place, then. And the amount of optimization that the JVM does is truly impressive.</p> <p><center><a href="http://www.lispcast.com/how-the-jvm-spec-came-to-be">Read full post</a></center></p> http://www.lispcast.com/json-and-adt http://www.lispcast.com/json-and-adt Thu 16 Aug 2012 05:01:41 PM CDT <p>I recently wrote about the <a href="http://www.lispcast.com/yahoos-doug-crockford-on-javascript">birth of JSON</a>, which describes how JSON came to be and the story of its success. Crawford talks about how JSON (or a very close equivalent) was reinvented several times throughout the years.</p> <p>What strikes me is that JSON turned out to be an <a href="http://en.wikipedia.org/wiki/Algebraic_data_type">Algrebraic Data Type</a> (ADT). Specifically, it is a tagged union.</p> <p>JSON ADT variants:</p> <ol style="list-style-type: decimal"> <li>Null</li> <li>Boolean</li> <li>Number</li> <li>String</li> <li>List</li> <li>Dictionary</li> </ol> <p>With these six constructors, you can make all of JSON.</p> <p>It's interesting because JSON is a point of intersection between Javascript and Haskell. Javascript is very dynamic, with a very weak sense of type. Haskell has strong typing. On close analysis, JSON is statically and strongly typed. In fact, JSON <em>is</em> a type.</p> <p>Could its ADT nature be one of the secrets to JSON's success?</p> <p><center><a href="http://www.lispcast.com/json-and-adt">Read full post</a></center></p> http://www.lispcast.com/notes-from-the-mystery-machine-bus https://plus.google.com/u/0/110981030061712822816/posts/KaSKeg4vQtz Tue 14 Aug 2012 10:38:18 PM CDT <p>Steve Yegge:</p> <blockquote> <p>Software engineering has its own political axis, ranging from conservative to liberal.</p> </blockquote> <p>Steve, I am so often with you. Typically, you write stuff that is very concrete and easy to agree with. In fact, I agree with most of what you have written in your very long rants.</p> <p>But this, I am afraid, is bullshit. Not right, not wrong, just <em>bullshit</em>.</p> <p>I was giving you the benefit of the doubt until I read your list of categorized features, either conservative or liberal. That list made absolutely no objective sense. <strong>There is not one shred of a good idea in the dichotomy you gave.</strong></p> <p>The dichotomy conflates so many different dichotomies into a single one in the name of clarifying a terrible mess. In that way, it makes the same mistake as classifying people into conservative and liberal does. It does not help explain anything. And <strong>it only creates more fighting by arming people with names to call each other</strong>.</p> <p>Which is more &quot;liberal&quot;, Common Lisp or C? Common Lisp protects against the most common types of C errors: memory leaks and buffer overflows. Does that make Common Lisp more conservative because it protects the programmer from errors? But C has compile-time type checks! And &quot;conservative&quot; syntax! Bullshit!</p> <p>But then came the clincher. When you said that Clojure was a conservative language, <strong>I came up with something which may actually have some merit: how <em>opinionated</em> the language is</strong>.</p> <p>Clojure is strongly opinionated. So is Python. So is Haskell.</p> <p>Clojure's opinions: state changes should be explicit, values should be immutable, functions should be separated from data, etc.</p> <p>Python's opinion: code should be well-indented.</p> <p>Haskell's opinions: functions should be pure, types should be consistent.</p> <p>These languages may appear conservative because, in their respective worlds, <strong>the opinions are solidified into laws and imposed on the programmer</strong>. Python does not allow you to write unindented code. Haskell does not allow you to write programs with inconsistent types. You cannot mutate a Clojure map.</p> <p><strong>Perhaps, Steve, you mean to say that you don't like when a programming language's opinion is imposed on the programmer?</strong></p> <p>I personally like some laws and dislike others. For instance, Clojure's immutability is great. <strong>It's not just great because it's possible. It's great because it is enforced.</strong> Nothing can change my values--not me, not you, not anyone! And I like Haskell's type system in production but not during development. I like that my program is guaranteed to have consistent types on production. But in development, I'd rather run it and debug it (for some definition of &quot;run&quot; for a type-inconsistent Haskell program).</p> <p><strong>If you say it like that, it ceases to be bullshit.</strong> And then we can get back into a discussion. Question: Which features should be imposed on the programmer and which should not? Discuss.</p> <p><center><a href="http://www.lispcast.com/notes-from-the-mystery-machine-bus">Read full post</a></center></p> http://www.lispcast.com/the-value-of-values http://www.infoq.com/presentations/Value-Values Tue 14 Aug 2012 10:17:36 PM CDT <p>Rich Hickey is a force of nature. The mark he will leave on programming will reach much farther than the Clojure programming language. The agenda he is setting forth will have as much impact on the notion of state as McCarthy conditionals had on structured programming.</p> <p>Please listen closely. The main idea of this talk goes far deeper than &quot;immutable good, mutable bad&quot;.</p> <p>It is wonderful to be a part of this.</p> <p><center><a href="http://www.lispcast.com/the-value-of-values">Read full post</a></center></p> http://www.lispcast.com/extreme-cleverness-functional-data-structures-in-scala http://www.infoq.com/presentations/Functional-Data-Structures-in-Scala Fri 10 Aug 2012 07:18:58 PM CDT <p>According to Daniel Spiewak, Clojure's vec requires, in the worst case, 7 array accesses and 14 bit operations.</p> <blockquote> <p>On really large datasets--this just astonished me when I discovered it--on really large datasets this data structure [<em>Clojure vec</em>] beats java.util.ArrayList for lookup. It beats java.util.ArrayList for datasets that are in the 2 billion range. That is incredibly fast. java.util.ArrayList is an array, right? And we're beating an array.</p> </blockquote> <p><center><a href="http://www.lispcast.com/extreme-cleverness-functional-data-structures-in-scala">Read full post</a></center></p> http://www.lispcast.com/my-own-url-shortener http://www.windley.com/archives/2012/07/my_own_url_shortener.shtml Mon 30 Jul 2012 04:09:55 PM CDT <p>Phil Windley set up his own URL shortener system. He made it use Apache. It could also work on Amazon S3 (like this very blog). It would be super cheap and virtually maintenance-free. I love it.</p> <p><center><a href="http://www.lispcast.com/my-own-url-shortener">Read full post</a></center></p> http://www.lispcast.com/structure-and-interpretation-pdf https://github.com/sarabander/sicp-pdf Thu 26 Jul 2012 10:44:48 AM CDT <p>Beautifully typeset (with LaTeX). The only issue is that PDF pages are not the best way to view code on a screen. Code should scroll continuously. For that, I would still recommend the <a href="http://mitpress.mit.edu/sicp/">HTML version</a>.</p> <p><center><a href="http://www.lispcast.com/structure-and-interpretation-pdf">Read full post</a></center></p> http://www.lispcast.com/knockbox-an-eventual-consistency-toolkit http://www.infoq.com/presentations/Knockbox-an-Eventual-Consistency-Toolkit Tue 24 Jul 2012 02:43:21 PM CDT <p>I originally dismissed <a href="https://github.com/reiddraper/knockbox">Knockbox</a> as yet another concurrency paradigm for Clojure. But after watching this lecture by its creator, I have changed my mind. The few use cases he gives are enough to convince me that I may someday use it, if only to give a bit of structure to edit conflict resolution.</p> <p>It appears to follow the Clojure library trend and implements work from a <a href="http://hal.archives-ouvertes.fr/inria-00555588/">published academic paper</a>.</p> <p>I will keep it in mind when I want lock-free eventual consistency.</p> <p><center><a href="http://www.lispcast.com/knockbox-an-eventual-consistency-toolkit">Read full post</a></center></p> http://www.lispcast.com/building-user-interfaces-with-seesaw http://www.infoq.com/presentations/Building-User-Interfaces-with-Seesaw Tue 24 Jul 2012 10:04:08 AM CDT <p><a href="https://github.com/daveray/seesaw">Seesaw</a> represents the best of Clojure: a monstrous Java library tamed to be pleasant and docile.</p> <p><center><a href="http://www.lispcast.com/building-user-interfaces-with-seesaw">Read full post</a></center></p> http://www.lispcast.com/state-of-clojure-2012 http://cemerick.com/2012/07/19/2012-state-of-clojure-survey/ Tue 24 Jul 2012 09:39:53 AM CDT <p>Chas Emerick is at it again. Please fill in the survey if you have ever been exposed to Clojure. This is the third year that cemerick has conducted the survey. He does a great job at summarizing the data with nice graphs. Have a look at the <a href="http://cemerick.com/2011/07/11/results-of-the-2011-state-of-clojure-survey/">2011</a> and <a href="http://cemerick.com/2010/06/07/results-from-the-state-of-clojure-summer-2010-survey/">2010</a> survey results. The survey is useful to the entire community. Please participate.</p> <p><center><a href="http://www.lispcast.com/state-of-clojure-2012">Read full post</a></center></p> http://www.lispcast.com/unbreakable-crypto http://www.extremetech.com/extreme/133067-unbreakable-crypto-store-a-30-character-password-in-your-brains-subconscious-memory Thu 19 Jul 2012 10:48:01 AM CDT <p>Good to see someone innovating on user authentication. Username + password is old as dirt.</p> <p><center><a href="http://www.lispcast.com/unbreakable-crypto">Read full post</a></center></p> http://www.lispcast.com/your-coding-philosophies-are-irrelevant http://prog21.dadgum.com/142.html Fri 15 Jun 2012 11:54:28 AM CDT <p>James Hague:</p> <blockquote> <p>Now imagine there are two finished apps that solve roughly identical problems. One is enjoyable to use and popular and making a lot of money. The other just doesn't feel right in a difficult to define way. One of these apps follows all of your development ideals, but which app is it? What if the successful product is riddled with singletons, doesn't check result codes after allocating memory (but the sizes of these allocations are such that failures only occur in pathological cases), and the authors don't know about test-driven development?</p> </blockquote> <p>Imagine two pieces of medical equipment. One is easy to use, easy to clean, and always reliable. The other is buggy, has lots of crevices and corner which seem to collect infected goo, and needs constant maintenance. One of these apps was created by a rigorous design process, extensive testing, and built in an immaculate, air-conditioned factory manned by attractive MD/PhDs. The other was created in a basement from spare parts by a high school dropout with bad hygiene. What if the beautiful machine was created by the dropout?</p> <p>Is it even possible? Is it possible that software can be successful over time if it is not well-built? In my experience, messy software eventually drags new development (including bug fixes) to a halt. Time needs to be invested in cleanup.</p> <p>What I hear Hague saying is that some software architecture choices do not matter. This is true. But some do matter. They are not just important to you as a programmer. They are directly related to the number of bugs, the time it takes to fix a bug, and the time it takes to make a new feature. Don't throw the baby out with the bathwater.</p> <p><center><a href="http://www.lispcast.com/your-coding-philosophies-are-irrelevant">Read full post</a></center></p> http://www.lispcast.com/how-to-answer-a-question http://www.michaelnielsen.org/ddi/how-to-answer-a-question-a-simple-system/ Fri 15 Jun 2012 11:31:18 AM CDT <p><a href="http://scholarworks.uno.edu/td/877/">My Master's thesis</a>^{<a href="#fn1" class="footnoteRef" id="fnref1">1</a>} was very related to this topic, so I thought I would share a little anecdote.</p> <p>Michael Nielsen:</p> <blockquote> <p>As I describe in detail below, their approach was to take the question asked, to rewrite it in the form of a search engine query, or perhaps several queries, and then extract the answer by analysing the Google results for those queries.</p> </blockquote> <p>While I was researching my thesis, I came across <a href="http://ilpubs.stanford.edu:8090/421/1/1999-65.pdf">a paper by Sergey Brin</a> (cofounder of Google) which described a system called DIPRE which tried to do a similar thing using the Google index, though before Google was Google. My favorite quote from the paper was &quot;the Google search engine and other research projects&quot;. Brin has been aware of the power of huge sets of redundant documents for a long time.</p> <p>The system Nielsen describes is interesting and worth a look. I will just nitpick a little.</p> <ol style="list-style-type: decimal"> <li>Why do so much query rewriting? Google does a lot of query augmentation itself now. Also, a high number of documents means it is very likely to find the question exactly as it was posed. Try asking Google a question and see if you can find the answer on the results page.</li> <li>The system does not actually get rid of domain knowledge: it replaces part of the algorithm with a Google search, but there is a lot of domain knowledge of the English language used to extract the data from the text. An implementation of the system would use a simple statistical model of answers to find the text to extract.</li> <li>The system of weighting queries is very hard to justify mathematically. Much better would be a probabilistic system, such as Naive Bayes. Naive Bayes is very simple and, modulo a naive assumption, is mathematically correct.</li> <li>Be careful with questions like &quot;Who shot JFK?&quot; It is difficult for humans to answer, let alone computers.</li> </ol> <div class="footnotes"> <hr /> <ol> <li id="fn1"><p>The introduction to my thesis is a pretty good introduction to the techniques of information extraction in general.<a href="#fnref1">↩</a></p></li> </ol> </div> <p><center><a href="http://www.lispcast.com/how-to-answer-a-question">Read full post</a></center></p> http://www.lispcast.com/idiomatic-way-to-represent-either http://stackoverflow.com/questions/10947636/idiomatic-way-to-represent-sum-type-either-a-b-in-clojure/10951001#10951001 Wed 13 Jun 2012 10:50:59 PM CDT <blockquote> <p>how do you represent sum types, also known as tagged unions and variant records? Something like <code>Either a b</code> in Haskell or <code>Either[+A, +B]</code> in Scala.</p> </blockquote> <p><code>Either</code> has two uses: to return a value of one of two types or to return two values of the same type that should have different semantics based on the tag.</p> <p>The first use is only important when using a static type system. <code>Either</code> is basically the minimum solution possible given the constraints of the Haskell type system. With a dynamic type system, you can return values of any type you want. <code>Either</code> is not needed.</p> <p>The second use <em>is</em> significant but can be accomplished quite simply in two (or more) ways:</p> <ol style="list-style-type: decimal"> <li><code>{:tag :left :value 123} {:tag :right :value &quot;hello&quot;}</code></li> <li><code>{:left 123} {:right &quot;hello&quot;}</code></li> </ol> <blockquote> <p>What I'd like to ensure, is that :tag is always there, and it can take only one of the specified values, and corresponding value is consistently of the same type/behaviour and cannot be nil, and there is an easy way to see that I took care of all cases in the code.</p> </blockquote> <p>If you would like to ensure this statically, Clojure is probably not your language. The reason is simple: expressions do not have types until runtime--until they return a value.</p> <p>The reason a macro will not work is that at macro expansion time, you do not have runtime values--and hence runtime types. You have compile-time constructs like symbols, atoms, sexpressions, etc. You can <code>eval</code> them, but using <code>eval</code> is considered bad practice for a number of reasons.</p> <p><center><a href="http://www.lispcast.com/idiomatic-way-to-represent-either">Read full post</a></center></p> http://www.lispcast.com/programming-language-stages-of-development http://www.lispcast.com/programming-language-stages-of-development Wed 13 Jun 2012 10:12:14 PM CDT <p>I rewatched <a href="http://video.google.com/videoplay?docid=-533537336174204822">Doing with Images makes Symbols</a> recently and there was one bit that I had not absorbed before.</p> <p>In the talk, he explains the cryptic title. He took a simplified model of <a href="http://www.simplypsychology.org/piaget.html">Piaget's Stages of Cognitive Development</a>: corporal -&gt; visual -&gt; symbolic. He wanted to bring these three stages into relation with each other, so he made a sentence: &quot;Doing with Images makes Symbols&quot;. Doing, of course, is the body stage. Images is the visual stage. And symbols is the abstract symbolic stage.</p> <h3 id="doing">Doing</h3> <p>Imagine the <a href="http://el.media.mit.edu/logo-foundation/index.html">Logo programming language</a>. Logo is perfect for small children because it helps tie the visual and symbolic to their main mode of experience. Young children are primarily focused on their own bodily experience. They have trouble thinking from other points of view. But by translating their own actions (moving around) into symbolic instructions (Logo code), they can <em>see</em> the turtle performing the actions. Logo's turtle takes on the child's point of view and makes it visual. <strong>The child learns to see his/her own perspective from the outside</strong>. The coordinate system is egocentric. For example, the <code>FORWARD</code> command moves the turtle in the direction it is facing.</p> <p>Smalltalk includes the same egocentric perspective. Each object has its own perspective of the other objects in the system. Smalltalk objects could ask &quot;who are my neighbors in the list I am in&quot;. Squeak simulates a space that the objects inhabit which includes collision detection. This perspective, I would argue, is one of the unsung benefits of Object-Oriented Programming: the ability to program from the <strong>perspective of a single object at a time</strong>, freeing your mind from thinking about the inner workings of the rest of the objects. Objects are not just meant to be strung together but can be &quot;embodied&quot; by their programmer who sees from their unique perspective.</p> <h3 id="symbols">Symbols</h3> <p>The other end of the developmental spectrum is the symbolic. The obvious choice for symbolic programming is Lisp. Programs take on a very abstract quality and require advanced programming techniques. In this perspective, the programmer has a god-like, symbolic semantic of the workings of the system and <strong>builds abstractions in a calculus with simple yet powerful rules</strong>. Further, the programmer manipulates code in code. The coordinate system is abstract and relational. Shapes are manipulated in an abstract representation, not as pixels occupying space. A value may encode abstract knowledge (line between a and b) instead of specific coordinates.</p> <h3 id="images">Images</h3> <p>In the middle is the visual stage. I am going out on a limb, but I would like to posit that Java exemplifies this middle-ground perspective. In this perspective, you think and understand visually. You draw diagrams. <strong>You think in terms of archetypal interactions</strong> (client-server, MVC, etc). You can simultaneously conceptualize several roles in a single group of interacting objects. The coordinate system is cartesian, taking an external, objective perspective.</p> <p>This is not to say that Java does not include any corporal perspective, nor that Lisp is all symbolic. I am talking in broad generalities about <em>predominance</em>.</p> <h3 id="not-one-at-a-time-but-all-at-once">Not one-at-a-time but all-at-once</h3> <p>The interesting thing about Piaget's stages are that they are stages of dominance, not a rocket-stage-jettison progression. That is, we can still, as adults, think in terms of any of the prior levels. In fact, <strong>the most successful scientists and mathematicians work on the earliest levels (corporal/visual)</strong>. Einstein claimed he had body sensations about relativity and his disabilities with abstract symbols is well documented. These three types of thinking are done by different <em>parts</em> of the brain. The parts are always there but take dominant roles at different times in your life.</p> <p>How this relates to programming language design is that when we are designing a programming system, <strong>we should include all of these ways of thinking</strong> so that the programmer can choose the best way to think about the problem. The easiest way to draw a circle is from a self-centered perspective in terms of motion and gross actions. The easiest way to plan a protocol is visually with boxes and lines or swim lane diagrams. Once translated into symbolic code, syntactic and semantic abstractions become evident, and can be manipulated as such.</p> <p>The trick of good language design is to facilitate programming at any level and translation into the other levels. <strong>How can we perform this trick?</strong></p> <p><center><a href="http://www.lispcast.com/programming-language-stages-of-development">Read full post</a></center></p> http://www.lispcast.com/why-is-a-monad-like-a-writing-desk http://www.infoq.com/presentations/Why-is-a-Monad-Like-a-Writing-Desk Wed 13 Jun 2012 04:53:47 PM CDT <p>The best explanation of Monads for beginners I have seen yet.</p> <p><center><a href="http://www.lispcast.com/why-is-a-monad-like-a-writing-desk">Read full post</a></center></p> http://www.lispcast.com/statistical-graphics-clojurescript http://www.infoq.com/presentations/Statistical-Graphics-ClojureScript Wed 13 Jun 2012 04:42:12 PM CDT <p>Kevin Lynagh shows off some cool code for easily generating (and automatically updating!) DOM from Clojurescript. I can't wait to get to experiment with this.</p> <p><center><a href="http://www.lispcast.com/statistical-graphics-clojurescript">Read full post</a></center></p> http://www.lispcast.com/the-future-is-specific http://www.chris-granger.com/2012/05/21/the-future-is-specific/ Tue 22 May 2012 10:59:00 AM CDT <p>Chris Granger:</p> <blockquote> <p>the real potential is in making it trivial to build domain specific tools</p> </blockquote> <p>Chris is definitely onto something valuable. Eclipse has had plugins for a long time, but they were always expensive to write. Emacs has been programmable forever. But it looks like Chris is making it even easier still and in a more modern package.</p> <blockquote> <p>Imagine being able to create these sorts of experiences on a whim instead of needing hundreds of hours to even get something simple working. If you couple that with the generalized editing capabilities I showed last time, you have what we believe to be the future of tools: an environment that you are able to mold to the exact shape of your problem.</p> </blockquote> <p>Without diminishing the great work Chris is doing, I have one question: has this not been the promise of personal computing since its conception at Xerox PARC?</p> <p>Thank you, Chris, for bringing these ideas back into the realm of possibility.</p> <p><center><a href="http://www.lispcast.com/the-future-is-specific">Read full post</a></center></p> http://www.lispcast.com/light-table-yc http://www.chris-granger.com/2012/05/17/light-table-is-in-yc/ Fri 18 May 2012 10:01:30 AM CDT <p>Wow.</p> <p><center><a href="http://www.lispcast.com/light-table-yc">Read full post</a></center></p> http://www.lispcast.com/the-story-of-send http://www.google.com/green/storyofsend/ Wed 16 May 2012 10:14:11 AM CDT <p>Nice animation which follows an email sent from a computer to a mobile phone.</p> <p><center><a href="http://www.lispcast.com/the-story-of-send">Read full post</a></center></p> http://www.lispcast.com/ambrose-interview http://www.lispcast.com/ambrose-interview Wed 16 May 2012 08:28:50 AM CDT <p>I am really excited about an interview with Ambrose Bonnaire-Sergeant on the <a href="http://www.clojuregazette.com/">Clojure Gazette</a> that will be coming shortly. Be sure to sign up if you want to get it.</p> <p>You may want to <a href="http://twitter.com/ambrosebs">say hi to Ambrose on Twitter</a>.</p> <p><center><a href="http://www.lispcast.com/ambrose-interview">Read full post</a></center></p> http://www.lispcast.com/organizing-functional-code-for-parallel-execution http://vimeo.com/6624203 Tue 15 May 2012 05:27:10 PM CDT <p>A great talk by programming language legend Guy Steele. (referenced in Rich Hickey's <a href="http://clojure.com/blog/2012/05/15/anatomy-of-reducer.html">recent post</a>.)</p> <p><center><a href="http://www.lispcast.com/organizing-functional-code-for-parallel-execution">Read full post</a></center></p> http://www.lispcast.com/anatomy-of-a-reducer http://clojure.com/blog/2012/05/15/anatomy-of-reducer.html Tue 15 May 2012 02:40:41 PM CDT <p>Rich Hickey:</p> <blockquote> <p>I hope this makes reducers easier to understand, use and define.</p> </blockquote> <p>It does.</p> <p><center><a href="http://www.lispcast.com/anatomy-of-a-reducer">Read full post</a></center></p> http://www.lispcast.com/bishop http://twitch.nervestaple.com/2012/05/07/bishop/ Fri 11 May 2012 02:41:18 PM CDT <p>Doh! This looks like a library that I have that is 90% ready to release. Though mine takes a slightly different tack.</p> <p>I guess I will have to get it ready for release.</p> <p><center><a href="http://www.lispcast.com/bishop">Read full post</a></center></p> http://www.lispcast.com/precog-io http://precog.io/ Fri 11 May 2012 02:00:36 PM CDT <p>I can think of many uses for this. Store datapoints in the cloud. Prebaked analysis plugins. Some relational semantics in the query language.</p> <p><center><a href="http://www.lispcast.com/precog-io">Read full post</a></center></p> http://www.lispcast.com/interview-james-hague http://www.mailsend-online.com/blog/?p=90 Fri 11 May 2012 11:32:43 AM CDT <p>James Hague (of <a href="http://prog21.dadgum.com/">Programming in the 21st Century</a> fame):</p> <blockquote> <p>I've had an off and on romance with Forth. It's such a subversive language; you can fit an entire Forth development system into the space taken by the executable header of a &quot;Hello World&quot; program generated by a C compiler. But I've finally decided that the whole Forth concept is too minimal in the modern world. It's like using an artist's paintbrush to paint a house. The Forthers will respond with comments like &quot;If you think you need to paint the house, then you haven't thought about the problem enough.&quot; They'll suggest that a tent will keep you dry as well as a house and is much easier to maintain. Meanwhile, someone with a big, bulky brush is almost finished with the first coat of paint on the house. There has to be a happy medium between a 20K Forth and a C++ compiler than won't fit on a Zip disk.</p> </blockquote> <p>A great metaphor for programming in Forth.</p> <p><center><a href="http://www.lispcast.com/interview-james-hague">Read full post</a></center></p> http://www.lispcast.com/reducers-library-collection-processing http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html Thu 10 May 2012 04:04:21 PM CDT <p>Rich Hickey is still finding ways to apply simplicity to programming language design. It is amazing what can be done by starting your work by looking up a word in a dictionary instead of applying common practice.</p> <p><center><a href="http://www.lispcast.com/reducers-library-collection-processing">Read full post</a></center></p> http://www.lispcast.com/simplicity-matters-rich-hickey http://www.youtube.com/watch?v=rI8tNMsozo0&feature=relmfu Thu 03 May 2012 09:59:33 AM CDT <p>Rich Hickey:</p> <blockquote> <p>We focus on ourselves ... rather than [on] the programs.</p> </blockquote> <p>Software should be made of simple components because it makes the software better, not because it makes it easier for us as developers.</p> <p><center><a href="http://www.lispcast.com/simplicity-matters-rich-hickey">Read full post</a></center></p> http://www.lispcast.com/yahoos-doug-crockford-on-javascript http://coding.smashingmagazine.com/2012/04/27/yahoos-doug-crockford-on-javascript/?utm_source=javascriptweekly&utm_medium=email Fri 27 Apr 2012 02:34:43 PM CDT <p>Doug Crockford about developing JSON:</p> <blockquote> <p>One interesting story about leaving things out: as we got closer to releasing JSON I decided to take out the ability to do comments. When translating JSON into other languages, often times the commenting piece was the most complicated part. By taking the commenting out we reduced the complexity of the parsers by half—everything else was just too simple.</p> </blockquote> <p>I have wondered about why comments are not part of JSON. Now it makes sense.</p> <blockquote> <p>One of the best features of JSON is that it’s stable. If your program works now, it will work forever, and that is an attractive thing.</p> </blockquote> <p>Yum. He has found a reasonable data structure format that could indeed last forever.</p> <blockquote> <p>I still get notes from people saying they’ve got great ideas for the next version. But there isn’t going to be a next version. I always say you’re free to invent a new standard and promote it as much as you like.</p> </blockquote> <p><center><a href="http://www.lispcast.com/yahoos-doug-crockford-on-javascript">Read full post</a></center></p> http://www.lispcast.com/cljs-binding http://fluentsoftware.github.com/cljs-binding/ Thu 26 Apr 2012 09:10:00 PM CDT <p>This morning, in the <a href="http://www.clojuregazette.com/">Clojure Gazette</a>, I mentioned that Clojure was still looking for the &quot;vital point&quot; of the browser. Could this library hit that vital point?</p> <p><center><a href="http://www.lispcast.com/cljs-binding">Read full post</a></center></p> http://www.lispcast.com/light-table-john-gruber http://daringfireball.net/linked/2012/04/23/light-table Tue 24 Apr 2012 03:14:38 PM CDT <p>Get ready for major fundage.</p> <p><center><a href="http://www.lispcast.com/light-table-john-gruber">Read full post</a></center></p> http://www.lispcast.com/clojurescript-to-javascript http://himera.herokuapp.com/synonym.html Tue 24 Apr 2012 02:35:25 PM CDT <p>A well-chosen and well-designed reference explaining how to convert Javascript to Clojurescript.</p> <p><center><a href="http://www.lispcast.com/clojurescript-to-javascript">Read full post</a></center></p> http://www.lispcast.com/how-to-write-clean-testable-code http://www.youtube.com/watch?v=XcT4yYu_TTs&feature=relmfu Tue 24 Apr 2012 01:51:00 PM CDT <p>A good talk by Miško Hevery. I like his point that he likes constructors that have no logic. They simply assign data values passed to them to the appropriate fields instead of doing a lot of reasoning about the values. He likes to decomplect the logic from the data, and claims that it makes code more testable.</p> <p>It reminds me of Clojure, where data values are typically built using literal maps. Clojure encourages a separation between logic and data construction and generally avoids this problem which is common in Java.</p> <p><center><a href="http://www.lispcast.com/how-to-write-clean-testable-code">Read full post</a></center></p> http://www.lispcast.com/clostache https://github.com/fhd/clostache Mon 23 Apr 2012 07:26:16 PM CDT <p>Just what I needed. Clojure is developing faster than I can keep up. But we need to come up with better names for libraries.</p> <p><center><a href="http://www.lispcast.com/clostache">Read full post</a></center></p> http://www.lispcast.com/google-python-style-guide http://google-styleguide.googlecode.com/svn/trunk/pyguide.html Mon 23 Apr 2012 01:32:05 PM CDT <p>I really like style guides.</p> <p><center><a href="http://www.lispcast.com/google-python-style-guide">Read full post</a></center></p> http://www.lispcast.com/review-clojure-programming http://aviflax.com/post/review-clojure-programming-by-chas-emerick-brian-carper-and-cristophe-grand/ Mon 23 Apr 2012 08:36:37 AM CDT <p>Avi Flax reviewing Clojure Programming:</p> <blockquote> <p>The writing, examples, and organization are all excellent. And the book gets extra points for going beyond just explaining the language and how to use it, by being extra-comprehensive and covering how to really use the full Clojure ecosystem to build really useful software.</p> <p>This is worth highlighting: if the book had been comprised of only chapter 1, “Down the Rabbit Hole”, and the first 2 parts, “Functional Programming and Concurrency” and “Building Abstractions”, it would have been an excellent book which I’d be recommending wholeheartedly. The inclusion of the subsequent parts, “Tools, Platform, and Projects”, “Practicums”, and “Miscellanea” make the book an invaluable resource and a fantastic value.</p> </blockquote> <p>I will have to get it.</p> <p><center><a href="http://www.lispcast.com/review-clojure-programming">Read full post</a></center></p> http://www.lispcast.com/take-5-daniel-spiewak http://clojure.com/blog/2012/04/19/take5-daniel-spiewak.html Fri 20 Apr 2012 06:11:06 PM CDT <p>Daniel Spiewak:</p> <blockquote> <p>... a &quot;pluggable&quot; type system is really not very useful unless you can compose multiple type systems into a coherant whole, and this is where problems arise. Anyone who has studied type theory in a formal context and run a few soundness proofs will understand that seemly innocuous and self-contained type rules will almost always interact in surprising ways.</p> </blockquote> <p>This is certainly true if you are enforcing a strict type discipline on your language and rejecting programs that do not comply with this discipline, as type systems do. But it has yet to be shown that useful static analysis parts cannot be composed. They merely provide information, so they may be able to work orthogonally.</p> <blockquote> <p>By and large though, I think that most of the awesome bullet-points that Clojure hits have already been stolen whole-sale by Scala. :-) A few examples: vector, map/set, agents (in Akka), STM (in Scala STM), SLIME (see ENSIME), etc. The Scala community is very actively watching the Clojure community. Y'all are a very fertile source of inspiration!</p> </blockquote> <p><center><a href="http://www.lispcast.com/take-5-daniel-spiewak">Read full post</a></center></p> http://www.lispcast.com/clojure-1.4-reader-literals https://gist.github.com/2399254 Wed 18 Apr 2012 11:43:27 AM CDT <p>A cool use of reader literals new in 1.4. Though see my comment in the gist.</p> <p><center><a href="http://www.lispcast.com/clojure-1.4-reader-literals">Read full post</a></center></p> http://www.lispcast.com/clojure-1.4-released https://groups.google.com/forum/?fromgroups#!topic/clojure/H4f2nbB6gWI Wed 18 Apr 2012 09:17:05 AM CDT <p>Big news.</p> <p>Change your leiningen dependency to:</p> <pre><code>[[org.clojure/clojure &quot;1.4.0&quot;]]</code></pre> <p><center><a href="http://www.lispcast.com/clojure-1.4-released">Read full post</a></center></p> http://www.lispcast.com/light-table-kickstarter http://www.kickstarter.com/projects/306316578/light-table Wed 18 Apr 2012 08:00:35 AM CDT <p>It looks like it is doing well, but still needs some help. Please go fund it if you are interested.</p> <p><center><a href="http://www.lispcast.com/light-table-kickstarter">Read full post</a></center></p> http://www.lispcast.com/thinkrelevance-podcast-009-alan-dipert http://thinkrelevance.com/blog/2012/04/09/thinkrelevance-the-podcast-episode-009-alan-dipert Mon 16 Apr 2012 11:26:41 AM CDT <p>I wish they had more time to talk about function level programming. <a href="http://www.jsoftware.com/">J</a> is an example of a function level language.</p> <p>And a great <a href="http://www.cs.cmu.edu/~crary/819-f09/Backus78.pdf">article by Backus</a> about function-level programming introduces the idea and its benefits. The basic idea is that we stop talking about &quot;functions returning values&quot; and start talking about &quot;functions which behave like other functions&quot;. For instance, the function that constantly returns 1.</p> <p>The benefit is that you can create an algrebra of program transformations which allows two functions to be compared for equality. ^{<a href="#fn1" class="footnoteRef" id="fnref1">1</a>}</p> <p>For example:</p> <pre><code>(defn sum1 [l] (reduce + l)) (defn sum2 [l] (reduce + l))</code></pre> <p>A compiler could easily check the equality of these functions since they have the same definition. Note that the Clojure compiler does not even do this simple kind of check.</p> <p>An even simpler example:</p> <pre><code>(def const1 (constantly 1)) (def always1 (constantly 1))</code></pre> <p>These two functions are obviously equivalent and it could be trivial to make the compiler recognize this. These are examples of programming at the function level. At the function level, you program with at least first-order functions instead of with 0-order values.</p> <p>Let us imagine that we have this function that sums two lists:</p> <pre><code>(defn sumlists [l1 l2] (reduce + (concat l1 l2)))</code></pre> <p>And an equivalent function:</p> <pre><code>(defn addlists [l1 l2] (apply + [(reduce + l1) (reduce + l2)]))</code></pre> <p>It is easy to see that they do the same thing, but very difficult for the compiler to do so. (I used apply to make it first-order.) But with the proper transformation rules, these can be made equivalient:</p> <pre><code>if f is distributive then reduce f (concat l1 l2) &lt;=&gt; apply f [(reduce f l1) (reduce f l2)] + is distributive</code></pre> <p>This basically says that reduce is distributive over concat. Now we can transform one into the other and infer their equivalence. These transformations can allow the compiler to deeply optimize at a high level.</p> <p>Backus's idea is that we only program at first-order or higher so that we can guarantee to always be able to transform the programs and determine function identity. Clojure allows us to program at the 0-order (value) level. Many functions will not be able to participate in the function-level world.</p> <p>However, there is a large subset of most programs that are at the function-level, and some that are not that could easily be translated into that level. Could we augment the Clojure compiler to recognize this information and allow an <code>=</code> function for functions?</p> <p>Sounds like a job for <a href="https://github.com/clojure/core.logic">core.logic</a>.</p> <div class="footnotes"> <hr /> <ol> <li id="fn1"><p>Christophe Grand has discussed a good use case for equality of functions <a href="http://clj-me.cgrand.net/2011/10/17/valued-functions/">here</a>.<a href="#fnref1">↩</a></p></li> </ol> </div> <p><center><a href="http://www.lispcast.com/thinkrelevance-podcast-009-alan-dipert">Read full post</a></center></p> http://www.lispcast.com/introduction-to-haskell http://www.lispcast.com/introduction-to-haskell Mon 16 Apr 2012 09:01:47 AM CDT <p>Last Thursday I gave a talk to <a href="http://www.gnocode.com/">GNO Code</a>. It was about learning Haskell and my experiences programming in it professionally.</p> <p>There was no video of the talk but I have made the slides available online:</p> <ul> <li><p><a href="/files/slides/haskell-slides.pdf">Slides in PDF</a></p></li> <li><p><a href="/files/slides/haskell-slides.odp">Slides in OpenOffice</a></p></li> </ul> <p><center><a href="http://www.lispcast.com/introduction-to-haskell">Read full post</a></center></p> http://www.lispcast.com/meteor http://www.meteor.com/screencast Fri 13 Apr 2012 06:16:22 PM CDT <p>It looks like a pretty sweet web server that lets you do all front-end development.</p> <p><center><a href="http://www.lispcast.com/meteor">Read full post</a></center></p> http://www.lispcast.com/light-table http://www.chris-granger.com/2012/04/12/light-table---a-new-ide-concept/ Fri 13 Apr 2012 05:37:42 PM CDT <p>We have needed this for years.</p> <p>And might I add that Clojure is smoking hot right now.</p> <p><center><a href="http://www.lispcast.com/light-table">Read full post</a></center></p> http://www.lispcast.com/edit-scheme-on-your-ipad-via-the-parse-tree http://slidetocode.com/2012/04/05/lisping-released/ Thu 05 Apr 2012 10:01:10 AM CDT <p>Using Scheme is a good idea, because of structural editing, but applications like this need to break away from the textual past. There is so much opportunity for graphic design and user interface design to push programming forward. We are still stuck in the teletype era.</p> <p><center><a href="http://www.lispcast.com/edit-scheme-on-your-ipad-via-the-parse-tree">Read full post</a></center></p> http://www.lispcast.com/client-side-logging-with-google-analytics http://www.thetaboard.com/blog/client-side-error-logging-with-google-analytics?r=378 Thu 05 Apr 2012 09:55:56 AM CDT <p>Brilliant.</p> <p><center><a href="http://www.lispcast.com/client-side-logging-with-google-analytics">Read full post</a></center></p> http://www.lispcast.com/rich-hickey-datomic http://www.infoq.com/interviews/hickey-datomic Wed 04 Apr 2012 02:23:48 PM CDT <p>Interviewed at QCon London 2012.</p> <p><center><a href="http://www.lispcast.com/rich-hickey-datomic">Read full post</a></center></p> http://www.lispcast.com/next-openstep-return-of-jobs http://www.youtube.com/watch?v=QhhFQ-3w5tE Mon 02 Apr 2012 04:16:07 PM CDT <p><a href="http://youtu.be/QhhFQ-3w5tE?t=16m26s">Steve Jobs, 1997</a>:</p> <blockquote> <p>When I went to Xerox PARC in 1979 and saw the original genesis of the Graphical User Interface, they actually showed me three things. And I was so blinded by the first that I didn't hang around to find out about the other two. It took me years to rediscover them. The first was of course the Graphical User Interface which Xerox PARC had pioneered and they had a lot of it right and a lot of it was left to be completed. But the other two things -- the second was Object Oriented Programming. They had ita ll running back in 1979. And the third was networking. They had several hundred Altos hooked up with networked printing, network file servers, email, all in 1979. If I had just stayed for another twenty minutes . . .</p> </blockquote> <p>Jobs also shows that until he left Apple, he was still commercializing his visits to Xerox PARC. With iCloud he completed the trifecta of GUI, OOP, and Networked Computing that was already available thirty years ago.</p> <p>Steve Jobs, though he was not a programmer, also understood Object Oriented programming better than most programmers. Cue it up to 23:00 for his explanation and demonstration. He of course borrowed his understanding right from the source: Alan Kay and Xerox PARC.</p> <p><center><a href="http://www.lispcast.com/next-openstep-return-of-jobs">Read full post</a></center></p> http://www.lispcast.com/himera-model http://blog.fogus.me/2012/03/27/compiling-clojure-to-javascript-pt-3-the-himera-model/ Thu 29 Mar 2012 08:55:17 AM CDT <p>Dividing the read-compile-eval-print loop over client and server. In Himera, eval and print happen in the browser, while the rest happen on the Himera server.</p> <p><center><a href="http://www.lispcast.com/himera-model">Read full post</a></center></p> http://www.lispcast.com/rich-hickey-keynote http://blip.tv/clojure/rich-hickey-keynote-5970064 Fri 16 Mar 2012 11:18:55 AM CDT <p>I just rewatched this great talk where Rich Hickey talks about some future directions for Clojure.</p> <h3 id="notes">Notes</h3> <ul> <li>Different build targets - leaner and fatter builds of Clojure for deployment and development</li> <li>Clojure in Clojure - protocols, records, and deftype at the bottom</li> <li>Code analysis using core.logic - type checking, other analysis</li> <li>Pods - safely encapsulate state change</li> <li>Extensible reader - making Clojure a better format than JSON and XML</li> </ul> <p><center><a href="http://www.lispcast.com/rich-hickey-keynote">Read full post</a></center></p> http://www.lispcast.com/quil https://github.com/quil/quil Fri 16 Mar 2012 11:14:20 AM CDT <p>Fine, fine work. I had a project I was doing in OpenGL that I will have to convert to Quil.</p> <p><center><a href="http://www.lispcast.com/quil">Read full post</a></center></p> http://www.lispcast.com/clojure-gazette http://www.clojuregazette.com/ Sun 11 Mar 2012 06:39:22 PM CDT <p>I was inspired by <a href="http://rubyweekly.com">Ruby Weekly</a> and <a href="http://javascriptweekly.com">Javascript Weekly</a> to create an email newsletter specifically targeting Clojure programmers.</p> <p>The Clojure community is incredibly inspiring. It is at once <strong>pragmatic</strong> and <strong>philosophical</strong>. It looks to the <strong>future</strong> and learns from <strong>history</strong>. It adheres to its own vision while drawing from other languages. I wanted to create something that enhanced these wonderful features of the Clojure community.</p> <p>The <em>Clojure Gazette</em> is a mix of links to news, lectures, papers, libraries, and more that gives a weekly taste of the swirls of activity surrounding Clojure.</p> <p><a href="http://www.clojuregazette.com/">Click here to subscribe. It's free.</a></p> <p><center><a href="http://www.lispcast.com/clojure-gazette">Read full post</a></center></p> http://www.lispcast.com/paradigms-as-subtractive http://www.lispcast.com/paradigms-as-subtractive Thu 09 Feb 2012 05:22:11 PM ART <p>I recently watched a <a href="http://skillsmatter.com/podcast/agile-testing/bobs-last-language">talk by Uncle Bob Martin called <em>The Last Programming Language</em></a>. Since I had just written a post relating <a href="/indirection">indirection mechanisms to expressive power</a>, I was intrigued by Uncle Bob's idea and wanted to explore it further.</p> <p>Uncle Bob gives a brief history of programming paradigms. Here are the ones he mentions:</p> <ul> <li><a href="http://en.wikipedia.org/wiki/Modular_programming">Modular Programming</a></li> <li><a href="http://en.wikipedia.org/wiki/Structured_programming">Structured Programming</a></li> <li><a href="http://en.wikipedia.org/wiki/Object-oriented_programming">Object Oriented Programming</a></li> <li><a href="http://en.wikipedia.org/wiki/Functional_programming">Functional Programming</a></li> </ul> <p>His perspective was that programming paradigms are generally subtractive.</p> <ul> <li>Modular programming removed large programs</li> <li>Structured programming removed GOTOs</li> <li>Object Oriented programming removed hand-rolled vtables</li> <li>Functional programming removed mutable state</li> </ul> <p>He concludes by saying that there's nothing left to take away and a language of the future would have to have all of these.</p> <blockquote> <p>Perspective is worth 80 IQ points. -- Alan Kay</p> </blockquote> <p>The idea that paradigms are subtractive is interesting. It is interesting to look at what is taken away. However, I would rather say that paradigms replace a manual, error-prone pattern with a more reliable one (usually through <a href="/indirection">indirection</a>). Structured programming didn't just ban GOTO. It also encouraged conditionals and loops. Object Oriented programming didn't just prohibit tables of function pointers, it gave a unified syntax and semantics for message dispatch. But, still, I do appreciate the perspective.</p> <p>On the other hand, I think Uncle Bob has left out many interesting paradigms from his history. <a href="http://en.wikipedia.org/wiki/Programming_paradigm">Wikipedia lists 59 paradigms</a> in a hierarchy. (Note that they are not mutually exclusive!) Let's see if we can apply his subtractive perspective to those paradigms.</p> <h3 id="aspect-oriented-programmingaop"><a href="http://en.wikipedia.org/wiki/Aspect-oriented_programming">Aspect-oriented programming</a></h3> <p><strong>. . . aims to increase modularity by allowing the separation of cross-cutting concerns.</strong></p> <h4 id="what-does-it-remove">What does it remove?</h4> <p>The mixing of concerns.</p> <h3 id="concatenative-programmingcp"><a href="http://en.wikipedia.org/wiki/Concatenative_programming_language">Concatenative programming</a></h3> <p><strong>A concatenative programming language is a point-free programming language in which all expressions denote functions and the juxtaposition of expressions denotes function composition.</strong></p> <h4 id="what-does-it-remove-1">What does it remove?</h4> <p>Explicit arguments to functions (point-free!).</p> <h3 id="constraint-programmingconp"><a href="http://en.wikipedia.org/wiki/Constraint_programming">Constraint programming</a></h3> <p><strong>. . . is where relations between variables are stated in the form of constraints.</strong></p> <h4 id="what-does-it-remove-2">What does it remove?</h4> <p>Specifying the sequence of steps to execute.</p> <h3 id="logic-programminglogic"><a href="http://en.wikipedia.org/wiki/Logic_programming">Logic programming</a></h3> <p><strong>. . . is the use of mathematical logic for computer programming.</strong></p> <h4 id="what-does-it-remove-3">What does it remove?</h4> <p>Much like constraints, it removes the explicit steps to execute.</p> <h3 id="array-programmingarray"><a href="http://en.wikipedia.org/wiki/Array_programming">Array programming</a></h3> <p><strong>. . . is the generalization of operations on scalar values to apply transparently to vectors, matrices, and higher dimensional arrays.</strong></p> <h4 id="what-does-it-remove-4">What does it remove?</h4> <p>The distinction between scalar and vector quantities.</p> <h3 id="language-oriented-programminglop"><a href="http://en.wikipedia.org/wiki/Language-oriented_programming">Language-oriented programming</a></h3> <p><strong>. . . is the creation of a domain-specific language for the problem, then solve the problem in that language.</strong></p> <h4 id="what-does-it-remove-5">What does it remove?</h4> <p>General purpose programming languages.</p> <p>One more.</p> <h3 id="event-driven-programmingep"><a href="http://en.wikipedia.org/wiki/Event-driven_programming">Event-driven programming</a></h3> <p><strong>. . . means the flow of the program is determined by response to events.</strong></p> <h4 id="what-does-it-remove-6">What does it remove?</h4> <p>The <code>main</code> function?</p> <p>The perspective has some merits. But it also has flaws. I've already mentioned that it does not specify what the removed thing is replaced with, which may be more important than the removal itself. Also, the perspective probably does not apply to all programming paradigms, as Uncle Bob claims. He's exhibiting a blindness toward the possibility of future change because he can't imagine it.</p> <p>I also don't think we have come to the end of programming paradigms. Although I can't predict what paradigms will be invented in the future (if I could, I'd just invent it), I don't think we're looking at mere incremental improvement. It's just that after racking my brain I can't come up with much.</p> <p><a href="http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute">This video</a> holds some ideas.</p> <p><center><a href="http://www.lispcast.com/paradigms-as-subtractive">Read full post</a></center></p> http://www.lispcast.com/introduction-to-logic-programming-with-clojure http://blip.tv/clojure/ambrose-bonnaire-sergeant-introduction-to-logic-programming-with-clojure-5936196 Thu 09 Feb 2012 05:11:45 PM ART <p>This talk makes me even more excited about <a href="https://github.com/clojure/core.logic"><code>core.logic</code></a>.</p> <p><center><a href="http://www.lispcast.com/introduction-to-logic-programming-with-clojure">Read full post</a></center></p> http://www.lispcast.com/why-ruby http://vimeo.com/17420638 Wed 08 Feb 2012 12:10:52 AM ART <p>I've been watching a lot of Clojure videos at the moment. I really appreciate some of the more philosophical directions in Clojure talks. Then I started thinking that other languages must have that type of philosophical talk, too.</p> <p>So I searched for &quot;Ruby lectures&quot; and found this talk by David Heinemeier Hansson. He talks about what he likes about Ruby. He really shows his love for the language that has kept him engaged for so long. He ends with a passionate assessment of Ruby as a language that fosters freedom.</p> <p>It's not exactly <a href="http://blip.tv/clojure/hammock-driven-development-4475586">Hammock-Driven Development</a>, but it's still an interesting talk and one that all dynamic programming language fans should appreciate.</p> <p><center><a href="http://www.lispcast.com/why-ruby">Read full post</a></center></p> http://www.lispcast.com/ousterhouts-dichotomy http://blip.tv/clojure/stuart-halloway-ousterhout-s-dichotomy-isn-t-part-2-of-the-simplicity-power-focus-series-5936308 Tue 07 Feb 2012 06:56:21 PM ART <p>An excellent and down-to-earth talk from Stuart Halloway explaining some of the decisions made in Clojure as they relate to power. Particularly, I like that Halloway deconflated the general power of a language from its expressive power.</p> <p><center><a href="http://www.lispcast.com/ousterhouts-dichotomy">Read full post</a></center></p> http://www.lispcast.com/unpretty http://oblong-code.blogspot.com/2012/02/unpretty.html Mon 06 Feb 2012 03:28:59 PM ART <p>Snut:</p> <blockquote> <p>It wasn't pretty, but Leiningen is now generating a large .jar containing almost everything required to run a chunk of stuff excised from my &quot;random clojure braindump&quot; folder. So now I can in theory show my tiny vestigal 3D roguelike/turn-based Dungeon Master/hex-based Legend of Grimrock clone to people! People that don't have Clojure installed!</p> </blockquote> <p>I can't wait.</p> <blockquote> <p>How do people approach cross-project hacking at a small scale?</p> </blockquote> <p>It's still tough to do so in Clojure at the moment.</p> <p><center><a href="http://www.lispcast.com/unpretty">Read full post</a></center></p> http://www.lispcast.com/indirection http://www.lispcast.com/indirection Sat 04 Feb 2012 02:39:59 PM ART <h3 id="what-defines-a-languages-expressive-power">What defines a language's expressive power?</h3> <p>Expressive power is hard to pin down in programming languages. In this post, I want to explore how <em>indirection mechanisms</em> lend expressiveness to a language. By indirection, I mean something that happens at compile time or run time which was not explicitly specified in the code. By mechanism, I mean something with well-defined, rule-governed semantics.</p> <p>Indirection mechanisms are typically what makes a program shorter, easier to write, and easier to reason about. Instead of writing machine code directly, you are relying on the compiler or runtime to do the heavy lifting.</p> <p>I posit that the development of indirection mechanisms closely follows the development of multiplicative expressive power. One line of Python is worth far more than 100 lines of C and more than 1000 lines of Assembly. And rather than debate about expressive power in different languages, I'd like to simply catalog some of the more obvious and important indirection mechanisms out there.</p> <p>While many languages might share a given indirection mechanism, I don't know all languages, so I am just going to go with my personal experience and <em>group them roughly by programming languages</em> I am familiar with. I would love to hear of more mechanisms, if you know of them.</p> <h3 id="assembly">Assembly</h3> <p>Depending on the features available, Assembly can be seen as simply a more convenient language to write in than machine language. But this convenience comes from a indirection.</p> <ul> <li><p>Named instructions</p> <p>The assembler looks up the name of an instruction in a table and converts it to the machine code. It is much more convenient to remember a mnemonic sequence of characters than an arbitrary number.</p></li> <li><p>Labeled statements</p> <p>Instead of calculating a jump offset from the current instruction, you just name a line of code and the assembler will calculate it for you. It is much less error prone and immune to changes in the program.</p></li> </ul> <h3 id="c">C</h3> <p>C has many indirection mechanisms. Most of them were not invented in C. However, from a historical and pedagogical perspective, C is a good contrast to Assembly. Both are relatively low-level and ubiquitous, yet C is a huge leap beyond Assembly in terms of indirection.</p> <ul> <li><p>Automatic number coercion</p> <p>Numbers in C are automatically coerced &quot;up&quot; when operated on, whereas in machine language, the values would have to be explicitly converted. You reduce mathematical errors because the machine can do a better job than you.</p></li> <li><p>Function call semantics</p> <p>Function calls compile to a lot of code, including copying the arguments to the stack. Function calling in C is more convenient.</p></li> <li><p>Recursive expressions</p> <p>In machine code and Assembly, instructions are written linearly in sequence. In C, however, expressions can be nested. The compiler will convert them to the appropriate sequence of instructions. Nested expressions are easier to understand.</p></li> <li><p>Structured programming</p> <p>Conditionals and loops provide a simpler, less error-prone way to code than machine code jumps.</p></li> </ul> <h3 id="lisp">Lisp</h3> <p>Lisp's main evaluation semantic is the source of much veneration and arguably is the <em>Ur</em> indirection mechanism. I am talking about the <code>eval</code> function as defined in the original Lisp paper by McCarthy. There are more mechanism, but they are too many to list here.</p> <ul> <li><p>Eval</p> <p>Most values (so-called atoms) evaluate to themselves, symbols are looked up in the current environment, and to evaluate a list (a function call), evaluate its elements, then apply the first element (hopefully it's a function!) to the rest of the elements.</p> <p>The indirection comes from the late-binding of the symbol to its value. The environment can change, so the function call can have different meanings at different points in the program. This greatly facilitates incremental development.</p></li> <li><p>CLOS</p> <p>The Common Lisp Object System defines many indirection mechanisms for doing object-oriented programming. They include method combinations (before and after methods), class-based polymorphism, and method dispatch. The most interesting indirection mechanism is that a class can define its own indirection mechanism.</p></li> <li><p>Garbage collection</p> <p>Instead of writing routines for managing the memory of your program, the runtime will take care of recouping memory when it is no longer needed. A great productivity boost.</p></li> <li><p>Macros</p> <p>Lisp macro calls look like function calls, but they are expanded into code at compile time. This indirection mechanism essentially allows you to extend the language within the language.</p></li> </ul> <h3 id="smalltalk">Smalltalk</h3> <p>Smalltalk defined object-oriented programming as we know it today, based on a simple indirection mechanism: message passing. It also was the first language (that I know of) to make significant use of development tools. Like Lisp, I cannot list all of the indirection mechanisms in Smalltalk. They are too numerous.</p> <ul> <li><p>Method passing</p> <p>The main semantic of Smalltalk is message passing. A message consists of the name and the arguments. The name is looked up in the vtable of the receiving object. If it is found, the associated method is returned and called on the objects. Otherwise, the name is looked up in the vtable's parent, and its parent, to the end of the vtable list. This vtable lookup is both dynamic (it allows for changes to the vtable at runtime) and provides polymorphism (different kinds of objects can respond to the same message).</p></li> <li><p>Semantic refactoring</p> <p>Development tools before Smalltalk were usually confined to enhanced text editors. Smalltalk let you refactor code, meaning changing code not at the textual level but at the structural-semantic level. For instance, performing a &quot;rename&quot; operation on a method would not only change the name of the method in that class, but also change the code for all of the callers. This is another indirection mechanism which is now taken for granted in the Java and .NET worlds.</p></li> </ul> <h3 id="self">Self</h3> <p>Self is a prototype based object-oriented language.</p> <ul> <li><p>Slot access</p> <p>In Self, to access a slot from an object, the name of the slot is looked up in the object. If it is found, the value is returned. Otherwise, the <code>parent</code> slot is accessed, and the slot name is looked up in the parent recursively. This allows one to build objects that are mostly identical to an existing object except in a small way.</p></li> </ul> <h3 id="haskell">Haskell</h3> <ul> <li><p>Typeclass polymorphism</p> <p>Haskell, unlike Smalltalk, keeps the values (objects) separate from the vtables. It is the job of the compiler to reunite these two elements when necessary. This allows data types to be defined separately (even in different files) from the code defining the type's inclusion in typeclasses. The Haskell compiler, following well-defined semantics, will convert calls to a typeclass method into a call to a function with the vtable as an implicit argument. This enables a limited form of polymorphism, where the same name refers to different functions depending on the types.</p></li> <li><p>Pattern matching</p> <p>Pattern matching in Haskell means destructuring a value into component values while optionally binding names to values. It lets you write in one concise statement the equivalent of several conditionals and <code>let</code> statements.</p></li> </ul> <h3 id="clojure">Clojure</h3> <p>Clojure also deserves a mention for its championing of various mechanisms for controlling concurrent state.</p> <ul> <li><p>Concurrent state (refs, agents, atoms, etc.)</p> <p>The Clojure runtime provides many indirection mechanisms to deal with state. Refs, for instance, provide transactional semantics over different values. This allows one to write parallel programs without explicitly using locks.</p></li> </ul> <p>Indirection mechanisms are semantic abstractions afforded by the language. Like all abstractions, they are <a href="http://www.joelonsoftware.com/articles/LeakyAbstractions.html">prone to leakage</a>. How a language deals with the leaks might be just as important a choice as which mechanisms the language supports. For instance, what happens when you pass an object a message it doesn't understand? Some common options include: compiler error, thrown exception, silent failure, magic, or undefined behavior. These are damage control at best.</p> <p>A lot of the leakiness of abstractions has to do with how mechanical the indirection is, and how simple the rules of the mechanism are. A complex mechanism is hard to understand, while a non-deterministic mechanism will sometimes give unwanted behavior. And when things go wrong, it is hard to distinguish between complexity and non-determinism. We should therefore strive for simple, deterministic abstractions. And we should also strive to bake the failure into the model, and build systems to deal with abstraction failures upfront.</p> <p>I want to complete this list and keep it updated. Please <script type="text/javascript"> <!-- h='&#x67;&#x6d;&#x61;&#x69;&#108;&#46;&#x63;&#x6f;&#x6d;';a='&#64;';n='&#x65;&#114;&#x69;&#x63;&#x77;&#110;&#x6f;&#114;&#x6d;&#x61;&#110;&#100;';e=n+a+h; document.write('<a h'+'ref'+'="ma'+'ilto'+':'+e+'">'+'contact me'+'<\/'+'a'+'>'); // --> </script><noscript>&#x63;&#x6f;&#110;&#116;&#x61;&#x63;&#116;&#32;&#x6d;&#x65;&#32;&#40;&#x65;&#114;&#x69;&#x63;&#x77;&#110;&#x6f;&#114;&#x6d;&#x61;&#110;&#100;&#32;&#x61;&#116;&#32;&#x67;&#x6d;&#x61;&#x69;&#108;&#32;&#100;&#x6f;&#116;&#32;&#x63;&#x6f;&#x6d;&#x29;</noscript> if you have other ideas for indirection mechanisms and I'll add them here and credit them to you!</p> <p>To conclude: Different languages make different choices of which mechanisms to provide, and hence the endless variety of languages we see today. It is my hope that we will find more such abstractions which allow programmers to be even more productive in the future. Further, perhaps there are ways to make existing mechanisms more robust and which fail in more appropriate ways.</p> <p><center><a href="http://www.lispcast.com/indirection">Read full post</a></center></p> http://www.lispcast.com/programming-language-checklist http://colinm.org/language_checklist.html Fri 03 Feb 2012 09:24:57 AM ART <p>A funny and painfully true look at language development.</p> <p>I still think developing your own language is a great learning process.</p> <p>via <a href="http://news.ycombinator.org/user?id=akoumjian">akoumjian</a></p> <p><center><a href="http://www.lispcast.com/programming-language-checklist">Read full post</a></center></p> http://www.lispcast.com/modern-language-wishlist http://www.lispcast.com/modern-language-wishlist Thu 02 Feb 2012 01:34:07 PM ART <p>I was brainstorming the other day about features that I expect to be easy in modern programming languages (plus libraries).</p> <p>Some of them are very common, some less common, and some might not exist yet. Some are basic services of the runtime and some are more conveniences for interacting with the modern networked world.</p> <p>None of them are impossible. I can point to examples of each of them in popular programming languages. But there is no language that has all of them. A lot of progress could be made with fortuitous curation of existing libraries.</p> <ul> <li><p>String manipulation</p> <p>String manipulation should be incredibly convenient. It's so common to parse something out of a string, or build up a new string. It should be so easy it disappears.</p> <ul> <li>Regular expressions</li> <li>Splitting</li> <li>Joining</li> <li>Replacing</li> </ul></li> <li><p>Polymorphism</p> <p>Polymorphism, as I'm describing it here, means the specific type of a value is an implementation detail that I can ignore. I can program to an &quot;interface&quot; and two values that implement the same interface can be treated interchangeably.</p></li> <li><p>Basic &quot;container&quot; types</p> <p>I don't think it's a stretch to say that we know enough, as a science and industry, to know exactly what we need from our containers. +1 for convenient syntax.</p> <ul> <li>Linked list</li> <li>Dynamic array</li> <li>Hash map</li> <li>Set</li> </ul></li> <li><p>Input/output</p> <p>It's still a little hard in some languages to read and write files. Especially binary.</p></li> <li><p>Web requests</p> <p>Our computers are approaching 100% time on the Internet. And the web is ubiquitous. You should be able to do web requests with one line.</p></li> <li><p>URL Manipulation</p> <p>URL's are very structured strings, but that doesn't mean we should be concatenating the strings ourselves. There needs to be a way to build URL's and break them into their individual components.</p></li> <li><p>Garbage Collection</p> <p>I just don't want to worry about memory management anymore.</p></li> <li><p>Namespaces</p> <p>It is convenient to avoid naming conflicts as your library ecosystem grows.</p></li> <li><p>Homoiconic</p> <p>Code can be manipulated as data.</p></li> <li><p>Extensible syntax</p> <p>I find I don't use macros much anymore. I do more with data-driven programming. But it is nice to have when you need it.</p></li> <li><p>Math-oriented numeric types</p> <p>There are times when I want numbers that are defined by their machine representations, such as C <code>int</code> and <code>double</code>. I'll call this &quot;machine-oriented numbers&quot;. There are times when I want a more abstract representation of numbers, that act like they taught me in Math class. I'll call this &quot;math-oriented numbers&quot;.</p> <p>With math-oriented numbers, the fear of overflowing should not exist and division is division.</p> <p>While we're at it, we could add in matrices, vectors, and even equations.</p></li> <li><p>Units</p> <p>Numeric values should be able to be qualified with a unit. You should be able to convert between units of the same kind.</p> <ul> <li>Mass</li> <li>Time</li> <li>Distance</li> <li>Temperature</li> <li>and combinations of the above (speed, acceleration, etc.)</li> </ul></li> <li><p>Time</p> <p>Time, dates, and calendars are hard. The language should solve the hard part for us.</p></li> <li><p>Error</p> <p>A number is rarely 100% accurate. There should be ways to represent the error and have it accumulate when combining different values. +1 for tracing the sources of error.</p></li> <li><p>Unification / pattern matching</p> <p>It's just for convenience. The important thing is how unification errors are dealt with. Hopefully, there is something better than catching an exception.</p></li> <li><p>Before / after functions</p> <p>This is sometimes known as aspects. But there is a lot of value being able to add functionality to existing functions without modifying the original code.</p></li> <li><p>Parser</p> <p>Convenient way to define parser grammars that generate AST's available in the language.</p></li> <li><p>CSV library</p> <p>CSV is a very common way to store tabular data, but it's not really a standard. There is enough variability in the format that a library is called for.</p></li> <li><p>Good error messages</p> <p>Good error messages need to help you locate and solve the problem. It's actually really hard to get right. You can see this a lot in newer languages. Languages with helpful errors are typically mature.</p></li> <li><p>Immutable values</p> <p>Values are values. They shouldn't change.</p></li> <li><p>Explicit model of time</p> <p>It is very rare to find in programming languages. Time needs to be modeled by the programming language so that we can sanely deal with concurrency. This is one of the bigger mini-revolutions happening in programming at the moment.</p></li> <li><p>Graphics</p> <p>Most languages make it really hard to draw on the screen. This just needs to be easier. Displaying images, shapes, colors, text, video, and associated manipulations: scaling, rotation, translation.</p></li> <li><p>Sound</p> <p>Same goes for sound: playing sounds should be easy! Listening to the microphone should be easy!</p></li> <li><p>Common file formats</p> <p>Reading common formats should be easy. At the very least, there should be a framework/convention for libraries for common formats to follow.</p></li> <li><p>Game input</p> <p>By this, I mean getting raw events about key down, key up, mouse movement, etc.</p></li> <li><p>GUI</p></li> <li><p>First-class functions</p> <p>Higher-order programming is an obvious win. +1 for lexical closures. +1 if you can store the functions to disk and read them back in!</p></li> <li><p>Easy way to store data in flat text files</p> <p>I don't want to have to write my own serialization routines.</p></li> </ul> <p><center><a href="http://www.lispcast.com/modern-language-wishlist">Read full post</a></center></p> http://www.lispcast.com/escape-from-the-ivory-tower http://yow.eventer.com/events/1004/talks/1054 Sat 28 Jan 2012 06:47:44 PM ART <p>This brief history of Haskell is a nice introduction to how Haskell has developed. Jones tells a nice story punctuated by seminal publications that contributed to the ideas. He is a living example of how well the Cambridge accent was designed for giving lectures.</p> <blockquote> <p>Some programs work but are not well-typed. That is, they are the programs that you want to write but the compiler rejects them. So this is the &quot;Region of Abysmal Pain&quot;. Because that's where you think: &quot;Ugh! The type system is getting in my way! I know! I'll use an untyped language.&quot;</p> </blockquote> <p>It is very refreshing to hear someone straight from the top of the static typing pantheon acknowledge the pain of working with current, statically-typed languages.</p> <blockquote> <p>Now, of course there's always going to be a small Region of Abysmal Pain. There's rather a sort of sterile debate that happens between the static and the dynamic crowd. But I just want to remark that there's something not just self-indulgent but I think is actually quite important about the process of trying to find ways of making types more expressive so that they maintain the good property of being somewhat comprehensible and while moving closer to writing programs that you really want to write.</p> </blockquote> <blockquote> <p>Alright, so here's our plan for world domination: make the type system sufficiently expressive to the point where everybody will forget dynamic languages and write statically typed ones. I don't expect that will happen to me in my lifetime. But I regard Haskell as a kind of thought experiment that's trying to go in that direction.</p> </blockquote> <p>In the end, I think Simon Peyton Jones is the perfect mix of humility and hubris to lead the Haskell movement. He seems to have the patience to work with (and be excited about) an incomplete language (as Haskell was in the early days and still is in a lot of ways) without being dogmatic about the virtue of the current limitations.</p> <p><center><a href="http://www.lispcast.com/escape-from-the-ivory-tower">Read full post</a></center></p> http://www.lispcast.com/beautiful-web-type http://hellohappy.org/beautiful-web-type/ Sat 28 Jan 2012 05:38:57 PM ART <p>Thanks for this curation of <a href="http://www.google.com/webfonts">Google Web Fonts</a>. Despite Google Web Fonts' excellent UI, I still have trouble finding the gems.</p> <p><center><a href="http://www.lispcast.com/beautiful-web-type">Read full post</a></center></p> http://www.lispcast.com/parser-combinators-how-to-parse-nearly-everything http://www.infoq.com/presentations/Parser-Combinators Thu 26 Jan 2012 12:08:09 PM ART <p>This is the best video I've ever seen defining monadic parser combinators from the ground up. Nate Young explains <a href="https://github.com/youngnh/parsatron">his translation</a> of <a href="http://www.haskell.org/haskellwiki/Parsec">Parsec</a> into Clojure^{<a href="#fn1" class="footnoteRef" id="fnref1">1</a>}. I'm surprised he could show the code and explain it well in less than forty-five minutes.</p> <p>As you may know, I have my own PEG parser combinator library called <a href="https://github.com/ericnormand/squarepeg">squarepeg</a>. I began developing it as monadic, but decided that I didn't like having to write my own version of Haskell's <code>do</code> notation (<code>let-&gt;&gt;</code> in his version), which felt awkward in Clojure. Instead, squarepeg lets you bind variables and refer to them later within each parser itself (instead of in the code that builds the parser). There were a few other differences, but in general, I think the two libraries are more similar than different.</p> <p>One thing I think I will borrow from his library is counting the character position of the current parser to help report parsing errors. It's going on my TODO list.</p> <p>I have more plans for squarepeg when I get a chance. They include limiting the laziness of the parser and being able to report better error messages.</p> <p><strong>Update</strong> The kindly <a href="https://twitter.com/spariev">Sergey Pariev</a> clued me into the github repo of <a href="https://github.com/youngnh/parsatron">The Parsatron</a>.</p> <div class="footnotes"> <hr /> <ol> <li id="fn1"><p>Nate said his parser was available on Clojars under the name &quot;The Parsitron&quot;, but I could not find it.<a href="#fnref1">↩</a></p></li> </ol> </div> <p><center><a href="http://www.lispcast.com/parser-combinators-how-to-parse-nearly-everything">Read full post</a></center></p> http://www.lispcast.com/clojurescript-one http://clojurescriptone.com/ Fri 20 Jan 2012 06:40:11 PM ART <p>Simply amazing.</p> <p>I tried to build a small project using ClojureScript and gave up, reverting back to Javascript. The workflow was awkward and information about the language was lacking. ClojureScript One aims to exemplify the power latent in ClojureScript by giving us a productive workflow from the very start. You clone the repo and use it as a starting point for your own project.</p> <p>I haven't explored this new project, but it is already impressive. It sets a high bar for new projects. It includes a well-designed home page, getting started videos, and nice documentation. But, more importantly, it hints at a new age in web development in much the same way as the <a href="http://www.youtube.com/watch?v=Gzj723LkRJY"><em>Blog in 15 Minutes</em></a> Ruby on Rails video ushered in the rise of Ruby on the web. Watch the ClojureScript One Getting Started video to have your mind blown.</p> <p>I also recommend a <a href="http://thinkrelevance.com/blog/2012/01/12/podcast-episode-003.html">podcast</a> about the goals of ClojureScript One.</p> <p><center><a href="http://www.lispcast.com/clojurescript-one">Read full post</a></center></p> http://www.lispcast.com/apple-equals-oranges http://www.lispcast.com/apple-equals-oranges Fri 30 Dec 2011 06:44:36 PM ART <p>If you are reading this, you are probably a programmer. Let me ask you, for just a moment, to step out of your programmer shoes and answer these questions:</p> <ul> <li>Is this apple equal to that orange?</li> <li>Is that cloud equal to this house?</li> <li>Is my backpack equal to my television?</li> </ul> <p>The obvious answer is &quot;no&quot; to all of these. And so (please step back into your programmer shoes) we see in many languages I can ask a similar question:</p> <p>In Java:</p> <pre><code>apple.equals(orange)</code></pre> <p>Or in Clojure:</p> <pre><code>(= apple orange)</code></pre> <p>The answer to both questions is unsurprisingly <code>false</code>.</p> <p>And in Haskell?</p> <pre><code>apple == orange</code></pre> <p>Type error! The compiler is saying I cannot even ask the question.</p> <p>What model of reality is Haskell asserting?</p> <p>Is it telling me that I need to convert the apple and orange into values of the same type?</p> <pre><code>Fruit {name = &quot;apple&quot;} == Fruit {name = &quot;orange&quot;}</code></pre> <p>Is this question really different from <code>apple == orange</code>?</p> <p>Which model (Haskell's or Clojure's) more closely models reality?</p> <p>Is this behavior intentionally designed into Haskell or is it incidental behavior due to the choice of type system?</p> <p>Does this behavior make Haskell better or worse than a hypothetical Haskell that allowed the question to be asked?</p> <p>Deep questions.</p> <p><center><a href="http://www.lispcast.com/apple-equals-oranges">Read full post</a></center></p> http://www.lispcast.com/the-future-of-programming-pchiusano http://pchiusano.blogspot.com/2011/12/future-of-programming.html Fri 30 Dec 2011 05:24:54 PM ART <p>Paul Chiusano:</p> <blockquote> <p>In the functional programming world, there is insane amounts of code reuse happening, but along with this comes a fair bit of plumbing.</p> </blockquote> <p>The <em>plumbing</em> Chiusano is referring to is incidental complexity imposed by current static type systems without a good set of &quot;universal&quot; types. Dynamically typed languages often do not have the same plumbing problem because of the extra information available at runtime to do dynamic dispatching and the use of overloading. This incidental complexity is a huge hurdle to languages like Haskell, where half of the code is about converting from one type to another.</p> <p>This could be the fault of the codebase/libraries I am working with. In my practical Haskell experience, I have failed to find the zen of type/domain fit that static-typing enthusiasts talk about. Chiusano, however, hints that this problem is universal.</p> <blockquote> <p>It makes it clear that types are effective not just at preventing many software errors, but also in <em>guiding development</em>.</p> </blockquote> <p>I would love to see the adoption of standard type classes recognized by the Haskell compiler that could automatically handle the most common coercions safely. For instance, the compiler could &quot;upgrade&quot; function application to Functor application when the types match. It is beyond me whether this can be done &quot;safely&quot;. I suspect that it cannot.</p> <blockquote> <p>The second is to have more normalized types and type systems so that there is no incidental structure for code to broker between in the first place. To support this we'll see things like row types, unordered tuples, type sets, and so on, and any related type system machinery needed to make all this feasible and convenient.</p> </blockquote> <p>If modules were programmed to a small, standard set of types (and type classes), they would be more universally applicable. The compiler could &quot;overload&quot; functions automatically. The trick is to keep it safe. At the very least, the &quot;universal&quot; types would help programmers do it manually. We may already be seeing such a convergence.</p> <p>Not coincidentally, the built in Clojure data structures are usually all I need. Others appear to think the same. The Clojure ecosystem thrives from the consensus on a small, universal set. There is a lot of reuse and little boilerplate.</p> <p>See <a href="https://github.com/mmcgrana/ring">Ring</a> as an example of a universal datatype facilitating a flourishing community. It allows the problem domain (web programming) to be broken up into subproblems with little-to-no coordination between the groups. Clojure has a number of web frameworks and libraries that are all inter-compatible. I think this is unique among languages.</p> <blockquote> <p>The editor will search for a program to make the types align, show me the program for confirmation if I request it, and then not show this subexpression in the main editor view . . .</p> </blockquote> <p>Please give me this editor. It is technically feasible. <a href="http://www.haskell.org/hoogle/">Hoogle</a> can already do a pretty decent search based on the types of functions. All you need is a planner to find a path from one type to another.</p> <p>You could even help the search by defining a type class <code>Convertible</code> like this:</p> <pre><code>class Convertible a b where convert :: a -&gt; b</code></pre> <p>All of the instances of <code>Convertible</code> would form graphs which could be searched for all paths between any two types. The editor could show a list of those paths and let you choose one.</p> <p><center><a href="http://www.lispcast.com/the-future-of-programming-pchiusano">Read full post</a></center></p> http://www.lispcast.com/programming-and-scaling http://tele-task.de/archive/video/flash/14029/ Fri 30 Dec 2011 03:27:29 PM ART <p>A great Alan Kay-esque speech (by none other than Alan Kay himself).</p> <p>Alan Kay is a great thinker and I always enjoy his talks, but he needs someone to refine his presentations--particularly his verbal explanations. There are lots of great ideas and perspectives, but mostly he is just saying that &quot;we're doing it wrong&quot;. Much better would be to show us his analysis of a problem.</p> <p>In general, I finish his presentations feeling like everyone is doing everything wrong but with no concrete steps to take to correct it. We are thinking wrong (we need better perspectives), we are programming wrong, we are engineering wrong, we are learning the wrong things, we are doing computer science wrong, etc.</p> <p>I also finish thinking that a new and better way is possible, but again, with no idea of that better way except a vague notion of less and better code in less time.</p> <p>And then here I am, trapped in a world of crappy computers and crappy thinking, with a feeling of unease. I wish he would come down to Earth a little and apply that big brain with its great perspectives to a problem on-camera. It would be concrete and I could learn to emulate his thinking.</p> <p><center><a href="http://www.lispcast.com/programming-and-scaling">Read full post</a></center></p> http://www.lispcast.com/the-coming-war-on-general-purpose-computation http://boingboing.net/2011/12/27/the-coming-war-on-general-purp.html Wed 28 Dec 2011 07:12:50 PM ART <p>An insightful talk from Internet activist Cory Doctorow about the future of the freedom of computation.</p> <p><center><a href="http://www.lispcast.com/the-coming-war-on-general-purpose-computation">Read full post</a></center></p> http://www.lispcast.com/the-mapping-dilemma http://www.infoq.com/presentations/The-Mapping-Dilemma Sat 17 Dec 2011 11:59:54 AM ART <p>David Nolen speaking at Strange Loop:</p> <blockquote> <p>How much of Computer Science is sitting around when I'm sitting and working on a problem?</p> </blockquote> <p>David draws on some of the giants of Computer Science in recent years. Alan Kay, Gregor Kiczales, Peter Norvig, and more. I love to see the products of great minds folded into Clojure and ready at my fingertips.</p> <p><a href="https://github.com/clojure/core.match">core.match</a> and <a href="https://github.com/clojure/core.logic">core.logic</a> are now on my reading list.</p> <p><center><a href="http://www.lispcast.com/the-mapping-dilemma">Read full post</a></center></p> http://www.lispcast.com/multimethod-js http://krisjordan.com/multimethod-js Fri 16 Dec 2011 07:56:50 PM ART <p>Kris Jordan:</p> <blockquote> <p>Inspired by Clojure's multimethods, multimethod.js provides a functional alternative to classical, prototype based polymorphism.</p> </blockquote> <p><a href="https://github.com/KrisJordan/multimethod-js">multimethod.js</a> builds functions which dispatch on arbitrary predicates in Javascript using a <a href="http://martinfowler.com/bliki/FluentInterface.html">fluent style</a>.</p> <blockquote> <p>Multimethod iterates through each 'method' registered with <code>when</code> and performs an equality test on the <code>dispatchValue</code> and each method's match value.</p> </blockquote> <p>I wonder whether a linear search for the dispatch value will scale. I prefer to see some kind of hash-map based solution. Is it possible to serialize the object to JSON and use the resulting String as a key?</p> <p>Still, I enjoy seeing inter-language cross-pollination. It is also a nice translation from a functional language to a prototype language. The fluent interface does the job extremely well.</p> <p>Kris Jordan deserves a follow on <a href="https://github.com/KrisJordan">GitHub</a>.</p> <p><center><a href="http://www.lispcast.com/multimethod-js">Read full post</a></center></p> http://www.lispcast.com/ring-1.0-release http://groups.google.com/group/ring-clojure/browse_thread/thread/f18338ffda7e38f5 Tue 13 Dec 2011 09:37:46 AM ART <p>Congratulations to the Ring developers on finishing the 1.0.0 Release.</p> <p>James Reeves:</p> <blockquote> <p>Ring 1.0.0 has now been released, almost three years since Mark pushed the first commit. In that time, Ring has become the de facto standard for building web applications in Clojure.</p> </blockquote> <p>Ring deserves its place as the &quot;de facto standard&quot;. It is the perfect example of what makes Clojure great. It encourages composition and simplicity and creates an abstraction that allows an entire ecosystem to flourish.</p> <p>Read the <a href="https://github.com/mmcgrana/ring/blob/master/SPEC">Ring Spec</a> and the <a href="https://github.com/mmcgrana/ring">Ring source</a>. They both short and well-written.</p> <p><center><a href="http://www.lispcast.com/ring-1.0-release">Read full post</a></center></p> http://www.lispcast.com/clojure-for-dummies-a-kata http://java.dzone.com/articles/clojure-dummies-kata-0 Sat 10 Dec 2011 05:24:48 PM ART <p>It's good to see someone trying Clojure and sharing his experiences. Congratulations are due for getting it up and running and finishing a kata.</p> <p>Giorgio Sironi:</p> <blockquote> <p>Clojure is a LISP dialect; if you have ever been forced to use LISP in a computer science class, I understand your resistance towards this class of totally functional languages.</p> </blockquote> <p>I appreciate his honesty here. Universities have traditionally used Lisp to teach functional programming. They often neglect to mention that mosts Lisps are <em>not</em> purely functional. In fact, they lie to the students in the name of pedagogy. People leave Programming Languages class with many false notions about Lisp.</p> <blockquote> <p>In fact, LISP for many of us means lots of Reverse Polish Notation where (+ 1 2) evaluates to three; absence of for cycles <em>[loops]</em> and other commodities to privilege tail recursion; and absolute lack of state in the form of variables (the state isn't really absent: I've seen it on the stack.)</p> </blockquote> <p>In <a href="http://en.wikipedia.org/wiki/Reverse_Polish_notation">Reverse Polish notation</a>, the same expression would be <code>(2 1 +)</code>. Lisp uses <a href="http://en.wikipedia.org/wiki/Polish_notation">Polish notation</a>, otherwise known as Prefix notation.</p> <p>Common Lisp, in fact, has <em>more loops than Java</em>. Java has <code>for</code>, <code>while</code>, and the sadder <code>do..while</code> loops. Common Lisp's <code>loop</code> macro alone trumps any other language I know for <em>imperative</em> and <em>stateful</em> iteration. In addition to <code>loop</code>, Common Lisp defines <a href="http://clhs.lisp.se/Body/m_dotime.htm"><code>dotimes</code></a>, <a href="http://clhs.lisp.se/Body/m_dolist.htm"><code>dolist</code></a>, <a href="http://clhs.lisp.se/Body/m_do_do.htm"><code>do</code></a>, <a href="http://clhs.lisp.se/Body/m_do_do.htm"><code>do*</code></a> (a variation on <code>do</code>), and the loops for symbols in a package <a href="http://clhs.lisp.se/Body/m_do_sym.htm"><code>do-symbols</code></a>, <a href="http://clhs.lisp.se/Body/m_do_sym.htm"><code>do-external-symbols</code></a>, and <a href="http://clhs.lisp.se/Body/m_do_sym.htm"><code>do-all-symbols</code></a>.</p> <p>The fact that a non-lisper believes something about Lisp so false yet so common hints that something is very wrong. The misconception &quot;absolute lack of state in the form of variables&quot; will be familiar to many Lisp programmers who talk to non-lispers.</p> <blockquote> <p>Download and unzip the last release of Clojure. Start up a class by specifying clojure-1.3.0.jar in the classpath :</p> </blockquote> <pre><code> java -cp clojure-1.3.0.jar clojure.main</code></pre> <p>It's nice that Clojure is so easy to run.</p> <p>Again, thumbs up to Giorgio for finishing a kata in a new language. Keep up with the Clojure!</p> <p><center><a href="http://www.lispcast.com/clojure-for-dummies-a-kata">Read full post</a></center></p> http://www.lispcast.com/growth-ballad http://cognitivecomputing.wordpress.com/1986/01/28/a-short-ballad-dedicated-to-the-growth-of-programs/ Sat 10 Dec 2011 12:43:00 PM ART <p>This is a cautionary tale set in a dystopian Lisp where <code>nil</code> is not false and false is not <code>nil</code>.</p> <blockquote> <p>So I went back to the master and appealed once again<br /> I said, pardon me, but now I’m really insane<br /> He said, no you’re not really going out of your head<br /> Instead of just <code>VAL</code>, you must use <code>NOT NULL</code> instead</p> </blockquote> <p><code>nil</code> means (traditionally) false, the empty list, and also &quot;no value&quot;. In my opinion, Lisp has hit a sweet spot. Somehow, <code>nil</code> overloading makes for succinct programs.</p> <p>It's possible to go overboard and do this wrong. Case in point: <a href="http://www.mapbender.org/JavaScript_pitfalls:_null,_false,_undefined,_NaN">the problems with boolean values and comparison in Javascript</a>.</p> <p><center><a href="http://www.lispcast.com/growth-ballad">Read full post</a></center></p> http://www.lispcast.com/the-heart-of-unix http://www.lispcast.com/the-heart-of-unix Sat 10 Dec 2011 10:56:42 AM ART <p>Despite all of its warts, I like working in Linux. I've used it for 15 years and I've never been as productive in another environment. Most people claim that it's the configurability of Linux that keep the users coming. That may have attracted me at first, but <strong>what attracts me now is its programmability.</strong></p> <p>Let me be very clear. I'm not saying that Linux is great because I can patch the source code to grep and recompile it. In all my years of Unix, I've never done anything like that. And I'm not saying that Linux is a great workstation for programmers because it helps you program better. Those are topics for another essay.</p> <h3 id="unix-is-a-programmable-environment">Unix is a programmable environment</h3> <p>I <em>am</em> saying that Unix is a programmable environment. When you interact with the shell, <strong>you are writing programs to be interpreted</strong>. You can easily extend the Unix system by writing a shell script, copying it to a directory in your <code>PATH</code>, and making it executable. Boom. You've got a new program.</p> <p>What's more, that program, if it follows certain simple conventions, is now able to work with other programs. Those conventions are simple, and they are summed up well by Doug McIlroy, the inventor of Unix pipes:</p> <blockquote> <p>This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.</p> </blockquote> <p>If your program <em>reads text lines from standard in and writes text lines on standard out</em>, it is likely to do well on Unix.</p> <h3 id="programs-on-your-path-are-like-pure-functions-in-the-higher-level-language-called-the-shell">Programs on your path are like pure functions in the higher-level language called the shell</h3> <p>Not all programs are so pure. But the vast majority of the programs that are so typically Unixy are. <code>grep</code>, <code>awk</code>, <code>sed</code>, <code>wc</code>, <code>pr</code>, etc.</p> <h3 id="unix-is-a-multi-lingual-environment">Unix is a multi-lingual environment</h3> <p>I must have compilers or interpreters for 30 languages on my machine. Maybe more. All of these languages are invited to the party. They can all call each other (through the shell). And of course their <code>stdin</code>/<code>stdouts</code> can be piped together.</p> <p>You really can use the best tool for the job. I've got Bash scripts, awk scripts, Python scripts, some Perl scripts. What I program in at the moment depends on my mood and practical considerations. It is a little crazy that <strong>I don't have to think about what language something is written in when I'm at the terminal</strong>.</p> <h3 id="unix-provides-a-universal-interface-with-a-universal-data-structure">Unix provides a universal interface with a universal data structure</h3> <p>It needs to be stated that there is a reason all of these languages can work together. There is a standard data structure that programs are invited to use: text streams. That means sequences of characters. Text streams are cool because they're simple and flexible. <strong>You can impose a structure on top of the flat sequence.</strong> For instance, you can break it into a sequence of sequences of characters by splitting it on a certain character (like new-line). Then you can split those sequences into columns. In short, text is flexible.</p> <h3 id="unix-is-homoiconic">Unix is homoiconic</h3> <p>There's another property that I think is rarely talked about in the context of Unix. In Lisp, we often are proud that code is data. You can manipulate code with the same functions that you manipulate other data structures. This meta-circularity gives you a lot of power.</p> <p>But this is the same in Unix. <strong>Your programs are text files</strong> and so can be <code>grep</code>'d and <code>wc</code>'d and anything else if you want to. You can open up a pipe to Perl and feed it commands, if you like. And this feeds right back into Unix being programmable.</p> <h3 id="functional-universal-data-structure-homoiconic-power">Functional + universal data structure + homoiconic = power</h3> <p>All of this adds up to synergy. When you write a program that follows the Unix conventions of <code>stdin</code>/<code>stdout</code> with text streams, <strong>it can work with thousands of programs that are already on your computer</strong>. What's more, your program has to do less work itself, because so much of the hard work can be done better by other programs.</p> <h3 id="on-the-file-system-hierarchical-names-point-to-data-objects">On the file system, hierarchical names point to data objects</h3> <p>And this synergy extends well beyond just using text streams. I have this tendency to look to databases as storage solutions for my personal projects. They have some nice properties, like ACID and SQL.But by using a database, I'm missing out on joining the Unix ecosystem. <strong>If I use the file system to store my data--meaning text files in directories--I can use all of Unix to help me out.</strong> I can use <code>find</code>, <code>grep</code>, <code>head</code>, <code>tail</code>, etc., just because I chose to use the measly file system instead of some fancy database.</p> <h3 id="blog-example">Blog example</h3> <p>A good example of the synergy I'm talking about is the blog you are reading now. Here's how my blog works:</p> <p>I store everything on the file system. I have an <code>src/</code> directory with <code>drafts/</code> <code>posts/</code> <code>pages/</code> and <code>links/</code>. I wrote a Python script (currently at 183 well-commented lines) that reads <code>src/</code> and spits out the final product to <code>build/</code>. The Python uses a few libraries, but the meat of it is done by calling other programs. The rendering of Markdown to HTML is done by <a href="http://johnmacfarlane.net/pandoc/"><code>pandoc</code></a>, which happens to be written in Haskell. I also do a call out to the shell to copy a directory (<code>cp -rp</code>) because I was too lazy to figure out how to do it in pure Python.</p> <p>I sync <code>build/</code> to Amazon S3 with a Ruby program called <code>s3sync</code>. I edit my entries in Emacs. If I need to delete a post, I run <code>rm</code>. If I need to list my posts, I run <code>ls</code>. If I'd like to change the name of a post, I use <code>mv</code>.</p> <p>It may not be the best interface for writing a blog. But notice all of the stuff I didn't have to write to get started. I'm already writing posts and publishing them. <strong>Compare that to the reams of PHP and Javascript it takes to get the same functionality in Wordpress.</strong> That's the power of small tools working together.</p> <h3 id="unix-is-old">Unix is old</h3> <p>Now that I've expressed how great Unix is, allow me to speak about its numerous shortcomings. I can't say for sure, but I would guess that most of the shortcomings are due to the long history of <strong>Unix starting on underpowered machines</strong>.</p> <p>For instance, the fact that your programs have to be manually stored to disk using file system operations so that your dynamic shell language can have access to them seems awfully quaint. But when Unix was developed, disk space, RAM, and computation were expensive. Everything was expensive. So the strategy was to <strong>cache your compiler output to disk</strong> so you wouldn't have to do a costly compile step each time you ran a program.</p> <p>If I want to write a new program, even a short one, I have to open up a text file in Emacs (make sure it's in the path!), write the program, save it, switch to the terminal, and <code>chmod +x</code> it. Compare that to Clojure, where you constantly define and redefine functions at the REPL. Or, if you like, a Smalltalk system where you can open up the editing menu of <em>anything you can see</em> and change the code which will then be paged out to disk at a convenient time. Unix clearly has room to grow in that respect.</p> <h3 id="the-file-system">The file system</h3> <p>The file system is archaic, too. It's reliable, but a little feature-poor. It's one of the reasons I think first about a database before remembering the synergy available with the file system. It doesn't provide any kind of ACID properties. The metadata available is laughable (permissions, owner/group, date, and filesize?). <strong>A more modern file system would give a little more oomph</strong> to compete with other forms of storage.</p> <h3 id="the-terminal">The terminal</h3> <p><strong>The terminal is just old.</strong> It's all text. The editing is sub-primitive. The help it gives you is the bare minimum. One of its biggest shortcomings is how opaque it is. It doesn't do much to help you learn commands. It's not very good with huge dumps on <code>stdout</code>. Multiline commands? Supported with <code>\</code>. I think we can do better.</p> <h3 id="text-streams">Text streams</h3> <p>The world of computers has grown up a lot since the early days of Unix. There has been a Cambrian explosion in the number of file formats. Lots of them are binary formats. Lots are structured text, like XML or JSON. Unix can handle those kinds of files, but <strong>it has failed to find a lever to help the Unix user master them with the same synergy you see with flat text files</strong>.</p> <h3 id="wrong-turns">Wrong turns</h3> <p>Unix has a long history. Some of that history was kind, some was unkind. Most of the development of Unix was just practical people doing their best with the tools they had.</p> <p>What's unfortunate is that we now have better tools and we see what could be done, but to do it would break backwards compatibility. And so we continue with sub-optimal tools.</p> <h3 id="layering-instead-of-evolving">Layering instead of evolving</h3> <p>One thing I think is unfortunate in the world of Unix today is layering. <strong>Modern Linux distributions are midden piles of configuration daemons to manage permissions daemons to give your configuration GUI access to the configuration daemons.</strong> Or we find ourselves installing a database to manage a few kilobytes of metadata.</p> <p>The problem is Unix has not evolved in those areas. The permission system has changed very little. Modern distributions want to provide a modern and unintrusive interface to protected resources, so they add a layer of indirection onto the primitive permissions model instead of evolving the permission system itself. The Unix permissions system is solid and has worked for years. Maybe it should stay. But instead of giving us small programs that do one thing well to let us become masters of the permissions system, <strong>we get obtuse, opaque daemons</strong> that also need to be learned.</p> <p>The file system, though much improved in terms of capacity, stability, and reliability, still has the same basic features: hierarchical directories containing files, accessed by name. If you want something more, you have to add a layer like BerkeleyDB or SQLite. These tools are great, but I'd like to see a more Unixy solution that allows for the synergy you get from existing programs made to run with files on the disk.</p> <h3 id="megacommands">Megacommands</h3> <p><a href="https://gist.github.com/1091803">Command bloat</a> <a href="https://gist.github.com/665971">is terrible</a>. Rob Pike and Brian Kernighan have <a href="http://harmful.cat-v.org/cat-v/">written about this</a>. I'll merely refer you to their <a href="/files/papers/unix_prog_design.pdf">excellent paper</a>. The gist is that having n commands gives you O(n²) ways of combining them. <strong>Having fewer, bigger, &quot;more powerful&quot; programs does not give you this exponential and synergistic advantage.</strong></p> <p>If you look at it the right way, all of these little programs that do one thing are like functions in the higher-level language that is Unix. We see that languages like Perl and Python have huge numbers of libraries for doing all sorts of tasks. Those libraries are only accessible through the programming language they were developed for. This is a missed opportunity for the languages to interoperate synergistically with the rest of the Unix ecosystem.</p> <h3 id="the-road-ahead">The road ahead</h3> <p>I've given a bit of a taste of some of the non-Unixy directions we're going in. Now I'd like to end with some right directions.</p> <p>I mentioned before that saving a compiled binary to disk is done to cache what used to be an expensive operation. With modern hardware, a short utility C program could be read in, parsed, compiled, and run very quickly. Probably with no noticeable delay. It's something to consider when thinking about the division between static programs and dynamic scripting languages and the role of the compiler.</p> <h3 id="talking-to-unix">Talking to Unix</h3> <p>Foreign Function Interfaces between programming languages are considered very difficult to work with because of the semantics mismatch between any two languages. But Unix provides a universal interface for programs to <strong>interoperate without the need for FFI</strong>. I hope to see more &quot;sugar&quot; in languages to take advantage of calling out to other programs for help. <a href="http://stackoverflow.com/questions/799968/whats-the-difference-between-perls-backticks-system-and-exec">Perl's backticks</a> comes to mind.</p> <p>You might say that this is expensive. Well, yes and no. Yes, there is much more overhead in reading in who-knows-how-many files to execute some script on disk than in just calling some library function. I argue, though, that <strong>the time difference is becoming small enough not to matter</strong>; and the operating system should evolve to make it more practical.</p> <h3 id="evolving-stdinstdout">Evolving <code>stdin</code>/<code>stdout</code></h3> <p>Stdin/stdout with text streams is the closest thing we have to a universal, language-agnostic interface. It defines a minimal &quot;constitution&quot; with which programs can interact. <strong>Can this interface be improved on without destroying it?</strong> I wouldn't doubt it. There are lots of &quot;data flow&quot; patterns besides input and output. Pub/sub, broadcast, dispatch, etc., should be explored.</p> <h3 id="text-streams-evolved">Text streams, evolved</h3> <p>Unix was designed for flat text and the existing Unix tools operate on text. We need new tools to <strong>bring structured text and binary into the Unix world</strong> to join the party. I don't think this would be hard. I've written programs that read in JSON and write it out with one JSON object per line. That lets you grep it to find the one you want, or <code>wc -l</code> it to count the objects.</p> <p>Another thing I've been working on is defining a dispatch mechanism for common operations on files of different types. Take, for instance, metadata that is stored in a file. An HTML file has a title, sometimes it has an author (in a meta tag), etc. A JPEG file has metadata in the EXIF data. <strong>Is there some way we can unify the access of that metadata?</strong> I think there is and I'm working on it. The same command would dispatch differently based on mime-type.</p> <h3 id="st-century-terminal">21st Century Terminal</h3> <p>How can we improve the terminal? I think it's a hard problem but not impossible. Part of the issue with the terminal is that as X Windows developed, people started using menus to run monolithic programs instead of piping things with the shell. So the usefulness of the terminal will be improved, without changing the terminal itself, by <strong>breaking those monolithic programs up into composable programs</strong>. For instance, a program which displays all of the thumbnails of the files listed on <code>stdin</code> would be much more useful to me than a mouse-oriented file browser.</p> <p>The terminal is about text. I don't think that could or should change. But does it have to be only about text? <a href="http://acko.net/blog/on-termkit">Explorations</a> are underway.</p> <h3 id="the-shell">The Shell</h3> <p>The last improvement I want to touch on is the shell language itself. Bash is ugly. There. I said it. A lot of good work has been done in programming language design and I'd like to see some of it make its way to the shell. <strong>What if we take the idea of Unix programs as pure functions over streams of data a little further?</strong> What about higher-order functions? Or function transformations? Combinators? <strong>What if we borrow from object-oriented languages?</strong> Can we have message passing? What about type-based dispatching?</p> <h3 id="conclusions">Conclusions</h3> <p>Unix has always been practical and it has proven itself over the years. It's 40 years old and it's still being used. Furthermore, Unix is the closest thing to a personal computing experience^{<a href="#fn1" class="footnoteRef" id="fnref1">1</a>} that is practical today.</p> <p>People tend to <a href="/files/papers/LispGoodNewsBadNews.pdf">contrast Unix</a> with systems like the Lisp Machine and Smalltalk. But I see <strong>more similarities than differences</strong>: <em>Code as data.</em> <em>Everything is programmable.</em> <em>Dynamic language prompt.</em> <em>Universal data structure.</em> <em>A propensity for &quot;dialects&quot; or &quot;distributions&quot;.</em> <em>Garbage collection.</em>^{<a href="#fn2" class="footnoteRef" id="fnref2">2</a>} Unix just made a lot of compromises to make it practical on the limited hardware that was available.</p> <p>Unfortunately, those compromises have stuck. A lot of work went into workarounds and a lot of software has been built on top of those design decisions. The question is: <strong>where to go from here?</strong></p> <p>My own personal choice is to go <strong>back to the roots</strong>. Often, when we want to make a change, we must look to what has worked in the past. What has brought us this far? What were the things that made Unix special? Unix was built by individuals all adding their own practical knowledge and hard work into one cohesive system. Their individual work was multiplied by the synergy of a common interface. If we want to evolve Unix (and I do), that common interface--the heart of Unix--is the place to start.</p> <div class="footnotes"> <hr /> <ol> <li id="fn1"><p>When I say &quot;personal computer&quot;, I'm referring to <a href="http://www.mprove.de/diplom/gui/kay72.html">Alan Kay's vision</a>:</p> <blockquote> <p>What then is a personal computer? One would hope that it would be both a medium for containing and expressing arbitrary symbolic notions, and also a collection of useful tools for manipulating these structures, with ways to add new tools to the repertoire.</p> </blockquote> <a href="#fnref1">↩</a></li> <li id="fn2"><p>Unix has a limited form of garbage collection. Short-running programs (like those executed at the terminal) need not concern themselves with freeing allocated memory since the OS will free everything when they exit.<a href="#fnref2">↩</a></p></li> </ol> </div> <p><center><a href="http://www.lispcast.com/the-heart-of-unix">Read full post</a></center></p> http://www.lispcast.com/tips-for-marginalia http://www.lispcast.com/tips-for-marginalia Thu 08 Dec 2011 03:28:12 PM ART <p>I've used <a href="https://github.com/fogus/marginalia">Marginalia</a> a tiny bit for a few of the libraries I've developed that actually have comments and doc strings.</p> <p>Marginalia did help me refine my doc strings and comments. From the <a href="http://fogus.me/fun/marginalia/">Marginalia docs</a>:</p> <blockquote> <p>Following the guidelines will work to make your code not only easier to follow – it will make it better. The very process of using Marginalia will help to crystalize your understanding of problem and its solution(s).</p> </blockquote> <p>In general, this is true. Marginalia follows some strict rules, like a compiler. Even if your comments seem to make sense to you reading the source, Marginalia might produce something that makes no sense. However, it generates attractive and useful documentation. So I decided to use it.</p> <p>What this meant was figuring out some of the quirks of Marginalia. Here is what I've learned:</p> <h3 id="dont-use--comments-when-a-doc-string-is-more-appropriate">Don't use ;-comments when a doc string is more appropriate</h3> <p>This is good advice in general and Marginalia makes the comments look wrong. In Marginalia, comments seem to follow the docstring for the function they apply to when both are defined.</p> <h3 id="blank-lines-are-important">Blank lines are important</h3> <p>From what I can tell, a blank line will cause the top-level comment to be placed above the following form. No blank line will put them at the same level. That sounds very sensible.</p> <p>However, if you have a comment with no blank line immediately before a function, the docstring for that function will come first, followed by the comment. This is weird. You should follow the advice above and choose docstring or comments, but not both.</p> <h3 id="namespace-ordering">Namespace ordering</h3> <p>There is a convention in Clojure to use project.core as the main namespace of a library. Marginalia sorts the namespaces alphabetically. This means that in the documentation, project.anunimportantmodule comes before project.core.</p> <p>I have renamed my namespaces once to avoid this problem. But in general, my projects are very small and don't have many namespaces. It's not a practical problem.</p> <p>Marginalia is great. It produces beautiful documentation. And it has helped me clarify my code.</p> <p>Nice job.</p> <p><center><a href="http://www.lispcast.com/tips-for-marginalia">Read full post</a></center></p> http://www.lispcast.com/janki-method http://www.jackkinsella.ie/2011/12/05/janki-method.html Thu 08 Dec 2011 02:48:33 PM ART <p>Jack Kinsella describes an excellent method for learning <em>any</em> skill, disguised as a method for learning programming.</p> <p>He draws on his own personal experiences using <a href="http://ankisrs.net/">Anki</a> (a nice learning tool which I recommend, too; I've used it to learn foreign languages) to help him learn the huge number of commands, functions, and other arcana that we all either grep from memory or Google constantly as we work. He sums everything up in eight rules which define the Janki Method.</p> <p>Here's an example:</p> <blockquote> <p>The eighth rule of Janki encourages you to use your readings of other people’s code as a source of learning:</p> <p>&quot;Read code regularly. If you come across something interesting – be that an algorithm, a hack, or an architectural decision – create a card detailing the technique and showing the code.&quot;</p> </blockquote> <p>In the article, you'll find solid examples of flashcards chunked down to the right bite-size.</p> <p>The hardest part of the Method is to stick to it. He suggests rule 2:</p> <blockquote> <p>The second rule of Janki encourages a commitment to daily learning:</p> <p>&quot;You must use Anki every single day- including weekends and holidays – and commit to doing so indefinitely.&quot;</p> </blockquote> <p>I can't say this seems realistic, even with the five- to eight-minute daily commitment he claims. I have used Anki for long stretches. Two months was my longest. It is true that it doesn't take long each time. The trouble is the same trouble you have starting any new habit. It's just hard.</p> <p>I have had luck using Anki in an opposite way: one hour per day for a week. For some reason, it's easier for me to commit to than an indefinite commitment. You don't get the same benefits. The benefits are different.</p> <p>And, finally, the great thing about Anki is that it is very forgiving if you do stop using it regularly. If you take a two-week break, you can start up again with very little fuss.</p> <p>Some ideas:</p> <ul> <li>Use Anki to remember Emacs keystrokes/commands</li> <li>Use Anki to learn the Vars in clojure.core</li> </ul> <p>Jack manages to bring together the ideas of spaced repetition, learning by doing, and continuous self-improvement to give practical advice to make us better at what we do.</p> <p>Nice job.</p> <p><center><a href="http://www.lispcast.com/janki-method">Read full post</a></center></p> http://www.lispcast.com/waving-our-tentacles http://blog.raynes.me/blog/2011/12/02/waving-our-tentacles/ Thu 08 Dec 2011 02:27:22 PM ART <p>Anthony Grimes shows off his Clojure interface to the Github API.</p> <p>I'm definitely going to check this out. There are some people I'd like to stalk . . .</p> <p><center><a href="http://www.lispcast.com/waving-our-tentacles">Read full post</a></center></p> http://www.lispcast.com/clojure-west http://clojurewest.org/ Thu 08 Dec 2011 10:13:25 AM ART <blockquote> <p>Clojure/West is a new conference bringing the Clojure community together to discuss techniques, tools, and the state of the Clojure ecosystem March 16-17th for three tracks of sessions.</p> </blockquote> <p>I sure wish I could go hang out with other Clojurians. It's lonely here by myself. The conference looks like it will be fun and informative.</p> <p>Registration is open:</p> <ul> <li><a href="http://www.regonline.com/clojurewest2012">For the conference</a></li> <li><a href="http://www.regonline.com/clojurewest2012training">For the training</a></li> </ul> <p><center><a href="http://www.lispcast.com/clojure-west">Read full post</a></center></p> http://www.lispcast.com/seesaw-repl-tutorial https://gist.github.com/1441520 Thu 08 Dec 2011 09:07:53 AM ART <p>Dave Ray has written a commented source listing which guides you through building a simple GUI with Seesaw.</p> <blockquote> <pre><code>; How can we get to the radio buttons without using the rbs var? How about ; with a selector: (select f [:JRadioButton]) ;=&gt; (#&lt;JRadioButton ... &gt; #&lt;JRadioButton ... &gt;)</code></pre> </blockquote> <p>. . .</p> <blockquote> <pre><code>; and, of course, you can register a listener for group selection changes (listen group :selection (fn [e] (when-let [s (selection group)] (println &quot;Selection is &quot; (id-of s)))))</code></pre> </blockquote> <p>I have only done a bit of GUI programming with Java (mostly in college). But rather than giving me flashbacks to that nightmare, <a href="https://github.com/daveray/seesaw">Seesaw</a> makes me feel secure that I could face the Swing dragon again.</p> <p>From the Seesaw readme:</p> <blockquote> <p>It's an experiment to see what I can do to make user interface development funner in Clojure.</p> </blockquote> <p><center><a href="http://www.lispcast.com/seesaw-repl-tutorial">Read full post</a></center></p> http://www.lispcast.com/lisp-academy http://www.lispcast.com/lisp-academy Wed 07 Dec 2011 05:32:55 PM ART <p><a href="http://whalliburton.github.com/academy/">⚡ ⚕ Welcome to the academy. ⚛ ♬</a></p> <p>This appears to be a way to learn Common Lisp. It intrigues me because of the esoteric flavor of it.</p> <p>From the top of the page:</p> <blockquote> <p>Genesis</p> <p>In the beginning Man created the computer. Now the computer was formless and empty, darkness was over the surface of the deep, and the Spirit of Man was hovering over the terminal.</p> <p>And Man said, &quot;Let there be lisp,&quot; and there was lisp. Man saw that the lisp was good.</p> </blockquote> <p>It is followed by a rendering of the <a href="http://en.wikipedia.org/wiki/I_Ching">I Ching</a>, an inline rendering of the game of life, and references to movies and music.</p> <p><center><a href="http://www.lispcast.com/lisp-academy">Read full post</a></center></p> http://www.lispcast.com/from-humble-beginnings http://www.lispcast.com/from-humble-beginnings Tue 06 Dec 2011 10:37:05 AM ART <p>LispCast has been reborn from the ashes of its former existence.</p> <p>Please stay tuned.</p> <p><center><a href="http://www.lispcast.com/from-humble-beginnings">Read full post</a></center></p>