www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Walter did yo realy go Ohhhh?

reply PatrickD <patrick.down gmail.com> writes:
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>
Jun 15 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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!
Jun 15 2008
parent Jan Claeys <digitalmars janc.be> writes:
Op Sun, 15 Jun 2008 11:40:33 -0700, schreef Walter Bright:

 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.

The C ABI isn't really useful if you want (standardised) interoperability on an OO level. That's where an OO machine design (be it a VM or a physical machine design--I don't care, and I don't see the difference for language designers) can be useful. E.g., I've been wondering for some time what a hardware design like Linn's Rekursiv[*] could have meant to computer languages if it wouldn't have been killed because of various reasons (mostly financial...). [*] <http://www.cpushack.net/CPU/cpu7.html> -- JanC
Jun 29 2008
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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*?"
Jun 15 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"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?
Jun 15 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
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.
Jun 15 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"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.
Jun 15 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
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.
Jun 15 2008
prev sibling parent reply Georg Wrede <georg nospam.org> writes:
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.
Jun 18 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Jun 18 2008
parent reply Georg Wrede <georg nospam.org> writes:
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.
Jun 19 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Georg Wrede wrote:

 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.

Or you could just use Java's VM instead of trying to figure out how to make all that work. I think that's a big part of it. The Java VM works and is available today, so for people like Steve it makes sense to use it.
 ---
 
 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.

That's kinda what the "virtual appliance" thing is about isn't it? Running an app inside a VMWare instance with some ASM as the VM's native tongue. --bb
Jun 19 2008
parent reply Georg Wrede <georg nospam.org> writes:
Bill Baxter wrote:
 Georg Wrede wrote:
 
 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.

Or you could just use Java's VM instead of trying to figure out how to make all that work. I think that's a big part of it. The Java VM works and is available today, so for people like Steve it makes sense to use it.

Hmm. I originally took it like he's promoting the VM as /itself/ having properties that make it the superior and Obvious choice. But maybe it's all simply about the Java VM bein easy ubiquitous and mature.
 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.

That's kinda what the "virtual appliance" thing is about isn't it? Running an app inside a VMWare instance with some ASM as the VM's native tongue.

Pretty close.
Jun 19 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Georg Wrede" <georg nospam.org> wrote in message 
news:485A582F.6050103 nospam.org...
 Or you could just use Java's VM instead of trying to figure out how to 
 make all that work.  I think that's a big part of it.  The Java VM works 
 and is available today, so for people like Steve it makes sense to use 
 it.

Hmm. I originally took it like he's promoting the VM as /itself/ having properties that make it the superior and Obvious choice. But maybe it's all simply about the Java VM bein easy ubiquitous and mature.

I could be wrong, but I got the impression that he, like a lot of VM-proponents (but not all!), aren't considering those to be two separate concepts. That is, I suspect they might be confusing "the way things currently are" (ie, "VMs like the JVM have mature sandboxing and runtime reflection today, and such things aren't currently in non-VMs") with "the only way things can be" (ie, "You can't have things like sandboxing and runtime reflection without a VM").
Jun 19 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Georg Wrede wrote:
 Hmm. I originally took it like he's promoting the VM as /itself/ having 
 properties that make it the superior and Obvious choice. But maybe it's 
 all simply about the Java VM bein easy ubiquitous and mature.

I see the advantage of a VM as being if you're inventing a new language, you don't have to bother writing an optimizer, code generator, or linker. Of course, LLVM should make that advantage moot as well.
Jun 19 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 I see the advantage of a VM as being if you're inventing a new language, 
 you don't have to bother writing an optimizer, code generator, or linker.

And often GC, part of the standard library, some/most external modules, DBMS interfaces, GUI widgets, etc, too :-) That's why creating a language like Boo on the dotnet was doable by a single person in few months. Bye, bearophile
Jun 20 2008