Python Moving into the Enterprise

Qa1 writes "Seems that Python is moving into the enterprise. At the recent PyCon it has become apparent that it's not just Google, GIS, Nokia or even Microsoft anymore. The article points out that Python is increasingly becoming a perfectly viable and even preferred choice for the enterprise. More and more companies are looking at Python as a good alternative to past favorites like Java. Will we finally be able to code for living in a language that's not painful? Exciting times!"

Comments

Which Enterpise

[Anonymous Coward]

TOS or TNG?

Jython?

[Crono]

Aren't some of them using Jython, which is really just Python on top of Java anyway.

Re:Jython?

[pogofish]

The Jython language is still (essentially) an older version of Python. Just because it runs in a Java VM and can integrate with Java classes doesn't moot the point about doing enterprise work by "coding in a language that isn't painful."

Re:Jython?

[hey!]

I don't find Java as a language painful.

It's the output of Java programmers that turns my stomach.

Re:Jython?

[hey!]

Well, my point is that more knowledge isn't necessarily a good thing, if it isn't coupled with judgment -- wisdom if you will.

I think the level of knowledge among Java programmers is impressive, but by in large I've found they aren't necessarily better programmers because of it. I've learned this the hard way, by hiring people with incredibly impressive knowledge of Java APIs, and then watching them struggle with overengineered designs that attempt to drag as much of that knowledge in as they can manage. I'm not going to make sweeping generalizations here, only to state that I've had bad experiences Java guys who prefer to wander lost in the wonderfully rich world of Java APIs and frameworks than focusing on a customer's problem.

Advantages?

[voss, sometimes...]

Im not a coder my self, altough I hahe programmed in Java and in python, but I fail to see Python's advantages comparing to Java in an enterprise environment.

Besides... wasn't Star Trek cancelled?

Re:Advantages?

[archeopterix]

Until you find out that you need to code most everything from scratch due to the lack of standardized libraries and frameworks, and you can throw the whole "productivity" argument out the window.

I'm curious about that, since my experience with Python is just the opposite - everything from http stack, unit testing framework to xml parsing is in the standard lib. Please name at least one area where Python standard library is lacking functionality.

Re:Advantages?

[NeoBeans]

Amsing site, but... it didn't answer the original question. It just shows a comparison of two "Hello World" programs.

The one thing that Java has going for it are "standard" APIs you can bank on. Is there a standard set of enterprise APIs for Python akin to J2EE?

And all of this isn't to say that one can't leverage both technologies where appropriate, even in commercial products...

Re:Advantages?

[afd8856]

Do yourself a favor and sacrifice 3 months of your life learning Zope & Plone. If you're into web development, it will pay off big at the end.

It's like: why build your own search engine, security engine, your own membership system, html form engine, templating system, cache engine, skin system, content types & custom types, etc, when you can just use zope & plone and get a complete framework with open source products and addons on which thousands already develop at the highest profesional level?

I admit that Plone and zope suffer from some documentation problem, but it's possible to overcome that. There are free books, available online (Zope book and The Definitive Guide to Plone) that can get you through. The documentation on Plone.org is getting very good. There are several code repositories (collective is one of them and some on zope.org) that have example products. Also, read the sources, they're not that hard to understand.

And before any of you jump and shout Booo!! ZODB, let me remind you that you can use just as well a reqular sql server to store your content information.

Re:Advantages?

[hey!]

Having used both, I'd say that Python is quite a bit terser than Java, which is very good in itself. Java is a bit pickier at compile time, which usually is a good thing.

Probably the biggest difference is that there are no checked exceptions in Python. Java has both checked exception and non-checked ("runtime") exceptions, but the normal type of exception used in practice is checked. A checked exception is compulsory for the caller to handle or to pass up.

In theory, a programmer using an API with checked exceptions has to consider all the things that could possibly go wrong. In reality, the idea you can catch every error before you get to testing is a pipe dream. You often don't know what you want to do with it until you have some empirical experience with your basic design. So you do one of two things -- either handle the exception in a half-assed but temporary manner (hoping you'll remember to come back and fix it later), or you pass the buck.

Since the best of these two alternative practices (passing the buck upward) is the better, that means that it is a lot of work to get traction -- you can create a facade layer to orchestrate all kinds of low level stuff, but there is a tendency for that low level stuff to bleed through your facade. Modern Java practice (within the last couple of years) has rediscoverd the runtime exception -- which works exactly like the Python exception. Hibernate 3, for example, uses runtime exceptions. Personally, I'll rip bleeding strips off flesh of one of my guys who does something stupid with an exception -- because it's so easy to just wrap it in a runtime exception (we have a wrapper class for this) and rethrow it. Throwing an exception in a tester's face leads to quicker fault discovery than papering it over.

I think the remaining difference between Python is that it's concept of collections are built-in, whereas the Java language only has generic objects and containers are built using this low level stuff. The resutl is that Python gets a big win when it comes to providing terse, convenient and easy to read syntax for processing all the elements in a collection. In programming terms, this task is about as common as dirt on a farm, and is a major win for Python.

I think Groovy may be more the way to go for Java shops looking for a productivity boost. Python has its own set of gotchas. Which is not to say it isn't quite good, but I'm not a big fan of the idea of combining Java and Python.

Re:Advantages?

[CrocketAndTubbs]

Its the package name for the class File. Similar to c++ namespaces. Its a CS thing dude.

That said, the grandparent poster was a bit disingenous. The File class is roughly equivalent to the stat function/structure in C. You can't read the file without creating an inputstream/reader.

So yes. You are correct. It is more verbose when doing simple operations. But I like to think that more complex operations fall together more easily.
Many programmers like to whip something out now. A quick "one off". Instead, often, with a little more time and more ground work, they can make something that is reusable.

In terms of the IO being verbose. Well its pretty flexible. 2 Interfaces (InputStream/OutputStream) are used for many different opertations. Read/write a file. Read/write to/from a socket. Read/write from a string or byte array. Read/write serialized object s to/from a file/socket/etc.... Its not just File IO. Its ALL IO. Long story short, that is why.

Good:

[TeleoMan]

Maybe it'll eat Archer's stupid little dog.

No such thing

[RicardoStaudt]

"Will we finally be able to code for living in a language that's not painful?"

Dude, programming for the enterprise without the pain is like the Passion of the Christ without the crucifiction... It's Impossible.
In that case, Perl should fit perfectly.

python performance

[khuber]

Python is a nice language, but it's excruciatingly slow. It's below Tcl on The Computer Language Shootout, which is telling.

Re:python performance

[Sweetshark]

The Computer Language Shootout is pretty useless - often there is a reference implementation in C and the task is to code the *same* algorithm in other language. This ignores the fact that there might be better ways to solve the problem in the other languages. Or in almost all languages. Just take a look at the fibonacci test - it a stupid useage of recursion, if your compiler doesnt optimize out all the duplication. Ok, that would be a nice feature, but it just shows "This language/compiler is good at optimizing bad written code".

Also you can make the shootout say almost anything, for example if you also calculate the code lines in and weight pidigits with a 4 multiplier, Python comes up as the best of the "serverside languages" (Perl, Python, Java, PHP ..)

Re:python performance

[The Famous Brett Wat]

I think that Python is supposed to be better in benchmarks not listed on that page, such as "mean time to correctly add a feature to unfamiliar code, written by someone who has since left the company".

Re:python performance

[Sweetshark]

If you feel you have better python code to perform a task on the benchmark, feel free to submit it.
Actually I tweaked around with the code - but the rule of the game are just wrong. Just look at the fibonacci test. It requires you to do the stuff completely recursively - thats one of the rules. So you not only generate a huge return stack, you also calculate all the fibonacci numbers far too often. This is just braindead. A good requirement would say: "Calculate the nth fibonacci number". A simple solution would be to start from the beginning and not recursively calulate every fibonacci number bazillion times.

Ok, the test description says that its task is to show the performance of recursion. But then they have to find a task where recursion is an merit - not a flaw. Otherwise you could claim your language is best because it has the best performing idle loops ....

Re:python performance

[goombah99]

Yes python falls in this weird crack between a scripting language and a high performance programming language. combines the slowness of perl with the inconvnience of structured programming. Its too structured and takes too many steps to be a good scritping language and too slow to be a programming language.

That being said I am enjoying it. I recently found I was writing a perl program that became unweidly in its comlpexity and impossible to maintain. So I converted to python. My reason for doing so was the existience of a nice matlab packages that allowed me the ability to recycle matlab code and make nice graphs. The syntax in python is cleaner with lets me do more complex array manipulations in the scientific envirnoment.

On the other hand I note that this syntactic sugar is simply a coating. FOr example, python implementes obects via an underlying hash just the same way perl does. But it hides it from view. Thus you get less flexibility in objects than perl and no real ability to optimize their speed since the access method is frozen in the syntax.

other things that trouble me are its seeming incompleteness of many of its metafors. For example, variables do spring into existence upon assignment but they dont auto initialize. Thus simmple things like counting the occurence frequency words in a file becomes a hassle since you have to either explicitly initialize every hashkey value to zero, or use one of the slow accessor methods (like .get()) that introduce huge perofrmance penalties. And the method of doing this is different for arrays, hashes, and scalars. auto-instantiation is somewhat dangerous too since a typo can now become an error without some means of declaring a variable name was meant to exist (e.g. the perl "my" statement).

Related to the lack of auto-initialization is the tendency to rely on the crutch of throwing exception rather than returning default values or signals that allow the progammer to decide if it's worth throwing an exception. I find I end up wrapping too many inner loop clauses in "try" statements. If operations that failed simply returned "None" or zero as appros many things could be simplified without any loss of ability to use exceptions properly.

other incomplete features are a lack of consistency on when an intrinsic operation is done in-place or returns the result. for example .sort() is done in place while .ltrim() is not. While one might wish to argue that space issues can require in-place operations, it woul dbe better to detect when an operation can be done in place from the syntax: a = a.sort() should be done inplace. b = a.sort() should not modify "a".

typcasting also seems to be incomplete as well. Take for example the casting of strings to integers. try this: i= int(45.3); i = int('45') ; i = int('45.3'). The first two casts work. the last one is an error. Why? I note .atoi() also fails in the same way.

My final lament about unfinshed python is the screaming lack of a decent syntax chekcer. Too many of its errors occur at runtime. It's weird that its the low level syntax of python that seems so unbaked. The high level imports are luxurious indeed and are a major attraction of the language. Having a conveinent operation like "shelve" for persistence takes enormous pain out of coding (now if 'shelve' could just use objects rather than olny strings for keys it would be complete).

My hope is that someday python will take advantage of the syntactic sugar to imlpement objects in a faster way under the hood.

all in all I do like python because it's a lot simpler to get the job done than Java or C++. If you know perl then python is useless as a scrpting language (sadly pathetic really) but if you dont know perl then python must seem like a fantastic scripting language if you are coming from C++.

Re:python performance

[Wavicle]

Ok, the test description says that its task is to show the performance of recursion. But then they have to find a task where recursion is an merit - not a flaw.

Can you establish that more fully? How is testing say, a recursive-descent parser, going to be a more valid test of recursion than a recursive solution for fibonacci numbers?

Fibonacci is convenient because you get lots of recursive calls while only hitting the stack, and no integer overflow. If you were to use a recursive parser and python ended up slower than the others, you could easily blame it on the non-recursive work you were doing. The fibonacci example allows you to accurately describe the recursive performance without all that other stuff getting in the way.

Re:python performance

[zorander]

I agree with a lot of what you are saying, though it doesn't tend to stop me from using python.

If you want a language that's consistently unsurprising and surprisingly efficient, then try ruby. Performance is not a dream, but that's what compiled languages are for. It lacks most of python's inconsistencies and is really quite pleasant to work with. in ruby there are two sort methods, sort and sort!. One does it in place and one returns a new list. (the ! suffix for mutation and ? suffix for predicates is a gem. I'm pretty sure it was stolen from scheme. It really, really helps make your code clearer)

I still find python more practical for large projects, though, because of the large library and potential for rapid development. I generally use python (possibly with C underpinnings) for larger apps and ruby (with its perl heritage) for scripting. Blocks are the greates when you're dealing with ssh sessions, opening and closing files/database connections, etc. As for per,l I've generally avoided after a few bad experiences trying to decipher six month old code. I really don't think it has a place when ruby has most of its features and enough of it's syntax along with the slickest object system around short of smalltalk.

Re:python performance

[Bob9113]

Clearly everyone missed my point, so I'll clarify.

I was using an example from the real world to point out why 3 seconds matters. In any significant application there will be some processes that are sufficiently complicated that the choice of algorithm or choice of language will lead to a 3 second delta one way or another. There will also be places where adding a UI shortcut will save 3 seconds.

The real world example talks about UI shortcuts that can save those 3 seconds, and Python makes it easier (according to the common wisdom) to add features. Other languages are more performance centric, and make it easy to save those 3 seconds in operation intensive sections of the code.

I wasn't arguing that Python is bad because it's not as performant. I was saying that both CPU performance and UI friendliness are important, so choosing between Python, Ruby, C#, Java, C++, C or any other language on the spectrum is a question of weighing values.

Ferfucksake people, stop trying to be argumentative and start trying to understand what people are saying. We all claim to be so smart, is our only ability with our intelligence to pick nits? Or can we use our intelligence to seek mutual understanding?

I mean, I can see why the media is turning into a bunch of ranting extremists - they're just a mirror reflecting our own horrible image.

Feh.

Toolsets

[justanyone]

I work at an Application Service Provider startup with 16 employees (5 developers) using Python (30K lines+).

I have 6 years of Perl development plus another 8 in C. So, a newcomer to Python (about 2 months now), I have several reactions shaded by that experience:
* Nice syntax: Not perfect, but very passable overall.
* Love the no-brackets: Indentation as a means of delineating code blocks is great; there's no debate over where to put squiggly braces (the 'if test { statement; } stuff;
* Immature toolsets: there are very few mature toolsets yet. We're using SQLObject, which is in version 0.6, as an object-relational-mapper. It's got some limitations and is admittedly not 'enterprise ready'. it's hard to compare to the Perl DBI because the dbi just is an interface and doesn't do mapping.
* Lack of CPAN: the single most fantastic "tool" I've found in my programming career (15 years) has been CPAN. Got a problem? Someone has probably already seen it and started a solution. I know this is in the works for Python but the tools are not all there yet.
* Syntax (bad): Lack of a requirement to declare vars before use. I really would like the ability to require that all vars are explicitly declared before being assigned to. it would help coding reliability.

Just my 5 cents.
-- Kevin

Re:Toolsets

[Ursus Maximus]

Kevin wrote:
Syntax (bad): Lack of a requirement to declare vars before use. I really would like the ability to require that all vars are explicitly declared before being assigned to. it would help coding reliability.

Actually, Guido von Rossum (the Creator of Python) is working on optional declaration of variables for a future version of Python. Although some Pythonistas are annoyed, it may give folks like you, Kevin, the best of both worlds. There is discussion on comp.lang.python about this from time to time, but it certainly appears as though Guido may take action soon;-))).

Ron Stephens
Python Learning Foundation
http://www.awaretek.com/plf.html

sigh... how about a real opinion?

[paRcat]

The first dozen replies are all trolls, so I'll add my experiences for posterity's sake.

I've been using python for pretty much anything in my company that isn't web based, and things couldn't be better. There's talk about python being slower, which it is, but most libraries that do important things are just C wrappers anyway, so the speed decrease is negligible as python is just holding the logic. Tk is nice enough, I guess, but I tend to use wxPython. Either way, it gives you cross platform GUIs, which is always a nice thing. Using pyexe allows you to even 'compile' scripts into exe files with win32 machines.

To be absolutely honest though, I can't think of an easier language to learn (I even teach >40 yo women now and then!) or a quicker language to code in. Once you're accustomed to it, the code just flows out, and I've seldom been disappointed by the results. The formatting requirement helps to ensure that your code isn't a disgusting mess that no one can figure out, YMMV.

Yes, but what about the GUI - speed no problem

[bblazer]

While I agree wholeheartedly that python is a wonderful language to code in, I think that it lacks a sting GUI system. Yes wxPython is cross-platform, but without getting overly detailed here, it definately lacks the detail and robustness of SWT or even Swing. Until wxPython can stand up to those, I think the movement to it for more broad based use with be a bit slow. As far as apeed goes, who cares? We are not programming for 286 machines anymore!

Re:Yes, but what about the GUI - speed no problem

[costas]

Agreed on wxPy, but you do know that SWT and Swing are scriptable from python thru Jython (or the Python-Java bridge project, forget the name right now)? IIRC there has also been an effort to wrap the native SWT widgets in python w/o going thru Java, which would be awesome.

But overall, I completely agree: the std python distro needs to standardize on wx, get rid of Tk and at least incorporate the win32all distribution in the win32 version (it just too nice to leave out).

My biggest peeve as a long-time pythonista (the newsbot in my sig is 25k+ LOC of pure Python) is the standard library: I can live w/o a CPAN-like repository (although that would rock), but for a language that used to boast that it comes "with batteries included" the std lib has gone downhill in the last few versions: too many overlapping or competing modules (why, why do we need httplib, httplib2 and urllib?? or getopt and optparse? and what are the differences between them?) and not enough attention into polishing the library into the fantastic toolkit that was around the 1.5 or early 2.1 series.

Someone, probably the BDFL, needs to stand up and take obsolete modules *out* of the standard library, so that the better ones can be improved even more, instead of having various tweaks and improvements going into overlapping modules. That's the point of having a *standard* library after all...

I'd rather have a good std lib than function decorators and other exotic language constructs...

Re:A quick check on Dice.com

[jimicus]

Had you done the same test 8 years ago but searched for Java versus C/C++, you'd probably have seen the exact same results.

Three barriers to enterprise Python

[blackhedd]

1) The twenty minute problem
Many programmers, including top ones like Eric Raymond http://www.linuxjournal.com/article/3882, are so put off by Python's use of whitespace as a block delimiter that they swear never to touch the language. In my case, this lasted for two years. You need to spend twenty minutes learning the language, after which the whitespace stops being a problem and starts looking like one of the many great ideas in the language. The challenge is getting people past their initial disgust enough to try it.
2) Misperceptions about typing
Many people think agile languages like Python and Ruby are not strongly typed and therefore present scalability problems and can't be used reliably by large teams. But Python and Ruby are strongly typed (unlike Perl)- you don't get type conversions you don't ask for. The real distinction is that the agile languages are dynamically typed rather than statically typed like Java/C++. To truly grasp the notions of "duck-typing" and lazy evaluation of types is as much a stretch as it was to "get" objects for those of us who were around 15 years ago- it's a basic change in how you think. You'll know when you're there, because you'll see in a flash that Java's static type declarations are not only redundant and painful, but they are also in themselves a key source of brittleness in large programs over time.
3) The youngsters' problem
This is probably the biggest barrier: university CS departments have become nothing but Java training courses. In trying to better prepare grads for actual careers, they have added a lot of basic business teaching, which is good. But they no longer bother to give students a real understanding of actual computer science, sticking instead to a cookbook approach using Java. So young people arrive in enterprise IT shops knowing nothing but Java and thinking they know everything, so they are not open to anything requiring a different intellectual approach.

Re:Too bad...

[zootm]

"Processors are cheap." and "Disk space is cheap." are horrendous excuses for bad programming. If you have used these expressions to justify your application, you are a bad programmer!

"Bad programming" has many points to it. I'd include using an old-fashioned language like C or C++ in a system which does not require huge speed or efficiency (which is almost everything these days). It increases the development time of a project, increases the code complexity, increases the chances of runtime bugs, and increases the potential severity of what bugs you do have.

I'm sorry, but the "but it's slow" argument does not hold for most software designed today. Let's please get over it.

We will start to see alot more of it..

[codepunk]

Soon as the qt windows free version starts shipping I think we will see alot of renewed development of gui stuff in python. Currently wxwindows exists but it is a little funky to program in if you ask me. A good industrial strength redily available qt is going to move alot of things.

It is a great language we use it for everything, web services, linux / win integration, nt services, automation etc.

Re:Python *is* painful

[justanyone]

Curly braces { } have always been a stylistic thorn in the side of C, C++, and now Java programmers. I'm sure other languages use them, too.

The old K&R style of doing:

if (test) {
expression;
}

versus:

if (test)
{
expression;
}

this is NASTY in the debates it causes and wars people fight over which is 'right' or 'easier'. For those who don't know, Python doesn't use braces, it uses any consistent indent, as in:

if (test)
expression

Very simple. Reduces line count by 1 or 2 and completely removes the religious debate about brace location. I really like this. There's enough problems debating what the code header/copyright/IDENTIFICATION DIVISION (grin) section's going to look like. "I like #####!" "No, I like #-------!!!", "You Suck!" "No, You Suck!" etc.

Don't knock the lack of braces until you try it. it really does make the code look cleaner.

--Kevin

Why is whitespace significance a good thing?

[OblongPlatypus]

One thing I've never been able to grasp is why Python proponents always mention the fact that whitespace is significant as a good thing. I guess it could be argued that at least it's not a bad thing, in which case it boils down to a matter of personal taste, but everyone seems to be saying it makes reading unfamiliar Python code so much easier.

Well, with any other language, if I get a piece of unfamiliar code and have problems reading it due to weird indentation, I just run it through Emacs' indent-region. Can anyone explain to me why this is not just as viable as mandating the indentation policy by embedding it in the language's syntax?

Re:Why is whitespace significance a good thing?

[krumms]

One thing I've never been able to grasp is why Python proponents always mention the fact that whitespace is significant as a good thing.

Whitespace (or more specifically, indentation) significance forces you to make the visual structure of your code match its semantic structure.

Java / Python / Ruby

[linuxbaby]

This article confirms it...

• Ruby is the new Python
• Python is the new Java
• Java is the new COBOL

:-)
(found many places online...)

Re:Too bad...

[FreeLinux]

What's the point in spending several times the develeopment effort on making it work properly instead of adding polish or just doing new stuff?

What's the point of making it work properly?!?!? Surely you have mis-spoken here.

Let's play a game. Let's suppose a bunch of little apps for which speed is not a critical factor for any one of them. As a forinstance, look at all those apps presently running in the system tray. Let's suppose that those apps are written badly or are written in inefficient languages. That shouldn't be too much of a stretch.

Now, let's try to do something. Whether you are trying to run a realtime application like desktop video conferencing or create a document in a word processor, it doesn't really matter. What ever it is that you try will be a struggle because the system's resources (CPU cycles, memory, swap space) are consumed by all those "noncritical" apps and their inefficiencies. A 1Ghz processor with 1 gig of RAM is no longer adequate? That's ridiculous! And yet, that is where we are at today.

Everyone seems to feel that their "Ultimate MP3 player" is the only app in the world or at least the only one that will ever be run on a machine. They don't think that speed and size are important. After all, they have a very powerful machine at their disposal with oodles of available resources, right?. They fail to realize that their program, no matter how wonderful, is only one of countless others that are all running at the same time and are required to share the resources. They fail to realize that their app may not be too slow when run by itself but, it becomes too slow when run with everything else.

Today, the preferred system is 3Ghz, 64bit, with at least 2 gigs of RAM. Why? What's the point of such a powerful system? Speed! That's the point. Speed is important. Code efficiency is important. But, as programmers continue to deny this and produce poorly written and bloated/slow apps or use inefficient languages, the time will come when a 6Ghz processor is not enough. Doesn't that sound stupid?

Kill the GIL (Global Interpreter Lock)

[hagbard5235]

I love python. It's by far my prefered language for development, but it has one major impediment that makes it very hard to take seriously in many rolls in an enterprise: the GIL (global interpreter lock).

You see Python has quite good support for threads, but there are a number of operations in the interpreter that are hacked into being thread safe by providing a global lock on the whole interpreter. One of them is reference counts on objects. So everytime I do an assignment, I have to queue for the GIL. This effectively means that I only really run one thread at a time, even if I have multiple CPUs in the box (or soon, multiple cores).

As more and more applications start shifting to multicpu (or multicore boxes) this problem becomes a much more noticable issue.

Kill the GIL.

Re:Python *is* painful

[rbarreira]

If I read another comment talking about the fucking lack of braces I'm going to punch the monitor... Why are people giving that so much weight instead of discussing the features of the languages instead?

And who cares about the programmers discussing brace placing styles? They'll surely find other things to discuss about with Python...

Re:Too bad...

[Hast]

What's the point of making it work properly?!?!? Surely you have mis-spoken here.

Another poster already made a clarification on this. I didn't "mis-speak" I was just a bit obscure with my meaning. Point being, if you code in C/C++ you'll spend a lot of time making the program work correctly. If you write in eg Java or Python you can get the program working correctly in a fraction of the time. This means you can add polish or move on to new stuff.

Point being, you are more productive in other languages as you don't have to mess with the details so much.

Whether you are trying to run a realtime application like desktop video conferencing or create a document in a word processor, it doesn't really matter. What ever it is that you try will be a struggle because the system's resources (CPU cycles, memory, swap space) are consumed by all those "noncritical" apps and their inefficiencies

First off, I'm willing to bet that virtually none of the little apps you currently have running are written in Java/Python whatnot. A sloppy coder can leak memeory in any language. (In fact I'd say it's a lot easier to leak memory in a language without a GC.) So moving to C/C++ doesn't really fix the memory issue.

That they consume enourmous amounts of CPU is also not really true. Those processes I have running on my machine all go in at 0% CPU time. If you add them together they might reach a few percent. Not really something which will stop you from typing in Word.

The fix for this "problem" is to get an OS with a descent scheduler so you can prioritise processes properly. That way your real-time applications won't suffer because your little application wants to check for new mail.

What's the point of such a powerful system? Speed! That's the point. Speed is important.

No, bragging to your friends that you can get 180 FPS in Doom3 is important. Very few people actually need a 3GHz 64-bit CPU with 2GB memory, I have one and I sure as hell don't need it.

And while code has become more bloated and unoptimised by the years a lot of that is because today a computer can do quite a hell of a lot more than say 10 years ago. Is all of that necessary stuff? Hell no! Is it more fun? Hell yes!

Finally there is one specific area of consumer software that actually demands better computers. That is games. Interestingly enough that area also have many of the best coders.

Re:Purpose of dynamic types?

[Ambassador Kosh]

One of the benefits is in things like duck typing. Often you don't care what kind of object something is so long as it has some certain method. To put it in a practical way I work with zope which is a python based app server which has an object database as part of it. Often I will run queries and get objects back. Most of the time I don't care if it is a file, picture, dtml document, or any of the many other types in the db all I care is that it has an id and it is willing to draw its url. Those are the conditions I have for working with the object.

So you work with objects by interface rather then by type. The interface also does not have to be a complete interface. You can implement as much of the interface as you need for something. I have some objects that are not lists and can not be used as lists however I have implemented some methods that make it so you can iterate over them like lists and slice them like lists.

This makes many tasks far simpler and encourages more regularity in usage.

How do you check if a substring is in a string, an item in a sequence, a key in dictionary etc? How do you iterate over them? In python it is all the same. if substing in string, if item in seq, if key in dict and the for character in string, for item in seq, for key in dict, for line in file, etc etc etc.

Types are nice but the types the static compilers have are not the types my apps use. The static type systems just end up costing me more time to develop working apps with then the dynamic typing systems and you have to test the product anyways.