Re: OT: compilers, interpreters, and VMs

On Mon, Jun 11, 2007 at 02:09:36AM +0000, Marco van de Voort wrote:
On 2007-06-02, Robbert Haarman <comp.lang.misc@xxxxxxxxxxxxx> wrote:
On Sat, Jun 02, 2007 at 09:38:26PM +0200, Marcin 'Qrczak' Kowalczyk wrote:
I disagree. Very few programs would benefit from the ability to change
code on the fly.

I agree with all your other points, but not this one. It sounds like the
same argument that gets made against anonymous functions, macros, etc.
by people used to languages that don't have these features.

So following your reasoning, a language should absorb each and every feature ?

Not exactly. I was trying to point out that run-time code generation,
like certain other features, is one of those things that people don't
realize the utility of, unless they've worked with it pretty
extensively. Indeed, many existing programs have been written without
run-time code generation, anonymous functions, exceptions and so on.
Clearly, we don't need these features. Does that mean they aren't useful
or desirable? You'll find people both sides. However, I claim that these
features are useful and desirable, and many people arguing otherwise
just haven't realized their power yet.

Does this mean we should add each and every feature to a language? Not
at all. What we should strive for, in my opinion, is a language with a
minimal set of features than can be used to _build_ as much
functionality as possible. Macros are my favorite examples of this. With
this one feature, we can build new syntactic forms. This eliminates the
need to bake a lot of constructs into the implementation (e.g. looping
constructs), but also to build syntactic forms that nobody had thought
of when the language implementation was made.

Like other features, being able to change code in a running program has
its supporters.

(I'm only supporter for certain specific goals. Like mathlab and similar
programs, and e.g. MUDs and other online games. Not for general purpose
programming)

Ok. So if we define "general-purpose" as "every kind of program, except
the ones Marco wants to use dynamic code generation for", then a
general-purpose language should not include dynamic code generation. I
see your point, though. Indeed, if there are only one or a few
application domains in which a feature would be useful, then it makes
sense to not include that feature in a general-purpose language. I just
don't agree that this is the case for dynamic code generation.

For example, I seem to recall Paul Graham bragging about
how they would fix bugs in the running system while the customer was
still on the phone. The ability to make changes to a program without
having to take it offline can be very valuable.

It can yes. However messing with a program runtime can also be a great way
to break a program or installation.

Absolutely.

On the other hand, the situation we're talking about is one where the
running program is already known to be broken. Whoever is doing the
debugging will just have to make the right decision about whether to
make the changes in the running system or not. Note that nothing
prevents you from testing the proposed changes off-line, and only
merging them into the running system once you're satisfied they are
indeed an improvement.

Imagine that you could
upgrade the software on your mission-critical system, without having to
restart it!

Imagine messing with mission-critical systems runtime. Brrr.

It could kill you or it could save you. What if the satellite has
already been launched? Your choices are "Too bad, we'll get it right in
the next release." and "We can at least try to fix it on the fly."
Unless, of course, your implementation does not support run-time
changes. In that case, you have rejected the latter option up front.

And if we really have the ability to modify software on the
fly, why not also use it to update, say, your web browser, without
having to restart it?

Well, for starters, your software needs to be modifyable (think bigger,
slower here),

Bigger, probably. Slower, not necessarily. But you're right, there are
costs.

there is an integrety issue there (who is allowed to?),

Yes. On the other hand, is this really different (for purposes of
authorization) from applying a patch off-line and restarting?

but most importantly, it is pretty incontrollable.

Again, more so than applying a patch off-line? Depending on the
specifics, dynamic modification could even be more controlled:
presumably, dynamic modifications would have to stay within the
framework of the language (type safety etc.), whereas an off-line patch
could overwrite arbitrary parts of the binary with arbitrary data.

I also wanted to point out that the ability to modify a system at
run-time is not exactly revolutionary. In fact, it is completely taken
for granted in certain domains. And I don't just mean certain obscure
domains that hardly anybody ever touches. I'm thinking of web
development and the shell. In both cases, we can modify the system by
adding, removing, and editing files. In both cases, I think, the ability
to modify the system without having to restart it is clearly valuable.

I am a aware that the whole infrastructure underlying a web site is not
like how we would typically imagine a programming language. However, if
you imagine URLs as designating functions (which is actually what they
do in many web applications I've worked on), you should get the picture.
The shell, on the other hand, is very much like how we would imagine a
programming language. The external programs _are_ the functions of the
shell (although, of course, most shells also support functions that
aren't external programs -- but these can typically be modified
dynamically, too).

Various programs allow run-time customization to greater or lesser
degrees. Emacs can be completely stood on its head (or maybe that should
be "many heads" in Emacs's case). Mutt, while clearly not allowing the
core program itself to be altered at run-time, still allows extensive
modifications to its behavior through the ability to run commands and
modify various hooks. The line between program code and configuration is
fuzzy; some configuration languages are so powerful that they can be
used to alter the purpose of a program. To stick with the two programs
already mentioned: Emacs (a text editor) can be used to play Tetris, and
mutt (a mail client) can be used to send and receive Usenet news...and
the necessary changes can be made without restarting the running
programs.

Regards,

Bob

--
"Cross platform apps are like unisex underwear."


.

Relevant Pages

  • Re: OT: compilers, interpreters, and VMs
    ... by people used to languages that don't have these features. ... a language should absorb each and every feature? ... run-time code generation, anonymous functions, exceptions and so on. ... general-purpose language should not include dynamic code generation. ...
    (comp.lang.misc)
  • Re: OT: compilers, interpreters, and VMs
    ... by people used to languages that don't have these features. ... a language should absorb each and every ... benefit from dynamic code generation, ... Macros are my favorite examples of this. ...
    (comp.lang.misc)
  • Re: OT: compilers, interpreters, and VMs
    ... by people used to languages that don't have these features. ... a language should absorb each and every feature? ... benefit from dynamic code generation, ... Macros are my favorite examples of this. ...
    (comp.lang.misc)
  • Re: OT: compilers, interpreters, and VMs
    ... by people used to languages that don't have these features. ... a language should absorb each and every ... run-time code generation, anonymous functions, exceptions and so on. ... The ability to make changes to a program without ...
    (comp.lang.misc)
  • Re: Where did the prophet really live?
    ... features were in the spoken language or not. ... Now the point that Macdonald makes is that Sabaic was the prestige ... medieval arab historians had reported inscriptions ...
    (soc.religion.islam)