Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #105331 > unrolled thread

Re: Why do you use python?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Why do you use python? rharding64@gmail.com - 2016-03-20 20:59 -0700
    Re: Why do you use python? Chris Angelico <rosuav@gmail.com> - 2016-03-21 15:13 +1100
      Re: Why do you use python? Dan Sommers <dan@tombstonezero.net> - 2016-03-21 04:49 +0000
        Re: Why do you use python? Chris Angelico <rosuav@gmail.com> - 2016-03-21 16:09 +1100
        Re: Why do you use python? Ben Finney <ben+python@benfinney.id.au> - 2016-03-21 16:33 +1100
      Re: Why do you use python? mbg1708@planetmail.com - 2016-03-21 13:26 -0700
        Re: Why do you use python? Larry Martell <larry.martell@gmail.com> - 2016-03-21 16:45 -0400
    Re: Why do you use python? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-21 05:01 +0000

#105331 — Re: Why do you use python?

On Saturday, October 31, 2009 at 3:22:20 AM UTC-6, Martin P. Hellwig wrote:
> sk wrote:
> > 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?"
> > 
> > (because my resume says I know C/C++/Java)?
> 
> 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.'

here's what i tell employers and potential employers for next gig;

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???

[toc] | [next] | [standalone]

#105333

On Mon, Mar 21, 2016 at 2:59 PM,  <rharding64@gmail.com> wrote:
> 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???

Because you won't be there forever, and they'll have to find someone
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

[toc] | [prev] | [next] | [standalone]

#105334

On Mon, 21 Mar 2016 15:13:22 +1100, Chris Angelico wrote:

> On Mon, Mar 21, 2016 at 2:59 PM,  <rharding64@gmail.com> wrote:

>> 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???

> Because you won't be there forever, and they'll have to find someone
> 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.

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.

[toc] | [prev] | [next] | [standalone]

#105336

On Mon, Mar 21, 2016 at 3:49 PM, Dan Sommers <dan@tombstonezero.net> wrote:
>> 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.

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.

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

[toc] | [prev] | [next] | [standalone]

#105337

Chris Angelico <rosuav@gmail.com> writes:

> 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.

There is also an important distinction to draw on how much effect one's
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

[toc] | [prev] | [next] | [standalone]

#105405

On Monday, 21 March 2016 04:13:45 UTC, Chris Angelico  wrote:
> On Mon, Mar 21, 2016 at 2:59 PM,  <rharding64@gmail.com> wrote:
> > 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???
> 
> Because you won't be there forever, and they'll have to find someone
> 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

Spot on.  It's actually worse than Chris says.  I've had trouble with old code that I WROTE MYSELF.  Please don't tell me that I didn't try hard enough the first time......the only time to find that out is the second time!!

[toc] | [prev] | [next] | [standalone]

#105407

On Mon, Mar 21, 2016 at 4:26 PM,  <mbg1708@planetmail.com> wrote:
> On Monday, 21 March 2016 04:13:45 UTC, Chris Angelico  wrote:
>> On Mon, Mar 21, 2016 at 2:59 PM,  <rharding64@gmail.com> wrote:
>> > 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???
>>
>> Because you won't be there forever, and they'll have to find someone
>> 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
>
> Spot on.  It's actually worse than Chris says.  I've had trouble with old code that I WROTE MYSELF.  Please don't tell me that I didn't try hard enough the first time......the only time to find that out is the second time!!

https://xkcd.com/1421/

[toc] | [prev] | [next] | [standalone]

#105335

On 21/03/2016 03:59, rharding64@gmail.com wrote:
> On Saturday, October 31, 2009 at 3:22:20 AM UTC-6, Martin P. Hellwig wrote:
>> sk wrote:
>>> 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?"
>>>
>>> (because my resume says I know C/C++/Java)?
>>
>> 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.'
>
> here's what i tell employers and potential employers for next gig;
>
> 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???
>

I'm not quite sure why you've replied to a five year old thread, but I'd 
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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web