On Thu, 23 Nov 2006 01:52:01 +0900, Bill Baxter <wbaxter@gmail.com> wrote:

>Don Clugston wrote:
>
>> Well, now that we have IFTI and tuples(!) I seriously don't think any template affectionado is likely to evaluate D negatively in that regard. Once the word gets around, I think there'll be a lot of defections.
>
>Metaprogramming in C++ is OOP in C all over again.  Sure you can do it, but...  they definitely didn't have that in mind when they designed the language, so it ain't gonna be pretty.

I saw someone asking about the VC++ __if_exists and something like static if in a GCC discussion once, about whether GCC would support it. The reply was that template metaprogramming creates unmaintainable messes and shouldn't be encouraged.

And I thought to myself - but metaprogramming isn't going away, presumably because it is needed. And most of the reason for the mess is that conditional parts need to be handled using specialisation rather than simple conditionals. So why not make life simpler and more maintainable?

I was going to say so, but that would have meant registering and blah blah, and I put it off to the later that never happens. Which is a shame. It needed saying.

-- 
Remove 'wants' and 'nospam' from e-mail.

On Wed, 22 Nov 2006 09:53:41 -0800, Sean Kelly <sean@f4.ca> wrote:

>Walter Bright wrote:

>> That's to be expected. Many people have bet their careers on C++ being the greatest ever, and nothing can change their mind.

>That said, I do agree that C++ is an "older" language in terms of its users, and that D is much "younger" in this respect.  It makes perfect sense.  C++ has been around for a long time and D has not, and few professional programmers seem inclined to learn new things.  If anything, they're more likely to refine their existing skill set and stick to their "specialty."

Oh no. C++ is the new COBOL. AAARRRGGGHHH!!!

-- 
Remove 'wants' and 'nospam' from e-mail.

On Wed, 22 Nov 2006 19:10:36 +0000 (UTC), Mike Capp
<mike.capp@gmail.com> wrote:

>>  > some of these people are literally annoyed at D and D
>>  > promoters
>
>Not all of those people are diehards, though. I like D, and I sometimes get annoyed by D promoters. There does seem to be an underlying attitude among some of the younger and more enthusiastic posters here that D is essentially perfect for everything, that anyone expressing reservations is automatically a closed-minded fogey, and that no amount of experience with other languages is relevant because D is a whole new paradigm.

It sounds like you have a lot of sympathy with this view...

http://www.perl.com/pub/a/2000/12/advocacy.html

Me too, but it's not all one side. The anti-advocacy-resistance can overreact as well by becoming defensive and adopting a the-best-defence-is-a-strong-offense approach. And if they're attacking, well, we need to defend ourselves - and again, the best defence is a strong offense. And now they know that we're definitely on the attack, so...

The problem is one of human nature, as opposed to the people on one side or the other. Just be glad that bullets don't work over the internet ;-)

-- 
Remove 'wants' and 'nospam' from e-mail.

On Wed, 22 Nov 2006 19:07:59 -0800, Sean Kelly <sean@f4.ca> wrote:


>> No? Hypothetical: your boss dumps a million lines of D code in your lap and says, "Verify that this avoids the GC in all possible circumstances". What do you do? What do you grep for? What tests do you run?
>
>I'd probably begin by hooking the GC collection routine and dumping data on what was being cleaned up non-deterministically.

1.  If possible, relink without the GC library. If that fails, it
    doesn't necessarily mean the GC gets used, so relink with
    the GC library patched so that any attempt to allocate memory from
    the GC heap fails with a loud noise.

2.  Run all unit tests, and check that full coverage is achieved.

Of course that assumes that there *are* unit tests...

-- 
Remove 'wants' and 'nospam' from e-mail.

On Mon, 20 Nov 2006 11:35:03 -0800, Walter Bright <newshound@digitalmars.com> wrote:

>The reason for this is not so obvious. It isn't "random" with a 1/2^32 probability, that integers (and other types) contain random values with an even distribution. They don't. The overwhelming majority of ints have values that are between -100 and +100. The most common value is 0. Those values are nowhere near where the gc pools are located.

It's also worth bearing in mind that most random-looking data doesn't hang around in current objects too long. For example, if you're doing encryption or compression, you're probably streaming that data in/out of a file or socket or whatever.

-- 
Remove 'wants' and 'nospam' from e-mail.

On Fri, 24 Nov 2006 19:29:07 -0800, Steve Horne <stephenwantshornenospam100@aol.com> wrote:

> On Wed, 22 Nov 2006 09:53:41 -0800, Sean Kelly <sean@f4.ca> wrote:
>
>> Walter Bright wrote:
>
>>> That's to be expected. Many people have bet their careers on C++ being
>>> the greatest ever, and nothing can change their mind.
>
>> That said, I do agree that C++ is an "older"
>> language in terms of its users, and that D is much "younger" in this
>> respect.  It makes perfect sense.  C++ has been around for a long time
>> and D has not, and few professional programmers seem inclined to learn
>> new things.  If anything, they're more likely to refine their existing
>> skill set and stick to their "specialty."
>
> Oh no. C++ is the new COBOL. AAARRRGGGHHH!!!
>


He he.. It's inevitable... the languages start to date developers.

The same thing works for operating systems.  When I mention I used some of the very first Slackware linux releases in the 1990s (maybe around 19993 or 94) because I was desperate to move away from the DOS/Win16 platform... well, even a minor thing like that starts dating me among the younger generation of linux gurus (a linux guru, I am not... still after all these years).  At 31, I'm an in-betweener... not that old... but old enough that computer history is leaving it's mark in my memories. :)

-JJR

Steve Horne wrote:
> On Thu, 23 Nov 2006 01:52:01 +0900, Bill Baxter <wbaxter@gmail.com>
> wrote:
> 
>> Don Clugston wrote:
>>
>>> Well, now that we have IFTI and tuples(!) I seriously don't think any template affectionado is likely to evaluate D negatively in that regard.
>>> Once the word gets around, I think there'll be a lot of defections.
>> Metaprogramming in C++ is OOP in C all over again.  Sure you can do it, but...  they definitely didn't have that in mind when they designed the language, so it ain't gonna be pretty.
> 
> I saw someone asking about the VC++ __if_exists and something like
> static if in a GCC discussion once, about whether GCC would support
> it. The reply was that template metaprogramming creates unmaintainable
> messes and shouldn't be encouraged.
> 
> And I thought to myself - but metaprogramming isn't going away,
> presumably because it is needed. And most of the reason for the mess
> is that conditional parts need to be handled using specialisation
> rather than simple conditionals. So why not make life simpler and more
> maintainable?

Exactly. In C++ metaprogramming, the only control structure you have is:

(x==CONST_VALUE) ? func1() : func2()

where x must be an integer. No wonder C++ metaprogramming code is so disgusting. I've been amazed at how D metaprogramming on strings can sometimes be shorter than the equivalent C++ runtime code !

> 
> I was going to say so, but that would have meant registering and blah
> blah, and I put it off to the later that never happens. Which is a
> shame. It needed saying.
> 

Dave wrote:
> Boris Kolar wrote:
>> == Quote from Steve Horne (stephenwantshornenospam100@aol.com)'s article
>>> Most real world code has a mix of
>>> high-level and low-level.
>>
>> True. It feels so liberating when you at least have an option to
>> cast reference to int, mirror internal structure of another class,
>> or mess with stack frames. Those are all ugly hacks, but ability to
>> use them makes programming much more fun.
>>
>> The ideal solution would be to have a safe language with optional
>> unsafe features, so hacks like that would have to be explicitly marked
>> as unsafe. Maybe that's a good idea for D 2.0 :) If D's popularity
>> keeps rising, there will be eventually people who will want Java or
>> .NET backend. With unsafe features, you can really put a lot of extra
> 
> Good Gosh, I hope not, not if that means wrecking the language to conform to those runtimes. Look at what MS has done with (or to!) C++.Net - yikes!.

I think it's even worse than that. The opposite of 'unsafe' is *not* safe!

My brother has worked with medical software which contain software bugs which kill people. And the bugs are NOT 'dangling pointers', they are incorrect mathematics (wrong dosage, etc). The code is 'safe', yet people have been taken out in body bags.

I think this whole "safe"/"unsafe" concept can be distracting -- the goal is software with no bugs! It's just a tool to reduce a specific class of bugs. D does many features which help to reduce bugs, the concept of 'safe' code just isn't one of them.

> D is aimed primarily at the native compilation / systems programming space, with great support for general application programming. Just like C/++. And there will be plenty of room for all of the best native / JIT / interpreted languages for a long time to come.
> 
> It's the old 80-20 rule - 20% of the available .Net and Java libraries are used for 80% of development work. So if most of the effort is concentrated on the 20% most often used, D libraries will be a reasonable alternative for 80% of the applications out there. The other library fluff can come later. Actually I wouldn't be surprised to learn that it's more like 90-10.

That's an excellent point.

>>> No? Hypothetical: your boss dumps a million lines of D code in your lap and says, "Verify that this avoids the GC in all possible circumstances". What do you do? What do you grep for? What tests do you run?
>>
>>I'd probably begin by hooking the GC collection routine and dumping data on what was being cleaned up non-deterministically.
>
>1.  If possible, relink without the GC library. If that fails, it
>    doesn't necessarily mean the GC gets used, so relink with
>    the GC library patched so that any attempt to allocate memory from
>    the GC heap fails with a loud noise.
>
>2.  Run all unit tests, and check that full coverage is achieved. Of course that assumes that there *are* unit tests...


It should be as simple as choosing a compile option
and letting the compiler complain the use of GC.

%u, (:P)

as soon as you compile to object files and do the linking yourself, you are in any way getting undefined references to some GC functions, as soon as you try to use GC-enabled features, anyways. And as this thread is about OSnews discussions, in OS development, you *do* link yourself anyways (gcc -c, ld -Tlinker-script).

Kind regards,
Alex

%u wrote:
>>>> No? Hypothetical: your boss dumps a million lines of D code in your lap and says,
>>>> "Verify that this avoids the GC in all possible circumstances". What do you do?
>>>> What do you grep for? What tests do you run?
>>> I'd probably begin by hooking the GC collection routine and dumping data
>>> on what was being cleaned up non-deterministically.
>> 1.  If possible, relink without the GC library. If that fails, it
>>    doesn't necessarily mean the GC gets used, so relink with
>>    the GC library patched so that any attempt to allocate memory from
>>    the GC heap fails with a loud noise.
>>
>> 2.  Run all unit tests, and check that full coverage is achieved.
>> Of course that assumes that there *are* unit tests...
> 
> 
> It should be as simple as choosing a compile option
> and letting the compiler complain the use of GC.