[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Dylan rather than CL -- why?
- To: email@example.com
- Subject: Dylan rather than CL -- why?
- From: Stavros Macrakis <firstname.lastname@example.org>
- Date: Fri, 4 Dec 1992 16:25:35 -0500
- Cc: email@example.com
- In-reply-to: Frank Deutschmann's message of Fri, 4 Dec 92 14:44:05 EST <9212041944.AA06880@panix.com>
- Sender: firstname.lastname@example.org
email@example.com (Frank Deutschmann) said:
> ...where the target hardware can support it, it is nice to
> have at least some of the development environment present, to
> allow end-user programming and live system debugging.
> Ah, but here you're pulling the whole environment back in....
... debugging an active production system can be even more
The issue is not whether it should be possible to have a development
environment in the running system when you DO want it. (Which I agree
is useful in many circumstances.) I think that's a given. The issue
is whether it should be possible to have a running system WITHOUT a
development environment when you DON'T want it. The latter is not
possible if you don't make a clean distinction between development
environment and execution environment, while making such a clean
distinction doesn't hurt in the other case.
Also, to reply to another point, if you want a standard development
environment, you can certainly define one without building it into the
language, just as you can define a standard linear-programming package
or a standard graphic-interface package (although of course its
implementation is much more closely linked to the language
implementation than these examples). There are surely a lot of areas
where standard interfaces are desirable. In fact, I could go through
the arguments why that is more important than standardization of
development environments if it's not obvious.