Re: What programming language for Future


"Marco van de Voort" <marcov@xxxxxxxx> wrote in message
news:slrndu67rt.a41.marcov@xxxxxxxxxxxxxxxxx
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.

well, in this case the primary difference is when it is run, eg, prior to
runtime, or during runtime.

then again, java had used a seperate compiler, but still interpreted the
result. imo, java is oddball in this respect.


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;_)

not sure I follow.

the user typically does not notice the recompiling/reinterpreting going on
with a vm, as it is done automatically, and is typically quite fast (usually
the scripts are pretty small, and most script languages tend to compile
quite fast vs c or c++, possibly due to the absence of things like header
processing and similar).

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.

well, usually the vm is built into the app (eg: either part of the app's
codebase, or maybe a statically or dynamically linked lib).

linking to dll's is easy. writing working replacement dlls for existing apps
has been in my experience a lot more problematic, for some reasons I have
yet to decipher. maybe it is because they typically want people to rebuild
the damn things with msvc, and not everyone has msvc, and mingw is
incompatible in some subtle way. then again, it could have something to do
with the def files as well, but I don't know.

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.

it could, but using dll's for extensions is imo a very bad teqnique if the
idea is that people will actually write scripts or extensions. imo,
vm/interpreters do a much better job on this front.

one edits the damn file, and the app knows how to rebuild it, and often will
do so on its own.

I think dlls are popular because:
the scripts/extensions can be written in the host language, thus avoiding
the usual hassles of interfacing c or c++ to most script languages;
theoretically, the dll approach is more powerful, becuase the user can use
functionality outside the host app (system api's, ...);
it is the least work.

hell, even I have used dll's in the past, but tend to prefer static linking
instead (in my experience, less can foul up with static linking).
usually it is trivial stuff, like running the app from a directory where
it's dlls are not visible, ... resulting in the app not working. sometimes
it is other problems, like the dll got rebuilt but the app didn't, and now
they don't match so that the app crashes (vs being left in a consistent,
albeit out of date condition, ...).

imo, a lot of this didn't seem to be worth it, contributing to the switch to
using primarily static linking for my stuff (yeah, system stuff is still
dlls, but at least they don't really change all that often...).

then again, in general writing replacement dlls comes out as very
problematic in my experience. a lot seems to come down to subtle order type
issues.

typically use of "auto export" seems common, and different compilers/linkers
will apparently export the functions in a different order (or however all
this works).



.

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
    ... 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: What programming language for Future
    ... usually when apps come with scripts, those scripts are for that version of ... 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: 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)