Jim Crigler <criglerj_at_acm.org> writes:
> >>>>> "B" == Brady Montz <bradym_at_cs.arizona.edu> replied:
>
> B> Many people, including myself, will refuse to have anything to do
> B> with perl. It's not wise to pick a language on so many people's
> B> blacklists. Guile, while probably tecnically the most feasable,
> B> should probably be set aside for the same reason.
>
> Do you mean that you don't visit web sites with server side CGI (most
> estimates put Perl at 75-80% of CGI)? I doubt it. You seem to mean
> that you have religious intolerance against using perl yourself. From
> what I understand, the main blacklist Perl is on is that of the
> Computer Science establishment. If that's your perspective, why not
> say so.
This is not the best counterargument. For example, Just because I'll visit web
sites hosted on windows 95 machines doesn't mean I'd ever set up a web server
on such a machine. Since you yourself admit the existense of negative feelings
against it, I resubmit my argument that we shouldn't use a language on so many
blacklists. I've already sacrificed guile to the same chopping block. If it
turns out that there is no candidate language which doesn't anger people, then
I'd say it's not worth the cost of adding one.
>
> Perl's not perfect, and I wouldn't use it for some things because it's
> just unsuitable. But an FVWM2 configuration is a small database of
> sorts, and perl handles those quite nicely.
>
It's not that perl's always unsuitable, it's just that it's rarely the most
suitable.
> But FVWM already *has* an interpreter running! You can pull up the
> FvwmTalk module any old time you want, issue commands. No, it doesn't
> do conditionals and looping (which CS tells us is sufficient for most
> reasonable things to be done in reasonable time), but it *is* and
> interpreter and it *is* running all the time.
Good point. I meant a standalone interpreter.
> So I think we agree that the extension language might very well reside
> in a module rather than in the "core" code. Hmmm... what visibility
> to the "core" data structures can/should a module have? Given a
> module extansion language implementation, there's an awful lot of data
> to have to pass around ...
I agree.
1. If we add a full-blown turing complete language to fvwm, I want it to be
(a) optional (b) in a module (needed for a) and (c) well designed, both on
our part and the language designers part.
2. If it's in a module, then we clearly need to redesign the module interface,
probably by adding a new type of modules. This would either result in
unportable designs (dynamic loading), or a message passing scheme with
lots of mutexes which could well be slow.
3. Right now, the only language a machine need support for a user to run fvwm
and all of its modules is C. If we add another language, then we have to
ensure that fvwm remains completely usable for people who
don't want to run that interpreter on their machine. The nightmare
situation for me is that fvwm supports 4 languages, and I have to have all
of them running in order to run the feature set which I want. Not only will
this bog down many machines, it makes fvwm depend on a lot of other
software projects (and language designers are always changing things).
Does anybody who knows slang have anything to contribute? I haven't looked at
it in years, but it's starting to sound to me like a reasonable choice. Is it
lightweight enough to run in the fvwm executable?
>
> --
> Jim Crigler (407)850-9677 | Crown Him with many crowns
> 4053 Summerwood Avenue | as thrones before him fall;
> Orlando FL 32812-7941 | Crown Him ye kings who rule the earth
> criglerj_at_acm.org | for He is the King of all!
--
Brady Montz
bradym_at_cs.arizona.edu
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Fri May 01 1998 - 10:50:17 BST