A few notes on choosing between Go and D for a quick project
Joe Greer via Digitalmars-d
digitalmars-d at puremagic.com
Fri Mar 13 12:02:09 PDT 2015
<SeeWebsiteForEmail at erdani.org> wrote in
news:mdv6st$28mg$1 at digitalmars.com:
> Yah, indeed. Continuing the
experiment, I set out to find Go's
> startsWith. So I googled for
``startswith golang''. First hit is
> http://golang.org/pkg/strings/ but
there's no StartsWith on that page.
> The second hit is
> tions-in-go, which puts me in the
right direction - HasPrefix is the
> name. So I click on that and I get to
> That has no example but the signature
is obvious enough. Just to
> verify, I click on the "Example" link
on the function "Index" below,
> and I edit these lines:
> Click Run produces "true\nfalse"
and... I got it.
> * * *
> Now here's the interesting part.
There's a world of difference between
> D's startsWith and Go's HasPrefix.
(Not because there's anything wrong
> about HasPrefix.) It's just that
startsWith is very powerful -
> disconcertingly so. It is quite
literally the ultimate startsWith:
> * Works with any combination of UTF8,
UTF16, and UTF32.
> * Works with not only strings, but any
> * Works with array and element (e.g.
"abc".startsWith('a')), not only
> array and array
> * Equality is too much? You can pass a
> * Efficiently looks for multiple
prefixes in a single pass, e.g.
> "abc".startsWith("ab", '#')
> * Scratch "array", works with any two
ranges with comparable elements
> and for any range and comparable
> For example the expression (assuming s
is e.g. a string)
> opens a file, progressively reads
chunks of 4KB, stitches them
> together at no cost, compares against
a prefix until it makes a
> decision, then closes the file and
returns the result. A putative Go
> user wouldn't even dream of using
HasPrefix directly on a stream
> coming from a file; the whole endeavor
would be a function that
> painstakingly takes all of these steps
> We need to take the "disconcerting"
out the documentation equation
> while still exposing the power.
s1.startsWith(s2) is perfectly apt for
> two strings, and that should be
immediately apparent to someone who
> just needs that.
I think you're touching on what is bad
about algorithms in general.
That is, documenting them in a way that
one could actually find them
when they are needed. C++ has the same
problem. In this case, there
should really be an entry associated
with the string class that
indicates that this algorithm works with
it and for that matter, all
common string operations that are
implemented as algorithms should be
referred to there. Now, I am not saying
that it is vitally important
that this be all inclusive, that is,
functions that happen to work on
strings, but are really associated with
string operations don't need to
be referenced in the string class.
After all, by the time something
like that is wanted, the user knows way
more about D and can find it
themselves, but certainly things like
startWith() which started in the
string domain and moved out the
generality should be referenced with
strings. The same is true of other
class types as well, but string
manipulating is very important in modern
Just my opinion,
More information about the Digitalmars-d