[MUD-Dev] Re: J (was: Re: 16K mud server competition !)

[Cynbe ru Taren]

Miroslav Silovic <silovic at zesoi.fer.hr>

| Cynbe ru Taren <cynbe at muq.org> writes:
| 
| > Optimal solution is probably a language like J, Haskell or teco
| > that is more about conciseness than efficiency. :)
| 
| *grin* I *hope* you meant to say 'readability' rather than efficiency.

Well, 'conciseness' is objectively measurable, 'readability' tends to
be somewhat in the eye of the beholder. ;)

I know math types who insist the important thing is that the entire
program fit in one screenful, so you can study it without flipping
back and forth.

The result is not in the usual C tradition of readability -- to put it
mildly! -- but it works for them and is very much in the mathematical
tradition of terse proofs that leave out all the discovery process.

Since it does work for them, so I don't feel free to say the result is
"unreadable" -- but I sure don't think it scales to megaline C programs!

I think the J crew's notion of readability is very much in the above
mathematical tradition rather than the C tradition.  Not surprising
given that it was designed by Iverson, a mathematician, and was
originally for teaching math (computer implementations of APL came
later as an afterthought, if I understand correctly.)

Haskel (and Lucid and ...) seem to me attempting to be attempting
scale the J/math sort of esthetic to larger programs: Many very short
equation-style chunks of code rather than page-size procedures.  I
think the jury is still out: It is taking a long time to develop, but
it is an ambitious, even audacious, effort.

It is possible to experiment with similar ideas of suppressing such
syntactic noise as explicit loops, explicit loop variables, and
explicit subroutine parameters within the context of more conventional
languages, with the idea of reducing the amount of junk syntax the
reader has to wade through to get to the essentials of the
computation: I think this is worth experimenting with, albeit far from
a guaranteed win.  (E.g., parameter names provide useful documentation
-- eliding them can mystify rather than clarify, often as not.
Perhaps one has to learn when to elide, and when not to?)



| I heard of J before and your post finally got me to read the docs. J
| is somewhat more powerful than Perl, and somewhat less readable than
| Intercal. Rather interesting language, in other words. ;)

*laugh*!

Writing enough code in J to absorb the paradigm would certainly
teach one a deeper appreciation of programming, whatever one's
ultimate conclusion!

I keep hoping to find a good excuse to do this.  A mathematician
friend advised that J is a great way of rapidly whomping up test
datasets for statistics and graphics programs, maybe I can try
it for that next time I take a serious whack at 3D graphics...




| Seriously, I haven't read the contest rules yet, but I assume they
| limit the language selection. Otherwise, you can just write a MUD in
| Java or Common LISP (The Language With Everything On, or Did You
| Really Think That -Emacs- Was Big? or MMap Twenty Megabytes On
| Startup), and use all the available libraries for these languages - as
| a result, you'd get really small code indeed, and it'd want to link to
| megabytes of runtime environment.

Hey, I like CommonLisp!  It is reassuring to know that in an
emergency, you can heat your house through the winter by burning the
reference manual a chapter at a time. :)

I'm actually basing Muq's semantics on CommonLisp, and hoping to work
up gradually to a reasonably full implementation of it as one of Muq's
supported languages.  (Looks like Python comes first though!  More of
a weekend project than a decade one. :)

I wonder how much bigger CommonLisp really is than Perl or Java or
Smalltalk or emacs or whatever, in these days of bloatware hosted on
gigabyte PCs?  I note the emacs executable I'm typing this in is
nearly 3meg, and the standard .elc files (without anything fancy
like calc) for it run another 9meg.  A 12Meg program calling a 20Meg
program bloated?   Sounds like the pot calling the kettle black... :)

I'm not sure the CommonLisp (or whatever) libraries would actually
save you a lot of code when writing a mud, though.  Sure, you get
I/O in roman numbers and hash tables and such for free, but...



| Also note that they rank the entries by maintainability, which rather
| limits the use of C obfuscators (or J, for that matter).

Well, given that the judging is (I presume) by C programmers and by C
cultural standards.  A committee of SML or J hackers might beg to
differ?  There -is- life beyond the C Corral, still even if it is a
pretty sparsely settled frontier compared to the urban sprawl of the C
world... :)

  Fair skies and warm winds beneath your wings,

    Cynbe



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev