Re:Could Groovy replace Java? Some features crypti
on
Groovy in Action
·
· Score: 1
Oops, add return(..) around the create_function bodies; no implicit return values in PHP.
Re:Could Groovy replace Java? Some features crypti
on
Groovy in Action
·
· Score: 1
I've never used Groovy, but it looks fairly clear to me (though I have a Ruby background), except the final bit looks like it should be *.product.name (which will apply.product.name to each element of the list to the left of the operator):
send objLineItemList to invoices (returns a List)
send grep to the List with a closure (returns a List containing each element for which closure(element) returns true)
for each element of the List, send product, and to the return value of that send name (returns a list with the result of that for each element, equivilent to list.map { item -> item.product.list})
send == to the List literal ['UCL'] with the mapped list as an argument, (returns a boolean)
send that to assert which will do something if it's false
$ExpensiveItems = array(); foreach ($invoices->objLineItemList() AS $aLineItem) {
if ($aLineItem->totalCostLineItem() > 7000)
{// you could of course do the code in the loop below here
$ExpensiveItems[] = $aLineItem;
} } $ExpensiveItemNames = array(); foreach ($ExpensiveItems AS $aLineItem) {
$ExpensiveItemNames[] = $aLineItem->product()->name(); } assert(array('UCL') == $ExpensiveItemNames);
"Now, consider the fact that I'm only 22 (meaning "back in my day" refers to only a decade or so ago) and you really have to wonder how people got this stupid, this quick!"
You know that whole "we're headed for a technological singularity" thing? Well, it's kind of like that, but going in the opposite direction.
So, in 30 years or so when everyone and his uplifted dog has a universal constructor in his cupboard and the ability to destroy everything, humans will be too dumb to actually operate them, thus averting the whole "anyone can grow a superweapon" problem. In the mean time, ubiquitous surveillance gives us billions of hours of reality TV per day \o/
It's nearby, has fairly mild conditions, and it's an interesting target; we send more stuff there and pay more attention to it. Since it's popular, there's more pressure on each probe to really better all the previous ones, so we're more ambitious with what we send.
I'm sure we'd see similar rates of failure if we sent probe after probe after probe to the outer planets; each probe would really want to do something different to the previous one, and pushing the boundaries would invariably find them. Instead we manage something like one a decade, so each one really needs to count and doesn't need to be quite so bleeding edge to be significantly better than previous probes.
Roughly what Cell is for PowerPC; take a x86 core, rip out most of the OOE stuff and the whacky big caches, beef up the SIMD side, put a few dozen on a die with a really fast interconnect and there's your x86 GPU/Stream Processor.
"It sounds like, by eliminating block devices, that they basically remove the kernel from doing any re-ordering or caching of data, which makes things "safer""
No; FreeBSD's shifted the buffer cache away from individual devices and into the filesystem/VM, where it caches vnodes rather than raw data blocks. The IO queue (below all this block/character/GEOM stuff) is scheduled using a standard elevator algorithm called C-LOOK. It's showing it's age in places, and there's been some effort towards replacing/improving it, making it pluggable etc (e.g. Hybrid); sadly it's a tricky problem to solve properly. See this recent thread.
Pfft. Remove it and use quicksearches like sensible people. "g my search terms" in the address bar is far, far nicer than navigating to the silly little text box in the corner, and it works for any search engine you might use (see Bookmarks -> Quick Searches).
This also works in Opera (Preferences -> Searches), and even IE (see TweakUI, Internet Explorer -> Search, or look for the registry tweak).
"1) Buy song on iTunes 2) Drop it in a playlist 3) Menu: File => Burn Playlist to Disk 4) Import... 5) Profit!" Sure, burn 128kbps AAC to a CD, then rip it again (eta: 30+ minutes) and encode to FLAC so I can have the worst of both files (or to MP3 and leave my ears bleeding), just so I can play it in something that doesn't make me want to dismember puppies or people who suggest burning and re-ripping lossy formats. Why wouldn't I just give the money to the CD manufacturers in the first place and actually get something worthwhile for my money? Chances are the CD will cost less anyway because they're not sold by a single vendor with 90% of the market.
"I'm sorry, this is only a problem for morons"
Oh, well, your harsh words now surely have me convinced.
Ruby has similar problems; the standard interpreter only supports green threads, so doesn't scale beyond a single CPU. JRuby supports native Java threads, but then Rails isn't thread safe, doh!
YARV has pthreads support, but they seem to be targeting a Big Giant Lock style design to avoid breaking lots of extensions, which is similar to what you get with PHP; the interpreter's thread safe, but use more than the most basic extensions and it all comes tumbling down.
It's not such a big deal for many deployments; you'll tend to be running out of CPU before you start hitting memory limits, but it does suck somewhat if you're trying to host lots of little apps for lots of users on the cheap.
"The last time I used Rails (0.9ish), it wouldn't let you connect to more than one database per application. This is unacceptable in my environment, so I had to throw it out as a prospective tool."
That's an ActiveRecord thing.. use a different ORM (Og looks quite nice), or no ORM; convention isn't a gun to your head, and it's not really a lot of effort to keep most of the benefits without actually using AR (my last Rails app used descript.ion files, heh). It's also not been true for a long, long time; each model can have it's own seperate connection, a feature added for ActiveRecord 1.0 (it's at 1.15.1 right now; 1.0 is 90% of the way down the changelog, sometime in 2004).
"Rails (or rather ActiveRecord) has all the same problems that all ORMs do. The first of which is optimizing for ease of development, not memory footprint."
Er, right. Can't say I've noticed ActiveRecord's memory footprint being much of a problem; if I'm loading huge result sets, it's generally enough of a problem that I just use a cursor, no matter what library I'm getting them via -- removing the few additional objects AR throws in doesn't really make much of a dent. Besides, developers generally cost more than memory.
"A second problem is the "more information than I asked for" problem. SELECT * should be used sparingly in favor of just grabbing the information that you need. ORMs have no idea of what information you want, so they just grab everything."
Bla.find(:all,:select => "title,body") --:select was added in 1.12.0, about 14 months ago.
"I don't think God would want us to be so bored as spending 1,000 years to visit the next planet."
If there's one thing that's clear, it's that if there is such a being then he doesn't really care much for our comfort.
"There was a really good sci-fi book I once read about the human race getting wiped out by some other races von-Neumann machines. We find out later that they are Universally out-lawed, and that other alien races have banded together to wipe out any race that uses them."
Greg Bear's Anvil of Stars and The Forge of God? There was supposed to be a movie being made out of at least one of those.
As for your comment about self-replicating machines; I think the most desirable answer is obvious there; we don't send mere automated robot probes, we migrate ourselves into the machines and go ourselves. At least we shouldn't need to break physics to do that:)
It's news because it's supposedly the fastest platter based disk yet, and because it's the first major development in 2.5" disks in several years; in that time they've grown rather popular in servers, as seen in Sun's range of Opterons for example.
This now makes the form factor even more competitive in IO-sensitive applications, and I dare say Slashdot has enough users interested in such a thing to warrant a FPP.
That's all a Podcast is; a URL to an audio file, streamable or otherwise, that happens to be linked from an RSS/Atom/etc feed. Said feed doesn't seem to have any impact on this proposal.
I wonder how much these people are getting bribed^Wpaid for pushing this utter crack.
Maybe if you're a psychopath. Of course assuming much about your expected lifespan while our technological development is accelerating with no end in sight is perhaps not very logical either.
It sucks, but it handily doesn't violate causality. I'm not sure I'm willing to give that up just yet, though it might make for some interesting computer architectures:)
Seagate have 5 year warranties on all their disks (though I don't know what they're doing with their cheapo brand - Maxtor), and make Near-Line storage drives like the NL35 and the newer NS models with lower projected failure rates for a modest increase in price.
Your handful of failed disks are insufficient to back up your conclusion. Maybe you've got some environmental problem you haven't noticed, maybe the couriers who have handled your disks are really bad, or maybe you're just unlucky -- with a sample size of 9, you're really not in a position to make claims about hundreds of millions.
Everything dies more often at the front and back end of the bathtub curve, and Seagate are the world's most popular disk manufacturer, so yes, there will be plenty of "my Seagate killed my dog and committed suicide after only 13 microseconds of use!!111!11" anecdotes. That's all they are -- anecdotes. Unless you've got a significant sample size, you can draw no conclusions, though if it happens a lot you might think about using a different courier.
Of course new technology often does have a higher than expected failure rate, at least to start with. It's not unique to Seagate.
Most people don't know what lossy or lossless formats are, but most will understand the implications if they're explained in a context that might matter to them.
"Future portable players will support formats which allow you to fit 2 or 3 times as much music on them without noticable loss in quality. Do you want to buy a future-proof lossless format which can take advantage of such an advancement in future but will take a bit more space on your PC, or a lossy format which might result in noticable quality loss if you ever want to use a different format?"
If the option were offered, the price difference was reasonable, and the differences explained simply, I'm sure a significant proportion of users would opt for the "better" option.
FCC regulations would appear to prohibit that kind of thing -- if it was easy to poke at the transmitter directly you might tell it to do something illegal. Even if you can technically allow for fairly open firmware with few distribution restrictions, you can imagine it raising the hackles of any corporate lawyer.
This memo presents a set of TCP extensions to improve performance
over large bandwidth*delay product paths and to provide reliable
operation over very high-speed paths. It defines new TCP options for
scaled windows and timestamps, which are designed to provide
compatible interworking with TCP's that do not implement the
extensions. The timestamps are used for two distinct mechanisms:
RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped
Sequences).
Section 4:
The timestamp value to be sent in TSval is to be obtained from a
(virtual) clock that we call the "timestamp clock". Its values
must be at least approximately proportional to real time, in order
to measure actual RTT.
"Also, digital is crap. Analog hands forever. A wristwatch should show you what time it is, not tell you. If you have to read it, you've defeated the point of having a wristwatch."
What bollocks. If reading 3 or 4 numbers off a display takes you more time or effort than reading the hands on a watch, it's your reading comprehension that's crap. Granted plenty of digital watches have sucky displays filled with useless spinny crap and squeeze the time into an area the size of a toothpick.
Personally I use a Casio F-E10; it's cheap, thin, and about as optimal as it gets display wise.
I never said anything about what I was in favour of. Pointing to a set of artificial numbers doesn't really help, either; for 99% of cases they're irrelevent past a point most languages reach with ease (and by those numbers, a language with somewhat nicer looking semantics than C/++ seems to be winning); where they are relevent, dipping into a lower level language just for that is normally a better choice than doing your entire app in C. Alternate hard and soft layers. Plenty of systems, including games, follow this pattern.
Yes, IT's not easy, but most of the real complexity is in the data and the algorithms you use; adding more complexity to everything by using a basic very low level language for the sake of performance you normally don't need is just silly. Frankly, even when performance is needed, languages like C/++ are often still too low level -- you should be able to trade off less in the way of programmer friendliness without removing significant chunks of performance. But now I'm handwaving:P
Slashdot Mirror
Oops, add return(..) around the create_function bodies; no implicit return values in PHP.
Here's the rough equivilent in PHP:
Or in less dense form:$ExpensiveItems = array();
foreach ($invoices->objLineItemList() AS $aLineItem)
{
if ($aLineItem->totalCostLineItem() > 7000)
{
$ExpensiveItems[] = $aLineItem;
}
}
$ExpensiveItemNames = array();
foreach ($ExpensiveItems AS $aLineItem)
{
$ExpensiveItemNames[] = $aLineItem->product()->name();
}
assert(array('UCL') == $ExpensiveItemNames);
"Now, consider the fact that I'm only 22 (meaning "back in my day" refers to only a decade or so ago) and you really have to wonder how people got this stupid, this quick!"
You know that whole "we're headed for a technological singularity" thing? Well, it's kind of like that, but going in the opposite direction.
So, in 30 years or so when everyone and his uplifted dog has a universal constructor in his cupboard and the ability to destroy everything, humans will be too dumb to actually operate them, thus averting the whole "anyone can grow a superweapon" problem. In the mean time, ubiquitous surveillance gives us billions of hours of reality TV per day \o/
It's nearby, has fairly mild conditions, and it's an interesting target; we send more stuff there and pay more attention to it. Since it's popular, there's more pressure on each probe to really better all the previous ones, so we're more ambitious with what we send.
I'm sure we'd see similar rates of failure if we sent probe after probe after probe to the outer planets; each probe would really want to do something different to the previous one, and pushing the boundaries would invariably find them. Instead we manage something like one a decade, so each one really needs to count and doesn't need to be quite so bleeding edge to be significantly better than previous probes.
"what the fuck is an x86 GPU???"
Roughly what Cell is for PowerPC; take a x86 core, rip out most of the OOE stuff and the whacky big caches, beef up the SIMD side, put a few dozen on a die with a really fast interconnect and there's your x86 GPU/Stream Processor.
"It sounds like, by eliminating block devices, that they basically remove the kernel from doing any re-ordering or caching of data, which makes things "safer""
No; FreeBSD's shifted the buffer cache away from individual devices and into the filesystem/VM, where it caches vnodes rather than raw data blocks. The IO queue (below all this block/character/GEOM stuff) is scheduled using a standard elevator algorithm called C-LOOK. It's showing it's age in places, and there's been some effort towards replacing/improving it, making it pluggable etc (e.g. Hybrid); sadly it's a tricky problem to solve properly. See this recent thread.
"little box in the upper right hand corner"
Pfft. Remove it and use quicksearches like sensible people. "g my search terms" in the address bar is far, far nicer than navigating to the silly little text box in the corner, and it works for any search engine you might use (see Bookmarks -> Quick Searches).
This also works in Opera (Preferences -> Searches), and even IE (see TweakUI, Internet Explorer -> Search, or look for the registry tweak).
"Memory: 1 DDR2 533 SODIMM socket, up to 1GB".
Perhaps mounted underside?
"1) Buy song on iTunes ...
2) Drop it in a playlist
3) Menu: File => Burn Playlist to Disk
4) Import
5) Profit!"
Sure, burn 128kbps AAC to a CD, then rip it again (eta: 30+ minutes) and encode to FLAC so I can have the worst of both files (or to MP3 and leave my ears bleeding), just so I can play it in something that doesn't make me want to dismember puppies or people who suggest burning and re-ripping lossy formats. Why wouldn't I just give the money to the CD manufacturers in the first place and actually get something worthwhile for my money? Chances are the CD will cost less anyway because they're not sold by a single vendor with 90% of the market.
"I'm sorry, this is only a problem for morons"
Oh, well, your harsh words now surely have me convinced.
Ruby has similar problems; the standard interpreter only supports green threads, so doesn't scale beyond a single CPU. JRuby supports native Java threads, but then Rails isn't thread safe, doh!
YARV has pthreads support, but they seem to be targeting a Big Giant Lock style design to avoid breaking lots of extensions, which is similar to what you get with PHP; the interpreter's thread safe, but use more than the most basic extensions and it all comes tumbling down.
It's not such a big deal for many deployments; you'll tend to be running out of CPU before you start hitting memory limits, but it does suck somewhat if you're trying to host lots of little apps for lots of users on the cheap.
"The last time I used Rails (0.9ish), it wouldn't let you connect to more than one database per application. This is unacceptable in my environment, so I had to throw it out as a prospective tool."
:select => "title,body") -- :select was added in 1.12.0, about 14 months ago.
That's an ActiveRecord thing.. use a different ORM (Og looks quite nice), or no ORM; convention isn't a gun to your head, and it's not really a lot of effort to keep most of the benefits without actually using AR (my last Rails app used descript.ion files, heh). It's also not been true for a long, long time; each model can have it's own seperate connection, a feature added for ActiveRecord 1.0 (it's at 1.15.1 right now; 1.0 is 90% of the way down the changelog, sometime in 2004).
"Rails (or rather ActiveRecord) has all the same problems that all ORMs do. The first of which is optimizing for ease of development, not memory footprint."
Er, right. Can't say I've noticed ActiveRecord's memory footprint being much of a problem; if I'm loading huge result sets, it's generally enough of a problem that I just use a cursor, no matter what library I'm getting them via -- removing the few additional objects AR throws in doesn't really make much of a dent. Besides, developers generally cost more than memory.
"A second problem is the "more information than I asked for" problem. SELECT * should be used sparingly in favor of just grabbing the information that you need. ORMs have no idea of what information you want, so they just grab everything."
Bla.find(:all,
"I don't think God would want us to be so bored as spending 1,000 years to visit the next planet."
:)
If there's one thing that's clear, it's that if there is such a being then he doesn't really care much for our comfort.
"There was a really good sci-fi book I once read about the human race getting wiped out by some other races von-Neumann machines. We find out later that they are Universally out-lawed, and that other alien races have banded together to wipe out any race that uses them."
Greg Bear's Anvil of Stars and The Forge of God? There was supposed to be a movie being made out of at least one of those.
As for your comment about self-replicating machines; I think the most desirable answer is obvious there; we don't send mere automated robot probes, we migrate ourselves into the machines and go ourselves. At least we shouldn't need to break physics to do that
It's news because it's supposedly the fastest platter based disk yet, and because it's the first major development in 2.5" disks in several years; in that time they've grown rather popular in servers, as seen in Sun's range of Opterons for example.
This now makes the form factor even more competitive in IO-sensitive applications, and I dare say Slashdot has enough users interested in such a thing to warrant a FPP.
That's all a Podcast is; a URL to an audio file, streamable or otherwise, that happens to be linked from an RSS/Atom/etc feed. Said feed doesn't seem to have any impact on this proposal.
I wonder how much these people are getting bribed^Wpaid for pushing this utter crack.
Maybe if you're a psychopath. Of course assuming much about your expected lifespan while our technological development is accelerating with no end in sight is perhaps not very logical either.
It sucks, but it handily doesn't violate causality. I'm not sure I'm willing to give that up just yet, though it might make for some interesting computer architectures :)
Seagate have 5 year warranties on all their disks (though I don't know what they're doing with their cheapo brand - Maxtor), and make Near-Line storage drives like the NL35 and the newer NS models with lower projected failure rates for a modest increase in price.
Your handful of failed disks are insufficient to back up your conclusion. Maybe you've got some environmental problem you haven't noticed, maybe the couriers who have handled your disks are really bad, or maybe you're just unlucky -- with a sample size of 9, you're really not in a position to make claims about hundreds of millions.
Everything dies more often at the front and back end of the bathtub curve, and Seagate are the world's most popular disk manufacturer, so yes, there will be plenty of "my Seagate killed my dog and committed suicide after only 13 microseconds of use!!111!11" anecdotes. That's all they are -- anecdotes. Unless you've got a significant sample size, you can draw no conclusions, though if it happens a lot you might think about using a different courier.
Of course new technology often does have a higher than expected failure rate, at least to start with. It's not unique to Seagate.
Most people don't know what lossy or lossless formats are, but most will understand the implications if they're explained in a context that might matter to them.
"Future portable players will support formats which allow you to fit 2 or 3 times as much music on them without noticable loss in quality. Do you want to buy a future-proof lossless format which can take advantage of such an advancement in future but will take a bit more space on your PC, or a lossy format which might result in noticable quality loss if you ever want to use a different format?"
If the option were offered, the price difference was reasonable, and the differences explained simply, I'm sure a significant proportion of users would opt for the "better" option.
FCC regulations would appear to prohibit that kind of thing -- if it was easy to poke at the transmitter directly you might tell it to do something illegal. Even if you can technically allow for fairly open firmware with few distribution restrictions, you can imagine it raising the hackles of any corporate lawyer.
"Also, digital is crap. Analog hands forever. A wristwatch should show you what time it is, not tell you. If you have to read it, you've defeated the point of having a wristwatch."
What bollocks. If reading 3 or 4 numbers off a display takes you more time or effort than reading the hands on a watch, it's your reading comprehension that's crap. Granted plenty of digital watches have sucky displays filled with useless spinny crap and squeeze the time into an area the size of a toothpick.
Personally I use a Casio F-E10; it's cheap, thin, and about as optimal as it gets display wise.
Use GPU-accelerated decoding, ala PureVideo. Not that I wouldn't also want the CPU power to do it too.
I never said anything about what I was in favour of. Pointing to a set of artificial numbers doesn't really help, either; for 99% of cases they're irrelevent past a point most languages reach with ease (and by those numbers, a language with somewhat nicer looking semantics than C/++ seems to be winning); where they are relevent, dipping into a lower level language just for that is normally a better choice than doing your entire app in C. Alternate hard and soft layers. Plenty of systems, including games, follow this pattern.
:P
Yes, IT's not easy, but most of the real complexity is in the data and the algorithms you use; adding more complexity to everything by using a basic very low level language for the sake of performance you normally don't need is just silly. Frankly, even when performance is needed, languages like C/++ are often still too low level -- you should be able to trade off less in the way of programmer friendliness without removing significant chunks of performance. But now I'm handwaving