1) There are degrees of type strength. A 100% strongly typed language will not allow you to implicitly convert an int to a float, for example.
2) K&R C had "lint", which wasn't part of the compiler, but really helped. Python has an array of such tools, that aren't part of the compiler, but are quite useful.
"Strongly typed" means "few to no implicit type conversions". Don't confuse it with "manifestly typed". A 100% strongly typed language won't allow you to do things like add a number to a string (java allows this) or multiply a string by a number (Python does this) - but it also won't allow you to implicitly convert an int to a float (almost everything does this).
"manifestly typed" means you have to spell out your types by typing them in.
Python 3.x (and to a lesser extent, Python 2.x) can be "gradually typed", which means you can declare some of your types if you want. This requires a tool like mypy or pytype.
Look at Haskell. It's strongly typed, even though it is implicitly typed. IOW, it's not manifestly typed. Sadly, its type system is a royal pain, IMO - at least in its main implementation, the Glasgow compiler.
I use vim+syntastic+jedi+supertab, and a simple macro that spawns make from inside the editor. Consider it a text editor with plugins.
vim does syntax highlighting for almost everything out of the box.
syntastic does static analysis for almost everything with deeper error detection than syntax highlighting alone can do.
jedi+supertab do completion for Python nicely.
The macro I mentioned looks in your CWD's Makefile and runs its default rule. I usually have this do heavier-weight static analysis, unit testing, and system testing - but if I'm up against a head scratching bug, sometimes I'll temporarily change it to start a debugger like pudb or winpdb. But to be honest, I don't use debuggers much - I'm more likely to use print's for most bugs
emacs likely has analogs to all of these.
The only thing I've heard of that one IDE does that vim+plugins doesn't, is error detection for SQL code embedded in strings within a non-SQL file, like a.py or a.java. vim+plugins does files with a.sql extension pretty well, but it doesn't do SQL code that's embedded in some other language file. I tend to see ORM's as a good way around this.
I'm not sure what supposedly makes an IDE-based debugger superior to other debuggers, but pudb (curses, linux) and winpdb (wxWindows, cross-platform) are really pretty good for python.
Manifest, static, strong typing (C++, Java) can catch some significant bugs.
However, dynamic, strong typing (Python) can catch almost all of the same bugs using a tool like pylint or pyflakes. These look for variables that are set but not used, or used but not set. Pyflakes doesn't do much else, but pylint catches a large number of additional problem types in Python code.
For speed, it's hard to beat an rsync wrapper like Backup.rsync: http://stromberg.dnsalias.org/... . It doesn't deduplicate super-well, and it doesn't compress on disk, but like I said, it's fast. It's quite good at removing old data that you don't care about anymore.
For frugality, consider something like backshift: http://stromberg.dnsalias.org/... . It deduplicates quite well, and compresses everything (including most metadata) with xz. It also makes it easy to expire old data, unlike a lot of backup software you'll see.
Also, CPython having a GIL supposedly makes it easier to write C extension modules, which may be partially responsible for the large number of such modules for CPython.
map, filter and reduce are almost always better done as a generator expression or list comprehension, FWIW.
I'm interested in hearing about Python and Functional Programming though.
Python, as a plugin, would require adoption by Chrome, Firefox, Internet Explorer, Opera - I doubt all four of these would all agree to support Python as a plugin.
However, it's possible to compile Python to javascript. Most of these transpile individual Python programs to JavaScript, but one, empythoned, actually compiles CPython 2.x to JavaScript using LLVM's JavaScript backend.
Python the language definition, supports threads fine. CPython the reference implementation, supports threads, but while they work fine for I/O bound workloads, they are poor for CPU bound workloads. However, CPython supports multiprocessing, which uses multiple processes and shared memory; multiprocessing tends to give looser coupling between parallel code units than threading.
Jython and IronPython support threads for both I/O bound and CPU bound workloads.
You're almost always better off using a generator expression or list comprehension instead of a lambda. Also, multiline lambdas detract from readability.
Python is duck typed - no need for interfaces, though it'd be nice to have them in pylint. Python has abstract classes. Python has a weak form of private members.
Rumor has it that patches were submitted for removing the GIL from CPython once, but they made uniprocessor workloads so much slower that the patches were rejected.
C: Overcomplicated, but fast, and useful for extending most other languages
Java: Reasonable, but a bit wordy. Pretty marketable. Performs quite reasonably really, though slow to exec
C++:Probably best avoided unless you have libraries in C++ you must use (in which case you could use Cython)
Objective-C: Useless, except on an iPhone
C#: Another lockin trojan horse from Microsoft. Avoid.
PHP: Awful design. Avoid.
BASIC: Those whom the gods would destroy, first they teach BASIC.
Python: Very nice language to work in. Sacrifices performance a bit in the reference implementation, but pretty fast if you use Pypy. Can be extended using C or Cython. Sometimes off-putting to people who feel that programming "should be complicated".
JavaScript: The assembly language of the web. It's a bit of a mess, but many, many web applications use it. There have been many projects attempting to translate other languages to JavaScript, to make web development less painful. One of them is Python, another is Java. I'd be surprised if there aren't others.
Perl:What a mess! It's much too kitchen-sink. For people whose problem domains aren't complicated enough to keep them entertained, so they need a messy language to make things more interesting.
Ruby:Popular among Java programmers who don't want to use anything but Java. Kinda perlish, but not quite as bad.
Slashdot Mirror
1) There are degrees of type strength. A 100% strongly typed language will not allow you to implicitly convert an int to a float, for example.
2) K&R C had "lint", which wasn't part of the compiler, but really helped. Python has an array of such tools, that aren't part of the compiler, but are quite useful.
Python is strongly, dynamically typed.
C is weakly, statically typed.
C++ and Java are strongly statically typed.
"Strongly typed" means "few to no implicit type conversions". Don't confuse it with "manifestly typed". A 100% strongly typed language won't allow you to do things like add a number to a string (java allows this) or multiply a string by a number (Python does this) - but it also won't allow you to implicitly convert an int to a float (almost everything does this).
"manifestly typed" means you have to spell out your types by typing them in.
Python 3.x (and to a lesser extent, Python 2.x) can be "gradually typed", which means you can declare some of your types if you want. This requires a tool like mypy or pytype.
Look at Haskell. It's strongly typed, even though it is implicitly typed. IOW, it's not manifestly typed. Sadly, its type system is a royal pain, IMO - at least in its main implementation, the Glasgow compiler.
Some people use "rope" for Python refactoring without an IDE. PyCharm can probably do it too, a popular Python IDE.
My idea of refactoring is mostly vim's n.n.n.
Neither of these is a Python problem.
2 words: "Static analyzer".
EG: pylint, pychecker or pylint.
I use vim, but supposedly pycharm can do a good job of this too.
I use vim+syntastic+jedi+supertab, and a simple macro that spawns make from inside the editor. Consider it a text editor with plugins.
.py or a .java. vim+plugins does files with a .sql extension pretty well, but it doesn't do SQL code that's embedded in some other language file. I tend to see ORM's as a good way around this.
vim does syntax highlighting for almost everything out of the box.
syntastic does static analysis for almost everything with deeper error detection than syntax highlighting alone can do.
jedi+supertab do completion for Python nicely.
The macro I mentioned looks in your CWD's Makefile and runs its default rule. I usually have this do heavier-weight static analysis, unit testing, and system testing - but if I'm up against a head scratching bug, sometimes I'll temporarily change it to start a debugger like pudb or winpdb. But to be honest, I don't use debuggers much - I'm more likely to use print's for most bugs
emacs likely has analogs to all of these.
The only thing I've heard of that one IDE does that vim+plugins doesn't, is error detection for SQL code embedded in strings within a non-SQL file, like a
I'm not sure what supposedly makes an IDE-based debugger superior to other debuggers, but pudb (curses, linux) and winpdb (wxWindows, cross-platform) are really pretty good for python.
Commit testing is good, but static analysis is good too. They're complementary technologies.
I prefer vim+syntastic+jedi myself, but I have met some pretty strong coders who like the pycharm IDE for Python.
Also, I know some strong Java coders who really love the IntelliJ IDE.
Manifest, static, strong typing (C++, Java) can catch some significant bugs.
However, dynamic, strong typing (Python) can catch almost all of the same bugs using a tool like pylint or pyflakes. These look for variables that are set but not used, or used but not set. Pyflakes doesn't do much else, but pylint catches a large number of additional problem types in Python code.
K&R C had lint. Python has pylint.
For speed, it's hard to beat an rsync wrapper like Backup.rsync: http://stromberg.dnsalias.org/... . It doesn't deduplicate super-well, and it doesn't compress on disk, but like I said, it's fast. It's quite good at removing old data that you don't care about anymore.
For frugality, consider something like backshift: http://stromberg.dnsalias.org/... . It deduplicates quite well, and compresses everything (including most metadata) with xz. It also makes it easy to expire old data, unlike a lot of backup software you'll see.
Full disclosure: I wrote both of them.
Here's a table comparing some common backup tools: http://stromberg.dnsalias.org/...
http://stromberg.dnsalias.org/...
You might be able to tell which hop is slow using something like pchar: http://stromberg.dnsalias.org/~strombrg/network-performance.html
Also, CPython having a GIL supposedly makes it easier to write C extension modules, which may be partially responsible for the large number of such modules for CPython.
try/except is no longer a programmer trap.
map, filter and reduce are almost always better done as a generator expression or list comprehension, FWIW. I'm interested in hearing about Python and Functional Programming though.
Here's a list. See especially CFFI.
Python, as a plugin, would require adoption by Chrome, Firefox, Internet Explorer, Opera - I doubt all four of these would all agree to support Python as a plugin. However, it's possible to compile Python to javascript. Most of these transpile individual Python programs to JavaScript, but one, empythoned, actually compiles CPython 2.x to JavaScript using LLVM's JavaScript backend.
Tail recursion can be hard to debug - no stack frames to look back at.
Python the language definition, supports threads fine. CPython the reference implementation, supports threads, but while they work fine for I/O bound workloads, they are poor for CPU bound workloads. However, CPython supports multiprocessing, which uses multiple processes and shared memory; multiprocessing tends to give looser coupling between parallel code units than threading. Jython and IronPython support threads for both I/O bound and CPU bound workloads.
I've commented on python and whitespace enough times, that it became more practical to create a small web page about it: Read it here.
You're almost always better off using a generator expression or list comprehension instead of a lambda. Also, multiline lambdas detract from readability.
Python is duck typed - no need for interfaces, though it'd be nice to have them in pylint. Python has abstract classes. Python has a weak form of private members.
Rumor has it that patches were submitted for removing the GIL from CPython once, but they made uniprocessor workloads so much slower that the patches were rejected.
C: Overcomplicated, but fast, and useful for extending most other languages
Java: Reasonable, but a bit wordy. Pretty marketable. Performs quite reasonably really, though slow to exec
C++:Probably best avoided unless you have libraries in C++ you must use (in which case you could use Cython)
Objective-C: Useless, except on an iPhone
C#: Another lockin trojan horse from Microsoft. Avoid.
PHP: Awful design. Avoid.
BASIC: Those whom the gods would destroy, first they teach BASIC.
Python: Very nice language to work in. Sacrifices performance a bit in the reference implementation, but pretty fast if you use Pypy. Can be extended using C or Cython. Sometimes off-putting to people who feel that programming "should be complicated".
JavaScript: The assembly language of the web. It's a bit of a mess, but many, many web applications use it. There have been many projects attempting to translate other languages to JavaScript, to make web development less painful. One of them is Python, another is Java. I'd be surprised if there aren't others.
Perl:What a mess! It's much too kitchen-sink. For people whose problem domains aren't complicated enough to keep them entertained, so they need a messy language to make things more interesting.
Ruby:Popular among Java programmers who don't want to use anything but Java. Kinda perlish, but not quite as bad.