On 10 January 2014 15:48, Andrei Alexandrescu <seewebsiteforem...@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.