Check out this video about Erlang. I found it while reading
Jao’s Programming Musings blog so I’ll just give the link to his post
Erlang looks interesting and I’m planning on getting my hands on the new Programming Erlang book.
The word transparent is often used in descriptions of programs and their API’s. Here’s one example from some Java documentation:
KeyFactory
The KeyFactory class is an engine class designed to provide conversions between opaque cryptographic keys (of type Key) and key specifications (transparent representations of the underlying key material).
Quite reasonable. Opaque and transparent are evocative and describe key features of the objects that are players in the API. But I often see transparent used when, IMO, opaque makes much more sense. Consider this page describing REST webservices.
The web service makes available a URL to a parts list resource. For example, a client would use this URL to get the parts list:
http://www.parts-depot.com/parts
Note that “how” the web service generates the parts list is completely transparent to the client. All the client knows is that if he/she submits the above URL then a document containing the list of parts is returned. Since the implementation is transparent to clients, Parts Depot is free to modify the underlying implementation of this resource without impacting clients. This is loose coupling.
The use of transparent means to me that the user would understand how the services generates the parts list. I think the word opaque fits much better. Am I missing something? When describing parts of a system that are decoupled from other parts, the details of the implementation should be opaque to other components, not transparent. Thank you.
Guido posted about the possibility of Python 3000 having generic functions. That would be a fantastic addition IMO.
He mentions in one of the comments that one way to think of generic functions in Python is as method overloading. Whereas method overloading in static languages like Java is not nearly as flexible as multimethods, perhaps it is the same thing in a dynamic language.
On the topic of multimethods and function overloading, I find Peter Seibel’s comparison a helpful example. BTW, it is a nice book.
A number of smart people I know are fans of GNU Arch (aka tla). There are also a number of projects that I follow that have adopted tla as their SCM solution (planner-mode, muse-mode, MoinMoin).
Now, I really think I have given it a chance. I’ve read through tutorials and even tried using it as my personal scm for awhile. But I find it incredibly opaque, unfriendly, and difficult to use. I think I’m allergic to it. Just about every time I have to interact with it I come to the edge of a cursing fit.
Even when I get it to do what I want, it irks me. Grab a copy of a project, make a few changes and ask for some diffs. First you have to figure out that you should say “tla changes –diffs”. Then you wait while it does some bizarre computation to calculate a diff.
I’ve been experimenting with git and I find it much friendlier and more responsive. Here is a comparison of time to produce a simple diff for a modest tree with two small changes:
$ time tla changes --diffs > ../editor_quickhelp.diff real 0m7.086s user 0m4.518s sys 0m1.359s
Yikes! Here’s the same operation on the same tree
$ time git diff > ../fixes.diff real 0m0.162s user 0m0.024s sys 0m0.083s
Now I probably should work harder to install baz which as I understand it has a much saner user interface. But last time I tried to build it on my OS X laptop, it errored out. I can’t build the most recent tla either. Maybe it senses my loathing I don’t know.
My current vote is going to git. I played with Mercurial (hg) for a bit and I really like that it is all Python based, but after giving git a whirl, it just doesn’t have the same usability and quickness.
