This is part of a series examining the strengths and weaknesses of
various scripting languages, with particular attention to enterprise
(read: big company) use.
You Used Python to Write WHAT?
Python is a powerful, easy-to-use scripting language suitable for use
in the enterprise, although it is not right for absolutely every use.
Python expert Martin Aspeli identifies when Python is the right
choice, and when another language might be a better option. http://www.cio.com/article/185350
Feb 20 '08
62  2921 
Paul Rubin wrote:
Jeff Schwab <je**@schwabcen ter.comwrites:
>So to use the Perl example: If you want to sort a list using some
arbitrary snippet of code as the comparison function, you can write:
sort { code to compare $a and $b } @elements
Yes, you can do that in Python, using a lambda expression, a named
function, or whatever.
You can indeed. I think you can also use this to do the other stuff you
would expect, e.g. return locally defined code snippets to define closures:
def mkadder(n):
return lambda x: x + n
I have gotten the impression that this was somehow inferior in Python
though, at least in terms of performance. Every time somebody uses
lambda here, they seem to get a bunch "why are you using lambda?"
responses. If I am grossly mistake, please just enlighten me.
>What language do you have in mind, in which lambda is more basic than
named definitions? Are you coming from a functional language
background?
All languages that I know of with lambda, treat it as more basic than
named definitions, e.g. the Lisp family (not sure if those count as
functional languages) in addition to functional languages like Haskell.
I note from your other posts that you seem to have a strong Lisp bent.
Lisp programmer and Smalltalk programmers stand out in the crowd. I
first noted this when somebody found a while-loop offensive, on the
grounds that recursion was somehow a more natural way to implement
looping. It can take a while to convince somebody like that they
different idioms work best in different languages.
Just some anecdotal confirmation:
In article <ma************ *************** ***********@pyt hon.org>,
"Ryan Ginstrom" <so******@ginst rom.comwrote:
I personally used C++ for about 90% of my code for 10 years. During that
time, I was chugging the C++ Kool-Aid so hard I almost peed myself. I still
think that C++ is a beautiful language, but I have also come to think that
starting a program with C++ is a premature optimization.
Yes, I came to the same conclusion and now start all projects in Python,
then add C/C++ extensions for optimization.
I think that very few Python programmers today started with Python. Most of
them came to Python for a reason.
Exactly right in my case. In fact this observation is directly related
to the one your the previous paragraph. Python is a good language in
which to start a progrom.
--
-- Lou Pecora
On Feb 21, 10:22 am, Nicola Musatti <nicola.musa... @gmail.comwrote :
On Feb 21, 6:31 pm, Paul Boddie <p...@boddie.or g.ukwrote:
The main reason why C++ has declined in usage is because almost
everything of practical value is optional.
No, disagree.
The main reason why C++ has declined in usage is because it never got
the kind of corporate marketing enjoyed by Java and C#.
I'm inclined to disagree for two reasons. C++ is a very complex
language. Java (and the later C#) less so. Couple that with reduced
debugging time due to garbage collection and fewer pointer problems, a
lot of us decided a factor of 2x in personal productivity was worth
it. Runtime was initially an impediment, and still is for desktop
applications, but the trade was worth it.
Corporate marketing, and corporate attention in general, saw to it
that Java was well equipped with libraries and frameworks addressing
enterprise application needs. ...but the *big* reason Java won over C+
+ is because your application became stable sooner. ...with arguably
fewer problems later.
And the migration to Python is due in large part because of an
additional factor of 3-4x in personal productivity (over Java).
Improvements in runtime performance wouldn't hurt, but for many
applications that's not an issue. (If optional data typing were
offered, Python's penetration in the enterprise space would be even
higher, and I suspect there would be performance gains as well.)
Larry
Larry Bugbee wrote:
And the migration to Python is due in large part because of an
additional factor of 3-4x in personal productivity (over Java).
Improvements in runtime performance wouldn't hurt, but for many
applications that's not an issue. (If optional data typing were
You mean static data typing, right? Are there any known holes in the
dynamic type system that still need to be plugged? (I haven't heard of
any.)
offered, Python's penetration in the enterprise space would be even
higher, and I suspect there would be performance gains as well.)
You mean static data typing, right? Are there any known holes in the
dynamic type system that still need to be plugged? (I haven't heard of
any.)
My apologies. You are right, I meant optional, static typing. Thanks
for the catch Jeff.
Python's dynamic typing is just fine. But if I know the type, I want
the ability to nail it. ...local variables, arguments, return values,
etc And if I don't know or care, I'd leave it to dynamic typing.
The need for a lot of doc goes away, those new to the language that
think it's a big deal can be explicit, and as I suggested earlier, I
think the byte code interpreter could be made a lot smarter and
faster. ...and corporate acceptance would follow.
Larry
PS: And tools like ShedSkin and Pyrex benefit.
On Feb 24, 9:14 pm, Larry Bugbee <ebug...@gmail. comwrote:
On Feb 21, 10:22 am, Nicola Musatti <nicola.musa... @gmail.comwrote :
On Feb 21, 6:31 pm, Paul Boddie <p...@boddie.or g.ukwrote:
The main reason why C++ has declined in usage is because almost
everything of practical value is optional.
No, disagree.
The main reason why C++ has declined in usage is because it never got
the kind of corporate marketing enjoyed by Java and C#.
I'm inclined to disagree for two reasons. C++ is a very complex
language. Java (and the later C#) less so. Couple that with reduced
debugging time due to garbage collection and fewer pointer problems, a
lot of us decided a factor of 2x in personal productivity was worth
it. Runtime was initially an impediment, and still is for desktop
applications, but the trade was worth it.
While this was probably true towards the end of the nineties, given
the standard library and Boost I find it hard to believe that a
similar increase can be accounted for just in terms of language
differences.
Corporate marketing, and corporate attention in general, saw to it
that Java was well equipped with libraries and frameworks addressing
enterprise application needs. ...but the *big* reason Java won over C+
+ is because your application became stable sooner. ...with arguably
fewer problems later.
The number of libraries you get "out of the box" appear to me as more
likely explanations for the productivity increase.
And the migration to Python is due in large part because of an
additional factor of 3-4x in personal productivity (over Java).
Improvements in runtime performance wouldn't hurt, but for many
applications that's not an issue. (If optional data typing were
offered, Python's penetration in the enterprise space would be even
higher, and I suspect there would be performance gains as well.)
This I found less hard to believe. Python is more expressive than Java
and usually requires less code for the same task. Moreover tha
availability of libraries is comparable.
Cheers,
Nicola Musatti
On Feb 25, 8:29 am, Nicola Musatti <nicola.musa... @gmail.comwrote :
On Feb 24, 9:14 pm, Larry Bugbee <ebug...@gmail. comwrote:
Corporate marketing, and corporate attention in general, saw to it
that Java was well equipped with libraries and frameworks addressing
enterprise application needs. ...but the *big* reason Java won over C+
+ is because your application became stable sooner. ...with arguably
fewer problems later.
The number of libraries you get "out of the box" appear to me as more
likely explanations for the productivity increase.
The productivity increase of the language appears to me as a more
likely explanation for the number of libraries you get "out of the
box".
:)
Carl Banks
Jeff Schwab wrote:
>You like managing your own memory, be my guest. But please don't
imply that you're putting forth less effort because of it. You're
just putting forth different effort.
I disagree with you completely. Your points don't make any sense to me
at all. I believe I am putting forth less effort by having a generic
resource-management infrastructure, rather than a memory-specific
language feature -- that's not just an implication, it's my honest belief.
Yet your belief is provably wrong. It's been realised by langauge developers
long time ago.
It's quite simple.
1. Your "generic" resource-management infrastructure is not generic to begin
with! It does not work for mutually dependant resources.
2. Your "generic" infrastructure increases burden on the programmer
everywhere any resorce (including trivial one like memory) is used, while
GC kills that burden in 95% of the cases. C++ish approach puts the notion
of ownership everywhere - both in 95% of cases where it's useless and in
remaining 5% where it's actually needed. That's not reduced effort by any
means.
3. You can't handle clean-up errors in reasonable way in C++ish approach, so
anything more complex should not by handled that way anyway.
rgds
--
"Never underestimate the power of human stupidity" -- L. Lang
On Feb 25, 3:17 pm, Carl Banks <pavlovevide... @gmail.comwrote :
On Feb 25, 8:29 am, Nicola Musatti <nicola.musa... @gmail.comwrote :
On Feb 24, 9:14 pm, Larry Bugbee <ebug...@gmail. comwrote:
Corporate marketing, and corporate attention in general, saw to it
that Java was well equipped with libraries and frameworks addressing
enterprise application needs. ...but the *big* reason Java won over C+
+ is because your application became stable sooner. ...with arguably
fewer problems later.
The number of libraries you get "out of the box" appear to me as more
likely explanations for the productivity increase.
The productivity increase of the language appears to me as a more
likely explanation for the number of libraries you get "out of the
box".
In the case of Python I suspect you have a point even without the
smiley, given how much of what's available was developed without any
major corporation's support. On the other hand, had the kind of money
that's been poured into Java and/or .NET been poured into *standard* C+
+, I dont' think it would be so far behind. Witness the kind of
libraries/framework that used to and still come with some commercial C+
+ implementation, and even some free/open source ones; Boost, ACE and
wxWidgets are the first that come to mind.
Cheers,
Nicola Musatti This thread has been closed and replies have been disabled. Please start a new discussion. |
