I'm for it - if only because it's worth the experiment. Anxieties over prejudices from US lawmakers or some such don't mean much to me. I'm not from the US and I very much doubt that even those that _are_ from the US can do much more than express those anxieties. Nobody can prove anything. Besides that, the reasons given by ICANN are bogus. 'Not in the content-business' ? We're talking about the same organisation that sanctioned '.museum' ?! And even if porn were regulated in there, it would take _years_ for the lawsuits to dry up, by which time '.xxx' would have found a natural place. I'd say: give it a chance. Who cares.
What if it turns out that it's more efficient to produce ethanol from, oh, let's say hemp......or certain other highly over-valued weeds....
Do you have _any_ idea of how ethanol production works, and why we're not all drinking distillates from hemp ? If you do - nice troll - otherwise, let me start an explanation: it's about S.U.G.A.R.
No. You pedant. Because the topic would fall over very quickly if that was the case. With 'buy cool', the topic-writer didn't mean 'buy Youtube': Youtube is not for sale at the moment. He/she meant 'buy people and hardware to create 'cool' from scratch'. Does it make sense now ? Go take your pill.
Hm. I focussed on java, because you seemed to do so - it was the only specific thing you reacted to. With regards to performance; if locking was an aspect of a class, rather than its accessors, then java might not have suffered so much in performance. The architectures are all the same (within C, C++ and java) because they were chosen to be the same (something existing programmers knew). Kernighan and Ritchie had an excuse - their predecessors are long gone and threads weren't existing when they invented C. C++, C# and java have no such excuse - they were invented long after that, when computer power was many times that of a PDP-11.
I agree with you that MT programming is something that you have to understand the (almost mathematical) basics of. I don't agree with you that modern languages have an excuse for ignoring threads as a intrinsic aspect of their being. Java's core may be finished, but if we're really to write in languages that allow for proper usage by multiple CPUs, then C++ or java aren't the right choices.
FWIW, I don't personally think that this 'multiple core programming revolution' is around the corner in any way. If only because what they do at the moment (services and batch-processes) can already be programmed successfully in many other ways. The revolution that the topic at hand seems to imply, requires a radical shift in what people expect programs to do in the first place.
But isn't that the same old excuse ? I mean, if a language prides itself on 'there's just one way to do it' (and don't tell me java doesn't do that - it does), then why would it allow such a glaring hole ? I tell you why - it was never thought about. I know: I've inspected every JDK source tree since it was 1.0.2 - the people then, brilliant as they were, never gave a second thought about making classes re-entrant, and when they started doing that, the language wasn't really fit to apply it on. So you get ugly things like re-entrant and non-re-entrant varieties of the same class. Yuk.
So you come up with the oldest excuse in the book, and you replace responsibility from the tool to the people who use it. I'll tell you something: that only goes when the tool as such is finished, which it obviously isn't. The tool must go back to the toolmaker, but that's something we've heard about java so many times now, it isn't even funny.
The programming language must provide thread safety as part of its own paradigm, not as an add-on to the language in the form of functions, classes, templates or whatnot. Even java doesn't do it; you can make definitions of public accessors in java classes that are a mix of synchronized and not synchronized. That is provably unsafe (provided that these public accessors access the same private data), yet the language and the compiler allow it. Elegant degradation during runtime in case of deadlock detection or race conditions are non existent in the world of programming languages, yet you can easily think them up (binding some sort of preference to a thread and let the most preferential thread break the lock - experimenting with sleeping a thread for a number of seconds if it seems to race - notifying an 'exception' thread in case of all of this). I don't think that _any_ language that I know (and that isn't saying much, I'm not boasting) is really thread-ready.
Fits in perfectly with the current trend among dieticians to wave away the whole concept of exercise. Overheard one saying on TV the other night, that 'it takes two hours of rowing just to burn a banana'. That is, this person had probably burned a banana in her lab and compared it with the power needed to push a small boat forward. Not entirely representative as a) energy transfer in the human body is efficient, but not 100% efficient, b) the rowing movement is inefficient to say the least, c) we do a lot more when we row than just rowing (carrying our own weight, keeping the body warm, panting, repairs, etc.). I don't think that when you take a person who's just about to faint, give them a banana, have them row for two hours and expect to find them in the state they were in before they took the banana. Plus, what they refuse to mention: excercise is healthy.
Huh ? What's with your analogy man ? Recycling _did_ take off, and it _did_ produce a profit-making industry, and it _does_ help us use our resources more sparingly. Metals, paper, glass - they all come to us recycled in percentages way in the double digits.
Microsoft is doing what they think is in their best interest. Their purpose isn't to justify your education, or try and boost the number of CS majors. Their purpose is not to give you, or anyone else, employment. Nor is that the purpose of any company. Then maybe Mr Gates should also not be shooting his mouth off on how there are too preciously few people enrolling in computer science, as he did just a few weeks ago.
Java was just an example. If you write stuff in C++ to fit inside an appserver, then I wonder why you don't turn the order of things around. That is, write your application, and have a library on the side which runs a http server, publishing your app - but that's just a side-thought. With C++ I'd mainly have the reservation that the danger of heap-corruption by a neighbouring (different app-owned, even) thread is even bigger. I mean, in a java appserver I only run the risk that a badly programmed Servlet throws some element on a static Vector which each request, leaking memory until it can't run no more. With C++ I run the risk that some neighbouring thread causes a seqfault. With process isolation, I might spend time sucking up my state; with an app-server, how much time is spent inside locks ?
No, I love process isolation; I can add, remove, debug a single element of my app, all the while the machine keeps on running. In my line of business, there are no static, 'finished' applications. Ever. That's why I go for CGI every time.
]] I would never use CGI for any large scale development (maybe that's just me).
I do. And it works. Let me spell out the reasons why:
- code is extremely maintainable because every point of entry (script) is a separate entity on the filesystem. You always know where to start to trace a call. - library structures (control model view) can be used in CGI just as anywhere else, and my apps do just that. - code is executed extremely safely because of process isolation and privilege degradation; I don't have dangling database connections, other threads fucking up my heap, or re-entrancy issues. When my CGI process terminates abnormally, I'm pretty sure the rest of the appserver is undamaged.
On top of that I find it funny when people will smile when I explain to them how my CGI apps have to fork, execute an interpreter, load up resources and state and are only then good to go, and say: 'but you'll be slow, you'll need a lot of resources'. And then they'll fondly talk about their java webservers which are so fast, but unfortunately won't run unless you multiply the dimensions of my CGI's hardware by a thousand.
Not to put a too fine point to it, but 'Whether this change makes them more or less fit' isn't entirely correctly worded either. Selection always strives for more fitness. The problem is that fitness in one place (outer space, the world, a test-tube) doesn't necessarily define fitness in another. This is why we have the concept of 'biotope'.
Phones are only ever _really_ wanted by two categories of people - the gadget freaks (solo guys with big paychecks who also do something like kitesurfing on the side), and teens. All us other slobs just get boss issued phones, hand-me-downs from the wife, or whatever they had in the first phone shop that was the cheapest. I can't see a teenager going for this phone (it's too expensive), so they'll have to gamble that the gadget freak will want one. If you only have one product that's a big gamble.
]] in Windows threads, there is pretty much just the one type: HANDLE.
Yes. A HANDLE in WIN32 can also be a window, a file, a thread, a mutex, a pipe, a process and your grandmother. Since when is type checking not a good thing.
]] there is only the one function needed to make a thread block while waiting for an object: WaitForSingleObject.
Except, of course, if you're waiting for something to be posted to a pipe. Then you have to associate the pipe with a handle first. Oh and does he realize we have the same thing in UNIX ? It's called select() on a filedescriptor. Which you can't do in windows - because in windows, a pipe isn't a network socket isn't a filesystem object.
]] If a thread signals a condition variable and no other thread is waiting, does it make a sound?
Why do you want to write crappy code ?
Sorry - gotta go now. Diner's ready.
Not mentioned: Why does windows create recursive mutexes by default ?
Also not mentioned: Why doesn't UNIX have a proper POSIX event API that mixes with a threading API and a socket API ?
Slashdot Mirror
I'm for it - if only because it's worth the experiment. Anxieties over prejudices from US lawmakers or some such don't mean much to me. I'm not from the US and I very much doubt that even those that _are_ from the US can do much more than express those anxieties. Nobody can prove anything. Besides that, the reasons given by ICANN are bogus. 'Not in the content-business' ? We're talking about the same organisation that sanctioned '.museum' ?! And even if porn were regulated in there, it would take _years_ for the lawsuits to dry up, by which time '.xxx' would have found a natural place. I'd say: give it a chance. Who cares.
Because having .com .net .org and .museum means you're _not_ in the content regulation business.
What if it turns out that it's more efficient to produce ethanol from, oh, let's say hemp......or certain other highly over-valued weeds....
Do you have _any_ idea of how ethanol production works, and why we're not all drinking distillates from hemp ? If you do - nice troll - otherwise, let me start an explanation: it's about S.U.G.A.R.
No. You pedant. Because the topic would fall over very quickly if that was the case. With 'buy cool', the topic-writer didn't mean 'buy Youtube': Youtube is not for sale at the moment. He/she meant 'buy people and hardware to create 'cool' from scratch'. Does it make sense now ? Go take your pill.
It's probably not blogonarcisism; this behaviour is more like borderline Tourette.
So are you going to scan them ?
Stewed for a day in wine and garlic.
He doesn't need it for his resume. Last I heard Mr Gates had started his own company.
This person has been trolling slashdot for weeks now with exactly the same post. $DEITY only knows what he/she's trying to say with it.
Hm. I focussed on java, because you seemed to do so - it was the only specific thing you reacted to. With regards to performance; if locking was an aspect of a class, rather than its accessors, then java might not have suffered so much in performance. The architectures are all the same (within C, C++ and java) because they were chosen to be the same (something existing programmers knew). Kernighan and Ritchie had an excuse - their predecessors are long gone and threads weren't existing when they invented C. C++, C# and java have no such excuse - they were invented long after that, when computer power was many times that of a PDP-11.
I agree with you that MT programming is something that you have to understand the (almost mathematical) basics of. I don't agree with you that modern languages have an excuse for ignoring threads as a intrinsic aspect of their being. Java's core may be finished, but if we're really to write in languages that allow for proper usage by multiple CPUs, then C++ or java aren't the right choices.
FWIW, I don't personally think that this 'multiple core programming revolution' is around the corner in any way. If only because what they do at the moment (services and batch-processes) can already be programmed successfully in many other ways. The revolution that the topic at hand seems to imply, requires a radical shift in what people expect programs to do in the first place.
But isn't that the same old excuse ? I mean, if a language prides itself on 'there's just one way to do it' (and don't tell me java doesn't do that - it does), then why would it allow such a glaring hole ? I tell you why - it was never thought about. I know: I've inspected every JDK source tree since it was 1.0.2 - the people then, brilliant as they were, never gave a second thought about making classes re-entrant, and when they started doing that, the language wasn't really fit to apply it on. So you get ugly things like re-entrant and non-re-entrant varieties of the same class. Yuk.
So you come up with the oldest excuse in the book, and you replace responsibility from the tool to the people who use it. I'll tell you something: that only goes when the tool as such is finished, which it obviously isn't. The tool must go back to the toolmaker, but that's something we've heard about java so many times now, it isn't even funny.
The programming language must provide thread safety as part of its own paradigm, not as an add-on to the language in the form of functions, classes, templates or whatnot. Even java doesn't do it; you can make definitions of public accessors in java classes that are a mix of synchronized and not synchronized. That is provably unsafe (provided that these public accessors access the same private data), yet the language and the compiler allow it. Elegant degradation during runtime in case of deadlock detection or race conditions are non existent in the world of programming languages, yet you can easily think them up (binding some sort of preference to a thread and let the most preferential thread break the lock - experimenting with sleeping a thread for a number of seconds if it seems to race - notifying an 'exception' thread in case of all of this). I don't think that _any_ language that I know (and that isn't saying much, I'm not boasting) is really thread-ready.
Dunno.. maybe it helped if you were a little bit more specific ?
Skiplists are cool, though a bit roomy - but how about a tree with a parent and two children links - that's three links already.
Do the facts that you got laid and that BSD had a hole have anything to do with each other ? Just asking - kids these days...
Fits in perfectly with the current trend among dieticians to wave away the whole concept of exercise. Overheard one saying on TV the other night, that 'it takes two hours of rowing just to burn a banana'. That is, this person had probably burned a banana in her lab and compared it with the power needed to push a small boat forward. Not entirely representative as a) energy transfer in the human body is efficient, but not 100% efficient, b) the rowing movement is inefficient to say the least, c) we do a lot more when we row than just rowing (carrying our own weight, keeping the body warm, panting, repairs, etc.). I don't think that when you take a person who's just about to faint, give them a banana, have them row for two hours and expect to find them in the state they were in before they took the banana. Plus, what they refuse to mention: excercise is healthy.
Huh ? What's with your analogy man ? Recycling _did_ take off, and it _did_ produce a profit-making industry, and it _does_ help us use our resources more sparingly. Metals, paper, glass - they all come to us recycled in percentages way in the double digits.
Java was just an example. If you write stuff in C++ to fit inside an appserver, then I wonder why you don't turn the order of things around. That is, write your application, and have a library on the side which runs a http server, publishing your app - but that's just a side-thought. With C++ I'd mainly have the reservation that the danger of heap-corruption by a neighbouring (different app-owned, even) thread is even bigger. I mean, in a java appserver I only run the risk that a badly programmed Servlet throws some element on a static Vector which each request, leaking memory until it can't run no more. With C++ I run the risk that some neighbouring thread causes a seqfault. With process isolation, I might spend time sucking up my state; with an app-server, how much time is spent inside locks ?
No, I love process isolation; I can add, remove, debug a single element of my app, all the while the machine keeps on running. In my line of business, there are no static, 'finished' applications. Ever. That's why I go for CGI every time.
]] I would never use CGI for any large scale development (maybe that's just me).
I do. And it works. Let me spell out the reasons why:
- code is extremely maintainable because every point of entry (script) is a separate entity on the filesystem. You always know where to start to trace a call.
- library structures (control model view) can be used in CGI just as anywhere else, and my apps do just that.
- code is executed extremely safely because of process isolation and privilege degradation; I don't have dangling database connections, other threads fucking up my heap, or re-entrancy issues. When my CGI process terminates abnormally, I'm pretty sure the rest of the appserver is undamaged.
On top of that I find it funny when people will smile when I explain to them how my CGI apps have to fork, execute an interpreter, load up resources and state and are only then good to go, and say: 'but you'll be slow, you'll need a lot of resources'. And then they'll fondly talk about their java webservers which are so fast, but unfortunately won't run unless you multiply the dimensions of my CGI's hardware by a thousand.
"A group of us wanted to connect our computers to each other and then we wokked out a way to get of getting the signal between two points," he said.
Not to put a too fine point to it, but 'Whether this change makes them more or less fit' isn't entirely correctly worded either. Selection always strives for more fitness. The problem is that fitness in one place (outer space, the world, a test-tube) doesn't necessarily define fitness in another. This is why we have the concept of 'biotope'.
Phones are only ever _really_ wanted by two categories of people - the gadget freaks (solo guys with big paychecks who also do something like kitesurfing on the side), and teens. All us other slobs just get boss issued phones, hand-me-downs from the wife, or whatever they had in the first phone shop that was the cheapest. I can't see a teenager going for this phone (it's too expensive), so they'll have to gamble that the gadget freak will want one. If you only have one product that's a big gamble.
]] in Windows threads, there is pretty much just the one type: HANDLE.
Yes. A HANDLE in WIN32 can also be a window, a file, a thread, a mutex, a pipe, a process and your grandmother. Since when is type checking not a good thing.
]] there is only the one function needed to make a thread block while waiting for an object: WaitForSingleObject.
Except, of course, if you're waiting for something to be posted to a pipe. Then you have to associate the pipe with a handle first. Oh and does he realize we have the same thing in UNIX ? It's called select() on a filedescriptor. Which you can't do in windows - because in windows, a pipe isn't a network socket isn't a filesystem object.
]] If a thread signals a condition variable and no other thread is waiting, does it make a sound?
Why do you want to write crappy code ?
Sorry - gotta go now. Diner's ready.
Not mentioned: Why does windows create recursive mutexes by default ?
Also not mentioned: Why doesn't UNIX have a proper POSIX event API that mixes with a threading API and a socket API ?
It's a trap !