One idea: accountability + small refundable payments.
Essentially, you need a validated account with payment information to post, you post, you pay (say) $0.05. If your post is confirmed to violate the sites spam policy by a human reviewer employed by the site operator within a certain period of being posted posting, it is deleted and the payment is retained, otherwise, the payment is refunded.
Clearly, you need a payment system where the transaction costs on individual payments is low to make this work.
Yes, because it's so hard to use the 2 click, automated IDE function to generate all those getters and setters.
If the idea is that simple that it takes only two commands to fully specify what you need to do, why should those commands have to be to a separate program, rather than your language implementation? To me, the need for that kind of tooling support is a sign that the language is poorly designed for expressiveness. Essentially, your using a "language" that you read, but using a separate visual language (the IDE UI) to actually write it (or using a mix of that and the native language.)
Its better, all other things being equal, for the language you read to be the one you use to write.
How many awesome libraries are there in Java for things like IOC, data access, web frameworks (MVC and otherwise)? There's piles and piles. Are some of them stinkers? Yes, but there's tons of robust, usable, and EFFICIENT frameworks out there.
Yes, there is plenty of great existing Java code. Which is why having language implementations that can interface with and leverage that code is a good thing. Of course, there are plenty of JVM-based languages that do that quite well -- JRuby, Scala, Groovy, Jython, etc. The existence of lots of useful existing Java code is definitely an argument for leveraging the Java platform, but that generally doesn't require using the Java language.
But to pull older out of print stuff is just removing a revenue stream.
Its removing a product from the market which competes with what Wizards is trying to sell now; since their current books are not just books, but part of a coordinated marketing effort designed to sell linked lines of miniatures and other accessories, they really don't like alternative RPGs that compete with the current D&D line. They can't do much, legally, about the alternatives on the market from other companies (though they do use their licensing program to encourage what would otherwise competitors to instead publish products that will promote sales of Wizards' core books and accessories), but they can do something about their own products that are competing with their flagship product.
Its a lot like Microsoft trying pull the plug on XP, really.
The tag/marking system in combat was asinine and it catered too much to the figure and strategic war-gamers and seriously lacked role-playing support.
The tag/marking system has nothing to do with "figure and strategic wargames", and everything to do with emulating MMORPG combat and roles; its equally (or more) distant from traditional miniatures and strategic wargames as it is from traditional RPGs.
Nonoe of this address the fact that the point buy system in GURPS doesn't really make sense if you understand probability.
Your argument doesn't make sense if you understand the GURPS rules and what they do.
going from a 12 to a 13 is much bigger improvement then going from a 17 to an 18, yet the 17-18 is vastly ore expensive.
Actually, in GURPS, a +1 improvement to a stat or a skill (except for the vary narrow range of quicker advancement in the first few levels of a skill) costs exactly the same, as both attributes at all levels and skills after two levels have flat costs.
Further, an attribute or skill score alone doesn't tell you where you are on the bell-curve in regard to probability of success at tasks that come up in game, since you'd have to know what difficulty level and stat (in the case of skills) or skill (in the case of stats) and other factors would typically apply.
OF course if you enjoy long combats, arguments over which rules to use, listens to some jack-off belly ache how HIS martial art styles should get more pluses(or gun, or tank) along with hardly ever feeling like a star then stick with GURPS, have fun, good luck.
Except for long combats, which IME just isn't true, generally, compared to other RPGs, those problems all seem to be problems with personalities in a gaming group, not game systems.
You are absolutely wrong. The additional current increases the resistive losses on the transmission lines. Hence for a lower power factor, more energy must be generated to deliver a given amount of watts.
Yes, but the power that needs to be generated isn't increased by a factor equal to the reciprocal of the PF, which is what TFA seems to assume. The actual effect is, I believe, to divide transmission losses (not total power generated) by the square of the power factor, such that if transmission losses were 5% with a 1.0 PF, they would be 20% with a 0.5 PF.
IIRC, the overall average transmission losses for utility power are somewhere around 7-8%.
I was looking at the syntax of scala- and it looks like they're trying to do web development in C.
A lot of what they are replacing with Scala is things like their message queueing system, which isn't "web development", except in the extremely loose sense in that it is used in a very large system which happens to have a web-facing interface available.
Why can't people just learn a new syntax?
The one thing Scala is, compared to almost any language you care to name (and certainly C) is "a new syntax".
Seriously speaking, when you cannot have long lived processes due to memory leaks, you're having a language/platform problem. When you only have green threads, you're having a language/platform problem.
The first is an implementation (or "platform") problem, not a language problem, unless the language requires memory leaks, which would be unusual. The second could be either, I suppose (though again, a language is more likely to determine thread semantics, not whether they are implemented as native threads on the underlying platform), but since Ruby as a language has threads, and only in certain implementations are they only green threads, its also, in this case, a platform, not a language problem.
Neither of these problems, particularly, exists with JRuby, which is also the best performing Ruby 1.8.x implementation* overall. Now, JRuby won't run the gems Twitter was using that use native extensions in C, but then neither will Scala (or Erlang, for that matter), obviously.
Enter Scala: Scala achieves a brevity of syntax you see in Groovy and Ruby without sacrificing the static type system (it uses type inference).
While, certainly, Scala code is less verbose than Java, it is noticeably more verbose, in most cases, than Python, Ruby, or Groovy.
Since Groovy and Ruby are dynamically typed, they are inherently slower than Scala.
Groovy, as I understand, supports but does not require static typing.
The nieche Scala fits into is actually a testament that developers want the power and benefits of Ruby's syntax,
Scala's syntax, which is almost completely unlike Ruby's.
A JVM language occupying a similar nieche is Fan, with a growing community and tool support coming right up.
Fan seems to fit much better into Groovy's niche (the almost-Ruby-but-intimately-tied-to-the-JVM niche, such as it is) than Scala's. Scala's real niche, it seems to me, is closer to Java's own niche.
So i take it that this will mean the corporations will have to finally upgrade.
No, because the corporations will be the ones that are buying through the channels through which (unlike the consumer oriented channel) they can continue to pay for XP support if it is less expensive for them than the transition cost to Vista, which many corporations are likely to continue to perceive it to be.
Its quite possible that (assuming that Windows 7 succeeds) many corporations will stay on XP until Windows 7 has proven itself, and then move straight to that.
Hell even Twitter devs says Ruby doesn't have 'true' threads and that they are fake threads.
Twitter devs saying it doesn't make it true. The Ruby language has support for threads. In MRI (1.8.x), they are implemented as green threads. In YARV (1.9.x) and Rubinius (the latter of which is not yet a complete implementation) they are implemented as native threads with something similar to Python's Global Interpreter Lock (GIL) so that only one thread running Ruby code can be running at once (though native extensions that do not need access to the Ruby interpreter internals can release the lock). In JRuby, they are implemented as Java (i.e., native in every, or nearly so, JVM) threads, with no GIL.
They couldn't - they tried, and it wouldn't run their stuff (why exactly this is, I have no idea, but that's what Alex said).
What they said is that it wouldn't run the Ruby gems they use that include native extensions, which is true of JRuby, but even more emphatically true of everything that is not Ruby, since then you can't use any gems whether or not they use native extensions, so certainly isn't, in and of itself, a competitive advantage to Scala.
This means that if they don't preform, they get cut.
Yes, it means if any operation conducted by WotC don't perform as well as an application of equal resources by Hasbro in other areas would be expected to, that operation (in a kind of ideal profit maximization theory, which firms tend to attempt to approximate in practice) gets cut.
If D&D (as a traditional RPG) is already performing near or below that bar, then taking an action which has a low expected direct cost that might, the probability is low,improve it to reach that bar (but is likely to fail) may, assuming everything that appears more likely to succeed which has equal or less cost has already been tried, make sense as a last ditch effort to save the line before shutting it down.
Why do these arrogant companies think they can take back what they've sold without compensation?
Maybe they just figure that the amount they are likely to be held liable for is less than the cost of continuing the existing business model.
Or maybe the contract they had with the electronic resellers is written in a way that it is quite clear that the reseller, which is who sold ongoing access to the consumer, is on the hook, since Wizards didn't provide any assurance to the reseller that justified them making that offer to the consumer.
Considering they have their OGL and SRD information which is free to the public to use I don't understand how this claim came about.
About the same time as the 4e release, they pulled the OGL, because of similar concerns. They can't "get back" the stuff that was already out there (though, IIRC, the initial version of the GSL included a clause intended to get as much of it off the market as they could by dangling participation in the anticipated 4e boom as bait), but they certainly aren't happy that it exists. The 4E SRD is not available under the OGL, only the very restrictive GSL (which essentially replaces the old d20 System Trademark License.)
The sooner they die the sooner their old, useful, materials can be bought up by an wealthy geek and put into the commons.
You assume that Hasbro is going to sell rights to the back catalog and the trademarks; this may be unlikely. If their attempt to make D&D a profitable as a set of subscription-based online servcies works, they may well just keep all the old stuff to keep it off the market, even if traditional D&D dies completely.
Of course, with their (now abandoned) foray into open licensing, they already let a lot of material out that isn't coming back, and people will continue to build on that as long as there is interest in the market.
WotC is such a small part of Hasbro that there is very little that they could do with through WotC that would be shooting themselves in the foot (and shooting WotC in the foot is meaningless, WotC isn't an independent entity.) I suspect, also, that WotC, or at least D&D, has been disappointing to Hasbro since the acquisition, and has never been profitable enough, and I wouldn't be surprised if they are at the point where desperate moves that are perceived as having some (though low) probability of improving the profitability in that area are warranted prior to simply cutting their losses and moving the resources elsewhere or simply not expending them at all anymore in a cost-cutting move. IOW, this may well be a natural part of Hasbro proving to themselves that D&D (except, perhaps, in the online-game form) simply cannot be salvaged as something profitable enough for them.
The really odd part is trying to imagine Scala as a reasonable replacement for Ruby or any other higher level language.
For something Ruby is really ideal for, like, say, the stuff Twitter isn't replacing, its maybe not. For implementing message queues, one of the things Twitter is replacing, Scala isn't exactly a bad choice. (If someone put a gun to my head and told me to implement a message queuing system from scratch where performance, development time, and scalability were major concerns, I'd probably choose Erlang personally, but Scala seems like a not-unreasonable choice -- quicker to develop in than Java or C++, better performance than most dynamic languages, and no obvious barriers in the particular problem domain.)
Listen to your own Ruby rhetoric. Ruby itself doesn't have threading; it's FAUX threads.
Ruby 1.9.x and JRuby both use native threads (well, Java threads for JRuby, but most/all JVMs use native threads), Ruby 1.9.x with a GIL, JRuby without one.
Couldn't the code be written in a way that gcc can compile efficiently then?
It could be, and IIRC there is some consideration being given to incorporating some or all of the MBARI patches in to Ruby 1.8.x in future releases (which will continue even while the main thrust of new Ruby development has moved to 1.9.x); of course, MRI has been completely replaced with the YARV VM for Ruby 1.9.x, making the whole issue moot for the main line of development.
Re:Should have used PHP.
on
Twitter On Scala
·
· Score: 2, Insightful
Or is there any high level 'scripting' language out there that can actually measure up to a decent Lisp implementation?
Since many decent Lisps are high-level dynamic languages (hence, "scripting" languages) clearly so.
If someone threw the necessary money at Ruby, it could have easily the performance of a modern Smalltalk implementation, as Ruby is essentially Smalltalk in diguise.
JRuby 1.1.2, has similar performance, and Ruby 1.9.0 better performance, in the alioth shootout, to GNU Smalltalk or Squeak, and worse performance (though Ruby 1.9 by not as much) than VisualWorks Smalltalk. But JRuby performance (1.2.0 is current) has come a considerable way since 1.1.2 (and Ruby 1.9.1 probably has some improvement from 1.9.0), so I don't think modern Ruby is much off from modern Smalltalk implementations.
Slashdot Mirror
One idea: accountability + small refundable payments.
Essentially, you need a validated account with payment information to post, you post, you pay (say) $0.05. If your post is confirmed to violate the sites spam policy by a human reviewer employed by the site operator within a certain period of being posted posting, it is deleted and the payment is retained, otherwise, the payment is refunded.
Clearly, you need a payment system where the transaction costs on individual payments is low to make this work.
If the idea is that simple that it takes only two commands to fully specify what you need to do, why should those commands have to be to a separate program, rather than your language implementation? To me, the need for that kind of tooling support is a sign that the language is poorly designed for expressiveness. Essentially, your using a "language" that you read, but using a separate visual language (the IDE UI) to actually write it (or using a mix of that and the native language.)
Its better, all other things being equal, for the language you read to be the one you use to write.
Yes, there is plenty of great existing Java code. Which is why having language implementations that can interface with and leverage that code is a good thing. Of course, there are plenty of JVM-based languages that do that quite well -- JRuby, Scala, Groovy, Jython, etc. The existence of lots of useful existing Java code is definitely an argument for leveraging the Java platform, but that generally doesn't require using the Java language.
Its removing a product from the market which competes with what Wizards is trying to sell now; since their current books are not just books, but part of a coordinated marketing effort designed to sell linked lines of miniatures and other accessories, they really don't like alternative RPGs that compete with the current D&D line. They can't do much, legally, about the alternatives on the market from other companies (though they do use their licensing program to encourage what would otherwise competitors to instead publish products that will promote sales of Wizards' core books and accessories), but they can do something about their own products that are competing with their flagship product.
Its a lot like Microsoft trying pull the plug on XP, really.
The tag/marking system has nothing to do with "figure and strategic wargames", and everything to do with emulating MMORPG combat and roles; its equally (or more) distant from traditional miniatures and strategic wargames as it is from traditional RPGs.
Your argument doesn't make sense if you understand the GURPS rules and what they do.
Actually, in GURPS, a +1 improvement to a stat or a skill (except for the vary narrow range of quicker advancement in the first few levels of a skill) costs exactly the same, as both attributes at all levels and skills after two levels have flat costs.
Further, an attribute or skill score alone doesn't tell you where you are on the bell-curve in regard to probability of success at tasks that come up in game, since you'd have to know what difficulty level and stat (in the case of skills) or skill (in the case of stats) and other factors would typically apply.
Except for long combats, which IME just isn't true, generally, compared to other RPGs, those problems all seem to be problems with personalities in a gaming group, not game systems.
Yes, but the power that needs to be generated isn't increased by a factor equal to the reciprocal of the PF, which is what TFA seems to assume. The actual effect is, I believe, to divide transmission losses (not total power generated) by the square of the power factor, such that if transmission losses were 5% with a 1.0 PF, they would be 20% with a 0.5 PF.
IIRC, the overall average transmission losses for utility power are somewhere around 7-8%.
A lot of what they are replacing with Scala is things like their message queueing system, which isn't "web development", except in the extremely loose sense in that it is used in a very large system which happens to have a web-facing interface available.
The one thing Scala is, compared to almost any language you care to name (and certainly C) is "a new syntax".
The first is an implementation (or "platform") problem, not a language problem, unless the language requires memory leaks, which would be unusual. The second could be either, I suppose (though again, a language is more likely to determine thread semantics, not whether they are implemented as native threads on the underlying platform), but since Ruby as a language has threads, and only in certain implementations are they only green threads, its also, in this case, a platform, not a language problem.
Neither of these problems, particularly, exists with JRuby, which is also the best performing Ruby 1.8.x implementation* overall. Now, JRuby won't run the gems Twitter was using that use native extensions in C, but then neither will Scala (or Erlang, for that matter), obviously.
While, certainly, Scala code is less verbose than Java, it is noticeably more verbose, in most cases, than Python, Ruby, or Groovy.
Groovy, as I understand, supports but does not require static typing.
Scala's syntax, which is almost completely unlike Ruby's.
Fan seems to fit much better into Groovy's niche (the almost-Ruby-but-intimately-tied-to-the-JVM niche, such as it is) than Scala's. Scala's real niche, it seems to me, is closer to Java's own niche.
Uh, yeah, the actual support for Java, while non-Python language support had been discussed as a possibility for the future previously, is new.
No, because the corporations will be the ones that are buying through the channels through which (unlike the consumer oriented channel) they can continue to pay for XP support if it is less expensive for them than the transition cost to Vista, which many corporations are likely to continue to perceive it to be.
Its quite possible that (assuming that Windows 7 succeeds) many corporations will stay on XP until Windows 7 has proven itself, and then move straight to that.
The "alternative line" had a name: "Dungeons & Dragons", as distinct from "Advanced Dungeons and Dragons".
Twitter devs saying it doesn't make it true. The Ruby language has support for threads. In MRI (1.8.x), they are implemented as green threads. In YARV (1.9.x) and Rubinius (the latter of which is not yet a complete implementation) they are implemented as native threads with something similar to Python's Global Interpreter Lock (GIL) so that only one thread running Ruby code can be running at once (though native extensions that do not need access to the Ruby interpreter internals can release the lock). In JRuby, they are implemented as Java (i.e., native in every, or nearly so, JVM) threads, with no GIL.
What they said is that it wouldn't run the Ruby gems they use that include native extensions, which is true of JRuby, but even more emphatically true of everything that is not Ruby, since then you can't use any gems whether or not they use native extensions, so certainly isn't, in and of itself, a competitive advantage to Scala.
Yes, I do.
Quite.
Yes, it means if any operation conducted by WotC don't perform as well as an application of equal resources by Hasbro in other areas would be expected to, that operation (in a kind of ideal profit maximization theory, which firms tend to attempt to approximate in practice) gets cut.
If D&D (as a traditional RPG) is already performing near or below that bar, then taking an action which has a low expected direct cost that might, the probability is low,improve it to reach that bar (but is likely to fail) may, assuming everything that appears more likely to succeed which has equal or less cost has already been tried, make sense as a last ditch effort to save the line before shutting it down.
Maybe they just figure that the amount they are likely to be held liable for is less than the cost of continuing the existing business model.
Or maybe the contract they had with the electronic resellers is written in a way that it is quite clear that the reseller, which is who sold ongoing access to the consumer, is on the hook, since Wizards didn't provide any assurance to the reseller that justified them making that offer to the consumer.
About the same time as the 4e release, they pulled the OGL, because of similar concerns. They can't "get back" the stuff that was already out there (though, IIRC, the initial version of the GSL included a clause intended to get as much of it off the market as they could by dangling participation in the anticipated 4e boom as bait), but they certainly aren't happy that it exists. The 4E SRD is not available under the OGL, only the very restrictive GSL (which essentially replaces the old d20 System Trademark License.)
You assume that Hasbro is going to sell rights to the back catalog and the trademarks; this may be unlikely. If their attempt to make D&D a profitable as a set of subscription-based online servcies works, they may well just keep all the old stuff to keep it off the market, even if traditional D&D dies completely.
Of course, with their (now abandoned) foray into open licensing, they already let a lot of material out that isn't coming back, and people will continue to build on that as long as there is interest in the market.
WotC is such a small part of Hasbro that there is very little that they could do with through WotC that would be shooting themselves in the foot (and shooting WotC in the foot is meaningless, WotC isn't an independent entity.) I suspect, also, that WotC, or at least D&D, has been disappointing to Hasbro since the acquisition, and has never been profitable enough, and I wouldn't be surprised if they are at the point where desperate moves that are perceived as having some (though low) probability of improving the profitability in that area are warranted prior to simply cutting their losses and moving the resources elsewhere or simply not expending them at all anymore in a cost-cutting move. IOW, this may well be a natural part of Hasbro proving to themselves that D&D (except, perhaps, in the online-game form) simply cannot be salvaged as something profitable enough for them.
For something Ruby is really ideal for, like, say, the stuff Twitter isn't replacing, its maybe not. For implementing message queues, one of the things Twitter is replacing, Scala isn't exactly a bad choice. (If someone put a gun to my head and told me to implement a message queuing system from scratch where performance, development time, and scalability were major concerns, I'd probably choose Erlang personally, but Scala seems like a not-unreasonable choice -- quicker to develop in than Java or C++, better performance than most dynamic languages, and no obvious barriers in the particular problem domain.)
Funny, no one seems to have told Microsoft, who still seem to think that William H. Gates III is their Chairman.
Ruby 1.9.x and JRuby both use native threads (well, Java threads for JRuby, but most/all JVMs use native threads), Ruby 1.9.x with a GIL, JRuby without one.
It could be, and IIRC there is some consideration being given to incorporating some or all of the MBARI patches in to Ruby 1.8.x in future releases (which will continue even while the main thrust of new Ruby development has moved to 1.9.x); of course, MRI has been completely replaced with the YARV VM for Ruby 1.9.x, making the whole issue moot for the main line of development.
Since many decent Lisps are high-level dynamic languages (hence, "scripting" languages) clearly so.
JRuby 1.1.2, has similar performance, and Ruby 1.9.0 better performance, in the alioth shootout, to GNU Smalltalk or Squeak, and worse performance (though Ruby 1.9 by not as much) than VisualWorks Smalltalk. But JRuby performance (1.2.0 is current) has come a considerable way since 1.1.2 (and Ruby 1.9.1 probably has some improvement from 1.9.0), so I don't think modern Ruby is much off from modern Smalltalk implementations.