Walter did yo realy go Ohhhh?

[Nick Sabalausky]

"PatrickD" <patrick.down at gmail.com> wrote in message 
news:g33e3g$pdd$1 at digitalmars.com...
> http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.html
>
> <Steve Yegge>
> He told me the other day, [talking about] one of my blog rants, that he 
> didn't agree with the point that I'd made that virtual machines are 
> "obvious". You know? I mean, of course you use a virtual machine!
>
> But he's a compiler dude, and he says they're a sham, they're a farce, "I 
> don't get it!" And so I explained it [my viewpoint] to him, and he went: 
> Ohhhhhhh.
> </Steve Yegge>
>

I've never read much of Steve Yegge's stuff (in large part because I have 
better things to do than read though a book-sized blog post. "But I 
deliberately make them long because it's the opposite of everyone else and 
that makes mine stand out!" Yea, good for you, I don't care.) But after 
reading through the Intro, "FOO Chaos", "The right way to do unit testing", 
and "Static Typing's Paper Tigers", I'm now convinced Steve's full of shit.


FOO Chaos:
First he says "VMs are great for language interop", then he demonstrates 
that VMs *don't* solve the language interop issue. Ok, fine, then he scales 
back his claim and says "Well, they help!" Doesn't do much to convince me 
that VMs are "obvious".

But then, the whole idea of VMs being better for language interop is 
preposterous anyway. After all, how do VMs work? You take a 
high-level-language, compile it down to a sequence of pre-defined binary 
opcodes, and execute. Hey! Just like a real CPU! So if you can solve 
language interop on a VM, you can do the same thing to solve it for native 
code.

And what is that thing that "solves" it for VMs? (Oh that's right - it 
doesn't solve it, it merely *helps* it). A standard ABI, or at least 
something that basically boils down to a standard ABI. And that can't be 
done on native code...why?

So the strengths of VMs (and sure, there are some - but they're limited) do 
not lie in language interop.

And maybe I'm wrong, but I'd imagine that a bigger problem for language 
interop would be different languages for which there is no single machine 
target (native or VM) that they all have in common.


The right way to do unit testing:
"And [on a dynamically-typed language] when it works [for that mock data], 
you're like, "Oh yeah, it works!" You don't run it through a compiler. You 
copy it and paste it into your unit test suite. That's one unit test, right? 
And you copy it into your code, ok, this is your function."

Soo...He's advocating the strategy of assuming something works just because 
it worked for your mock data? Unit tests and regression tests catch one set 
of bugs, a good statically-typed compiler catches another set. The sets 
probably intersect, but one is not a superset of the other.

"To a large extent, especially in C++ and Java, the way you develop is: 
[step 1, 2, 3, etc.]
So it's this batch cycle, right? 1950s. Submit your punch cards, please."

I'm sure he didn't mean this as a serious argument, just a jab, but 
seriously, you could say the same thing about the scientific method. It's 
step-by-step a batch cycle too.


Static Typing's Paper Tigers:
"[Static Typing is a talisman that "keeps real tigers away". And I'm proving 
this by pointing out examples of big production systems written in 
dynamically-typed languages (While forgetting that VB and VB.NET code both 
supports and typically makes appropriate use of static typing)]"

Ok, so you *can* make big production systems in dynamically-typed languages. 
So what? You *can* also do it in Perl or Assembly. I don't think anyone 
disputes that. You can build a whole house using a coin to drive in all your 
screws. But that doesn't turn screwdrivers into proverbial tiger-dispelling 
talismans. The question is: During the course of those programs' development 
(and maintenance), how much time, effort and money did they spend chasing 
after things that a good statically-typed language would have immediately 
caught/prevented? Oh, is it *those* things that are the proverbial tigers? 
So just because big production systems *have* been made using those 
languages, that automatically implies that the developers *didn't* ever come 
across those problems and have to spend their time overcoming them?


I did agree with Steve on one thing though: "What are the odds that XML's 
going to wind up being less verbose than *anything*?"