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>

PatrickD wrote:
> 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>
> 


Steve and I did talk about VMs, and I did say that I thought they were a sham. Maybe I did say Ohhhhh, but that was more of understanding his point of view than agreeing with it.

Steve also says in his blog that the advantage of VMs is language interoperability. I don't agree, since all you need for interoperability is an ABI. For compiled languages, the C ABI serves just fine, and as long as each language has a way to get at the C ABI, you have language interoperability.

Case in point - D!

"PatrickD" <patrick.down@gmail.com> wrote in message news:g33e3g$pdd$1@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*?"

"Nick Sabalausky" <a@a.a> wrote in message news:g33t27$2dq$1@digitalmars.com...
> "PatrickD" <patrick.down@gmail.com> wrote in message news:g33e3g$pdd$1@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?

Nick Sabalausky wrote:
> 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.

By that argument, anything that a VM can do, native code should be able to do. This is kind of true, but to get some of those things (i.e. hot-swapping, security management, selective dynamic loading) working, you almost need to implement a mini-VM.

"Robert Fraser" <fraserofthenight@gmail.com> wrote in message news:g346g3$ou7$1@digitalmars.com...
> Nick Sabalausky wrote:
>> 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.
>
> By that argument, anything that a VM can do, native code should be able to do. This is kind of true, but to get some of those things (i.e. hot-swapping, security management, selective dynamic loading) working, you almost need to implement a mini-VM.

True, but I guess what I was trying to say was "How do VMs work from the perspective of language interop?" From the security perspective, for instance, there are differences (With a VM, you can sanbox whatever you want, however you want, without requiring a physical CPU that supports the appropriate security features.) But for language interop it all just comes down to "standard ABI" regardless of whether it's a VM's machine code or a real CPU's machine code.

Robert Fraser wrote:
> By that argument, anything that a VM can do, native code should be able to do. This is kind of true, but to get some of those things (i.e. hot-swapping, security management, selective dynamic loading) working, you almost need to implement a mini-VM.


Heck, there's nothing stopping one from writing a CPU instruction set emulator and create a 'VM' to do it. There are only a couple hundred of rather simple instructions needed to be emulated.

PatrickD wrote:
> http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.html

I've read a number of his previous rants, and I've generally found them interesting, informative, and thought provoking. Sometimes even entertaining. This one was an exception.

> <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>

The above story, and the fact that he goes on ranting irrespective of the slide sequence, the fact that he blatantly generalizes, derides, self-promotes, the fact that the transcript includes the superfluous interjections from spoken language, that he cavalierly exaggerates, and some other details -- collectively lead me to think he's, ehhh, in an "accelerated state of mind".

There are basically a few different ways to achieve that state of mind (of which I'm not suggesting any, I'm merely enumerating the most usual ones here).

 - A speed trip.
 - The upper phase of bipolar syndrome.
 - A state of mind that can be deliberately achieved through repeated self-assertion and self-excitement.
 - The pre-onset stage of a nervous breakdown.
 - A basically "God, I'm good" mindset.

Now, I'm not saying it's any of these, but it sure looks like it. But enough of that.

---

What especially made me glad here was (yet another) "subliminal" advertisement for D. At least we get exposure.

PS, well, most of his blog readers are intelligent-wannabes, professional programmer-wannabes, and the readership of his blogs must be immense. The more controversial the blog, the more readers you get. A littel like tabloids, where you know that "The President escapes death" on the front page translates to "he almost stepped on a bee that could have stung him". Just take them with a truckload of salt. But D being mentioned there gets a lot of eyeballs. And the D related stuff was written with obvious respect for D! One really couldn't ask for anything better.

Georg Wrede wrote:
> PatrickD wrote:
>> http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.html
> 
> I've read a number of his previous rants, and I've generally found them interesting, informative, and thought provoking. Sometimes even entertaining. This one was an exception.
> 
>> <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>
> 
> The above story, and the fact that he goes on ranting irrespective of the slide sequence, the fact that he blatantly generalizes, derides, self-promotes, the fact that the transcript includes the superfluous interjections from spoken language, that he cavalierly exaggerates, and some other details -- collectively lead me to think he's, ehhh, in an "accelerated state of mind".

My guess is he's more accustomed to writing blogs than presenting them as talks.  So he was probably just a little hyped up on stage fright.  I think he makes some very good points in that talk, and they mostly make sense if you start with the premise that all software can and should be delivered over the web.  He's working for Google, and before that at Amazon, so it's not surprising that his world view is skewed in that web-centric direction.

So I think he's just forgetting (or deliberately ignoring) the fact that someone still has to write that VM and the operating system it runs on, and those better run as fast as possible or no one will care how wonderfully "dynamic" it is.

--bb

Bill Baxter wrote:
> Georg Wrede wrote:
>> PatrickD wrote:
>>
>>> http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.html
>>
>> I've read a number of his previous rants, and I've generally found them interesting, informative, and thought provoking. Sometimes even entertaining. This one was an exception.
>>
>>> <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>
>>
>> The above story, and the fact that he goes on ranting irrespective of the slide sequence, the fact that he blatantly generalizes, derides, self-promotes, the fact that the transcript includes the superfluous interjections from spoken language, that he cavalierly exaggerates, and some other details -- collectively lead me to think he's, ehhh, in an "accelerated state of mind".
> 
> My guess is he's more accustomed to writing blogs than presenting them as talks.  So he was probably just a little hyped up on stage fright.

Let's hope it. (OT: it took me more than the promised 20 minutes to read the stuff. Very much more. I guess I'm a slow reader.) :-)

> I think he makes some very good points in that talk, and they mostly make sense if you start with the premise that all software can and should be delivered over the web.  He's working for Google, and before that at Amazon, so it's not surprising that his world view is skewed in that web-centric direction.
> 
> So I think he's just forgetting (or deliberately ignoring) the fact that someone still has to write that VM and the operating system it runs on, and those better run as fast as possible or no one will care how wonderfully "dynamic" it is.

Considering that all the languages he talks about still have to be /compiled/ for the VM (JIT or no JIT), I have a hard time seeing the case for VMs being rock-solid and compelling.

Think about it. If I have a web site where I let viewers run their own code on my server, I could simply provide them with a rigged D compiler. The compiler would (or a preprocessor, it would actually be easier for me) flag no-nos in their source code as errors. No biggie.

Or I might sandbox the running user binaries.

Of course I'd should also enforce per user quotas (or per user code snippet), and such. They could even write to the hard disk, and an easy way would be to have a virtual filesystem in a file.

---

And then there's the choice nobody seems to suggest: running a VM that uses the processor's own ASM as the VM language. The (e.g. D) compiler would enforce the exclusion of dangerous idioms.

Sure, this is more work than I'd personally care to do, but for some big company this should be a reasonable alternative.

---

Hmm. On second thought, there /is/ one case for the VM. And that is, the choice of languages. The bunch of languages he is talking about, I guess, are more suited for this kind of "user-tinkering" than "Real Languages", like D. At least some of them are somewhat usable with hardly any programming experience.

But that's definitely a language choice issue, and not a VM/no VM issue in itself.