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

[Miroslav Silovic]

Cynbe ru Taren <cynbe at muq.org> writes:

> | *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. ;)

Well, efficiency refers to runtime speed or memory
profile. Conciceness is the source size. I guess you meant the
latter. :)


> 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.

Hmm, -I-'m a Math type. And I know how to use scrollbars.

But a friend of mine did write code like that (in C, and he's a
physicist) - no indentation, lines are just stuck together till they
fill the row (or several rows), then he'd put a newline and continue.
Needless to say, his code was not exactly maintainable, not even by
himself. Incidentally, he learned programming on a TinyMUSH.

> 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!

It doesn't. :) Note that programming language you'd put on your
calculator isn't designed along the same constraints as the language
you'd use to write 1,000,000 lines of code that don't just fly apart
the moment you try to run them. J is much like the former - I'd use it
to quickly generate a dataset, too (that replies to your friend's
comment below).

> 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?)

Okay, so the first question I ask before using a new language is 'does
it support closures and higher order functions?' (since my idea of fun
is to write 100 lines of code that consists of a dozen lambdas that
fling other lambdas at each other).

For example, to parse English-like syntax with full
(context-sensitive) backtracking, you could do the following (in
untested Scheme, and the input is a sentence given as a list of
symbols, for quicker dictionary lookups):

(define (nounp word)
	(memq word '(table chair apple red)))

(define (adjectivep word)
	(memq word '(white blue big small red)))

(define (adverbp word)
	(memq word '(quickly slowly)))

(define (match-noun-phrase prefix cont)
	(if (nounp (car sentence))
		(cont (cons (car sentence) prefix) (cdr sentence)))
	(if (adjectivep (car sentence))	
		(match-noun-phrase (cons (car sentence) prefix) (cdr sentence) cont)
		#f))

(define (match-near-object sentence cont)
	(match-noun-phrase sentence
	    (lambda (phrase rest)
		 (if (match-environment phrase)
		     (cont phrase rest)
		     #f))))


etc. Note that you pass the sentence snippets to the continuations
(explicit ones, in this case, not the ones created from call/cc) and
that simply by returning #f (FALSE), you can initiate a backtrack
(since the check-condition-and-pass-to-another-lambda pattern acts
like a stack machine, but on the source level, it keeps each parsing
bit sequestrated within its own function).

> | 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 actually considered implementing J<>guile or J<>TOM translator, out
of sheer perversity. But most of J is syntactic sugar over a largish
runtime lib - I prefer the languages where runtime library actually
-is- a bloody library.

> 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...

I did my share of 3D graphics in guile. It was fun. :)

> | 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! 

Yes, me too. See my other post.

> 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. :)

*grin*

> 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. :)

For a single person, it's more of a lifetime project, if you want a
decent, compiled, *optimized* implementation. :)

For example, ANSI CL commitee had to deal with queries from CMUCL
people like:

Can we optimize 2 + MINFLOAT - 2 to MINFLOAT? I.e. is float considered
to be discrete or continuous datatype?

Or CMUCL mailing list discussions on what *exactly* can be inferred
about result types of trancedent functions in certain boundary cases
of their (complex) arguments.

After seeing -that-, you learn about fear. :)

> 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... :)

It's not that much bigger, nowadays. That's why I put Java and
CommonLISP in the same sentence (and that's why I try to avoid both).

> 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...

I implemented Common LISP's format in TOM in 1500 lines, or about 30kb
of source, that compiles into 30kb of .so - I just ported the
implementation from slib (which is around 1600 lines, or 55 kb of
Scheme). Good hashtable implementation is a few killos of C. So, no,
that wouldn't save you much code.

CLOS and its MOP, on the other hand...

But currently I'm not aware of a fast, compiled, well optimized, free
CLOS.

> 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... :)

You misunderstood me, I think. It'd be likely that the language would
be limited to C because C is probably the most verbose language you
could choose for a fixed level of maintainability (apart from
perversities - I -do- know a guy who won a bet by writing a chess
program in COBOL) - mainly because you can't count on a rich set of
standard runtime libraries that other languages try to serve to their
users (in hope of a wider public acceptance, no doubt). So, not using
C would probably give you unfair advantage if C -is- the required
language.

A 16kb MUD in obfuscated Perl (with builtin dbm, and modules for
networking and possibly ANSI/curses support) would make a of sense.

I wonder about 16kb of a Common LISP format string that'd be a
MUD... :}

--
How to eff the ineffable?



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