On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
> On 3/13/2015 3:34 AM, bearophile wrote:
>> "Strict mode" is a D2 with immutable+@safe+pure by default,
>
> Note that you can get this largely by starting a module with the following:
>
>    immutable @safe pure:
>

As far as I'm aware, there's no way to mark functions impure this way other than lexical location. Am I incorrect?

Andrei Alexandrescu
<SeeWebsiteForEmail@erdani.org> wrote in
news:mdv6st$28mg$1@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

On Friday, 13 March 2015 at 19:01:08 UTC, weaselcat wrote:
> On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
>> On 3/13/2015 3:34 AM, bearophile wrote:
>>> "Strict mode" is a D2 with immutable+@safe+pure by default,
>>
>> Note that you can get this largely by starting a module with the following:
>>
>>   immutable @safe pure:
>>
>
> As far as I'm aware, there's no way to mark functions impure this way other than lexical location. Am I incorrect?

There is no way to mark functions impure, mutable or virtual. ;)

On 3/13/2015 6:18 AM, Dicebot wrote:
> In my opinion it is better to focus on tempting users with D strong bits than
> oversell it by trying it compete in topics it has inherent disadvantage. There
> is not point in try to compete with Go on topic of simplicity - they have
> crippled the language tremendeously to get that simplicity. Simple D has no
> value - I would simply prefer Go instead of it as it has head start advantage in
> toolchain.
>
> Instead it is better to focus on explaining users that they don't want what they
> think they want, akin to that Bjarne quote. And don't be afraid to admit to
> certain users that D is not a best choice for them. It doesn't mean that such
> valuable feedback should be ignore - there is indeed a lot that can be improved
> in the learning curve. But trying to fight for user who makes choice with
> "trendy" and "simplicity" in mind is a battle lost from the very beginning.

Yup. There are fashions in language design, and if one is always chasing the fashion one will always be behind. We should be looking forward in anticipating future developments. I think D has done very well in this, such as array slicing which other languages are adopting. C++ is now adopting UFCS, too :-)

Having a "me too" language is not an easy way to sell it - especially in the panoply of free languages. People will default choose the original.

Much of Go's and Java's simplicity comes from having a garbage collector. As we all well know, there are limitations that come with that. Moving beyond a GC is not simple.


I strongly believe that one can write simple and effective code in D. Unfortunately, there seems to be a learning curve to writing simple and effective code. I find much of Phobos to be excessively complex. (Though Boost C++ takes the cake in being terrifically complex code.)

On 3/13/15 12:02 PM, Joe Greer wrote:
> 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.

Yah, I think we should add references (with examples) to std.string's documentation to std.algorithm functions that typically apply to strings. -- Andrei

On 3/13/15 12:05 PM, Walter Bright wrote:
> Having a "me too" language is not an easy way to sell it

Well Go is the epitome of "me too" but is doing well for other reasons. -- Andrei

On 3/13/2015 7:20 AM, Chris wrote:
> This is true. This battle is lost. But a lot of users, even people who are
> interested in D, shy away from D, because they don't have the feeling that "this
> is something really useful". We fail to communicate both its general usefulness
> and its strong points as opposed to other languages. What the big marketing
> machines behind Go etc. do is to make people feel good about a product (even if
> it's shit). We should do the same. Only because Google does it, doesn't mean
> it's a big taboo for us. The fact of the matter is that we have failed to win over:

I gave a talk at Digipen recently. (Digipen is a private college aimed at teaching professional game programmers.) They are mostly a C++ house. So I was talking to college students who were deep into programming.

I thought I'd try something different, and wrote a presentation that simply showed some neato things that D could do without diving deep into how those things work.

The home run, though, was showing how unittests combine with -cov testing to make code robust. Yes, you can do this in other languages, but it is so simple to do in D. It really struck a chord with these people.

On Friday, 13 March 2015 at 19:03:29 UTC, Namespace wrote:
> On Friday, 13 March 2015 at 19:01:08 UTC, weaselcat wrote:
>> On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
>>> On 3/13/2015 3:34 AM, bearophile wrote:
>>>> "Strict mode" is a D2 with immutable+@safe+pure by default,
>>>
>>> Note that you can get this largely by starting a module with the following:
>>>
>>>  immutable @safe pure:
>>>
>>
>> As far as I'm aware, there's no way to mark functions impure this way other than lexical location. Am I incorrect?
>
> There is no way to mark functions impure, mutable or virtual. ;)

Is there a reason for this?
I currently put @safe: at the top of all of my D files, and use @trusted/@system as needed(i.e, barely ever except for IO.) I'm not sure if it's good practice but I prefer it.

On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
> On 3/13/2015 3:34 AM, bearophile wrote:
>> "Strict mode" is a D2 with immutable+@safe+pure by default,
>
> Note that you can get this largely by starting a module with the following:
>
>    immutable @safe pure:

no you can't until there will be something like disable(pure) or default immutable @safe

>
>> something like a "var" keyword to denote mutable values,
>
> Transitive const may make this problematic.

Yes, I agree


>> static full tracking of memory ownership,
>
> Makes the language significantly more complex.
>

Yes, but maybe it's worth it

>> less implicit casts (because now we have the safe int(x) sytnax),
>
> I think D does very well with implicit casts.
>

Me too

>> And I'd still like built-in tuple syntax in D.
>
> [... Just one more feature ...] is the road to hell.

No if it would be my own just one more feature :P

On Friday, 13 March 2015 at 19:11:59 UTC, weaselcat wrote:
> On Friday, 13 March 2015 at 19:03:29 UTC, Namespace wrote:
>> On Friday, 13 March 2015 at 19:01:08 UTC, weaselcat wrote:
>>> On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
>>>> On 3/13/2015 3:34 AM, bearophile wrote:
>>>>> "Strict mode" is a D2 with immutable+@safe+pure by default,
>>>>
>>>> Note that you can get this largely by starting a module with the following:
>>>>
>>>> immutable @safe pure:
>>>>
>>>
>>> As far as I'm aware, there's no way to mark functions impure this way other than lexical location. Am I incorrect?
>>
>> There is no way to mark functions impure, mutable or virtual. ;)
>
> Is there a reason for this?
> I currently put @safe: at the top of all of my D files, and use @trusted/@system as needed(i.e, barely ever except for IO.) I'm not sure if it's good practice but I prefer it.

As always: there was many discussions and nothing was decided/done.
The nearest thing we had (and I'm so proud that the suggestion comes from me :P) was: final(false), pure(false) etc.