* ES (Mar 20, 2005 00:40):
> WTF is with the attitude?

Right back at you?  Sorry for being a dick.  I guess I should have
calmed down and thought my response through more thouroughly before
sending.

> > That's a rather weak statement.

> I think it's a pretty strong statement. 'Conceptually better' code
> tends to be easier to write and understand.

Yes, but just saying that it's conceptually better without giving a good
reason for it doesn't really mean anything.  Your solution for working
around the problem that the solution that you argue is conceptually
better just leads to another problem, a problem that so far doesn't have
an obvious solution (i.e., what is discussed below--how to check for
success).  So it doesn't seem to be conceptually better, at least to me.

> > > It could be given via the return value wrapped inside a
> > > MethodCallResult [sic] structure.

> > You're not using "sic" correctly.  You use "sic" when you quote
> > somebody elses writing that contains an error to make a not that the
> > error occurs in the original and that you know about it.  It is
> > often considered redundant, as you assume that your reader isn't
> > clever enough to understand that you probably quoted it correctly.
> > The "sic" is usually added to in some way discredit the source you
> > are quoting (and proving that you have nothing better to counter the
> > argument being quoted with than the person being quoted's ability to
> > write correctly).

> 'Sic', latin. Literally, 'thus'. It here indicates a sentiment similar
> to 'as it were'. You may be thinking of 'stat', which means 'so it was
> originally'.

No, that's not what I'm thinking of.  It is used precisely as I
described.  It is not, in English, used as you suggest.  I was not
trying to be rude by pointing this out.  I apologize if you thought it
to be so.

> puts "failed: #{$err}" failing line.strip!.downcase!.split //

> The separation is such a high-level concept that it's probably not
> possible to extend any existing language to take full advantage of it
> though a workable solution is quite viable.

Yes, but introducing additional language constructs to solve a problem
introduced by the solution of a, to me, non-problem seems very costly.

The best solution, it seems to me, would be to remove the destructive
versions of these methods.  I guess we're returning to the whole
immutable versus mutable strings discussion again.  Anyway, I'm not
advocating the removal of all destructive methods.  They're viable for
hashes and arrays, which can be very costly to create anew, but strings
are meant to be short by their very nature, as they are stored
continuously in memory, and can then be copied rather efficiently.  I
have suggested earlier that what we perhaps need is a second
string-like, or sequence, class that is better suited for doing a lot of
transformations.  I will try to put my money where my mouth is, but I'm
strained for time as it is.  I guess I shouldn't be spending so much
time trolling on this mailing-list...,
        nikolai

-- 
::: name: Nikolai Weibull    :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA    :: loc atm: Gothenburg, Sweden    :::
::: page: minimalistic.org   :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}