low-level approach

[Brian P Templeton]

Kyle Lahnakoski <kyle@arcavia.com> writes:

> The reasons for a particular language preference appear to be lacking in
> the TUNES discussions.  I would like to see more detail on the benefits
> of a
> language that is claimed to be better than another.
> 
> For instance, I doubt that Lisp is a superior language to Java or even
> C. I would rather accept that it has certain aspects that make it
> superior.  The separation of a language into it's semantic aspects allow
> the TUNES community to see the benefits of these aspects and be able to
> construct a better language that contains them all.  
> 
If Lisp (what dialect? Common Lisp? Emacs Lisp? Dylan? Scheme? EuLisp?
ISLISP? XLisp? XLisp-Stat? ...) has ``certain aspects that make it
superior [to Java or C]'', then it is /ipso facto/ superior to Java or
C!

However, you later seem to indicate that you mean that no language is
syntactically superior to another - but you fail to define `semantic'.
Where does syntax end and semantics begin? By the time you mention
that Lisp doesn't use traditional-style infix syntax (where a few
operators are infix and function calls are prefix), but rather uses
prefix syntax, does that demonstrate that Lisp isn't as strongly
biased toward certain operations? When you explain that Lisp programs
are not simply streams of characters, but rather print representations
of objects that are read back in and evaluated, and therefore Lisp
programs may be considered sequences of objects, does that imply that
metaprogramming is easier with Lisp than the other languages? If you
want to discuss semantic aspects of languages, then define `semantic'!

> Ultimately all language aspects compete on the field of semantic
> efficiency.  It is important that each of these aspects are demonstrated
> in a code example to show their semantic efficiency.
> 
> For example, the difference between C and Java can be summed in three
> aspects:
> 	Java has garbage collection
> 	Java has inheritance (limited polymorphism) 
> 	C has function pointers
> 
> The advantages of one language over anther give clues as to the aspects
> we would like to incorporate into our TUNES HLL.  My comparison gives a
> clue to the advantage of allowing function objects in Java "JPP - A
> preprocessor for the Java language" (use Google cache).  This new
> advanced Java is better than either language.  Now let me tackle Lisp
> and it's advantages over C and Java.
> 
> Note that I have limited experience in Lisp and Scheme (I am able to
> read them, but writing is another matter).  So this post will be the
> beginning of a two way discussion over the advantageous aspects of Lisp
> over Java and C.  Here is what I have come up with.
(assuming you're talking about Common Lisp here)
> 	All compound objects are treated as lists.
How do you define a compound object? Something other than a symbol,
number, or character, perhaps? Then you're incorrect.

> 	Function references, using quotation, are available.
Huh? Functions are first-level objects in CL.

> 	Lisp syntax is simple
Yes

> 
> The first advantage can be easily overcome by using library functions in
> any procedural language.  I have seen a comparison of Lisp (Prechelt?)
> to C
> and Java with respect to development time, with Lisp winning.  The
> positive result was a side effect of having a string intensive program
> requirement.  Lisp naturally handles strings, but Java and C require the
> developer to make/find good string libraries to compete.
> 
What? Lisp doesn't `naturally' handle strings. Lisp, to me, seems to
naturally handle sequences (lists, arrays, etc), dictionary-type
objects (alists, hashtables), and functions.

> The second advantage is significant compared to Java (as discussed), but
> not too significant with respect to C (which has function pointers). 
> Many Lisp "superiority" examples compare themselves to "equivalent" C
> programs, but I have yet to see one that does not use a deliberately
> verbose C equivalent.
> 
> The last, when combined with the second may be something significant. 
> It
> allows for dynamic specification of functions.  But it has been my
> experience that most dynamic function specifications are simply generic
> programming with partial evaluation.  C does this easily (albeit
> inefficiently).  
> 
I haven't yet seen lambda in C, but I may have missed some language
feature that makes it possible.

> The rare case of true dynamic function specification requires a compiler
> to be
> added to either Java or C.  Java has a minor advantage over C here
> because an object framework already exists that can support a dynamic
> compiler.  But even with a compiler, the simplicity of Lisp syntax
> allows for simpler automated specification.  Unfortunately, the case of
> automated
> function specification is so rare that I have yet to stumble across an
> example that exposes a Lisp semantic advantage over C or Java.
> 
> 
> SUMMARY
> 
> I have considered these aspects and included them in my own language
> specification, especially the step of simplifying the language
> semantics.  But my inexperience with other languages (such as Forth and
> Haskell) makes me unsure if I have included all the advantageous aspects
> from those languages too.  I would appreciate if the "experts" in these
> languages could come forward and describe the beneficial semantic
> aspects, and give examples if unclear.
> 

-- 
BPT <bpt@tunes.org>	    		/"\ ASCII Ribbon Campaign
backronym for Linux:			\ / No HTML or RTF in mail
	Linux Is Not Unix			 X  No MS-Word in mail
Meme plague ;)   --------->		/ \ Respect Open Standards