Re: What programming language for Future

On 2006-02-03, cr88192 <cr88192@xxxxxxxxxxxxxxxxxx> wrote:
and
its vm, matches the code that came with it, and the user can tweak it out
or
write new code, no concern for the past or the future.

I don't know what you mean here.

usually when apps come with scripts, those scripts are for that version of
the app. if the user edits the scripts, they are writing code for that
version of the app. if the language or vm changes, oh well, no big loss. the
app-provided scripts will change with the vm, and user supplied scripts will
need to be modified.

Which is exactly the same as when the compiler is shipped with the app. ?!?

I don't see any difference between compiler and vm here.

yes, that is partly why depending on the bytecode version, and not the
source version, is a very bad idea...

Correct.

older, all is fine. but once you try rebuilding and replacing the dll
(without rebuilding the app that uses it), things become much more error
prone.

Same for bytecode compiled app and VM.

yes, I agree to this at least.

Where you were comparing to recompiling DLL, which happens with general
compilers

yeah, but in the context of someone or another deciding "hell, it would be
cool if we did all our app's extensions as dll's". this leads to the
occurance of having to recompile the dll to write new app extensions, which
is imo a pita.

Re-interpreting it at _any_ run, no that is a pleasure;_)

one then ends up with apps where it is difficult to write extensions, if
for the sole reason that they can't rebuild a working dll.

Or get the relevant VM and all its modules set up. I don't see any
difference to be honest. Actually, one can link against an existing DLL
without having all source for the DLL. With modules in VM languages one
often needs them set up before a recompile.

the fact it is a general purpose compiler/language doesn't matter in this
particular case. in the case where extensions are done as dlls, using a
general-purpose compiler is the only real option, but that does not change
much.

I don't see why a specialistic compiler couldn't compile to a DLL.
.

Relevant Pages

  • Re: What programming language for Future
    ... version of the app. ... app-provided scripts will change with the vm, ... Which is exactly the same as when the compiler is shipped with the app. ... which was more for things to serve as plain scripting languages. ...
    (comp.lang.misc)
  • Re: What programming language for Future
    ... usually when apps come with scripts, those scripts are for that version ... version of the app. ... Which is exactly the same as when the compiler is shipped with the app. ... for the sole reason that they can't rebuild a working dll. ...
    (comp.lang.misc)
  • Re: What programming language for Future
    ... version of the app. ... app-provided scripts will change with the vm, ... for the sole reason that they can't rebuild a working dll. ... With modules in VM languages one ...
    (comp.lang.misc)
  • Re: Returning vectors from a managed dll
    ... If you return a vector from that DLL, ... * The DLL and the app are compiled with the same compiler and linker settings, with the exact same version of the compiler and linker, and using the exact same STL version ... In this case you can allocate memory in a DLL and delete it in the main app, and vice versa, because the memory allocator itself is in the same DLL. ... If you can't meet all of those conditions, you're not able to use std::vector in the exported DLL function declarations. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: How to configure my application to recognize the bin directory?
    ... This looks more like a compiler ... >scripts cannot find the namespace compipiled in the dll in my bin ... But the dll is in the bin ...
    (microsoft.public.dotnet.framework.aspnet)