Hi again, Ladislav and all
Joel Neely wrote:
> Hi, Ladislav,
>
> I did a bit of benchmarking with functions that use each of the three
> strategies ...
>
> There's one final point, but I'll post it separately.
>
This has been very interesting, and your parse-based solution is an
*excellent* illustration of thinking with series-level operations
instead of element-level operations -- a classic bit of REBOL-style
thinking IMHO.
Perhaps I should blame my illustration that started this -- or how I
explained my request for alternative solutions -- because I was trying
to focus on a different issue than histograms! (although it DID have
to do with language thinking styles ;-)
The design of every language with which I'm familiar reflects at least
two issues: the conceptual model used by the designer(s) (or lack
thereof!) and the decisions about what things to make easy for the
programmer using the language.
Both Perl and REBOL make it easy to use a "variable" -- you just start
using it and the language keeps up with what you're doing; no advance
declaration is required. OTOH Java makes it easy to detect errors in
type mismatch as early as possible (at compile time), which REBOL and
Perl can't catch until the program is running.
Perl goes further and makes it easy to use data structures; if you try
to modify/store data, the appropriate "place" is automagically created
(and initialized to an appropriate value, depending on the operation
you are performing). The Perl expression
++$array[$n]
means "add one to the nth element of array". If the array doesn't have
n elements (or if the array doesn't even exist!), Perl will allocate
that position and and initialize it to zero before evaluating your
expression.
REBOL seems to occupy a middle-ground position on this issue; it does
not require you to declare the existence of a data structure (as e.g.
Java does) but it *does* require that you allocate and initialize it
explicitly. REBOL certainly has some nice built-in facilities for
processing series data, but once you leave those you are *really* on
your own. My original dinky demo was intended to compare that one
expression above with
insert/dup tail tallies 0 score + 1 - length? tallies
change at tallies score + 1 1 + pick tallies score + 1
or
either found? here: select tallies score [
here/1: here/1 + 1
][
append tallies reduce [score copy [1]]
]
which are the equivalent in REBOL (given that it's the programmer's
responsibility to allocate and initialize the tally structure).
Of course, I'm well aware that I could initialize the tally structure
for e.g. all "key" values between 0 and 100 as a way to avoid the
dynamic initialization issues above... (But my experience tells me that
as soon as I do that, some teacher will add an extra credit problem so
that some students can score 110! ;-)
Language design decisions have far-reaching (and often subliminal)
effects on the subsequent design thinking of programmers using the
language(s) in question. One such issue that I find interesting is
the question of when I -- as the programmer -- must commit to a
decision regarding the data structures used within my programs.
COBOL and Pascal require that I commit to the type and size of every
array before submitting my programs to the compiler, and initialize
the structures appropriately (at run time, but before any other use).
Java requires me to commit to the type of an array, but lets me defer
the size committment until run-time when I actually initialize it.
Newer versions of Java provide the Vector class, which can be thought
of as an array that can change size during use. Perl and REBOL (and
Python, et cetera) arrays/blocks not only let me dynamically resize
during use, I don't even have to commit to a single type of data to
put there! Finally, (back to the original discussion) Perl will even
automatically figure out when to allocate/initialize structures and
elements for me.
Advocates of each of these languages will offer passionate arguments
for why the binding-time choices of their preferred language are good.
As a polyglot, I'm less interested in picking sides in a political
debate than understanding deeply the effects on my own thinking when
I begin to "think like a native" in one or more of them.
-jn-
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
