Slashdot Mirror
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!"
TOS or TNG?
Aren't some of them using Jython, which is really just Python on top of Java anyway.
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?
Maybe it'll eat Archer's stupid little dog.
$6.21 is the number of the beast before sales tax. Meh.
"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 is a nice language, but it's excruciatingly slow. It's below Tcl on The Computer Language Shootout, which is telling.
I don't know whether to be happy or afraid.
...Monty Python was merging with Enterprise? Now there's a show I'd like to see... :)
I had a mental image of a new member of starfleet with an odd name..
. ,it is easy to learn and has a massive collection of librarys for many difrent things , infact i am suprised it has not happend sooner .
However seeing python moving into the enterprise market would be grand
Python has really come on in strides in the past few years
The only things certain in war are Propaganda and Death. You can never be sure which is which though
and Cameron Laird is an unabashed Python booster who's been writing the same booster prose for years. You're actually arguing Python is ready for the enterprise because Cameron Laird went to a Python conference full of Python boosters and saw they were just like him?
Timothy, you may want to check out the definition of "echo chamber."
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
Unitarian Church: Freethinkers Congregate!
Sorry guys; April Fools' was two days ago.
Donald Ferrone, Ph.D
Professor of computer science
http://www.geocities.com/donald_ferrone/
Star date 3042005 , we have recently encounter a strange spacial disturbance , The computers logs seem alterd and for some odd reason the Starfleet logo on the lcars monitors is replaced by a cartoon snake . Voice commands have been replaced with typing #! /usr/bin/env python
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.
no matter what cool features it has nothing is going to make me want to code in a language where you have to bung the self reference into the signature of class methods.
php is annoying enough with $this-> accesses to everything
can't somebody spend a bit more time on the basics?
Python has a reputation for being quick to program in. If you just speak basic python, you can program the same stuff you could in qbasic. It is very comparable to Visual Basic at that level. I find it very good for quick-and-dirty stuff.
The difference from the simpler languages is that it can do very difficult things. Once you get used to some of its unique features (I remember how thrilled I was to discover dictionaries) you can put serious applications together a lot faster than with other languages.
The bottom line is that you can do serious applications a lot faster than you can with other languages. In a business environment, that translates to profit.
p.s. "Integrated development environments (IDEs) are also more numerous than polished." Yep, I use emacs.
Marketing and support , Python is in dire need of some big name support , This is one of the primary reason Java became such a large player in the enterprise market .
The only things certain in war are Propaganda and Death. You can never be sure which is which though
I know that Java is used to push realtime market/financial data to a possible countless number of hosts. One only has to visit http://www.refcofx.com/FinanceChart.html?symbol=EU R/USD to see java in action, (assuming the java runtime is installed). Can one use Python to do the same? Where would it play its role? The backend or on client machines?
Yes.
for Python jobs. It returned 312 jobs. Java returned 9196. I don't think Python will ever dent Java's dominance in the enterprise. Do you really expect Python to do what .NET has failed to do? Not a chance. It is a cute scripting language. No more and no less. Python competes with Perl and Ruby.
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!
My
It seems Google is using Python for a good deal of stuff... And I thought google was enteprise
Assembling etherkillers for fun an profit
Happy. It's open, and could be a sign that MS is actually "getting it".
I wonder if anyone said that when they introduced IE.
Who in the 90's writes a language where whitespace has meaning???
11*43+456^2
...then why is it found in nearly every Linux distribution? ...and why is there ActivePython? BTW, I've used this with "classic ASP" and, not unlike JScript, it makes it almost a tolerable environment to use it in.
List comprehensions rule.
Il n'y a pas de Planet B.
Not that I think Java is the ideal example of a modern programming language (far from it), but this trend towards 'lean' scripting languages where almost every bit of rubbish you can write is executable, and every bit of code you look back at (even your own code two days later) looks like rubbish is really troubling.
Is it just because there are more and more people writing code who've never had to work on maintaing large-scale software?
had you used something other than a 6sided die your results would be different.
Besides Python is evil, why would i use that which poisoned eden.
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.
I'm sorry, but the "but it's slow" argument does not hold for most software designed today. Let's please get over it.
I'm glad to hear it. Python is amazing, and I'd like to see it get the credit it deserves. Whenever I do a big project in it, I'd say I spend about %3 of the time I spend with other languages debugging. About half of that is time spent telling people about how much I love python, because I'm always blown away when every drastically complex feature I implement works perfectly on the first shot. Regarding speed, I've never checked them out, but I'm told there are several ways to dramatically optimize normal python code. Psyco, for instance.
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.
Got Code?
Is it possible to use Python with Mac OS X's developer tools and build GUI applications?
For good measure, let's look at the documentation from a J2EE vendor here.
While PEAK sounds intriguing, I'm not sure that major projects started by Fortune 100 globals will leverage a technology that lacks the level of documentation quality you can find in other products in that space.
I bring this up because documentation is often an indicator of the level of quality you can expect in terms of support. This is not to say PEAK is bad or poorly written, just that the supporting documentation and resources don't match those available for J2EE implementations.
Remember -- it isn't the best technology that wins, but the technology that is most accessible. In the case of enterprise APIs, even though PEAK may be easier and more scalable (and this is an excerpt from their page): But PEAK is different from J2EE: it's a single, free implementation of simpler API's based on an easier-to-use language that can nonetheless scale with better performance than J2EE. ...it will need some time and some nurturing in order to compete for mindshare with developers and non-technical decision makers.
C is faster then Python?
Lets see a performance of data-entry GUI apps for a PostgreSQL database, and in addition you need to export queries over a VPN to a MySQL database used in the backend on a clients website.
Oh, and it has to be cross platform.
Person A gets to use C or C++
Person B gets to use Python
They both are equaly experianced programmers.
Lets see who gets it done faster and who is more likely to have bugs and other issues!
Then the newer pythons allow you to import from a zip. That needs polish, there should be a standard way to package a whole app in a zip (just to make it harder to screw up the file distribution. Having a single unit that contains all the needed code is a huge positive; it's just that much harder to screw stuff up.
Then there are people working on compiler speed, really it isn't as bad as you might think from some of the benchmarks. It can use some improvment though and people are working on it.
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?
-- If no truths are spoken then no lies can hide --
I remember when I first heard of Python back in grad school. I wondered what would become of it, but didn't have time to deal with it at the time, after all FORTRAN was teh cool, right? Lately, since I started using Zope, which is written in Python, and more recently Plone, which is built on Zope, I've really gained a great appreciation for Python because it really has made building sophisticated logic for web apps a lot easier than some alternatives. Now admittedly, I did not choose any of these because I heard they were easy or even cool, I stumbled into Zope because of an app, OIO, that I thought I could build on for another project. Later I heard about Plone and decided that I could build an easier to use portal for clinical investigators using that rather than PHP based solutions like PHP-Nuke. Python was just the icing on the cake as I discovered how much I could do with it.
To the making of books there is no end, so let's get started
Call me when Python has CPAN's 7848 modules. Then we can talk about "productivity".
-- Given enough time and money, Microsoft will eventualy invent UNIX.
Set phasers for stun.
The toad can't burp - and for some reason can't fart either, so it swells up and eventually explodes. --Anonymous Coward
I mean "J2EE" is a good name, but the Python equivilent "PEE", is missing something.
For some strange reason, I, suddenly, have to use the bathroom...
If Mr. Edison had thought smarter he wouldn't sweat as much. --Nikola Tesla
Obligatory PC Weenies webcomic about one Python developer's personal struggle...
:-)
(found many places online...)
(I write this under assumption that Fibonacci numbers can be more easily calculated without recursion, although I am not sure if I am right.)
No sig today.
I'm sorry, but the "but it's slow" argument does not hold for most software designed today. Let's please get over it.
No, it is I that is sorry. Right now, your thinking is prevailing. Slow, crappy software is being pumped out left and right by programmers that are either too lazy to do it properly or they simply don't have the ability to do it properly.
The fact that most software today is poorly written and is slow is a very sad fact that I can't "get over". Perhaps, one day, you will.
The example could be written in Java as:
public class Hello
{
public String myName="Monty";
public static void main(String[] args)
{
System.out.println("Hello " + myName);
}
}
Which is just as short, if not shorter (depending on how you measure length) as the Python example.
The joke, to my mind, is not on Java, but on Java developers' tendency to overengineer everything in sight. Once you move these people over to Python, you'll be seeing the same joke with Python on the right side and Ruby or Groovy on the left.
People in the "scripting" lanuage camp by contrast have more of a "just make it work" attitude. To my mind, neither of these attitudes is perfect. Getting this right involves experience and judgement -- you have to look at the big picture. The kind of person who can be consistently successful using scripting (or "dynamically typed" ) technology is likely to be quite capable of having the same success with Java, and vice versa.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
The same goes for poorly written C++ programs. Sure they may be a bit more responsive at times than a poorly written application in Java or Python but OTOH it has a lot more maintenence issues and the potential severity of the bugs are higher (ie buffer overflow vulnerabilities).
When I code for fun I seldom do that in C/C++ anymore. At least not I know that the application won't need "that extra juice". 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?
I'm sorry, but the "but it's slow" argument does not hold for most software designed today. Let's please get over it.
LOL! Fresh out of tech school are we? Not out of college yet? I only wish that I could be there when you discover the "new concept" of efficient and quality programming. Speed counts.
One day you will have an epiphany. You will realize that it shouldn't require a 3Ghz processor and a gig of RAM to run a browser.
Typical Example Mr. Golfplayer. Found a great little OSS application, needs compiling, uses Perl, running make, opps need to use CPAN, "Oh crap, company firewall blocks FTP", "No problem, I'll download the packages one at a time.", followed by individual downloads, packages added only to find out a package requires another package!
Bzzzt! Wrong!
Interdependencies of packages on CPAN are a clusterfuck. All the hack work is paid for by us compilers.
You tell me to make a backup of CPAN or what? You can't call these packages easily, it's crap work you have to make a offline mirror of CPAN. No. No. No. CPAN is the plague. You customize your Perl env and build and start using non-standard hack libs just because you can and you quote CPAN!
Python might not have so many libraries OR a so-called package repository but the standard libraries accomplish as much as the fancy CPAN calling Perl code.
As you say, Java's type system is often worse than managing the typing for yourself (dynamic typing), but that's hardly a reason to move to a dynamically-typed language - a good type system can manage your types better than you can, so if you're going to switch languages over typing, you need to future-proof your investment by moving to something that does it well.
Surely you don't still believe that garbage collection is inferior to the DIY approach, just because the first mainstream implementations had drawbacks in comparison to C's DIY approach to memory management? So don't make the same mistake with type management.
Would anyone recommend Python in an embedded environment, like say embedded Linux on a Virtex 4 with dual hard-core PPC processors running at 350MHz? Would anything but C/C++ be fast enough for this kind of environment?
I'm inclined to think that the embedded world is still very much dependent on the old workhorses C and C++, but I could be wrong.
Ever hear of the Crimson Permanent Assurance?
"I just run it through Emacs' indent-region."
Why would you want to reformat code every time you check it out? And what about checking it back in? That only work if you're completely taking over a project, or mandating a particular style. Keep in mind that the fact that you're familiar with this issue indicates that there is a problem in your language. Someone who only ever learned python would not be familiar with this "different style" issue at all - it doesn't exist in python.
"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?"
It's not just a policy. It's an enforced policy - meaning code doesn't work correctly if it's not formatted correctly. That may sound like big restraints to a programmer, but haven't you ever tried to follow someone elses coding style? It's not the end of the world. The biggest arguements I've seen in C are when one guy puts { on a new line and someone else puts it at the end of a conditional or for(){. Or when someone indents 2 spaces for { and then another 2 spaces for the code (I hate that). In python these worst case differences of opinion can not happen because they are arguements over the placement of extra characters that don't exist in python syntax. We all indent the code anyway - in fact python doesn't care how far you indent, just that you do. Therefore, Pythons enfoced indentation style is not IMO objectionable, and you don't need to type the extra characters (and {} each require the shift key). That may seem lazy, but so is an unwillingness to use a defined indentation style.
Just commit to doing some of the tutorials and writting a simple application with it (or any language) before you pass judgement. That's all I can really say. If you still don't like it after actually using it, at least you'll have a proper feel for what it's like and why people may like it.
You're not talking about python there. Python is the most readable language I've ever used. I suspect you have't used it.
So, instead of Java we could use perl, pyton, php (remember that?) .net and I am sure someone will come up with many more.
They all are simple, fast, exciting, new, wonderful... etc.
I am beginning to think that this is a plot of Microsoft to dilute the only alternative to .net (.net is a clone of java, but of course -SARCASM- much better, faster, newer, more portable etc. -/SARCASM- )
It was Caesar that used the method to conquer an empire, and it did work.
"Mind your own business, Mr. Spock. Your mother was a hamster and your father smelt of elderberries!"
"You don't frighten us, Starfleet pig-dogs!"
There are two kinds of people: 1) those who start arrays with one and 1) those who start them with zero.
As someone who used to code for a living in python for enterprise, this can only be a good thing. This is one of the easiest languages you can learn, I picked it up in just a week and was more or less productive from that point onward.
The company I worked for used it for CAD/CAM software, which let code written in one language, python run on five platforms (windows, and a bunch of UNIX platforms). The ability of Python to call C libraries when speed was a must made it the perfect language for our uses. Given you really want speed in the CAD world, python still did the job admirably!
You still needed the C interfaces, but you could do all the logic and front ends in Python, which really reduced the amount of re-work when porting to new platforms without really sacrificing much speed at all. I'm glad more companies are seeing the use for Python and hopefully many will learn, like my last employer, that Python is good for more than just replacing Perl and shell scripts.
--Won't that be grand? Computers and the programs will start thinking and the people will stop. - Dr. Walter Gibbs
When some zealot starts pushing Python that's the first thing that they'll also defend. Much like when some zealot starts pushing Macs and the one button mouse is the first thing they'll defend.
It doesn't matter if it's "right" or "wrong". Some people just don't like it. There are no absolute truths when it comes to people's preferences.
It reminds me of a joke I once heard regaing a guy who, after getting hard contact lenses fitted said, "It feels like a toenail is stuck in my eye", to which the optometrist responds, "Don't worry, you'll get used to it." He replied, "If I've got a toenail stuck in my eye I want it out, I don't want to get used to it."
All I can say is there already are a lot of block delimters already in use in Python, e.g.:That defines an associate array with a regular array as the value and a string as the key.
Python's statement's like if still require weird syntaxtic sugar (presumably for parsing):What's with the colons?
Instead of alienating people by spouting dogma and telling them their opinion is invalid and incorrect when critiquing Python's choice of how to handle statement block delcarations perhaps just once reflect on why so many people feel this way and just maybe ponder the possibility and wonder to yourself "Why can't there be block delimters or the use of whitespace? Wouldn't that make everyone happy and the world a better place to live?"
At least in Apple's favour, it may have taken them 20+ years to come around but at least they finally did. Perhaps there's some hope for Python too but maybe we'll have to wait until 2010.
large, monolithic, and inelegant.
:)
Zope is a reason there are so many python web frameworks today: people try Zope, think, "there has GOT to be a better way" and create a new framework.
What's Python like for coding GUI's in?
And are there any nice IDEs available for it?
My Journal
John Cleese? Eric Idle? Michael Palin? Terry Jones in drag? Or have they decided to drop the 3D CGI and replace all special effects with Gilliam's cutouts?
Java is dying!
Sorry, I just couldn't resist.
On a more serious note - good riddens. Java needs to die a quick and painless death. Unfortunately it'll be a slow and painful (especially for those that are forced to use it) death. Java is the one programming language I've used that I have truly *hated* working with. It's slow, bloated, and has no redeeming qualities to make up for it. It even failed at its goal of "write once, run anywhere" - I don't know how many Windows-only Java applications I've seen, and J2ME is a joke - look at any mobile gaming site and their J2ME games have a different file size for nearly every phone they support.
Unbelievably, despite Python being a scripting language (admittedly one that can be bytecode-compiled) and Java being bytecode-interpreted, my experience has been that every Python app I've used has been far more responsive and memory efficient than anything written in Java I've used. (Java AIM client and its 256M of memory usage anyone?) Add psyco (JIT compilation for Python, x86-only for now) and it's REALLY fast.
It's also pretty easy to interface native code to Python when you need the speed, even easier than using SWIG with Perl
retrorocket.o not found, launch anyway?
Does exist in Python. Guido, last I heard, believed firmly that tabs stops should always be 8 characters apart. Almost every other programmer likes 4 or 3, but some like 2 or even 1. Some have their editors set to use and save tabs, some have their editors set to get rid of all the worthless tab characters. You've got to enforce some kind of standard on a shop of multiple python programmers to make this work at all.
I've had very positive experiences with Python, and I'm glad that it is making its way into lots of large, serious projects. Problem is, though, that as these projects get very large, there HAS to be an option to disable implicit variables, e.g., variables that can be used without first being declared. Try working with an old Fortran 77 code that is full of implicit variable usage, and you'll understand!
Please, Python dev-team, hear our pleas!
Once you've fixed the gazillion-th bug caused by dangling pointers or out of bounds access you start to realize that the fast-no-matter-the-cost approach is utter bullocks 95%* of the time (if not more).
* Number pulled from you know where.
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?
Was that an intentional pun?
Excerpt from http://www.forum.nokia.com/main/0,,034-821,00.html
Python for Series 60 allows developers to execute Python commands and run Python scripts and applications in devices based on Series 60 Platform.
Python for Series 60 is capable of running applications that use native resources of Series 60 Platform and Symbian OS. It is well suited to the development of prototypes or for building proof of concept applications with a simple and consistent language. Python for Series 60 is an idea choice for starting to create application for devices based on Series 60 Platform.
Read the subject line....
Think Deeply.
I've done work simultaneously in Java and C# in the last 2 years, and there so similar as to not have any meaningful difference, as far as day to day coding goes. Every coder worth his salt is looking for the next good thing to learn, and for a lot of guys, it boils down to: C#, or something different? Anecdotally, 'something different', i.e. Python, seems to be more attractive. So what I've seen at two large employers in the Bay Area is that people spend a couple days playing with C# , conclude that it's enough like Java that there's no need to invest time in mastering it, and then after playing with Python, they decide Python is the new toy worth spending many evenings and weekends mastering. So I think we'll find in a few years there will be a lot of programmers who have deep Java expertise, and secondarily pretty good Python expertise.
Builded with the Default build of Python there IS a IDE but kinda ugly...
As corporate and enterprise-able products and that have support:
The Kompany makes one called Black Adder...(Never seen it.)
http://www.thekompany.com/products/blackadder/
ActiveState makes one called Komodo(pay) which can/is bundled with ActiveState Python(free). It is very nice and a free trial download!
http://www.activestate.com/Products/Komodo/?_x=1
"Will we finally be able to code for living in a language that's not painful? Exciting times!"" Yeah...I have been doing ti for years...I believe it is called C++. No language is painful once you master it....well except FORTRAN.
Spaces are for spacing, tabs are for indenting: 1 tab per level of indentation
Sorry for shouting, but the number of spaces *you* use to represent an indent in *your* editor SHOULD BE IRRELEVANT TO ME! The only reason it ever becomes an issue is when people who don't understand this decide to use spaces to indent their code. And if ever there was a language where this mattered, it's python.
Dr. McCoy - - Captain, I wish to register a complaint... Hello? Miss?
Capt. Kirk - - What do you mean, miss?
Dr. McCoy - - Sorry Captain, I have a cold. I wish to make a complaint.
Capt. Kirk - - Not now Bones, we're closing for launch.
Dr. McCoy - - Never mind that, I wish to make a complaint about this tribble that I purchased not half an hour ago from this very bridge.
Capt. Kirk - - Oh yes, the Bajoran Blue. What's wrong with it?
Dr. McCoy - - I'll tell you what's wrong with it. It's dead, Jim, that's what wrong with it.
"If I've got a toenail stuck in my eye I want it out, I don't want to get used to it."
Uncontestably true, but it says nothing about having a hard contact in your eye, so it misses the point.
Whitespace-delimited blocks are not the reason to use Python. Dynamic typing is.
But even having said that, I've seen many cases where thirty minutes of practice gets rid of the problems people have with the whitespace. The problem is prejudice, not toenails.
Anyone else read the headline and think of that, hiding in the ship, eating the entire crew one by one?
Python isn't painful?
python is said to be strongly dynamicly typed. Sort of the worst of both really. The inconvenience of strong typing with the inabilty to syntax check caused by dynamic typing. this means run time errors out the wazoo.
Intentional typing is what perl does. The prefixes tell the compiler/interpreter what kind of thing to expect but not the type. @ means its an array but never mind the type of the content. $ means its a scalar primitive or scalar reference.
the result is the compiler can find syntax errors easily and its hard to so something you did not mean. For example, in python both of the follwoing compile:
A = d.lstrip()
A = d.lstrip
in the latter cas A becomes a function reference and in the former it becomes a string with the spaces removed from d.
Gaa! that's a syntax error waiting to bite, but python cant detect it since both are legal syntax.
Some drink at the fountain of knowledge. Others just gargle.
I'm a big fan of Python. I used it almost exclusively before taking my current job. But let's be honest, Python and Java just aren't intended for the same type of applications.
Python's standard library just doesn't have the breadth of Java's. For small apps, the CPython VM is lighter than Sun's JVM, but CPython's VM is lacking several capabilities that I'd consider pretty essential -- chief among them is the ability to return unused memory back to the OS. And for many tasks, CPython is still effectively single-threaded due to its global interpreter lock. Java has never suffered from either of these problems. These aren't trivial issues or the result of nitpicking -- they're rather severe limits (which make me seriously question the suitably of Python for enterprise apps, eg. Zope). Of course, once CPython does get decent threading, it's likely that it's GC subsystem will need to be totally rewritten. I apologize if it sounds like I'm beating up on Python. That's not my intent here. I love Python, and I only wish I could stop more people from using Perl :)
In fairness, it does look like the Python community is trying to address some of these problems. I just read a paper presented last week at PyCon 2005 on CPython's memory management. The author is developing some patches to let CPython return unused memory to the OS for most object types (except for Number, List and Dictionary). The memory manager still can't defragment its heap, so this isn't a perfect solution. As of a few weeks ago it looks like these patches haven't yet been accepted.
I once spent six months of my life trying to write a production-quality compiler for SML/NJ. I concluded that it couldn't be done. And sure enough, functional languages have not had a mainstream impact on enterprise computing.
I would contend that the static typing embedded in Java/C++ imposes an exogenous constraint on programming methodology that does not directly contribute to quality (defined as correctness + maintainability + large-team support).
I suspect that the same is true for type-inference engines. "Duck-typing," on the other hand, relies on the shocking intuition that proper typing is in fact almost automatic in a properly thought-out program.
In other words, the fact that the compiler/interpreter checks your types doesn't actually make your programs any better. This is the non-obvious insight that explains why Python and Ruby seem to be "magically" better to their proponents.
There's a much better example of the use of python in a GIS: OpenEV - its open-source, cross-platform, and has an open python API for writing extensions, including, using PyGTK, graphical dialogs and menus.
Its not as 'enterprise' as anything from ESRI is, but as an open platform for building custom solutions onto basic GIS functionality, I've not found anything better.
It will be a true pretty for many good programmer to overlook Python just because they the feel turn off by the whitespace syntax.
To appreciate the power of Python one should look beyond this trivial issue. How do you feel if your 50 lines Java program can be implemented in 10 lines Python code? What about the productivity gain you can archieve by using such agile and dynamic language? Once you used Python's high level data structure like list and map, Java's collection feel like a drag.
Whitespace is such a trivial issue, it never enter my consciousness after I used the language for 5 minutes. Turn your focus on truely significant aspect of a language, not this minor syntactic issue. Python has many more unconventional design that may shock you when you look deeper into it. And these unconventional ideas are what make Python a break through rather than yet another language. (Think XP)
Without goto a language is crippled. It is fairly easy to translate a Knuth algorithm into a language that has goto (C, BASIC, Perl, Common Lisp, Scheme (tail calls)). Translating into a language without goto sometimes requires enough changes that it isn't obviously the same algorithm.
If you are deciding between Python and Java, you obviously don't understand the question.
I read the headline and thought that is the one thing they needed to get Enterprise past season five, the Monty Python boys reprising the roles of the various enterprise crew. Nobody expects a federation inquisition!
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-read my post, I was unclear about Eric. He initially resisted Python because of distaste for the white-space handling. However, he tried the language and got past the issue, and now is a Python devotee. My point is that everyone who "hates Python" because of the whitespace issue should spend the time needed to give it a fair trial. Thanks to michael00_98 for taking me to task over this.
You are right: there is no way that you can use python for any task that requires even the slightest amount of performance. Realistically a zope / plone server can support 10 concurrent users (with write access). With PHP I aim at supporting 100+ concurrent users per server, and with java 1000. For me these technologies are for totally different uses, and I use the 3 of them:
python/zope/plone - intranets
php/perl - "medium" commercial apps
java - "Enterprise" stuff (3+ developers)
For each project the right technology: I like all of them!
lol... if you can't ftp, you can just grab files from the cpan website.
it's funny you didn't think of that. quite telling actually.
in fact, if you were at all competent, you could whip up a 10-liner script to do that...
but oh well, guess you better use python, the language for those who can't think out of the box...
"I'm sorry, but the "but it's slow" argument does not hold for most software designed today. Let's please get over it. " Agreed. Please cavemen, go bang rocks toghther or something. The rest of us are sick of reinventing the wheel over and over again. It was fun 15 years ago writing 20k lines for a windows form, but ya know what? Maybe it's time for you learn someting new.
I should not respond to your post because I happen to be a Rubyist rather than a Python-ist! However, the key point is that dynamic typing is the benefit which enterprise practitioners need to focus on, and this is true for both Python and Ruby.
Python is a somewhat older language than Ruby (~15 years vs ~12 years) and is a little creakier syntactically. But that is a pure matter of taste. Both Guido and Matz have said as much on many occasions.
The whitespace issue is one of those religious things that give zealots something to fight about. But it's important to mention in a discussion about "Python in the Enterprise" because it's a (perceived) barrier to adoption.
Ruby has different barriers to adoption (at least in America and Europe), such as the lack of comprehensive documentation, a defect that is being rapidly addressed through the efforts of Gavin Sinclair and many others.
Ignore this terrible advice. Zope is so horribly slow that it is simply not worth trying to use. You absolutely must run a caching proxy in front of zope to make it usable, and that only helps with pages that are the same for each visitor.
Zope's documentation is terrible, and trying to do anything above and beyond "ordinary" things becomes a nightmare. You will be more productive using apache + PHP than you will with zope, and that's just sad. If you want to use python, go for it, there's web frameworks for python out there. But stay the hell away from zope.
""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!"
Okay, I'm going to refute this is two stages because you're wrong in two ways.
First, it's not a matter of "processors are cheap". It's "processors are cheap compared to programmers, sometimes". If they're paying for months of your time, most of the time it's way cheaper for them to get a faster computer than have you write the thing in a language that will take longer. That is of course dependant on the number of computers it will run on and the performance requirements of the project.
Second, Java and Python are not necessarily slow. In the case of Java, it's usually a matter of keeping heap allocations to a minimum. In the case of Python, it's usually a matter of spending as much time as possible in a C library (even if that means you have to write the C library).
Doing that will usually get you within a factor of two of the performance of C.
I rarely criticize things I don't care about.
Sadly you can't just flip a switch and never make a mistake again, nor can you flip such a switch in other people.
I really like Python. It's an incredibly powerful language -- what other languages give you the power to redefine what "is" means? For example, you can override the '.' operator (and getattr) and create whole sets of virtual objects that don't really exist. Things like object proxies for RPC or external resources like Zope become possible.
:), the third-party libraries certainly made this project a breeze.
Its main two faults in my mind are:
1. Speed (but this is being worked on, see the Parrot JIT compiler)
2. Memory usage. wxPython especially is an excellent toolkit but a memory HOG.
As far as Java goes, I don't particularly like Java all that much, but one area where it has a definite advantage over Python at the moment is libraries. Not just the standard library, but what add-on libraries are available. Python has a lot, but Java has pretty much everything and the kitchen sink.
For example, I recently worked on a project that needed to display and manipulate SVG graphics. The two requirements are that it be cross-platform, and be done quickly (in just a couple weeks). I originally wanted to use Python but was unable to find a cross-platform SVG rendering library for Python. I came across the Apache Batik toolkit for Java and found that it was exactly what I needed.
Batik is pretty sweet -- you get a swing component that you can plop into an app in about 10 lines of code and boom -- you have one of the most compliant SVG renderers that I've seen to date. Plus it even gives you a DOM interface that will update the graphical view in real-time. As much as I dislike Java in general (even more bloated than Python
>>> Very bad, it really increases developing times since an error which could simply be signalled at compiling time is, instead, found only when executing the wrong line.
>>> The value of strictly typed languages is in compile time type checking. It's good to have languages that are not type checked, and it's good to have languages that are.
These two statements encapsulate the received wisdom on the static-vs-dynamic issue. It will take several years to decide the issue. Compile-time checking is indeed valuable in its own way. However, it just may be that the problems solved by compile-time checking are not actually the problems that make programming-in-the-large difficult to do. Please re-read that sentence a couple of times. This is the subtle and far-from-obvious intuition which must be tested and proved or disproved over the next several years.
Thee Python jobs can be found here...
I'm sorry, but the "but it's slow" argument does not hold for most software designed today.
What planet are you from? I do a lot of work at oil companies and utilities, and they have tons of slow software that causes them to hemorrhage man-hours at an insane rate. I'm talking about the big name companies spending tens of millions of dollars per year on bloated applications that take 30-60 seconds just to start up and take just as long to perform many of their routine functions. People often use these various functions throughout the day, running them hundreds of times. This amounts to several hours per day of users twiddling their thumbs waiting for slow software.
Very often, there are only one or two vendors supplying some niche market such as geological interpretation or pipeline facility management. So if you can write an application that takes half as long to perform certain commonly used functions, you've just saved your customer hundreds of thousands of dollars per year in lost productivity, and they will pay you for that.
There are numerous areas where performance does matter. It's not always the most important consideration, but it's certainly not irrelevant.
YOU are the one smoking crack! If you search the Ruby, Python, Tcl (and any other dynamic language) site and you find that they want a CPAN type central repository. CPAN is the MAIN reason I continue to use Perl. I use Tcl as a secondary language because adding libraries is brain dead easy,
which is precisely the idea, barring your utterly fallacious argument that the modules are "crap" (which ones? how so?).
I don't want my devkit to be a 90MB download, I would rather call packages upon request to my system as I need them, outside of the sensible core perl ships.
"A 1Ghz processor with 1 gig of RAM is no longer adequate? That's ridiculous! And yet, that is where we are at today."
1 gig of ram is no longer adequate??? I don't know what "noncritical" apps you use, but I have a AMD 2200 with 512 of ram. I run both XP and Suse on it and I very rarely use up the ram or cpu and I run lot's of python apps. I program python and php for a living.
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?
If there was money to be made by making that WeatherThing or UltimateMP3 player fast and efficient - companies would do that. There's plenty of programmers out there capable of writing in or learning more low level languages - of optimizing each loop or branch. The problem is that people are not willing to pay all of the extra associated with the development and testing of software written with risky optimizations (optimizations tend to complicate and obfuscate code, reduce abstraction, etc) in unsafe languages.
The truth is the consumer would rather spend an extra $100 to get enough RAM then spend $10 per program on their PC (that adds up faster) for the programmers to program it "correctly." It's not economically efficient, at least not in the eyes of the consumers.
Why do you think so many kitchen appliances last only a year or two nowaways? Or current VCRs which almost qualify as "disposable." People are rarely willing to pay extra when they think the low cost option is "good enough." In some ways this is what killed the Mac - it was better according to many metrics, but PCs were "good enough" for the average consumer, and the price difference wasn't justifyable.
A computer is a tool to get work done, nothing more. If people valued security, reliability, and efficiency enough, most software would be secure, reliable and efficeint. But people value features and low price, so that's what the market gives them.
Look on the bright side - at least compilers are getting better.
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.
---------
He meant that if you program in one language, you *have* to spend extra development time just to get it to work, but if you use the other one you can spend time doing other spiffy stuff.
"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.
No, I'm fairly certain that you misunderstood. You focused on completely the wrong part of the sentence and totally missed the point. The emphasis was on the "several times the development effort" part. The implication was that in languages such as Python, it is easier to make things that work properly, so it takes less time to get to that point. Which means more time can be spent on streamlining, adding useful extension features, etc.
# Speakers told of experiments and used anecdotes to explain that programmers
# who use Python finish jobs in no more than half the time required by those
# coding in more conventional languages
The "more conventional languages" it's talking about are C# or Java, mainly.
(It also mentions XML and SQL, but you don't use Python instead of those.)
I'm trying to figure out how doing anything in a VHLL such as Python could take anywhere *near* half as long as in C# or Java. As a Perl programmer, I know that if I can't complete, test, debug, and deploy in an eight-hour shift what would take a C# programmer a month, then there's something wrong with my understanding of the problem. I would not expect Python development to be quite as fast as Perl, since it's a bit stricter about certain things, but nevertheless, I would have thought it would be a lot closer to Perl than to Java or C#. It *is* a VHLL, after all, right?
Are they just being really conservative with this claim, or is Python develpment really that slow?
Cut that out, or I will ship you to Norilsk in a box.
The profusion of library modules with overlapping functionality is a real concern. The confusion over a standard window system (wxPython, Tk, ...) is actually just another example of that.
The sys/os split, logical as it may seem to the experienced Python programmer, also confuses Python newbies, as does the fact that string needs to be imported and that re is yet another separate module.
I think Python would do well with a major library cleanup, removing rarely used and duplicated functionality, and improving the quality of the library code that is there.
Furthermore, I think it would help for common string, I/O, OS, and regular expression functionality to be importable either via a single import statement (without name conflicts), or to be simply present in the default namespace.
It will take several years to decide the issue.
This issue hasn't been decided for half a century, what makes you think it will be "decided" within another several years?
However, it just may be that the problems solved by compile-time checking are not actually the problems that make programming-in-the-large difficult to do
Who said they were? Static type checking fulfills an important function in large programming projects. That function is not necessarily what you would understand as "programming in the large", it may well be "programming in the small". But when building large systems, you need to do both a little bit of "programming in the large" and a lot of "programming in the small".
If there is anything like an answer emerging at all, it is that the Java and C# approach seems pretty good: those languages use static type checking by default, but they also give you dynamic type checking, reflection, and code generation when you explicitly ask for them. The existence of such a compromise won't shut up the people who are religiously in the static or dynamic camp, but it helps the rest of us get our work done faster and more safely.
Harump! Harump! Harump!
Use pike. Its a statically typed, object oriented scripting language with a curly brace syntax. So your example would be found at "compile time". If you have A declared as a string, then your second line of code will be a compile time error (bad type in assignment, expected string got function).
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.
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.
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.
...or a replacement for VB6? What little I've heard is Visual Basic (which I know from experience has got to be the most successful garbage programming language in a long while) and Python are often used in the same sentence, with disparaging remarks reserved for the former. Given that a few programmers out there are peeved that VB6 is being phased out in favor of VB.NET (how successful has that been?) and Java is controlled by another single company for the most part, this leaves Python.
He was "thrilled" to "discover" hashes. Every decent high level language has this data type, wether its called a hash, a mapping, a dictionary or an associative array, its not new and its not thrilling.
Eric Raymond is not a top programmer. He is barely a programmer at all. He has contributed nothing but self obsessed posturing, no worthwhile code has ever come from him.
Second, spending 20 minutes with python will not cure the whitespace problem. It is 100%, without a doubt a mistake. I have a 12000 line 3 man project in python, and the whitespace issue is a very big problem. We are looking for a proper language to migrate to partly because of this.
And typing is a real problem. variable = obj.function and variable = obj.function() are both legal, and both compile. They are not equivilent and a language with proper typing would catch such errors.
I should NEVER have to debug whitespace, EVER!
I've heard and used those expressions. Let me tell you what we mean by them at my company:
Processors are cheap -> it is ok to implement superior features, even if they are more cpu intensive than inferior features.
Memory/Disk are cheap -> it is ok to use a lot of memory or disk to implement a superior feature or a faster algorithm in important parts of the code.
As a result, we make the highest quality, best selling software in our industry.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
If only more geeks considered the economics of what they're doing, as you have...
:(
The logical extreme of the "all apps must be as fast as possible" argument is to code in ASM. I suggest that anybody who pushes this argument write every app in ASM. See how long it takes before this person gets fired for inefficiency...
Why are some coders hesitant to "use the right tool for the job"? ASM might be necessary if you're optimizing a crypto or compression loop, while C or C++ might be more appropriate for the rest of the app, but Perl or PHP are surely more-appropriate languages for web-scripting! Duh.
But no, we have these "code everything in C, C is the be-all end-all of languages" dolts...
Is Capitalism Good for the Poor?
"It's slow" is entirely valid.
Lets be serious -- Java isn't slow so much because of any real technical issues with the language, but because of the mentality surrounding it.
The mentality is to overdesign and overengineer. Everything must be reusable, nothing should be written from scratch if it can at all be avoided. Don't try to understand the problem, get the module that advertises the solution you need and drop it in. Speed? Let the RDBMS/window toolkit/JVM worry about it, programmer time is expensive, you know!
This mentality certainly is not limited to the Java world. This mentality is a facet of "enterprise" scale software development, which you can apply to any language; Java is simply unique in that the Java world goes far out of its way to facilitate this model.
I find that under such a model, the end result is a dreadfully slow, frustrating product which prompts developers to make severe compromises or shove in workarounds at the last minute for speed.
Case #1: Windows NT 4 maintains a SAM database to control access. Pretty clever, keeping it all in a centralized database, but the sucker is massive and takes a long time to load on startup. Waiting for the damn thing to load on some servers was taking 10-15 minutes (I shit you not). The boot process already took 2 or 3 minutes, and to wait 10-15 more minutes on top of that before you can log-in is agonizing, so Microsoft put in a hack to rig it so you could login with the barest bones part of the SAM loaded.
Of course, you logged in, but on the server we found that if we launched anything an administrator would want to use, the management tools would either hang until all of the data got loaded, or crash because it was working on a dataset that was rapidly changing.
Case #2: Large application suites generally take a long time to start because they're organized into numerous modules that all need to initialize and load when the app is started. As the app gets more featureful, load time shoots up. Developers would at first try hard to minimize the impact of their module load times, but as the features kept creeping it, they realized that there was no hope -- the load time was well past the 10 second mark and the user was getting irked. So, they added the splash screen with a status indicator! Once that went in, developers don't try so hard to keep their module load times down, so it stretches into minutes.
It doesn't occur to anyone until after 500,000 lines of code are written and they see the shell of the app running that they should worry about load time. By then it's far too late.
Case #3: the RDBMS is on a giant beast of a server, it's got a terabyte of RAM, 64 processors, -- no worries here: the developers start getting lazy and write O(N^X) performing queries. They don't notice how slow it is on small dataset, and they go with it. Besides! The RDBMS is a monster that can handle anything! But then it goes into production and Y is 100,000,000 and X is 100 and a couple of these queries happen a second. Oops.
I've used whitespace-blocked programming languages (MUMPS, anyone?) and they blow. They blow so hard, they suck.
Someone (I think it may have been Stroustrap) said (and I paraphrase), "The restrictions of the language translate to restrictions in the programming solution." I find white-space blocking restrictive and somewhat... arbitrary.
I understand these are my opinions, and others feel differently. Python looks like it might have been a good language for me if it wasn't for the pain of whitespace blocking. But you know what? It doesn't matter, because Python is there for those that like rules and restrictions, and Perl is there for those that thrive in chaos, and Forth is there for those who like to invent their language to fit the solution every time.
Lisp is there for those that like lots of tiny little chunks of things. C is there for those who aren't man enough for assembler. C++ is there for those who like pain (those are called masochists, right?). Objective-C is there for those who can't *quite* commit to Smalltalk. COBOL is there for the clearly insane obsessive-compulsive.
Java is there for those who used to listen to marketing hype. C# is there for those who grew disillusioned with the old marketing hype, and who listened to the *new* marketing hype.
That's the great thing, even about sucky languages like Python. Everyone has their place.
Mine is INTERCAL.
Microsoft is to software what Budweiser is to beer.
Just because you can't think of a reason for it doesn't mean it should be a syntax error.
There are perfectly good reasons why you'd want to store method references (x = obj.method) that way. The fact that you can then use the reference x() instead of obj.method() means the assignment is not a "dead-end".
If you're in the habit of forgetting parenthesis in function calls, perhaps that's something you should work on instead.
C may be old-fashioned, but please don't lump C++ in with it. Chances are you haven't even seen modern C++ source code, which in practice has little to do with C source other than that you can link to C libraries easily.
That said, I'm all for programming in higher-order languages (e.g. Python) and I prefer to do so, but some problems are better solved in C++ or even C. It doesn't even have to be about efficiency; things like static type checking can be essential in large programs when it's hard to test all code paths.
I've seen plenty of poorly-written, slow code written in C and C++ -- the languages themselves makes it easier to write poor code. There's a time and a place for C, and it's not always -- or even usually -- that time, nor that place.
These tools would not be in widespread use over C or C++ were they not useful. Doing it "properly", using your definition, is more error-prone, and takes longer. But sure, if you want it to run as fast as it possibly can, go for it. It's just not a requirement for 90% of applications, and the benefits just often don't justify the risk.
There are a lot of things wrong with what you are saying. It looks like while you learned the language, you have a lot of trouble adapting to some of the "paradigms".
Asking for functions to return None instead of raising exceptions on errors ruins a fundamental concept of "focus on what the program should do" which makes exceptions useful. A significant percentage of C code is "if - else" statements dealing with such return codes.
In C or Perl, writing a file is a painful operation, along these lines:
open file for writing()
if open failed {
handle error
} else {
while not finished {
retvalue = write content to file
if retvalue not good {
handle error
}
}
close file
if close failed {
handle error
}
}
Note how inline error checking not only makes the bulk of the code, but also makes it less obvious what the code does. In Python, you'd do something along these lines:
try:
open file for writing
while not finished:
write to file
close file
except open failed or write failed or close failed:
handle error
That is even assuming we want to handle the error and not let it propagate up, which is made possible by the exception mechanism, and would be made difficult if all those functions would return on error.
You forgot about HTTP via the LWP module, or using an external call to wget. Think the company blocks outbound HTTP? (well, for call-center employees, yes, but for developers?)
Is Capitalism Good for the Poor?
With automated memory (and occasionally other resource) management present in these systems, the "background" applications you describe will generally disappear into the background, and not consume resources. Which is comparable to a well-written program in C or C++, say.
I'm not sure about you, but Java/Mono apps have never caused my computer any strife while in the background, whereas "poorly written" applications implemented in C or C++ have frequently brought my system to the ground with memory leaks and the like.
Have you ever tried Python? It's far more readable than Java, the clean indentation, limited for loop, and general verbosity without anything unnecessary make it much easier to maintain than any other language I've ever worked with. The non-compilation also means it feels easier to debug, there's no separation of compile-time and run-time errors but that's actually a good thing, because it doesn't really matter where the error occurs, you just need to see where it is and fix it, so there's no need for two "cycles" when debugging.
I am trolling
I do agree, largely. I do not like C++ as a language though. C's use can be justified for low-end systems, but C++ is in more of a quandary, since its architecture has been superceded by newer languages -- but yes, if there is a larger system that absolutely, positively has to run fast, it might be beneficial to use C++. Most of the time, though, I think of it as more of a legacy thing in a lot of ways.
Static type-checking is implemented better in a lot of languages than C++, although yes, Python's a special case at not having that feature.
C may be old-fashioned, but please don't lump C++ in with it. Chances are you haven't even seen modern C++ source code, which in practice has little to do with C source other than that you can link to C libraries easily.
Chances are, you haven't even seen the code in modern C++ compilers, which in practice has little to do with reality or sanity.
At least no one at /. can complain that MS is hurting open source software by providing a way to compile python to CLR.
The paragraph below is a great example why people usually *want* stuff they really do not *need*, and why not all programmers can be language designers:
It reminds me of a joke I once heard regaing a guy who, after getting hard contact lenses fitted said, "It feels like a toenail is stuck in my eye", to which the optometrist responds, "Don't worry, you'll get used to it." He replied, "If I've got a toenail stuck in my eye I want it out, I don't want to get used to it."
Interesting point, although I'm not sure you're even trying to object to Java itself. To be fair, though, careful selection of packages will, in a lot of situations, be a better solution than complete reimplmentation (a lot of things are basically trivial-but-time-consuming to implement). And yes, Java's GUI support is awful (although a couple of apps seem to have worked past that, recently).
And dear God. O(N^X) queries are a horrible, horrible thing, no matter which language is lumped with dispatching them.
I recall the "old" style as being
if (test)
{
expression
}
But even with that goal it still includes some very irritating and useless constructs.
It's best place is to replace the original BASIC as in introduction to computer programming course... say at the early middle school level.
I program in C every day and I haven't coded an error of the type you describe in over a year. I would know if I had -- our C memory manager catches all manner of pointer problems, accounts for all memory allocation and freeing, memory over- and under-runs, gives us stats on memory allocations and so on.
I'm definitely a Python fan, but your agument against C isn't valid. It's just an argument that crummy programmers write crummy C programs, which is not news.
Python is a perfectly reasonable language for coding certain types of applications, and it is also a good language for programmers that aren't that skilled because it puts a strong safety net in place for many types of errors with the exception system it uses. C is something else entirely.
I've fallen off your lawn, and I can't get up.
Last week I realised I needed some way of generating a bunch of stuff on the fly as prep work for a current project.
It had been mentioned in my hearing that Python was acceptable within the constraints for the overall program.
Figuring it was at least worth a look, I spent a day playing with Python basically putting together the things I needed to to do the task. In spite of a couple of disruptions, my code was fully functional and more or less ready for primetime by COB Friday.
I wouldn't use it for the real-time parts of what I'm doing if only because the framework being used is suitable as it stands ( C++/C/FORTRAN ) but for most other things it rocks.
I plan to push for making Python the standard glue language at the office.
Modded insightfull? Just because someone doesn't use up all his resources playing Nethack?
"Speed is important"
...just like price, just like quality.
You meet the demands of the project/customer. I'm not really arguing with you, but this is sort of the point of a thread about Python. It's a tool that helps balance this process for the developer - this in turn should result in benefits to the enduser.
It is nice to have a perfect balance, but efficiency is relative and (developer) resources are finite. Always.
That's where i'll desagree with whateverparent who said that high level "so called scripting languages" should only be used for prototyping/testing and should be cast aside for final app:
It's well known that ~10% of an application's codebase consumes ~90% of the application's resource needs (source: my ass), high level modular languages with easy ASM/C/C++ integration such as Python therefore allow you to:
- Develop the whole application in a fraction of the time you'd need to develop C/C++ version
- Using it as a "proof of concept" of the app's viability
- Fully test both application and test-cases (including unit tests
- Identify performances "roadblocks" modules/parts
- Recode these modules in a more efficient language using the already perfect testing tools
You'll use maybe 10% of the "full C/C++ approach" coding time to code the initial java/python/ruby/whatever high-level language you prefer version, 5% or maybe 10% top to recode the performance-critical modules in low-level languages, and you'll get... 99% of the low level version performances for under 20% of the dev time (with less chances of memory leaks and better portability to boot)The stupid part is that most people don't even realise the ease of embedding low level modules into modern high level languages, and therefore use a "all or nothing approach", either full high level or full low...
Learn how to use your tools guys, low level compiled and high level interpreted language do not oppose themselves, they're complementary and both are necessary to get the best out of your dev teams
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Ruby is first of all, incredibly slow. Second, it doesn't have real threads. And third, it doesn't offer anything special. The best argument for ruby anyone has come up with is "look at rails", which could be done in python or perl just as easily, and "the syntax is like natural language", which is both wrong, and not a good thing.
GTK is portable, and you can make a GUI for it in glade. Then save that GUI as an xml file, and use it to quickly and easily create the GUI portion of your app from any number of languages, including C, C++, perl, python, pike, and ruby.
Pike is statically typed and requires you to declare variables, but is still just as fast and easy. For your example:
int|float twice(int|float x) {
return (x * 2);
}
See, it doesn't have to limit the functionality of the function twice. And you still get all the benefits of static typing finding mistakes for you at compile time.
CURLY BRACE PLACEMENT HAS NEVER BEEN AN ISSUE. Man indent you fucking whitespace loving morons. Curly braces are a *feature* that allows you to indent and re-indent any code automatically. Python breaks this, and makes it completely impossible to re-indent people's code, and you don't even know if the code is indented correctly to begin with. (bugs can hide behind space vs tab problems, and you will often totally miss them). We knock the lack of braces BECAUSE we have tried it, because we are experienced programmers who have been coding since before you are born, and realize that the lack of block syntax is a problem, not a feature.
Someone who doesn't understand what semantic structure is, and is stupid enough to not realize that block delimiters allow computer applications to indent and re-indent code automatically, while syntactically significant whitespace makes it impossible to assertain wether or not code is in fact correctly indented, much less reindent it to a standard indent size/type.
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?
Sure it does. But let's take a look at it:
1) It might cost the company an extra $25,000 to go through the performance tweaking to get it "right". Yes, a small team of coders, and a calendar month.
2) Let's say that they improve performance by 100%.
3) Assume that the software is server-based.
4) Cost to get software running "right" - $25,000. Cost to upgrade the server to a dual proc - $1,500. Which are YOU going to do?
I'd suggest that you read a bit more on the realities of software "BLOAT" before you go judging.
It's not what you think it is.
People, given the choice of better performance or better features will almost always choose the latter, because they can "do more". So, what's the economic incentive to hand-craft everything in assembler?
"c" is a compromise solution - I remember when it was considered a HIGH level language! The price/performance curve is always reshaping itself towards higher and higher level languages. Get used to it!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Your example is painfully silly and does not even compile. You neglected to create a sayHello method and looks like you criticized someone else for not creating a class which is just silly because while you define one you do not create it.
It doesn't solve all my problems with python, and it doesn't support threads. This is not a show-stopper, but it does lose points.
And there isn't "some" validity to my point, its a real and serious problem. There is no assurance that such an error will be caught when I run my code the first time, only when a certain, possible rare sequence of events causes that particular line of code to execute. That bug could be there for weeks after it was made, without anyone noticing, and then by the time we notice, its a problem that just affected a user, and we've got to debug it now. In a statically typed language it would have been caught immediately, and would save time having to debug a silly mistake.
I'm not sure why you are comparing to java, as there's no way in hell I would write this in java, but we have started re-implimenting the base of it in perl, ruby and pike to see which seems like the best bet. My vote is currently on pike due to this exact static typing issue.
There have been many posts concerning the speed of each and every possible language. Some have gone as far as to link to several studies with nice charts and graphs to conclude that X language is faster or X1 is truly the fastest. You are all wrong.
A laguage, in of itself, cannot be measured by speed. A language is merely a group lexical elements with a particular syntax. That syntax has an associated semantics to it. That is it! It is pointless to compare languages purely on speed.
Now, what we can compare is the implementation of a particular language. For example, we can compare the speed differences between the intel compiler and gcc for the same piece of C code. We might find that in most cases, gcc is slower that the intel compiler. Does this mean that C is slow? No! Now, take the same algorithm and port it to Java. Lets imagine that the Java version was 10x faster. Does this mean Java is inherently faster langauge? NO! It means that the compiler, JIT, and HotSpot implementations are better at tranlating Java source code down to the machine level.
So, in summary, a language by itself should NOT be measure in speed. It should be measured by the following:
Maintainability
Ease of Use
Learning Curve
Clear Semantics
Support
Documentation
Standard APIs
Most often, when languages are compared, you are merely comparing the differences in constants in a language! Lets say we implement the Quick Sort Algorithm in C++ and Python. We will probably find that the C++ version is slightly faster. What does this mean? It means the the implementation of C++ generates fewer constants that the Python Implementation. So, the Python version may be slower, but it is only in constant O(1) differences and in most cases this does not matter! Eliminating extra constants ( in any language ) is stupid when you have chosen the wrong algorithm in the first place! ( such as an order n^3 when it could have been n*log(n) ).
So, what is the moral of this story? Pick the right langauge for the right job. It you are doing advanced GUI development and prototyping, C++ is probably not the way to go ( since it is harder to write fast and correctly ). However, it you are doing low-level real-time I/O where constants do matter, then C/ASM is probably the way to go. After you have chosen he right language for your task, you must choose the right algorithm! Algorithms are the key! Algorithms are the only true way to measure the efficiency on any program in terms of memory and speed.
you obviously don't know what "enterprise" means, let me clue you in, it does not inclulde any of the things you are arguing, all those are DESKTOP apps not enterprise applications.
And uglier. Kinda like perl. Go away, troll.
-Don
Take a look and feel free: http://www.PieMenu.com
Which is mostly what "enterprise" software is. I've been using Spyce (python server pages) for a few clients and it's a very decent tool. There is however a serious lack of standardization that a true enterprise technology needs. In Java there isn't a 100 different ways to do something right and it helps in commodotizing the Java programmer which in our geek eyes is a Bad Thing but in the view of corporate money it is a Good Thing.
Screw realty just hook me up another monitor!
Well That's certianly not how I would write it. now lets look at how one would do this in a good language that returns default values like Nulls.
That I'm sure you will agree just as readable and maintanable as the try-wrapper. Indeed the above does not preclude having a try-wrapper around it. One of the nice things, any python programmer ought to appreciate, is that the above form is self-documenting. You know where the errors came from rather than having an unexplained branch jump into a non-local piece of code. But the point is that by returning a default value I am free to handle the error or ignore it. I dont have to have the try enclosure if I dont want it. This is especially important when the error is inside of a loop or worse if the error occurs in a nested function.If instead function2 might throw an exception instead of a default return value then I have to wrap the thing inside of a try statement when in many cases if it just returned null or zero I would be perfectly happy. lacking that capability I have to write something like this:Some drink at the fountain of knowledge. Others just gargle.
If a person wants to write spaghetti code, they will manage it, even in Python. If a person wants to write intelligible code, they will manage it.
The most important part of any program is the algorithm. That's what needs to be understood. And Python cannot make a programmer write algorithms.
I don't see the attraction of Python's forcing you to indent in a certain way.
MS SharePoint stores _everything_ in SQL, and it's pretty darn zippy.
So what is the benefit? Is it mainly a productivity thing, where the programmer can type less? Is it that you don't have to cast things? These seem like small benefits when considering you don't have the security of knowing what type your variables are.
What other benefits exist? Where have I made bad assumptions?
Your argument is true for some "Ultimate MP3 player" and like apps, but not for most custom software. If someone is spending $10k - $100k+ for software that is only going to be used on a dozen machines, the cost of buying faster machines is often tiny compared to doing anything but the most high-level optimizations.
Here is an example of what I see as the pernicious "try" crutch. The try syntax is excellent for certain kinds of errors but one should not be forced to deal with an exception when default value would do. it should be optional but its not this leads to the follwoing: see my answerto a simmilar issue for a worked example of what exactly I mean.
i don't know much about java as i hate that language
So, you don't hate it because you've coded in it and you don't like it, you hate it because some other idiot has told you he/she it was crap?
Apologies in advance if I have misunderstood you, but ...
I think you may be missing an important point here. In older languages, you'll find that the bulk of the work was often thrust on the programmer because the programmer was far cheaper than the computer. One need look no further than the horror of JCL and COBOL to see a high level language that still required inordinate amounts of fiddling by the programmer to get it to play nicely with the computer.
Today, we find that the programmer is far more expensive relative to the computer. Simple economics dictates that shifting much of the load from the programmer to the programming language will save money. However, that's not the end of the story. Some applications need raw speed. Others do not. Choosing Python or Perl for device drivers or ray tracing is probably not a good idea. Choosing C or C++ for processing log files is also probably a bad idea (though not always.) An "always/never" dogmatic approach to language choice means that one cannot choose the best tool for the job, but is instead forced to twist every problem in such a way that your favored language is an appropriate solution (or, perhaps just as common, to simply ignore those areas where your favored language is a bad choice.)
In other words, don't be dogmatic. Dogmatism implies that you won't consider new ideas and that's almost always an error, even if the beliefs that you hold as true are true. Developer performance, processor performance and language performance are all factors that should be considered.
You forgot a very important step. The VAST majority of the time those low level bottlenecks are also low level bottlenecks that other people have and there is already a highly optimized c module to do that task with a python binding already. So you just use that library and the problem is solved and you did not need to write any lower level code.
You are right though that a mix of high level and low level languages tends to give the best result in the lowest amount of time. What has shocked me is that from experience I have seen that pure c/c++ apps are almost always faster when redone in python even without anything outside the standard library. C/C++ show up very fast in these micro optimization benchmarks. However I have not seen them show up that fast on large codebases. Probably because it takes so much time and effort to optimize them. So while those apps could be made faster then the python versions it would cost too much money to do it since the code base is so large. This is an even better reason that that hybrid stuff pays off so well. The low level parts are so small that you can highly optimize them and you will end up with an app a good deal faster then ANY c/c++ app of reasonable since you can afford to produce.
Computer modeling for biotech drug manufacturing is HARD!
Python is easy to learn at a basic level. It is very easy to use for simple tasks.
Python also has the features of modern, powerful, high level languages. I was not saying that Python had features that other languages didn't. Quite the opposite.
At some point it became necessary that I could create cross-platform applications. The reason I selected Python, rather than Java, was a Slashdot article. The article had comments from a developer at Sun saying that Java was a lousy language for developing in their environment. One of the languages that he proposed as an alternative was Python.
ett ne
I can't believe some idiot would mod my reply down while modding the other responses up, even though I was being just as honest in my opinion as they were. Obviously the guy is a Python zealot who doesn't want to hear an opinion he doesn't like.
Python is a great language, so much better than Perl, but it isn't as great as python zealots keep preaching. It simply fails when compared to other tools in areas such as enterprise development, web development, etc.
Just like Java before it, Python is the latest "answer to all our problems" in software development. I'm betting that we'll see another replacement within three years.
But the real problem is that it seems the majority of developers will use any justification to use Python, no matter how thin. Once acheived, they begin their campaign of rewriting entire projects from whatever crappy, unmaintainable language we last used to whatever soon-to-be-crappy-and-unmaintainable new language they want to play with.
This ongoing effort to move from old language to new seems to be driven by little else than a developer's desire to work with cool new stuff. It robs our businesses of tremendous productivity and makes it that much harder to succeed. I've seen bugs put off for years because they were in the old-language code and the developers didn't want to touch it until the major rewrite scheduled real-soon-now. I've seen perfectly good code bases thrown away with no justification given or some flimsy speculation that new language will be better/faster/more.
It is this campaign to use new languages that robs businesses of huge amounts of productivity. Not merely the effort to rewrite stable code with new code in new languages, but the effort to test it, the effort to find and fix bugs. The effort to achieve the previous code's stability with multiple cycles going from 0.0 to 3.0+ over the course of years.
So if you're looking at Python or some new language as an interesting way to do your type of software development work, please consider how much further your business could advance if you just train your current development staff and new hires in whatever language you are already using.
These opinions guaranteed or your money back.
Q: My program wont run!
A: Reconfigure your editor!
Meme of the day: I browse "Disable Sigs: Checked". So should you.
Nobody mentions that the person who wrote the article is hyping python. He is a python lover.
In mature coding shops, all code is automatically run through a lint engine before it is compiled. It doesn't matter what the religious arguments one might have about where the brackets go, how many spaces between parens, etc., because when you hit the "compile" button, it all gets replaced by the corporate standard.
The net bonus is that one can concentrate on making the program work, rather than worrying about tabbing/spacing/bracketing in the right place. In fact, whenever I've worked in a non-mature shop, it is always a pain, because I have to remember to do all that stuff. Using a LINTer is so much easier.
Since you appear to be unaware of formating your code with lint, please at least tell me that you use source control.
Yeah, right.
"for God's sake, rewrite the application in a real language."
Why and what do you mean by a real language? I knew people that feel anything less than assembly is not real language. c and c++ are for those armatures that can not write assembly language. c is slower and a lot more bloated than hand optimized assembly. Sound s just like the anti java nuts. I we use several apps written in java where I work. They work well and respond fast enough. The users never have to wait on the program. They also run on Linux as well as Windows. So why should we spend time and money to rewrite the applications in a "real language"? What would we gain? If a program is fast enough that you never wait for it, never crashes, and gets the job done then the programmer did a good job.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
i don't get you.
why? why does that matter? why should i care whether Alan Turing was gay? why does it matter what religion or faith Larry Wall may or may not follow?
grey wolf
LET FORTRAN DIE!
If you really hate the whitespace thing, then use Ruby. You haven't argued against the basic dynamic-language proposition, just against one of the (arguably minor) features of Python.
Python is no easier to learn at a basic level than comparable languages like perl, pike and ruby. All of which are just as cross platform, just as easy, and more feature complete compared to python. Just because you are used to VB, doesn't mean python is good. It just means VB is bad.
Just because everything is on the heap doesn't mean you can't reduce allocations.
Littering memory with temporary objects makes a lot of work for the garbage collector. If that can be reduced, there are significant performance advantages. For example, javax.swing.JComponent.getLocation() takes a Point object as an argument, so it can setup the provided object rather than allocating a new one.
If you can set up your classes to recycle objects like that, you can reduce the allocations and therefore reduce the work for the garbage collector. You can get very close to C++ performance if you put a little time and care into it, and it's still way easier than dealing with C++ because you don't have to achieve perfection with your memory management. You just have to recycle the most commonly used objects.
I rarely criticize things I don't care about.
When I first read it I thought maybe Jonathan Archer got a new pet.
Then I wondered, did he get rid of the dog or did the new snake just eat him?
Bet this
The problem is that actually, it hasn't, although it surely should have been a long, long time ago. Alas, the bulk of the software development industry is so driven by marketing hype and buzzwords that it has collectively failed to develop a new language that is a serious choice as a general purpose programming language spanning many problem domains.
A lot of newer languages imitate C++'s approach in terms of design tools, most obviously Java, C# and now Visual basic.Net. However, the beauty is only skin-deep; these languages often lack the solid, underlying framework and reasoned design decisions that have gone into C++, with the result that most of the time they are lucky to be as good, never mind an improvement. The addition of generics to Java several years later is an obvious demonstration of what happens when you go for buzzwords and you meet someone who went for solid design principles.
Many other languages have something valuable to offer developers, but then go and spoil it in some other way, ultimately winding up with something that might fit certain niches, but isn't suitable for major development projects across a wide range of areas. Some common examples come immediately to mind:
Java Pro: emphasises safety, readability, and portability; con: sacrifices low-level control (and with it performance) and only supports a limited number of programming techniques, encouraging over-engineered, component-based designs Perl Pro: quick, flexible, useful for rapid development of useful tools; con: terrible scalability and unfriendly (to both programmers and tools) syntax restrict it almost exclusively to quick-and-dirty projects Haskell Pro: elegant and powerful syntax, serious support for powerful programming tools like higher-order functions; con: overly academic community, and puts purity above pragmatism, making it hard to use in real-world projects where things like UIs are involvedThe list goes on, but the important point is that while each of these has good applications, they all have obvious flaws as well. Java is the closest to a serious general purpose language, but even today most of the serious Java code is restricted to server-side back-ends driving databases or some thinly disguised variant on that theme.
C++, for all its sins, remains a pragmatic, balanced choice for a general purpose language that can be effectively adapted to a diverse range of applications. Is it a perfect language? Of course not. It has gaping flaws in any number of areas. The problem is that no-one has yet produced an alternative that beats it on all of them without significant compensating weaknesses.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
You're debating which language is better based on whether a one-liner takes 9 lines or 12 to code?! If it were that easy, we'd all go back to writing in BASIC.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I'm not convinced that Java, as an example, is a worse general choice than C++ (I'd assert that as often, or more often, than C++ is a good choice, Java would be a good choice, but that's obviously not really fairly decidable). You're right that everything has pros and cons, I just feel that C++'s cons began to outweigh its pros a while back, and it just seems more evident today.
I'm also extremely unconvinced that any of the languages you mention have less "reasoned design decisions" than C++. The advantage of these newer languages is that their programming is, in general, more "safe" than predecessors like C++ -- although none of them are a true "general" language (what is?), a competent coder should be able to pick up the one most suited to his or her project and use it, without fear of having to learn a whole load of coding rules to avoid buffer overruns and the like.
Although C++ can be a reasoned choice sometimes, I do not see it as useful for new projects in a lot of areas. For most purposes, there's a better choice. But that's simply my opinion, of course.
Well, you've repeated the same entire expression twice in just one line of code. Moreover, the syntax contains redundant elements even without that. That's hideously verbose compared to, say,
or any number of similarly concise and more readable variations in other languages.
Really, if you're going to support Java, you shouldn't have argued in favour of one of its worst attributes! :-p
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The project is a network server application. What code gets executed depends on what commands the client sends to the server. Conditional execution is very common, they added handy things like "if" and "else" because its so handy in fact. You should try it sometime, it really makes things much easier.
I assume you mean that I should waste time writing tests that verify what the language should be verifying? Things like is my string a string? That's an awfully backwards way of thinking. Rather than spending more time working around a languages limitations, I would prefer a language that doesn't stick me with such limitations in the first place. If you don't mind having to work around limitations like this that's up to you, but not everyone is going to be horny for python and ignore its faults. I don't consider languages like religions, so I am perfectly willing to switch to a language that solves the problems python has.
Saying "ruby doesn't support threads" in response to my statement that "ruby doesn't support threads" seems somewhat disingenious. I know ruby has a broken, pretend threading implimentation within the interpreter. Like I said, its not a show stopper, but I would certainly give more points to languages that impliment threads correctly. We made end up needing to use an SMP machine at some point, and working around ruby's limitations isn't any more appealing than working around python's limitations.
And finally, there's no way I would write this in java because I value my time, and java is not portable. We're using openbsd/amd64 because this is a security sensitive application that has been actively targetted by "hackers", likely being paid by the company we're making angry. There is no java on openbsd/amd64. There is python, ruby, perl and pike though. Python doesn't compete with java for me, java isn't even an option. Python does compete with ruby, perl and pike though, which are all very similar languages that are all similarly productive. We will continue to evaluate those 3 languages, and then move to whichever one solves more of the problems with have with python, while adding the least number of problems of its own.
My question is, why do you have such a strong desire to try to make me believe that python's faults don't exist? Every language has its downsides, I am not going to ignore them and use python just because you can't fathom the benefits of static typing.
We should change the Fundamental Law of Software Development to "premature attempts at reusability are the root of all evil".
If it takes you five lines of code and seven abstractions just to read a value from an input stream, just because you can then share a couple of those abstractions across different types of value, is that really more readable, maintainable or efficient than simply writing one-liner versions to deal with different input types?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Python can't hold a candle to the elegance of Ruby.
Python is excellent for web programming, thanks to a number of frameworks. Zope is the best known, but I much prefer SkunkWeb (http://www.skunkweb.org), which is simple to use and (in my experience, having spent a lot of time trying to get Zope to do things) more flexible. It's also very fast. There is also webware, cherrypy, and others. All these frameworks make it easy to access form fields, manage cookies, build up pages from components, access databases, and use Python to generate dynamic content.
Since Java is unavailable to you because of your platform choice, why not consider C++? (I'm currently supporting a 300,000 line C++ app written on OpenBSD, so I know it works pretty well.)
I'm trying to find out if, in your view, the use of dynamic languages for enterprise applications is a good thing or not. I hold no particular brief for Python (I prefer Ruby).
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.
These statements about programming productivity given X language spouted as truisms still make me grind my teeth. I've spent most of my time programming in C++ and Java. After gaining a good bit of experience with Java, I awaited the epiphany that I was suddenly experiencing a boost in productivity coding in Java. This never happened. My experience in dealing with other professional developers (the company I am currently with employs 80+) is that most with significant experience in both worlds share this opinion. The languages are simply not that far apart on the language tree. Java's "out of the box" libraries dwarf the STL, but it is not as if its difficult to find mature C++ libraries (QT, ACE, BOOST, etc) which cover the bases and provide a cross-platform framework. The level of depth is simply not that wide - nothing like ASM->C. Does anyone really feel writing a complex swing GUI is more efficient than a similar QT one? Back in the day, the lack of templates was a checkmark in the Java win column for "simplicity and productivity". So here we are now with Generic's in Java's latest incantation, along with our old friends enum and printf. It also always amazed me when operator overloading was touted as some highly confusing mess that Java managed to avoid -- when page 3 or so of any Java book has you concatenating strings using +. If anything, Java and C++ continue to grow more similar and this trend is only bound to continue. The popularity of Java has in no small way influenced the thinking and proposals for the impending C++0x standard.
During my time at the university I had a couple professors who were large fans of functional programming. If anything this argument is far more interesting to me as it involves an entirely different programming paradigm (whereas Java and C++ are both "OOP" languages, with extremely similar syntax). LISP has been a garbage collected language since the 60s. However functional programming continues to dodge any real mainstream acceptance.
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.
Yes, it is obviously easier to leak memory in a non-GC language. However, your implication that memory management in a non-GC language is so difficult (and leaks so prevalent) equalizes the greater memory footprint of a GC language is a little baffling. It's simply not that difficult, particularly with the maturity of memory checking toolkits and a variety of well developed smart pointer libraries.
Regarding your comments about performance, let me point you to some interesting comments in "One Half a Manifesto" by Jaron Lanier...
"If anything, there's a reverse Moore's Law observable in software: As processors become faster and memory becomes cheaper, software becomes correspondingly slower and more bloated, using up all available resources...
One part of the answer is fundamental. It turns out that when programs and datasets get bigger (and increasing storage and transmission capacities are driven by the same processes that drive Moore's exponential speedup), internal computational overhead often increases at a worse-than-linear rate. This is because of some nasty mathematical facts of life regarding algorithms. Making a problem twice as large usually makes it take a lot more than twice as long to solve. Some algorithms are worse in this way than others, and one aspect of getting a solid underg
Because using recursion to calculate Fibonacci in the obvious way is a hideously inefficient algorithm. In languages designed to support recursive programming styles, such as most functional programming languages, this will be dealt with. In low-level languages like C, it won't, but then in C you would never implement the algorithm that way in the first place. It's not a fair test of the ability to implement a real world algorithm efficiently in different programming languages, which is the only useful metric you're going to get out of that sort of test set-up.
Compare this with a divide-and-conquer algorithm like quicksort, or an algorithm over a recursive data structure like an insertion on a binary tree, where the use of recursion to implement the algorithm is natural and need not introduce these arbitrary overheads.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
"I'd include using an old-fashioned language like C or C++ in a system which does not require huge speed or efficiency"
I'd like to say that it's not only speed or efficient requirements for C or C++, but for legacy needs as well. One could probably make the argument that more legacy development is done than new speed-dependent code. Last time I wrote C was to interface with a FORTRAN backend. We didn't have the time or money to rewrite 200K+ LOC, nor spend time validating "new" compilers. C was the most logical and quickest choice here.
Main point is that C/C++ have many applications in which they would be used, not just for the sake of speed/efficiency.
Why, o why must the sky fall when I've learned to fly?
How many Starfleet Officers does it take to shoot a Python in the Enterprise... Wait wrong article.
Yeah, I should've made that more explicit in the post (some of the other posts I've made around this thread have said this more clearly).
I would rather go all the way and use C, I am not a big fan of C++ at all. However, this choice has nothing to do with dynamic vs static languages. Like I said, we are evaluating pike (specifically, I am doing the test rewrite in pike) which is statically typed and catches errors like the one I pointed out, yet its just as high level and fast to develop in as python. It doesn't have to be a choice between low level static and high level dynamic, high level static languages exist too.
You are making a big mistake here in assuming that dynamically typed languages offer a development speed benefit over statically typed languages. I can understand why you would think that if you compare working in java to working in python, but try comparing python and pike, and suddenly you'll see that you can have static typing, and fast development speed.
What I am saying is high level, object oriented, interpreted languages are good, and I don't see any reason they can't be useful in an enterprise environment. But they don't have to be dynamically typed, they can and should be statically typed.
> 4) Cost to get software running "right" - $25,000. Cost to upgrade the server to a dual proc - $1,500. Which are YOU going to do?
I'd spend $27,500 and make it 4 times better.
See that "About Us, Products, Services, etc" menu at the top? I moved my mouse to "products," which automatically popped up a menu with "About Zope", "Zope4Intranets", etc. Then I highlighted "About Zope" and right-clicked, assuming my browser would show me a menu that would let me open that page in a tab while keeping the careers page open.
It didn't work.
Because it's not a hyperlink.
That whole top menu is some weird Javascript construction. 2005, and they don't even know how to use hyperlinks on a website yet.
Please, somebody with even modest familiarity with the web, go help these people.
Don't forget that Red Hat has been using Python extensively in its Enterprise Linux releases for years now. Stuff like the system-config tools and... the installer. :)
Wall isn't like that. He's somehow retained his mental agility and rejects the idea that you should code the same way he would.
He's the only believable character on the show!
Then again, shouldn't we all be truly worried for Porthos?
There is nothing wrong with having a variable be a function, and he's not saying that should be a syntax error, or that he can't think of a reason for it. The point is that static typing catches errors that arise when you set a variable you *thought* was a string to be a function. It doesn't stop you from making a variable be a function if you want it to. You just have to want it to, instead of doing it by accident.
// var is the string returned by obj->method() // var is obj->method(), you can now call var()
See, in pike it would go like this:
string var = obj->method();
function var = obj->method;
if you do:
string var = obj->method;
you will get an immediate syntax error, just like if you do:
function var = obj->method();
(assuming obj->method() doesn't return a function of course).
Object reuse usually doesn't reduce the load on the garbage collector on modern systems. On the contrary, it may increase the load. This is because modern generational collectors are optimized for reclaiming short-lived objects. Most collectors pay no cost at all for reclaiming them. Reusing objects creates longer-lived objects, which add to the cost of every GC during their lifetime.
You can submit your faster programs here
"With what you suggest, what's the difference between Java code and C code then?"
The structure of Java makes it easier to deal with large projects as compared to C, and it's less of a minefield than C++.
"what's the point in having the GC? getLocation(Point) looks close enough to something like gets(char*) to be unnerving."
Well yeah. It's basically the same thing. Except it doesn't have a buffer overflow vulnerability.
The point is that you can pass things around without worrying so much about who has one (though of course you still do have to worry for thread safety). In C/C++, you have to take very special care if you want to pass anything that's been allocated around, make sure it has a refcount, etc.
Also, you don't need to do it all the time, just catch the cases that happen a lot. It's usually not that hard to provide two altneratives of a function, where one allocates the object and the other takes it as an argument. It's an optimization, it's optional, and it's damned easy to use. Another example is the use of StringBuffers instead of Strings when you need to concatinate them. Strings are immutable, so it has to do a copy every time you cat two strings, and the old copy is lost.
We'd all like to believe garbage collection were free, but it's not. If we can take a bit of the work away, it's a lot less expensive. We can still use it though.
I actually prefer Python and C to Java, but Java does have its uses.
I rarely criticize things I don't care about.
As for the 'magic' of in-place or not in-place I dont see that as magic. Indeed this is something that garbage collecting object oriented languages should strive for. For example, java and i'd bet python makes every effort to re-use allocated object space from garbage collected objects rather than creating new ones as they are instantiated. This is essentially no different than the program deciding to do a sort in-place because it can. It's analogous to the lstrip being space efficeint on imuatables.
That is by hiding the implementation you are free to do exactly this sort of magic under the hood. From the user's perspective it would be no hardship if sort() always appeared to return the sort as a value. It could be secretly in-inplace due to the Garbage collection of the original memeber when writing a=a.sort().
So __slots__ is analogous to perl psuedoarrays I gather where keys become enumerables. In some ways I wish you would hide all that from the user so that even more efficient access could be implemented down the road. One could Grant back the low-level under-ther-hood access to object functionality with a forma introspection method rather than allow primitive access to the details to the object itself. (ala java) Afterall how often does one need to fiddle with the objects method list manually? exposing this structure freezes the implementation. This is one place where python could make its greatest perfromance enhancement over perl I would think.
Anyhow thank you for your intelligent comments.
Some drink at the fountain of knowledge. Others just gargle.
I would still prefer the Eiffel approach to that. Frankly, I never understood why Java doesn't have any means to store objects on the stack (apart from perceived simplicity). The powerful 'expanded' modifier in Eiffel, or at least value-types in C#, are really useful.
No denying that.
I'm not saying Java is perfect, but the performance is generally good enough for something else to decide which language to use.
I rarely criticize things I don't care about.
I know from experience that syntax I don't like slows me down. I'd rather write more lines in a syntax I'm comfortable with than fewer in a syntax I find painful and annoying to work with.
You're coloured by a particular way of thinking - so whitespace is "trivial" for you. Good for you. It's not for me - or more precisely, the lack of explicit non-whitespace block markers is not trivial for me.
Unconventional semantics doesn't bother me. A syntax I don't like will make me stay far away from a language regarding of semantic properties.
If programming isn't painful then you aren't doing it right. Nothing scares me more than a programmer that still thinks programming is fun. It means they probably either haven't had a customer for their code or they left before their bugs caught up with them.
"Meaningless!, Meaningless!" says the Teacher. "Utterly meaningless!"
I'm sorry, but the "but it's slow" argument does not hold for most software designed today. Let's please get over it.
That's only if it's an interactive application with a reasonable response time. If a human is sitting in from of your app and your app is faster than the human, great.
However, that doesn't work for any underlying software. As processors get faster, software engineers are using increasing degrees of abstraction as a tool. If you're working on one of the lower layers, it better be fast, or else everything on top is going to compound the performance problems.
Operating systems have to be fast, file systems have to be fast, databases have to be fast, http servers have to be fast, web services servers (e.g. SOAP servers) have to be fast, code libraries have to be fast, interpreters have to be fast. Once all those things are fast, you can make the final, end-user app pretty slow and it will still be so fast the user won't know the difference.
However, even that can be a little deceptive. You have to avoid major algorithmic problems. You have to understand all the layers you're building on, otherwise you will misuse some abstracted library and it could perform much more poorly than you expect (even if you follow the documented spec). The more abstractions you rely upon, the easier it is to do that.
Oh yeah, and processors are not improving so much in serial processing as parallel processing. So if your algorithm can't be easily parallelized, you might have a problem even if you spend infinite money on processors.
So, performance will always matter to programmers unless they are really just designing an interface by clicking and dragging in VS.Net. Or maybe if projects stop becoming more complex, which is unlikely to happen.
Social scientists are inspired by theories; scientists are humbled by facts.
You had me right up until you wrote this:
Another example is the use of StringBuffers instead of Strings when you need to concatinate them. Strings are immutable, so it has to do a copy every time you cat two strings, and the old copy is lost.
In reality, nearly every Java compiler since 1.2.1 will optimize for this and will auto-generate StringBuffers on the fly if you concat two Strings.
The
As for algorithmic problems, this isn't really relevant to the point of which language one is using (I'm not sure if you're even trying to argue that?), other than the fact that a language with well-implemented utility libraries is likely to have used as good or better an algorithm to yours.
My post was about programming languages, not programming style, in any case.
I rarely criticize things I don't care about.
It's good to have languages that are not type checked, and it's good to have languages that are. The former is better with smaller groups, smaller programs, or more proficient developers. The latter is better with larger groups working on larger programs with more apprentices on the team. The former allows more flexibility and speed. The latter offers more imposed speed limits (and less car crashes).
Why is dynamic or loose typing allegedly bad for "large" projects? I keep reading this claim from Java fans, but have never seen a clearly described/coded scenario. Can anyone give a specific example?
Table-ized A.I.
It all depends on your application domain. For applications that are predominantly UI/database driven, as obviously many are, C++ has few advantages over something like Java. However, in anything scientific (where performance is often paramount) or in huge markets like embedded or instrument-control applications (where tight code and/or low-level control are often required), languages like C and C++ are still far ahead of the competition IME. Java is making some inroads into the embedded space, but it's barely a blip in the graph right now.
I think that's a little harsh. If there's one thing you can fairly say about C++, it's that Stroustrup and the standards committee take their time and try to reach good, practical decisions. It takes forever to make changes as a result, but with a few exceptions (the designed-by-committee string functionality, for example) the underlying design decisions of C++ are really very robust. Stroustrup's oft-cited book, The Design and Evolution of C++, provides some fascinating insights into how a serious computer scientist designs a language, and the factors that weigh into that decision. Even where I disagree with a decision that's been made, not that that often happens with this particular programming language, I can at least understand the rationale behind the decision.
Compare this with Java's almost amateur development process, and the design weaknesses that have resulted. For ages, the Powers That Be dictated that generics/templates/whatever weren't useful, and wouldn't be included. Lo and behold, a few years later, they concede that they were wrong and retrofit them (but still in a feeble way that misses half the point and 90% of the power). More seriously, although Java has a vast standard library, much of it is a joke compared to the high-quality, often peer-reviewed work found in things like Boost, CPAN, and so on. For example, AWT was so bad they had to invent Swing, and that's still not a patch on serious GUI libraries like Qt or wxWidgets in their various forms.
In fairness, the less formal processes (a.k.a. benevolent dictatorships in most cases) that underlie many scripting languages (notably Perl and Python in relation to the current discussion) tend to be rather more flexible. Even so, how can a language that doesn't even have a specifcation apart from a compiler that its own author couldn't rewrite from scratch possibly be considered to have an industrial-strength design process? (That would be Perl, and indeed the reason for all the completely rewritten underlying mechanics for Perl 6.)
That is indeed a compelling advantage. C++ has always been written for "good programmers", the craftsmen who take their craft seriously enough to learn the details and avoid the obvious mistakes. Unfortunately most programmers aren't like that, and most companies are going to be employing "most programmers" most of the time. It is therefore a sensible management decision to go with technology that mitigates "most programmer" errors.
The only problem is that sometimes, you actually need finer control (and to accept the attendant risks) in order to get a good result, and if you need to hire some geeks to use that control, so be it. If you have a language that actually won't let them bend or even outright break the rules when they know damn well that it is safe to break them in the particular circumstances they're working under, then that's a serious liability to some kinds of project. If you're going to fall back on linking to C functions, using JNI, or whatever every time you need performance, you might as well write in a language like C++ in the first place, and just hire enough good people to write safe, high-performance wrappers for the low-level code...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I can't see your problem. We just use the normal side-effects to communicate with the outside world, and... Oh, did you say Haskell was lazy? You did? Oh, dear.
Seriously, monads aren't such a difficult concept if you're familiar with the basics of functional programming already. The main argument against them is similar to those often used against "design patterns" for OO languages: they get the job done, but other languages can do it all so much more neatly that they seem like a pointless over-complication to anyone who's used to the languages with native support for the feature. Forcing that level of over-complication to maintain conceptual purity or to permit occasionally elegant techniques like lazy evaluation is fine in academia, but a dead end in the real world.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
What Python requires you to do is basically indent you code neatly. Which is what a good programmer is doing already. If you take a good Java program and remove the curly braces it is what a Python program looks like. So I really don't see why it can be a non-trivial issue.
Do you have any representative example in which Python's syntax cause you grieve?
I know what you are saying that some language's syntax can be annoying. Coming from a C background Pascal's := often got me. VB has lot more idiosyncrasy that often drive me crazy. In anycase it does not stop me from cranking out many lines of code. Python's white space syntax is very minor compares to the above cases as it is what we are practicing everyday. I never find any urging need to format my source code wildly.
according to the parent post, Perl does not even do that: $ is either a variable or a reference, so both would work fine on the left side.
You are saying that indentation is good. Ok, so go ahead and indent. That doesn't explain why curly braces have to be removed. What else people want is the ability to have the clear, consise and useful curly braces that they have come to love. Instead of trying to dismiss the valid concerns about whitespace, how about trying to explain what benefit it provides? Saying "its just like what you are already used to" is a cop-out, that's not a benefit. And "it forces you to indent correctly" isn't even correct, as you can clearly have lines that look identically indented, but aren't actually being interpreted that way by python due to a mix of spaces and tabs. At some point you will have to accept the fact that you cannot convince people to give up something they like and find useful, in exchange for nothing. Provide some valid reasons why significant whitespace is good. If they best you can do is "its not that bad really, you'll get used to it", then its clearly a bad thing, not a feature.
Yes, having to enforce someone elses coding standard that we don't like on ourselves is the entire problem. Languages with syntax allow us all to program as we please, then re-indent to the standard *we* choose for our project. That's the entire point.
Try writing some unit tests? No, try not having to test things that should be dealt with by the language. That's the entire point being made. Statically typed languages find these bugs immediately, and you don't have to waste time testing if your variables are what you think they are, its already guarenteed for you. Just because you don't mind wasting your time, doesn't mean everyone feels the same way. Some people like having computers deal with boring crap for them.
When people say "I don't like language X because it has these 2 problems", you stating those same problems again doesn't counter it and make things all good. If you like python go ahead and use it, but stop expecting everyone to put up with pythons problems just because you don't mind having to deal with them. Python loses points for having these problems, but it doesn't having anything on the other side giving it points that I've seen. I don't find python offers any benefits over perl, ruby or pike, but it definately has a couple downsides. So, we're going to switch to one of those other languages that doesn't go out of its way to try to make things difficult for us.
I benched the two pieces of code: (note the slashdot ecode tag removes the proper indentation, but this should be obvious in context)
and then using your suggestion:timing these shows the try clause almoist QUADRUPLES the time: the first runs in 0.62 seconds and the latter runs in 2.4 seconds!!!
Now here is the is the point I was making in my original post: if you try this without using the get its almost 6 times faster than using the .get format and 24 times faster than doing it with the try statement!!!!!!!
To show this consider the following example: In this special problem we know ahead of time what the keys will be. In general we would probably not know this if we were say parsing a file. But since we know them its cheap to write a loop to initialize them first. then we dont have use the get() statement or the try. then we can see how much speed we are losing to the get() statement.
this runs in 0.11 seconds. Which is about 24 times slower than using the try.your information about how to replace autointialization appears to be seriously mistaken.
Some drink at the fountain of knowledge. Others just gargle.
Re: CPAN -- a bunch of improvements for PyPI (the Python Package Index) were written during PyCon, which should go some length to making something like CPAN. It's hard to really say -- CPAN is actually just a very simplistic FTP site, with lots of tools built on top. So it's a very different design. But with just a little more work, and a lot more evangelism PyPI (a lot of Python programmers don't even know about it) should become very useful.
er..no that's not what I said. in perl if you want the function you have to prefix the name with a slash, otherwise the function is simply called.
> 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.
C or C++, right? How about C,C++,Assembly and other things that I have no clue about and therefore declare them complex! How else on earth someone can put C and C++ on the same shelve when speaking about something like "code complexity"?
JFYI: C++ with STL (and Boost if you want so) is just as fast to develop in as most so-called loosly-typed scripting languages. And speed is here for you as well.
If it's really a problem, there are a myriad of solutions -- Numeric and numarray for lots of numbers, psyco for JIT optimizations, Pyrex for a Python-like syntax that compiles to C (and can be as fast as C if you use it correctly), and lots of other new options as well -- IronPython is supposed to be faster than CPython (the standard implementation), there's quite a bit of work on type inference, PyPy is working hard at compiling Python to fast C, Boost can inline C++ code... there's a huge number of options.
I've never encountered someone who had to throw a project away because of performance issues in Python. Sometimes they have to change the design, move some small parts of C, make better use of other people's libraries, and always of course driven by profiling -- but that's the kind of refactoring that always happens in development. And for a very large number of applications it simply is never a problem.
Uh, no, i hate it because i've coded in Java and hated it, but since i didn't code many things in Java before hating it (no big apps or anything really major) i don't consider myself "fluent" in Java.
I know the basis, with a few hours on the Javadoc (which i'm even able to find ! Ain't I impressive) i'd probably be able to code something in Java, but i still don't like the language
Is that clearer?
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
That means Python is slow.
Having two types of allocations (and parameter passing semantics) makes things more complicated. It's simpler to think of all allocations being heap allocations. However, there are optimizations to automatically use the stack in some of the cases where it's safe (see escape analysis).
just what most companies need... "new" migration experts pushing widgets that nobody on staff knows how to use.. but hey it must be better, it's new.
Get your torrents...
"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."
Already being discussed in comp.lang.forth The short is that most "higher-level" languages need lots of "scaffolding" to verify the code is correct.
Without a proper steering comittee, made of independent bodies you can't consider a language "enterprise worthy". Take PHP for example - hobsons choice, "The Zend way, or the highway". Same goes for Perl, Python and Ruby - very few people are controlling the direction the language is taking. With Java, at least you have the JCP, JSRs etc - expert groups spend a great deal of time suggesting and revising APIs before they are finally democratically decided upon and implemented.
Java works because of this, and because it has such a large and stable selection of standardised components.
Just my $0.02
It sounds like you're basing that purely on your own experience. Perhaps you simply haven't encountered that much C and C++ code, or you know some particularly good Python programmers?
Here's a more objective test for you: which languages underlie the vast majority of high-performance mathematical/scientific/engineering applications developed in the past decade? If you need a clue, look for software developer job ads from scientific companies. ;-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Your points on this topic are valid. Specifically wrt comparing Java and C++.
When it comes to comparing productivity in languages there are many diffrent variables. The three (I'm sure you can think of more) that IMHO differ a lot between C/C++, Java and Python are code compactness, code accuracy and libraries.
Often parts of these are related, eg Python has a rather high code compactness and coupled with powerful standard libraries this means that very little code can do a lot.
In my experience Java and C/C++ are about equal when it comes to code compactness. All are quite verbose languages, although you can do "hacks" in C/C++ which in Java requires a lot of type-casting. Scripting languages and eg Haskell as a functional language have much more compact code. This may translate to faster to write and easier to understand code. (In the case of eg Perl this isn't necessarily so. But that's more compact due to obscurity instead of clearness.)
By code accuracy (not a very good name for it) I mean that the code works like you think it should. Issues that appear due to eg memory or runtime issues are detrimental to this. A language which make it easy to catch errors and handle them at compile time get high ratings in this area. It doesn't really have anything to do with logical errors in the code, if the coder has a poor understanding of the problem no language can help. This is an area where C/C++ suffers compared to eg Java. In my experience you spend a lot more time in C/C++ chasing down memory issues and runtime segfaults than in a GC language.
Libraries are probably the most important part though. Good libraries can make you extremey productive as well as making the code easier to understand. In this aspect Java and scripting langages typically triumph over C/C++. Naturally STL, Boost etc are all work-arounds for this, but it takes a lot more knowledge for the coder to know about these than standard libraries. (The discussion is really about poor/normal coders after all.)
True. But again, the discussion was not so competent or sloppy programmers and programs that run a long time.
It turns out that when programs and datasets get bigger (and increasing storage and transmission capacities are driven by the same processes that drive Moore's exponential speedup), internal computational overhead often increases at a worse-than-linear rate
Yes, naturally. Not many algorithms are less than O(n) when they operate on large datasets.
The data is larger both because there is some "sloppyness" but also becuase the data is a lot more complex today than 10 years ago. Back then MP3's were really neat and the thought of having your computer chew through multi GB data like DVDs for processing were not very common.
Bloat and complexity increases, but so does "useability".
You find very few 3D engines coded in Java. But you also find that the majority of games today use internal scripting languages. These are often standard languages such as Java, Python or Lua.
Right tool for the job. As another poster wrote, don't write everything in one language. And sloppy coding in C/C++ may very well turn out slower than a sloppy coding in eg Python.
And yes I agree that C# and Java are very similar. I have never doubted that. C++ is not really the same thing though, mainly due to lack of a standard set of libraries and memory management.
Python proponent constantly harp on that one of the advantages of Python is that it gets rid of the {} bracket debate, but completely miss the point that it opens up the more violent "space versus {}" debate or the "you indent 2 spaces? That's unreadable, I use 8 spaces" debate, or that "how the hell do I fix a file that has it's indentation structure broken because has a mix of tabs and spaces -- with braces this mess wouldn't have happened".
Why not be done with it an use the Ruby/Modula style of:
. . if condition:
. . . . stuff
. . end
It's easy to reformat in a good editor to any tab style, and there's only one logical indent struct form.
First off, I'm willing to bet that virtually none of the little apps you currently have running are written in Java/Python whatnot.
If you're running bittorrent, you're running a python application.
Extrapolate that a little... and you discover that means 20% of net traffic is generated by python code.
Just because there's the possibilty of improved performance someday, that doesn't mean you can't compare what exists now. This is what exists, this is what people are trying to claim is so much better than python, this is what gets compared. If ruby increases in performance in the future then that's great, but right now it is a potential issue. Also, pike isn't as old as python either, and has fewer developers and a much smaller community, but its faster than python.
I have tried python. Whitespace didn't prevent me from trying it, it seemed fine at first. Then when I did something larger, I realized what a problem it actually is, and stopped using python.
What I am saying is that removing curly braces does not add any benefit, the language is not any more clear or concise. But there are problems with removing the curly braces. So if you add up the fact that there is no benefit, but there are downsides, that means its a problem. If you don't mind dealing with the problem that's up to you, but trying to pretend its not a problem by claiming "its just like what you should be doing anyways, only kinda a pain in the ass in certain situations" isn't going to solve the problem.
if a > b:
if a > c: # indented with 4 spaces
print "python forces me to use stupid editor settings" # indented with 8 spaces
print "I am less productive in python as a result" # indented by a tab
If your editor's indentation level is 4, then this is how the code looks. But the second print is always executed when the first one is, despite not looking that way. And you can always do bizarre ass indentation where every level is a different width. I realize you shouldn't code this way, and obviously I don't *intentionally* code this way. But there is more to programming than simply writing a piece of code the first time, many other people read it and edit it afterwards, and cause weird errors like this if they don't worship at the alter of python editor settings, or when they try to move a block of code to a different place, where the indentation is different, and have to try to fix it, and can very easily make a mistake. This is completely avoided by simply using curly braces, and any inconsistancies in indentation can quickly be fixed by running indent on the code.
So, clearly removing the curly braces does NOT force the code to be indented clearly, instead it just forces me to use editor settings I dislike, have a hard time working with other people, and makes it a huge pain to move blocks of code since I now have to manually re-indent a whole crapload of code. Even if you don't think these downsides are a big deal, the fact is they are downsides, and there is no upside.
That tells you, at most, what languages people who choose languages think are better (not just fast) for mathematical/scientific/engineering applications. It's not really an objective test of what languages are actually fast.
'Ambassador Kosh' certainly isn't the only one to have observed that the C and C++ community tends to measure speed based on microbenchmarks, and not on real-world applications.
Of course it's slow, but it was always intended to by a hybrid with C. Since a significant fraction of the libraries are written in C, it's not actually that hard to write reasonably fast Python code.
For example, a project I worked on last year was only 20% faster in C than in Python. It relied heavily on the regex library, which is written in C.
I rarely criticize things I don't care about.
That's true, of course.
However, you're unlikely ever to get a study that produces the same large-scale, professional-standard development in two different langugages with development teams of controlled experience levels etc., just to see which one works better. The cost overhead would be terrible. The closest approximation I can think of is to consider the view of a whole community with huge amounts of experience and a genuine willingness to try new approaches if they look beneficial. In the absence of one of those, I suggest that the scientific software community is again the closest realistic approximation. Right now, that community is pretty heavily pro-C and C++ (with a bit of FORTRAN, but not much new work in it these days).
This is a pretty heavy chain of assumptions, but what more authoritative study would you suggest, given what's ever likely to happen in practice?
On the contrary; in my experience, the low-level guys are happy to take on whatever benchmarks are around. It's the high-level language guys, who are always trying to demonstrate that their pet language is "as fast as C" (or more likely "within a factor of N of the speed of C") that frequently cite microbenchmarks like the Programming Language Shoot Out.
Using mostly (or only) imperative programming techniques seems to be the current favourite tactic here. After all, you can easily show that Language L is comparable in performance to C if you write lots of simple programs using L's imperative features, which probably compile down to pretty much the same machine code as the equivalent C would generate. This conveniently avoids using other features that Language L advocates cite as its big improvements, and thus it also avoids the horrible possibility that they might actually suck when it comes to speed.
IMHO, a much more interesting study that the PLSO is to look at the structure of the high-performing entries in the ICFP competition, where skilled developers are writing non-trivial code in many languages according to their own preferences. The overall results there have been reasonably consistent over the years, and support many held perceptions very strongly: in particular, it really is the algorithm that matters most in practice, and the community's ideas of relative speeds of languages are actually pretty accurate.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I don't think so. If you develop with Qt, you either have to pay big bucks to Troll Tech up front, or you have irrevocably committed to putting your software under an open source license. Since the latter is usually not acceptable to enterprises (even open-source friendly enterprises), this means paying a lot of money per developer up front.
Keep in mind that there is plenty of software that never gets "distributed". Licensing isn't an issue then, really. If you use Qt under the GPL to develop an in-house tool/application/minderbinder, you're not exactly obligated to go set up a CVS repository at SourceForge.
If other reasons we do lack, we swear no one will die when we attack
I'd settle for making them all watch the first couple of lectures from a decent data structures and algorithms course. That alone would shatter the illusions of the McProgrammers who don't understand the different performance characteristics of a list, an array and a map. Just getting that simple choice right would do a lot to fix the pathetically slow code we see everywhere today.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Are you implying that 1 gig of ram IS NOT adequate for most people?