I want a machine that looks like a single powerful machine, but can be made out of tons of different PCs, where if one PC dies, it doesn't really matter.
Something like clustered VMS - but more generalized than Google's map reduce stuff.
Can't help you for general purpose stuff, but if you want a way to code applications on multiple machines, use Erlang, it's been built for this from ground up.
Developers get the idea of multithreaded programming - it's hard, but they understand it.
No they don't, they truly don't, most people don't being to truly "get" parallel processing and -- even worse -- no "popular" languages gets it either, all of the languages based on Dijkstra's concurrency model (shared memory and semaphores/locks) are fundamentally broken.
Are you mental? The 360 is already multi-processor, and multi-core is just a performance optimization to reduce communication overhead between processors
Actually, the 360 is multi-core, not multi-processor (it has a single Xenon CPU with 3 symmetrical PPC-based cores), and multi-core is more of a cost optimization and less of a performance one (AMD's communication overhead reduction between cores, as well as cache-sharing technologies, is an optimization only viable through the use of multi-core packages, but as Intel's old dual-core P4 showed, you can create a dual-core CPU by slapping two regular processors in a single package / on a single die without any such optimization)
Not really no, it's a repeat of the past PC history: push more pixels on the screen, output more flops. Nothing innovative, and nothing truly "leaping", especially when you don't build the tools to allow your devs to work on massively parallel machines.
It's a safe bet that the XBox 1080 (or whatever) will have multi cores
Uh... You're aware that the XBox 360 already has 3 (symmetric) cores aren't you? You don't seem to be...
Granted, the architectures may be completely different, but the principles involved are the same.
As computer developers are currently discovering, this is not so and thinking about parallel processing has huge differences with thinking about sequential processing.
Especially when just about every "popular" language is deeply broken as far as parallel processing goes.
VB, much like generic beer and America's Funniest Home Videos is an enabling technology for stupid people. It allows stupid people to do stupid things on scale that they couldn't accomplish on their own. While using VB does not make you a dumb programmer, being a dumb programmer does make VB your weapon of choice. That is unless you really don't know what the fuck you are doing, then its PHP all the way.
Srip them from their monopolies, use public money to roll out (dense) fiber data networks (instead of buying bridges to nowhere), then rent fiber to any private companies (for a fee).
The current telcos lose their power, everyone gets potential access to the network, new (disruptive) telcos can appear on the market without being strangled by teh mini bells.
Not going to happen of course (since the mini bells have pretty much bought out every telco-related regulator), but that's the best thing you guys could do.
The initial function on which you use new is merely a constructor, the only thing that would be gotten from a more regular class syntax in that point would be... well... nothing at all.
Class-based POO has other advantages, but this is not one of them.
continuations
There are great many things that should be fixed in Javascript before implementing continuations.
As a language, Javascript is simple, but has a very rich featureset. The standard libraries allow it to interface with the DOM of a HTML page.
In what bizarro world do you live where having a DOM interface means "a very reach featureset"?
I do like Javascript, but come on, javascript has barely any "featureset" to speak of and no standard library whatsoever apart from the DOM.
The only significant problem I can think of is Javascript's lack of thread control structures, which may prove problematic for applications that handle complicated asynchronous events.
Javascript has no threads, the lack of thread control structure therefore doesn't matter much.
its standard library is small and to the point
I strongly disagree: Javascript has no standard library. As far as the shortcomings of regular JS, check the improvements to javascript in JS1.6, JS1.7, E4X, and the various Javascript 2.0 propositions.
It is not possible to have two methods with the same name and different parameters (only one of those will ever be called).
Because Javascript has no ways of dispatching: all functions (remember that Javascript methods are exactly like functions) use varags, and the arguments you ask for are but pointers to vararg cells.
Example:
function foo(a, b, c) {
return [a, b, c, arguments];// `arguments` holds every single argument of your function no matter what
On the other hand methods behave like objects. One can have arrays of methods and then call mymethods[2](param);!
It's not that JS functions "behave" like objects, JS function are objects, period. Callable objects maybe, but objects nonetheless, they're no different from strings, integers or lists in that aspect.
And this is one of the nicest features of the language (along with lexical scoping and complete closures)
if it is not meant to replace HFS+, could there be any other reasons to support ZFS?
The answer is that it probably is meant to replace HFS+, but since ZFS is not bootable yet (including for Solaris 10) Apple can take the time to introduce ZFS, build tools for easier management, and let people get familiar with the FS before they have to drop HFS+.
HFS' lifetime has already stretched far beyond what it should have, it's time for Apple to think of its next generation FS, and ZFS is an extremely promising FS with heaps of amazing features Apple has already started to integrate into its UIs with Leopard (Time Machine + ZFS Snapshots anyone?).
ZFS also shows strong promises as both a home and a server FS.
you, care way too much about a piece of free software
It's not caring about "a piece of free software", it's caring about my choices of which browser I want to use.
If I run into a site that doesn't let me use Firefox (still run into them even now) then I just fire up IE for a second to get the job done, instead of waisting time complaining to people.
And I just leave the site, because I won't let anyone tell me what I'm supposed to surf with.
Its bad enough there are IE and firefox to contend with. Additional browsers makes an already bad situation worse. The space is simply too complicated to be entirely spec driven - unless the browser manufacturer is going to guarantee 100% bug-for-bug compatibility with existing engines they should not even try.
Oh come on, there are -- at the moment -- 6 browsers to test your sites in:
MS Internet Explorer 6.0
A pain in the ass, whether on the CSS or JS matters MSIE is a sheer annoyance. At least the JScript engine is well documented on MSDN, but that's it. MSIE6 is the most frustrating browser in existence, and usually gets a monkey-patching CSS all for itself via conditional comments.
MS Internet Explorer 7.0
As frustrating as his little browser JS-wise, better on CSS stuff but the engine is still quirky and new bugs, much less documented than IE6'. An overall improvement, but still frustrating.
Firefox 1.5 / 2.0
Supposedly the same CSS engine, Firefox 2.0 has Javascript improvements (1.7 instead of FF 1.5's JS1.6) which doesn't matter since you're limited to JS 1.5 anyway. A fairly good browser (with it's share of CSS bugs), but there are extremely good tools to fit it with (Web Developer Toolbar and Firebug 1.0) so it's by a far margin the most enjoyable development platform.
Safari 2.0
Fairly good CSS (although with it's share of bizarre bugs), but the JS support is abysmal. Developing Javascript for Safari 2 is a frigging pain, and I haven't managed to find any good documentations (MSDN-level at least, or devmoz-like) to mitigate the issue. Sucks.
Safari 3.0 (currently known as "Webkit nightlys")
A godsend compared to 2.0: better CSS support and the JS is leaps and bounds beyond Safari 2.0, we're litteraly in another realm. Plus it comes with an OK JS Debugger (Drosera). I just wish it were already a required upgrade to Safari 2.
Opera 9.0
Very good CSS and JS support, the only issue I sometimes have with it is that it's support of standard is often very strict. This means that strange bugs can crop up where you think you've understood what you were doing, other browsers were doing what you wanted them to, but Opera spots a mistake and tells you to go f*ck yourself (recently suffered from this issue when I dried to query XML documents using XPath). Other than that, my experience with Opera9 has been very enjoyable so far.
Overall, Opera 9 is up there with Firefox and Webkit in ease of development, both CSS and JS wise: they all have quirks, but not that much and usually fairly easy to work with. Firefox also comes with a really good dev doc, and it's possible to find dev resources for Opera's issues. Opera and Firefox also have the advantage of being useable (and testable) right-off-the-bat on any platform.
Safari 2.0 and both IEs, on the other hand, are the most painful to work for, I'd be more than happy to get rid of them.
Why should he stop using Opera? From my experience (as a web dev), Opera 9 is one of the best browsers out there, much better than any MSIE at CSS stuff, leaps and bounds beyond Safari 2.0 in JS related stuff (and I pray Apple will release a Safari 2 update including the current Webkit/future Safari 3 improvements), it's reliable and fast. The only thing it's missing when compared to firefox is better JS dev tools (a debugger and a Firebug-like tool). That's it. Opera is one of the most enjoyable browsers to dev for, along with Firefox and the current Webkit nightlys.
Most of the time, it's because the "creators" of the page only tested in in MSIE, and the page therefore renders well in MSIE because the designers only happen to use broken code that somehow renders well in MSIE.
It's not that MSIE is good at rendering broken html (it's not really), it's that people are creating broken HTML that renders well in the mess of misbehaviour, bugs and other hellspawns that live in the MSIE code.
On the other hand, it's dead easy to create perfectly good HTML/CSS that render perfectly well in any browser but MSIE. You don't even have to try hard, just use a few floated elements here and there, a piece of position: fixed and some min/max heights and widths, and you're done.
The answer, 90% of the time, is that the window is the wrong size or shape for its contents. That's what the green "optimize" button is for -- to resize the window automatically to the same size as its contents, and properly implemented, this does just what you want.
Yeah, and the 10% left you're fucked, because the zoom button doesn't do what you want it to do. Case in point: Cocoa Emacs, the zoom button just changes the height, it's utterly useless.
It's not that PHP's fast with a bytecode cache, it's that PHP is damned slow without it
Django/mod_python beats the crap out of most PHP stuff
And I strongly doubt Django's the fastest framework out there (in terms of raw speed, it also beats PHP in security and speed of development by the way). Seaside (+ Strongtalk?) looks mighty fast for example.
I agree that PHP has problems that make it easy for non-experts to leave their scripts wide open, and create terrible, kludgey code;
Worse than "easy", trivial, and most documentations head you towards crappy code hell.
but that does not somehow make it impossible to write good code in PHP.
Of course not, just as you can write Fortran in any language, you can write good code in any language (except BrainFuck or Moo, I guess). The thing is, PHP makes it far harder than necessary, and you'll always feel the nudge to "just do a quick fix here", and if you do, everything gows downhill. Fast.
It's a flexible language compared to Java
That's kind-of like saying that something is warmer than liquid nitrogen. It's true, but it's not really hard if you try, and many other things are.
but that doesn't mean that good code somehow cannot be written in it.
Still makes it far harder than some other languages out there that are much more flexible, complete, enjoyable, clean, and full featured.
PHP should escape automatically and anything that needs to be placed into the database raw should have be moved there via an "unescape" function. Why is the default functionality "Do this the dangerous way".
Slashdot Mirror
17
5 (I'm a very bad drinker)
30 to 50 in residential areas, 70-90 outside of towns, 110 to 130 on motorways.
Not out of the US dear sir.
Yes it does, 1000cm^3 = 1dm^3 = 1 liter, and by definition 1 liter of pure water weights 1kg (== 1000g) at sea level.
Metrics just pwned you, good sir.
Nope, it's 1 processor, 3 cores, and every core handles 2 "physical" threads (as opposed to HyperThreading's virtual threads)
So the Xenon handles 6 threads on 3 cores on 1 CPU.
Can't help you for general purpose stuff, but if you want a way to code applications on multiple machines, use Erlang, it's been built for this from ground up.
No they don't, they truly don't, most people don't being to truly "get" parallel processing and -- even worse -- no "popular" languages gets it either, all of the languages based on Dijkstra's concurrency model (shared memory and semaphores/locks) are fundamentally broken.
Actually, the 360 is multi-core, not multi-processor (it has a single Xenon CPU with 3 symmetrical PPC-based cores), and multi-core is more of a cost optimization and less of a performance one (AMD's communication overhead reduction between cores, as well as cache-sharing technologies, is an optimization only viable through the use of multi-core packages, but as Intel's old dual-core P4 showed, you can create a dual-core CPU by slapping two regular processors in a single package / on a single die without any such optimization)
Not really no, it's a repeat of the past PC history: push more pixels on the screen, output more flops. Nothing innovative, and nothing truly "leaping", especially when you don't build the tools to allow your devs to work on massively parallel machines.
Uh... You're aware that the XBox 360 already has 3 (symmetric) cores aren't you? You don't seem to be...
As computer developers are currently discovering, this is not so and thinking about parallel processing has huge differences with thinking about sequential processing.
Especially when just about every "popular" language is deeply broken as far as parallel processing goes.
VB is not about logic, or intelligence.
Srip them from their monopolies, use public money to roll out (dense) fiber data networks (instead of buying bridges to nowhere), then rent fiber to any private companies (for a fee).
The current telcos lose their power, everyone gets potential access to the network, new (disruptive) telcos can appear on the market without being strangled by teh mini bells.
Not going to happen of course (since the mini bells have pretty much bought out every telco-related regulator), but that's the best thing you guys could do.
Javascript is currently evolving towards Python, which I consider much more fit to what JS currently is and its past history.
It's also acquiring features from much more functional languages (such as JS 1.7' let structure for dynamic scope generation)
You can already get "private" variables easily, and JS has properties too, I don't see anything missing
That's in the work for Javascript 2.0... maybe.
I sujest that you look up the notion of Prototype-based Object Oriented Programming
The initial function on which you use new is merely a constructor, the only thing that would be gotten from a more regular class syntax in that point would be... well... nothing at all.
Class-based POO has other advantages, but this is not one of them.
There are great many things that should be fixed in Javascript before implementing continuations.
In what bizarro world do you live where having a DOM interface means "a very reach featureset"?
I do like Javascript, but come on, javascript has barely any "featureset" to speak of and no standard library whatsoever apart from the DOM.
Javascript has no threads, the lack of thread control structure therefore doesn't matter much.
I strongly disagree: Javascript has no standard library. As far as the shortcomings of regular JS, check the improvements to javascript in JS1.6, JS1.7, E4X, and the various Javascript 2.0 propositions.
Please, you don't have the slightest idea of what you're talking about, just shut up and stop wasting slashdot's database space
Because Javascript has no ways of dispatching: all functions (remember that Javascript methods are exactly like functions) use varags, and the arguments you ask for are but pointers to vararg cells.
Example:
It's not that JS functions "behave" like objects, JS function are objects, period. Callable objects maybe, but objects nonetheless, they're no different from strings, integers or lists in that aspect.
And this is one of the nicest features of the language (along with lexical scoping and complete closures)
The answer is that it probably is meant to replace HFS+, but since ZFS is not bootable yet (including for Solaris 10) Apple can take the time to introduce ZFS, build tools for easier management, and let people get familiar with the FS before they have to drop HFS+.
HFS' lifetime has already stretched far beyond what it should have, it's time for Apple to think of its next generation FS, and ZFS is an extremely promising FS with heaps of amazing features Apple has already started to integrate into its UIs with Leopard (Time Machine + ZFS Snapshots anyone?).
ZFS also shows strong promises as both a home and a server FS.
It's not caring about "a piece of free software", it's caring about my choices of which browser I want to use.
And I just leave the site, because I won't let anyone tell me what I'm supposed to surf with.
Oh come on, there are -- at the moment -- 6 browsers to test your sites in:
MS Internet Explorer 6.0 A pain in the ass, whether on the CSS or JS matters MSIE is a sheer annoyance. At least the JScript engine is well documented on MSDN, but that's it. MSIE6 is the most frustrating browser in existence, and usually gets a monkey-patching CSS all for itself via conditional comments. MS Internet Explorer 7.0 As frustrating as his little browser JS-wise, better on CSS stuff but the engine is still quirky and new bugs, much less documented than IE6'. An overall improvement, but still frustrating. Firefox 1.5 / 2.0 Supposedly the same CSS engine, Firefox 2.0 has Javascript improvements (1.7 instead of FF 1.5's JS1.6) which doesn't matter since you're limited to JS 1.5 anyway. A fairly good browser (with it's share of CSS bugs), but there are extremely good tools to fit it with (Web Developer Toolbar and Firebug 1.0) so it's by a far margin the most enjoyable development platform. Safari 2.0 Fairly good CSS (although with it's share of bizarre bugs), but the JS support is abysmal. Developing Javascript for Safari 2 is a frigging pain, and I haven't managed to find any good documentations (MSDN-level at least, or devmoz-like) to mitigate the issue. Sucks. Safari 3.0 (currently known as "Webkit nightlys") A godsend compared to 2.0: better CSS support and the JS is leaps and bounds beyond Safari 2.0, we're litteraly in another realm. Plus it comes with an OK JS Debugger (Drosera). I just wish it were already a required upgrade to Safari 2. Opera 9.0 Very good CSS and JS support, the only issue I sometimes have with it is that it's support of standard is often very strict. This means that strange bugs can crop up where you think you've understood what you were doing, other browsers were doing what you wanted them to, but Opera spots a mistake and tells you to go f*ck yourself (recently suffered from this issue when I dried to query XML documents using XPath). Other than that, my experience with Opera9 has been very enjoyable so far.Overall, Opera 9 is up there with Firefox and Webkit in ease of development, both CSS and JS wise: they all have quirks, but not that much and usually fairly easy to work with. Firefox also comes with a really good dev doc, and it's possible to find dev resources for Opera's issues. Opera and Firefox also have the advantage of being useable (and testable) right-off-the-bat on any platform.
Safari 2.0 and both IEs, on the other hand, are the most painful to work for, I'd be more than happy to get rid of them.
Why should he stop using Opera? From my experience (as a web dev), Opera 9 is one of the best browsers out there, much better than any MSIE at CSS stuff, leaps and bounds beyond Safari 2.0 in JS related stuff (and I pray Apple will release a Safari 2 update including the current Webkit/future Safari 3 improvements), it's reliable and fast. The only thing it's missing when compared to firefox is better JS dev tools (a debugger and a Firebug-like tool). That's it. Opera is one of the most enjoyable browsers to dev for, along with Firefox and the current Webkit nightlys.
Most of the time, it's because the "creators" of the page only tested in in MSIE, and the page therefore renders well in MSIE because the designers only happen to use broken code that somehow renders well in MSIE.
It's not that MSIE is good at rendering broken html (it's not really), it's that people are creating broken HTML that renders well in the mess of misbehaviour, bugs and other hellspawns that live in the MSIE code.
On the other hand, it's dead easy to create perfectly good HTML/CSS that render perfectly well in any browser but MSIE. You don't even have to try hard, just use a few floated elements here and there, a piece of position: fixed and some min/max heights and widths, and you're done.
Yeah, and the 10% left you're fucked, because the zoom button doesn't do what you want it to do. Case in point: Cocoa Emacs, the zoom button just changes the height, it's utterly useless.
Doesn't work at all in Adium. Of course I don't quite see why you'd want that behavior for an IM client, but hey it still doesn't work.
Worse than "easy", trivial, and most documentations head you towards crappy code hell.
Of course not, just as you can write Fortran in any language, you can write good code in any language (except BrainFuck or Moo, I guess). The thing is, PHP makes it far harder than necessary, and you'll always feel the nudge to "just do a quick fix here", and if you do, everything gows downhill. Fast.
That's kind-of like saying that something is warmer than liquid nitrogen. It's true, but it's not really hard if you try, and many other things are.
Still makes it far harder than some other languages out there that are much more flexible, complete, enjoyable, clean, and full featured.
How the hell can you compare C and PHP?
And PHP being a tool doesn't mean it's a good tool, if PHP was a hammer it'd have a soft-rubber handle and would only whack thumbs and never nails.
Oh yeah, magic_quotes worked sooo well didn't it?
Use Django then, it does.