On Sun, Feb 9, 2014 at 4:17 PM, Skybuck Flying <windows7i...@dreampc2006.com> wrote: > Anything that needs to be super reliable. > > My experience so far with Python versus Delphi has shown that Python > requires way more time to debug than Delphi. > > The reason for this is the interpreter versus the compiler. > > Delphi's compiler will catch many bugs in branches that have not been > executed or tested. > > While Python's interpreter will mostly catch bugs in executed and tested > branches.
What this means is that Python forces you to have a good test suite. Yes, that is a cost; but it's nothing to do with compiled vs interpreted. These days, language engines aren't strictly one or the other, they're on a scale. Python will catch syntactic errors at compile time, but will catch most other forms of error at run time... except for the ones that, regardless of the language used, simply result in wrong data. So if you're not testing your code, you can't rely on it, and that's nothing to do with the language. A language with typed variable declarations can catch at compile-time a class of error that Python can't catch until run-time. Yep. But that doesn't actually answer the question: what should Python not be used for. If you need to trust your code, you need to test it. > However there is more... Python may lack some technical language elements > like, call by reference, and perhaps other low level codes, like 8 bit, 16 > bit, 32 bit integers which play a roll with interfacing with hardware. I've never yet found a desperate need for call-by-reference. In toy examples, the equivalent functionality can be achieved by treating a one-element list as a pointer, and dereferencing it just like you would in C, with [0] at the end. Never needed it in production code, though. But again, this doesn't cut out a class of application, just a style of coding. As to strict-size integers, Python does have a struct module, and ctypes, both of which are designed for interfacing with hardware or low-level APIs. For normal work, you don't need to care about that at all. > Types of software which would not go onto my python list: operating systems, > drivers, perhaps also virtual machines and even compilers, python slow > execution speed hampers that as well. A virtual machine where machine code is executed in Python? Well, depends on how fast you need it to be, but yes, that's quite likely to demand more oomph than your typical Python interpreter can give you. Although you could probably play ancient 8088 games, actually interpreting it all on the fly; on modern hardware, you could probably get up to the speed of those old CPUs. Of course, if you can get most of the work done at a lower level, then it's not that kind of VM, and performance is completely different. Compilers... yes, on big projects, you'd probably want to write the compiler in C. I generally say that C is for writing operating systems and high level languages, and those high level languages are for writing everything else in. But look at PyPy. It's possible to write a Python compiler in Python, which can often out-perform CPython. So it's not so clear-cut :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
