On 3/20/12, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> What are your faves? I have a few in mind, but wouldn't want to influence answers.

Hey here's a big one: Phobos. Or maybe both Phobos and D2. I don't have the numbers but I think quite a few people thought D was going to die because of a backwards-incompatible change of a language, and the fact that Tango was missing from D2 (it seems people avoided using Phobos in D1 days).

On Mar 20, 2012, at 10:54 PM, Brad Anderson wrote:
> 
> It's probably far too early to think about this with all the other important issues you're addressing but have you given much thought to improving the hashing function?  I haven't hit any issues with the speed of the current hasher but better performance is always welcome. MurmurHash seems to be all the rage these days with a lot of languages and systems adopting it <http://en.wikipedia.org/wiki/MurmurHash> (it compiles down to ~52 instructions on x86). It'd be interesting to see benchmarks with it. I'm not sure where the current hashing function lives to see what it's like.

Druntime actually did use MurmurHash for a while and then dropped it because the site had no copyright license for the code (a mistake that has since been rectified).  I'd consider switching back, though I don't really like that MurmurHash has a number of separate implementations targeted at different platforms, each having different performance characteristics.  It's 4x faster than SuperFastHash on x86 but 10x slower than SuperFastHash on SPARC, for example.

On 21.03.2012 18:14, Walter Bright wrote:
> On 3/21/2012 8:21 AM, Don Clugston wrote:
>> On 21/03/12 03:47, Walter Bright wrote:
>>> And now x is an instance of a voldemort type! It's completely
>>> encapsulated.
>>
>> That idiom is already built into the language. Anonymous nested
>> classes don't
>> have a name at all.
>>
>> auto x = new class { ... }
>>
>
> True, but it's the ability to return them from a function that's new &
> cool!
>
> (Yes, I know you can return x as type "Object".)

BTW what is 'nested' about anonymous nested classes? They seem to work anywhere! Can we just drop that from the name?

"Sean Kelly" <sean@invisibleduck.org> wrote in message news:mailman.981.1332359368.4860.digitalmars-d@puremagic.com...
>
>Druntime actually did use MurmurHash for a while and
>then dropped it because the site had no copyright license
>for the code (a mistake that has since been rectified).  I'd
>consider switching back, though I don't really like that
>MurmurHash has a number of separate implementations
>targeted at different platforms, each having different
>performance characteristics.  It's 4x faster than SuperFastHash
>on x86 but 10x slower than SuperFastHash on SPARC,
>for example.=

People still use SPARC?

/me out of the loop

On 03/21/2012 09:00 PM, Don wrote:
>
> BTW what is 'nested' about anonymous nested classes? They seem to work
> anywhere! Can we just drop that from the name?
>

Seems reasonable.

BTW: They don't work in a typeof expression:
http://d.puremagic.com/issues/show_bug.cgi?id=7104

On 2012-03-21 18:20, Walter Bright wrote:

> I knew import would be good :-)
>
> It's because I've used languages before with an import, and as a
> compiler guy, I knew what a kludge #include is. The preprocessor in
> C/C++ is a crutch to make up for deficiencies in the language.

I've never been able to properly handle includes in C/C++. Import is SO much better.

-- 
/Jacob Carlborg

On Wednesday, 21 March 2012 at 17:20:28 UTC, Walter Bright wrote:
> On 3/21/2012 7:23 AM, Adam D. Ruppe wrote:
>> But, is import unlikely success, or is this just a
>> leftover feeling from my massive bias in the early
>> days? I have to say it is my bias, since everyone
>> else uses import and they all know it is good.
>
> I knew import would be good :-)
>
> It's because I've used languages before with an import, and as a compiler guy, I knew what a kludge #include is. The preprocessor in C/C++ is a crutch to make up for deficiencies in the language.

On the topic of import, mixin imports are something that I believe will eventually become a great deal more popular than they are today. First, there's the advantage of being able to use a language/syntax more appropriate for the task at hand. For example, for things that output html you could just import mixin a raw html file. But the real advantage is that you can still do compile-time processing on this. Plug in an xml parser, or something like pegged, and you can now extend Html and generate D code for it. For example, if you have something like runat="server" on an element, just like in ASP.net you could create a serverside element for this and manipulate it. Because you know exactly which parts are static and which are dynamic, you could (at compile time) create buffers containing the static portions to prevent having to copy things many times. Unlike other languages, there would be no performance hit to doing this because it's all done at compile time. This is just one example. Another one would be automatically creating bindings for a scripting language, or even automatically creating bindings for a C header file.

On 2012-03-21 20:49, Sean Kelly wrote:

> Druntime actually did use MurmurHash for a while and then dropped it because the site had no copyright license for the code (a mistake that has since been rectified).  I'd consider switching back, though I don't really like that MurmurHash has a number of separate implementations targeted at different platforms, each having different performance characteristics.  It's 4x faster than SuperFastHash on x86 but 10x slower than SuperFastHash on SPARC, for example.

Would it be possible to use different algorithms on different platforms?

-- 
/Jacob Carlborg

On Wednesday, March 21, 2012 22:18:16 Jacob Carlborg wrote:
> On 2012-03-21 20:49, Sean Kelly wrote:
> > Druntime actually did use MurmurHash for a while and then dropped it because the site had no copyright license for the code (a mistake that has since been rectified). I'd consider switching back, though I don't really like that MurmurHash has a number of separate implementations targeted at different platforms, each having different performance characteristics. It's 4x faster than SuperFastHash on x86 but 10x slower than SuperFastHash on SPARC, for example.
>
> Would it be possible to use different algorithms on different platforms?

I'm sure that it would be, but it sounds like part of his complaint is that you end up with different implementations per platform with using MurmurHash, and using a different hash algorithm per architecture is just as bad in that respect. If you're trying to absolutely maximize performance though, that would probably be the way to go if there isn't one which is a clear winner on all architectures. It doesn't matter all that much for dmd at present though, since it's x86-only.

- Jonathan M Davis

Kapps wrote:
> or even automatically creating bindings for a C header file.

I've thought about that before. It would be great to have fully automatic linking to C libs. You could even have a cache system that stores .di files and only regenerates them if the .h file was modified.