A few notes on choosing between Go and D for a quick project

[Joe Greer via Digitalmars-d]

Andrei Alexandrescu 
<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 
> http://stackoverflow.com/questions/132
44048/no-startswith-endswith-func
> tions-in-go, which puts me in the 
right direction - HasPrefix is the
> name. So I click on that and I get to
> http://golang.org/pkg/strings/
#HasPrefix. 
> 
> 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:
> 
>      fmt.Println(strings.Index
("chicken", "ken"))
>      fmt.Println(strings.Index
("chicken", "dmr"))
> 
> to:
> 
>      fmt.Println(strings.HasPrefix
("chicken", "chi"))
>      fmt.Println(strings.HasPrefix
("chicken", "dmr"))
> 
> 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 
arrays
> 
> * Works with array and element (e.g. 
"abc".startsWith('a')), not only 
> array and array
> 
> * Equality is too much? You can pass a 
predicate
> 
> * 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 
element
> 
> For example the expression (assuming s 
is e.g. a string)
> 
>    File("/tmp/a").byChunk
(4096).joiner.startsWith(s)
> 
> 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 
by hand.
> 
> 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.
> 
> 
> Andrei
> 
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 
program development. 

Just my opinion,
joe