Re: What programming language for Future

On 2006-02-03, cr88192 <cr88192@xxxxxxxxxxxxxxxxxx> wrote:
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.

That doesn't change the versioning problem one bit. If I have to haul my
scripts through a real compiler, or through a VM/JIT, there is no
difference.

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

See also .NET

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).

Be careful here that you don't equal C/C++ to gcc. C/C++ are lousy in the
performance department, but that is all relative, and a lot can be done
about it. gcc just doesn't do it :-)

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).

So? All compilers I work with have the compiler built into the app. (Delphi
and Free Pascal's IDE)

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.

I have exactly the same problem with getting scripting languages running.
They often are horribly backwards compatible due to their specification
being relatively lax and evoluating in radical ways each iteration.
Of course it doesn't have to be this way.

maybe it is because they typically want people to rebuild the damn things
with msvc, and not everyone has msvc

That is a tool availability problem, and exactly the same with VMs.
Moreover, not all the compiled world is C/C++

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.

You keep repeating that, but provide IMHO no reasons :_)

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

And why does that _need_ to be a interpreter or bytecodecompiler-VM step,
and not a compile followed by the dynamic linking of a DLL?

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;

Sure. Heterogenity is a maintenance hassle.

theoretically, the dll approach is more powerful, becuase the user can use
functionality outside the host app (system api's, ...);

And get the raw performance and low memory footprint of compiled apps,
together with the possibility for plugins to scale to become _huge_. IMHO
this is the main reason.

scripts/bytecode actually can have better mem-footprint, but most general
purpose scriptlanguages don't in practice. (example of better footprint in
VM languages, that is actually in production: Forth)

Actually scripting/VM languages could exhibit nearly all these advantages,
specifically when engineered for the domain.

However usually they don't, because people resort to a horribly complex
general purpose scripting language which are externally maintained, and thus
have their own agenda. IMHO MathLab comes closest to what I mean.

The trouble is that one must have quite a sizable application to make it
worthwhile to develop a good domainspecific scripting language.

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).

I prefer static linking because ease of deployment and avoidance of
more complex versioning (.exe + .dlls having own versioning). However if you
want to postdeliver code (e.g. plugin system) or share code in anyway you
can't do without dynamic libs (of which DLLs are the windows incarnation).

usually it is trivial stuff, like running the app from a directory where
it's dlls are not visible

Equal to misconfigured/misinstalled VM/scriptlanguage. Moreover, maybe the
DLL is application generated, and then the application knows how to find it.

, ... 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, ...).

Bad design, bad building structure. Of course the script will simply
silently fail :_)

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).

This is only a problem with statically linked DLLs, not with truely
dynloaded ones that load on symbol.
.

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
    ... 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: How to make Forth interesting?
    ... For lots of things specialized languages may have the easiest ... We could use an iTV card as a sort of Forth stamp and host web pages ... I was just joking about the insanely complicated way that you ... Naturally scripts that are simple in scripting languages are suppose ...
    (comp.lang.forth)
  • Re: Newbie-ish dialog box questions
    ... My app uses FiveWin. ... and elsewhere are written with Clipper ... writing code blocks. ... and call code blocks in these scripts! ...
    (comp.lang.clipper)