"language_fan" <f...@bar.com.invalid> wrote in message news:h8b5tf$bs...@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.
