Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[data structures] (was Re: [append][series]Appending to a series of str

 [1/1] from: joel::neely::fedex::com at: 20-Nov-2003 16:08

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-