Walter did yo realy go Ohhhh?

[Nick Sabalausky]

"Nick Sabalausky" <a at a.a> wrote in message 
news:g33t27$2dq$1 at digitalmars.com...
> "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*?"
>
>

One more thing: I also take issue with Steve's implication (somewhere in 
that post, I can't find it in that haystack now), that you need VMs for 
runtime reflection. Umm...If debugging symbols/type-info can be injected 
into the executable and read/interpreted by a debugger at runtime, then they 
can me made readable by the program itself at runtime. (In fact, isn't there 
already a D library that enables runtime reflection by doing just that?) And 
if there's any needed info that's not in the injected debugging symbols, 
what's to stop the compiler/language-definition from just sticking it in the 
vtable, or something else akin to a vtable?