Avdi Grimm › Comments

"I have no problem with the word (which is common in the programmer community); I object to it's misuse. There's nothing magical about the OP's reaction to nanny-staters. "Automatically" is the right word. Now, if the OP instantly transformed into Captain Freedom, Cyborg of Liberty everytime someone said "there oughtta be a law...", that might be considered automagical." - Avdi Grimm

"Please don't equate reddit libertarians with all libertarians. I keep /r/libertarian in my reddits for the links, but I almost never read the comments." - Avdi Grimm

"I didn't say I object to the word; I object to it's misuse. Actually, come to think of it, that IS a misuse. There's nothing magical about an automatic restart." - Avdi Grimm

"I think I'm a programmer. When I see someone misuse the term "automagically", I automaTically assume they don't know what they are talking about." - Avdi Grimm

"Wow, this review has finally answered the question: What happens when unstoppable banality meets immovable snobbery?" - Avdi Grimm

"Upvoted for accuracy. My wife does most of this (I pay the bills and look after the finances). I work for a startup which means I work overtime every day and often on the weekend as well. All the replies about "balancing the load" are nice in theory but for some family situations they just don't work." - Avdi Grimm

Every reporter has a point of view. But some refuse to admit it. - Avdi Grimm

"I'm not sure you picked up on the theme of the article. You seem to think I was making a point about what is good design, and I wasn't. It wasn't about design, it was about the *terms* we use when talking or debating about design. The example wasn't mine, but it wasn't "contrived" either - it was a real response to a programming challenge. I wasn't putting either version forward as objectively "good" - I was using them to illustrate two takes (out of many) on the meaning of simplicity." - Avdi Grimm

"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." - Avdi Grimm

"I'm amazed how many people seemed to get stuck on the code examples. Honest question: did you read the rest of the article? If not, why not? I'm looking for ideas on how to write philosophical articles that have concrete examples but don't cause the reader to get stuck on those examples." - Avdi Grimm

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

"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!" - Avdi Grimm

"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." - Avdi Grimm

"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." - Avdi Grimm

"I'm using Ubuntu and my fonts look nothing like that. And no, I don't use the Microsoft fonts. Something's messed up on that machine." - Avdi Grimm

"Heh. I love that you can publish dozens of technical language-tips articles in relative obscurity, then have one purely philosophical post shoot up reddit and HN - and all the language lawyers come out and quibble about the code samples! Not that I'm complaining, mind you, I actually learned something from this comment. Thanks!" - Avdi Grimm

"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!" - Avdi Grimm

"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!" - Avdi Grimm

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

"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?" - Avdi Grimm

"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!" - Avdi Grimm

"Think of it this way, who would you rather have manage you? Someone who is familiar with the difficulties of software development, or someone who thinks that things can be done in half the time if they just nag you persistently enough?" - Avdi Grimm

"Oh! I re-read your post and I think I get it now. Panes inside of tabs instead of tabs inside of panes. Kind of like virtual desktops. OK, yeah, I see where that would be nice. It exists for emacs, of course – I’ve used a couple of modes that make it possible to cycle through different pane-sets. But AFAIK it’s not been integrated with tabs. Nevermind, please ignore my obtuseness." - Avdi Grimm

"Fair enough. I can see the argument of the features being in some way more obvious or less surprising or otherwise easier to find/use in Vim. Also, I actually have a lot of respect for people that prefer the modal-ness of Vim – I think the modal model makes a lot of sense. I prefer Emacs for other reasons, but Vim’s neatly complementary single-key commands make a lot of sense to me intellectually. I’m still kind of curious about the Tabs/panes thing though, because I honestly don’t get the distinction you are making. Granted I disable tabs in Emacs (I often have a hundred buffers open, and use ido-mode to navigate between them quickly), so I might be missing something about the interaction between Emacs “windows” (i.e. panes) and the tab bar which differs between Emacs and Vim. But I know that if I turn tabbar-mode on, I get split panes and tabs under one OS window. Would you mind expanding on the difference between the two editors in this regard?" - Avdi Grimm

"It’s always hard to write a comment like this without coming off like a zealot. So let me start out by saying that I’m glad you’ve found an editor you love! Several of your criticisms are of Emacs are ones that I have as well. In particular, while it’s possible to get pretty decent indentation, highlighting, and ERB support in Emacs, it’s certainly not set up that way out of the box in any distribution I know of (not even Aquamacs). It’s not at all clear that, for instance, it’s usually a good idea to replace the dated ruby-mode.el that comes with it with a newer version. However, so many of the VIM features you cite are basic Emacs features as well that I question your characterisation of yourself as “proficient” with Emacs. For instance, I’m not sure how you can spend more than a month in Emacs without learning the commands for dividing a window into panes by heart. Likewise, if you’ve used it for a year without learning the commands to repeat a command, record and execute macros,..." - Avdi Grimm

"Leaves out the fact that in 1984, the proles were fed all the kind of pleasurable pablum that Brave New World describes. The aspect of 1984 that the comic captures are the measures that party members - i.e. people too smart or too well-connected to be kept down as proles - were subject to to keep them in line." - Avdi Grimm

"Your rationalisations are as plausible as someone saying no one is responsible for voting George W. Bush into office, because each vote taken as an individual was insignificant. And your claim that you create jobs is no better than the vandal who claims that by breaking windows he is making jobs for glaziers. A shred of economics knowledge will tell you that you are removing value from the system, not adding to it. Bottom line, you contributed to increasing prices and reducing wages. Thanks, Robin Hood." - Avdi Grimm

"Thanks, I've updated the post!" - Avdi Grimm

"This is welcome news." - Avdi Grimm

"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..." - Avdi Grimm