This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Translation for extension is a bad idea


Subject: Translating to Scheme is a bad idea
X-Mailer: VM 6.75 under Emacs 20.7.1
Reply-To: hanwen@cs.uu.nl
FCC: ~/persoonlijk/Mail/sent



Hi,

I've just read the ongoing discussion about GUILE translators. Since I
have been using GUILE as an extension language for some time now,
someone might find my NLG 0,05 interesting.

>There is lots of experience with translating other languages into
>Scheme and Lisp, so we know it is practical.

First of all, it is to me unclear what the original goal of having
translators was --- or rather, which problem exactly would be solved
by having translators.  The guile reference manual explains the
history, and describes the idea of translators as merely being an
"interesting feature". (note that the urls given in the doco don't
work any longer).  Perhaps, the reason for having translators should
be documented more clearly, because I think 

	"But I hate Scheme --- it has Lots of Insignificant, Silly
	Parentheses!"

is utter bollocks. Sure, there will be people saying this, but the
love for the syntax of a language is an acquired taste. Lots of people
still write to the python newsgroups saying "I hate Python -- it has
No Significant Braces!"

If you are a developer considering an extension language, you will
consider the following issues:

	1. is the language powerful enough?

	2. is it easy to embed the interpreter?

	3. is the interpreter powerful enough?

	4. will the language still be around in a few years?

	5. will the interpreter still be maintained in a few years?

	6. is the language popular enough?

	7. do I enjoy writing code in the language?

I suspect that the `translator idea' was designed to solve issue 6 and
possibly 7 (if not, please correct me).

However, I see problems both with writing and using translators. Most
importantly, syntax only goes skin-deep. If you want to offer a
different languages you also have to translate the semantics. For
example, most python I know (I write), makes heavy use of python
lists.  Python lists are in essence arrays. Hooking up a
python-translator to a GUILE application will require lots of
expensive conversions This is my technical argument against
translators, but not my main point:

I see a lot more non-technical problems:

* What's the point in trying to do away with parentheses?  One of the
strengths of Scheme is that code = data, and data = code. How will you
achieve this with code coming out of a translator? By translating you
take away the biggest redeeming feature of Scheme.

* What does the Free Software World benefit from another version of
{Tcl|Perl|Python}?  The GUILE community only has a limited amount of
manpower. Why should it be spent on writing clones of tools that have
perfectly working free alternatives?

* I fail to see where the fun is in developing a translator: suppose
someone are knowledgeable enough about Scheme to write a translator;
do Scheme hackers feel happy when working on something as ghastly as a
Perl or SH interpreter?

* Where is the benefit for the application developer in having
multiple extension languages?  From an software engineering point of
view, multiple components with similar goals (eg., different language
frontends), are a bad idea. In my role as a developer, I would demand
that extensions be written in only one language, just for the
maintenance aspect.

* Finally, where is the forward looking vision in translators?

Firstly, writing translators amounts to chasing the tail-lights of
communities with more speed and more inertia. Secondly, giving users
ways to extend their application with tcl or perl invites them write
even more perl or tcl, and the world will be stuck with more gory
code.  Is that really what we want?

Scheme itself may even suffer from a lack of vision.  Some fellow
researchers over here have been trying to indoctrinate me, with
limited success. If I'd believe them, the next wave for extension
languages, are strongly typed functional languages like ML, CAML,
Haskell, etc.  They may be right, but it 'll them take some years to
get there. Even if they are right, not all is lost: during those years
guile could serve a useful goal.

>We've already decided to do things this way.

As I explained in this post, I think that translating languages into
each other for extension purposes misses the point, and I can't
imagine people wanting to write nor to use translators.

Basically, I think it is a bad idea. Maybe you should reconsider the
idea.

I think the GUILE community should work focus on improving other
aspects of GUILE (issues 1 to 5), or at least the public perception of
those issues.

The best to do that is to show how small yet powerful and elegant an
application with LISP inside can be.

For instance Sawfish is doing lots of good for the public perception
of LISP (and hence for GUILE).  It's too bad that the space for window
managers has already been taken from GUILE, but maybe we can show the
power of GUILE with another application. That will accomplish much
more than any kind of translator will ever do.

My hand has started hurting; I'll stop here.



-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl    | http://www.cs.uu/~hanwen/




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]