This is the mail archive of the guile@cygnus.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]

Re: Scheme is too complicated



> >     When Maciej started on turning FVWM into SCWM, he noticed that a
> >     lot of things got simpler, because Guile had real arrays,
> >     conditionals, variables, etc.  There was a lot of grunge in the
> >     FVWM configuration language that just went away.
> 
> I don't think anyone has ever held up fvwm as a paragon of simplicity
> in terms of its configuration:->  OTOH, I wonder if it may not have
> been easier to do using something like Tcl (no gh_enter...), which
> would more closely mirror the program flow of the original code.  In
> any case, the fvwm config thing isn't quite a language in the sense
> that even tcl or php are.

This is another interesting point.  Whenever you hear someone say, "We
don't need a full language here, it's just a configuration script",
you want to get really suspicious.  History is littered with examples
of little config languages (repeat after me: "We don't need anything
too complicated") that go awry.

The thing is, the people who say that *are* making a reasonable
choice.  They don't care about writing an interpreter, they want to
write an app, and they should focus on the app.  It's smart.  Writing
an interpreter is a big distraction.

The whole idea of Guile, and Tcl, is to support that choice.  You
shouldn't have to invest time in an interpreter --- you should just
link against Guile or Tcl.  You write your app to check Scheme-visible
variables, call Scheme hook functions, and so on.

My argument is that, by using Guile or Tcl, you actually spend *even
less* time on the configuration language than you would if you rolled
your own "simple" configuration file parser.  Guile and Tcl have the
parser done for you.

(I admit, I'm neglecting the time you spend learning Guile.  That's a
one-time cost, but still...)


So, my thesis: If you know your application is going to suffer from
creeping featurism, you should plan for it.  Doing a "simple"
configuration language is a cop-out, and you will actually waste time.
Learning time aside, using Guile or Tcl is less work, even in the
early stages.



> > A simple language does not mean that the code you write in it is
> > simple.  Your application doesn't need to get very complex at all
> > before you begin to appreciate local variables, functions, and data
> > structures richer than strings.  When you need a feature missing from
> > the language, you have to work around it, which can complicate your
> > code quite a bit.
> 
> To be fair, even PHP and Tcl have those things, even if they are
> hacks, in a certain sense.

Right --- I actually get funny looks when I say this, but I think that
Tcl is actually a nice language, given its basic assumptions.  But the
limitations do hit you --- like, you can't put a pointer to something
in a Tcl list; you have to name it, and then put the name in the list.
And the way you pass arrays to functions is so bogus.

I haven't actually learned PHP; I've just looked at someone else's
code.  I think I'd get annoyed with it pretty darn fast.


> >     A year or so ago, my friend Noel Cragg used PHP to whip up an
> >     entire ISP account and bug tracking system, in a weekend.  Clearly
> >     a success story for PHP (and Noel).  But he had to do some really
> >     gross trickery to report the (sometimes large) SQL query results
> >     back to the PHP code in a way it could handle.  If PHP had had
> >     reasonable datatypes, this wouldn't have been an issue.
> 
> Data types such as.. ?  I'm not a big fan of PHP, I think it would
> have made more sense to at least reuse Perl, Tcl or Python, but it
> does seem to work ok for web stuff.

I'm going to have to back off on this, at least for now, because my
reasoning goes: "Noel is a bright guy.  He did this in a circuitous
way, because he says he had to.  So he must not be getting the support
he needs from the data system."  I'm not actually reasoning based on
facts about the two languages, so I'm not making much of a
contribution there.

> > As a program with a simple scripting language ages, people inevitably
> > want to do something that doesn't fit inside the language.  The
> > maintainer certainly wants to accomodate the users, so he or she makes
> > a small extension to the language for the specific need, instead of
> > strengthening the language so that the users could have coded it
> > themselves.  Repeat this cycle for a few years, and you've lost your
> > original simplicity, and you are *still* in the trap of making little
> > extensions here and there, so your complexity is only going to go up.
> > And now it's almost too late to strengthen the language, because the
> > small extensions have complicated it so much.
> > 
> > Examples, off the top of my head: the POSIX Bourne shell, Perl, make,
> > sendmail, FVWM, the Tcl 8.0 Object API (Tcl itself is still quite
> > clean for its age).
> 
> By Object API, do you mean the C API, or Object Oriented Tcl?

I mean the functions in the Tcl 8.0 C API with Object in their name.
Tcl supports the old API too.