"Daniel" <dan.from.to...@gmail.com> wrote in message news:hj0pvc$2si...@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.