Re: left, right? head, tail? which one?
Mike777 wrote:
>
> Matt Lewis wrote:
> >
> > Jeremy Cowgar wrote:
> > >
> > }}}
<eucode>
> > left("John Doe", 4) -- "John"
> > left({{1,2},{3,4},{5,6}}, 2) -- {{1,2},{3,4}}
> > right("John Doe", 3) -- "Doe"
> > tail("John Doe", 3) -- "Doe"
> > pad_left("ABC", 6) -- " ABC"
> > pad_head("ABC", 6) -- " ABC"
> > pad_tail("ABC", 6) -- "ABC "
> > trim_tail("ABC \r\n\t", 0) -- "ABC"
> > trim_head("...ABC", '.') -- "ABC"
> > trim_head("\r\t\nDEF ABC", "\tFD\n E") -- "ABC"
> > </eucode>
{{{
> >
> > My thought is, "Is there really a need for this stuff?" There are better
> > ways to do this in euphoria. This seems like a very BASIC-y way to do
> > things. I don't think we should include this in the standard library.
> >
> > Well, the trim stuff is useful, but should probably live in string.e.
>
> Somebody earlier stated that they were probably the least competent Euphoria
> programmer commenting here. I beg to differ.
>
> With that in mind, sometimes the "old" way of doing things is the best way as
> it leverages prior knowledge, lowers barriers to understanding and generally
> makes the language easier to propagate.
>
> Unless there is a compelling reason to use a descriptor which is different,
> I would argue for using the BASIC-y way of doing things. That is, if the
> descriptor
> is perfectly apt when dealing with strings, let the standard be that anything
> which does work with strings also will work with sequences.
>
> It has taken me a while to get my head around the overloading of the sequences
> type with both strings and sequences (oh, if I had a nickel for each
> compilation
> that resulted in the "sequence found within character string" error). But now
> that I have, I don't want to forget the fact that this most elegant of
> features
> is, as the documentation says, "IT" and that just because the documentation
> says it doesn't mean that the reader actually GETS it until later. In my
> case,
> MUCH later.
>
> With that said as more background, I'll restate the above in the following
> manner:
> for each function I can immediately understand because it is BASIC-y, the
> barrier
> for me to adopt Euphoria for my programming needs lowers. The best way to
> communicate
> that to the EU newbie is a name which is both familiar and apt.
>
I'm sorry, but how many people today (not back in 1993) come to Eu after
non-Visual Basic? My guesstimate is 0.
What had attracted me in the language, in spite of all its drawbacks, is the
intuitiveness of sequences. I have read some stuff about it being hard to hrasp,
all right, but I simply don't understand what the problem is, and hence of how to
alleviate it.
You know, Windows XP comes with some version of Python. Lots of newbie
programmers will start, and have started, with Python. If they later come to Eu
because of the simplicity/performance mix, they won't be newbies in programming
any more. Add in a few that started tinkering with VBA/VBE at the office. Sure,
it's Basic, but already object Basic. And again, if these people come to Eu, it's
because they understand what they are doig, so are not real newbies.
In a nutshell, I think that centering on what newbies are supposed to understand
easily or not is not the right target for Eu, since people ocoming to it nowadays
are usually not newbies in programming.
CChris
> Please don't interpret the above as saying you should always use names that
> are archaic. New concepts scream out for new descriptors. Hacking the first
> few things off for later use (or the last) is about as basic (not BASIC) as
> one can get.
>
> Mike
|
Not Categorized, Please Help
|
|
