Hackety Hackers Before A Live Studio Audience

May 22th 18:40
by why

Okay, here’s some video from the Hackety Hack meeting in Boston a couple of weeks ago. Three talks from gentlemen who were among the original fifty Hackety Hackers. This here is Eric Mill coding a chat application. This talk is just ramshackle and fun, especially since the audience subverts his chat in a really damned gleeful way. I also like this talk because it reveals a bunch of shortcomings to H-ety H that I hadn’t seen yet. Oh, I’ve much to do!

The other talks are great, too. Part one: Kevin Driscoll’s talk about how he went about teaching Python to his high school kids. And part two: Brian DeLacey’s overview of what we’re shooting for and how he’s been teaching his kids.


Peter Cooper

said on May 22th 19:44

Great video! One great thing about it is the guy sounds like Tom Green, which keeps me listening :)


said on May 22th 22:15

I knew Eric Mill before he was internet-famous. He seems grander now, like a platform diver gracefully hanging in the air above a pool.

Tony Buser

said on May 22th 22:44

Holy Firefox toolbars Batman!


said on May 22th 22:46

Chris you are too kind. Especially since I am just so danged disorganized in this presentation! I did a better job at RailsConf, I promise.


said on May 23th 00:18

The ^$().*? noise is madness! How shall the regular expression monster be slain by HH?


said on May 23th 05:08

Offtopic, would you be a dear and fix the LINK tag (currently href=“/”) at the top of your RSS feed, _why?


said on May 23th 11:59

I don’t think regexes can or should be slain—but perhaps we can find a better syntax. Brevity in regular expressions is overrated.

Someone want to try writing a library to make this work?

Regexp.build do
  one_or_more { exactly "foo" }
  exactly "bar"
  capture { zero_or_more { any_char_from "a".."f" } }
end # => /^(?:foo)+bar([a-f]*)/


said on May 23th 13:01

I think a more readable syntax is what yerejm meant, Mental, not removing them altogether. I really like the block approach. I wonder if you could do simple stuff in a line though, with a special string?

string.match(“starts with ‘gordon’, has any letters or numbers, has one ‘@’, has many letters or numbers, has one ‘.’, ends with many lowercase letters”)
=> string.match(/^gordon[a-zA-Z0-9]*@[a-zA-Z0-9]+\.[a-z]+$/)

This would match emails starting with “gordon”. I think this grammar is actually parsable.


said on May 23th 14:02

It’s parseable, but I’ve learned to strongly dislike attempts at “natural language” programming because they create false expectations. People get repeatedly drawn to try things which are entirely natural in English but fall outside of the small subset the synthetic language corresponds to, so they’re effectively punished for experimenting.

[In terms of specific experiences, I would have to say the least unsuccessful example of a “natural language” approach is Inform 7, but even there I find it becomes very frustrating to learn until you finally internalize the limits of its pidgin.]

Contrast that with Ruby, where generalizing from examples is likely to lead to pleasant surprises, rather than a smack on the hand and violated expectations. That’s one of the things that makes Ruby so fun in the first place, isn’t it?


said on May 23th 14:38

HH has a few methods like String#starts? and String#ends? and String#remove that I think help the situation a bit. And there’s String#count, too.

aanand: Is fixed. Thankyou for being so aanandamant.


said on May 23th 18:21

I’m always amazed that ruby doesn’t have String#starts? and String#ends? methods. I think mental actually has a reasonable idea. It could probably even be a lot more succinct. Maybe I’ll play with something tonight :)


said on May 24th 14:00

I like MenTaLguY’s example.

But perhaps the exactly operator is redundant?

And could we assign captured stuff to variables directly? Using magic $n variables is succinct but a bit implicit, and especially confusing when there are lots of nested captures to index.

> r = Regexp.build do
>   anchor_start
>   one_or_more "foo"
>   "bar"
>   capture(:named_thing) { zero_or_more { any_char_from "a".."f" } }
> end
=> [...]
> named_thing
NameError: undefined local variable or method `named_thing' [...]
> "foobarbaz" =~ r
=> 1
> named_thing == $1
=> true


said on May 24th 15:56

Anthony: maybe it could return a subclass of MatchData which would define accessors for the match names.

Something like: capture(:named_thing){…} or capture_many(:other_things){…}.

Which could then be used:
result = built_expression.match(“Some text”)
result.named_thing => some match
result.other_things => array of stuff

It’s a little more explicit, and somewhat less magic.


said on May 25th 14:58

If you’re trying to assign to a variable, why not use assignment?

named_thing = capture {zero_or_more {any_char_from “a”.."f"}}

And named_thing would be a scalar or an array, depending on whether 1 or more objects were found.


said on May 25th 18:16

I like netghost’s idea.

By way of contrast, using assignment with the call to capture directly won’t work, since Regexp.build is not evaluating the regexp, but constructing it, which may not even happen in the binding where you need to do the match (in fact, if you’re using this more expensive way to create a regexp, you almost certainly don’t want it to be!). There are also problems if you need to nest the capture.


said on May 30th 02:59

_why, sorry to bother you on a blog post, but HH forums and other bits and bobs aren’t working for me and I wondered what’s wrong? There isn’t a hint on the other parts of the HH site…

This sadly means some of the later HH leasons just fall down and die, is there something wrong at your end or mine?



said on May 30th 09:16

Got the same problem…Hope you guys can fix it soon.

Comments are closed for this entry.