Code Quarterly

Speaking as someone who's been following the project for a few years and once actually bothered to learn Hoon, your first paragraph is probably the best criticism of Urbit I've seen. I do think there is an interesting system buried under all the obfuscation, but the uncritical groupthink within its user base is obnoxious. I kind of doubt "produce a vanguard of true believers" is a primary goal of the project, but Yarvin doesn't really seem to discourage that behavior either.

That said, the old "it's just typical Moldbug" trope isn't much better than the propaganda his followers spout, and the rest is pretty weak too. AFAIK, the Urbit term for "file" is "file". I don't know which funny weird name you're thinking of for "network endpoint", as that's not really a separate concept in the system. Hoon's cores (which I assume you're at least passingly familiar with) are pretty distinct from closures in any language I know... I mean, do you also complain that Java uses the word "object"? (Forgive me if I omit the part where I ascribe sinister motives to the creators of Java due to their choice of vocabulary.)

As for "implementations of well-known computer science concepts", cue Rich Hickey[1]:

> It's interesting, because Clojure provides almost nothing you can’t find somewhere else. But I do think it occupies an otherwise empty spot in the multidimensional space of language features and capabilities.

In other words, even if your claim is true, it describes almost every project…

Here is my brief review of the articles as a whole. As a little background, I've been writing Lisp professionally for a while at many companies, both start ups and top-tier tech companies.

I like writing about Lisp[1], and have been so far as to write blog posts ranging from why parentheses are a good thing to what kinds of data types Common Lisp has. I think there is still a place for writing about Lisp, but I don't think this e-zine accomplished the task to make it interesting.

Lisp unfortunately attracts a lot of fluff writing. Writing about how wonderful, deep, rich, or sophisticated it is. Writing about how it completely blows one's mind and takes you to this baroque, fluid land of programming literacy. I must admit that I've even been sucked into the vortex at a point in my Lisp career.

Then there are particular topics that get rehashed over and over again: what makes a Lisp? which is the best Lisp? which is the most practical? lisp-1 vs. lisp-2? was r6rs a failure? why are macros so great? why does Lisp subsume every programming language ever?

I found in this e-zine—whose title I can't repeat without bloating the paragraphs I write—that I didn't really gain anything after reading it all. What did I learn about T? I just learned that it was some language with interesting concepts, backed up with a paltry offering of examples. What did I learn about Apple? To me, it seemed like an opinion: Since Apple isn't doing wacky Lisp things, it no longer is catering to those…

It depends on the person. Does writing tests help you understand the problem, and if so, does that help you solve it faster? Only you can answer that. Here's a quote from Rich Hickey that really struck home with me:

> I never spoke out 'against' TDD. What I have said is, life is short and there are only a finite number of hours in a day. So, we have to make choices about how we spend our time. If we spend it writing tests, that is time we are not spending doing something else. Each of us needs to assess how best to spend our time in order to maximize our results, both in quantity and quality. If people think that spending fifty percent of their time writing tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather spend that time thinking about my problem. I’m certain that, for me, this produces better solutions, with fewer defects, than any other use of my time. A bad design with a complete test suite is still a bad design. (http://www.codequarterly.com/2011/rich-hickey/)

Another question to ask is does this help others understand the problem? You often don't write tests for yourself, but for other people, including the later you that has popped the problem off the mental stack long ago. Writing tests might lose you time right now, but the net gain of time saved by others may make up for it. Let me emphasize the word "may", because you might make the problem clearer by writing documentation in English rather than code. So the only conclusion…

That's precisely the problem. Many in the rails community do use it as a substitute for thinking.

In general, I'm not the biggest DHH supporter (although, he's made me a ton of money, indirectly, via rails), but I do like that he's stirring the pot here.

Back in the 90s and early 2000s, I wrote tests, when needed. Sometimes before application code, sometimes after, it was a discretionary tool that I had in my arsenal that helped me both solve problems and feel confident that "my code won't break".

At some point in time the majority of the rails community decided that if you don't test, you're a terrible programmer. Full Stop.

The problem with this was that testing tools were terrible at the time, RSpec, before it's API solidified was breaking every other release, things like capybara and selenium and watir, always kinda worked, but not really, and you'd often spend 10 minutes writing the business logic, and then 40 minutes writing tests, getting them to pass, wrestling with external dependencies, etc.

Furthermore, because people were practicing test-based application design, you were constantly re-writing your codebase and your test suite, because if you're designing for tests, you're not designing for the domain, and as domain requirements changed, and broke your testing model, you basically had to fix everything, and you couldn't get a handle on the domain because you had to be ruled by tests.

All that said, I do think tests are useful. TDD isn't as useful for…

This comment should not be [dead] (if you don't want to give/dock me karma for irahul's comment, down-/upvote my reply to this comment):

irahul 7 hours ago | link [dead]

> For example, Rich Hickey, the author of Clojure, said recently at the Strange Loop conference "We say, “I can make a change because I have tests.” Who does that? Who drives their car around banging into the guard rails!?"

Rich has spoken about it other time with an interview with Fogus:

http://www.codequarterly.com/2011/rich-hickey/

Hickey: I never spoke out ‘against’ TDD. What I have said is, life is short and there are only a finite number of hours in a day. So, we have to make choices about how we spend our time. If we spend it writing tests, that is time we are not spending doing something else. Each of us needs to assess how best to spend our time in order to maximize our results, both in quantity and quality. If people think that spending fifty percent of their time writing tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather spend that time thinking about my problem. I’m certain that, for me, this produces better solutions, with fewer defects, than any other use of my time. A bad design with a complete test suite is still a bad design.

He said something on the similar lines about development on CLR:

Fogus: Clojure was once in parallel development on both the JVM and the CLR, why did you eventually decide to focus in on the former? Hickey: I got tired of…

I am in a similar situation to the author of this article: learning to program after having having tried and given up ages ago.
I believe the problem lies in trying to learn a complex language from the bottom up.
In the OP's words: "Recently I took on the enormous task of learning Objective-C from the bottom up and I was struck by something I couldn’t shake: this is too hard."
I believe one must consider the top-down approach:
figure out what you want to do accomplish first, paint the solution in broad strokes, then fill in the details.
Hal Abelson touched on this in a recent interview: "there also really are people who like to understand stuff bottom-up. It’s not to my taste. To my taste the most important thing is the idea that you build on abstraction." http://www.codequarterly.com/2011/hal-abelson/.
Get over your discomfort not knowing every detail before the fact, consider what the solution to your task might be and try it.
For a non computer example: you meet a French girl who you want to get to know her better. You could drown yourself in learning the intricacies of French grammar, pronunciation, spelling, etc.. or you could muster your courage and engage in simple dialogue of the 'me- Tarzan you- Jane' type.
Might work and you could fill in the details later.