Why do you use python?
sk
interview?
a modified version might be:
"Where would you use python over C/C++/Java?"
(because my resume says I know C/C++/Java)?
Jaime Buelta
I also know C/C++/Java so...
I'd say that I can be much more productive in Python that in those
other languages.
I can do the same with , let's say, 5 lines of Python that with 15 or
20 lines of C/C++/Java (maybe a little less in Java), with much less
errors.
I can produce clear code, so it's easier to understand when other
person will look at it.
I can produce a prototype much faster
I can focus more on the problem and less on the coding...
I can make cross-platform code (well, also with Java)
I would use it as much as possible, but specially for:
* Complicated script-like actions, in spair of bash scripts, which
it's great for simple , OS related operations, but to manage workflow
it's sometimes confusing.
* Rapid prototyping. Check ideas.
* Tests automation
I try to use Python as often as possible, as my "default language", as
I think I can't be more productive, which it's usually the most
important parameter in software development. Of course, if there is a
good reason not to use it, then it's not the adequate tool. But But I
tend to ask myself "Is there a reason for not using Python?" instead
of "Is there a reason for using Python?"
Martin P. Hellwig
I would say where I can, where 'can' is depending on the problem,
already implementations and requirements.
On the other hand, when I go to a restaurant I usually don't tell the
chef which brand of knives he has to prepare my meal with, even though I
prefer Globals knives for my own use.
--
MPH
http://blog.dcuktec.com
'If consumed, best digested with added seasoning to own preference.'
Alf P. Steinbach
> [title "Why do you use python?]
The C++ FAQ addresses this question here:
<url: http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.5>
Cheers & hth.,
- Alf
Bruno Desthuilliers
> What would be your answer if this question is asked to you in an
> interview?
>
> a modified version might be:
> "Where would you use python over C/C++/Java?"
>
As far as I'm concerned, I'd put it the other way round : where would I
use C/C++/Java over Python ?-)
Jaime Buelta
Mphfffff
Even I have some agreement that the choice of a language it's more a
business-driven issue I REALLY don't like that the techie weenie
shouldn't be heard. Talks a guy that programmed a GUI on Motif using C
(plain old C) in 2003 and takes almost forever (one year and a half),
instead of using any other graphical toolkit because "we can't afford
to expend time on learning new languages"...
I think time to development (usually related to "mystical" bugs well
hidden in layers and layers of code) it's an important thing to take
into account.
TerryP
Python is a language I choose for any of several reasons:
0.) It is easy to setup dependent packages on both BSD, Linux, and
Windows
1.) Most important things already have a Python binding somewhere
2.) Working in Python is fun
3.) Python scripts are more portable between OSes then compiled
executables.
I find that Python makes me very productive, and lets me worry more
about the engineering side of the art. However, I'm just as happy
using C or a portable subset of sh. Unless it means writing Swing
layouts by hand.
Jaime Buelta
> On Sat, 31 Oct 2009 06:54:27 -0700 (PDT), Jaime Buelta
> <jaime.bue...@gmail.com> declaimed the following in
> gmane.comp.python.general:
>
> > shouldn't be heard. Talks a guy that programmed a GUI on Motif using C
> > (plain old C) in 2003 and takes almost forever (one year and a half),
>
>
> I emulated a Ramtek 9300 (think that was the model) graphics engine
> using GKS (for display lists, and ability to turn "layers" on/off
> without regenerating all the data) on top of plain DECWindows/Xt
> library, with no layout utility. Around 1990 (I date it by the fact
> that, on return from the 7 week two site deployment of the application,
> I decided my old cameras had gotten too burdensome, and bought a Canon
> EOS 10s, 35-105 & 100-300 lenses, and a photo vest that I could wear
> onto the flights)
>
> Emulation was needed as the data generation program had to have
> minimal changes -- we replaced the Ramtek library with a package that
> formatted the Ramtek instructions as text strings, sent them via VAX/VMS
> mailboxes to the emulation program... Oh, and the main data generation
> program really was a set of some 50 programs that were invoked in
> "random" order, each drawing certain data elements onto a single window
> -- so there had to be a common graphics application to maintain the
> window...
> --
> Wulfraed Dennis Lee Bieber KD6MOG
> wlfr...@ix.netcom.com HTTP://wlfraed.home.netcom.com/
Hahahaha, I souposse that I must consider myself EXTREMELY
lucky... ;-)
Anyway, each tool has its time, and we should try to use more-or-less
adequate and available tools of our time...
Simon Forman
Mark Miller has some adages posted on his homepage. [1] One of my
favorites is this:
"A Computer's Perspective on Moore's Law:
Humans are getting more expensive at an exponential rate."
Python saves you human-time.
Python allows you to write software that runs, is readable, can be
maintained and modified easily, etc... far better than any other
language I've ever used.
You can write working code, and read and understand already-written
code /faster/ in Python than any other language I've ever used.
Use Python. I would use C (to write Python extensions) only where
profiling had shown a definite hotspot, and then only when there were
no better algorithmic choices available. I would never use C++ or
Java.
(N.B. I've managed to be gainfully, and blissfully, employed
programming in Python for about six years now. I've passed on
otherwise interesting jobs because the folks involved were using
something other than Python.)
I'm actually working at a startup at the moment that originally hired
me to "do python" and then decided to use PHP because more of the team
(two out of three) knew it and didn't know python. I figured "what
the heck, it's been awhile, and it will look good on my resume" so I
have stuck with them.
PHP isn't as horrible as I remembered, but it's still horrible.
/Everything/ is horrible compared to Python. WTF is wrong with
people? (Disclaimer: Smalltalk and LISP are not horrible... *grin*)
Anyway, I wouldn't say all that in an interview, heh, but that's my $0.02.
My strong advice to you or any programmer is, don't bother
interviewing with a company that's not already committed to using
Python as their main language (modulo extraordinary circumstances.)
david
and I agree with your comments regarding python. I've turned down
recruiters who have offered otherwise interesting positions, but Java
was being used. This is just personal, and I'm not going to disparage
anyone who enjoys Java, C++, whatever. But for me, dynamic languages
(particularly python and Lisp) are so far ahead of anything else.
-- david
rhard...@gmail.com
i go to the job like the plumber; i have a toolbox full of hardware and software of my design that i use to solve client problems. what i dislike is the fact that some employers ONLY want to use python and nothing else. while i can appreciate the point that they are trying to get across, the fact is that solving real world problems sometimes takes other languages and approaches that cannot be easily done or not done at all in python.
instead, to be efficient, it is best to combine tools to solve problems that contain complexities where there is nothing available off the shelve that does the job. c# is free, free VS studio, i can run ironpython there, i can do python there, and talk to linux boxes with python, i can run c# on linux boxes using mono(did that back in 2004 and thereafter for a while). i can run python on my beaglebone black inside of snappy ubuntu, ect.
so i ask those employers why not use what is available to solve problems instead of limiting yourself to just one???
Chris Angelico
> instead, to be efficient, it is best to combine tools to solve problems that contain complexities where there is nothing available off the shelve that does the job. c# is free, free VS studio, i can run ironpython there, i can do python there, and talk to linux boxes with python, i can run c# on linux boxes using mono(did that back in 2004 and thereafter for a while). i can run python on my beaglebone black inside of snappy ubuntu, ect.
>
> so i ask those employers why not use what is available to solve problems instead of limiting yourself to just one???
else to maintain your hellspawn hodge-podge of languages, tools, and
libraries. (And yes, it will be described that way by the next person,
no matter how careful you are.) It's in their interests to restrict
its complexity at least a bit. I'm not sure what advantage you gain by
incorporating C# into the mix, but the *dis*advantage is that, forever
afterward, Visual Studio and Mono will be necessary to use and develop
this project. Every new thing needed is another thing that can go
wrong, another thing people need to learn, etc, etc.
So instead of treating programming like a plumber at a hardware store,
treat it like an artist with a canvas. You wouldn't normally see a
portrait done partly in watercolor and partly in oils - or if it is,
it's for a VERY deliberate effect. You'd more often see one style used
for one project, and maybe another one used for another.
ChrisA
Dan Sommers
I've worked on jobs where the tool or target operating sytem (singular)
was chosen first, or specified as part of the "system requirements," and
it can work out just as badly as a hellspawn hodge-podge of a solution.
We've all heard the one about all problems looking like nails.
It should, by now, go without saying, but choose the right tool (or
tools) for the job, where "right" includes any number of things *not*
related to its immediate implementation, and often includes some number
of things *counter* to an obviously superior, in one way or another,
implementation.
Mark Lawrence
suggest that the employers' main concern is Total Cost of Ownership.
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
Chris Angelico
>> So instead of treating programming like a plumber at a hardware store,
>> treat it like an artist with a canvas. You wouldn't normally see a
>> portrait done partly in watercolor and partly in oils - or if it is,
>> it's for a VERY deliberate effect. You'd more often see one style used
>> for one project, and maybe another one used for another.
>
> Both viewpoints must be tempered in order to create successful systems.
>
> I've worked on jobs where the tool or target operating sytem (singular)
> was chosen first, or specified as part of the "system requirements," and
> it can work out just as badly as a hellspawn hodge-podge of a solution.
> We've all heard the one about all problems looking like nails.
>
> It should, by now, go without saying, but choose the right tool (or
> tools) for the job, where "right" includes any number of things *not*
> related to its immediate implementation, and often includes some number
> of things *counter* to an obviously superior, in one way or another,
> implementation.
every additional tool used costs exponentially in complexity. And
people who claim they should use any tool whatsoever usually use "I
know this tool" as the most important criterion in the decision -
which results in the worst kind of hodge-podge.
Possibly the best way to handle it is to have to justify every new
tool you use to at least two other people, preferably people who have
never used it before.
ChrisA
Ben Finney
> True. I'm not saying you should never use more than one tool, but that
> every additional tool used costs exponentially in complexity. And
> people who claim they should use any tool whatsoever usually use "I
> know this tool" as the most important criterion in the decision -
> which results in the worst kind of hodge-podge.
choice of tool will impact others working on the same code base, either
contemporaneously or in the future.
If I choose to use Vim, and passionately defend that decision, this
choice of tool is unlikely to have much impact on my workmates or future
programmers.
Whereas if I pull the entire code base into a Subversion repository,
that choice will have a major impact on what others must to do
collaborate and work on the code base.
The more impact a choice of tool will have on others working on that
same code base, the less weight should be given to “what tool makes me
personally happy” and the more weight needs to be given to “what will
help people work together better on this code base”.
--
\ “Everyone is entitled to their own opinions, but they are not |
`\ entitled to their own facts.” —US Senator Pat Moynihan |
_o__) |
Ben Finney
sohca...@gmail.com
I use C/C++ when speed of execution is priority and I don't care about being cross-platform.
Though for what it's worth, I've only been a software engineer using Python for two years, and I have yet to use C/C++ outside of small personal projects and school.
