The Python Paradox is now the Scala Paradox(yes-no-cancel.co.uk)
yes-no-cancel.co.uk
The Python Paradox is now the Scala Paradox
http://www.yes-no-cancel.co.uk/2009/09/18/the-python-paradox-is-now-the-scala-paradox/
58 comments
Esoteric languages are a lot of fun. But they're not very productive, exactly for the reasons mentioned: lousy IDE support, buggy compilers, few libraries, few bindings to existing libraries, and so on. When you work in a stable language, you can assume that when something goes wrong -you- messed up. In a new and cool language you don't have that luxury.
You'll be less productive, but you'll have more fun when you get to program in language. A good trade off? I don't think so. A few years down the road you'll have to maintain the same project. The honeymoon period is over, and the code base isn't quite as good as you'd like it to be (you designed the project back when you didn't know the language very well, and it shows). You know you could spend a few weeks refactoring, but that would probably introduce bugs and you'll drive the other people in your team crazy if you start renaming methods, and move stuff around just to make the code "nicer". And besides, you'd much rather be programming in the next-nifty-language, because it lets you extend the syntax at runtime and it has a debugger that will let you go back in time.
The bottom line is that when you pick a language that is on the cutting edge of cool right now will no longer be cool a few years from now, but it still won't have any libraries and other essentials. Languages too have to cross the chasm, and they all have to go through a period where they're neither new and exciting nor stable.
If you're serious about software, concentrate on writing something that is reliable as hell and easy to maintain and install. Want a challenge? Write your app in such a way that power can be lost at any point in time without losing any user data. Or (for desktop apps) make sure that the UI -never- hangs, even when the hard drive has to spin up. Software is never done, there are always things you can make better, more fault tolerant, faster. It's not as if we've run out of challenges.
Messing around with unstable languages is a lot of fun. It's educational too. But don't build your business around it. Python/Django and Ruby/Rails are only barely stable enough to work with. Thinking that using Haskell, Clean, IO or Lisp will be a net benefit to productivity is foolish.
(Of course there are obvious exceptions, and that Clojure and Scala use the JVM does make the whole library thing less of an issue. But it's still a big deal.)
You'll be less productive, but you'll have more fun when you get to program in language. A good trade off? I don't think so. A few years down the road you'll have to maintain the same project. The honeymoon period is over, and the code base isn't quite as good as you'd like it to be (you designed the project back when you didn't know the language very well, and it shows). You know you could spend a few weeks refactoring, but that would probably introduce bugs and you'll drive the other people in your team crazy if you start renaming methods, and move stuff around just to make the code "nicer". And besides, you'd much rather be programming in the next-nifty-language, because it lets you extend the syntax at runtime and it has a debugger that will let you go back in time.
The bottom line is that when you pick a language that is on the cutting edge of cool right now will no longer be cool a few years from now, but it still won't have any libraries and other essentials. Languages too have to cross the chasm, and they all have to go through a period where they're neither new and exciting nor stable.
If you're serious about software, concentrate on writing something that is reliable as hell and easy to maintain and install. Want a challenge? Write your app in such a way that power can be lost at any point in time without losing any user data. Or (for desktop apps) make sure that the UI -never- hangs, even when the hard drive has to spin up. Software is never done, there are always things you can make better, more fault tolerant, faster. It's not as if we've run out of challenges.
Messing around with unstable languages is a lot of fun. It's educational too. But don't build your business around it. Python/Django and Ruby/Rails are only barely stable enough to work with. Thinking that using Haskell, Clean, IO or Lisp will be a net benefit to productivity is foolish.
(Of course there are obvious exceptions, and that Clojure and Scala use the JVM does make the whole library thing less of an issue. But it's still a big deal.)
" lousy IDE support, "
This is valid in a sense, but it is also important to remember that a lot of software was built with emacs and vi or even more ancient editors.
"If you're serious about software, concentrate on writing something that is reliable as hell and easy to maintain and install. "
That is terrible advice, not so much the sentence itself as the "stay away from powerful languages" spin you give it, as in
"Messing around with unstable languages is a lot of fun. It's educational too. But don't build your business around it. "
There are profitable companies using Haskell and OCaml (and Lisp and J and .. )!
You make a decent point then spoil it by stretching it too far, to the point of farce.
One situation in which you should definitely not use advanced languages is when you know you have (or intend to hire) very dumb "programmers" who won't be able to warp their heads around the "exotic" language, which probably doesn't have a "Learn in 21 days" book to go with it.
Many companies doing outsourced software do hire these "middle of the curve" programmers and will do well to stay with "stable" languages. If you have a bunch of bright programmers doing something innovative, it is a completely different situation.
By your logic PG wouldn't have built Viaweb in Lisp, FlightCaster wouldn't be using Clojure and so on.
Taking just one example, Clojure is evolving very fast, which for you would be "unstable". I know at least 4 startups using Clojure, one using Scala and no one's yet complained of "instability" and lack of IDE support destroying their productivity. There are tradeoffs (IDE maturity being one, if you are an I-can't-program-productively-without-my-IDE kind of guy ) with any language selection, but the consequences aren't as dire as you make it out to be.
As I said, this is bad (or rather very one sided, which amounts to the same thing in practice) advice. There is an excellent rationale for building certain types of applications in powerful languages, what PG calls LFSP - languages for smart people.
PG and other people have made this argument more eloquently than I can, so I'll refrain.
"Python/Django and Ruby/Rails are only barely stable enough to work with."
heh heh! Sure, What do you use then? COBOL? Should be "stable" enough for you I guess.
Somebody should tell all the stupid programmers using RoR or Django to run companies that they are being foolish, using "barely stable" software. ;-)
This is valid in a sense, but it is also important to remember that a lot of software was built with emacs and vi or even more ancient editors.
"If you're serious about software, concentrate on writing something that is reliable as hell and easy to maintain and install. "
That is terrible advice, not so much the sentence itself as the "stay away from powerful languages" spin you give it, as in
"Messing around with unstable languages is a lot of fun. It's educational too. But don't build your business around it. "
There are profitable companies using Haskell and OCaml (and Lisp and J and .. )!
You make a decent point then spoil it by stretching it too far, to the point of farce.
One situation in which you should definitely not use advanced languages is when you know you have (or intend to hire) very dumb "programmers" who won't be able to warp their heads around the "exotic" language, which probably doesn't have a "Learn in 21 days" book to go with it.
Many companies doing outsourced software do hire these "middle of the curve" programmers and will do well to stay with "stable" languages. If you have a bunch of bright programmers doing something innovative, it is a completely different situation.
By your logic PG wouldn't have built Viaweb in Lisp, FlightCaster wouldn't be using Clojure and so on.
Taking just one example, Clojure is evolving very fast, which for you would be "unstable". I know at least 4 startups using Clojure, one using Scala and no one's yet complained of "instability" and lack of IDE support destroying their productivity. There are tradeoffs (IDE maturity being one, if you are an I-can't-program-productively-without-my-IDE kind of guy ) with any language selection, but the consequences aren't as dire as you make it out to be.
As I said, this is bad (or rather very one sided, which amounts to the same thing in practice) advice. There is an excellent rationale for building certain types of applications in powerful languages, what PG calls LFSP - languages for smart people.
PG and other people have made this argument more eloquently than I can, so I'll refrain.
"Python/Django and Ruby/Rails are only barely stable enough to work with."
heh heh! Sure, What do you use then? COBOL? Should be "stable" enough for you I guess.
Somebody should tell all the stupid programmers using RoR or Django to run companies that they are being foolish, using "barely stable" software. ;-)
Go easy on the sarcasm and ridicule; it doesn't help you make your case.
PG built Viaweb in Lisp because there was no Ruby, Python or Perl back then. When there are no libraries to chose from, you pick a language that lets you write libraries quickly. Today we boldly go where many have gone before, and that means that we can benefit from technologies others have built. Standing on the shoulders of giants, and all that.
I'm arguing that if you want to run a business you should be pragmatic about the language you pick.
The second half of your post seems to consist of mere hyperbole and strawmen (COBOL? Right). If there is excellent rationale for picking an esoteric language, I'd love to hear it.
PG built Viaweb in Lisp because there was no Ruby, Python or Perl back then. When there are no libraries to chose from, you pick a language that lets you write libraries quickly. Today we boldly go where many have gone before, and that means that we can benefit from technologies others have built. Standing on the shoulders of giants, and all that.
I'm arguing that if you want to run a business you should be pragmatic about the language you pick.
The second half of your post seems to consist of mere hyperbole and strawmen (COBOL? Right). If there is excellent rationale for picking an esoteric language, I'd love to hear it.
"PG built Viaweb in Lisp because there was no Ruby, Python or Perl back then."
First, you were the one suggesting we don't use Ruby or Python, in 2009 in the name of "stability". and now you are saying PG would have used these "unstable" languages in 1995 "if they existed" which brings me to
"because there was no Ruby, Python or Perl back then."
You are wrong.
ViaWeb was started in 1995
Perl was available (and being used to build websites) in 1995. Python was available too. Do your research before making ridiculous claims!
As PG says in one of his essays (link below)
"During the years we worked on Viaweb I read a lot of job descriptions. A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers."
;-)
You go on to say,
"If there is excellent rationale for picking an esoteric language, I'd love to hear it."
Start with the PG essay I quoted above, http://www.paulgraham.com/icad.html
many nice points there, for e.g:
"In fact, choosing a more powerful language probably decreases the size of the team you need, because (a) if you use a more powerful language you probably won't need as many hackers, and (b) hackers who work in more advanced languages are likely to be smarter."
He (and others) have written a lot about this. Again, do your research. You may or may not agree with the rationale he puts forward, but you undermine your own argument when you make up things to strengthen it (like perl not existing in 1995).
First, you were the one suggesting we don't use Ruby or Python, in 2009 in the name of "stability". and now you are saying PG would have used these "unstable" languages in 1995 "if they existed" which brings me to
"because there was no Ruby, Python or Perl back then."
You are wrong.
ViaWeb was started in 1995
Perl was available (and being used to build websites) in 1995. Python was available too. Do your research before making ridiculous claims!
As PG says in one of his essays (link below)
"During the years we worked on Viaweb I read a lot of job descriptions. A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers."
;-)
You go on to say,
"If there is excellent rationale for picking an esoteric language, I'd love to hear it."
Start with the PG essay I quoted above, http://www.paulgraham.com/icad.html
many nice points there, for e.g:
"In fact, choosing a more powerful language probably decreases the size of the team you need, because (a) if you use a more powerful language you probably won't need as many hackers, and (b) hackers who work in more advanced languages are likely to be smarter."
He (and others) have written a lot about this. Again, do your research. You may or may not agree with the rationale he puts forward, but you undermine your own argument when you make up things to strengthen it (like perl not existing in 1995).
"PG built Viaweb in Lisp because there was no Ruby, Python or Perl back then."
Then why did he build Hacker News in Lisp?
Then why did he build Hacker News in Lisp?
As a test app for his programming language, of course. Not because it's the best tool for the job. He essentially built an entire language for this website -- that won't give you a highscore in the productivity hall of fame :)
And yet, even with Python and Ruby well established, he still felt the desire to build his own language. And the language he chose to build was Lisp-like rathar than Python- or Ruby-like.
I'm not sure how true this is. I was into Java in '95 when it had "lousy IDE support, buggy compilers, few libraries, few bindings to existing libraries, and so on". Java fell far short of its potential, and the ambitions Sun had for it, but still, that wasn't a bad call. People who got into Python early on made a similarly good call.
And also, some esoteric languages, like Haskell, the ML family, Erlang and so on have deep roots, they may not be mainstream but they aren't going away anytime soon. And sometimes something funny happens; anyone who has ML experience is going to feel right at home on F# and suddenly the library problem is solved, the IDE problem is solved, the bindings problem is solved...
And also, some esoteric languages, like Haskell, the ML family, Erlang and so on have deep roots, they may not be mainstream but they aren't going away anytime soon. And sometimes something funny happens; anyone who has ML experience is going to feel right at home on F# and suddenly the library problem is solved, the IDE problem is solved, the bindings problem is solved...
> some esoteric languages, like Haskell, the ML family, Erlang and so on have deep roots
None of Haskell, ML or Erlang is an esoteric language.
None of Haskell, ML or Erlang is an esoteric language.
I think you have a fairly high bar for esoteric :).
No. Esoteric languages are a fairly clear category of languages created to test the boundaries of language design.
Esoteric languages are not created for real-world usage (or even for usage at all), examples of such languages are INTERCAL, Thue, Unlambda, Moo, Befunge or Java2K. They can be turing tarpits (languages with extremely low number of commands), funges (multi-dimensional programs), nondeterministic (from a given global state A and a current instruction f, the next state `f A` of the system can't be predicted)…
There's nothing esoteric about a language such as Erlang created very specifically to solve industrial problems, or even about languages originally created for research (ML or Haskell), especially when they've now leaked into practical, real-world programming outside of academia.
Esoteric languages are not created for real-world usage (or even for usage at all), examples of such languages are INTERCAL, Thue, Unlambda, Moo, Befunge or Java2K. They can be turing tarpits (languages with extremely low number of commands), funges (multi-dimensional programs), nondeterministic (from a given global state A and a current instruction f, the next state `f A` of the system can't be predicted)…
There's nothing esoteric about a language such as Erlang created very specifically to solve industrial problems, or even about languages originally created for research (ML or Haskell), especially when they've now leaked into practical, real-world programming outside of academia.
> But don't build your business around it. Python/Django and Ruby/Rails are only barely stable enough to work with.
I agree with your basic premise but,
Python and ruby both have extremely good library support. Hell, python's stated aim is batteries included. Both of them have (al least semi-)mature Jvm implementations. Django has a stated policy of not breaking backward compatibility on point releases.
I agree you need to choose stable languages to work with, but if you are selling consulting services around Java god luck competing with BigCo. If you are building your products with Struts, good luck doing xml-situps.
I agree with your basic premise but,
Python and ruby both have extremely good library support. Hell, python's stated aim is batteries included. Both of them have (al least semi-)mature Jvm implementations. Django has a stated policy of not breaking backward compatibility on point releases.
I agree you need to choose stable languages to work with, but if you are selling consulting services around Java god luck competing with BigCo. If you are building your products with Struts, good luck doing xml-situps.
If you think Python and Ruby have extremely good libraries your standards are pretty low. CPython itself is stable and well documented, but it's frequently breaking backwards compatibility across versions. My production servers can't get anything newer than Python 2.4, and the servers are barely a year old. Python 2.6 libraries almost never work in 2.4, and when I do upgrade to 2.6 I know a lot of my own code is going to break. If I used Perl instead of Python this would be no issue, because Perl _is_ stable and reliable as hell.
In two years time most libraries will move to Python 3.0, and Django is unlikely to patch security issues for Python 2.4 by then. In other words, I either have to spend a week upgrading stuff that already works, or I'll have to use insecure libraries. I don't like those options at all. How can we write solid and stable software if we don't have a stable foundation to build on?
C++ code I've written a dozen years ago still compiles and runs fine. Executables still run when double-clicked. If I scpy a Django directory to a different server I'm __surprised__ if it just works. Doesn't that say enough?
Python exists 20 years now and the spec is still not stable. Any Python library written today won't run on the computers of tomorrow. That's a pretty big price to pay for a print() function.
In two years time most libraries will move to Python 3.0, and Django is unlikely to patch security issues for Python 2.4 by then. In other words, I either have to spend a week upgrading stuff that already works, or I'll have to use insecure libraries. I don't like those options at all. How can we write solid and stable software if we don't have a stable foundation to build on?
C++ code I've written a dozen years ago still compiles and runs fine. Executables still run when double-clicked. If I scpy a Django directory to a different server I'm __surprised__ if it just works. Doesn't that say enough?
Python exists 20 years now and the spec is still not stable. Any Python library written today won't run on the computers of tomorrow. That's a pretty big price to pay for a print() function.
> If you think Python and Ruby have extremely good libraries your standards are pretty low.
.Net, JVM, Perl. Apart from these, which lanngauge has better Library than Python? Python is available on two of them. Ruby one one of them at least. (I dunno if ruby is avaialble on .Net)
> CPython itself is stable and well documented, but it's frequently breaking backwards compatibility across versions.
No. Afaik, Python has never broken backward compatibility in a majot way on point releases, and even minor details are dicussed ad infintum on the mailing list. Py3K was discussed for 8 years, before being released.
> Python 2.6 libraries almost never work in 2.4
Neither do Java's library which use generics or Autoboxing work in Java 1.4. However libaries comaptible with Java 1.4 work in 1.5(or 5.0 if you will), and so do libraries which were written for Python 2.4, do in 2.5 and 2.6. Languages can only guarantee backward compatibility. I am not sure which language you work in that guarantees forward compatibility.
> and Django is unlikely to patch security issues for Python 2.4 by then. In other words, I either have to spend a week upgrading stuff that already works
Django has a stated security policy. All security bugs must be fixed for 2 point releases prior to latest release. 0.96 got official security upgrades till recently. People have backported it to 0.95 and released.
> How can we write solid and stable software if we don't have a stable foundation to build on?
Sorry, but what you are asking here is again forward compatibilty. What will you have, Django never move to 3.0?
> Python exists 20 years now and the spec is still not stable.
Define stable. Python has 1. A reference implemntation. 2. Mutiple VM implemntations, targetting the popular ones. 3. Others, (Stackless, Pypy etc). Unless you use platform specific functions, your code will run on any of these. Fyi, the reference is, http://docs.python.org/reference/introduction.html .
Probabaly you hold a problem with this philosophy, from the reference (While I am trying to be as precise as possible, I chose to use English rather than formal specifications for everything except syntax and lexical analysis. This should make the document more understandable to the average reader, but will leave room for ambiguities.) But this is a debated, and concious decision.
.Net, JVM, Perl. Apart from these, which lanngauge has better Library than Python? Python is available on two of them. Ruby one one of them at least. (I dunno if ruby is avaialble on .Net)
> CPython itself is stable and well documented, but it's frequently breaking backwards compatibility across versions.
No. Afaik, Python has never broken backward compatibility in a majot way on point releases, and even minor details are dicussed ad infintum on the mailing list. Py3K was discussed for 8 years, before being released.
> Python 2.6 libraries almost never work in 2.4
Neither do Java's library which use generics or Autoboxing work in Java 1.4. However libaries comaptible with Java 1.4 work in 1.5(or 5.0 if you will), and so do libraries which were written for Python 2.4, do in 2.5 and 2.6. Languages can only guarantee backward compatibility. I am not sure which language you work in that guarantees forward compatibility.
> and Django is unlikely to patch security issues for Python 2.4 by then. In other words, I either have to spend a week upgrading stuff that already works
Django has a stated security policy. All security bugs must be fixed for 2 point releases prior to latest release. 0.96 got official security upgrades till recently. People have backported it to 0.95 and released.
> How can we write solid and stable software if we don't have a stable foundation to build on?
Sorry, but what you are asking here is again forward compatibilty. What will you have, Django never move to 3.0?
> Python exists 20 years now and the spec is still not stable.
Define stable. Python has 1. A reference implemntation. 2. Mutiple VM implemntations, targetting the popular ones. 3. Others, (Stackless, Pypy etc). Unless you use platform specific functions, your code will run on any of these. Fyi, the reference is, http://docs.python.org/reference/introduction.html .
Probabaly you hold a problem with this philosophy, from the reference (While I am trying to be as precise as possible, I chose to use English rather than formal specifications for everything except syntax and lexical analysis. This should make the document more understandable to the average reader, but will leave room for ambiguities.) But this is a debated, and concious decision.
Aside from those three? C and C++. Those libraries are not "batteries included", but they are plentiful and very mature. I like the "batteries included" part of Python though.
- I don't know if Python on the JVM is stable. Last time I checked Ruby on the JVM and .NET was in its infancy.
- They're not big breaks, and they are, as you say, discussed on mailing lists. The difference is that with a JAR file you can upgrade Java and you _know_ that the JAR will continue to run. With Python the only guarantee you have is that one of your libraries is going to throw an exception at some point after you upgrade. Essentially, you have to keep track of every library you use, and you have to check if it's compatible with the new point release.
- Not forward. Merely backward. Backward compatibility is offered by JAR files. You compile it, and even if the language changes the JAR will stay in place. Because the Java VM is stable you don't have to worry as much about precompiled libraries. I don't think Java is the solution to the world's problems, but at least old JAR files still run on modern JVMs (afaik). You can also design a language grammar in such a way that you leave room for future extensions. That is, to only make previously illegal statements legal. To change the semantics of legal statements (except for the rarest of corner cases) is, I think, a bad (but tempting) idea. You can have forward compatibility if you guarantee that code that uses new features won't compile or even attempt to run on an older interpreter. Essentially, if it runs it works. That is a hard guarantee, and the kind of thing you can build on.
> Define stable? That the language grammar doesn't change. Or more generally, that every version of the interpreter can flawlessly execute code written for version n - 1. Take Python: print used to be a keyword, now it becomes a function. I think it's too late for that kind of change, and it's only a minor blemish in the language anyway. You can't upgrade to Python 3 until every single library on your server has been updated. The number of man-hours this will take is staggering.
When you're actively developing in a language, these changes are only a minor nuisance, and upgrades come with a bunch of goodies. 10 years down the road you just want things to run, and with Python the only way to guarantee that is by deleting aptitude.
- I don't know if Python on the JVM is stable. Last time I checked Ruby on the JVM and .NET was in its infancy.
- They're not big breaks, and they are, as you say, discussed on mailing lists. The difference is that with a JAR file you can upgrade Java and you _know_ that the JAR will continue to run. With Python the only guarantee you have is that one of your libraries is going to throw an exception at some point after you upgrade. Essentially, you have to keep track of every library you use, and you have to check if it's compatible with the new point release.
- Not forward. Merely backward. Backward compatibility is offered by JAR files. You compile it, and even if the language changes the JAR will stay in place. Because the Java VM is stable you don't have to worry as much about precompiled libraries. I don't think Java is the solution to the world's problems, but at least old JAR files still run on modern JVMs (afaik). You can also design a language grammar in such a way that you leave room for future extensions. That is, to only make previously illegal statements legal. To change the semantics of legal statements (except for the rarest of corner cases) is, I think, a bad (but tempting) idea. You can have forward compatibility if you guarantee that code that uses new features won't compile or even attempt to run on an older interpreter. Essentially, if it runs it works. That is a hard guarantee, and the kind of thing you can build on.
> Define stable? That the language grammar doesn't change. Or more generally, that every version of the interpreter can flawlessly execute code written for version n - 1. Take Python: print used to be a keyword, now it becomes a function. I think it's too late for that kind of change, and it's only a minor blemish in the language anyway. You can't upgrade to Python 3 until every single library on your server has been updated. The number of man-hours this will take is staggering.
When you're actively developing in a language, these changes are only a minor nuisance, and upgrades come with a bunch of goodies. 10 years down the road you just want things to run, and with Python the only way to guarantee that is by deleting aptitude.
As was said before you are arguing for forward compatibility as backwards compatibility between point releases is guaranteed.
If you have code that works fine in Python 2.4 upgrading to 2.5, 2.6, 2.7 etc won't break your program. If you write you program in Python 2.6 you have to take special care if you want it to run in 2.4. Until Django decides to bump up the minimum version required, which I believe is at 2.3 now, you have nothing to worry about.
Since Python 3.x is not a point release, compatibility is not guaranteed anymore between 2.x. The 2to3 tool will take care of all the easier but time consuming tasks. Why waste the man hours converting 'print x' to 'print(x)' and 'xrange' to 'range' if there is a free tool to do it for you?
Really you are making a mountain out of a mole-hill. If you are not updating your software/site anymore with new features let it be. Python interpreters can run side by side.
If you have code that works fine in Python 2.4 upgrading to 2.5, 2.6, 2.7 etc won't break your program. If you write you program in Python 2.6 you have to take special care if you want it to run in 2.4. Until Django decides to bump up the minimum version required, which I believe is at 2.3 now, you have nothing to worry about.
Since Python 3.x is not a point release, compatibility is not guaranteed anymore between 2.x. The 2to3 tool will take care of all the easier but time consuming tasks. Why waste the man hours converting 'print x' to 'print(x)' and 'xrange' to 'range' if there is a free tool to do it for you?
Really you are making a mountain out of a mole-hill. If you are not updating your software/site anymore with new features let it be. Python interpreters can run side by side.
I may be making a mountain out of a mole-hill, but I think these little things do matter. Python 2.6 introduced the "with" keyword, as you probably know. That's a breaking change, because it alters the language grammar and changes the meaning of previously legitimate programs. And it's a point release. This changes the "it won't break your program" statement to "this will probably not break your program".
When I see a statement that "backwards compatibility is guaranteed", I generally take that literally. And it's really a binary thing. Either it's guaranteed, or it isn't. And with Python it most definitely isn't.
We clearly look at this from a different perspective. I think it's a big deal, and you don't.
When I see a statement that "backwards compatibility is guaranteed", I generally take that literally. And it's really a binary thing. Either it's guaranteed, or it isn't. And with Python it most definitely isn't.
We clearly look at this from a different perspective. I think it's a big deal, and you don't.
Ruby on the JVM is production ready. Apparently Thoughtworks generally deploy on it. I've got it in production too - there's a few very very minor issues, but basically rock solid.
http://martinfowler.com/articles/rubyAtThoughtWorks.html
http://martinfowler.com/articles/rubyAtThoughtWorks.html
> Take Python: print used to be a keyword, now it becomes a function. I think it's too late for that kind of change, and it's only a minor blemish in the language anyway. You can't upgrade to Python 3 until every single library on your server has been updated.
Stop using Python 3 as an example of "python instability" damn it, it's a change known to be incompatible, it's been in preparation for 5 years, it's not an evolution one's supposed to take lightly and it does not mean the end of the 2.x branch for at least a pair of years.
Before that, here's the track record of Python backwards compatibility: you can run Python 1.6 (2000-09-05) code on Python 2.6. In fact that's exactly what ElementTree does.
Stop using Python 3 as an example of "python instability" damn it, it's a change known to be incompatible, it's been in preparation for 5 years, it's not an evolution one's supposed to take lightly and it does not mean the end of the 2.x branch for at least a pair of years.
Before that, here's the track record of Python backwards compatibility: you can run Python 1.6 (2000-09-05) code on Python 2.6. In fact that's exactly what ElementTree does.
You cannot run all legit Python 1.6 code on Python 2.6 (except perhaps with special flags).
If Python 2.6 would flawlessly execute all Python 1.6 code I would have no complaint.
If Python 2.6 would flawlessly execute all Python 1.6 code I would have no complaint.
"I am not sure which language you work in that guarantees forward compatibility."
Lisp? :-)
Lisp? :-)
Trying to avoid sounding like a fan-boy but your python bashing goes a bit far, imho.
CPython itself is stable and well documented, but it's frequently breaking backwards compatibility across versions.
I think you are over-dramatizing this. The big transition to Python 3.0 is still ahead of us. I'm using python since 2.3 and the path to 2.6 has been much less troublesome here than CPAN or the jar interdependency hell have ever been.
I especially find your claim that Perl is "stable and reliable as hell" amusing. CPAN has always been hit & miss for me and I've seen much greater variance in the quality of 3rd party perl modules than in python land.
If I scpy a Django directory to a different server I'm __surprised__ if it just works. Doesn't that say enough?
I think that says more about your deployment methods than about python or django.
Any Python library written today won't run on the computers of tomorrow. That's a pretty big price to pay for a print() function.
That's simply not true. Nobody stops you from running python 2.4 or older on computers of tomorrow. Just like you don't upgrade JVM versions willy-nilly in production.
Python has it's quirks and problems like any other platform. But the particular issue you're going at here (backwards compatibility) is really far from our biggest concern.
CPython itself is stable and well documented, but it's frequently breaking backwards compatibility across versions.
I think you are over-dramatizing this. The big transition to Python 3.0 is still ahead of us. I'm using python since 2.3 and the path to 2.6 has been much less troublesome here than CPAN or the jar interdependency hell have ever been.
I especially find your claim that Perl is "stable and reliable as hell" amusing. CPAN has always been hit & miss for me and I've seen much greater variance in the quality of 3rd party perl modules than in python land.
If I scpy a Django directory to a different server I'm __surprised__ if it just works. Doesn't that say enough?
I think that says more about your deployment methods than about python or django.
Any Python library written today won't run on the computers of tomorrow. That's a pretty big price to pay for a print() function.
That's simply not true. Nobody stops you from running python 2.4 or older on computers of tomorrow. Just like you don't upgrade JVM versions willy-nilly in production.
Python has it's quirks and problems like any other platform. But the particular issue you're going at here (backwards compatibility) is really far from our biggest concern.
Actually, I like Python. I think it has a lot going for it and I use it on a daily basis.
You say that you shouldn't upgrade Python or the JVM willy-nilly. I say: why not? Why do you find it acceptable that languages break existing functionality?
You say that you shouldn't upgrade Python or the JVM willy-nilly. I say: why not? Why do you find it acceptable that languages break existing functionality?
It's not actually about breaking functionality. Both java and python go through a long deprecation period before removing language features. Most Python 2.4 code will run on 2.6 just fine, a few warnings nonwithstanding. Just like most Jdk1.3 code will run on 1.6, again with a bunch of deprecation warnings.
The bigger problem with willy-nilly upgrades is that the new version is not the version you tested on. It might introduce new bugs, unwillingly. I have seen many more subtile problems with minor version jdk updates (e.g. changes in GC behaviour or outright segfaults) than with any python upgrade so far.
The gist is that when you upgrade your environment then you'll just naturally also update the codebase to match it anyways. Or do you upgrade your jdk1.3 project to jdk1.6 and then just ignore the 20 screens of warnings scrolling down on each build?
You don't. You either just stick with what works (for finished projects) or port it forward (for ongoing projects).
The bigger problem with willy-nilly upgrades is that the new version is not the version you tested on. It might introduce new bugs, unwillingly. I have seen many more subtile problems with minor version jdk updates (e.g. changes in GC behaviour or outright segfaults) than with any python upgrade so far.
The gist is that when you upgrade your environment then you'll just naturally also update the codebase to match it anyways. Or do you upgrade your jdk1.3 project to jdk1.6 and then just ignore the 20 screens of warnings scrolling down on each build?
You don't. You either just stick with what works (for finished projects) or port it forward (for ongoing projects).
The Python community, being relatively small, seems to dig this aggressive way of making changes to libraries and the interpreter itself. It has many advantages and speaking of disdvantages, most of the ones you specify are really non-issues.
I mean, you're not forced to use the newest version of the interpreter. You're not forced to use the newest version of any library. Moreover, you're not forced to use a single specific version of the interpreter on a machine. And with the use of virtualenv or buildout, you won't complain that your application used to work, and it doesn't, because the environment evolved.
And if you're "scpying directories" between servers, relying on whatever version of the interpreter you find, you're doing it wrong.
I mean, you're not forced to use the newest version of the interpreter. You're not forced to use the newest version of any library. Moreover, you're not forced to use a single specific version of the interpreter on a machine. And with the use of virtualenv or buildout, you won't complain that your application used to work, and it doesn't, because the environment evolved.
And if you're "scpying directories" between servers, relying on whatever version of the interpreter you find, you're doing it wrong.
I've been using Clojure to "sketch" solutions for a Java project, then translating the results back into Java when I'm happy with it.
This gives me a REPL I can use to type in expressions referencing my existing code base and immediately see the result. Clojure has macros that make typing in many Java expressions require even fewer parens than Java itself! PG came up with the sketching analogy to describe what its like trying things in an interactive environment, immediately seeing the results, then modifying little by little to eventually get the result you want.
When I switch back to Java, on the other hand, I feel like I'm chiseling my code in granite. I need to have all of the boiler plate just so before I can see any results at all, followed by a compile and run or debug cycle. Test driven development makes this a little better, but just a little.
This gives me a REPL I can use to type in expressions referencing my existing code base and immediately see the result. Clojure has macros that make typing in many Java expressions require even fewer parens than Java itself! PG came up with the sketching analogy to describe what its like trying things in an interactive environment, immediately seeing the results, then modifying little by little to eventually get the result you want.
When I switch back to Java, on the other hand, I feel like I'm chiseling my code in granite. I need to have all of the boiler plate just so before I can see any results at all, followed by a compile and run or debug cycle. Test driven development makes this a little better, but just a little.
@jimbokun
"I've been using Clojure to "sketch" solutions for a Java project," and "When I switch back to Java, on the other hand, I feel like I'm chiseling my code in granite." remind me of this bit from SICP
"Pascal is for building pyramids -- imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms -- imposing, breathtaking, dynamic structures built by squads fitting fluctuating myriads of simpler organisms into place."
It seems that some things never change!
"Pascal is for building pyramids -- imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms -- imposing, breathtaking, dynamic structures built by squads fitting fluctuating myriads of simpler organisms into place."
It seems that some things never change!
Well, clojure is still a lisp, and java and pascal are still an algol.
What library is it that you're missing in Haskell but have in Java? What libraries do you feel are unstable? Have you actually programmed anything in Haskell?
The Java language in its current form is from 2004. The Haskell language in its current form is from 1998. Both originally appeared in 1990. Lisp is much older.
The Java language in its current form is from 2004. The Haskell language in its current form is from 1998. Both originally appeared in 1990. Lisp is much older.
Which shows a potential danger of using more "stable" languages. Maybe the biggest flaw of Common Lisp is that the standard lacks many features necessary for modern development, like networking, threads, and Unicode. I think that the C++ standard lacks a String class (please correct me if I'm wrong).
So sometimes "stable" can degenerate into "frozen solid." Not having new libraries is arguably as bad as not being stable.
So sometimes "stable" can degenerate into "frozen solid." Not having new libraries is arguably as bad as not being stable.
I've found that the language (new or old) doesn't matter as much as the experience and depth of the user when it comes to well designed maintainable code. Learning times may vary, but these users try to do things well in any language.
I am not sure you will be that much less productive if you go from Java to Scala. You know most of the libraries, and so code completion is less of an issue and Scala removes many of the problems that are in Java.
> Esoteric languages are a lot of fun.
No esoteric language was mentioned in TFA.
> But they're not very productive
Esoteric languages aren't "not very productive", they're the most counter-productive langages on the planet. Productivity runs counter to the point of an esoteric language.
> Messing around with unstable languages is a lot of fun. It's educational too. But don't build your business around it. Python/Django and Ruby/Rails are only barely stable enough to work with. Thinking that using Haskell, Clean, IO or Lisp will be a net benefit to productivity is foolish.
Wow. Cocaine is one hell of a drug.
No esoteric language was mentioned in TFA.
> But they're not very productive
Esoteric languages aren't "not very productive", they're the most counter-productive langages on the planet. Productivity runs counter to the point of an esoteric language.
> Messing around with unstable languages is a lot of fun. It's educational too. But don't build your business around it. Python/Django and Ruby/Rails are only barely stable enough to work with. Thinking that using Haskell, Clean, IO or Lisp will be a net benefit to productivity is foolish.
Wow. Cocaine is one hell of a drug.
Now I don't agree with his points exactly either. But you and I know full well what he meant when he said "Esoteric Languages". Arguing with people by intentionally misinterpreting their statements just makes you look stupid and it lowers the tone of the whole discussion.
> Arguing with people by intentionally misinterpreting their statements just makes you look stupid and it lowers the tone of the whole discussion.
Yes, because purposefully using terms which don't apply to the subject just to insult other people or degrade languages you don't like clearly doesn't.
Yes, because purposefully using terms which don't apply to the subject just to insult other people or degrade languages you don't like clearly doesn't.
I never thought the word esoteric would raise any eyebrows. I have no idea how it can be interpreted as an insult. It's meant as the opposite of mainstream; languages you won't find at IBM. I hope you don't work there, otherwise you might feel insulted again!
> I have no idea how it can be interpreted as an insult.
http://esolangs.org/wiki/Esoteric_programming_language
> It's meant as the opposite of mainstream; languages you won't find at IBM.
Then what you're looking for is "non-mainstream". Or maybe "suit-incompatible". And FWIW IBM has a lot of Python stuff in their developerworks site and newsletter. And given Erlang comes from Ericsson, not exactly a small company, it's hardly "suit-incompatible".
http://esolangs.org/wiki/Esoteric_programming_language
> It's meant as the opposite of mainstream; languages you won't find at IBM.
Then what you're looking for is "non-mainstream". Or maybe "suit-incompatible". And FWIW IBM has a lot of Python stuff in their developerworks site and newsletter. And given Erlang comes from Ericsson, not exactly a small company, it's hardly "suit-incompatible".
Ah, I see. That definition doesn't fit the situation though. I was using the dictionary definition, and the original article used the word esoteric in the same context as I did.
Scala is _not_ some esoteric MIT, CMU language to make a point exercise. Its a pragmatic and practical attempt to "fix" Java so it has all the capabilities of Java with the proper foundational coherence which allows for additional, some yet to be defined or added, capabilities. Java has long ago painted itself into a corner. It has reached its evolutionary dead end.
As someone who lead a team which wrote one of the largest retail websites in the earlier days of Java, and as someone who has spent the last year rewriting legacy business logic in Scala, there is no comparison.
Scala wins not because its the new hipster language, it's distinctly superior across the board. You can write better, clearer, far more robust, far more scalable and far more easier to maintain and modify business logic at higher levels of productivity. That and its ability to work with legacy Java code makes it ideal. This is from direct and in-depth experience.
My concern with gizmo's post is its complete lack of claimed experience. No context of based on my experience where ... so we ... and then did a POC comparison with ... and found .... and concluded ...
In fact it appears very much to be a direct quote of from the preamble from the "Enterprise IT Managers Survival Handbook For Those Without Experience Or Knowledge Of Software Development Fundamentals"
Privately I've played with all of them. I love the shear outrageous power and beauty of Scheme (PLTs impl) and Haskell, the base competency of SML, and I've even used them in the enterprise in isolated in very few situations where the situation demanded it.
However, never once did it cross my mind to even "think" to introduce any of them into the enterprise (well a brief fling with Python for our operations group, it was found to be too hard).
Scala deserves to win. It is decidedly superior, however, lots of deservedly good things, in fact most, never see the light of day in IT.
As someone who lead a team which wrote one of the largest retail websites in the earlier days of Java, and as someone who has spent the last year rewriting legacy business logic in Scala, there is no comparison.
Scala wins not because its the new hipster language, it's distinctly superior across the board. You can write better, clearer, far more robust, far more scalable and far more easier to maintain and modify business logic at higher levels of productivity. That and its ability to work with legacy Java code makes it ideal. This is from direct and in-depth experience.
My concern with gizmo's post is its complete lack of claimed experience. No context of based on my experience where ... so we ... and then did a POC comparison with ... and found .... and concluded ...
In fact it appears very much to be a direct quote of from the preamble from the "Enterprise IT Managers Survival Handbook For Those Without Experience Or Knowledge Of Software Development Fundamentals"
Privately I've played with all of them. I love the shear outrageous power and beauty of Scheme (PLTs impl) and Haskell, the base competency of SML, and I've even used them in the enterprise in isolated in very few situations where the situation demanded it.
However, never once did it cross my mind to even "think" to introduce any of them into the enterprise (well a brief fling with Python for our operations group, it was found to be too hard).
Scala deserves to win. It is decidedly superior, however, lots of deservedly good things, in fact most, never see the light of day in IT.
Note that I primarily object to the "let's do a startup with language FOO, because then everybody can see how cool we are and every smart programmer will want to join us because the language is so awesome!" attitude.
It's fine to take a calculated risk (Scala) if the direct benefits are measurable and significant. I'm not claiming that people should dogmatically stick to languages from the 90ies because they're safe. I'm saying that you need a very good reason to use a language with an uncertain future.
Also note that I (deliberately) didn't put Scala in the list of foolishness that contains Clean and IO.
It's fine to take a calculated risk (Scala) if the direct benefits are measurable and significant. I'm not claiming that people should dogmatically stick to languages from the 90ies because they're safe. I'm saying that you need a very good reason to use a language with an uncertain future.
Also note that I (deliberately) didn't put Scala in the list of foolishness that contains Clean and IO.
"Note that I primarily object to the "let's do a startup with language FOO, because then everybody can see how cool we are and every smart programmer will want to join us because the language is so awesome!" attitude."
(a) no one ever diplayed such an attitude on this discussion or put that argument forward. Strawman.
(b) This is what you said.
"Messing around with unstable languages is a lot of fun. It's educational too. But don't build your business around it. Python/Django and Ruby/Rails are only barely stable enough to work with. "
which is different from reacting to the non existent "everybody can see how cool we are if use language foo" argument.
"I also note that I (deliberately) didn't put Scala in the list of foolishness that contains Clean and IO."
But you did say " Thinking that using Haskell, Clean, IO or Lisp will be a net benefit to productivity is foolish."
You never really showed where the "foolishness" is.
Also, from your original list that still leaves Haskell and Lisp as languages that don't "provide a net productivity gain", which is a very strange (and as pointed out by boskone above, unsubstantiated) claim. There are profitable businesses built on both these languages (lisp is a family of languages but still .. ), and very capable programmers being massively productive using both.
You said something stupid with nothing to back it up, got hauled over the coals and are now backtracking trying to make a less objectionable claim.
You then claimed Perl didn't exist in 1995 (!) and that's why PG used CL for ViaWeb (!).
quoting boskone "In fact it appears very much to be a direct quote of from the preamble from the "Enterprise IT Managers Survival Handbook For Those Without Experience Or Knowledge Of Software Development Fundamentals"
Indeed.
(a) no one ever diplayed such an attitude on this discussion or put that argument forward. Strawman.
(b) This is what you said.
"Messing around with unstable languages is a lot of fun. It's educational too. But don't build your business around it. Python/Django and Ruby/Rails are only barely stable enough to work with. "
which is different from reacting to the non existent "everybody can see how cool we are if use language foo" argument.
"I also note that I (deliberately) didn't put Scala in the list of foolishness that contains Clean and IO."
But you did say " Thinking that using Haskell, Clean, IO or Lisp will be a net benefit to productivity is foolish."
You never really showed where the "foolishness" is.
Also, from your original list that still leaves Haskell and Lisp as languages that don't "provide a net productivity gain", which is a very strange (and as pointed out by boskone above, unsubstantiated) claim. There are profitable businesses built on both these languages (lisp is a family of languages but still .. ), and very capable programmers being massively productive using both.
You said something stupid with nothing to back it up, got hauled over the coals and are now backtracking trying to make a less objectionable claim.
You then claimed Perl didn't exist in 1995 (!) and that's why PG used CL for ViaWeb (!).
quoting boskone "In fact it appears very much to be a direct quote of from the preamble from the "Enterprise IT Managers Survival Handbook For Those Without Experience Or Knowledge Of Software Development Fundamentals"
Indeed.
It's only a slight exaggeration. In the OP he states "my heart just said yes, it wasn't' a rational choice but an instinctive emotional one". The original article also states/quotes that picking an esoteric language is a good idea because that way you attract people who learn languages for fun. The "let's use a cool language" attitude is very visible here on HN.
I stand by what I said in (b). That you shouldn't pick a language because it's fun -- this I find almost self-evident. When you want to build a business you need to be more pragmatic and you need to consider other factors. Django and Rails are now probably the most popular frameworks for web 2.0 shops. I claim they are not very stable (and I provide supporting arguments in other posts). So I argue that using Django/Rails is adventurous enough. Barely stable enough obviously doesn't mean that it's unusable or worthless. The success of many Django/Rails projects is evidence of that.
The onus is on those who use non-mainstream languages to provide evidence there is an advantage. I claim there is no advantage, and I point out several downsides. If I claim that using Assembly for web programming is foolish you wouldn't expect me to show you why either.
"But of course there are obvious exceptions" covers the few businesses that have become successful. Here too, the onus is not on me to prove that Lisp did not contribute to their success, the onus is on those who are successful to show that it is Lisp that made it so. The reddit people drank the cool-aid, and it didn't work out for them. A single data point, I know.
I'm not taking back anything I said. I stand by it. I find that some of you are looking for things to disagree with, and you read my statements in the most objectionable way. You're saying you know what I meant better than I did when I wrote it. That's quite presumptuous. To attack my character by implying I'm trying to weasel out of anything is most uncalled for.
My claim that Perl didn't exist when viaweb was started was indeed stupid. Had I known viaweb started in 1995 I would never have said that. I (mis)remembered something pg said some time back, along the lines of "if I had to start viaweb today, I would use Python or Ruby". Maybe pg never said that, I don't know. Either way, I was completely wrong there.
edit: found the reference http://news.ycombinator.com/item?id=36905 (I was wrong)
I stand by what I said in (b). That you shouldn't pick a language because it's fun -- this I find almost self-evident. When you want to build a business you need to be more pragmatic and you need to consider other factors. Django and Rails are now probably the most popular frameworks for web 2.0 shops. I claim they are not very stable (and I provide supporting arguments in other posts). So I argue that using Django/Rails is adventurous enough. Barely stable enough obviously doesn't mean that it's unusable or worthless. The success of many Django/Rails projects is evidence of that.
The onus is on those who use non-mainstream languages to provide evidence there is an advantage. I claim there is no advantage, and I point out several downsides. If I claim that using Assembly for web programming is foolish you wouldn't expect me to show you why either.
"But of course there are obvious exceptions" covers the few businesses that have become successful. Here too, the onus is not on me to prove that Lisp did not contribute to their success, the onus is on those who are successful to show that it is Lisp that made it so. The reddit people drank the cool-aid, and it didn't work out for them. A single data point, I know.
I'm not taking back anything I said. I stand by it. I find that some of you are looking for things to disagree with, and you read my statements in the most objectionable way. You're saying you know what I meant better than I did when I wrote it. That's quite presumptuous. To attack my character by implying I'm trying to weasel out of anything is most uncalled for.
My claim that Perl didn't exist when viaweb was started was indeed stupid. Had I known viaweb started in 1995 I would never have said that. I (mis)remembered something pg said some time back, along the lines of "if I had to start viaweb today, I would use Python or Ruby". Maybe pg never said that, I don't know. Either way, I was completely wrong there.
edit: found the reference http://news.ycombinator.com/item?id=36905 (I was wrong)
"The "let's use a cool language" attitude is very visible here on HN."
Some evidence would be nice. I don't see it at all in the sense you claim i.e "we'll use a cool language because it makes us cool". No one I know on HN ever makes that claim or thinks that way. And yet to you it is "very visible". Links please?
"The reddit people drank the cool-aid, and it didn't work out for them. A single data point, I know"
But you don't accept "single data points" in the other direction do you? ViaWeb, Jane Street, Orbitz, FlightCaster?
"single data point I know" ;-)
"The onus is on those who use non-mainstream languages to provide evidence there is an advantage."
You are the one who makes outrageous claims that there is no productivity gain without ever actually using "esoteric" languages in a business context, so you could have some experience backing t your claim that there is no productivity increase. Your troubles upgrading Python (or whatever, your arguments on this are very vague and unconvincing) are not sufficient. Sorry.
When people who actually do use powerful languages to run their businesses report increased productivity, you refuse to accept it or consider it a possibility.
<Shug> Flip Bit. Move on.
"You're saying you know what I meant better than I did when I wrote it."
I don't know you in person. I have to judge your argument by what you actually write not by what you thought in your innermost heart when you wrote it. In your writing you come across as uninformed wrt your claims, and constantly shifting positions when confronted with counter claims, citations or evidence.
That said, I am done discussing this with you. Your argument has nothing backing it but "I think thus and thus with no experience or data or evidence and I refuse to consider anything contrary to my stated position".
Good Bye, Have a nice day.
Some evidence would be nice. I don't see it at all in the sense you claim i.e "we'll use a cool language because it makes us cool". No one I know on HN ever makes that claim or thinks that way. And yet to you it is "very visible". Links please?
"The reddit people drank the cool-aid, and it didn't work out for them. A single data point, I know"
But you don't accept "single data points" in the other direction do you? ViaWeb, Jane Street, Orbitz, FlightCaster?
"single data point I know" ;-)
"The onus is on those who use non-mainstream languages to provide evidence there is an advantage."
You are the one who makes outrageous claims that there is no productivity gain without ever actually using "esoteric" languages in a business context, so you could have some experience backing t your claim that there is no productivity increase. Your troubles upgrading Python (or whatever, your arguments on this are very vague and unconvincing) are not sufficient. Sorry.
When people who actually do use powerful languages to run their businesses report increased productivity, you refuse to accept it or consider it a possibility.
<Shug> Flip Bit. Move on.
"You're saying you know what I meant better than I did when I wrote it."
I don't know you in person. I have to judge your argument by what you actually write not by what you thought in your innermost heart when you wrote it. In your writing you come across as uninformed wrt your claims, and constantly shifting positions when confronted with counter claims, citations or evidence.
That said, I am done discussing this with you. Your argument has nothing backing it but "I think thus and thus with no experience or data or evidence and I refuse to consider anything contrary to my stated position".
Good Bye, Have a nice day.
Because it's down now, a vague summary from what I saw.
Python and Ruby are now basically "mainstream" languages with little of the all new sparkle they had several years ago - little early adopter aura around them. What languages have that 2004 shine in 2009? Author decides to try Scala for this reason and likes it. Author thinks Scala is the new Python because people are excited by it.
Python and Ruby are now basically "mainstream" languages with little of the all new sparkle they had several years ago - little early adopter aura around them. What languages have that 2004 shine in 2009? Author decides to try Scala for this reason and likes it. Author thinks Scala is the new Python because people are excited by it.
I have to say that, even as someone fascinated with Scala this week, I find the argumentation here a little disingenuous. There are a lot of ways to filter developers and I don't think that the ability to learn a new language sets the bar high enough to actually select for the good ones and potentially means selecting the wrong tool for the job.
There are a large group of people that are effectively programming language hobbyists, frequently learning new programming languages for kicks, and while that set intersects the set of good developers, it is not a subset of it.
There are a large group of people that are effectively programming language hobbyists, frequently learning new programming languages for kicks, and while that set intersects the set of good developers, it is not a subset of it.
The initial hump in hiring is always the shortlist - you might get a hundred (or a thousand!) CVs and you can maybe first-interview 10 and second-interview 2-3. So the priority is always to get down to a manageable list by rejecting candidates who are obviously unsuitable.
So you are correct, but you could probably even trust your HR department armed with a suitable list of esoteric languages keywords (instead of their usual "Java" etc) to build you a pretty good first-interview shortlist, even if you were after Java developers.
So you are correct, but you could probably even trust your HR department armed with a suitable list of esoteric languages keywords (instead of their usual "Java" etc) to build you a pretty good first-interview shortlist, even if you were after Java developers.
The Haskell Paradox, too.
He mentions that. And Erlang, too.
He forgot OCaml ;-)
I am not sure OCaml has gained any traction lately. The only paradox of OCaml is why people use it~
Jane St likes it because of the rock-solid type system, but they've been eyeing Haskell compiled with -Wall for the same reasons.
I think these guys use O'Caml as well: http://skydeck.com/
Site down. Cancel.
Google cache has it though:
http://www.google.com/search?q=cache:http://www.yes-no-cance...
http://www.google.com/search?q=cache:http://www.yes-no-cance...
Cache is not working for me :(
I've developed several large projects in Python (specifically CPython 2.x) for $$ for about 6 years and I am learning scala right now. So I have a somewhat interesting perspective on both.
Although I suppose I could be termed a Pythonista since I "do python" for a living, I consider myself more of a true polyglot... I also use Perl, Ruby, C++, Java, Lisp, C#, whatever language I can get my hands on that fits for the project at hand. I don't subscribe to the Golden Hammer theory.
So far, scala does feel like it has that 5x productivity improvement as compared to using straight Java, on par with what I experienced when I started porting significant portions of the code base of a large application from C++ to CPython (embedding CPython in C++, or vice-versa as needed).
I personally see scala being somewhat in a different category from CPython for 2 main reasons: JVM (stability, maturity) & Java interoperability (vast library resources).
1. The JVM is arguably the most widely used, stable, and mature virtual machine ever developed. Not surprising since Sun and IBM have both invested millions (billions?) in JVM development over the last 15+ years. The latest generation JVMs sport multi-threaded garbage collection, profiler support, remote debugging, remote method invocation, compile-and-reload while debugging, and very advanced JIT. JVM runs in more places than any other VM to date. 'Nuf said. Yes CLR is probably on similar footing nowadays. By comparison Python, Ruby, Perl, scheme, or any other language that has its own home-grown VM is always going to be behind that curve... for example, I was just reading about how most of the Common Lisps (many pre-dating the JVM) are still working on adding multi-threaded garbage collection.
2. The other (main) reason I'm looking at scala is the HUGE advantage of JVM interoperability and the vast libraries available.
From my Python & Java & other language experience, I have learned that:
=> cool-language-features-productivity-multiplier = 5x to 10x productivity improvement, such as what Lisp and most of the dynamic interpreted languages (CPython, Ruby, Perl) claim and pretty much deliver
=> existing-library-productivity-multiplier = 100x or more, since I don't have to re-invent every wheel every time for file format X reader/writer, GUI widget, or other library du-jour. Let's face it, we have to interoperate and communicate with a lot of different gizmos & whatzits nowadays, right?
We all know that we as programmers are vastly more productive when we can get almost any library imaginable (usually open source) to do almost anything we want... GUIs, Charting, FFTs/Numerics, networking, 3D graphics, Neural Nets, , and can even leverage Eclipse environment and toolkits for programming in the large for GUI building, writing rich-client platforms (building entire IDE's), Web server frameworks, web services & SOA development, DSLs & modeling, reporting, DB persistence, and then write our glue logic in scala or other JVM language of choice.
We can even intermix them with other JVM languages in the same project (Groovy, Jython, Jruby, clojure, PNut, etc).
The good news is... if I pick scala, and it doesn't work out... I can always selectively replace out the pieces I don't want to keep one-at-a-time in Java or any other JVM language as time permits. But if it works, I'll just leave it alone. Nobody even needs to know my JAR is written in scala except that they have to put a couple of scala JARs on the classpath. Not so for CPython where the installation & deployment overhead is much steeper in my experience. Not everyone has CPython 2.6 installed on every machine for example, but most everyone has a JVM 1.5 or greater whether they know it or not :)
Wow.