True, but it's useful to have tiny toy but real programs for newbies to experiment with.

All these Thing in 30 lines posts would make an excellent collection for people to type in, debug, modify, debug, expand, debug, etc.

Someone could make an RPi friendly page and collate these. Maybe include some gentle competitive edge - code golfing or neatest added feature or somesuch.

I agree with your basic sentiment, but tiny toy programs for newbies to experiment with should DEFINITELY have readable variable names.

I've been programming for 15 years now and that Excel-like thinger taught me a thing or two, and it didn't take tearing it apart to figure out how it worked.

This game, and the Snake one from yesterday, didn't even go so far as to generate the DOM objects in a loop. That was another big part of how the Excel thinger worked, it wouldn't have been nearly as succinct without it.

Now, I can see using the HTML if there were significant text data you wanted to include, e.g. text-adventure room descriptions, but this just seems like they're focusing on the "30 lines" part of the challenge and not the "super-dynamic" part.

Have you looked at http://codegolf.stackexchange.com/ ? From what I understand, these are similar except it's more about doing things in the least amount of characters than lines.

For example, here's the 552 character Ruby code to print the lyrics of a song.

    i=44
    s="We; n7trangMsL8loT63Ke rules5s8d8I
    AJull commit4nt'sChatFKink: of6CHldn'tRetKisJrom<ny@Ruy-/A= if?<sk 42DS'tLE 4?;Lo8bli=L7ee..
    O,R1)O,R001)/-.."
    "
    I justCannaLE?2Gotta >u=Msta=.|
    Ng1Nlet? downNrun<rH=5desMt?N>cryNsayRoodbyeNtE< lie5hurt?|
    
    We'T3n each@Jor s8lSg6r hear9<ch: but6;Lo7hyL7BInsideCe both3Cha9Ro: S
    We3KeRa45we;QplB|1)O)NgiT, nPgiT
    (G|iT? up| howFJeel:
    | know|me|<= |
    YH|8s|o |t's been|ing|'re| a|nd|make? | yH| othM|A|ay it
    | w|D|ell| I'm|G|ou|I| f|Lh| t|er|
    NP|
    (Ooh|eTrQ|RSna | g|on|ve".scan(/[^|]+/){s.gsub!((i+=1).chr,$&)}
    puts s

I like the idea of the challenge, but some kind of standard formatting is needed, otherwise 30 lines is very arbitrary. I like the X bytes challenges as there's no ambiguity in what that means.

My problem (and I think a lot of other people's) is not with the arbitrariness of lines so much as the fact that you can run a longer program through a very dumb minifier and get a "short" program just by sacrificing readability. It's still very much the same program; we're just rewarding people for making it harder for us to read. This problem isn't solved by switching the requirement to bytes. I would sooner accept a token limit than a byte limit, because it's harder to elide tokens to the point of unreadability in most languages.

I think the fairest way to do it and keep readability is to have the minified code be the byte count and also provide the unminified version as well.

Similar to http://ioccc.org/ ?

Me, I'm looking forward to "Linux in 30 lines."