On 7/25/2015 8:03 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com> wrote:
>> BTW, you might want to remove the UTF-8 characters from your user name.
>> Evidently, NNTP doesn't do well with them.
> Hm. It works in the web interface when I reply to my own messages, maybe just a
> client issue?

Looking at the raw text of your posting, it contains:

  From: "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
   <ola.fosheim.grostad+dlang@gmail.com>

I don't know where that comes from, but it is not coming from my NNTP client (Thunderbird).

On 7/25/2015 3:29 AM, Jonathan M Davis wrote:
> We're essentially using it with ranges already when we're implementing
> algorithms differently based on what type of range we're given or what extra
> capabilities the range has, so it obviously is showing its usefulness there,

That's right. We've already been doing it in a haphazard manner, what Andrei is doing is recognizing the technique, naming it, and thinking about how to formalize it, organize it, and determine best practices.

It's like going from an ad-hoc table of function pointers to recognizing that one is doing OOP.


> but the allocators is the only other case that I can think of at the moment where it
> would make sense to use it heavily.

Containers are another fairly obvious use case.

On 7/25/2015 6:20 AM, Andrei Alexandrescu wrote:
> It would be a mistake to put concepts and traits together.

Then I'm misunderstanding one or the other.

On 7/25/2015 11:40 AM, Tobias Müller wrote:
> I'm not convinced at all that checked exceptions (as implemented in Java,
> not C++) don't work.
>
> My suspicion is that the usual Java code monkey is just too sloppy to care
> and thus sees it more as a nuisance rather than the help that it is.

Unfortunately, Bruce Eckel's seminal article on it http://www.mindview.net/Etc/Discussions/CheckedExceptions has disappeared. Eckel is not a Java code monkey, he wrote the book Thinking In Java
http://www.amazon.com/gp/product/0131002872/

On 7/25/2015 6:35 AM, Dicebot wrote:
> If compiler would actually show 0 coverage for non-instantiated lines, than
> automatic coverage control check in CI would complain and code would never be
> shipped unless it gets covered with tests (which check the semantics). Your are
> putting it totally backwards.

A good case. https://issues.dlang.org/show_bug.cgi?id=14825

On Saturday, 25 July 2015 at 19:23:43 UTC, Tobias Müller wrote:
> Walter Bright <newshound2@digitalmars.com> wrote:
>> They write it something like:
>> 
>>     void foo(hasPrefix t) {
>>        t.prefix();
>>        s = cast(hasSuffix)t;
>>        if (s) bar(s);
>>        else RuntimeError(message);
>>     }
>
> That's horrible!
>
> Tobi

I agree. Seriously, that's horrible. I can't remember ever seeing code written like that. Why even use a statically-typed language if you are just going to bypass the type system?

Jordan

On Saturday, 25 July 2015 at 20:48:06 UTC, Walter Bright wrote:
> On 7/25/2015 11:40 AM, Tobias Müller wrote:
>> I'm not convinced at all that checked exceptions (as implemented in Java,
>> not C++) don't work.
>>
>> My suspicion is that the usual Java code monkey is just too sloppy to care
>> and thus sees it more as a nuisance rather than the help that it is.
>
> Unfortunately, Bruce Eckel's seminal article on it http://www.mindview.net/Etc/Discussions/CheckedExceptions has disappeared. Eckel is not a Java code monkey, he wrote the book Thinking In Java
> http://www.amazon.com/gp/product/0131002872/

This ?
http://www.artima.com/intv/handcuffs.html

On Saturday, 25 July 2015 at 00:45:06 UTC, Walter Bright wrote:
> On 7/24/2015 3:12 PM, deadalnix wrote:
>> On Friday, 24 July 2015 at 19:10:33 UTC, Walter Bright wrote:
>>> If I have a call tree,
>>> and at the bottom I add a call to interface X, then I have to add a constraint
>>> that additionally specifies X on each function up the call tree to the root.
>>> That is antiethical to writing generic code, and will prove to be more of a
>>> nuisance than an asset.
>>>
>>> Exactly what sunk Exception Specifications.
>>
>> In many language you have an instaceof keyword or something similar. You'd get :
>>
>> if (foo instanceof X) {
>>    // You can use X insterface on foo.
>> }
>>
>> vs
>>
>> static if (foo instanceof X) {
>>    // You can use X insterface on foo.
>> }
>>
>> The whole runtime vs compile time is essentially an implementation detail. The
>> idea is the very same.
>>
>> The most intriguing part of this conversation is that the argument made about
>> unitests and complexity are the very same than for dynamic vs strong typing (and
>> there is hard data that strong typing is better).
>>
>> Yet, if someone would make the very same argument in the case of dynamic typing,
>> both Walter and Andrei would not give it a second though (and rightly so). Yet,
>> nowhere the reason why this differs in ay that make the cost/benefit ratio shift
>> is mentioned. It is simply asserted as such.
>
>
> I don't see how this addresses my point at all. This is very frustrating.

I think it does. Your point is essentially an argument by ignorance: this is new, we don't really know, and it has been show in the past that what seems like a good idea (checked exception for instance) turns out horribly wrong, against all expectations.

My point is that it is not new, it is very much the same thing as what we've been doing ll along for several decades, the difference being mostly implementation details.

Also, argument from ignorance is hard to maintain when the thread is an actual feedback from experience.

On Saturday, 25 July 2015 at 02:28:49 UTC, Jonathan M Davis wrote:
> On Saturday, 25 July 2015 at 01:22:15 UTC, Tofu Ninja wrote:
>> On Saturday, 25 July 2015 at 00:49:38 UTC, Walter Bright wrote:
>>> On 7/24/2015 2:27 PM, Tofu Ninja wrote:
>>> No it isn't. Google QueryInterface(). Nobody lists all the interfaces at the top level functions, which is that Rust traits and C++ concepts require.
>>
>> The only time you don't use the right interface for your needs is if you plan on casting somewhere down the line. But certainly there are people who don't do that, I for one feel it's bad practice to need to use casts to circumvent the type system like that.
>
> I confess that I've always thought that QueryInterface was a _horrible_ idea, and that if you need to cast your type to something else like that, you're doing something wrong. *shudder* I really have nothing good to say about COM actually...
>
> - Jonathan M Davis

Well yes and now. When you design is new and shinny, sure, that is a sign that somewhere it is broken. When you are patching a hundred of thousand line of code, you may not be able to get the refactoring in all at once in a realistic manner and need to build some debt. Hopefully, as the refactoring progress, these hacks are removed, but not having just makes cost of change prohibitive, which is bad.

I'm not quite sure I understand why this thread is so hot...

Here's my case in point: Rust may as well be a system-language however it appeals more to the high-level programmers of today. Your folks from Java, C#, etc. are going to look at Rust with awe. Technically speaking, Rust doesn't do anything that cannot be done in D. The way you go about doing things may be different, and frustrating at times, however that's the basis behind any language.

D on the other hand is more of a systems language for C and C++ guys.

I'm personally of the opinion that D is wonderful, and it certainly has already reduced my headache count tremendously from my C++ days.

As for marketing, for novice and intermediate programmers, the IDE is the language. D does not have very good IDE support. DDT is by far the best, but is fairly easy to break, and still lacks the feel of an IDE designed for D natively, as opposed to a Java IDE with a plugin running in the background to manage DUB for us.