On Monday, 17 February 2014 at 19:08:46 UTC, Andrei Alexandrescu
wrote:
> On 2/17/14, 10:59 AM, Jesse Phillips wrote:
>>> Andrei
>>
>> It looks like you've been completely ignored.
>
> This may be partly a logistics issue - my name appears garbled.

Have you posted to that Google group before? If you hadn't, you
would have had to wait a few hours for your post to be moderated
before it appeared. I believe this is what happened, as I was
active on the thread around the time it says you posted, but I
don't recall seeing your post. I imagine that's why nobody
noticed your comment, as it was inserted in the middle of the
thread, so only people reading the whole thread from start to
finish would notice it.

Regarding the whole generics thing, I think it's important to
note that the focus on them slowing compile time has been by the
community, not so much the core designers. The language devs
state that they just haven't found a generics model they're
comfortable with yet.

It's also work noting that Go's developers are from a C
background; while they are of course extremely competent, there
is no substitute for experience, and in my understanding they
don't have the same experience with templates that you and Walter
have via you being a C++ guru and him having written a C++
compiler. Lacking that experience, a much greater amount of
foresight and planning is required to ensure that the form of
generics implemented doesn't come back to bite Go, so I think
their delay is understandable. There's also the Go 1.x
compatability promise, so even if implementing generics was the
number one priority in the language, it still couldn't happen
until a few years from now when Go 2.0 is released.

"ponce"  wrote in message news:loreiqmesicuysdtmgvb@forum.dlang.org...

> I heard a story of a C++ gamedev team that would use type-punning to reduce code size. std::vector<void*> would be the only instantiation of std::vector + casts everywhere. That was for console binaries.

We had a similar thing in the compiler for a long time, with void* arrays underneath and a very thin (inlineable) typesafe wrapper on top.  I met a lot of resistance when trying to change it to a fully templated struct, until benchmarking showed the performance difference was negligible. 

On Tuesday, 18 February 2014 at 01:21:43 UTC, logicchains wrote:
> Regarding the whole generics thing, I think it's important to
> note that the focus on them slowing compile time has been by the
> community, not so much the core designers. The language devs
> state that they just haven't found a generics model they're
> comfortable with yet.

That maybe be true, but they also aren't looking for a solution, they don't see an urgency. This has made it so they don't take the time to explain the problems with each (there was a blog I had read which did some detailing of the trade offs, but can't find it to see if it was from one of the devs).

I have my doubts that they will make generics a priority for 2.0 either.

Of course, implementing generics isn't going to be enough for me. It is just an indicator. You are correct that they will want to get the implementation correct and avoid ruining "Go" as we know it; that just means they'll avoid all the other positive things I enjoy about D's templates and meta-programming features.

On 2/17/2014 1:32 AM, Paulo Pinto wrote:
> On Monday, 17 February 2014 at 05:51:09 UTC, Nick Sabalausky wrote:
>
>> Besides, I suspect the #1 optimization in making a fast-to-compile
>> language is just simply "Don't make C++".
>
> Well, supporting modules would already help. With luck C++ will get them
> around 2020. I think it won't matter by then.
>

Heh. I shudder to think what they might end up looking like, too. C++ deserves some credit for gaining some of D's features here and there, but they're never (and likely can't ever) be as nice and clean as their D counterparts.

On Tuesday, 18 February 2014 at 06:11:38 UTC, Nick Sabalausky wrote:
> On 2/17/2014 1:32 AM, Paulo Pinto wrote:
>> On Monday, 17 February 2014 at 05:51:09 UTC, Nick Sabalausky wrote:
>>
>>> Besides, I suspect the #1 optimization in making a fast-to-compile
>>> language is just simply "Don't make C++".
>>
>> Well, supporting modules would already help. With luck C++ will get them
>> around 2020. I think it won't matter by then.
>>
>
> Heh. I shudder to think what they might end up looking like, too. C++ deserves some credit for gaining some of D's features here and there, but they're never (and likely can't ever) be as nice and clean as their D counterparts.

Apple is driving it, it is going to be a kind of hack so that they can marry the world of #include with a future world of import.

You need a module map that describes the structure of the module. Which header files are responsible, and what libraries are part of the module.

Here is the latest version I know of,

http://clang.llvm.org/docs/Modules.html

--
Paulo

On Tuesday, 18 February 2014 at 05:11:00 UTC, Jesse Phillips wrote:
> Of course, implementing generics isn't going to be enough for me. It is just an indicator. You are correct that they will want to get the implementation correct and avoid ruining "Go" as we know it; that just means they'll avoid all the other positive things I enjoy about D's templates and meta-programming features.

Maybe it'd help things if they just directed any inquiries regarding generics to the most popular preprocessor package? There are a few around the community. I even wrote a tiny one myself this morning; it can only handle simple functions like:
func myFun<T, S>(a, b ~T, u, v ~S) (~T, ~S, ~S){
    return a + b, u*u, v*v
}

Nothing like D's capabilities, but it's enough for most of my needs. What's the problem with just using an unofficial preprocessor for generics? If one package became popular enough amongst the community, that might be enough to convince the devs to adopt it when Go 2.0 comes around.

On Tuesday, 18 February 2014 at 06:50:36 UTC, logicchains wrote:
> On Tuesday, 18 February 2014 at 05:11:00 UTC, Jesse Phillips wrote:
>> Of course, implementing generics isn't going to be enough for me. It is just an indicator. You are correct that they will want to get the implementation correct and avoid ruining "Go" as we know it; that just means they'll avoid all the other positive things I enjoy about D's templates and meta-programming features.
>
> Maybe it'd help things if they just directed any inquiries regarding generics to the most popular preprocessor package? There are a few around the community. I even wrote a tiny one myself this morning; it can only handle simple functions like:
> func myFun<T, S>(a, b ~T, u, v ~S) (~T, ~S, ~S){
>     return a + b, u*u, v*v
> }
>
> Nothing like D's capabilities, but it's enough for most of my needs. What's the problem with just using an unofficial preprocessor for generics? If one package became popular enough amongst the community, that might be enough to convince the devs to adopt it when Go 2.0 comes around.

It is like traveling back in time when parametric polymorphism was debated in university papers and everyone was inventing their own code generation tool.

Back to mid-90's compiler technology when only Ada supported generics, C++ started to adopt some form of genericity at ISO meetings and everything else where academic languages like Eiffel, Modula-3 or Standadard ML.

We are in 2014, not in the early 90's. So to ignore what happened in mainstream language design in the last 20 years, is nothing more than an opinionated political decision against generics.

--
Paulo

On Tuesday, 18 February 2014 at 07:45:10 UTC, Paulo Pinto wrote:
> It is like traveling back in time when parametric polymorphism was debated in university papers and everyone was inventing their own code generation tool.
>
> Back to mid-90's compiler technology when only Ada supported generics, C++ started to adopt some form of genericity at ISO meetings and everything else where academic languages like Eiffel, Modula-3 or Standadard ML.
>
> We are in 2014, not in the early 90's. So to ignore what happened in mainstream language design in the last 20 years, is nothing more than an opinionated political decision against generics.

I understand the sentiment that it is 'backwards', but what exactly on a practical level is harmful about people writing their own code generation tools?

On Monday, 17 February 2014 at 22:53:47 UTC, Asman01 wrote:
> I don't think so. Did you know that some of they are the same guys from Bell Labs which created C, UNIX, Plan9, UTF8 etc?

I'm aware of that, but I'm also aware that there are few things in the world more agonisingly complex than writing a C++ compiler. I think I read Walter say somewhere that it took him ten years! That's ten years of domain-specific experience working with generics in the language with the most complex implementation of generics in existence. My impression is that no amount of experience in other aspects of language design would be a substitute for this specific experience, and hence I think it makes more sense to attribute the effectiveness of D's generics implementation to Walter's extensive experience implementing generics than to attribute it to generics being easy to implement well. If generics are easy to implement, then why isn't there another language with the compile-time power of D that's not a monster like C++ or a Lisp?

On 02/18/2014 10:42 AM, logicchains wrote:
> I think it makes more sense to attribute the effectiveness of D's
> generics implementation to Walter's extensive experience implementing
> generics than to attribute it to generics being easy to implement well.
> If generics are easy to implement, then why isn't there another language
> with the compile-time power of D that's not a monster like C++ or a Lisp?

It's the 'compile-time power of D' that is not 'easy to implement' (there is not (yet) one D compiler in existence that actually can handle all of it in a reasonable way), not 'generics' (whatever that means exactly).

On Tuesday, 18 February 2014 at 07:45:10 UTC, Paulo Pinto wrote:
> It is like traveling back in time when parametric polymorphism was debated in university papers and everyone was inventing their own code generation tool.
>
> We are in 2014, not in the early 90's. So to ignore what happened in mainstream language design in the last 20 years, is nothing more than an opinionated political decision against generics.

I have a hard time to subsume D's type system under parametric polymorphism, while I see how Javas generics may be. This may just be way over my head, but I'd rather say D has a sophisticated way of ad-hoc polymorphism that provides ways to generate overloads on demand, contrary to the wikipedia statement that ad-hoc only allows for a fixed amount of overloads.

> Thus, ad hoc polymorphism can generally only support a limited number of such distinct types, since a separate implementation has to be provided for each type. [1]

I'd say inout is a example of parametric polymorphism in D.

[1] http://en.wikipedia.org/wiki/Parametric_polymorphism