This post originated from an RSS feed registered with Python Buzz
by Dean Goodmanson.
Original Post: Notes on Tool Friction
Feed Title: Dean Goodmanson: Slices of Py
Feed URL: http://www.pycs.net/sqr/categories/slicesOfPy/rss.xml
Feed Description: Bits from the world of the Python programming language.
Notable stuff from the recently active Python Marketing list:
"> Instead of spending a lot of time and effort learning the tool, you > can spend more time and effort doing the neat stuff with the tool.
The way I've put it to people is that with C++, you spend more time programming the language than programming the problem. Maybe we could flip that around: "With Python, you program the problem, not the language"." - [link]
I've wanted a zinger that infered that Python was closer to the problem domain, but that let to ambiguity. This phrase cuts off most ambiguity by stating the playing field: Programming Language. This can support the "Right tool for the right job" argument.
Sure to offend those with a keener sense of computer science and most certainly langauge zealots, here's my first (and probably only!) taxonomy of programming language tool problem domains:
"programming the processor" - Machine, Assembly "programming the computer" - C "programming the shell" - shell script/awk/sed/perl "programming the database" - SQL, COBOL "programming the problem" - Python (Programming Language) "programming the analysis (AI, etc.)" - LISP, Python.. "programming the application" - Python (Scripting Language)
Moral of the story: Friction is created when the wrong tool is used for the job. But sometimes the handle makes up for the difference so don't hyper-evangelize.
Russel Beattie has written 1,000+ words covering his perspective on Python. I'd love to bullet point and annotate, but I'm not up for that and will leave you with this teaser: "Using Python when compared to Java is like using Linux when compared to Windows." (Product Development/Marketing notes follow.)
Previous Topic
