Re: [ANN] Underscore.lua 0.3

[David Kastrup <dak@...>]

steve donovan <steve.j.donovan@gmail.com> writes:

> On Mon, Dec 7, 2009 at 1:27 AM, Marcus Irven <marcus@marcusirven.com> wrote:
>> Announcing Underscore.lua -- http://mirven.github.com/underscore.lua/.
>> Underscore.lua is a utility library with 30+ (and growing) functions that
>> can be used in a functional or object-oriented manner.
>
> Nice, a well-chosen set of functionalities. I like how you've provided
> some aliases.
>
> I quote:
>
> _.({1,2,3,4}):chain():map(function(i) return i+1
> end):select(function(i) i%2 == 0 end):value()
>
> First random observation: Lua people tend to use '_' as a throwaway
> variable, in cases like 'local _,i2 = s:find('%s+')'.  But it can
> always be aliased if necessary.
>
> Second, support for 'string lambdas' would be cool:
>
> _.({1,2,3,4}):chain():map '|i| i + 1' :select '|i| i%2==0': value()
>
> There's a slight hit to compile them, but thereafter they can be
> easily memoized. They don't require any syntax enhancements so David K
> can only have style objections ;)

David K has no power apart from his loud mouth.

For an interactive shell like the GSL shell, shortcuts are certainly a
life saver.  You want as many of them as possible.  No objection.  For
writing programs, things are different, because programs are not
write-only.  You read them much more often than you write them.  If you
see people reinventing the wheels in a programming language, the
language is deficient for the purpose for which it is used.

For example, C is deficient for numerical computation primarily because
it does (in its commonly employed language versions, existing code bases
and mindshare) not have dynamically sized arrays, no multidimensional
arrays, and because the arrays it has have intermingled semantics with
pointers, making them subject to aliasing, prohibiting a lot of
optimizations.  As a result, numerical libraries for C/C++ all have
their different incompatible array implementations.  While recent C
standards address these issues somewhat, only specialists will be able
to write code that stands a chance to be close to optimal, and
interoperability remains optional.  Fortran is much better for numerical
code, not because it is a great language, but because the most
simple-minded code a good mathematician and lousy programmer will come
up with tends to optimize well and integrate nicely with existing
libraries.  Recent Fortran standards have not extended Fortran's market
niche significantly in real life, recent C/C++ standards did nothing in
their area.  Because they are late in the game.

Lua is a great base for things like the GSL shell.  Or for functional
programming platforms.  But it is a great base for a lot of things, and
keeping the base clean is important to have it as a minimal building
block suitable for tasks of different focus and style.

To have something like token filtering for application building is a
great idea.  Especially when we are talking about interactive
applications.

But a program that is supposed to interact with other basic Lua programs
outside of such a special application context should not rely on syntax
trickery specific to some application realm.

Putting things like |i| i + 1 into strings does not change what they are
intended to do.  When a system keeps shuffling with those things, it
might be a better idea to let it deal with those things naturally.

But there is always a price paid for tampering with syntax: all existing
tools are affected with regard to parsing and understanding and
indenting code.

Moving everything inside of strings only helps superficially: once the
main structure of the program is inside strings, the editing, parsing,
indenting, highlighting tools don't do any work on the actual program
logic.  While they are able to keep doing their job with confidence,
their job has become unimportant.

I'm fine with extending Lua's syntax, but its main application should be
creating special-purpose static languages.  Syntax that shifts at
run-time is a nightmare for stable systems.  I'm coming from a TeX
background, and that's one lesson in the TeX programming frameworks.

-- 
David Kastrup