Re: What programming language for Future


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

imo, jvm is quite oddball.

things like jvm and .net are imo in a very different catagory than my aim,
which was more for things to serve as plain scripting languages.

however, the design, and implementation complexity, don't fit so well with
the usage pattern (script languages are typically small enough that the
compiler/vm can be written without investing too much effort). I may have
aimed too high for right now.

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

See also .NET

yes, .net is in about the same catagory as the jvm imo.

the vm's in these case are intended to operate standalone, rather than as a
part of another app, and the vm's intend to be able to do everything
themselves, rather than just 'scripts'.

I don't particularly like this style of vm.

at least in the case of java, and gnu's implementation, it was refocused
slightly into being a little closer to an extension language. imo, this
makes some difference, but I still don't like some things in java...

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

well, most of my experience has been using gcc, so I can't comment much on
other compilers.

but, it does seem worth mention that most scripting languages have very
simple compilers, eg, most of the work goes into the parser (well, excepting
runtime functions, which tend to be the largest part in my experience...).
the compiler typically just rewrites the syntax trees fairly directly into
bytecode (or, in some cases, the syntax trees are interpreted directly).


I would imagine that even a fairly fast c compiler would likely go a little
slower, due to the fact that a lot more has to be considered during
compilation (even absent processing headers or such).

then again, I can't be so certain (very crude dynamic language compiler vs a
fairly well written and optimized c compiler).

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)

I can't say much on them.
if the comiler is present at runtime, and especially if any form of bytecode
is used, imo, that makes it a pretty strong canidate for 'vm' status.

most of my oppinions are based around experience with c and c++, and the c
notion of what comes with the language (essentially, not a whole lot).

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.

well, in my case, I am imagining backwards compatibility as a non-issue
(can't run old scripts, no problem, don't run old scripts...).

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++

but, most of it is, and, particularly, most of these apps that expect the
user to recompile code into dlls, tend to have the code for the dlls as
either c or 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 :_)

past experience.

recompiling the damn quake2, half-life, and half-life2 dlls, and having them
very consistently not work.

messing with quake1 and doom3, and having the experience go much more
smoothly.

even crap like messing with ac3d, is workable (a lot of things are written
in tcl).

with many other apps, no luck.


now, I don't have a clear "reason" per se, beyond this.
keeping ramming into this particular problem bothers me.


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?

because the former typically works, and the latter almost always
segfaults...

note it is the dll being rebuilt, and not the client app. in the case where
the client app is built after the dll, I suspect the app doesn't really care
which compiler built it.

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.

yeah.

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.

one advantage of the compiled approach, yes.

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.

I was trying this, but the effort became too great.
more likely, I am going to patch a lot of what was written into my old
language, and deal with the memory-spewing problems somehow.

in any case, a lot has been resolved, a "go between" system between the
script level and c level now exists, and is maybe worth something. I just
have to figure how I am going to integrate some of my stuff with the usual
buildprocess though ('make' could be a little more flexible sometimes...).

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.

yeah.

in my case, I usually favor people rolling their own scripting languages.
even if the language is oddball and unique, it is typically well integrated
into the host app.

conversely, many python-using apps require one to go install the python vm
seperately, which, though minor, still stands out imo.

me remembering back a number of years ago. guile had just ended up annoying
my too badly, I started rolling my own languages, and have been to varying
degrees satisfied with this approach. then again, the languages still aren't
perfect, semantics, performance, and memory use have been ongoing struggles.

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

I would argue this one.
then again, "sizable" likely depends on personal definition.

10 or 20 kloc will give a pretty good script language (though, how easy this
comes depends a lot on if the coder has had past experience with these kind
of things).

if your app is, say, around 200 or 300 kloc, this is barely even noticable.


it could be I am just weird liking doing my own thing...

coding is not that expensive typically, then again, it could be argued that
I am lost in my coding...


then again, sometimes there are problems. recently I noticed that there
seems to be a problem, for example, where my inflater crashes for some
files, effectively limiting the reliability of my png loading code and
similar. yeah, some would have used libpng or zlib, I did my own. maybe I
will go and debug it, or maybe I will be more lazy and maybe fix it
eventually.


then again, a dilema is the apparent lack of any real significance to my
efforts. all in all most of it amounts to unfocused coding and recreating
stuff that exists already, but I am unsure what I "should" be coding.


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

yeah.

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.

possibly.

yeah, I don't like vm's having external dependencies. by this point imo it
is shown that it is likely too bulky.

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


building structure is usually globs of makefiles.

there is varying levels of coordination between them, but typically minor.
often the system is ad-hoc.

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.

well, in my experience, static linking with the dlls is also a common
approach for these kind of things.


but, whatever really...


.

Relevant Pages

  • 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: 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: 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)
  • Re: Security Error over LAN
    ... Actually, you can run scripts that require high privilege from GPO, but they ... there are MSI packages - they execute as LOCAL SYSTEM on the client - this ... build an MSI that programmatically modifies policy (recommended) ... I was able to get the app to work by ...
    (microsoft.public.dotnet.security)