Should this work?

[Manu]

On 10 January 2014 15:48, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org
> wrote:

> On 1/9/14 8:21 AM, Manu wrote:
>
>> My standing opinion is that string manipulation in D is not nice, it is
>> possibly the most difficult and time consuming I have used in any
>> language ever. Am I alone?
>>
>
> No, but probably in the minority.
>
> The long and short of it is, you must get ranges in order to enjoy the
> power of D algorithms (as per http://goo.gl/dVprVT).
>
> std.{algorithm,range} are commonly mentioned as an attractive asset of D,
> and those who get that style of doing things have no trouble applying such
> notions to a variety of data, notably including strings. So going with the
> attitude "I don't use, know, or care for phobos... I just want to do this
> pesky string thing!" is bound to create frustration.
>

The thing is, that pesky string thing is usually a trivial detail in an
otherwise completely unrelated task. I'm not joking when I've had details
like formatting a useful error message take 90% of the time to complete
some totally unrelated task.
I guess I'm a little isolated from high level algorithms, because I spend
most of my time at the level of twiddling bits.

This is a key motivation for my kicking off this all-D game project, and
getting others involved. I need excuse to push myself to have more
involvement with these type of things. Doing more high-level code than I
usually do will help, and having other D users also in the project will
keep me in check, and hopefully improve my D code a lot while at it ;)

I personally find strings very easy to deal with in D. They might be easier
> in Perl or sometimes Python, but at a steep efficiency cost.
>
> Walter has recently written a non-trivial utility that beats the pants off
> (3x performance) the equivalent C program that has been highly scrutinized
> and honed for literally decades by dozens (hundreds?) of professionals.
> Walter's implementations uses ranges and algorithms (a few standard, many
> custom) through and through. If all goes well we'll open-source it. He
> himself is now an range/algorithm convert, even though he'd be the first to
> point the no-nonsense nature of a function like strrchr. (And btw strrchr
> is after all a POS because it needs to scan the string left to right... so
> lastIndex is faster!)


How long did it take to get him there? I suspect he made the leap only when
a particular task that motivated him to do so came up. I suspect I'm likely
to follow that same pattern given the context; like him, I'm a somewhat
no-frills practicality-oriented programmer, and don't get too excited about
futuristic shiny things unless it's readily apparent they can make my
workload simpler and more efficient (although I would also require it not
sacrifice computation efficiency). But my point remains, as a trivial
ancillary detail - I'm not doing stuff with strings; I'm working on other
stuff that just _has_ some strings - it's not presented in a way that one
can just get the job done with low friction, and without at least tripling
the number of imports from the std library.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140110/b5c0677c/attachment-0001.html>