From the docs:
Convenient proxy factory bean superclass for proxy factory beans that create only singletons.
Manages pre- and post-interceptors (references, rather than interceptor names, as in ProxyFactoryBean) and provides consistent interface management.
Good thing this is "convenient".
Rich Hickey:
This is not a schemaless system. There's no such thing as a schemaless 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.
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.
That said, the Datomic schemas, along with the "datom" model, do look expressive.
James Coplien's criticism of Java (that it cannot do proper object-oriented programming) is my essential criticism of static languages in general: what if the model of programs that your language enforces does not allow you to program well?
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.
That concept was what we now refer to as "duck typing". To fulfill a "methodful role", you simply needed to have all of the required methods defined.
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.
In Clojure, "classes" are simply data, perhaps validated to conform to a schema, perhaps wrapped in a ref to get state. "Methodful roles" are groups of functions that can operate on data. If you're feeling frisky, you can use protocols. "Methodless roles" are variables in your program, each assigned to the data which will play that role.
Let's look at the main example in Clojure.
;; 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 (< (balance @source) amount)
(throw (ex-info "Insufficient funds." {: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)I wrote this just to make sure I was not kidding myself that "DCI" 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?
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 "Bridge" 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!
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.
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 altered1, since the compiler was always looking for consistent types. There were ways to work around it2, but they were always tedious and unsatisfactory.
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.
This is the classical definition of tight coupling. That's right: static typing introduces coupling.↩
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 Lisp written in Javascript with first-class environments and first-class continuations. The README claims it starts in 50ms on modern browsers. Looks interesting.
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.
Liberator looks like it might have found the leverage point between navigating the essential complexity of HTTP and managing the requirements of your server.
Two things look promising:
There seems to be a lot of potential for reuse. That means you can
decide server-wide policies instead of per-handler policies.
Behavior can change incrementally. You can still get up and running
using the defaults and adapt the server's behavior to suit the problem
later.
I look forward to trying it out.
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.
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.
Object-orientation is more than just syntactic sugar. OO uses message passing as its computational semantic, while procedural programming uses procedure calls.
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 "private in X". 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.
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++.
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.
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.
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).
Cool talk on programming languages from 2001 featuring Paul Graham, John Maeda, Jonathan Reeves, and Guy Steele.