6 ms·
This is such a troll. This article mixes valid points with obvious inacurracies. Ok, Python is a fine language, even for building large-scale systems. No, it i
by Xion345 12y ago
This is such a troll. This article mixes valid points with obvious inacurracies.
Ok, Python is a fine language, even for building large-scale systems. No, it is not free from drawbacks.
#1 : Ok, Python is not new and is mature
#2 : "Compiled" is almost a meaningless word. The general definition of compiler is a program that transforms a document written in a source language into a document written in a destination language. TeX is compiler, a CSV to XML parser is a compiler.
As regards security/reverse engineering, Python and Java bytecode files can be very easily decompiled into the original program. It is not the case for C/C++ and thus reverse-engineering is much more difficult. Anyway, this issue can be mitigated using obfuscation.
So ok for this myth.
#3 : Again speaking about the "security". I don't see why Python would be more "secure" than Java. I can see why it would be more secure than C/C++(runs on a virtual machine, so less buffer overflows, bounds checking etc.).
#5 : Yes very valid point for Python. And then you start comparing the JVM (a platform, a runtime, a virtual machine) with Python (a language). This is like comparing apple to oranges. And no, Java is not dynamically typed. Python is.
#6 : This is the wrongest point of your article. Python is slow, very slow. Excuse me, CPython, the runtime that virtually everyone uses is very slow (as all non-JIT virtual machines). Usually 5-10x slower than a native program and 2-4x slower than a JVM program. You can't completely decorrelate the language and the platform. Speaking about Java performance means discussing the JVM (although Java can be compiled). Speaking about Python means discussing CPython.
Performance-wise, Jython is not much better (and sometimes a lot worse than) CPython, and they only implement Python 2.5. Pypy does an excellent job at optimizing Python and often yields on par performance with the JVM. However, it is incompatible with C extensions/modules written for CPython, which means it can rarely be used in production (goodbye databases etc.)
There are countless stories in HN of start up developers rewriting their systems from Python/Ruby to Java/Go because performance was an issue.
#7 : I think some of your examples are contrived (e.g. Youtube) as we don't know where exacly where Python is used is the infrastructure. I only use Python to draw graphs does it mean my infrastructure relies on it ?
About GC pauses. Yeah, there are no pauses in Python because the GIL allows only one thread to run concurrently.
#8: The GIL is a performance optimization ? Really ? The GIL is here because it eased the development of the CPython VM but is terrible for performance. Because of the GIL a CPython cannot run more than one thread concurrently. In the era of multicore processors, this is terrible for performance. Yes, there are workarounds for I/O operations (greenlets etc.), but for processing intensive tasks, it is impossible to exploit a multicore processor with Python. And no multiprocessing is not a solution, as it does not allows to share memory between processes. Also remind that Python is often 4x slower than Java on a signle core...
#9: True but this looks like a strawman. Nobody ever said Python programmers are scarse.
#10: I am not having this debate again, but a strong type system is useful for big projects. I don't say it's mandatory but it reduces development time.
- bkcooper 12y agoAnd no multiprocessing is not a solution, as it does not allows to share memory between processes. You actually can. multiprocessing defines a few classes (e.g. Array) that store their data in a mmap kept in the module. Data there will be visible to all processes, and you can even have a numpy array as a view to this data. That said, my attempts at working with this recently have been pretty painful. multiprocessing tries, but at least in Python 2.7 does not succeed in abstracting away the differences between Unix forks and Windows spawns. This results in a lot of weird issues: things running differently in command line vs. console IPython vs. IPython notebook; the need to structure your code to avoid pickling errors; etc. This is probably the biggest portability issue I've encountered with Python thus far (using it mostly for scientific problems.) I'm aware that there are solutions to some of these issues out there, but it's too bad that the standard library implementation has these issues.
- slantedview 12y agoThe mmap solution, along with various others, are ridiculous workarounds for folks dead set on jamming a square peg into a round, single-threaded hole. If a technology doesn't support something that you need, natively, don't rely on lame workarounds, use a more appropriate technology.