Should this work?

[H. S. Teoh]

On Fri, Jan 10, 2014 at 04:37:03PM +1000, Manu wrote:
> 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.

You have to be doing something wrong... formatting error messages is as
trivial as using std.string.format:

	if (argsAreBad(x,y,z))
		throw new Exception("Parameters x=%s y=%s z=%s are invalid!"
					.format(x,y,z));

I can't imagine what can be simpler than this. (Not to mention, %s in D
just means "string format of X", so the above code will actually work
for x, y, z of *any* type that has some kind of conversion to string.
Try this with C/C++, and you'll be segfaulting all day.)


> I guess I'm a little isolated from high level algorithms, because I
> spend most of my time at the level of twiddling bits.

That would explain your difficulty with Phobos algorithms. :)


> 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 ;)

Well, maybe the reward of not having to grit your teeth everytime you do
string manipulation in D will motivate you to learn how to use Phobos
effectively? :)


> > 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).

I'm not the kind to get excited about futuristic shiny things either...
I don't even use a GUI, for example! (Well, technically I do, since I'm
running on X11, but it's so bare bones to the point that my manager is
baffled how I could even begin to use such an interface. I barely ever
touch the mouse except when browsing, for one thing. Almost everything
is completely keyboard-driven.) And I'm also skeptical of new trendy
overhyped things that has people jumping on the bandwagon by droves --
and usually it turns out that it's just another ordinary idea blown out
of proportion by the PR machine.

Yet I had no trouble getting up to speed with Phobos algorithms.  I
*will* say there's a learning curve, though -- you need to understand
what ranges are and why they're the way they are, before you can fully
grok Phobos algorithms. Andrei's article "On Iteration" (linked from the
std.range docs) is almost a must-read. But IMO it's more than worth the
time to learn this. It will revolutionize the way you think about code.
;-)


> 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.

But that's the thing, if you have some level of facility with ranges,
you could be using exactly the same algorithms for your other stuff as
you'd use for strings. That's much less mental overhead than having to
remember one set of API's for manipulating said other stuff, and a
different set of API's for manipulating strings.

The number of imports needed, though, is a different issue. That's
something that Phobos needs improvement in. At least the last time I
checked, the "Phobos philosophy", as stated on dlang.org, is that you
shouldn't need to import half the library just to do a single simple
operation like reading a file. Unfortunately, from what I can tell, that
philosophy hasn't really been carried through. Lazy imports, discussed
earlier this week, are a direction I'd like to see implemented some time
in the near future. Some of the code bloat just from importing a single
std module is a bit excessive, and bugs me quite a bit.

Nevertheless, I haven't experienced any "high friction" issues in
getting stuff done with strings. Once you learn where things are and
what is available, it's pretty straightforward to throw something
together. It does take a bit of time to learn this, but honestly, that's
not any more effort than learning C for the first time and learning what
strchr or memset means, and when to use strcat and when not to. In fact,
I'd argue that learning the C string functions is a lot more effort,
because they have so many pitfalls and gotchas that you must memorize
and constantly keep in mind, otherwise your program suddenly acquires
gratuitous segfaults, pointer bugs, and buffer overruns. IME, it takes
*more* effort to write string manipulation code in C, rather than less,
since so many more things can go wrong.


T

-- 
Turning your clock 15 minutes ahead won't cure lateness---you're just making time go faster!