Disqus - Latest Comments for avdi

Re: Why Go Matters

twitter-80396371 — Fri, 13 Nov 2009 13:31:53 -0000

Well yeah - there is that kind of competition, which is indeed healthy =). What I was saying was in reaction to "x, y, and z are competing for the title of 'better language'", which was the result of a miscomprehension from my part =)

Thanks for clearing up those issues for me, and reacting in a good way =) This is rare enough (for coders in general) to be pointed out.

Re: Why Go Matters

twitter-80396371 — Fri, 13 Nov 2009 13:29:31 -0000

Yeah, read too fast. Sorry for that.

Re: Why Go Matters

avdi — Fri, 13 Nov 2009 13:27:13 -0000

I reworded the statement in case others made the same mistake.

By the way, I disagree with you in one regard: of course there is competition. There is always competition in a healthy language ecosystem. It may be of the friendly and mutually beneficial sort, but languages will always compete for mindshare. I for one am happy to see competition returning to the systems language arena, in the form of languages such as ooc, Go, and D.

Re: Why Go Matters

avdi — Fri, 13 Nov 2009 13:21:10 -0000

I think you misread the article. I never said that Go was better than ooc. I said "go is better compared to languages like...". That means that it is better to compare it to those languages than to languages like Ruby and Python. I can see how if you were reading fast, or if English is not your first language, you might have misinterpreted it to mean I was saying that Go is better than other langauges; but that was not the intent.

Re: MrProper: Cleaner blocks in Ruby

michokest — Mon, 02 Nov 2009 04:47:32 -0000

I agree there, if_valued would be better naming. However, Array(variable) is a good way of avoiding nil checks, so I guess we should rather use that!

Re: MrProper: Cleaner blocks in Ruby

avdi — Sun, 01 Nov 2009 20:32:30 -0000

Thanks for the linkage. Note that since Ruby already provides a 'defined?' operator with slightly different semantics, the use of the term "defined" to mean defined-and-not-nil might be a bit confusing. Something like 'if_not_nil' or 'if_valued' might be more precise.

Re: Simplicity is Complicated

avdi — Sat, 31 Oct 2009 08:50:49 -0000

Indeed. When choosing a "default" philosophy of design, I think Unix philosophy of small, sharp, composable tools is one of the safer bets.

Re: Simplicity is Complicated

avdi — Sat, 31 Oct 2009 08:48:12 -0000

And yet the complexity is still there, you've just internalised it. This is an example of what I'm starting to think of as the accessibility/expressiveness continuum: do we push the complexity out in the open to be more accessible to the lowest common denominator, or do we count on certain principles being pre-loaded in the readers' brains and realise the benefits of greater expressiveness?

Thanks for the comment!

Re: Simplicity is Complicated

avdi — Sat, 31 Oct 2009 08:44:00 -0000

Your example reminds me a little bit of a pet peeve I have about certain ticketing systems (Lighthouse being one example): a drop-down selector for ticket status. This is workflow, I don't want to pick a status from a list. I want to see a button that lets me advance the ticket to the next state, and a button to back it up to the previous state in the workflow.

A pick-list of states is certainly "simpler" from the programming side but it imposes an additional cognitive burden of complexity on the user side.

Re: Simplicity is Complicated

avdi — Fri, 30 Oct 2009 11:56:13 -0000

As regular readers know, I'm a huge proponent of both BDD and pair programming. I find that, if anything, frequent pair programming has opened my eyes to the diversity of opinion between different programmers regarding what is "simple" and what is complicated.

Re: Simplicity is Complicated

thesaj — Fri, 30 Oct 2009 11:06:59 -0000

I'd postulate that most of the overcomplicated systems are justified in the name of efficiency.

Re: Simplicity is Complicated

avdi — Fri, 30 Oct 2009 10:14:45 -0000

Great insights, Tim. I'd think a lot of programmers confuse simplicity with clarity, which is a delineation I failed to clearly (heh) draw out in this article.

I love the word "implicity", I'm going to use that in future.

Thanks for the links, I'll check them out!

Re: Simplicity is Complicated

avdi — Fri, 30 Oct 2009 10:09:24 -0000

Paul, as I replied to chii, this article is definitely about how talk about essential/inherent complexity and doesn't really deal with the accidental kind.

I have pretty strong opinions about the the virtues of different styles of coding - I tend to agree with you, for instance, about staying within the idioms of the language. I tried to keep my opinions out of this article, however. The intent was to provoke reflection on what our definition of simplicity is says about our preferences regarding where the complexity belongs.

I'll definitely check out your article!

Re: Simplicity is Complicated

avdi — Fri, 30 Oct 2009 06:12:20 -0000

Ironically, I've seen some of the most overcomplicated systems justified in terms of efficiency.

Re: Simplicity is Complicated

avdi — Fri, 30 Oct 2009 06:11:31 -0000

Thanks for the note. The original challenge those examples come from was a pure-Ruby challenge, so the entrants would not have had ActiveSupport available to them.

A question for you: what does your choice to use ActiveSupport say about where you prefer the complexity to be?

Re: Simplicity is Complicated

avdi — Fri, 30 Oct 2009 06:07:19 -0000

This is a legitimate point, and you're right that I didn't address it. I've also seen the words "complexity" and "complication" used to differentiate: complexity is an inherent property, whereas complication is something that people add. In this article I'm talking more about the language people use when they have stripped a problem down to it's core complexity and are deciding how to distribute that complexity.

Thanks for the comment!

Re: ISO8601 Dates in Ruby

avdi — Mon, 26 Oct 2009 12:57:44 -0000

Thanks, I've updated the post!

Re: the update | gemcutter | awesome gem hosting

avdi — Mon, 26 Oct 2009 10:56:51 -0000

This is welcome news.

Re: Double-Load Guards in Ruby

twitter-16997374 — Fri, 23 Oct 2009 17:55:18 -0000

You're right. But specs/tests is about the only place I do so myself.

Re: Double-Load Guards in Ruby

avdi — Fri, 23 Oct 2009 09:55:05 -0000

Konstantin, thanks for your comment. Setting up $LOAD_PATH is essential and I make sure to add the current project to the load path in all but the smallest of projects.

However, there are always a few files where relative requires can't be avoided. For instance, it is conventional to set up unit test/spec files so that they can be run standalone. In order for this to work each test file has to start out by requiring a test_helper.rb or a spec_helper.rb which then sets up $LOAD_PATH, requires additional libraries, etc. Because this test helper is the first thing to be loaded and can't rely on anything else to be configured, it has to be loaded with a relative path.

This is where I see the most double-loads occurring, because when all of the tests are run together they each require the test helper file, often with differing relative paths. Using expand_path is a way to ensure that files that must loaded relatively are required in a consistent way.

I may update the post to make it clear that I'm not suggesting you use relative requires throughout a project.

Re: Array-ifying Values

avdi — Thu, 22 Oct 2009 00:48:54 -0000

Indeed. I personally feel that Array() is more intent-revealing, but [*] is certainly an alternative.

Re: My WebOS Makefile

avdi — Sat, 17 Oct 2009 18:30:51 -0000

Heh. Truth is, I wrote all that weeks ago, and as I was looking over my project today I realised it might be of use to someone else. It's certainly nice to know someone else doing Webos dev, though.

Re: Thin vs. Unicorn

avdi — Wed, 07 Oct 2009 11:56:19 -0000

I'd be interested to see the memory usage stats.

Re: Why Do Rubyists Test So Completely?

avdi — Sat, 15 Aug 2009 22:05:58 -0000

@ssmoot I find a lot of your comments thought-provoking, but I have to say I take with a grain of salt comments about Ruby's culture and community from someone who doesn't go to any Ruby conferences. You can't know the wider community if you don't take part in it.

Re: Why Do Rubyists Test So Completely?

avdi — Fri, 14 Aug 2009 15:54:32 -0000

Mike, with all due respect, the "mindset" section did not really address the design aspect of testing. And it certainly didn't acknowledge that design isn't just *a* reason, it is the reason that TDD was popularised in the first place, and that verification - which you devote 95% of your article to - is merely an ancillary benefit.