kris wrote:
> Walter Bright wrote:
>> kris wrote:
>>
>>> Walter Bright wrote:
>>>
>>>> The flashy stuff, though, is the stuff that piques peoples' interests enough to give D a try.
>>>
>>>
>>> Bling is very much in the eye of the beholder, and often has the inverse effect?
>>
>>
>> If it is perceived as being *just* bling, it will have the reverse effect. If you can show, however, that it solves otherwise intractable or time-wasting problems, you get interest.
> 
> Absolutely.
> 
> If you can successfully do that for, say, dev managers, then so much the better. On the other hand, giving such ppl a reason to fear adoption would be a terrible mistake. As you probably know, commercial shops tend to be more than a bit conservative when it comes to code.
> 
> Even companies perceived as progressive care deeply about ensuring the code is 'pedestrian' in nature. Google, for example, outlawed C++ templates. They did this because their experience showed such code was unmaintainable, more often than not. In the hands of the masses, such tools are often used for creating a language within a language, and everyone's version has a personal stamp: MyDSL
> 
> It's the old story about great power requiring great responsibility. Should the language be penalized for that? No. Might it be viewed that way? Sure. Just being "right" is never enough in such an environment.
> 
> In no way am I saying "oh, all that meta-stuff is poppycock", as someone had suggested to me. I personally /like/ a touch of DSL here and there (have been shot-down in the past for exactly that). Instead, my personal concerns (when it comes to D) are based purely around three things:
> 
> 1) is it of notable or daily value to 50%+ or more of users?
> 2) does it further delay fixing existing features that match #1?
> 3) does it have /real/ potential to hinder adoption due to ignorance, religion, sexual preferences, or the weather?
> 
> Those are all arguable, of course. Programmers are notoriously fickle when it comes to #3. But my concern over that one is the commercial dev shops; the likes of Google, Oracle, SAP, Yahoo, along with every single company that currently uses Java instead of C++
> 
> Thus; shouting from the rooftops that D is all about meta-code, and DSL up-the-wazzoo, may well provoke a backlash from the very people who should be embracing the language. I'd imagine Andrei would vehemently disagree, but so what? The people who will ultimately be responsible for "allowing" D through the door don't care about fads or technical superiority; they care about costs. And the overwhelming cost in software development today, for the type of companies noted above, is maintenance. For them, software dev is already complex enough. In all the places I've worked or consulted, in mutiple countries, and since the time before Zortech C, pedestrian-code := maintainable-code := less overall cost.
> 
> All IMO
> 
> - Kris

All great points. Build it (a solid foundation) and they will come. Recent activity on const/inout/scope come to mind for me.

That said, the metaprogramming stuff is cool, and has its place, but I don't think it should be given precedence over the basics.

Sean Kelly wrote:
> Walter Bright wrote:
>>
>> The flashy stuff, though, is the stuff that piques peoples' interests enough to give D a try.
> 
> I suppose it depends on the person.  Personally, I was mostly searching for a language that addressed my issues with existing languages, and D had that in spades.
> 
> 
> Sean

That was my case too.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Kirk McDonald wrote:
> Walter Bright wrote:
>> Kirk McDonald wrote:
>>> Given a class, I need a way to get a list of all of its member functions at compile-time.
>>
>> static member functions? non-virtual member functions?
> 
> Okay, I think I do need to clarify this.
> 
> Let's take this class:
> 
> class Foo {
>     void foo() {} // A regular method
>     static void bar() {} // A static member function
>     final void baz() {} // A non-virtual member function
> }
> 
> Here's one possible interface:
> 
> get_member_functions!(Foo) => Tuple!(Foo.foo, Foo.bar, Foo.baz)
> 
> To distinguish between these attributes, we could define an enum, like:
> 
> enum MemberAttribute { Virtual, Final, Static }


I think you should be able to use .mangleof to get that info, no?

L.

Lionello Lunesu wrote:
> Kirk McDonald wrote:
>> Walter Bright wrote:
>>> Kirk McDonald wrote:
>>>> Given a class, I need a way to get a list of all of its member functions at compile-time.
>>>
>>> static member functions? non-virtual member functions?
>>
[snip]
> 
> I think you should be able to use .mangleof to get that info, no?

At the moment, .mangleof can tell static from virtual or final (because of the 'M' indicating a 'this' pointer is passed to the latter two), but virtual and final member functions are mangled identically.

janderson wrote:
> Bill Baxter wrote:
> [snip]
>> I'm hopeful anyway.  But to me it seems like what D's souped-up templates have proved so far is that while features like static-if take you a long way -- maybe so far as "making the simple stuff simple" -- anything beyond that still turns into spaghetti.
>>
>> It's a step in the right direction, though.  In C++ even the simple stuff gives you spaghetti.
> 
> Very true.

I was surprised at what a big step static if's were.