I don't actually know of any [serious] Rails applications. Does it power anything meaningful? I mean, I looked at the website, and there's all this hype there and on community sites like/., but where's the substance? "Show me the money."
Not sure what your criteria for "seriousness" is, but, IIRC (and Wikipedia, FWIW, agrees) Yellowpages.com is on RoR.
picture quality is a way overblown feature. just as long as the picture is relatively clean of snow and other noise, extra pixels mean next to nothing to me.
You aren't the whole market.
we're about to move to HDTV in about a year and so what!
Only in that ATSC equipment must receive HD-resolution digital signals (among others). But it doesn't have to display in HD-resolution, and broadcasts can be 480i so long as they are ATSC digital broadcasts.
No. 1080p delivers a full 1080 line frame, non-interlaced, every 1/60th of a second.
No. 1080p delivers a full 1080-line frame, non-interlaced, at some specified refresh rate, which can be 24, 25, or 30 Hz (the broadcast 1080p modes) or 60 (the highest mode supported for BD and HD-DVD playback.)
and if the studios would wake up, it also has the ability to have the disc react to the player's preferred language, making the need for region-specific discs entirely obsolete.
Region-specific disks do not exist to serve consumers best in their native language, they exist to make it possible for studios to sell region-specific distribution rights with some veneer of confidence in the buyer that cheaper content from different distributors in other regions won't be imported to undercut the regional exclusivity.
So the feature you are referring to has nothing to do with the "need", insofar as such a need ever existed, for region-specific disks.
My educated guess is that they include 720p sets in that figure (720p sets are regularly sold with "HDTV" labelling).
Heck, the 1080i/540p CRT I got a few years back was sold with "HDTV" labelling, and while those will benefit from HD broadcast compared to SDTV's 480i, they won't benefit much from HD discs vs 480p DVDs.
Furthermore, If Sony wants to sell more BRD players they need to cut their costs in half and stop trying to bundle their PS3 console with the player.
Sony doesn't bundle PS/3 consoles with most of their BD players, though they do bundle a BD player as part of the PS/3 console. They sell standalone BD players (even entire home theater systems) that you can get cheaper than a PS/3 console.
720p to 1080p TVs, OTOH, are not all that cheap. And SDTVs and 1080i "HD" CRTs that'll do 540p don't benefit from HD players compared to progressive-scan DVD players. For most consumers, there is no compelling reason to upgrade to HDTVs and players if their current equipment is working. (My wife and I recently upgraded from a 1080i CRT to a 1080p LCD and picked up a Blu-Ray player -- a PS/3 -- but we don't have kids and each individually make over the median household income in the country, so are hardly they typical consumer -- and even we wouldn't have done it just for the movies [or just for the game console, either].)
So what's the solution, in the meantime you're going to waste your expensive high def TV watching shitty standard format DVDs?
Many consumers don't have a high-def TV that would benefit from HD over DVD, and many that do have such a TV are probably satisfied with getting their HD content from cable or satellite for now.
The cheapest 720p 32" TV I've seen is $700, the cheapest 1080i is $1000.
You've got to mean 1080p not 1080i -- I just switched from a 32" 1080i CRT that I bought a few years ago to a 32" 1080p, the 1080i was about $600 when I bought it then, and the 1080p was only a hair over $1000 when I bought it earlier this month.
"Read the link given."? I ask for the examples the author gives of a specific point, and you want me to read all his rantings?
The specific point was the central theme of the articles linked to, so, yes, if you want to know the specific arguments he makes for those points, you ought to read the arguments yourself.
Keep in mind this author is the same guy who says, "Maybe there is some aspect of Perl I do not understand that makes it easier than I thought in Perl, and if so I would love to know. I still have to use Perl occasionally and so any advancement of that knowledge is useful, too.:) And actually, even though I still find it much easier to write DSLs in Ruby than in Perl, in writing this post's examples I discovered that writing a DSL in Perl was a lot easier than I thought it was."
So? Again, since I've never endorsed either the thesis of the author's argument nor the argument advanced for it, simply argued that the existence of those posts did not at all illustrate the point about the Ruby community that the poster who linked to them suggested, I don't see why I would need to "keep that in mind", since it is relevant to no point that I have argued for or against. It may be relevant to the point that you are desperately looking for someone to argue with you about but, again, I'm not interested in that point.
I personally have never seen the use of Lisp macros referred to as a DSL.
I've almost never seen a discussion of DSLs that doesn't point to the use of Lisp macros as a key example of their implementation.
As for the tautological nature of my closing statement, I was simply keeping it in the terms I hear repeatedly from the promoters or Ruby.
That you were trying to extend or modify a statement structure you've heard other people use to say something different doesn't change the fact that what you said ended up not saying anything that has any meaning.
Fluff pieces, industry buzz, and the latest slick but narrowly focused toolkit don't mean much compared to programmer productivity in general.
You're right, they don't. So what?
They do nothing to sway people who notice how awkward the author's work in the other language is.
Maybe. So?
I'm sure it's a great language for some, and might be better for someone with no Python, Perl, or Ruby experience to start with than Python or Perl.
Lots of Rubyists did not come to it with no Python or Perl experience, and still find it better for many things. Many without abandoning Python or Perl. Including, for that matter, the author you are trying to get me to defend, who came to it from Perl.
The authors who promote it as better than something else without reasons or with admittedly awkward use of the other languages only help to reinforce happy feelings inside the community.
Actually, I'd think that the authors who admit their limitations when discussing their observations do more to promote useful dialogue that is illuminating for all participants than those that pretend to know everything about the subject and the arguments, especially those who do so without even reading the arguments they are criticizing.
By trying to treat Perl as Ruby and do a straight translation from idiomatic Ruby to non-idiomatic Perl, Cozine does the article and its readers a disservice.
Cosine didn't try to treat Perl as Ruby and do a straight translation from idiomatic Ruby to non-idiomatic Perl. He may have done that in effect, but what he set out to do was to compare the two based on his greater (in his perception) experience of Perl and more recent encounter with Ruby.
Now, it certainly seems that he had a better grasp of the most useful Ruby approach to the matter he was addressing and less so with Perl. But I think it would do a greater disservice to the community if impressions like this weren't discussed and responded to.
Maybe in theory. For instance, there is only one implementation of Perl, there's no formal specification of the Perl language (the language is defined by its standard implementation), and there's absolute 0% hope of someone being ever able to do another bug-a-bug compatible interpreter. The same applies to Ruby, I think.
To a certain extent, though mitigating that seems to be the focus of some effort. JRuby is, as I understand, mostly compatible with some important caveats, and there are other alternative Ruby implementations that are more-or-less compatible. One of the big pushes with 1.9.0 seems to be working toward a clear delineation of what features are necessary to generalized Ruby and what are specific, less-portable features of the principal implementation, with a particular eye to what is practically implementable in, e.g., JVM and CLR (and maybe Parrot) based implementations.
Then, most dynamic languages are forcing the implementors to keep type information at run-time, to do garbage collecting, etc. All that comes at a price. It's simply impossible to get it as fast as a static language like C or Fortran, even if you were to design special hardware for it (like Lisp machines).
Lisp machines were abandoned, IIRC, because they had become slower than Lisp implementations on more conventional hardware of the day, because most of the investment was going into development of conventional processors. But, yeah, while mature dynamic languages (like many Lisps), from what I've heard, can be very fast, there is some inevitable overhead. So if speed given fixed hardware constraints is an overwhelming issue, C may be the only choice. In most real world situations the constraint is money, so if a dynamic language for all or part of a system reduces development and/or maintenance costs, you can afford to throw more hardware at it to address performance issues, provided the implementation can make effective use of the hardware.
Um... so you agree that scalability is a problem but you say it's FUD?
Scalability is a general problem, and one that Ruby's development is seeking to address. But its FUD to say its a particular problem with Ruby without some actual measures or other evidence of particular scaling problems that are actually connected to Ruby. Usually, if people are pressed on these kind of accusations, they point back to the twitter thing which: 1) At the outset was suggested to be a problem with the Rails framework, not Ruby, 2) Twitter developers eventually stated wasn't really a particular problem with either Rails or Ruby.
Re:Netcraft confirms it: you're ignorant
on
Ruby 1.9.0 Released
·
· Score: 1
You are willing to debate Merriam Webster now?
Well, whether or not I am is irrelevant, since the first definition of "persecute" from Merriam-Webster (see their online dictionary), which is the sense relevant to "persecution complex", doesn't require the victim to care what the persecutor thinks.
When you acted as if you expect me to go on a moderation crusade against you becaus of your expressed opinions in this thread, that is exactly a description of your perception that you are (or are about to be) persecuted (that is, harassed or punished in a manner designed to injure, grieve, or afflicted.)
Re:Netcraft confirms it: you're ignorant
on
Ruby 1.9.0 Released
·
· Score: 1
By the way, persecution would be to mean I care about what you think.
Not really.
Sometimes you have to accept that some children don't wish to learn.
If you believed what you were writing, would you really have gone from responding once to each of my posts to responding twice to each of them?
Does that mean that I feel persecuted by the fact that you wish to remain ignorant?
You apparently think that I am obsessed enough with getting you that I am going to stalk you on other threads and mod you down (or, despite having a UID that's 1/3 of mine, you are grossly ignorant of how Slashdot moderation works and think I'm going to mod you down on this thread for the same reason.) You seem to, therefore, feel persecuted by my pointing out that the verifiable facts are not consistent with the claims you've made.
(Of course, why you describe fact-checking your claims and questioning when the evidence contradicts them as wishing to remain ignorant, I don't know. Care to explain?)
On what grounds is the claim made that ruby supports DSLs better than Perl?
Uh, read the links given.
The whole "internal DSL" moniker just sounds like flexible and intuitive syntax.
"Internal" or "Language-powered" DSLs are, indeed, an application of flexible syntax to produce intuitive constructs.
That's a good thing, but does not constitute a DSL as any other definition I've seen describes them.
This article claims to have coined the terminology, and certainly using "Domain Specific Language" to refer to such languages implemented through, e.g., Lisp macro systems which operated in the manner of what Fowler calls an "internal" DSL is not new.
Perhaps it does need terminology, but you might find that with regular expressions, source filters (considered questionable practice, but still), formats, an interesting prototype system, eval, and the above modules that Perl has pretty darn good "external DSL" and "internal DSL" support.
I might, indeed. So?
So do Lisp, Scheme, Haskell, and many other languages.
Not familiar with Haskell, but Lisp/Scheme certainly does, as does REBOL and, yes, many other languages.
Forth is built on your idea of "internal DSLs", BTW.
Its not my idea, but, sure. So?
Data stacks, postfix syntax, and an executable library are the three basics idea of the language.
Yes, they are. So?
Is it a point-by-point comparison or just the author's unqualified opinion? Which points does the author consider, on which of those does Ruby score better than Perl, and why?
If you want answers to those questions, read the links provided. Since I'm not endorsing or recommending the author's position (I don't know much Perl, and don't really have a position in the Ruby v. Perl argument -- I'm only pointing out that what the author did in the links that chromatic provided was make a claim about Ruby v. Perl regarding DSL, not claim that Ruby invented any of the features involved in the discussion) I don't really feel the need to regurgitate everything he writes in detail for you instead of allowing you to read it for yourself if you care. If you are just looking for a Ruby v. Perl argument here, well, sorry to disappoint you.
If you're wanting Perl programmers to concede that Ruby is better based on a simple opinion
I don't really give a flying flip whether Perl programmers concede that Ruby is better, either generally or in terms of DSL support, since I don't even have an opinion on those issues myself.
If I want some variation in languages, there are ones out there that vary much more than Perl, Python, and Ruby.
Probably. So?
Ruby might be worthwhile for its specific blending of them, but so far all I hear is how cool Rails is and how much better of a Perl Ruby is supposed to than Perl 5.
while certainly I've heard both of those, if that's all you've heard, you haven't really been listening to very much. But then again, I'm not trying to sell you on Ruby, so it doesn't really bother me.
Well, we have Catalyst, Mason, CGI::Application, and a hundred other web toolkits.
No doubt you do. So?
Perl 5 is still being developed, and Perl 6 has useful stuff being written in it even though it's not completely finished just yet.
Okay. So?
Perl is much more mature, performs generally better from what I've seen, is much more widely supported, and has a much broader base of publicly available modules.
No doubt. Though having more modules doesn't mean that it has better
Re:Netcraft confirms it: you're ignorant
on
Ruby 1.9.0 Released
·
· Score: 1
And feel free to waste your mod points on me too.
Nice persecution complex you have there. But just as out of touch with reality as the rest of your posts.
Re:Netcraft confirms it: you're ignorant
on
Ruby 1.9.0 Released
·
· Score: 1
Call it what you will. If you honestly wanted to know, you'd research it yourself outside of here.
I did. I checked Netcraft when you said it supported you, and it didn't. I searched for statements by the operators of those websites that you claimed stated their use of PHP was for scalability, and the only one that I could find -- from the creator of Ruby on Rails on rubyonrails.org's weblog -- stated, as an answer to the "why do you use PHP?" question, a different reason that the one you claimed they give in response to that question. I did research outside of Slashdot to verify for your claims, and that research contradicted your claims.
So this does not appear to affect RECHARGABLE Batteries...
Read T(other)FA, which provides specific limits on Lithium-ion batteries (which would presumably include LiPo batteries which are technically "Lithium-ion polymer batteries").
Does this mean I can't bring the external 4-hour battery I bought for my laptop? My laptop's battery lasts ~2 hours, and I bought the external with the sole purpose of USING IT ON THE FREAKING PLANE for the additional four hours it takes to get from East Coast to West Coast...
Please read the first link in TFS. You can probably bring such a battery (a 130 watt-hour external battery of that type for laptops is one of their examples of the "special case" batteries that you can bring up to 2 carry-on), though whether you can use the device it is attached to is less clear ("Whether in checked or carry-on baggage, ensure that devices remain switched off, either by built-in switch/trigger locks, by taping the activation switch in the "off" postion, or by other appropriate measures.")
If they can't handle a fire in the luggage room, isn't that the big WTF they should be trying to fix?
Yes, they should, but even if they did, that's a longer term fix.
Has this ever happened by accident during a flight?
There was one fire on a plane last year where lithium batteries can't be ruled out as a source, so "maybe".
OTOH, "can't be ruled out as a source" isn't anywhere close to "are likely to have been the source".
Surely it's not the first flammable object in luggage that could catch fire.
No, that's why they have fire suppression systems in the luggage compartment. OTOH, fire or explosive hazards that cannot be managed by such systems have been banned when those hazards have been discovered in the past, even before the TSA existed.
As for the reasons behind this (since some apparantly didn't read TFA)- it sounds like there was a cargo hold fire on one plane caused by lithium batteries
Are you one that didn't read TFA? Because there is a big gap between "The National Transportation Safety Board earlier this month said it could not rule out lithium batteries as the source of a cargo plane fire at Philadelphia International Airport last year" and "there was a cargo hold fire on one plane caused by lithium batteries".
From TFA, this ruling only covers NON-rechargable lithium batteries, like the AA/AAA lithium cells sold by Energizer, etc. Also, batteries that are installed in equipment don't count.
There are two different sources linked in the summary: a news report and the government website detailing the restrictions. Your statement seems to be based on the news report, and inconsistent with the detailed breakdown of the rules on the government site.
Again, to stress, this has NOTHING to do with rechargable Lithium-Ion or Lithium-Polymer batteries that are in most laptops, digital cameras, celphones, iPods, portable DVD players, etc...
Please explain, then, why the DOT page linked in TFS says, among other things, "Under the new rules, you can bring batteries with up to 8-gram equivalent lithium content. All lithium ion batteries in cell phones are below 8 gram equivalent lithium content. Nearly all laptop computers also are below this quantity threshold.". Also explain why that page provides a detailed breakdown of what is allowed and what prohibited for Lithium/Ion batteries (using cellphone, laptops, and professional A/V equipment batteries as specific examples of where things fall with regard to the limits) if the limits don't apply to " Lithium-Ion or Lithium-Polymer batteries that are in most laptops, digital cameras, celphones, iPods, portable DVD players, etc..."
Read the article - it clearly states that installed batteries are exempt. Therefore, your cellphones, cameras, iPods and laptops aren't affected.
The government page at the first link in TFS clearly does not exempt installed batteries. It clearly states Lithium/Metal batteries with over 2g lithium whether "spare" or "installed" in either checked or carry-on baggage are prohibited , that Lithium/Metal batteries with up to 2g lithium content each or Lithium/Ion batteries with up to 8g lithium content each are permitted in checked baggage when installed and in carryons installed or spare, and that up to 2 Li/Ion batteries with 8-25g are allowed installed in devices in either carryon or checked baggage, or spare in carry-on baggage.
It also indicates that all devices with lithium batteries installed, in either carry-on or checked baggage, must be ensured to remain off either with switch/trigger locks, with the activation switch taped off, or with some other "appropriate measure".
Re:Netcraft confirms it: you're ignorant
on
Ruby 1.9.0 Released
·
· Score: 1
I provided plenty.
You provided: (1) a demonstrably false claim about what Netcraft said about the sites, and (2) a claim that, to the extent it is verifiable at all, is also false about statements by the site operators.
If they shut off php.ini, and you don't wish to do your own legwork outside of this tiny little forum, then you don't truly wish to know now do you.
Whether or not they use PHP is mostly peripheral (that Netcraft doesn't show it shows that you were wrong in claiming that it did, but even if they did, that alone doesn't prove anything that matters: no one disputes that people in the Ruby community don't, for the most part, use Ruby exclusively.)
You claim that they use PHP for scalability. You claim that that's what they themselves say. You claimed (though you seem now to back off from it) that their use of PHP can be confirmed through Netcraft.
In point of fact, only one of them can be confirmed through Netcraft to use PHP, and the explanation they offer is not as you have falsely claimed that they do so for scalability, but that they use it because PHP is a good tool for putting small amounts of dynamic content on a largely-static page, which is what they use it for.
You only wish to argue.
No, I wish to know if your claim that they say they use PHP for scalability has any basis. Certainly the research I've done shows that it seems not to for Rubyonrails.org. And you've provided no reason it does for any of the others. The issue isn't whether or not they use PHP (though, of course, if they don't, they clearly don't use it for scalability), it is whether they say that they use it for scalability. So far you've provided no evidence of this claim, despite saying that they've "said it repeatedly" and that it is a "widely known fact".
It seems to me more that it is a rumor you've heard, for which you are aware of no actual substantiation, and that when you are pressed on it, you have nothing to back it up.
If you had read my posts with any degree of caution whatsoever, you would have noticed that I was very careful to suggest that only a small portion of the entire Ruby community exhibits this behavior.
Even so, the examples you've posted are all the same one person, and none of them exhibit anything even remotely resembling the behavior you have described. None of them involve even so much as an implicit suggestion that Ruby invented any of the practices or features described. They simply argue that Ruby supports a technique (or two techniques, if you consider internal and external DSLs distinct approaches) with considerable history (the author specifically credits Lisp) better than Perl.
As stated, in the php.ini, you can turn 'show_php' off.
You stated specifically that one could verify that those sites were running PHP with Netcraft. Checking Netcraft shows that you are wrong for all but one of the three. You stated specifically that the reason those sites gave for using PHP was scalability. The one site that uses PHP (rubyonrails.org), in fact, gives an explanation that has nothing to do with scalability.
You can state that I am wrong all you want
Yes, I can. And I'll be right, because you are, demonstrably, wrong.
but the cookies used to show (and in some cases still do), with a TINY amount of legwork, you will find that they still DO run PHP and if you ask them directly, they will state as much.
I'm not inclined to gather your evidence for you, especially given that your last claimed evidence that they used PHP -- that Netcraft showed it -- was false. But even if they did use PHP, you've presented know evidence that they do so for scalability. You've claimed that that's the explanation they give, but for the one site that verifiably does use PHP, that's false, as the explanation rubyonrails.org gives for using PHP is not scalability. If you've got evidence that the others use PHP for scalability, feel free to present it.
I'm constantly amazed at the state of denial in the RUBY community when even the maintainers state that they use other languages
No one is denying that many in the Ruby community, including (perhaps especially) the maintainers/developers of the Ruby language (who have to, at least, use C) use languages other than Ruby.
What is being questioned is your claim that specific web sites use a particular alternative language (PHP) for a particular reason (scalability), a claim for which you have presented no convincing evidence, and for which your claimed sources -- both regarding the use of PHP and the reason -- have shown things other than what you have claimed.
Seriously, if you want to remain ignorant, it's up to you. I'm not here to convince you of what even the maintainers of the language have stated repeatedly.
You have yet to provide any reason to believe that the "maintainers of the language" (which, incidentally, aren't represented by 43things or rubyonrails.org -- 43things is a social networking site, Ruby on Rails is a framework, both make use the Ruby language [among others--RoR includes JavaScript components, too]) have said any such thing, whereas the operators of rubyonrails.org (who you've also claimed have said the same thing about PHP for scalability) have given a different explanation of their use of PHP.
Slashdot Mirror
Not sure what your criteria for "seriousness" is, but, IIRC (and Wikipedia, FWIW, agrees) Yellowpages.com is on RoR.
You aren't the whole market.
Only in that ATSC equipment must receive HD-resolution digital signals (among others). But it doesn't have to display in HD-resolution, and broadcasts can be 480i so long as they are ATSC digital broadcasts.
No. 1080p delivers a full 1080-line frame, non-interlaced, at some specified refresh rate, which can be 24, 25, or 30 Hz (the broadcast 1080p modes) or 60 (the highest mode supported for BD and HD-DVD playback.)
Region-specific disks do not exist to serve consumers best in their native language, they exist to make it possible for studios to sell region-specific distribution rights with some veneer of confidence in the buyer that cheaper content from different distributors in other regions won't be imported to undercut the regional exclusivity.
So the feature you are referring to has nothing to do with the "need", insofar as such a need ever existed, for region-specific disks.
Heck, the 1080i/540p CRT I got a few years back was sold with "HDTV" labelling, and while those will benefit from HD broadcast compared to SDTV's 480i, they won't benefit much from HD discs vs 480p DVDs.
Sony doesn't bundle PS/3 consoles with most of their BD players, though they do bundle a BD player as part of the PS/3 console. They sell standalone BD players (even entire home theater systems) that you can get cheaper than a PS/3 console.
720p to 1080p TVs, OTOH, are not all that cheap. And SDTVs and 1080i "HD" CRTs that'll do 540p don't benefit from HD players compared to progressive-scan DVD players. For most consumers, there is no compelling reason to upgrade to HDTVs and players if their current equipment is working. (My wife and I recently upgraded from a 1080i CRT to a 1080p LCD and picked up a Blu-Ray player -- a PS/3 -- but we don't have kids and each individually make over the median household income in the country, so are hardly they typical consumer -- and even we wouldn't have done it just for the movies [or just for the game console, either].)
Many consumers don't have a high-def TV that would benefit from HD over DVD, and many that do have such a TV are probably satisfied with getting their HD content from cable or satellite for now.
You've got to mean 1080p not 1080i -- I just switched from a 32" 1080i CRT that I bought a few years ago to a 32" 1080p, the 1080i was about $600 when I bought it then, and the 1080p was only a hair over $1000 when I bought it earlier this month.
The specific point was the central theme of the articles linked to, so, yes, if you want to know the specific arguments he makes for those points, you ought to read the arguments yourself.
So? Again, since I've never endorsed either the thesis of the author's argument nor the argument advanced for it, simply argued that the existence of those posts did not at all illustrate the point about the Ruby community that the poster who linked to them suggested, I don't see why I would need to "keep that in mind", since it is relevant to no point that I have argued for or against. It may be relevant to the point that you are desperately looking for someone to argue with you about but, again, I'm not interested in that point.
I've almost never seen a discussion of DSLs that doesn't point to the use of Lisp macros as a key example of their implementation.
That you were trying to extend or modify a statement structure you've heard other people use to say something different doesn't change the fact that what you said ended up not saying anything that has any meaning.
You're right, they don't. So what?
Maybe. So?
Lots of Rubyists did not come to it with no Python or Perl experience, and still find it better for many things. Many without abandoning Python or Perl. Including, for that matter, the author you are trying to get me to defend, who came to it from Perl.
Actually, I'd think that the authors who admit their limitations when discussing their observations do more to promote useful dialogue that is illuminating for all participants than those that pretend to know everything about the subject and the arguments, especially those who do so without even reading the arguments they are criticizing.
Cosine didn't try to treat Perl as Ruby and do a straight translation from idiomatic Ruby to non-idiomatic Perl. He may have done that in effect, but what he set out to do was to compare the two based on his greater (in his perception) experience of Perl and more recent encounter with Ruby.
Now, it certainly seems that he had a better grasp of the most useful Ruby approach to the matter he was addressing and less so with Perl. But I think it would do a greater disservice to the community if impressions like this weren't discussed and responded to.
To a certain extent, though mitigating that seems to be the focus of some effort. JRuby is, as I understand, mostly compatible with some important caveats, and there are other alternative Ruby implementations that are more-or-less compatible. One of the big pushes with 1.9.0 seems to be working toward a clear delineation of what features are necessary to generalized Ruby and what are specific, less-portable features of the principal implementation, with a particular eye to what is practically implementable in, e.g., JVM and CLR (and maybe Parrot) based implementations.
Lisp machines were abandoned, IIRC, because they had become slower than Lisp implementations on more conventional hardware of the day, because most of the investment was going into development of conventional processors. But, yeah, while mature dynamic languages (like many Lisps), from what I've heard, can be very fast, there is some inevitable overhead. So if speed given fixed hardware constraints is an overwhelming issue, C may be the only choice. In most real world situations the constraint is money, so if a dynamic language for all or part of a system reduces development and/or maintenance costs, you can afford to throw more hardware at it to address performance issues, provided the implementation can make effective use of the hardware.
Scalability is a general problem, and one that Ruby's development is seeking to address. But its FUD to say its a particular problem with Ruby without some actual measures or other evidence of particular scaling problems that are actually connected to Ruby. Usually, if people are pressed on these kind of accusations, they point back to the twitter thing which:
1) At the outset was suggested to be a problem with the Rails framework, not Ruby,
2) Twitter developers eventually stated wasn't really a particular problem with either Rails or Ruby.
Well, whether or not I am is irrelevant, since the first definition of "persecute" from Merriam-Webster (see their online dictionary), which is the sense relevant to "persecution complex", doesn't require the victim to care what the persecutor thinks.
When you acted as if you expect me to go on a moderation crusade against you becaus of your expressed opinions in this thread, that is exactly a description of your perception that you are (or are about to be) persecuted (that is, harassed or punished in a manner designed to injure, grieve, or afflicted.)
Not really.
If you believed what you were writing, would you really have gone from responding once to each of my posts to responding twice to each of them?
You apparently think that I am obsessed enough with getting you that I am going to stalk you on other threads and mod you down (or, despite having a UID that's 1/3 of mine, you are grossly ignorant of how Slashdot moderation works and think I'm going to mod you down on this thread for the same reason.) You seem to, therefore, feel persecuted by my pointing out that the verifiable facts are not consistent with the claims you've made.
(Of course, why you describe fact-checking your claims and questioning when the evidence contradicts them as wishing to remain ignorant, I don't know. Care to explain?)
Uh, read the links given.
"Internal" or "Language-powered" DSLs are, indeed, an application of flexible syntax to produce intuitive constructs.
This article claims to have coined the terminology, and certainly using "Domain Specific Language" to refer to such languages implemented through, e.g., Lisp macro systems which operated in the manner of what Fowler calls an "internal" DSL is not new.
I might, indeed. So?
Not familiar with Haskell, but Lisp/Scheme certainly does, as does REBOL and, yes, many other languages.
Its not my idea, but, sure. So?
Yes, they are. So?
If you want answers to those questions, read the links provided. Since I'm not endorsing or recommending the author's position (I don't know much Perl, and don't really have a position in the Ruby v. Perl argument -- I'm only pointing out that what the author did in the links that chromatic provided was make a claim about Ruby v. Perl regarding DSL, not claim that Ruby invented any of the features involved in the discussion) I don't really feel the need to regurgitate everything he writes in detail for you instead of allowing you to read it for yourself if you care. If you are just looking for a Ruby v. Perl argument here, well, sorry to disappoint you.
I don't really give a flying flip whether Perl programmers concede that Ruby is better, either generally or in terms of DSL support, since I don't even have an opinion on those issues myself.
Probably. So?
while certainly I've heard both of those, if that's all you've heard, you haven't really been listening to very much. But then again, I'm not trying to sell you on Ruby, so it doesn't really bother me.
No doubt you do. So?
Okay. So?
No doubt. Though having more modules doesn't mean that it has better
Nice persecution complex you have there. But just as out of touch with reality as the rest of your posts.
I did. I checked Netcraft when you said it supported you, and it didn't. I searched for statements by the operators of those websites that you claimed stated their use of PHP was for scalability, and the only one that I could find -- from the creator of Ruby on Rails on rubyonrails.org's weblog -- stated, as an answer to the "why do you use PHP?" question, a different reason that the one you claimed they give in response to that question. I did research outside of Slashdot to verify for your claims, and that research contradicted your claims.
Read T(other)FA, which provides specific limits on Lithium-ion batteries (which would presumably include LiPo batteries which are technically "Lithium-ion polymer batteries").
Please read the first link in TFS. You can probably bring such a battery (a 130 watt-hour external battery of that type for laptops is one of their examples of the "special case" batteries that you can bring up to 2 carry-on), though whether you can use the device it is attached to is less clear ("Whether in checked or carry-on baggage, ensure that devices remain switched off, either by built-in switch/trigger locks, by taping the activation switch in the "off" postion, or by other appropriate measures.")
Yes, they should, but even if they did, that's a longer term fix.
There was one fire on a plane last year where lithium batteries can't be ruled out as a source, so "maybe".
OTOH, "can't be ruled out as a source" isn't anywhere close to "are likely to have been the source".
No, that's why they have fire suppression systems in the luggage compartment. OTOH, fire or explosive hazards that cannot be managed by such systems have been banned when those hazards have been discovered in the past, even before the TSA existed.
Are you one that didn't read TFA? Because there is a big gap between "The National Transportation Safety Board earlier this month said it could not rule out lithium batteries as the source of a cargo plane fire at Philadelphia International Airport last year" and "there was a cargo hold fire on one plane caused by lithium batteries".
There are two different sources linked in the summary: a news report and the government website detailing the restrictions. Your statement seems to be based on the news report, and inconsistent with the detailed breakdown of the rules on the government site.
Please explain, then, why the DOT page linked in TFS says, among other things, "Under the new rules, you can bring batteries with up to 8-gram equivalent lithium content. All lithium ion batteries in cell phones are below 8 gram equivalent lithium content. Nearly all laptop computers also are below this quantity threshold.". Also explain why that page provides a detailed breakdown of what is allowed and what prohibited for Lithium/Ion batteries (using cellphone, laptops, and professional A/V equipment batteries as specific examples of where things fall with regard to the limits) if the limits don't apply to " Lithium-Ion or Lithium-Polymer batteries that are in most laptops, digital cameras, celphones, iPods, portable DVD players, etc..."
The government page at the first link in TFS clearly does not exempt installed batteries. It clearly states Lithium/Metal batteries with over 2g lithium whether "spare" or "installed" in either checked or carry-on baggage are prohibited , that Lithium/Metal batteries with up to 2g lithium content each or Lithium/Ion batteries with up to 8g lithium content each are permitted in checked baggage when installed and in carryons installed or spare, and that up to 2 Li/Ion batteries with 8-25g are allowed installed in devices in either carryon or checked baggage, or spare in carry-on baggage.
It also indicates that all devices with lithium batteries installed, in either carry-on or checked baggage, must be ensured to remain off either with switch/trigger locks, with the activation switch taped off, or with some other "appropriate measure".
You provided: (1) a demonstrably false claim about what Netcraft said about the sites, and (2) a claim that, to the extent it is verifiable at all, is also false about statements by the site operators.
Whether or not they use PHP is mostly peripheral (that Netcraft doesn't show it shows that you were wrong in claiming that it did, but even if they did, that alone doesn't prove anything that matters: no one disputes that people in the Ruby community don't, for the most part, use Ruby exclusively.)
You claim that they use PHP for scalability. You claim that that's what they themselves say. You claimed (though you seem now to back off from it) that their use of PHP can be confirmed through Netcraft.
In point of fact, only one of them can be confirmed through Netcraft to use PHP, and the explanation they offer is not as you have falsely claimed that they do so for scalability, but that they use it because PHP is a good tool for putting small amounts of dynamic content on a largely-static page, which is what they use it for.
No, I wish to know if your claim that they say they use PHP for scalability has any basis. Certainly the research I've done shows that it seems not to for Rubyonrails.org. And you've provided no reason it does for any of the others. The issue isn't whether or not they use PHP (though, of course, if they don't, they clearly don't use it for scalability), it is whether they say that they use it for scalability. So far you've provided no evidence of this claim, despite saying that they've "said it repeatedly" and that it is a "widely known fact".
It seems to me more that it is a rumor you've heard, for which you are aware of no actual substantiation, and that when you are pressed on it, you have nothing to back it up.
Even so, the examples you've posted are all the same one person, and none of them exhibit anything even remotely resembling the behavior you have described. None of them involve even so much as an implicit suggestion that Ruby invented any of the practices or features described. They simply argue that Ruby supports a technique (or two techniques, if you consider internal and external DSLs distinct approaches) with considerable history (the author specifically credits Lisp) better than Perl.
You stated specifically that one could verify that those sites were running PHP with Netcraft. Checking Netcraft shows that you are wrong for all but one of the three. You stated specifically that the reason those sites gave for using PHP was scalability. The one site that uses PHP (rubyonrails.org), in fact, gives an explanation that has nothing to do with scalability.
Yes, I can. And I'll be right, because you are, demonstrably, wrong.
I'm not inclined to gather your evidence for you, especially given that your last claimed evidence that they used PHP -- that Netcraft showed it -- was false. But even if they did use PHP, you've presented know evidence that they do so for scalability. You've claimed that that's the explanation they give, but for the one site that verifiably does use PHP, that's false, as the explanation rubyonrails.org gives for using PHP is not scalability. If you've got evidence that the others use PHP for scalability, feel free to present it.
No one is denying that many in the Ruby community, including (perhaps especially) the maintainers/developers of the Ruby language (who have to, at least, use C) use languages other than Ruby.
What is being questioned is your claim that specific web sites use a particular alternative language (PHP) for a particular reason (scalability), a claim for which you have presented no convincing evidence, and for which your claimed sources -- both regarding the use of PHP and the reason -- have shown things other than what you have claimed.
You have yet to provide any reason to believe that the "maintainers of the language" (which, incidentally, aren't represented by 43things or rubyonrails.org -- 43things is a social networking site, Ruby on Rails is a framework, both make use the Ruby language [among others--RoR includes JavaScript components, too]) have said any such thing, whereas the operators of rubyonrails.org (who you've also claimed have said the same thing about PHP for scalability) have given a different explanation of their use of PHP.