D Language 2.0

[Bane]

Nick Sabalausky Wrote:

>  "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.
> 
> 
> 
> 
> 


Good points and colorful choice of words. I enjoyed reading this.