I see where you're driving--and to a certain extent, I agree.
Java is probably the best example of the particular kind of evil to which you allude... languages like Python and Ruby don't place as much emphasis on "architecture" and "abstraction", don't insist that OOP is the answer to every problem, don't produce such deep, thin inheritance schemes.
And yes, when your application reaches a certain level of complexity, Python can break down. I guess the point I'll re-emphasize is, I think far too many developers (still) predict a complexity for their applications that's not appropriate and that will never emerge. They base their tool decisions on this perceived complexity, they choose lower-level tools for a project with a limited scope and little performance demands, and the project simply never gets completed.
Many applications _should_ be relatively simple applications, and dynamic languages are excellent tools for these tasks.
Premature optimization was a sin in the days when people were arguing about the efficiency difference of particular assembler instructions, or if it was wiser to use post- or pre-increment. In current days of dynamic languages, on-the-fly typing, dynamic dispatch, remote procedure calls and multi-Ghz processors churning through billions of unnecessary instructions, the mantra should be revisited. If the tool you use sprinkles millions of unnecessary instructions around at random, no amount of profiling will allow you to optimize the whole program. Everything runs slow, and only some particularly obnoxious bottlenecks are found. The end result: a program that is slow as mollasses, even on the fastest hardware. Some 'premature' attempts at making the entire thing efficient could have avoided such a nightmare, but alas, the wrong application of Knuths comment on (for him) contemporary programming allows programmers to get away with sloppy thinking and therefore sloppy coding. Speed matters, if only that with more speed, you can pack more functionality in the program.
I disagree: premature optimization is an even bigger sin today. I didn't mean to imply that you needn't worry because Python can be made as fast (as, say , C), only that Python can often be made fast enough for the task as hand... and often is, even without profiling or extensions in C.
As far as sloppiness is concerned, needless infatuation with speed tends to be the greatest offender, insomuch as the programmer misses—or never accomplishes—the high-level goals and design of an ambitious program by focusing too much on non-issues like performance when the application makes relatively low demands of modern hardware.
"Slow" languages have, in my experience, have no correlation with sloppy thinking. In fact, I'd assert it's just the opposite: most of the best programmers I know work with languages like Python, Ruby, Haskell, Scheme, Dylan, etc. These languages allow those programmers to concentrate on the real problem (the application) rather than the distractions (the hardware).
Between Pyrex and Psyco, there's really very, very few applications that a language like Python isn't appropriate for. Premature optimization is the far more common programmer sin these days than choosing a language that's "too slow."
Except for a few, specific application domains (that only a minority of coders are writing) dynamic languages like python are an excellent choice on today's hardware. And if you need it to be faster, just profile, find the couple of spots that matter, and pull out Pyrex.. or even the C/Python API if it makes you feel manlier.:-)
Plus, with things like PyPy + LLVM, Parrot, and IronPython emerging, things are only going to get better.. don't be the last one on the dynamic boat!
First off, a general comment. A lot of your criticisms in of the "P" in LAMP seem to be based on a fundamental difference between some of the "P"s and J2EE.
Sun might package everything up and sell it in a nice box, but that doesn't mean that "requirement X" cannot necessarily be done with a "P" language. Instead, with the P languages, you're probably looking at combining different tools: different independent projects that were created in response to requirement X, which, believe it or not, a lot of "P" programmer are aware of.
The argument could be made that Sun's approach provides more integration; well, P's approach provides more variety. That may help you choose an optimum solution, and it keeps the competition alive as each project strives to fulfill that requirement the best for that language. Sun's J2EE solution wins simply because it's there, and it's official. Wee.
I'm a python programmer, so this may not necessarily apply to all P languages, though I think generally it does. Now I'll try to provide some specific answers.
If I'm honestly not getting what requirement X really is, I'd love to be educated and learn
something today.
2) Transaction support is new to the M in lamp, and no one uses them in the P part. J2EE has a transaction system (JTA) that will combine all your data access into one big happy transaction, on all your resources that support JTA (includes JDBC).
I have to admit, I don't really know what this is. I googled it, I read sun's website, I read a few FAQs, and still I don't get it. What does it provide transactions for? (Beyond, databases/JDBC, the obvious, which is done at the DB level anyhow [by serious databases.])
3) Session state replication is completely absent from LAMP. A server could catch fire in a good J2EE configuration, and when the user clicks submit, they wouldn't even know, because at least two servers will have the users session id.
I've been using memcached lately for sessions, (which has "P" language apis), and while you can distribute sessions/caches across a network this way, I'll admit there is no redundancy (I don't think), probably because it was only intended to be a caching daemon. It'd be nice to have the redundancy worked in there for session support.
Features completely abscent from LAMP:
Good web-service support (you can fake it, but Zope actually does XML RPC for you)
There are so many modules for this, it's crazy. soapy, ZSI, xmlrpc libs, Pyro, etc. Add "web services" to the long list things that are simpler problems than they're hyped to be.
JMS (Messaging System for asynchronous processing)
Seems like you could roll-your-own in a couple of hours with Twisted code.
Easy scripting of SQL (The Java Standard Taglib is far easier to use than anything I used in PHP or Perl, but Zope probably has everyone beat there)
If you're worried about easy scripting, you can take it a step further to a great ORM like SQLObject as well. The nature of dynamically typed languages makes it easy to do pretty neat tricks using metaclasses and such with projects like SQLObject.
Ok... now about why it takes less upkeep in J2EE land...
1) Specs require backwards compatibility in all new versions. I've had problems with every section of LAMP on this issue, but never on J2EE.
Never had this problem with Python, so I can't comment. I do know that Java/Sun is very good about backwards compat though.
2) A JSP page is only supposed to display information and forms. There is no logic in it. If you have problems with this, I recommend STRUTS. Some people recommend WebWork or Spring. It's a matter of taste, but STRUTS is still the top dog. In PHP, you have to work hard to not mix the two. I used to do action= in the get to simulate this behavior, but it's still not as good, just workable.
Good point, but not really relevant to the discussion: it's not a security issue. Your server is not comprimised by a spammer's exploitation of this MTA behavior.
Anyways, my point is. Cursive is useless. I know no one who actually uses it, in a professional common manner. NOT writing letters, notes. Something that REQUIRES it. Or is BETTERED by it.
As an English major, I'm constantly called on to write 15-20 handwritten pages in midterm and final exams. I find that though I prefer to use print in most places, and though I can write faster using print, I can sustain rapid cursive writing for longer periods of time. Cursive tends to move in smoother motions, and you typically only pick up your hand once per word. Print handwriting, however, rapidly jerks back and forth, and most letters require you to raise and lower the pen multiple times. This motion seems to cause more strain on my hand and wrist.
I'm no expert at penmanship: my handwriting is pitiful in all cases. I can type 90+ wpm, so naturally I would always prefer a keyboard to a pen. But when forced to write at length, cursive is my tool of choice.
Of course, this may say less about the utility of cursive than the stubborn traditions of the academic world!
Why is making the file fit a floppy that important? They are pretty much obsolete at this point.
With a floppy/ftp install, I get only the parts of FreeBSD I explicitly need. What good are ISOs filled with packages I don't use? After I have the OS up, everything else gets added via ports--so the tarballs are fetched over the internet. This means that because of kern.flp and mfsroot.flp, most of the servers I build don't even need a CD-ROM drive. It's really just one more thing to spend money on, suck power, and potential break.
I keep telling people that if they are one of the few who care about performance enough to run a specialized NBIO web server like thttpd or Boa or mathopd, they shouldn't throw away half their performance by running Linux. Use FreeBSD.
Jef-- you recommend this because of kqueues? or...
By the author of qmail. Though it doesn't get at much attention as the author's bigger projects, it is written with the same attention to efficiency, simplicity, and correctness.
Heh. Easy Karma Whoring you say??
Easy Karma Burning is more like it.
Incorrect. At the moment, your post is rated 3.
If slashdot readers are truly biased, why are they modding your post up?
Have you really contributed anything useful or new by whining about the horror of slashdot impartiality? Or have you just contributed to your points?
Hint: your post is modded up because slashdot readers are careful to avoid insensitivity and partiallity. Not because you've really said anything new or useful.
You are correct, but this opinion will be drown in the sea of "No way! M$ sucks!" replies
Is anyone else getting tired of easy karma-whoring by continuing to hammer slashdot on the bias issue?
Yes, the vast majority of slashdot users are linux advocates. But in case you haven't noticed, your wild-eyed call for fairness has been said.
I believe you will find those linux advocates among us have taken a certain sensitivity recently to blind evangelism and unreasonable Microsoft bashing.
Most of the responses here seem to be very even-handed and considerate. They pertain specifically to what has been presented in this particular story, and not the entire body of the documented history of MS-Linux flamewars.
And it's all due to gentle, kind pleas for impartiality from concerned individuals like yourself. Thank you!
In the future, I will be using my moderation points to mark such postings as "troll" and "offtopic"; they are both!
Seriously, you shouldn't be pushing free solutions that are less useful than the windows
or mac equivalents
Be careful using terms like "less useful"... Eudora may be easier to learn, and Eudora may certain have advantages compared to CLI MUAs; but you run serious risk of being trampled by devotee Unixites if you say that any MUA is more useful than mutt.
Do some reading: http://www.mutt.org . (It might take you awhile.) Then I'd be interested in your feature-to-feature comparison to mutt.
Is Eudora easy to learn? Yes. It is useful? Pine and mutt are proven CLI MUAs that are many times more useful than current GUI ones--for those who deem it worthwhile to get the most out of their mailer w/out the cruft.
Slashdot Mirror
I see where you're driving--and to a certain extent, I agree. Java is probably the best example of the particular kind of evil to which you allude... languages like Python and Ruby don't place as much emphasis on "architecture" and "abstraction", don't insist that OOP is the answer to every problem, don't produce such deep, thin inheritance schemes. And yes, when your application reaches a certain level of complexity, Python can break down. I guess the point I'll re-emphasize is, I think far too many developers (still) predict a complexity for their applications that's not appropriate and that will never emerge. They base their tool decisions on this perceived complexity, they choose lower-level tools for a project with a limited scope and little performance demands, and the project simply never gets completed. Many applications _should_ be relatively simple applications, and dynamic languages are excellent tools for these tasks.
Premature optimization was a sin in the days when people were arguing about the efficiency difference of particular assembler instructions, or if it was wiser to use post- or pre-increment. In current days of dynamic languages, on-the-fly typing, dynamic dispatch, remote procedure calls and multi-Ghz processors churning through billions of unnecessary instructions, the mantra should be revisited. If the tool you use sprinkles millions of unnecessary instructions around at random, no amount of profiling will allow you to optimize the whole program. Everything runs slow, and only some particularly obnoxious bottlenecks are found. The end result: a program that is slow as mollasses, even on the fastest hardware. Some 'premature' attempts at making the entire thing efficient could have avoided such a nightmare, but alas, the wrong application of Knuths comment on (for him) contemporary programming allows programmers to get away with sloppy thinking and therefore sloppy coding. Speed matters, if only that with more speed, you can pack more functionality in the program.
I disagree: premature optimization is an even bigger sin today. I didn't mean to imply that you needn't worry because Python can be made as fast (as, say , C), only that Python can often be made fast enough for the task as hand... and often is, even without profiling or extensions in C.
As far as sloppiness is concerned, needless infatuation with speed tends to be the greatest offender, insomuch as the programmer misses—or never accomplishes—the high-level goals and design of an ambitious program by focusing too much on non-issues like performance when the application makes relatively low demands of modern hardware.
"Slow" languages have, in my experience, have no correlation with sloppy thinking. In fact, I'd assert it's just the opposite: most of the best programmers I know work with languages like Python, Ruby, Haskell, Scheme, Dylan, etc. These languages allow those programmers to concentrate on the real problem (the application) rather than the distractions (the hardware).
...and it need not be said.
Between Pyrex and Psyco, there's really very, very few applications that a language like Python isn't appropriate for. Premature optimization is the far more common programmer sin these days than choosing a language that's "too slow." Except for a few, specific application domains (that only a minority of coders are writing) dynamic languages like python are an excellent choice on today's hardware. And if you need it to be faster, just profile, find the couple of spots that matter, and pull out Pyrex.. or even the C/Python API if it makes you feel manlier. :-)
Plus, with things like PyPy + LLVM, Parrot, and IronPython emerging, things are only going to get better.. don't be the last one on the dynamic boat!
How about wxPython? Or, if you prefer, PyQT? Both excellent.
Did anybody else notice version 4.1 (4/1 eg April 1), or was it just too obvious to write about?
Check out the mtimes of the file in the tarball. :-)
Huh. Given your nickname, I'd just assume you'd have a helpful answer.
PROFIT! PROFIT!
This is a good product for a good price; you seem to want to find a company doing charity, not business.
Hell, I want a porsche for a nickel, but that doesn't mean its reasonable (or even possible.)
First off, a general comment. A lot of your criticisms in of the "P" in LAMP seem to be based on a fundamental difference between some of the "P"s and J2EE.
Sun might package everything up and sell it in a nice box, but that doesn't mean that "requirement X" cannot necessarily be done with a "P" language. Instead, with the P languages, you're probably looking at combining different tools: different independent projects that were created in response to requirement X, which, believe it or not, a lot of "P" programmer are aware of.
The argument could be made that Sun's approach provides more integration; well, P's approach provides more variety. That may help you choose an optimum solution, and it keeps the competition alive as each project strives to fulfill that requirement the best for that language. Sun's J2EE solution wins simply because it's there, and it's official. Wee.
I'm a python programmer, so this may not necessarily apply to all P languages, though I think generally it does. Now I'll try to provide some specific answers.
If I'm honestly not getting what requirement X really is, I'd love to be educated and learn something today.
2) Transaction support is new to the M in lamp, and no one uses them in the P part. J2EE has a transaction system (JTA) that will combine all your data access into one big happy transaction, on all your resources that support JTA (includes JDBC).
I have to admit, I don't really know what this is. I googled it, I read sun's website, I read a few FAQs, and still I don't get it. What does it provide transactions for? (Beyond, databases/JDBC, the obvious, which is done at the DB level anyhow [by serious databases.])
3) Session state replication is completely absent from LAMP. A server could catch fire in a good J2EE configuration, and when the user clicks submit, they wouldn't even know, because at least two servers will have the users session id.
I've been using memcached lately for sessions, (which has "P" language apis), and while you can distribute sessions/caches across a network this way, I'll admit there is no redundancy (I don't think), probably because it was only intended to be a caching daemon. It'd be nice to have the redundancy worked in there for session support.
Features completely abscent from LAMP: Good web-service support (you can fake it, but Zope actually does XML RPC for you)
There are so many modules for this, it's crazy. soapy, ZSI, xmlrpc libs, Pyro, etc. Add "web services" to the long list things that are simpler problems than they're hyped to be.
JMS (Messaging System for asynchronous processing)
Seems like you could roll-your-own in a couple of hours with Twisted code.
Easy scripting of SQL (The Java Standard Taglib is far easier to use than anything I used in PHP or Perl, but Zope probably has everyone beat there)
If you're worried about easy scripting, you can take it a step further to a great ORM like SQLObject as well. The nature of dynamically typed languages makes it easy to do pretty neat tricks using metaclasses and such with projects like SQLObject.
Ok... now about why it takes less upkeep in J2EE land... 1) Specs require backwards compatibility in all new versions. I've had problems with every section of LAMP on this issue, but never on J2EE.
Never had this problem with Python, so I can't comment. I do know that Java/Sun is very good about backwards compat though.
2) A JSP page is only supposed to display information and forms. There is no logic in it. If you have problems with this, I recommend STRUTS. Some people recommend WebWork or Spring. It's a matter of taste, but STRUTS is still the top dog. In PHP, you have to work hard to not mix the two. I used to do action= in the get to simulate this behavior, but it's still not as good, just workable.
Twisted/Nevow. If you want that, you got it.
Since it's calling the
Oops.
Look at your sibling!
Good point, but not really relevant to the discussion: it's not a security issue. Your server is not comprimised by a spammer's exploitation of this MTA behavior.
Is any software really at the point where we can install it and forget about it?
Qmail is pretty damn close.
great! i'll give you my commodore 64 for FREE. that will have the best $/MHz ratio possible. i'm sure you'll love it.
I think you reversed that.
See, it would actually be MHz/$, not $/MHz. If you gave it to him for free, it would be
Anyways, my point is. Cursive is useless. I know no one who actually uses it, in a professional common manner. NOT writing letters, notes. Something that REQUIRES it. Or is BETTERED by it.
As an English major, I'm constantly called on to write 15-20 handwritten pages in midterm and final exams. I find that though I prefer to use print in most places, and though I can write faster using print, I can sustain rapid cursive writing for longer periods of time. Cursive tends to move in smoother motions, and you typically only pick up your hand once per word. Print handwriting, however, rapidly jerks back and forth, and most letters require you to raise and lower the pen multiple times. This motion seems to cause more strain on my hand and wrist.
I'm no expert at penmanship: my handwriting is pitiful in all cases. I can type 90+ wpm, so naturally I would always prefer a keyboard to a pen. But when forced to write at length, cursive is my tool of choice.
Of course, this may say less about the utility of cursive than the stubborn traditions of the academic world!
Why is making the file fit a floppy that important? They are pretty much obsolete at this point.
With a floppy/ftp install, I get only the parts of FreeBSD I explicitly need. What good are ISOs filled with packages I don't use? After I have the OS up, everything else gets added via ports--so the tarballs are fetched over the internet. This means that because of kern.flp and mfsroot.flp, most of the servers I build don't even need a CD-ROM drive. It's really just one more thing to spend money on, suck power, and potential break.
I keep telling people that if they are one of the few who care about performance enough to run a specialized NBIO web server like thttpd or Boa or mathopd, they shouldn't throw away half their performance by running Linux. Use FreeBSD.
Jef-- you recommend this because of kqueues? or...
woudl kill for an apple,
Jeez. What would you do for an orange?
djb's clockspeed
By the author of qmail. Though it doesn't get at much attention as the author's bigger projects, it is written with the same attention to efficiency, simplicity, and correctness.
To me, and I suspect most casual listeners, Ten was far and away the best Pearl Jam album.
What a coincidence that Ten was the last album that PJ heavily supported via MTV.
You might want to try <windows-button> m if your keyboard has a windows-button. That's the same feature, "Show Desktop," fast.
Heh. Easy Karma Whoring you say?? Easy Karma Burning is more like it.
Incorrect. At the moment, your post is rated 3.
If slashdot readers are truly biased, why are they modding your post up?
Have you really contributed anything useful or new by whining about the horror of slashdot impartiality? Or have you just contributed to your points?
Hint: your post is modded up because slashdot readers are careful to avoid insensitivity and partiallity. Not because you've really said anything new or useful.
You are correct, but this opinion will be drown in the sea of "No way! M$ sucks!" replies
Is anyone else getting tired of easy karma-whoring by continuing to hammer slashdot on the bias issue?
Yes, the vast majority of slashdot users are linux advocates. But in case you haven't noticed, your wild-eyed call for fairness has been said.
I believe you will find those linux advocates among us have taken a certain sensitivity recently to blind evangelism and unreasonable Microsoft bashing.
Most of the responses here seem to be very even-handed and considerate. They pertain specifically to what has been presented in this particular story, and not the entire body of the documented history of MS-Linux flamewars.
And it's all due to gentle, kind pleas for impartiality from concerned individuals like yourself. Thank you!
In the future, I will be using my moderation points to mark such postings as "troll" and "offtopic"; they are both!
Worms thrive on total volume, not specifically servers.
Umm... Can you think of really a more damaging worm lately than Code Red?
Did it need clients/volume? Or just he 2X% of NT/2K servers out there unpatched?
Seriously, you shouldn't be pushing free solutions that are less useful than the windows or mac equivalents
Be careful using terms like "less useful"... Eudora may be easier to learn, and Eudora may certain have advantages compared to CLI MUAs; but you run serious risk of being trampled by devotee Unixites if you say that any MUA is more useful than mutt.
Do some reading: http://www.mutt.org . (It might take you awhile.) Then I'd be interested in your feature-to-feature comparison to mutt.
Is Eudora easy to learn? Yes. It is useful? Pine and mutt are proven CLI MUAs that are many times more useful than current GUI ones--for those who deem it worthwhile to get the most out of their mailer w/out the cruft.
Ahh. Idealism. Realism. You pretended we didn't know the difference.
We're being honest, and somewhat selfish--but not delusional. Come back and live with us in the real world now.