Template Metaprogramming Made Easy (Huh?)

[Nick Sabalausky]

 "language_fan" <foo at bar.com.invalid> wrote in message 
news:h8b5tf$bs6$3 at digitalmars.com...
> Thu, 10 Sep 2009 06:05:59 -0400, Nick Sabalausky thusly wrote:
>
>> Yea, and another issue with VM-only languages is that you can't really
>> use them for systems programming (ex, try using Java or Python to write
>> firmware
>
> For what's it worth, I have not seen any firmware projects that use D,
> either. Not that it's impossible, no one in the firmware industry just is
> not interested in D. When you have limited amount of memory resources,
> the bloaty executables that dmd generates (all firmware uses x86 opcodes,
> right), the typeinfos, and the garbage collector are a nuisance.
>

True, but as you note, at least it's possible. Plus a lot of that bloat can 
be ripped out anyway. And LLVM has a C backend for all those processors that 
only have C compilers available. *And* there's interest in making all this 
happen. But with firmware on a VM-only language, you'd just be facing a 
dead-end (or at most, one of those mere side-show "Oh, wow, like what he 
did! In that language! Cool! Ha ha!" project with no real-world practical 
application).

> , or a commercially-competetive NDS game. And what language is a
>> person going to use to implement that VM in? Another VMed langauge? That
>> would be pointless). Now, for some people that's not an issue, because
>> they may never venture outside of web development and maybe end-user
>> desktop apps (Hell, most of the programmers I've met here in Cleveland
>> would never be *capable* of going beyond such simple types of
>> software...but that's a whole other set of discussions...).
>
> I happen to know that for instance the code (written in e.g. Java)
> banking industry,

Banking software is a glorified calculator. Granted, much more complex than 
a typical calculator (though not necessarily handheld graphing calculators), 
but still, a calculator. And when it still takes a day or two, in 2009, for 
certain simple transactions to go through, I have to seriously question how 
good of a job they're doing anyway.

> online shops,

I don't believe that for a second. And as far as performance, if they need 
more of that, they can (and do) throw hardware at it.

> and web search engines use,

Lumping search engines in with ordinary web apps is like lumping compilers 
in with typical end-user desktop apps, or like lumping home console games in 
with Flash games. Yea, I'll grant that searching is a serious topic, but 
throwing an HTML frontend over it doesn't make it comparable with web apps 
in general.

> isn't quite
> the simplest type of software. You can ask amazon or google or the
> technical department of your favorite bank. They wouldn't use C++ or D in
> its current form for the majority of their tasks, it's just how it is.
>

Right, they don't use systems langauges because they don't need to (except 
in google's case, and unless I'm mistaken, I think I've heard that they do 
write some of their low-level performance critical stuff in C).

Like I already said, many people will never need something that goes 
low-level. And so thay can get away with investing all their resources in 
VM-only languages. And like I already said, that's fine. But for someone to 
come in and indicate that complaints against VM-only languages are always 
unsubstantiated is just plain absurd.

> The problem with many developers is that they refuse to understand the
> mathematics behind algorithms. Time complexity just happens to matter
> more when you have millions of clients etc. If Java is 50% slower, it
> doesn't matter when your algorithm is 4 orders of magnitude faster with
> 10 million clients.

Yes, which just helps back up my remark that those apps are a lot easier. 
Think about it: Time complexity is always a concern when dealing with 
performance. But on some software, that's the only performance question. 
Easy. Nothing else to worry about. Just identify the type of algorithm, look 
up the complexity if you don't already know it off the top of your head, and 
you're done. But then on other software, you *ALSO* have to worry about 
whether or not the complexity *is* actually the bottleneck in the first 
place. And when it isn't - and, much of the time, even when it *is* - then 
you have to dive into the *real* world of software optimization...*in 
addition to* that time complexity that's still going to creep up from time 
to time anyway.

> Writing good algorithms is quite hard and error prone
> in low level languages and that's why bad algorithms are usually used
> even if they are known to perform weakly.

And then there's D, which handles both low and high level.