If you want to be able to call python code from perl and vice versa, then consider things like the foreign function interface, rpc of various sorts, corba, swig, and special-purpose tools like perlpy.
Compiling to python to perl bytecode is not necessary to achieve your aims, nor is it *possible* because the runtime features are different.
There are no limitations in the C implementation of the Python 2 runtime environment that are not also in the C implementation of the Perl 5 runtime environment. This is essentially true, which is why the idea of compiling one to run on the other is ridiculous. Thank you for agreeing.
Assuming AMD/ATI follows through with their current promise, there will be both technical documentation available, and an effort to actively cooperate with the "open source" world on driver creation. One presumes they are looking at Linux, but if they have resources in communication of fiddly bits in specs and docs I doubt they will look askance at those creating similar for windows.
The problem here is that you are insisting on thinking of these tools by the wrong names. If you remember that python has a stdin file object and then have to hunt around for it, you've done yourself a disservice. The name of this object is sys.stdin.
Just call things by their full names. They're short, they're unambiguous, and they say what they are.
That was pretty cool the way you absolutely did not answer the question.
Various BASIC implementations had an intermediary representation. It's nothing to crow about, on its own. Sure the Perl implementation is pretty performant. It's a decent piece of work, but it's nothing desirable as a *target platform* for other code tools. It doesn't have some endless list of hardware it magically works on, it's just a C-implemented runtime you compile in different places. Thus, the idea of specially targetting it as a runtime is kinda loopy, when there *are* very widely deployed runtimes which go far beyond the "compile it you fool" level. The Java VM is the foremost among these.
When I worked at Wind River, which in some ways was an arrogant culture, we routed support issues through from any customer with a defect issue, whether or not they were paying the four thousand a year to be allowed to talk to us. Sometimes these issues involved more work than the paid customers issues, with both sides spending many hours delving into and isolating the problem.
A defect in the product is the responsibility of the manufacturer/developer! Improving the product by removing/resolving defects is to everyone's benefit. Any company who doesn't understand this is run by idiots.
What we did *not* typically do for customers without support contracts is go through the whole effort to build a custom version of the product specifically without the one defect they had tripped over. If it was sufficiently severe perhaps the machinery for providing an across-the-board update might be triggered, and they would have access to that, eventually. The necessary research into workarounds would of course be shared with the reporter.
And yeah, a lot of bugs simply got tosssed into the "maybe, someday" pile, like usual. But the back-and-forth with the submitter was essential in getting good defect information.
The apple music devices "ipods" are accessed primarily as mass storage devices, block devices, a filesystem to toss crap on: however you like to phrase it. The rub is that the ipod native runtime expects to find information stored in a special database file. The information contained here includes things like how many times each song has been played, what the ratings are for the various songs, what songs have been loaded onto the ipod, and where they are located.
Essentially the idea is that the ipod-native data and the itunes data remain in sync at all times, providing a "seamless" local and mobile music playing experience. You can put files on an ipod that are not described in the special database, but the ipod firmware program will ignore these files.
It's possible you could make a great game out of your ideas but it would completely fly in the face of the concepts of earning ability which makes you seem more powerful, which is the central tenet upon which wow-like MMOs (correct or incorrect) are based. In short, your game is not WOW.
Taking WOW and adding features as you desire nondisruptively is not really workable. WOW has a very heavy-handed system of calculating interactions based on level which are there to ensure that the levels are *meaningful*. A system where everyone is forced to the same ability would work directly against that. If this kind of equalization were seen as desirable, battlegrounds would have had it long ago instead of cumbersome, and barely working "gear matching" systems.
The psychology of the game is as important as the mechanics.
World PvP sucks? They added instanced PvP. Yes, and Alterac Valley for example is so lopsided that most Horde players simply sit in the cave because the Alliance has the advantage. Which has been addressed in the soon-to-be-released 2.2, in keeping with the grandparent's message.
Honour system is a joke? Scrapped, in exchange for a token system. Token system? Where have you been? You still have to grind honor points, not just tokens. The change essentially pushes it to a progression system as opposed to a peak effort system, as I'm sure you're aware. However for most players the honor requirements are met long before the mark requirements, but the players shoot for honor anyway because they cannot do mathematics. I'm not sure what social factors are necessary to cure this one.
The rest of your comment focuses on things which have not yet been addressed, or which I think cannot be addressed (a level and gear focused MMO *RPG* presenting a real sense of warfare and battlefronts? I claim impossible.) Sure there are aspects of the game which are not great, but the point stands that Blizzard makes a serious effort to improve things as they are identified, an act which seems like it would be hard to follow.
And an aside:
The LFG system is practically useless, at least on my server, where the Horde population is so dead it's nearly impossible to find a group. Recommend changing servers. Really. All these things you're dissatisfied about, especially in-world PVP are vastly smaller problems or working just great on servers with higher populations.
Yes it's stupid they charge 15 bucks to transfer, but if you plan to pay 15 bucks a month to continue to slog it out, you owe it to yourself to move somewhere more fun.
This is still just a statically typed, medium-complexity type system, with procedural style. It's algol wearing a funny hat with a few convenience features.
Sure, it's a slightly better algol wearing a funny hat, but if you want algol, C is the dominant language. If you want a "more pleasant C" then there's the obvious D which has *much* higher compatability. If you want a language that offers true advancements in maintainability and reliability then you should look at a non-algol language which a proven track record.
Hooray for your combination generalization and straw man.
I criticised your typically Catholic views on sex because they are nonsense. You equated the real risk of sex with a ridiculously unacceptable risk, falsely.
Your extrapolation into this being a commentary on all catholic views is a fantasy.
Many of his points are about primordial pascal, which no one has really used during the entire time of its popularity (the 80s, mostly) and of course thereafter. However, the 'improved' pascals do not have a formal specification, which is a sad thing. Most people shoot for "tastes like borland", which I guess is at least fairly static now that they've given up on it.
Some of the typing weirdness remains, although it is better hidden. Some of the cosmetic issues remain.
Really the big problem with Free Pascal generation pascal is it is only better than C in some fairly academic ways, and a lot worse than C in some quite practical ways. There are far better minority language choices to be made for most tasks. Free Pascal is more of a "because it's fun" language that people choose because people used Borland pascal for those purposes historically, not really for any virtues of the language itself.
The key here was in the word "worldwide". Should say, Papua New Guineans benefit from the public works of The United Kingdom of Great Britain and Northern Ireland?
I don't see that the UK public institution has any particular charter to provide them free of charge in this fashion. Moreover there is a long history of BBC-produced works being licensed to rights houses who license them overseas for "performance", aka broadcast. Is there a particular reason that these fees are okay to collect institutionally, but not reasonable to collect from individuals?
There is of course the sticky bit that in a sense the BBC would be profiting from works paid for by the public. If well managed, then the world is simply helping to subsidise the good of the public institution of the UK. If poorly managed, then in effect perhaps the BBC would slowly become a for-profit institution which simply sells to the non-UK, which is not really what (I think) we all want out of the institution.
Systems which require reboots/restarts to update require testing and care to avoid problems on going live. This system which does not require a reboot/restart to update requires testing and care to avoid problems on going live.
The difference is that going live does not require you to become not-live in the process!
What is so hard to grasp here. You are complaining that this impressive technological achievement does not solve problems that it was not intended to solve, and that somehow because the process to validate correctness is not magically fixed, something is made worse.
Nothing is made worse, all the existing tools a quality-oriented software house can apply will work. The improvement is that the eventual update can be made without bringing the system down.
There are numerous *other* benefits to the language in question in terms of reliability, and conciseness which may lead to lower liklihood of problems regardless of this technological improvement. But you have yet to finger any actual problem other than your sense of worry over something you do not seem to understand.
To rephrase your observation: "Hey, I've been programming in imperative languages for decades, and this functional stuff is not familiar!"
That's right, it's not easy for you to understand because you do not have experience with it. That doesn't mean it's somehow intrinsically more difficult to understand.
Slashdot Mirror
If you want to be able to call python code from perl and vice versa, then consider things like the foreign function interface, rpc of various sorts, corba, swig, and special-purpose tools like perlpy.
Compiling to python to perl bytecode is not necessary to achieve your aims, nor is it *possible* because the runtime features are different.
So you are asking J.C.Roberts to cite his sources? He isn't here.
If you were not already aware, let me point out that the post you responded to is pointing out the *absurdity* of the claims, not agreeing with them.
Or that no one has really effectively communicated the risks of password acquisition (if real).
Wow, self-healing minefield. Are we on newspeak yet?
Is this a joke? She or he already did.
Assuming AMD/ATI follows through with their current promise, there will be both technical documentation available, and an effort to actively cooperate with the "open source" world on driver creation. One presumes they are looking at Linux, but if they have resources in communication of fiddly bits in specs and docs I doubt they will look askance at those creating similar for windows.
The problem here is that you are insisting on thinking of these tools by the wrong names. If you remember that python has a stdin file object and then have to hunt around for it, you've done yourself a disservice. The name of this object is sys.stdin.
Just call things by their full names. They're short, they're unambiguous, and they say what they are.
That was pretty cool the way you absolutely did not answer the question.
Various BASIC implementations had an intermediary representation. It's nothing to crow about, on its own. Sure the Perl implementation is pretty performant. It's a decent piece of work, but it's nothing desirable as a *target platform* for other code tools. It doesn't have some endless list of hardware it magically works on, it's just a C-implemented runtime you compile in different places. Thus, the idea of specially targetting it as a runtime is kinda loopy, when there *are* very widely deployed runtimes which go far beyond the "compile it you fool" level. The Java VM is the foremost among these.
When I worked at Wind River, which in some ways was an arrogant culture, we routed support issues through from any customer with a defect issue, whether or not they were paying the four thousand a year to be allowed to talk to us. Sometimes these issues involved more work than the paid customers issues, with both sides spending many hours delving into and isolating the problem.
A defect in the product is the responsibility of the manufacturer/developer! Improving the product by removing/resolving defects is to everyone's benefit. Any company who doesn't understand this is run by idiots.
What we did *not* typically do for customers without support contracts is go through the whole effort to build a custom version of the product specifically without the one defect they had tripped over. If it was sufficiently severe perhaps the machinery for providing an across-the-board update might be triggered, and they would have access to that, eventually. The necessary research into workarounds would of course be shared with the reporter.
And yeah, a lot of bugs simply got tosssed into the "maybe, someday" pile, like usual. But the back-and-forth with the submitter was essential in getting good defect information.
The apple music devices "ipods" are accessed primarily as mass storage devices, block devices, a filesystem to toss crap on: however you like to phrase it. The rub is that the ipod native runtime expects to find information stored in a special database file. The information contained here includes things like how many times each song has been played, what the ratings are for the various songs, what songs have been loaded onto the ipod, and where they are located.
Essentially the idea is that the ipod-native data and the itunes data remain in sync at all times, providing a "seamless" local and mobile music playing experience. You can put files on an ipod that are not described in the special database, but the ipod firmware program will ignore these files.
Congrats on agreeing? ME TOO!
That was a the joke.
That was the joke.
It's possible you could make a great game out of your ideas but it would completely fly in the face of the concepts of earning ability which makes you seem more powerful, which is the central tenet upon which wow-like MMOs (correct or incorrect) are based. In short, your game is not WOW.
Taking WOW and adding features as you desire nondisruptively is not really workable. WOW has a very heavy-handed system of calculating interactions based on level which are there to ensure that the levels are *meaningful*. A system where everyone is forced to the same ability would work directly against that. If this kind of equalization were seen as desirable, battlegrounds would have had it long ago instead of cumbersome, and barely working "gear matching" systems.
The psychology of the game is as important as the mechanics.
Yes, and Alterac Valley for example is so lopsided that most Horde players simply sit in the cave because the Alliance has the advantage. Which has been addressed in the soon-to-be-released 2.2, in keeping with the grandparent's message. Honour system is a joke? Scrapped, in exchange for a token system.
Token system? Where have you been? You still have to grind honor points, not just tokens. The change essentially pushes it to a progression system as opposed to a peak effort system, as I'm sure you're aware. However for most players the honor requirements are met long before the mark requirements, but the players shoot for honor anyway because they cannot do mathematics. I'm not sure what social factors are necessary to cure this one.
The rest of your comment focuses on things which have not yet been addressed, or which I think cannot be addressed (a level and gear focused MMO *RPG* presenting a real sense of warfare and battlefronts? I claim impossible.) Sure there are aspects of the game which are not great, but the point stands that Blizzard makes a serious effort to improve things as they are identified, an act which seems like it would be hard to follow.
And an aside: The LFG system is practically useless, at least on my server, where the Horde population is so dead it's nearly impossible to find a group. Recommend changing servers. Really. All these things you're dissatisfied about, especially in-world PVP are vastly smaller problems or working just great on servers with higher populations.
Yes it's stupid they charge 15 bucks to transfer, but if you plan to pay 15 bucks a month to continue to slog it out, you owe it to yourself to move somewhere more fun.
This is still just a statically typed, medium-complexity type system, with procedural style. It's algol wearing a funny hat with a few convenience features.
Sure, it's a slightly better algol wearing a funny hat, but if you want algol, C is the dominant language. If you want a "more pleasant C" then there's the obvious D which has *much* higher compatability. If you want a language that offers true advancements in maintainability and reliability then you should look at a non-algol language which a proven track record.
Hooray for your combination generalization and straw man.
I criticised your typically Catholic views on sex because they are nonsense. You equated the real risk of sex with a ridiculously unacceptable risk, falsely.
Your extrapolation into this being a commentary on all catholic views is a fantasy.
Exactly. It's a language almost the same as C/C++ with a very small number of improvements over C/C++.
If you're going to ditch the advantages of ubiquity, you could switch to languages with much larger improvements.
Many of his points are about primordial pascal, which no one has really used during the entire time of its popularity (the 80s, mostly) and of course thereafter. However, the 'improved' pascals do not have a formal specification, which is a sad thing. Most people shoot for "tastes like borland", which I guess is at least fairly static now that they've given up on it.
Some of the typing weirdness remains, although it is better hidden. Some of the cosmetic issues remain.
Really the big problem with Free Pascal generation pascal is it is only better than C in some fairly academic ways, and a lot worse than C in some quite practical ways. There are far better minority language choices to be made for most tasks. Free Pascal is more of a "because it's fun" language that people choose because people used Borland pascal for those purposes historically, not really for any virtues of the language itself.
I do not see any overwhelming reason it should not be.
I do not see any overwhelming reason it should be.
Therefore it comes down to practical issues.
Yes.
The key here was in the word "worldwide". Should say, Papua New Guineans benefit from the public works of The United Kingdom of Great Britain and Northern Ireland?
I don't see that the UK public institution has any particular charter to provide them free of charge in this fashion. Moreover there is a long history of BBC-produced works being licensed to rights houses who license them overseas for "performance", aka broadcast. Is there a particular reason that these fees are okay to collect institutionally, but not reasonable to collect from individuals?
There is of course the sticky bit that in a sense the BBC would be profiting from works paid for by the public. If well managed, then the world is simply helping to subsidise the good of the public institution of the UK. If poorly managed, then in effect perhaps the BBC would slowly become a for-profit institution which simply sells to the non-UK, which is not really what (I think) we all want out of the institution.
Again this is irrelevant to the language feature.
Systems which require reboots/restarts to update require testing and care to avoid problems on going live. This system which does not require a reboot/restart to update requires testing and care to avoid problems on going live.
The difference is that going live does not require you to become not-live in the process!
What is so hard to grasp here. You are complaining that this impressive technological achievement does not solve problems that it was not intended to solve, and that somehow because the process to validate correctness is not magically fixed, something is made worse.
Nothing is made worse, all the existing tools a quality-oriented software house can apply will work. The improvement is that the eventual update can be made without bringing the system down.
There are numerous *other* benefits to the language in question in terms of reliability, and conciseness which may lead to lower liklihood of problems regardless of this technological improvement. But you have yet to finger any actual problem other than your sense of worry over something you do not seem to understand.
To rephrase your observation: "Hey, I've been programming in imperative languages for decades, and this functional stuff is not familiar!"
That's right, it's not easy for you to understand because you do not have experience with it. That doesn't mean it's somehow intrinsically more difficult to understand.