I agree that MS has no real interest in making Linux more attractive to users. But maybe they could end up doing that in some small way as a side-effect of what they're really trying to accomplish. In this case, perhaps they are widening the.net ecosystem (for their own selfish purposes) but that may benefit Mac and Linux users in some way.
If they're wildly successful, though, maybe Linux in the form of Android would suffer. But I don't think see how more openness in.net and more competition in the mobile space can be viewed as a bad thing - except in the narrow sense that it may further Microsoft's business interests. To me, the real conspiricay here is that Microsoft want to be "doing well by doing good."
There is ALWAYS a hidden trap in any apparently-friendly action Microsoft takes.
Yes, and there will always be someone who sees a conspiracy in everything they do. Let's assume their real conspiracy is to make money. Is it possible that with new management and changing business conditions (e.g., dominance of Google and Apple in mobile), that their true conspiracy might actually work out for the "net" good?
If not, we need to seriously consider what folks like Redhat are really up to with their so-called support "open source"...
Clearly, my problem is that I'm not nearly as brilliant as folks like you and Tom Christiansen.;-) But at least you're a little nicer about putting down the less brilliant than he is.
But seriously, maybe it's just a matter of taste. It's nice that you find Perl readable but I don't. Likewise, I also don't much care for Hip Hop or Country Music, but I don't claim that people who do have any sort of "problem". Heck, maybe they're just more brilliant than me.
Good troll, dude. OK, I'll bite. What amazes me is that you believe you can infer my entire professional competency from a single sentence. I bow to your greatness...
Since I'm not, in fact, nearly as incompetent as you suggest, I did a couple of things to combat the Perl problem: 1) I wrote a comment at the end of nearly every line of Perl, just as I would do in assembly code, and 2) I switched to Python and returned to writing the density of comments I normally write, or even fewer.
In my own case, I don't claim to be any master of regular expressions, and I never do anything too fancy, but I can use them effectively when needed. In Python, I usually have to pull up the corresponding docs - which is either a bad sign indicating that the design could be better, or maybe it's just inevitable for someone who doesn't use REs "regularly".
I've also learned to use "redemo" which is a very handy little GUI utility that comes with Python that allows you to interactively hone your REs. Whatever one's language of choice may be, redemo or something like it is highly recommended.
The reasons why perl is still (heavily) used is because of several reasons, I think (for good or bad):
1) The only people who can really read the code in an effective fashion are those who wrote it
I first got disillusioned with Perl many years ago when I realized I couldn't even read my own code! Then I found Python - it was the perfect solution: the same important powerful concepts such as dynamic typing and regular expressions, without all the $_!@ noise. There are times when I miss Perl's easy syntax for operations on results of regular expressions, but Python's clunkier way of doing that ultimately is the correct way for Python to do it.
Sorry, I had meant Python 2.7. Anyway, I probably should reconsider Python 3 again at this point. I looked at it when it first came out, and library support definitely was an issued. The Unicode improvements of 3 never were that useful to me because nearly all of my Python work involved small personal utilities that were easy enough without those improvements.
I'm glad to hear that it's getting traction. If library support is better now, that might help a lot. Even though Guido seems to have managed the transition very well, these things still take time.
No, sorry - I actually meant Python 2.7. That said, I haven't had much need for new features in the last few versions of Python 2.x. I think the last big feature that was added that I actually use is "list comprehensions", which goes back a ways.
Ok, in this thread there are already C++, Ruby, and Perl 6 versions of your snippets, so I'll add the Python ones.
Congratulations to you and the others who were able to decode the original Perl snippet. Hopefully, I would have been able to do that the last time I wrote Perl, but that was about 15 years ago.
I actually find Python 2.6.x to be nearly perfect. The fact that it won't be getting any new features, only bug fixes, is actually one of its very best features for me.
In contrast, Python 3 has always seemed to me to be Guido indulging himself in whittling down the "Python warts" list. Although Python 3 is objectively better in many ways, the improvements don't seem compelling enough to me to bother to really learn, and porting code to it - even with the help of the automatic conversion tool - likewise doesn't seem worth the trouble. And I still kindda like "print" as a statement.
I do take some satisfaction, though, in the fact that Python 3 became the sort of technical success that Perl 6 never was, and never will be. To be fair, I think Guido drew some important lessons from the Perl 6 debacle, the most important of which was to make changes around the edges rather than try to totally reinvent the language. See Gall's Law:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
Then again, there was much less need to reinvent Python.
... replacing that part of Perl5 that was ugly at my leisure, or not, and still having things work.
I actually did that about 15 years ago. I switched to Python, then transliterated all of my Perl code into it.
BTW, it was remarkable to me at the time that in every case of transliteration, the resulting Python files were smaller in terms of both number of lines and number of bytes. Then I realized that since the two are semantically similar in so many ways, Python's lack of braces was a big advantage in terms of code compactness. To be fair, though, I never was one to pack as much code into a single line of Perl as possible. Which is, of course, why I prefer Python: it was never designed for that sort of thing.
In the future, the budget proposes that U.S. companies pay a 19 percent tax on all of their foreign earnings as they are earned
I wonder what the legal basis of this would be. Multinational companies that are interested in minimizing their taxes (and let's face it - who isn't?) already are incorporated elsewhere, and their earnings on U.S. operations are already taxed in the US. So, exactly what "U.S. companies" have substantial "foreign earnings"?
For example, if a corporation is incorporated in Switzerland, pays taxes it earns on Swiss operations to Switzerland, pays taxes on its U.S. operations to the U.S., and pays taxes as required by Swiss law on earnings made elsewhere, what else is there for the U.S. to tax?
g) That anything that happens in c) is likely to be irreversible. (Just think how hard it will be to re-freeze the polar ice that currently reflects significant energy from the sun. Has anybody got any idea how to do that?)
It fascinates me that anyone would think that releasing carbon which was sequestered over the course of millions of years back into the atmosphere over the span of just a few hundred would have no effect at all on the climate - especially when said carbon (as CO2) has a known, measurable warming effect.
I once worked on a project that had a handful of developers, where each developer was in charge of one code for one of the software subsystems of the project. We didn't have much of a coding standard there - only about one page - but we ended up with a consensus coding style in the project that everybody could live with. Even so, you could always tell who wrote what by the personality shown around the edges of the coding style of a given module, function, or even over just a few lines.
It seems like using the applicable features of the corporate version control system would be a lot easier - and possibly even better than 95% accurate.
I just realized that the common practice among current dictatorships regarding the Internet seems to be limiting access more than monitoring. We hear about this recently in North Korea and Cuba. It seems that they prefer that people not be able to communicate electronically at all rather than to allow them to communicate but monitor (and presumably go after) people who communicated the wrong thing. I can see the logic of that: it's much cheaper to limit access than it is to monitor what's communicated.
That's in stark contrast to the "Big Brother"-style monitoring that folks have become afraid of post-Snowden. Still, if a country already has a widely available system of electronic communication that The People aren't going to give up, I guess monitoring is the only thing that can be done by the would-be Big Brothers of the world.
I guess I've never known a great - or even good - programmer who didn't find it fun. (Imagine, for example, a concert pianist who didn't find playing the piano to be fun. Unlikely, at best.)
Of course, not ever aspect of a programmer's job is fun, so that's where professionalism comes in. Like many programmers, I don't always enjoy the documentation aspects of it, but that's part of what my employer is paying me for.
(BTW, the title of this thread makes me think fishermen are likely to be better at cod than great developers.)
I agree wholeheartedly. But is good taste born or made? A few years ago, I mentored a new grad who had very good taste in coding from the beginning. It took me a lot longer to develop that. Certainly, experience helps. But I've also met highly experienced people who had poor taste in coding. Like so many things, I guess no amount of experience will make up for a complete lack of talent.
Slashdot Mirror
to Mr. Spock's tricorder in everyone's pocket.
Spock - is that a tricorder in your pocket, or are you just happy to see me? Kirk out.
I agree that MS has no real interest in making Linux more attractive to users. But maybe they could end up doing that in some small way as a side-effect of what they're really trying to accomplish. In this case, perhaps they are widening the .net ecosystem (for their own selfish purposes) but that may benefit Mac and Linux users in some way.
If they're wildly successful, though, maybe Linux in the form of Android would suffer. But I don't think see how more openness in .net and more competition in the mobile space can be viewed as a bad thing - except in the narrow sense that it may further Microsoft's business interests. To me, the real conspiricay here is that Microsoft want to be "doing well by doing good."
There is ALWAYS a hidden trap in any apparently-friendly action Microsoft takes.
Yes, and there will always be someone who sees a conspiracy in everything they do. Let's assume their real conspiracy is to make money. Is it possible that with new management and changing business conditions (e.g., dominance of Google and Apple in mobile), that their true conspiracy might actually work out for the "net" good?
If not, we need to seriously consider what folks like Redhat are really up to with their so-called support "open source"...
Clearly, my problem is that I'm not nearly as brilliant as folks like you and Tom Christiansen. ;-) But at least you're a little nicer about putting down the less brilliant than he is.
But seriously, maybe it's just a matter of taste. It's nice that you find Perl readable but I don't. Likewise, I also don't much care for Hip Hop or Country Music, but I don't claim that people who do have any sort of "problem". Heck, maybe they're just more brilliant than me.
he'll then go in and manually corrects them
(Sorry, couldn't resist.)
Good troll, dude. OK, I'll bite. What amazes me is that you believe you can infer my entire professional competency from a single sentence. I bow to your greatness...
Since I'm not, in fact, nearly as incompetent as you suggest, I did a couple of things to combat the Perl problem: 1) I wrote a comment at the end of nearly every line of Perl, just as I would do in assembly code, and 2) I switched to Python and returned to writing the density of comments I normally write, or even fewer.
In my own case, I don't claim to be any master of regular expressions, and I never do anything too fancy, but I can use them effectively when needed. In Python, I usually have to pull up the corresponding docs - which is either a bad sign indicating that the design could be better, or maybe it's just inevitable for someone who doesn't use REs "regularly".
I've also learned to use "redemo" which is a very handy little GUI utility that comes with Python that allows you to interactively hone your REs. Whatever one's language of choice may be, redemo or something like it is highly recommended.
The reasons why perl is still (heavily) used is because of several reasons, I think (for good or bad):
1) The only people who can really read the code in an effective fashion are those who wrote it
I first got disillusioned with Perl many years ago when I realized I couldn't even read my own code! Then I found Python - it was the perfect solution: the same important powerful concepts such as dynamic typing and regular expressions, without all the $_!@ noise. There are times when I miss Perl's easy syntax for operations on results of regular expressions, but Python's clunkier way of doing that ultimately is the correct way for Python to do it.
Sorry, I had meant Python 2.7. Anyway, I probably should reconsider Python 3 again at this point. I looked at it when it first came out, and library support definitely was an issued. The Unicode improvements of 3 never were that useful to me because nearly all of my Python work involved small personal utilities that were easy enough without those improvements.
I'm glad to hear that it's getting traction. If library support is better now, that might help a lot. Even though Guido seems to have managed the transition very well, these things still take time.
No, sorry - I actually meant Python 2.7. That said, I haven't had much need for new features in the last few versions of Python 2.x. I think the last big feature that was added that I actually use is "list comprehensions", which goes back a ways.
My money's on fusion reactors being commercially viable before Perl 6
Maybe it will be used by Doc in the next "Back to the Future" movie instead of "Mr. Fusion".
Ok, in this thread there are already C++, Ruby, and Perl 6 versions of your snippets, so I'll add the Python ones.
Congratulations to you and the others who were able to decode the original Perl snippet. Hopefully, I would have been able to do that the last time I wrote Perl, but that was about 15 years ago.
std::sort(lines.begin(), lines.end(), [](auto &l, auto &l2) { return l1.name l2.name; });
If I may paraphrase an old saying, "You can write Perl in any language."
Perl was designed by a linguist, not an engineer.
Now you've got me wondering: was Esperanto designed by an engineer, not a linguist?
I actually find Python 2.6.x to be nearly perfect. The fact that it won't be getting any new features, only bug fixes, is actually one of its very best features for me.
In contrast, Python 3 has always seemed to me to be Guido indulging himself in whittling down the "Python warts" list. Although Python 3 is objectively better in many ways, the improvements don't seem compelling enough to me to bother to really learn, and porting code to it - even with the help of the automatic conversion tool - likewise doesn't seem worth the trouble. And I still kindda like "print" as a statement.
I do take some satisfaction, though, in the fact that Python 3 became the sort of technical success that Perl 6 never was, and never will be. To be fair, I think Guido drew some important lessons from the Perl 6 debacle, the most important of which was to make changes around the edges rather than try to totally reinvent the language. See Gall's Law:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
Then again, there was much less need to reinvent Python.
... replacing that part of Perl5 that was ugly at my leisure, or not, and still having things work.
I actually did that about 15 years ago. I switched to Python, then transliterated all of my Perl code into it.
BTW, it was remarkable to me at the time that in every case of transliteration, the resulting Python files were smaller in terms of both number of lines and number of bytes. Then I realized that since the two are semantically similar in so many ways, Python's lack of braces was a big advantage in terms of code compactness. To be fair, though, I never was one to pack as much code into a single line of Perl as possible. Which is, of course, why I prefer Python: it was never designed for that sort of thing.
In the future, the budget proposes that U.S. companies pay a 19 percent tax on all of their foreign earnings as they are earned
I wonder what the legal basis of this would be. Multinational companies that are interested in minimizing their taxes (and let's face it - who isn't?) already are incorporated elsewhere, and their earnings on U.S. operations are already taxed in the US. So, exactly what "U.S. companies" have substantial "foreign earnings"?
For example, if a corporation is incorporated in Switzerland, pays taxes it earns on Swiss operations to Switzerland, pays taxes on its U.S. operations to the U.S., and pays taxes as required by Swiss law on earnings made elsewhere, what else is there for the U.S. to tax?
How do we know it's legit?
Hey, it's The Pirate Bay - what's not to be legit?
Good points. May I add one?
g) That anything that happens in c) is likely to be irreversible. (Just think how hard it will be to re-freeze the polar ice that currently reflects significant energy from the sun. Has anybody got any idea how to do that?)
It fascinates me that anyone would think that releasing carbon which was sequestered over the course of millions of years back into the atmosphere over the span of just a few hundred would have no effect at all on the climate - especially when said carbon (as CO2) has a known, measurable warming effect.
I once worked on a project that had a handful of developers, where each developer was in charge of one code for one of the software subsystems of the project. We didn't have much of a coding standard there - only about one page - but we ended up with a consensus coding style in the project that everybody could live with. Even so, you could always tell who wrote what by the personality shown around the edges of the coding style of a given module, function, or even over just a few lines.
It seems like using the applicable features of the corporate version control system would be a lot easier - and possibly even better than 95% accurate.
I just realized that the common practice among current dictatorships regarding the Internet seems to be limiting access more than monitoring. We hear about this recently in North Korea and Cuba. It seems that they prefer that people not be able to communicate electronically at all rather than to allow them to communicate but monitor (and presumably go after) people who communicated the wrong thing. I can see the logic of that: it's much cheaper to limit access than it is to monitor what's communicated.
That's in stark contrast to the "Big Brother"-style monitoring that folks have become afraid of post-Snowden. Still, if a country already has a widely available system of electronic communication that The People aren't going to give up, I guess monitoring is the only thing that can be done by the would-be Big Brothers of the world.
The situation is clear. We must take care to ban this subversive document [wikipedia.org] now. For the children! For the Feds! For great justice!
I hear that Seth Rogen's already working up story ideas for that.
I guess I've never known a great - or even good - programmer who didn't find it fun. (Imagine, for example, a concert pianist who didn't find playing the piano to be fun. Unlikely, at best.)
Of course, not ever aspect of a programmer's job is fun, so that's where professionalism comes in. Like many programmers, I don't always enjoy the documentation aspects of it, but that's part of what my employer is paying me for.
(BTW, the title of this thread makes me think fishermen are likely to be better at cod than great developers.)
I agree wholeheartedly. But is good taste born or made? A few years ago, I mentored a new grad who had very good taste in coding from the beginning. It took me a lot longer to develop that. Certainly, experience helps. But I've also met highly experienced people who had poor taste in coding. Like so many things, I guess no amount of experience will make up for a complete lack of talent.