Notes on Tool Friction
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.)
1:37:34 AM  ,
|
