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 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.

While I agree I believe this comment by _delirium sums this up rather well,

http://news.ycombinator.com/item?id=1486502

full comment thread here http://news.ycombinator.com/item?id=1486158

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'm not a big fan of your explanation. To be more precise, true "regular expressions" are computationally equivalent to deterministic finite automata, which indeed can test an n-character string in O(n) time.

NFAs and DFAs both recognise the regular languages (and only them).

It's PCRE (Perl Compatible Regular Expressions) which is one of the most popular dialects of regex. But AFAIK there's isn't a hard and fast RegEx standard.

So I'd argue that code is RegEx.

I guess it's just a matter of perspective though.

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 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.

Looking at my Kindle Keyboard, I have one book (Moonwalking with Einstein) that is ragged-right and another (On Intelligence) that is full justified. Perhaps it's the formatting of the e-book and not the device?

I think it's an option that the publisher can control if they wish. In theory this is good, in reality it probably means it gets turned on or off randomly depending on which intern converted books today.

In the ebook's HTML, you can specify the text-align CSS attribute. If not specified, I believe the Kindle defaults to justify, and the Nook defaults to left-align. So books you read on the Kindle that are left-aligned (ragged right) probably have specified that in their CSS.

Can you (or lubutu) share some pics? Thanks.

Moonwalking with Einstein http://imgur.com/7UJgQ

On Intelligence http://imgur.com/QIdam

The second of those is interesting. Most of the lines are right-justified, and just a few aren't. It looks to me as if it's right-justified the lines except for when it can't do so without introducing an unbearable amount of whitespace, in which case it's fallen back to ragged-right.

(You can see it isn't just ragged-right where most of the lines happen to end in the same place; compare the spacing on, e.g., the first two lines.)

I don't think I've ever seen anything typeset that way before.

I think the reason you've not seen anything typeset that way before is because it's ridiculous to do it that way! You end up with an awful mix of fully justified and ragged-right... to my eye this makes me expect new paragraphs where there are none, for example.

It's such a shame that Amazon just doesn't seem to care about good typesetting practice. It's maybe just not something Amazon views as a "barrier to sale", but as Gruber says, the Kindle only has to do one thing well, so why shouldn't it do it fantastically well?

Good point, I hadn't even noticed that. I suppose it's better than full justification, but still odd that they don't just do ragged right.

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.

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...

Only if you take 'ten' to be a number in base 10. /s

Every base is base 10. ;).

I understand you meant that in jest but base 1 is possible, albeit very cumbersome:

1 = 1

2 = 11

3 = 111

4 = 1111 ...etc.

Sorry for the nitpick, but that's not really "base 1".

It is "unary", which is completely different encoding than the "positional notations" such as decimal, octal, binary, etc. The positional notation doesn't work with base 1, as in that notation there would be only 0, and 0, 00, 000, etc., which all mean the same number: zero.

That I agree on, it is conceptually different (and more primitive); the whole conversation just reminded me of GEB.

Really? How do I write zero in your system? (as in the number of apples I have if I have none at all)

If octal uses the digits 0-7, and binary uses the digits 0-1, then shouldn't base one use only the digit 0?

0 = 1

1 = 11

2 = 111

3 = 1111, etc. {1,2,3...} and {0,1,2...} are isomorphic.

But surely that's not the way it works in any other base. In any other base there is a digit '0' such that:

0 = 00 = 000 = 0000 = the number of apples I have if I don't have any.

To dig in a little further, when we say base N, we mean that we are expressing an integer as a sum of the values N^i (for i being every nonnegative integer), each multiplied by a weight that is an integer between 0 and N-1 inclusive.

Why do we do this? Because every integer has exactly one unique representation in this system. We could have picked any values we wanted for the places (rather than N^i) but unless we pick carefully, either some numbers aren't representable, or some numbers have multiple representations.

Base one has a problem right from the start, which is that 1^i = 1 for any value of i - when all places have the same place value, numbers aren't going to have a unique representation. The other problem is that the only number you can write in base one is zero, because the only possible weight (the only integer between 0 and N-1) is 0.

When you write 1111 = 4 you are sneakily using the length of the number on the page to encode the value. The length of the number on the page isn't supposed to matter. In base 10, 17 = 017 = 0017 = 00017.

"When you write 1111 = 4 you are sneakily using the length of the number on the page to encode the value. The length of the number on the page isn't supposed to matter. In base 10, 17 = 017 = 0017 = 00017."

I couldn't find a rigorous definition of a base system offhand. If you require that number N prepended with additive identity I, so IN = N, I agree with you. But every number in the system I described certainly has a unique representation. Also, this is incorrect: "The other problem is that the only number you can write in base one is zero, because the only possible weight (the only integer between 0 and N-1) is 0." Try taking a look at: http://en.wikipedia.org/wiki/Peano_arithmetic

They clearly have a different understanding of base 16 to us!

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...

The article mentions that as well: "Backward gotos could be ok when it makes sense that your error case would repeat the last iteration"

Btw, in Ruby there are two keywords that are basically backward gotos: redo and retry.

That's the exact case where I saw it in the PostgreSQL code. Re-doing join pruning when a join was eliminated.

while (xs.Any(x => f(x))) { }

Pulling things out into other functions makes it even clearer.

Though yes, the goto is clearer than the labelled continue. I wouldn't necessarily agree that it's less error prone though.

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

I just used higher order functions to keep the example short, and I'd use them irl to avoid code repetition. The concept still applies without them:

    while (fTrueForAny(xs)) { }

    boolean fTrueForAny(List xs) {
      for (Item x : xs) {
        if (f(x)) {
          return true;
        }
      }

      return false;
    }

There isn't anything non-imperative about higher order functions.

    var externalDataStore = new ExternalDataStore()
    [1, 2, 3, 4].each(x => externalDataStore.store(x))
    externalDataStore.getItems().each(item => print(item))

Plenty of higher order functions, and plenty of non-functional, ordered, stateful, imperative code.

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.

Yes, I understand your point. I didn't want to share the user profiles with non-users. I also haven't looked into how easy it would be to harvest profile pictures and profile data. Any thoughts on this?

"I didn't want to share the user profiles with non-users."

And yet, if someone wants to harvest profiles, they'll just sign up with a fake/throwaway email address, while legitimate users have to give up real information to do the same.

True. I'm not sure how to effectively prevent harvesting. Limiting the rate at which profiles can be fetched only goes so far.

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.

Interesting idea. If one doesn't want to leak any profile information, one could only show the number of results to non-users but not the actual profiles.

Of course, it's very hard to prevent any malicious use of the profile data.

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

Oh, I'm sorry. I'm taking back that then.

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.