D Language 2.0

[Nick Sabalausky]

 "Daniel" <dan.from.tokyo at gmail.com> wrote in message 
news:hj0pvc$2sil$1 at digitalmars.com...
>

Haven't we already had enough posts about "I don't like D2 because it 
doesn't add *enough* stuff"? Fuck, people, this shit takes time!

> D still takes 80kb just to print "hello world" to the prompt.
We *just* had a large debate over whether or not 200k was a problem for a 
"hello world". And now we're getting bellyaching over a measly 80k? WTF?

Sure, it certainly makes a big difference on embedded stuff, but...well, see 
a couple paragraphs below:

> When are we going to fix things so stuff is only
> imported if it's used?

When there aren't far more important things to take care of.

> I went to write a small program for an embedded device, but because of 
> this I had to
> abandon and rewrite it in C - and I have to work through a bit to find 
> where the program actually starts in IDA
> Pro.

D isn't even available for embedded platforms yet, AFAIK. Certainly not D2 
or DMD or in a real robust form anyway. And yea, I'd be one of the first 
people to agree that's a *major* missed opportunity, but there's only two 
real things to do about it: 1. help make it happen or 2. not whine about it. 
But until real embedded D actually does happen, trying to trim out a few k 
is worthless.

>
> Const does not provide me any guarantees that I couldn't already get with 
> in/out/inout and function contracts.
> It does not guarantee that a value will not change because D doesn't 
> control the execution environment, what
> const does is declare that it won't be changed by the program itself.  We 
> can already check that automatically.

> My problem is that now we have six dozen extra rules and a few more 
> keywords because of it.

Function contracts are run-time. As such, they are absolutely no substitute 
for const, which is compile-time. If you don't have any problem with 1. 
bogging down execution with useless processing that could have already been 
handled at compile-time and 2. ignoring errors at compile-time so that they 
may-or-may-not be caught at run-time, then that's what those 
dynamic-language toys are for.

The in/out/inout are only for function parameters and are not as 
fine-grained as const, so they're no substitute either.

And if you don't care for const, don't use it.

>
> D is still aimed at the i486,

Yea! That's terrible! Let's just deprecate anything less than 64-bit 
quad-core, because anything less than top-of-the-line is useless.

And I don't want to hear that damn "but that's all that the stores sell!" 
strawman that I've heard a thousand times because everyone knows damn well 
that's not all that's *actually in use*.

> and is just starting to handle threading.

It's been no worse at threading than C/C++ for quite some time. It's just 
starting to have a threading model that kicks the crap out of the threading 
in the vast majority of languages out there. But that's a hell of a far cry 
from "just starting to handle threading".

> My CPU is a Core i7, which is a quad-core.

> It also has SSE4.2




1. Good for you.

2. Next week I'll sell my house to buy a 50-unit cluster of quintuple-cores 
with 1TB RAM each, and start bitching about any software or language that 
supports a pathetic, measly non-cluster with merely 8GB or so of RAM.

Then I'll buy a Porsche and bitch and moan and carry on about any road that 
allows people to drive on it with a Corvette or, god-forbid, a sedan or 
anything else with a top-speed below 250+ mph.


> It's been 20 years.
>

Let's all be consumer whores! Remember kids: "old" means "unpopular", and 
above all allse, we certainly don't want to be unpopular!

>
> cent and ucent should be available via SSE.  Over 97% of computers now 
> have it and I still can't even assign to an
> SSE register?
>

Submit a patch.

> Don Clungston had some excellent code written up in BLADE found on dsource 
> 2 years ago.  Shouldn't that have
> become part of D native?
>

Maybe. Update it, merge it, and submit a patch.

> D ought to have a way to express math without automatically executing it. 
> Some math can't execute on an x86,
> and sometimes we just want to reduce instead of execute.  Hell, if a 
> function were something we could reduce
> and see, that would count.  This also has value for optimization.
>

That would belong in a math library. See if it's already supported in one of 
the existing math libs, and if not, write it and put it on dsource.

> An AST?
>

Already an intended future feature. But we obviously can't have everything 
and have it all right now.

> D missed big on short circuit evaluation because they want to typedef 
> bool.

D does do short-circuit evaluation. Not sure what you mean about it wanting 
to typedef bool.

> I was hoping I'd be able to see
> things like ||=  &&=

Submit a path or put a feature request on bugzilla. If there's already a 
ticket for it on bugzilla, then vote on it.

> and x = y || z
>

That works just fine:

void main()
{
    bool x, y, z;
    x = y || z;
}

If it isn't doing short-circuit eval on that, then submit a patch or a 
bugzilla ticket, etc.

> I also kind of hoped we'd see standard real world unit types in D.  Like 
> sqft, meters, ohms, kg, L, Hz, seconds,
> etc. native to D.  Being able to intrinsically convert types between these 
> things would make D the most
> approachable General Programming Language for real world problems.
>

1. Considering how few languages support that, a lack of it is hardly 
something to hold against D.

2. Someone here has already made/posted a lib that does that. Don't remember 
who though, maybe they'll reply here. Or try searching the newsgroup for it. 
I know it's around somewhere.

> Thanks for your time,
> Dan

If this post comes across overly harsh and inhospitable (and I realize it 
probably does), then I really do apologize. But it's just that we've had 
these very same discussions ("A: The problem with D is it doesn't have X!" 
"B: These things take time. / Then help out.") sooo many times here already, 
I'm getting quite tired of it.