On Thursday 23 January 2003 12:22, Witness wrote: > Here I must digress and cite the example of Java. While it is certainly > the hll - and probably the one you are most thinking of - it is also the > language with the worst performance. While throwing more hardware > (memory/cpu) at it will speed it up and perhaps make the speed > differences between it and C or C++ less noticible, the difference will > still be there. so? If my choice is between something that's relatively safer yet slower and something that's fast yet fragile, I'll take the lumbering tank any day. You wouldn't drive a Formula 1 car to get groceries, it'd be stupid. As soon as it hits a pothole, BOOM. So why do you think the programming allegory is somehow a good idea? > And I for one don't think we should pay such a penalty > for security. then you don't really want security in any meaningful sense. Security is about playing the averages and managing risks (not about eliminating every problem, although that would be nice). The less work required of a programmer to do the right thing, the more trustable the product. High level languages like Java and Python keep the programmer from having to deal with _one class_ of problems (pushing your focus on problems up the stack), and that's objectively good for your odds. Arguing against reducing the complexity programmers have to deal with is like arguing that we should only build airliners to go REALLY FAST. Pesky safety equipment...just think how much more you could carry without it! Just so long as you get there another 10% faster, right? So what if they fall out of the sky sometimes? It's a short-sighted argument that places speed over correctness. If it's faster and broken, that just means that it breaks _faster_. Um yeah, I think I'll pass on that. Additionally, you picked one of the worst performing high level languages available as an example. If something other than portable assembler (a.k.a., C) is really so anathema to you, I suggest you look around: large portions of the programming world are moving to late-binding, interpreted languages that allow programmers to do more with less and do it more correctly. Entropy is always against us, no need to throw it a bone just because you have some grudge against Moore's Law. -- Alex Russell alexat_private alexat_private
This archive was generated by hypermail 2b30 : Thu Jan 23 2003 - 13:16:55 PST