Feeds

back to article Python wraps its coils around the enterprise

The enterprise, long the stodgy bastion of mainframes, Oracle databases, and Windows servers, is starting to look a lot more like the consumer technology companies that eschew it. As enterprises embrace the web as a way to conduct business and manage employees, they're embracing the very technology stacks originally made popular …

COMMENTS

This topic is closed for new posts.

Page:

Silver badge
Thumb Up

Python talks to everything

Either there's a built-in module to do it, or you can find something on the net.

Plus, unlike Perl, you can read the source 6 months later, or someone else can understand/maintain/troubleshoot it without hours of going WTF?

I especially like the enforced indentation, because I'm tired of maintaining shit that's either totally not indented, or literally randomly indented, and usually there's not a handy indentation program that doesn't choke on the particular piece of code I have.

6
0
Ru
Paris Hilton

Re: "unlike Perl, you can read the source 6 months later"

Although Perl facilitates line-noise style programming, I'd argue that unreadable code can be written in any language. If you can't restrain your coders and you won't perform any sort of code review, you're bringing these problems upon yourself.

I'd have a hard job recommending Perl to anyone, however.

6
0
Silver badge

Re: Python talks to everything

Nah.. write-once code is possible in any language.

Python has some particularly compelling features for the dick-waving bad programmers who need to show their 1337 skillz. Dynamically altering the default values passed to methods is a great way of showing how brilliant you are, for instance. Also, creating instances of classes where no two instances share the same methods or members really impresses a maintainer (hey, why didn't you look up *why* we invented classes in the first place- testing for every fucking capability before you invoke it was pretty old back in X11, and it hasn't got more desirable since then). And, for extra nerd-points, why not wrap decision logic deep inside a nested list comprehension? I mean, that's where everyone expects to see it..

Against that, the language is simple enough, and easy to pick up, and mostly logical (apart from join(), of course... showing that technically correct is the worst kind of correct). But if you've come from any language that borrows its syntax from C, you'll be puzzled by what ++i does in Python. Look it up.. which brings me to the biggest drawback about Python, and it's nothing to do with the language.

There's a core of nutjobs out on the net who seem to have latched onto this one language in particular as if it's going to save civilisation. It isn't. There's also a strong tendency of telling people not how to achieve something, but exactly how the code should be stated: "But it's not Pythonic", is something you'll tire of reading. And the reason why you don't get any warning or error for the meaningless, impotent "++i"? Apparently it's your own fault for having known Other Languages. So there.

If you can put up with that kind of attitude every time you go looking for help, there's nothing wrong with Python, but do watch your declaration order, and get used to typing "self.". A lot.

And, while I'm sure the subhead was deliberately written to provoke just this response, here goes anyway: the name Python refers to "Monty", and not the family Pythonidae.

12
5
Bronze badge

Re: "unlike Perl, you can read the source 6 months later"

I'd have a hard job recommending Perl to anyone, however.

I'd be unable to recommend python in any way at all.

It forces you to layout your code in an unreadable manner.

And it hard-wired /usr/local/ (at least it did - I haven't checked recently) locations into the build (they were not an option), so obviously coded by one user of one user's setup, and hence unsuitable for general use.

And, just as you say you can write unreadable code in any language, you can write readable code in any language too. Except python (and, probably, APL).

1
8
Bronze badge

Re: Python talks to everything

@Kristian Walsh

I second all that. Plus the Global Interpreter Lock is a pretty poor construct these days. I mean, who's never heard of a thread blocking on I/O before?

Python has it's place, some fairly good things have been done in it pretty quickly. But for those who are planning on scaling up truly large it's worth looking at how others have done it.

Google and Amazon were C/C++ at their cores straight away. Facebook had to work out how to compile PHP in order to scale up (ironically by converting PHP to C++...). Twitter ran into scaling problems with Ruby and jumped ship (over a weekend apparently...) to SCALA, but they're only handling 140 characters at a time. NetFlix are C++ (AFAIK).

All those outfits are globally enourmous, and only Twitter seem to have avoided going to C++ one way or another. And it's obvious why. When one's datacentre(s) are vast and the energy costs sky high who wouldn't be prepared to spend a few $100k on programmers who can get you that extra few percent savings by going to the lowest level language that's viable?

1
2
Bronze badge
Angel

Re: Python talks to everything

I have used Python for both personal and in-company projects for the last four years, and I don't know a think about what you guys are talking.

I have known C/C++ for much longer than Python; the first time I tried i++ and it failed, I switched to i += 1 and never looked back. I don't remember ever trying ++i, playing with the order of increment and read operations is bad form anyway – for God's sake, that extra line of code you're trying to avoid isn't going to break the Internet.

It's also nice to know that integration with C/C++ is possible and not that hard to achieve, particularly if you rely on wrapping tools such as SWIG; though I've yet to use it myself, the interpreter's performance being good enough for my needs so far.

I've heard there are Python zealots somewhere, but have yet to meet any. Then again I'm not a very social coder, most of the advice I need can be found on reference docs, tutorials and forum threads (mostly from Stack Overflow) started by people other than me.

As for "dick-waving"-prone features, I've used some of them here and there, but "basic" Python is almost always enough – and I do a lot with it, from text file processing to COM interfacing with Windows applications, web pages and AI research on NumPy / SciPy. It's a matter of good-sense, knowing that just because you can do something, not necessarily you should do it every single time.

Overall what I enjoy most about Python is how it encourages writing clean, concise code (though of course you can mess it up if you really want); the speed with which you can slap together a proof-of-concept and then rework it into a practical solution; and the variety of packages and projects that make it a readily-available option for most things one might want to do. That you almost never have to do any changes to run programs on different platforms doesn't hurt either.

5
0
Anonymous Coward

Re: "the Global Interpreter Lock is a pretty poor construct these days"

Well, hold on there chief. If you genuinely need actual real threads, maybe. But non-blocking IO can be done perfectly well using coroutines/greenlets/green threads/lightweight processes or whatever else you want to call em; chunks of non-parallel co-operatively multitasking code. Multithreading is an easy way for you to screw stuf up in lots of subtle and unpleasant and hard to debug ways, and if all you need is nonblocking IO its a bit like using claymore mines to kill rabbits, to coin a slightly tortuous simile.

Everyone was all about the C++ cos for a long time it was the only game in town if you wanted to do seriously performant stuff. Nowadays though, people who aren't CPU bound generally find that there are all sorts of other options out there which are significantly easier to work with.

I'm not sure I buy you 'C++ saves you money on your datacentres' argument, but it seems like a tricky one to refute so I'll leave that one for another day ;-)

1
0
Thumb Up

Re: Python talks to everything

HERE HERE!!! Nail, meet hammer, on the head.

I am always fighting to get my developers to learn some basic style guidelines, to the point where I would happily trade away the benefit and just subjugate myself to the programming language.

0
0
Gold badge

Re: Python talks to everything

"I have known C/C++ for much longer than Python; the first time I tried i++ and it failed, I switched to i += 1 and never looked back."

I'm curious. Just *when* did you try i++ and see it fail? As far as I'm aware, there simply has never been a version of C, even in Dennis Ritchie's imagination that didn't support this with exactly the same semantics as the modern language. (Ironically, with your preferred form of "+=" you might be onto a loser if you go back far enough. The operator was originally written =+ but this quickly proved to be ambiguous and accident prone.) It does little for the credibility of the rest of your comment that you took two attempts to add 1 to a variable and shortly afterwards gave up on the language.

0
1
Bronze badge

Re: "the Global Interpreter Lock is a pretty poor construct these days"

"Well, hold on there chief. If you genuinely need actual real threads, maybe. But non-blocking IO can be done perfectly well using coroutines/greenlets/green threads/lightweight processes or whatever else you want to call em; chunks of non-parallel co-operatively multitasking code. "

My point really was that if there were very good reasons to use threads in Python then you're going to need something else too if you want to do blocking IO at the same time you want other threads to run. To have to resort to things like coroutines just to get round the issue of the GIL is crazy if all you want to do in a particular thread is read something from a socket whenever it cares to turn up. Makes writing something like a mult-theaded server unnecessarily painful.

To me it's just a symptom that the Python creators found solving the problem to be too hard (for exactly the reasons you outline about threads in general), so wisely didn't even try. By the by, I invite you to consider the relationship between NUMA, the pipe() function, and Intel's Quick Path Interconnect / AMD's HyperTransport. Once you understand that relationship threads become a *lot* easier, unless you're programming in Windows.

The point about C++ in the data centre is that if you're I/O bound then your CPU is too powerful for your needs so you're wasting electricity. It does mean that you can 'get away' with things like Python, Ruby, etc. which in turn may bring about genuine business benefits.

To get the best efficiency you want a CPU that's only just fast enough to keep your I/O fully utilised. And if you really optimise your code in C++ (hell, why not C?!) you can get away with a CPU that's just a little bit more modest. That makes a worthwhile difference to an electricity bill when you're the size of Google or Amazon. The trick I guess is to anticipate whether one's own data cente is ever going to have to scale that large and choose a language as appropriate at the right point in time; tricky.

0
0
Happy

Re: Python talks to everything

"I'm curious. Just *when* did you try i++ and see it fail? As far as I'm aware, there simply has never been a version of C, even in Dennis Ritchie's imagination that didn't support this with exactly the same semantics as the modern language. "

Maybe the O.P. refers to all the undefined or hard to get right behaviour surrounding legal statements incorporating prefic & postfix incrementin; especially when coupled with assignment.

0
0
FAIL

Re: "unlike Perl, you can read the source 6 months later"

Python makes code unreadable? What can't you read something unless it's all on one line or lacks anything resembling indentation?

If python excels over all languages in anything it would be readability.

0
1
FAIL

Re: Python talks to everything

What facebook does is irrelevant for 99% of businesses because they're never going to be as big as facebook. That's like recommending a lorry to someone needing something to take their food shopping home.

Google also use python btw because only moron would code everything in C++. You'd only use that where necessarry because otherwise it's a pita.

1
1
Bronze badge
Devil

Re: Python talks to everything

I'm curious. Just *when* did you try i++ and see it fail?

When I tried it on Python, which is not C, and therefore has no obligation to support it. And indeed, it doesn't.

So, realizing that i++ was not possible (on Python), I never bothered to try ++i either (on Python), and therefore never stumbled on whatever baffling results it produces (on Python).

On C / C++ I don't do much ++i either, because the kind of one-liners where it makes a difference are often too obscure and error-prone, and by the time I break them down into something safer and more readable, the relative order of the read and increment operations make no difference any longer.

0
0
Anonymous Coward

Re: "the Global Interpreter Lock is a pretty poor construct these days"

"To have to resort to things like coroutines just to get round the issue of the GIL is crazy if all you want to do in a particular thread is read something from a socket whenever it cares to turn up. Makes writing something like a mult-theaded[sic] server unnecessarily painful"

The fact that you are suggesting that coroutines or green threads are some sort of crazy last resort implies you are not very familiar with their use or function. To use conventional threading for IO is crazy. Conventional threading is great (for various values of great) fo when you need to perform CPU intensive tasks. Using a whole thread to do blocking IO when you want to do some other stuff in the background is absolutely crazy when you have alternatives; especially safer alternatives that don't suffer from synchronisation problems.

0
0

Re: only moron would code everything in C++

Ok, I am that moron, but you'll need to explain this to me in shorter words. My current app is 30K lines of C++. Most of this is back-end, admittedly, but why use a completely different language for the 2 or 3K lines of CGI code? What's the point? Why does CGI code even need to be interpreted? It doesn't: this is not an environment where rapid prototyping is important. what matters is that it's fast, it works, it's bullet-proof, it can be maintained, and that there's a large pool of programmers who can take it over. PHP is way down the list on all these criteria, and Perl doesn't even make it onto the list. I've got 130 lines of PHP, mainly because phpmailer is so convenient. The C++ CGI code is trivial to change and maintain, and recompiles in a few seconds with a single make.

@Matt Asay: "Java and .Net continue to rule the enterprise roost"... wish you'd told me that before I got started; it might have given me a chance to load Windows on the server.

0
0

This post has been deleted by its author

Gold badge
Happy

Re: When I tried it on Python

Ah, I see. A mis-parse on my part, then. Wretched language, English...

0
0
Anonymous Coward

Re: Python ...

FYI, Python + dJango, the easiest and fastest way to get going; It Just Works:

http://builtbyptm.com/blog/announcing-django-project-builder-v01/

0
0
Thumb Down

A scripting language vs. a low level language?

Two completely different things that operate in different domains.

As Gene says, a Python/Perl comparison would have been valid.

Very poor.

1
1
Silver badge

Re: A scripting language vs. a low level language?

Python and Java/.Net operate in pretty much the same domain on the server. And they are all either pre-parsed p-code compilers or JITs with a VM anyway so they are all scripting languages

0
0
Anonymous Coward

Re: A scripting language vs. a low level language?

Being run on a VM or through a JIT makes a language a 'scripting language'? Well, congrats on a) misunderstanding what a scripting language is, b) misunderstanding the point that the OP was trying to make.

The fact that the two of you are making the same mistake but casting it in two different lights would be entertaining, were it not for the fact that 'scripting language' is a phrase that seems to have been robbed of any meaning; I'm always grumpy when a perfectly reasonable linguistic tool is blunted through careless use.

4
1
Silver badge
Holmes

Re: A scripting language vs. a low level language?

Unfortunately, no-one knows what a scripting language is.

Riddle me this:

1) Is Groovy a scripting language?

2) How about if the code has been compiled into .class files?

3) How about when the code is available in text files that can be edited with and vi and the program is compiled at process startup?

4) How about when the process is running but checks code in text files for changes and reloads then on need?

1
0
Anonymous Coward

Re: A scripting language vs. a low level language?

1) No.

2) No.

3) No.

4) No.

There, that was easy.

0
0
Silver badge
Paris Hilton

Re: A scripting language vs. a low level language?

Such parochialism!

Pray tell what exactly is the magic water that you have to spray to scriptify stuff?

And will interpreted C++ code (e.g. used in the ROOT data visualization framework) work for you?

0
0
Gold badge

Re: There, that was easy

Sadly, case 3 describes pretty much how most web browsers handle Javascript these days. Obviously you are free to reject the suggestion that Javascript is a scripting language, but I suspect the majority of professional programmers would disagree with you there.

As for the article's claim that scripting languages are on the rise ... pah! In the absence of a formal definition, I would suggest that both UNIX shell scripts and Microsoft's wretched Visual Basic are scripting languages (even if the latter eventually allowed you to compile the code) and both probably still have more lines of code in operation on their respective systems than any of these "new-fangled" languages mentioned in the article.

0
0

Re: A scripting language vs. a low level language?

True but if you read the whole article you'd see it pointed (quite rightly) that scripting languages make more sense for web development. Sure you can use java but nearly all java frameworks are hell and maintainence and minor changes are hell and if you're not doing anything particularly grand you're taking more processing power and memory to do it in java.

0
2
Anonymous Coward

Re: Such parochialism!

Groovy is a perfectly capable language for developing whole, serious applications in. Contrast, say, unix shell scripts. Perhaps you might use Groovy for scripting, but then, you could use C for scripting too, and I don't think anyone would call that a scripting language either.

"And will interpreted C++ code (e.g. used in the ROOT data visualization framework) work for you?"

Interpreted C++ will work for anyone who also feels that glue sniffing is a reasonable idea.

1
0

Re: A scripting language vs. a low level language?

Exactly.

The reason scripting languages are used for more stuff these days is threefold - better cross-platform-ness, easier maintenance, and sheer horsepower on the servers. Of those, the third is most likely to have made the biggest difference. The other two are nice, but unless you can run that code fast enough to be useful then you're SOL.

0
1

This post has been deleted by its author

Re: Newer Languages?

Dot Not^WNet?

That's nearly as sad as writing 'M$'.

5
4

This post has been deleted by its author

Silver badge
Coat

Re: @Nick

Well you can try DotNyet (one of my faves)

0
0
Bronze badge

Re: Newer Languages?

Perhaps. But the poster does have a point regarding the dates, right?

0
0

Hmmm write an "enterprise" application in SpringMVC or in Django? Python wins hands-down for shallow learning curve, simplicity, and speed to market - and I'm a java developer!

5
0
Anonymous Coward

PHP is the Jenkem of gateway drugs

Python is doing well because it is a decent grown-up language that's not totally filled with warts (eg. Perl, PHP) and wasn't hamstrung by an underperforming implementation (eg. Ruby) and was designed from the outset to be a reasonable programming language (eg. unlike PHP). It has been around long enough to accrue a decent set of third party libraries which perform reasonably well. Hell, you can even use flavours of it on the CLR or JVM and make use of existing libraries there, too.

From that point of view its success isn't really surprising; not everyone gets into a tizzy about semantic whitespace, after all.

Me, I'm more of a fan of polyglot development. Using a reasonable dynamically typed language that can be closely and easily bound to a statically typed language is a powerful technique that makes it easy to combine rapid development with good performance. With Java/Scala in the static typing corner, and Clojure/Jython/JRuby/Rhino in the dynamic (or if you're a CLR user, C# and IronPython), you've got something a bit more compelling than either on its own. Single language systems aren't really so interesting or indeed desirable these days.

7
0
Boffin

Having developed code in perl, python and ruby, i can comments on a few things --

Perl is a more left-brain oriented scripting language and is very powerful. Its strength imho is thr fact that you dont have to play with data types...in my chaotic world of sys admin, that is very time-conserving.

Python is great, but i have used it to interface my unix systems with windows primarily...perl on unix, python-based gui apps on windows. Love its enforced indentation...hate the fact th regex doesnt work exactly like in perl...

Ruby (on rails) is great for quick mvc type development...autogenerates the sql as well. Imho, it is awesome for rapid prototyping..

2
0
Anonymous Coward

The problem with Python

It does suffer from the curse of script languages, which is that as an application grows, you eventually find you need to move to a different language, which is faster/easier to debug/some other reason.

The problem with Python, is that you can keep using it a lot longer than any other script language before you have to move. And when you do, the moving costs are a lot higher.

3
6
Anonymous Coward

Re: The problem with Python

Hmm, I don't think I'd dismiss Python as a scripting language; its primary use certainly isn't scripting these days (everyone tends towards shell scripts and perl, after all).

There are two problems, anyway. Firstly, assuming that you didn't choose your programming language because all the cool kids were using it (hello Ruby, circa 2007!) you should be unlikely to get bitten by critical failings of the language or the runtime. Python is quite performant, and if you've run the application into the ground and are looking for a new language, perhaps you should be looking long and hard at your architecture and development practises. We're not talking about moving away from old school C/C++ after all (where the benefits of a new language are very clear cut).

Secondly, perhaps you should consider using an architecture which facilitates easier changes of language. Not all python apps can be painlessly ported to JPython, but when you have done so you'll find it rather more straightfoward to reimplement parts of it in Java and limit future refactoring pain.

Unless of course your application is a horrible mess, in which case you'd probably have screwed everythng up regardless of the language you chose.

2
0
Megaphone

Use the right tool for the right job.

If you're looking for The One True Language to Do All Things, you're looking at the problem wrong. As Google, Weta, the Mozilla Foundation, CERN, and many, many other organizations have found, Python scales up to some huge work loads. The trick is to use it where it works well and choose other languages where it is appropriate to do so.

As a devoted Python fan, I'll be the first to admit that it does have its weaknesses. It was never meant to be a speed demon for writing code close to the metal, for one. Managing multiple threads can be a challenge, too, if you don't think through your design ahead of time. Even with these challenges, as I noted above there are plenty of organizations using Python to run some HUGE work loads. CERN, for one, uses it to manage hundreds of petabytes of data for analysis:

href=http://www.euroscipy.org/file/2202?vid=download

Python's strengths lie exactly where they should be to make long term maintenance of any application easy:

1) Python makes writing easy to read code easy to do. This is critical when you have to dive into a module that you haven't looked at for a long time or when taking over code maintenance from someone else. (Note: While some will argue that you can write easy to read code in any language, only the most stubborn will say that every language makes this task as easy as Python does.)

2) Python's native development environment and ease of writing code makes rapid prototyping almost trivially simple. For simple tasks, moving from a working prototype to production is much faster than in many other languages. As you noted as a weakness but I see as a strength, Python also allows a small scale application to grow quite large before it has to be replaced.

I see this as a strength, not a weakness, for two reasons. First, writing clean code in Python is easy enough that rewriting from scratch in a new design much less expensive than it would be in C or Java. Second, see reason #3:

3) Python has a wide range of predefined modules written in C that handle the heavy lifting for compute intensive tasks. Where such a module doesn't exist, Python makes it easy and computationally cheap to call out to other resources to handle those tasks. Which leads us to advantages #4 and #5:

4) Because it's so easy to call out to external resources, it's easy to rewrite just the performance pain points in a more appropriate language.

5) Because it's so easy to call out to external resources, it's easy to design an application from the ground up that uses Python to stitch together disparate sources to complete a task.

6) Finally, Python is popular enough and has been around long enough that there is a very large pool of battle hardened libraries already built for you. Outside of the obvious things like NumPy, SciPy, PyQt, Django, etc., a little googling will turn up plenty of options for just about any task.

So, don't worry about replacing an app written in Python. You won't. ;-) (kidding! sort of) You might replace some pieces over time, but doing so is so easy that you won't mind at all.

3
0
Happy

Re: The problem with Python

You are probably going about things in the wrong way if you advocate moving away from scripting as the problem gets huge or needs greater speed. Scripting languages like Ruby/Python/TCL allow you to get a working prototype out faster and give you something you can actually measure to find out where the problems lie.

Rather than a wholesale move to another language, scripting languages are built to interface with utilities written in other languages. If you know of a more performant tool for part of your task you have *measured* as being deficient in its script implementation then you could make another version that calls out to that library written in some other language. You can then test one version against the other for correctness as well as checking that you get your speed bump or whatever. Leave the scripting language in control of a larger application of many parts.

1
0

This post has been deleted by its author

Bronze badge

Year of the snake is 2013.

Although something has gone extremely wiggly with the caption on the main page, (as of 14:02 today) - or is it just Firefox?

0
0
Anonymous Coward

Re: Year of the snake is 2013.

Maybe, but I don't see any programming language based on dragons, either of the type that sits atop falcons, the type that addicts inhale, the type that is female and shouts a lot, the type that has a lot of money and likes to take the piss out of people's business ideas, or the type that's called a dragon 'coz it's always dragon people into its cave and chewin' 'em up.

Maybe someone should make one.

0
0

Job Trends from Indeed.com

Whose piss poor effort is this? Has someone been studying dodgy graphs 101? 6 is a 600% increase on 1, 1.1 million a 10% increase on 1 million, but 100,000 new jobs is a lot more than 5. Without seeing the actual numbers of jobs this graph is rubbish. The only reason for presenting data in a format like this is to hide the fact that there is no story in it.

12
0
Silver badge

c++ php .net java python?

okay, I can understand

php vs .net

java vs python

but what the hell is C++ doing in there?

3
1
Silver badge
Happy

Re: c++ php .net java python?

It's like being invited to a party where everyone is drinking cocktails except this one guy drinking beer.

I prefer to be that one guy :)

1
0
Bronze badge

Re: c++ php .net java python?

It's like being invited to a party where everyone is drinking cocktails except this one guy drinking beer. I prefer to be that one guy :)

Bad analogy. The C++ guy would be the one drinking white spirit, as both programming language and fluid cause similar levels of brain damage.

2
3
Silver badge

Re: c++ php .net java python?

The C++ guy would be the one around back with the distillery making all the brews for the cocktail drinkers.

4
0
Anonymous Coward

wait wut?

This has given developers unprecedented choice after years of basically a binary choice between Java or .Net.

uhm... what?

php has been around since 1995, ASP didn't enter the field until 1998.

And .net didn't appear until around 2002 so how the frack was it a binary choice between java and .net?

Going just by dates it shoudl be a binary choice between java and php. although I assume at the time both were released perl and cgi were more popular.

1
0

Page:

This topic is closed for new posts.