Someone tried getting rid of the GIL several years ago, and CPython ran about 2x slower. That said, some implementations -- like Jython and IronPython -- don't have the GIL. So, it's possible. But hurting everyone's performance for the negligable benefit of multi-processor scalability (which isn't the same as any actual performance requirement) is pretty silly. I'd much, much, much rather see better multi-process capabilities in Python. That Java leans so heavily on threads doesn't mean Python has to.
I almost never have problems with performance in Python, and I program in it exclusively. For those things where performance really matters -- e.g., image processing -- there are library written in C that are available from Python (and fairly easy to use) like PIL. There are lots of algorithms in Python itself that are extremely fast, like a great hashtable implementation (Python dictionaries) and sort algorithm.
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.
BTW, there's been a lot of recent development on Jython in the past few months, and it should resolve a lot of its issues (it's been stuck on par with Python 2.1 for quite a while, while Python is now up to 2.4). The Python Software Foundation actually gave a grant to a developer to help resolve the issue.
If you are writing code that only gets run infrequently and needs to work, you need to use unit testing. It's not a good idea, you ABSOLUTELY MUST TEST. Unless it doesn't matter if it works, and then who cares?
You'll be able to write the code in Python, and the tests, in less time than most statically typed languages. Many would argue that you can write code and tests in any language faster than writing WORKING code without tests... but that starts down a different avenue of discussion.
I think the standard library is challenging because it's representative of a younger Python, when backward compatibility wasn't a liability (since there was no backward) and the community of developers was small. As it grew older, there's been several cases where people have ported Java libraries as part of the standard library (unittest, logging), and the result hasn't been very good. Not to pick on those programmers who made those modules, but it has made the Python community a little shy about adding new modules unless they are really stable and have proven their utility and pleasantness of interface. So now the standard library is growing slowly; maybe with some language changes this could be resolved, but it's just a hard problem.
I wrote more about the standard library sometime back on my blog.
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.
SAP's is called SAPDB, or more recently MaxDB, and they are connected with MySQL now. There's also Firebird, which was Interbase when it was proprietary. Then there's the embeddable SQLite for the low-low end of SQL databases.
this page at riseup.net describes some software that supports the options for incremental hardlink-based backups, as there's been a bunch of packages that implement that.
Ah... from my reading I was confusing, and thought it was power-limited to 200 of wire, not 200 feet from the wire. Hmmm... so does this mean everyone on my block gets my radio station, or just everyone in my building, or just all the rooms that share my circuit?
If you use one of these transmitters, will plugged-in radios pick up the stations? Or do receivers require some special hardware as well? What kind of sound quality can you expect?
I'm a big fan of Logo. One of the reasons is that it's not written for programmers, it's written for kids who may or may not become programmers. It has things that would make normal programmers cringe -- like all the shortcuts (FD for FORWARD). But have you seen a young child type? Believe me, FD is enough of a struggle, "intention-revealing selectors" is not one of their top priorities.
Really Logo wasn't intended to teach programming (though of course it did that). It was intended to teach math, and algorithmic thinking, and thinking in general. And, paired with the right teacher and an interested pupil, it's really great at that. Without realizing it, a child can end up learning not just geometry (through the turtle graphics), but a lot of pre-algebra. I think programming is a far more accessible way to introduce algebra than the traditional techniques; even young children can understand variables in programs, when the declarative variables that are used in mathematics are much more challenging.
It's also a better language than many of "teaching" languages, like Basic. It's an old-school version of Lisp, with a little tweak to avoid the parenthesis. And don't be fooled by things that call themselves Logo when they are just turtle graphics. Turtle graphics are cool, but just a piece of the equation. (Though not-so-coincidentally, Python has built-in turtle graphics).
If you are really interested in programming as education, I might recommend the book Mindstorms, which is a classic about some of the theory behind teaching with Logo. It's not a practical guide, though many of those also exist.
If you are looking for a Logo implementation, on Windows I would recommend Elica, MSWLogo, and UCBLogo, in that order. On Mac or Linux, you can use UCBLogo, Turtle Tracks (a cross-platform Java implementation), or on Mac one of a number of (rather expensive) commercial Logos. If you are a programmer and feel like fiddling alongside your child, you might try my project PyLogo, which is cross-platform and written in Python, but quite rough around the edges. Or if you want something that is Logo, but pretends to be a general-purpose scripting language, look at Rebol. Or for a slightly-lame but functional embedded robot Logo, Cricket Logo. Or for older people, NetLogo is a massively-multitasking implementation to use to play around with autonomous entities (e.g., ant simulations). NetLogo is kind of the successor to StarLogo.
Re:Discarding too many people
on
Defining Google
·
· Score: 1
I think I'd rephrase your comments as: solving hard problems quickly is fine, but solving really really hard problems at all is much more valuable.
And I'd agree, but Google is probably being conservative, being more concerned that they don't hire the wrong person, even if it means they miss the right person sometimes. I'm sure anyone at Google doing hiring would admit the possibility they've passed up good candidates.
It's not subsidizing to pay increased product costs due to increased shipping costs. That's just a matter of paying the *real* cost of the product. It's subsidizing when we collectively, as tax payers, pay for infrastructure used to ship products that go to individuals. I'm not 100% against subsidies, but I'm tiring of the road subsidies.
Re:Not Learnn the API - Learn the Language
on
Defining Google
·
· Score: 2, Insightful
once you have a few good years under your belt, any decent programmer will tell you that all languages are essentially the same.
Maybe an okay programmer will tell you that, but a good programmer doesn't believe that. A good programmer has a thoughtful appreciation for their tools, and some tools are more powerful than others.
I would interpret it, from a hiring perspective, that after a couple years the skills you gain while developing in a language are largely transferable. So, for a Java job it's good if you have a couple years of Java experience. It's also good if you have more than a couple years experience, but it doesn't have to be in Java. Maybe it would even be better if it wasn't in Java; though really it's more important that the candidate be intellectually curious, and that's not necessarily represented by the specific languages they've been employed to use.
Programming is about algorithms and design. The language you use to implement those ideas is nothing more than a tool.
I'd give the language more credit than that. The design you'll use in Smalltalk will be much different than the design you'll use in C. At least if you are doing it right. They say you can program FORTRAN in any language; but that doesn't make it right;)
I'd place algorithm skill at a distant second to design skills (at least for most jobs; maybe not if you are working on a 3D renderer). For most programming jobs, you only have to be Good Enough at algorithms, and know when to use the right ones. And if you get it wrong, it should be easy to fix. If it's not easy to fix, you've got a design problem. Good design is way more important than good algorithms, and bad design can be way more damaging than bad algorithms.
I'd probably lump metholodogies in with design, but maybe it should be considered separately; knowledge and use of good programming methodologies (even informally) is also very valuable, and something that is very tied to experience. Of course, some people don't get anything out of their experience, and some people get a lot -- but that's just what you'll have to find out in the interview.
The days of needing to know the language's API inside and out are over - Google took care of that.
For the most part I'd agree. Not because of Google, but because there's just too many APIs to reasonably know them. It should be expected that you'll learn the necessary domain-specific APIs on the job when you are hired.
If you don't use it, what's the problem with tolls? And if you do use it, why do you think other people should be subsidizing your road use?
I travel relatively short distances. I get angry when my tax dollars go to subsidize the excessive travel of other people. And if you really NEED to travel, then suck it up and pay the toll.
As a bit of reference, the 55mph speed limit of yore was partly justified as a way of saving gas. And it does, in fact, save a lot of gas. But obviously these days saving gas doesn't matter.
Re:Ruby seems on the right track.
on
RAD with Ruby
·
· Score: 2, Interesting
Python Is Not Java is a good description of how to approach programming differently when using a dynamically-typed language. Pretty much everything it says applies to Ruby as well. One of the things it mentions is that in most cases where Java programmers use XML, it's to make up for the deficiencies of Java, and you express the same things using Python (or Ruby) source code, which is easier to work with and more general than any XML configuration.
Re:Short version...
on
RAD with Ruby
·
· Score: 2, Interesting
As for the Python vs. Ruby soapbox: I think it'a a valid component of the news because the two languages are fighting for mindshare in the same pool of savvy OO-script developers.
Not really; if you are a savvy OO-script developer, you are using Ruby or Python or something like it already, you've made your choice. Both languages are trying to pull new developers from other languages, like C or Java. As such, I think they actually help each other -- the potential pool of new people is still very large. Once you've gotten as far as using Python (if you have a statically typed, compiled background), it's a small step to use Ruby, and vice versa. A Python developer should feel quite comfortable with Ruby, compared to most other languages (and vice versa).
Or, if Python gets a good CLR/.NET implementation, the process and lessons will be very applicable to Ruby. Ditto Parrot. Ditto SWIG. And so on.
Once you know 1 or 2 languages you can pick up the others quickly if you REALLY understand how to develop software.
I don't really agree with this, though I did at one point. As I've become a better, more experienced programmer, I no longer believe it to be true.
If it's just syntax, sure. Libraries are also important, and change with each language. And they take a while to learn; first to learn what exists, then about the appropriateness and subtleties of that library. But learning those libraries is just work, not education. Learning to learn libraries is education, I suppose. But I digress...
It's important to learn programming methodologies, and those are harder to pick up than just syntax. Or, maybe worse, you won't pick them up just by coding, because you can probably use techniques you are comfortable with and avoid the appropriate styles for the language and environment you are using. School gives you a chance to disregard (most) deadlines and need for productive code, and focus on longer term goals and deeper understanding.
School is your chance to learn and study important languages that you might not use later, but which can effect your understanding of programming. Smalltalk is a good example -- it has had a deep impact on my programming since I learned it and studied it and its standard library (if you don't learn the Smalltalk library, you are missing out on most of the ideas it has to offer). But I don't use it at all anymore.
I also use Scheme notions all the time, in the form of higher-order functions, and other functional programming techniques. You often won't encounter these techniques normally, or if you do you won't recognize them for what they are.
And looking back, I wish I had learned a language like Erlang that emphasized concurrency.
And while in many ways these higher-level languages were my influences, languages like C are important too. I never touch pointers these days, but it's important that I know they are under there, hidden from view but always present. It also helps me understand where other people are coming from. I never learned Java, which was probably a mistake, but then it's not really a very pure expression of any idea so I don't think I missed anything big. It's one of those few languages that makes me sad whenever I read it, so I doubt I would have effected me much (in any positive way). I knew Basic really well at one time, and it hasn't influenced me; not every language has something new to offer.
Now I use a language that accomodates most any technique I care to use (Python). I think it's all the more important that I have the background of using other languages, because I could easily fall back into a small set of patterns, and miss out on important design techniques. One or two languages isn't nearly sufficient.
I was also stunned to learn how flexible decorators were in the previous version of python. It's refreshing to be see functions treated as objects... unless I'm mistaken about the concept.
Another important part has been Python 2.2's new-style classes and descriptors. Descriptors are basically objects with special methods (__get__, __set__, __delete__). When you access a class or instance attribute, instead of returning the descriptor, the a method of the descriptor is called. This is what allows classmethod, staticmethod, and property, but also a number of other declarative techniques for class definitions. Well, it's one of several things that work together to create interesting new possibilities in Python.
I played around with several source control systems a while back; I like Darcs, it was the easiest of the distributed systems to understand, with a concise and easy-to-understand command-line interface.
But in the end I think a centralized repository is right for many (most?) projects: Why Bitkeeper Isn't Right For Free Software
(by Greg Hudson) was the most convincing argument to me.
Of course, you can simulate a centralized model with a distributed system (just don't use the distributed bits), but it seems like you are on your own at that point. Subversion is behind when you compare distributed features (of course), but when you compare the other features (usability, access via various method, programmatic access, etc), it's way ahead. As it would be; centralized systems are easier to think about, so they are easier to develop with and on top of.
You don't even have to make egregious mistakes to have net negative returns. If adding 20% more time causes a 20% decrease in productivity, then you'll lose productivity: 40*1.2 = 48 (hours); 48 * 0.8 = 38.4 (actual productive time).
If you are overworked for extended periods of time, your overtime isn't just effected; all your time is effected, which is why you have negative returns. According to studies even small amounts of consistent overtime can lead to negative returns.
Push for quality ensurance measures like strong system and unit tests. It won't necessarily punish this programmer, but it might make his work more productive, and keep the rest of the team from the stressful and boring work of debugging someone else's code. Unit testing is not a hard sell to management, but it can be very hard to get individual programmers to actually participate.
Slashdot Mirror
- Older
- More mature: used by a wider variety of people for a wider variety of tasks, community process more developed
- Unicode
- Syntactically simpler; less punctuation
- There Should Only Be One (Best) Way To Do It (not always succeding -- but at least we try)
- Less opportunity to globally effect the language/process -- e.g., you can't change the behavior of strings throughout the system
- Larger community
- More libraries and software
- Better OS support -- standard on most Linuxes, Mac OS X
- Some corporate support (e.g., IronPython); EU funding
- Distributing Python apps fairly easy. Large-scale distributions have been successful (e.g., BitTorrent, iPodder)
- OS-level threading (I don't believe Ruby has this, though I think they are trying to add it)
Well, those are the ones I can think of now.Someone tried getting rid of the GIL several years ago, and CPython ran about 2x slower. That said, some implementations -- like Jython and IronPython -- don't have the GIL. So, it's possible. But hurting everyone's performance for the negligable benefit of multi-processor scalability (which isn't the same as any actual performance requirement) is pretty silly. I'd much, much, much rather see better multi-process capabilities in Python. That Java leans so heavily on threads doesn't mean Python has to.
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.
BTW, there's been a lot of recent development on Jython in the past few months, and it should resolve a lot of its issues (it's been stuck on par with Python 2.1 for quite a while, while Python is now up to 2.4). The Python Software Foundation actually gave a grant to a developer to help resolve the issue.
You'll be able to write the code in Python, and the tests, in less time than most statically typed languages. Many would argue that you can write code and tests in any language faster than writing WORKING code without tests... but that starts down a different avenue of discussion.
I wrote more about the standard library sometime back on my blog.
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.
SAP's is called SAPDB, or more recently MaxDB, and they are connected with MySQL now. There's also Firebird, which was Interbase when it was proprietary. Then there's the embeddable SQLite for the low-low end of SQL databases.
this page at riseup.net describes some software that supports the options for incremental hardlink-based backups, as there's been a bunch of packages that implement that.
Ah... from my reading I was confusing, and thought it was power-limited to 200 of wire, not 200 feet from the wire. Hmmm... so does this mean everyone on my block gets my radio station, or just everyone in my building, or just all the rooms that share my circuit?
If you use one of these transmitters, will plugged-in radios pick up the stations? Or do receivers require some special hardware as well? What kind of sound quality can you expect?
Really Logo wasn't intended to teach programming (though of course it did that). It was intended to teach math, and algorithmic thinking, and thinking in general. And, paired with the right teacher and an interested pupil, it's really great at that. Without realizing it, a child can end up learning not just geometry (through the turtle graphics), but a lot of pre-algebra. I think programming is a far more accessible way to introduce algebra than the traditional techniques; even young children can understand variables in programs, when the declarative variables that are used in mathematics are much more challenging.
It's also a better language than many of "teaching" languages, like Basic. It's an old-school version of Lisp, with a little tweak to avoid the parenthesis. And don't be fooled by things that call themselves Logo when they are just turtle graphics. Turtle graphics are cool, but just a piece of the equation. (Though not-so-coincidentally, Python has built-in turtle graphics).
If you are really interested in programming as education, I might recommend the book Mindstorms, which is a classic about some of the theory behind teaching with Logo. It's not a practical guide, though many of those also exist.
If you are looking for a Logo implementation, on Windows I would recommend Elica, MSWLogo, and UCBLogo, in that order. On Mac or Linux, you can use UCBLogo, Turtle Tracks (a cross-platform Java implementation), or on Mac one of a number of (rather expensive) commercial Logos. If you are a programmer and feel like fiddling alongside your child, you might try my project PyLogo, which is cross-platform and written in Python, but quite rough around the edges. Or if you want something that is Logo, but pretends to be a general-purpose scripting language, look at Rebol. Or for a slightly-lame but functional embedded robot Logo, Cricket Logo. Or for older people, NetLogo is a massively-multitasking implementation to use to play around with autonomous entities (e.g., ant simulations). NetLogo is kind of the successor to StarLogo.
For more information on Logo, you can look at the Logo Foundation, or get in touch with many helpful users in the LogoForum Yahoo Group.
And I'd agree, but Google is probably being conservative, being more concerned that they don't hire the wrong person, even if it means they miss the right person sometimes. I'm sure anyone at Google doing hiring would admit the possibility they've passed up good candidates.
It's not subsidizing to pay increased product costs due to increased shipping costs. That's just a matter of paying the *real* cost of the product. It's subsidizing when we collectively, as tax payers, pay for infrastructure used to ship products that go to individuals. I'm not 100% against subsidies, but I'm tiring of the road subsidies.
I would interpret it, from a hiring perspective, that after a couple years the skills you gain while developing in a language are largely transferable. So, for a Java job it's good if you have a couple years of Java experience. It's also good if you have more than a couple years experience, but it doesn't have to be in Java. Maybe it would even be better if it wasn't in Java; though really it's more important that the candidate be intellectually curious, and that's not necessarily represented by the specific languages they've been employed to use.
I'd give the language more credit than that. The design you'll use in Smalltalk will be much different than the design you'll use in C. At least if you are doing it right. They say you can program FORTRAN in any language; but that doesn't make it rightI'd place algorithm skill at a distant second to design skills (at least for most jobs; maybe not if you are working on a 3D renderer). For most programming jobs, you only have to be Good Enough at algorithms, and know when to use the right ones. And if you get it wrong, it should be easy to fix. If it's not easy to fix, you've got a design problem. Good design is way more important than good algorithms, and bad design can be way more damaging than bad algorithms.
I'd probably lump metholodogies in with design, but maybe it should be considered separately; knowledge and use of good programming methodologies (even informally) is also very valuable, and something that is very tied to experience. Of course, some people don't get anything out of their experience, and some people get a lot -- but that's just what you'll have to find out in the interview.
For the most part I'd agree. Not because of Google, but because there's just too many APIs to reasonably know them. It should be expected that you'll learn the necessary domain-specific APIs on the job when you are hired.If you don't use it, what's the problem with tolls? And if you do use it, why do you think other people should be subsidizing your road use? I travel relatively short distances. I get angry when my tax dollars go to subsidize the excessive travel of other people. And if you really NEED to travel, then suck it up and pay the toll.
As a bit of reference, the 55mph speed limit of yore was partly justified as a way of saving gas. And it does, in fact, save a lot of gas. But obviously these days saving gas doesn't matter.
Python Is Not Java is a good description of how to approach programming differently when using a dynamically-typed language. Pretty much everything it says applies to Ruby as well. One of the things it mentions is that in most cases where Java programmers use XML, it's to make up for the deficiencies of Java, and you express the same things using Python (or Ruby) source code, which is easier to work with and more general than any XML configuration.
Or, if Python gets a good CLR/.NET implementation, the process and lessons will be very applicable to Ruby. Ditto Parrot. Ditto SWIG. And so on.
If it's just syntax, sure. Libraries are also important, and change with each language. And they take a while to learn; first to learn what exists, then about the appropriateness and subtleties of that library. But learning those libraries is just work, not education. Learning to learn libraries is education, I suppose. But I digress...
It's important to learn programming methodologies, and those are harder to pick up than just syntax. Or, maybe worse, you won't pick them up just by coding, because you can probably use techniques you are comfortable with and avoid the appropriate styles for the language and environment you are using. School gives you a chance to disregard (most) deadlines and need for productive code, and focus on longer term goals and deeper understanding.
School is your chance to learn and study important languages that you might not use later, but which can effect your understanding of programming. Smalltalk is a good example -- it has had a deep impact on my programming since I learned it and studied it and its standard library (if you don't learn the Smalltalk library, you are missing out on most of the ideas it has to offer). But I don't use it at all anymore.
I also use Scheme notions all the time, in the form of higher-order functions, and other functional programming techniques. You often won't encounter these techniques normally, or if you do you won't recognize them for what they are. And looking back, I wish I had learned a language like Erlang that emphasized concurrency.
And while in many ways these higher-level languages were my influences, languages like C are important too. I never touch pointers these days, but it's important that I know they are under there, hidden from view but always present. It also helps me understand where other people are coming from. I never learned Java, which was probably a mistake, but then it's not really a very pure expression of any idea so I don't think I missed anything big. It's one of those few languages that makes me sad whenever I read it, so I doubt I would have effected me much (in any positive way). I knew Basic really well at one time, and it hasn't influenced me; not every language has something new to offer.
Now I use a language that accomodates most any technique I care to use (Python). I think it's all the more important that I have the background of using other languages, because I could easily fall back into a small set of patterns, and miss out on important design techniques. One or two languages isn't nearly sufficient.
An Oldy-but-Goody from Tom the Dancing Bug: Ethical Issue Raised by Man-Cow Organ Slave (Salon, may involve mandatory ad watching)
But in the end I think a centralized repository is right for many (most?) projects: Why Bitkeeper Isn't Right For Free Software (by Greg Hudson) was the most convincing argument to me.
Of course, you can simulate a centralized model with a distributed system (just don't use the distributed bits), but it seems like you are on your own at that point. Subversion is behind when you compare distributed features (of course), but when you compare the other features (usability, access via various method, programmatic access, etc), it's way ahead. As it would be; centralized systems are easier to think about, so they are easier to develop with and on top of.
If you are overworked for extended periods of time, your overtime isn't just effected; all your time is effected, which is why you have negative returns. According to studies even small amounts of consistent overtime can lead to negative returns.
Push for quality ensurance measures like strong system and unit tests. It won't necessarily punish this programmer, but it might make his work more productive, and keep the rest of the team from the stressful and boring work of debugging someone else's code. Unit testing is not a hard sell to management, but it can be very hard to get individual programmers to actually participate.