Substancelessness

Again, not much original thought to contribute here.  It's interesting to see how utterly different Lisp/Scheme/Racket are from anything else we've looked at so far.  Conveniently, it feels a lot more natural than I had anticipated.  Looks like the wider use of recursion is really the most potentially mind-boggling trait of all this functional stuff that the book has presented in this first bit of Ch. 15, at least.

In fact, the Lisp/Scheme/Racket stuff may be coming somewhat more easily precisely because it's so foreign.  We're going in with an open mind, y'know?  Related to this idea, Brooks had a nice observation about the issue of thinking in terms of a certain language when you're coding. I wonder if this very problem might have contributed to making Scala seem so difficult.  After all, so much of the syntax was like Java.  And we were working in Eclipse, for which Java programming is the only frame of reference that many of us have.  Maybe that familiarity was more a drawback than an advantage.

The Blub Paradox

This is a pretty fantastic little article, right here.  It seems that it is now time to determine which language is the most powerful and use it exclusively until something better is created.  Is it still Lisp?  Or is it, perhaps... Ruby?  :O  We should probably figure this out once and for all during tomorrow's class.  

Not a lot to talk about this time.  Just very excited about getting into Lisp and whatnot.  (And to check out everyone's games tomorrow!)

Apparently This Is The Blog Where We Brag About How Far Along In The Ada Game We Are

We're frickin' done.

Just a little more commenting and then the README to go.

Here's what a certain famous critic said after we let him try the beta:
"This revolutionary artistic foray into the realm of imagination and beauty will touch players emotionally, moving them from tears of delight, to tears of nostalgia, to tears of disbelief, to tears of frustration, to tears of despair, to tears of not-wanting-to-go-on-anymore, to tears of just-being-finished-with-this-nonsense-and-instead-playing-a-game-that-doesn't-kill-them-when-they-try-to-pick-up-some-random-item-because-how-are-you-supposed-to-anticipate-that-sort-of-thing-honestly-?."
      -Roger Ebert

Bring your tear-rags, folks.


So anyway.

I figured that it's a good time to talk about Objective-C, because I'm pretty sure this is the first time we've seen it in the text.

It's a little baffling to me that the Apple folks would choose to have the iPhone programmed in this formerly somewhat obscure language, instead of something that was... actually used by anyone.  I mean, we saw on the TIOBE index that the language was virtually unused prior to its designation as the language to be used for writing iPhone apps.  So I wonder: Why did they choose to use it?  What makes Objective-C stand out?  Were the language designers just really wealthy and sad that no one was using the language they made, so they paid Apple to make it popular?

Google's decision to use Java for the Android is easier to understand.  Being so widely used in the first place, programmers would face a gentler learning curve in beginning to write apps for distribution on the Android marketplace.  And when you're trying to populate a market with user-created products that extend the capabilities of a device you're selling, this reliance upon knowledge of a very widely used language makes a lot more sense than demanding that folks learn something new.

But hey.  It worked out for Apple.  Objective-C is currently #3 on the TIOBE index, just after Java and C.  Craziness.

Those Times When You Hurt The Formal Parameters' Feelings Because You Made Them Sound Like They Weren't Even Real

I'm still a little flabbergasted by how nicely these sections on subprograms and functions programmers coincided with my most recent question on the Q&A.  The powers that be do not want me confused, even for a second.

Most of this business was pretty straightforward, I thought.  My eyes did glaze over a bit during 9.5.6 (Multidimensional Arrays as Parameters), but I'm not actually sure if that's important enough for us to go over in class.

It would be great, though, if we could talk about the pass-by-name method!  Not sure I've caught that yet, even after seeing it a bit in Scala.  And I sense it's going to be relevant when we look at the functional paradigm, when that happens.

Python has a cool thing going on with its def statements being executable.  With certain functions (if they're brief enough that this wouldn't impair readability), seems like it could be nice to have their bodies be conditional (as in the way the book demonstrates at the top of p. 390).

Keyword parameters seems like a pretty epic thing to me, so I don't know what you're on about with that, Brooks.  Sure helps readability when you've got all kinds of parameters flying around.  I do agree with you on the matter of Ruby's parameter system being complex, though.  It's just flat out scary, really...  Fortunately, I've been able to find absolute boatloads of hipsters talking about this stuff (and hopefully making it clearer) here, here, here, and here.

Personally, I would have liked it if the book had referred to its actual parameters and formal parameters as arguments and parameters, respectively.  Or would that have been less precise?  Are they completely interchangeable?

Ruby Is Better Than Everything

It was bound to happen.  I was an easy target, after all.  In any case, I expect the flying seraphic yaks of the sky-hipsters will be along to whisk me over the mountains to Portland any moment now.

In the meantime: moar tasty blag.

I've always been a little put off by the fact that posttest and pretest loops are so named.  Call me crazy, but if a loop were really posttest, wouldn't it come... after the test?  And before the test for pretest, right?  Makes sense to me, at least.

Here I join my voice to the communal "Whut?" regarding Python's inclusion of an optional else clause with its for loops that's been initiated by Cara over here.  This is a singularly useful abomination, though, and I could honestly see myself writing one of these in the future.  Readability be damned (not actually, but I don't see how it interferes with readability so much).

Why is it that so many languages, including Python, have constructs like range(x) return all the numbers up to but excluding x?  Strikes me as a little counter-intuitive.  I'm sure they have their reasons, though...

And one last thing:
It sure is neat that we can use something like

for (ptr = root; ptr!=null; ptr = traverse(ptr)) {
//tentatively fixed, because I think the book
//may have erroneously printed ptr==null for it's control expression
...
}

to traverse our data structures.  I didn't realize this before 8.3, and it's a swell thing.

Last Wednesday's Blog...Today!!1

Like Brooks, I'd taken for granted the fact that we have all these lovely control structures to account for the variability of contexts/user input for our programs.  8.1-8.2 opened my eyes to how convenient multiple selection structures really are (and to how silly Java was to forbid the use of switches on Strings before SE 7... Probably should have brought that up during the debate...).

(I have taken the liberty of translating the above into the mother tongue of the inexplicably Russian majority of my readers.  Courtesy of Google Translate, here it is, for your convenience: )
Как Брукс, я бы само собой разумеющимся тот факт, что у нас есть все эти прекрасные структуры управления для учета изменчивости контекстах / вход для пользователей наших программ. 8.1-8.2 открыл мне глаза, как удобно нескольких структур Выбор на самом деле (и как глупо Java был запретить использование переключателей на строк до Ю-В 7 ... Наверное, должны были принести, что во время обсуждения ...).

Nay, but srsly brethren!

Thanks be to goodness for whatever obscenely bearded technomancers came up with and put together all these nifty little things we bath-salts'd poop-flinging monkeys get to throw around so indolently.  Hug a nerd today.