Re: OT: Programming Languages (Was: Phoneme system for my still-unnamed "Language X")

Hello!

On 9/9/05, Henrik Theiling <theiling@...> wrote:
> "Julia \"Schnecki\" Simon" <helicula@...> writes:
> > On 9/7/05, Henrik Theiling <theiling@...> wrote:
> > >...
> > > Originally, I wrote the four vowel phonemes /a i u @/ as <a i u e>,
> > > but then I decided that at some time in the future, I want to use <e>
> > > and <o> for allophones of /i/ and /u/.  It's not implemented in Lisp
> > > yet, but planned.  Anyway, that's why I used <y> for /@/.
> >
> > Ah, so you use Lisp for your conlang-related programming. Does this
> > language have any specific advantages that make it especially
> > well-suited for language (or more generally, string) handling?
> >...
>
> String handling alone is much better/easier in Perl.  (Common)Lisp is
> very nice because it can handle symbolic information so well.  It's
> perfectly suited for programming grammars (generators) or parsers.
> The string handling is not particularly clumsy or the like, but if you
> need regular expressions, you'd better you Perl for that part.
Ah. So string handling feels easier with Perl than with Lisp because
Perl lets me use all those nice regular expressions (which I love, by
the way), and not because I'm too stupid for Lisp or something like
that. ;-)

(In the olden days, when I was faced with the decision which of the
various "<programming language> for computational linguists" classes I
should take, the alternatives were Lisp and Prolog. I took Prolog,
which, like Lisp, is quite good for handling symbolic information but
somewhat less good for string handling. I guess they wanted us to
learn how to transform predicate logic into bits and bytes, not to
teach the computer German strong verb inflection patterns... which is
what I ended up doing a few years later (in a different programming
language, though). Go figure.)

> CommonLisp is also nice because it encapsulates the gory details of
> the computer hardware so well: the Integers are arbitrarily large (ok,
> memory limits them...) and you won't be confronted with the limits of
> the real hardware often (in Perl, the ints are 32bits and in C, you
> need to know that Strings are quite different from Ints).
>
> Furthermore, Lisp's special syntax (that many people dislike) makes
> code quite indistinguishable from data.
Yes, I've noticed that... ;-)

> You must be careful with
> this, you get spaghetti code easily, but it has advantages, e.g. after
> writing a lexicon file, you can decide to preprocess every entry on
> the fly on loading and implement this by re-defining a single
> function.
Nice! :-)

> This structure also made me programm an HTML-preprocessor in Lisp in
> order to make Conlang web-pages: the whole page is programmed as a
> large Lisp expression and then HTML is computed from that.  It looks
> just like a Lisp data expression, while in fact, it's an actively
> running program.  No parser for the preprocessor needed -- Lisp is my
> parser.  The advantage is that I can write new 'macros' that actually
> callback by Conlang grammar and computed the correct forms on the fly.
> So just like (b "this is bold") I can write (phonemic "hEnrIk") to
> generate /hEnrIk/ (including translation from CXS to IPA) or I can
> write
>   (s7-text-box1
>       (clause 'perception
>          head-read
>          (clause 'pat stem-book)
>          (clause 'agt (s7-name "Mary" '(ng a x i)))
>       )
>       "Mary reads a book."
>   )
> to render a sentence in Qthyn|gai. :-)
*sigh* I think I need to move Lisp *way* up on my list of fascinating
things to do...

> And due to the hierarchical arangement of data types and due to the
> careful design of the internal functions' parameter types, it took me
> about 30 minutes to port that experimental framework from normal
> strings to full Unicode support + own extensions -- I just changed
> string to vector of arbitrary type and only had to fix very few code
> lines.
>
> Anyway, it's not a modern language, so it's not type-safe, and even
> uses dynamic typing, to does not do type inference and you often get
> *very* cryptic error messages that look a bit like: ,your program is
> no good, please rewrite'.  You need some discipline to write nice
> programs because it allows so much.
Don't worry about the error messages. One of the databases I'm using
at work (or at least its error messages) seems to have been designed
by the same person as those Lisp error messages, so I'm quite used to
that kind of thing. ;-)

> I should add that for my private programming, I usually use a mixture
> of C++, Perl and Lisp -- whatever feels more appropriate.  None of
> those is a modern language, but I'm still quite satisfied with that
> constallation.
Just like with me and my AWK; it's not the most modern of languages,
but I know it well, and if it does the trick, why spend much time and
effort on something else? :-)

Regards,
Julia

--
   Julia Simon (Schnecki) -- Sprachen-Freak vom Dienst
_@"  schnecki AT iki DOT fi / helicula AT gmail DOT com  "@_
si hortum in bybliotheca habes, deerit nihil
                                        (M. Tullius Cicero)