D vs. C#

[Walter Bright]

Derek Parnell wrote:
> On Mon, 22 Oct 2007 11:27:47 -0700, Walter Bright wrote:
>> I once went through the design of encrypting source, and concluded it 
>> wasn't very practical (look at CSS for DVDs!). Also, it's pretty clear 
>> that VM bytecode does a lousy job of obfuscating source - good Java byte 
>> code decompilers exist.
>>
>> You might as well distribute source - after running it through a comment 
>> stripper, of course.
> 
> I work daily with a language called Progress. It is a 4GL style used
> primarily with large databases. Anyhow, it 'compiles' to a type of p-Code
> and we distribute our apps using its encrypted source facility. The
> run-time application server executes the p-Code in a VM. We have been doing
> this since 1994. It is very fast and applications are transportable to
> other architectures without changing the source code.

That's achievable with a language that is defined with portable 
semantics in mind. A VM doesn't contribute to it.

> I've moved
> applications from System V (Olivetti) to VAX-VMS to Redhat without having
> to even recompile.

Since you didn't have to change the source code, either, it doesn't make 
much difference if recompilation was necessary or not.

> It is practical to encrypt source code.

Since the people you are trying to hide it from must have the decryption 
keys in order to use it, it is inherently insecure. All it takes is one 
person with motivation to reverse engineer a crack, and then *all* of 
the source is available to *everyone*. It happens with DRM stuff all the 
time.


> VM's can be bloody fast.

They can be fast enough, but they'll never be faster than native code.


> One can distribute portable applications without compromising intellectual
> property.

All it takes is one motivated hacker, and *all* of your stuff then is 
compromised.

> I regard your point of view as blinkered. It seems to me that your opinion
> could be paraphrased with "if we had a perfect world we wouldn't have to
> solve problems". There is a role for VM languages and there is a role for
> native-code languages. It is not an either/or situation.

I've implemented both VMs and native compilers, I know intimately how 
they work. I don't believe that the claims made of VMs are justified.

BTW, because of the way the Java VM bytecodes are defined, it is 
particularly easy to decompile.