Re: On Scripting versus Compiled solutions

[jonadab]

I would agree with what you say except that I know there's an incorrect and harmful prevailing attitude out there that "scripting" languages are in some way inferior, because they don't create "real" programs. Honestly, I don't think we'll get the C/C++ people to stop looking crosseyed at us until we have an optimizing compiler that produces platform-specific native binaries, and I don't think a bundlemonkey approach (binding the interpreter and the bytecode together into an executable package) will do the trick. It's stupid, something that's only needed because of misconceptions that people have, but I'm pretty sure it's necessary, politically, for at least one major VHLL to have this before we'll be able to finally do away with the whole issue.

[tilly]

Whichever VHLL does this will lack eval, which will make it distinctly less HL...

[adrianh]

Whichever VHLL does this will lack eval, which will make it distinctly less HL...

Not necessarily so. You just need to include your compiler with the binary. Languages like Lisp and Pop-11 have been doing that for years.

[tilly]

Go back to Re: On Scripting versus Compiled solutions and read the following sentence, ...I don't think a bundlemonkey approach (binding the interpreter and the bytecode together into an executable package) will do the trick.

The approach that you suggest (including the compiler with the binary) is exactly the "bundlemonkey" approach that jonadab ruled out. And my claim is that if you rule that out, then you run into problems with eval.

Well..I'm not sure what he would think of Squeak's approach (decompile the running environment into C++ code which, when compiled again, gives you the same environment again). That isn't the usual "bundlemonkey" approach, but it isn't totally dissimilar either...

[jonadab]

Whichever VHLL does this will lack eval, which will make it distinctly less HL...

There are ways around this. First, some of the things we currently do in Perl via eval can be done in other ways. *Almost* anything you can do with the block form of eval could be done another way; Perl6 is adding some features in this regard. The string form of eval of course can do some things that would break this, so a solution is still needed for eval. There are a couple of options, and a hybrid approach that I would personally favour. The first approach is to provide an optimizing compiler for a subset of the language that does not provide the string form of eval. Thus, any program that doesn't use that could be compiled. The second approach is to compile all the rest of the code in the usual way but *also* then bundle an interpreter or JIT compiler, so that string eval and things like it would be possible. The hybrid approach is to only bundle the compiler or interpreter if the code being compiled uses the string eval.

I favor the hybrid approach, but really I don't think this is a big deal. The real problem is convincing anyone (well, anyone capable of doing anything about it) that political reasons and the views of C/C++ programmers are good reasons to write _and maintain_ an optimizing compiler despite that for almost the entire existing userbase the existing vm-based solution is the way to go.