lubutu

> the response by the project creator was "The busybox code sucks."

Whoever that is, they aren't the project creator.

Sorry, but this really isn't relevant to the article. "A bad UI pattern" is not an invitation to rant about your unrelated UI pet peeves...

More specifically — assuming the rules were the same as for the first such workshop, linked in the article — "women were automatically allowed to apply for a spot, while men were allowed to apply if they knew a woman who was going to attend."

I agree more with philh's response that there is no alternative term for the true meaning of "regular expression" — a regular language, as suggested by _delirium, is not the same thing.

I suppose I could accept "regex" as not being a regular expression as such, but the two are used so interchangeably that maintaining a distinction isn't very realistic. I'd personally rather a regular expression described a regular language, and "PCRE" (or so) used for the Turing-complete expressions with a similar syntax.

I do dislike people calling that expression a "regex", because it isn't: regular expressions cannot contain backreferences, and must be computable in linear time, whereas primality tests are polynomial.

Yeah, it seems BBC Worldwide is available for free in every country on Earth, except Britain. I'm not sure in whose head this makes any kind of sense.

Etymologically, the word 'spirit' originally meant one's life force or 'breath'; its supernatural connotations came later.

The justification in On Intelligence is what I'm talking about wrt words being "separated at most 1 em." Contrary to what Gruber says, there are no "unsightly gaps between words" because there is a maximum distance of 1 em between words, after which it favours ragged right.

"the Kindle still lacks hyphenation but yet insists upon full-justified text. Full justification without hyphenation inevitably results in unsightly gaps between words on a few lines each page."

On my Kindle, at least, words seem to be separated at most 1 em, and any more and they go 'ragged right' instead of hyphenating — which I actually found far more pleasant than even Liang's LaTeX hyphenation algorithm in terms of readability.

I also have a real problem with them referring to the second digit from the right as the "tens place", considering it's actually base sixteen...

Well, if we permit functional programming languages all the problems concerning imperative control flow magically go away...

And yet backward goto is extremely useful. Consider this Java,

  redo: while(true) {
      for(Item x : xs)
          if(f(x))
              continue redo;
      break;
  }

With goto,

  redo:
  for(Item x : xs)
      if(f(x))
          goto redo;

Most people seem at first to balk at the goto, even though they're functionally identical, and the goto is much clearer and less error prone...

Perhaps you could only share a limited amount of information to non-users, like the topics they'd like to talk about, and an "about you" or something. Just enough to catch one's interest.

I think it would be much more inviting if you could at least search for people without having made an account. As it stands I have no idea what kind of people I could talk to, so I have no idea if it would be worth giving up my email address.

Edit: Interesting idea, though. With social networks like Facebook you really need to have met in order to befriend — it doesn't encourage random meetings. When I was younger I would find likeminded people by chance on odd websites; I think that's become harder as I've grown older.

I think you misunderstood; the OP was saying that there should be no search button, ever, as in (e.g.) Chrome.

These are all completely obvious — idea 2, though, only in retrospect. For a long while I've wondered about how to combine path editing with hyperlinks. Numerous browser extensions have tried various methods: mode toggling, modifier keys, the direction whence came focus, and so on.

The OP's approach is perfect: always navigate to wherever the caret is placed. I would personally drop the ugly gradients in favour of hyperlink-style underlines, but seriously, thanks for an elegant solution to a simple problem.

I'm very fond of typography, but I don't know all that much about it. Is there a name for the style of fonts like Elena? As soon as I saw the sample I was struck by the similarities to Minion, which has to be my favourite serif font (though I do prefer some aspects of Elena).

Notice 'parseLogLoudly'. You could not implement that using your set of functions: you are not allowing for other code besides 'resume' inside the 'handle' blocks.

Also, I don't believe the mass duplication of code necessary for your approach is acceptable, even within a library.

The abstraction problem remains: you are reimplementing parseLog every time you write a new handler, as I described in section 1.

(By the way, you're looking for Haskell's Either type, but ([a],[b]) and [Either a b] are equivalent here.)

Suppose we were attempting to write parseLogInteractively by just returning errors (as in idiomatic Go).

If parseLog just returned an error upon failure we would have to same problem as exceptions do, as explained in section 1. So we have to make parseLog return two lists: one of entries, and one of errors. We would then have to search through the error list fixing and reparsing each error. In Python this would be something like,

  def parseLogInteractively(file):
      return parseLinesInteractively(file.readLines())

  def parseLinesInteractively(lines):
      entries, errors = parseLines(lines)
      if errors:
          entries += parseLinesInteractively(askToFixEntry(e.text) for e in errors)
      return entries

Again we lose the ability to abstract the function 'parseLog'. And I don't know about you, but this looks far worse to me than "resume FixEntry" in terms of exposing implementation details.

I've wondered about the "two week problem" in the context of large open source projects. It would be great if a developer could spin up, say, a temporary VPS for Chromium development, the toolchain all set up and source ready to modify. I can't be the only one with a pet bug that must be trivial to fix, but the overhead of setting up a whole new toolchain to do so is just not worth it.

It amazes me that the argument against this is by attacking some "standard-bearer of his cause." Let's not ask how it is compared to existing alternatives, or to 'perfection', but rather the potential alternatives. Your argument is akin to "stop talking about 'engines'; horse-drawn carriages might suck, but so does walking."

Likewise the emphasis! Although you're right that a lot of languages are bureaucratic with enigmatic exceptions and so on, I think that a well-typed language is better to learn to begin with than one which basically accepts whatever nonsense you throw at it. I'm not sure the perfect beginner's language exists, but I personally believe that if it did it would be statically typed.

I've noticed that the NUL-termination problem [1] has come up a number of times in these comments. If you want a solution to this that isn't so drastic as an object system, perhaps take a look at Usul [2], non-POSIX 'tabular' Unix utilities which use an AWK-style $RS.

[1]: http://news.ycombinator.com/item?id=4369699

[2]: http://lubutu.com/soso/usul

Fair point. Though anything using the standard POSIX dirent API would still get the performance hit (even if path resolution doesn't).

As Rob mentions in his post, the more dotfiles there are in $HOME the slower path resolution for any subfiles becomes. How do we navigate to ./src? We open the directory and read all the entries until we find the one called "src". What happens if we encounter a morass of dotfiles beforehand? src takes a while to find. The clutter may be invisible to you, but it does gum up the works.

A meta-corollary: whenever a headline with a question mark appears on Hacker News, there will be at least one comment referring to Betteridge.

(Please, can this stop?)

Analogously, "you don't need maths to tell you that one and one is two."

In POSIX -R is the recursion flag for ls, cp, rm, etc. So if you want to recurse, -R is probably a safer bet than -r. (ls -r just lists in reverse.)

Some of those American massacres go back to the 14th century. It's quite possible that more have occurred in the USA than the UK, but that's hardly a fair comparison.