Nick Sabalausky Wrote: > "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. > > > > >
Good points and colorful choice of words. I enjoyed reading this.