Yup, all less-than-10%-of-them-US-TV-owners (US HDTV market penetration is estimated to barely reach 10% by the end of 2006) (and much less everywhere else)...
Except that (C)Ruby works, is stable, is actually used (more than Jython I mean, which is used quite a lot), and is not designed by taking everything that looks shiny and shoehorning it in a stupid language.
Standard Libraries are first-party packages, I was talking about third-party packages. D has a fairly good stdlib (less extensive than Python's or Java's, but pretty much at Ruby's level, and with a documentation that doesn't quite suck as much).
I don't see anybody rushing to port this to run on the JVM/CLR, is this because the performance and memory use would absolutely suck?
I think it's because they don't go for the same market. Lua's goal is to be a fast, simple embedded language, to enable easy scripting of your C/C++ applications for example (which is why Lua is used a lot in embedded and games devs).
Python and Ruby are full fledged, self-contained programming languages (even though you can embed them into C/C++ programs, or use C/C++ libs from them). Porting them to the JVM or the CLR gives you all of the platform's power (modules & third party packages) with more dynamic and flexible syntaxes.
Java has garbage collection and is a simpler language than C++. The Java library is huge, but the actual language doesn't have nearly as many things that will bite you in the ass as C++ does. So it's easier to learn and harder to shoot yourself in the foot. I must not be as smart as the C++ fans, cause I prefer having a language like that for most of my development. I find that I can get things done in Java faster just because I spend less time catching bugs. My favorite's language is actually Ruby these days, but that's still impractical for a lot of things I like to do.
You should try the D Programming Language (from Digital Mars). It's much cleaner than Java, and faster. Has all the advantages of java (but the number of third-party packages I guess) with pretty much none of the inconvenients.
To be fair, Java does have some advantages over C and C++ for application development, and I think that Java has worked wonders in the corporate world.
So do many other languages. The main reason why Java worked wonders in the corporate world is marketting. Basically, Java is a victory of marketting over engineering.
For example, Java has static typing, which helps catch errors at compile time.
Doesn't have near enough to be truely useful, and the explicit typing (lack of type inference) make it extremely verbose and annoying to work with. Much more than statically typed languages with type inference and extremely strong type systems (à la Haskell) for example.
Two seconds of Googling could have told you that the JVM has supported more languages than.net for a long time.
I may be overreaching here, but I think that part of his point was that Sun never ever officially endorsed any language but Java on the Java platform. Only now that MS has started championing a pretty much official IronPython effort has Sun discovered dynamic languages, and started working towards making the JVM more dynamic-languages friendly.
Which is a damn shame, because they had Jython years ago, which they could easily have supported at almost no cost, and they let the project die on it's own.
and not a lot of effort has gone into making it run fast.
That one's right though, the current implementation of Ruby is pretty much the slowest way you could ever implement it. All the backend should be reimplemented for Ruby 2.0 (including a true VM) with YARV.
It's syntax is fairly alien. Most people don't like alien syntax. Ruby's syntax is much more in line with "traditional" languages such as Java
Ruby also has quite a lot of Perlish roots, which make it a quite "practical" language.
Smalltalk is a fairly unique language in the sense that it's image-based: your code always lives in your image, you never need to get out of the environment, the feeling is different
Smalltalk is fairly old, since it never took of most people never heard of it.
Last, but probably not the least, Smalltalk was quite "closed" as an architecture, for a long time the only useable implementations were commercial, which was not a good thing since there were no heavyweight backers of the language (C# has the former issue of a primarily commercial -- even if free via C# compilers and Visual C# Express -- implelementation, but it has all the weight of MS behind it)
But yeah, Ruby is much closer to Smalltalk than Lisp indeed, Ruby's main "ancestors" are Smalltalk and Perl with some bits of Lisp & others thrown in.
Backwards Compatibility is only half done on [..] wii.
I don't quite get that one. Last time I checked, the Wii was fully backward compatible with the GC, to the point that you can actually hook GC controllers to your Wii...
Dunno, most of the feedback about the devkits indicate that it's extremely complex and the tools are akin to PS2's devkits tools: they suck, and you have to create your own.
From what I've read, for this generation, the Microsoft devkits are the absolute best (in simplicity, functionality and features, I guess MS' experience with Visual Studio helped a lot there), then comes Nintendo (the devkits are OK, and the fact that the Wii is fairly similar to the GC allows companies to reuse GC knowledge), and dead end is Sony with much more difficult to use and less featureful devkits. I guess companies which developped a lot for the PS2 are used to it though.
But it seems that what sucked the most about the PS3 devkits were the second-to-last iteration: seems like they were extremely noisy ("vacuum cleaner") while the final iteration is extremely silent.
I'm not sure that we really need any more dynamic range than is offered by CDs, actually. 16 bits actually provides tremendous dynamic range -- so much so that almost no CDs actually use the range that is available.
The current CDs offer a very good dynamic range by itself, but as of late (well they've been at it for a few years already) labels have undergone a loudness war and are all but killing the dynamic range (see The Death of the Dynamic Range). There is also a fairly good article on the subject on the wikipedia including a most telling comparison of ABBA's One of Us 1981 version and 2005 remastering
CDs have a tremendous dynamic range, but it's less and less used in order to sound louder and louder.
Another thing that we could do is use sophisticated mathematical algorithms to analyze the sound in detail and figure out which bits to throw away. We might have problems if our algorithm is poor and throws out something we want, but after years of refinement we've developed algorithms that are far better than simple bit-tossing. In all blind testing, this gives much better results; you may hate a 128kb/s MP3, but try listening to an 8-bit 11khz recording sometime (88kb/s... for mono!)
Or we could use sophisticated mathematical algorithm to analyze the sound and only store the diffs between the channels, and compress anything that can be. Without information loss...
In a word, we could use... say... FLAC...
And we would have higher bitrates.
Because, you know, lossy formats even at uber-high bitrates- always have loss nonetheless. They all have "signatures", specific losses that you can't do anything about whatever bitrate you use. And they accumulate, which means that you couldn't use your high-bitrate lossy tune as a source for your conversion needs (to MP3, to OGG, to WMV,...) because you'd get the old artifacts plus the new ones.
So no, our "better" lossy compression format wouldn't get a way better sound than we get from a "lossless" CD, it would merely have a different sound signature, different losses.
Now if more work was done on truely lossless compression formats, and these formats were used instead of the current CD format, we could get much better quality music (most formats already yield CD-quality audio at 40% to 60% of a CD bitrate)
We don't know. They have big worldwide conferences on the 13th (Japan), 14th (Europe) and 15th (NA), most people/fanboys expect official disclosure of price and date (it's about time, after all) but not a thing has filtered. We still don't know what they're about.
Oh yeah, it starts the day after the Apple conf (12th of September) where they *may* unveil an upgrade of the Macbook Pros (and maybe even the MBs) to Core2 CPUs (I mean they just upgraded the iMac high end, and every MBP shipping is on hold at the moment)
I'm not sure, Intel could probably do it too but they'd have much less incensive (sp?) to, IBM on the other hand has it's whole PPC line that it can evolve in multiple directions at once, and doesn't sell CPUs to apple anymore.
Dude, these numbers have been debunked, no one has any info on either the CPU, the GPU or the RAM, even Wikipedia doesn't use these numbers for god's sake!
Graphics aren't everything but I have become used to beautifully rendered worlds immersive worlds and effects and it will be hard for most consumers to purchase a 'next generation' console with visuals from the pong era.
Remember that the Wii only needs to go up to 480p/60fps (well all games are supposed to be 480p/60fps stable), the Xbox360 and the PS3 will range between 720p and 1080p. You need a lot of processing power for the rise in pixels alone. And the GC probably had the highest power of it's generation, only the lack of RAM made it extremely hard to reach it's best potential (just check RE4/GC).
Correct me if I'm wrong, but IIRC, Sony is manufacturing the Cells for PS3s, but IBM holds a plethora of patents on that architecture and manufacturing process.
IBM probably gets a cut of every single manufactured Cell CPU. This is IBM we're talking about, not Mother Theresa, they played a big part designing the chip, you can bet they won't let Sony get away with just letting them sell Cells by their own
That one is wrong, the price will be under $250, and quite a few pointers tell us that it'll probably be $200/200/150£ for the bare console and a $250 pack.
Slashdot Mirror
IronPython moved from it's original site to GotDotNet ("The Microsoft .NET Framework Community", a microsoft website) in March 22, 2005...
I would've thrown Python in, but as Python is not much older than Ruby I finally decided against it.
Yup, all less-than-10%-of-them-US-TV-owners (US HDTV market penetration is estimated to barely reach 10% by the end of 2006) (and much less everywhere else)...
Uh? I'd say the issue's with Capcom here, but we'll see how the PS3 will fare since it's an issue of an HD game on an SD screen.
Except that (C)Ruby works, is stable, is actually used (more than Jython I mean, which is used quite a lot), and is not designed by taking everything that looks shiny and shoehorning it in a stupid language.
Standard Libraries are first-party packages, I was talking about third-party packages. D has a fairly good stdlib (less extensive than Python's or Java's, but pretty much at Ruby's level, and with a documentation that doesn't quite suck as much).
I think it's because they don't go for the same market. Lua's goal is to be a fast, simple embedded language, to enable easy scripting of your C/C++ applications for example (which is why Lua is used a lot in embedded and games devs).
Python and Ruby are full fledged, self-contained programming languages (even though you can embed them into C/C++ programs, or use C/C++ libs from them). Porting them to the JVM or the CLR gives you all of the platform's power (modules & third party packages) with more dynamic and flexible syntaxes.
Lua is definitely not "unheard of" though.
You should try the D Programming Language (from Digital Mars). It's much cleaner than Java, and faster. Has all the advantages of java (but the number of third-party packages I guess) with pretty much none of the inconvenients.
Give it a try between two Ruby sessions ;)
So do many other languages. The main reason why Java worked wonders in the corporate world is marketting. Basically, Java is a victory of marketting over engineering.
Doesn't have near enough to be truely useful, and the explicit typing (lack of type inference) make it extremely verbose and annoying to work with. Much more than statically typed languages with type inference and extremely strong type systems (à la Haskell) for example.
I may be overreaching here, but I think that part of his point was that Sun never ever officially endorsed any language but Java on the Java platform. Only now that MS has started championing a pretty much official IronPython effort has Sun discovered dynamic languages, and started working towards making the JVM more dynamic-languages friendly.
Which is a damn shame, because they had Jython years ago, which they could easily have supported at almost no cost, and they let the project die on it's own.
Ruby is older than Java.
That one's right though, the current implementation of Ruby is pretty much the slowest way you could ever implement it. All the backend should be reimplemented for Ruby 2.0 (including a true VM) with YARV.
Mmm reasons for not using Smalltalk:
But yeah, Ruby is much closer to Smalltalk than Lisp indeed, Ruby's main "ancestors" are Smalltalk and Perl with some bits of Lisp & others thrown in.
I don't quite get that one. Last time I checked, the Wii was fully backward compatible with the GC, to the point that you can actually hook GC controllers to your Wii...
And never intended to be hard to find
Dunno, most of the feedback about the devkits indicate that it's extremely complex and the tools are akin to PS2's devkits tools: they suck, and you have to create your own.
From what I've read, for this generation, the Microsoft devkits are the absolute best (in simplicity, functionality and features, I guess MS' experience with Visual Studio helped a lot there), then comes Nintendo (the devkits are OK, and the fact that the Wii is fairly similar to the GC allows companies to reuse GC knowledge), and dead end is Sony with much more difficult to use and less featureful devkits. I guess companies which developped a lot for the PS2 are used to it though.
But it seems that what sucked the most about the PS3 devkits were the second-to-last iteration: seems like they were extremely noisy ("vacuum cleaner") while the final iteration is extremely silent.
The current CDs offer a very good dynamic range by itself, but as of late (well they've been at it for a few years already) labels have undergone a loudness war and are all but killing the dynamic range (see The Death of the Dynamic Range). There is also a fairly good article on the subject on the wikipedia including a most telling comparison of ABBA's One of Us 1981 version and 2005 remastering
CDs have a tremendous dynamic range, but it's less and less used in order to sound louder and louder.
Or we could use sophisticated mathematical algorithm to analyze the sound and only store the diffs between the channels, and compress anything that can be. Without information loss...
In a word, we could use... say... FLAC...
And we would have higher bitrates.
Because, you know, lossy formats even at uber-high bitrates- always have loss nonetheless. They all have "signatures", specific losses that you can't do anything about whatever bitrate you use. And they accumulate, which means that you couldn't use your high-bitrate lossy tune as a source for your conversion needs (to MP3, to OGG, to WMV, ...) because you'd get the old artifacts plus the new ones.
So no, our "better" lossy compression format wouldn't get a way better sound than we get from a "lossless" CD, it would merely have a different sound signature, different losses.
Now if more work was done on truely lossless compression formats, and these formats were used instead of the current CD format, we could get much better quality music (most formats already yield CD-quality audio at 40% to 60% of a CD bitrate)
ditto, I'm in the same position console for console.
Seems to work with the DS' (at least in Japan) for now.
Oh yeah, it starts the day after the Apple conf (12th of September) where they *may* unveil an upgrade of the Macbook Pros (and maybe even the MBs) to Core2 CPUs (I mean they just upgraded the iMac high end, and every MBP shipping is on hold at the moment)
I'm not sure, Intel could probably do it too but they'd have much less incensive (sp?) to, IBM on the other hand has it's whole PPC line that it can evolve in multiple directions at once, and doesn't sell CPUs to apple anymore.
Dude, these numbers have been debunked, no one has any info on either the CPU, the GPU or the RAM, even Wikipedia doesn't use these numbers for god's sake!
Remember that the Wii only needs to go up to 480p/60fps (well all games are supposed to be 480p/60fps stable), the Xbox360 and the PS3 will range between 720p and 1080p. You need a lot of processing power for the rise in pixels alone. And the GC probably had the highest power of it's generation, only the lack of RAM made it extremely hard to reach it's best potential (just check RE4/GC).
I really doubt the Wii will be underpowered.
We'll just see, though.
IBM probably gets a cut of every single manufactured Cell CPU. This is IBM we're talking about, not Mother Theresa, they played a big part designing the chip, you can bet they won't let Sony get away with just letting them sell Cells by their own
That one is wrong, the price will be under $250, and quite a few pointers tell us that it'll probably be $200/200/150£ for the bare console and a $250 pack.
Not a snowball's chance in hell
Wrong, they plan to sell 6 million by March 2007, definitely not June.