On 8/19/2011 11:05 AM, DeNigris Sean wrote:
Alan,
I'm thinking more deeply about computers and language and have realized that,
after programming for 15 years, I still have no idea what I'm talking about :)
just offering my opinions here.
but, yeah, maybe many of us don't really know what we are talking about.
I think the problem is that it is very hard to know in advance what is
best or how things will go, so better probably to try out ideas and see
what all works and doesn't work, and use these to guide and refine
possible future technologies.
After reading many of the LISP suggestions (thanks), the primary features seem
to me to be:
* parsimony (again you got to me and I finally looked it up;
"extreme unwillingness to spend money or use resources")
o little syntax - you can learn the language in 5 minutes
o uniformity - everything from variables to procedures are
treated the same.
both points are "double-edged swords" though.
the minimal syntax makes many constructions overly verbose and
operations are often not "visually distinctive", which slows down
reading and thinking about code (the contrast is a "glyph soup"
strategy, where particular glyphs/operators/... will more often stand out).
granted an "ugly mass of glyphs" is not exactly an ideal strategy either.
building on common experience is another possibility to reduce the
learning curve (many things will retain a familiar look and feel), but
granted a strict/dogmatic adherence to convention might be overly
limiting, so there are tradeoffs.
uniform treatment of variables and functions also has good and bad
points. for example, it is possible to easily get/set methods, ... which
can be very useful.
some languages, such as Java, lack this ability (ability to get/set
functions or methods), and it is painfully obvious from the POV of
someone who is used to languages with this capability (namely: most
non-Java languages...). (having to use an class instance for sake of,
say, a callback, is just nasty...).
( Java then had later added anonymous classes/... to partly work around
some of this, but personally I feel that using anonymous classes to make
up for the lack of first-class functions/closures and ex-nihilo objects
and similar to be "not a very good strategy". )
a downside though is that most languages don't generally support
overloaded variables, meaning that the uniform treatment of variables
and methods will often come at the cost of being able to overload them
(may be hacked around, but often these have worse drawbacks).
a common result is that assignable functions are often explicit in the
language and may not be overloaded, and that typically getting a
function handle will require it to not be overloaded (more common, say,
in C++), or require an explicit cast to indicate the desired signature (C#).
a downside of C and C++ style function pointers is that they don't
(generally) capture binding state (nevermind GCC and C++0x, which add
support for "closures", but which are limited to the lifetime of the
parent scope). sadly, general-purpose state-capture then requires using
an object.
however, in the common case of using function pointers to implement
getable/setable methods, the lack of state capture isn't too much of an
issue (hence, C++ ends up still being somewhat more convenient than the
level of hassle required to do similar in a language like Java).
* power - a meta-system where you can change anything e.g. the order
the arguments are processed in, what syntax is legal, etc.
yep, this is a nifty feature.
sadly, the Lisp macro system is not something which can be faithfully
done in notably different languages.
another biggie problem is that a lot of this may conflict with the use
of late binding (and a delegation-based scoping model), since by design
macros have to be early-bound, making them potentially a "sore thumb" in
a language design sense.
they may also risk exposing some implementation "nastiness", or may be
used in confusing and/or counter-intuitive ways (since there may not be
any obvious way to tell them apart from built-in functions or similar).
some of what could be done in using macros can be done in my case using
the "quote" and "unquote" keywords, but these are sort of a "lame joke"
vs macros.
for example:
unquote foo(quote x+3);
would be (sort of) similar to:
(eval (foo '(+ x 3)))
although possible could be to do similar with the syntax:
foo<x+3>;
I don't really like this option (I don't really like the <...> syntax
for sake of it creating ambiguities).
"foo!(...)" or "foo![...]" could also be possible.
also:
"foo:(...)" but this would create a whitespace sensitive operation.
"foo::(...)", could also work, and is not *too* ugly.
note that, ideally, this would be a cached operation, rather than
naively rebuilding the code-fragment on every execution (or being a "one
off" static operation), but this leads to another problem:
how to make this semantically-transparent?... (I lack ideas for an
obvious flushing/invalidation mechanism in this case).
this could lead to several edge cases:
a case where it is preferable to have it be one-off;
a case where it is preferable to dynamically re-build the expression.
* I'm not sure where, if at all, security comes in
doesn't really appear to me that Lisp was really designed with security
in mind.
<snip>
I can't really comment on a lot of this (too far outside my area).
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
