The entire concept of contracts (which the libertarians are so in love with) only works if you accept the legal fiction that everybody reads all the contracts they've committed themselves to.
The courts disagree, and the courts are in a better position to determine legal fiction than you are.
Which is, of course, utterly impossible.
I've read every contract I'm committed to. I don't know why you think it's impossible.
because Gateway never gave him a chance to read the EULA
As the previous link makes clear, whether the guy actually read the EULA doesn't actually matter.
What makes you believe Gateway never gave him the chance? He could have asked the retailer for a copy, called the 1-800 number, read the website, and I suspect if he asked nicely they'd send him a copy for free by mail or email. Don't confuse the inability with the unwillingness to bother; the two are extremely different in court.
But if he had had the chance to read it
Which he did.
he would have been legally presumed to have read it.
Er, no he wouldn't. What makes you come to this fantastically unlikely belief?
This presumption seems very strange to the non-lawyer
Primarily because it's 100% incorrect, and seems to be entirely derived from the incorrect belief that because someone is liable to a contract they've agreed to, that they're legally assumed to have read it. I'm not sure why you believe a person must read a contract to agree to it; there's no such requirement.
There are no statutory rights impinged by Gateway's contract. That whole thing was one big non sequitor.
Similarly, in a lot of places, consumer legislation gives you the right to sue any manufacturer for a defect
If and only if the manufacturer refuses to repair or replace it, unless the manufacturer signed a contract guaranteeing service provision by such and such a date. The problem with reciting laws you seem to remember is that they start meaning something really, really different once you know about the second half.
Repeating theoretical laws without citation is poison.
Also, it'll be fun seeing Gateway try to appeal this one... they're out of luck here.
They won last time. Please stop pretending to understand the law until you have at least a basic familiarity with case precedent.
I never sign a contract when I buy something from a supermarket, or even a big ticket item like a fridge, and somehow those companies don't suffer "unlimited liability" claims.
That's probably because your business isn't reliant on that fridge. If you go look at biotech refrigerators, you'll start seeing EULAs left and right.
Don't confuse that consumer goods have different protections than commercial goods with that commercial goods don't need commercial protections. The only reason you don't see it anywhere but computers is because computers are the only commercial goods you personally use. These kinds of clauses are all over shipping trucks, heavy equipment, generators, furnaces, even the gates that open and close parking lots.
Yes, business operated without EULAs for hundreds of years. That doesn't mean that we don't need them now; business has operated without the Internet, wire bank transfers and escrow for hundreds of years too, but if you pulled those, our current system would go straight to Hell.
Plenty of businesses have general terms and conditions that aren't disguised as contracts, and they're just as valid
Wow, there's a kind of agreement that isn't an EULA? That must mean that EULAs are pointless! (cough)
Also, tricking people into agreeing to waive their rights is pretty stupid.
How can anyone be expected to give informed consent to legalese gibberish?
Well, you are, whether or not you think it's reasonable. (shrugs) If you try telling the judge you didn't understand the contract, he or she will just tell you you shouldn't have signed it. If you complain that you really wanted the computer, the judge will tell you that you should have asked Gateway's sales team to put you in touch with someone who would explain the contract to you before purchase.
The hospitals want you to think so, but the tactic amounts to "sign this or he dies". One can reasonably argue that you did not agree to the terms
One can reasonably argue anything one believes in. That doesn't make it the law. People have tried to claim that filling out hospital forms is duress for decades; there is not one single non-overturned case of this tactic being upheld in the entire body of American law. Not even one. Just because you can make it sound reasonable doesn't make it the law. Y'see, what you'll find out if you try to take that to court is that you should have just refused to sign the forms until you understood them.
The hospital can't turn you away from treatment because you refuse to sign. If you don't speak english, if you can't read, if you're retarded, if you're stunned or mentally altered by drugs, injury or disease, maybe you just can't focus on holding the pen with that railroad spike through your leg. The hospital cannot say no. Therefore, there is no duress.
since the sale was completed before he was presented with the EULA
What makes you believe this? Part of becoming a Gateway authorized retailer - or, indeed, an authorized retailer of pretty much any company that holds EULAs - is to have that EULA available on-site before purchase. Furthermore, the EULA is available online, as well as by phone. I have no doubt that Gateway would mail you a copy free of charge if you asked them to nicely.
I don't understand why people believe that an EULA is only valid if read before purchase. The dividing line is not having seen the EULA, but rather having the opportunity to see the EULA. It doesn't matter whether you actually did it; only if you had the ability. That EULA was easy as pie to get. It stands.
Sloth almost never a defense under American law; similarly, ignorance only applies when it's not preventable.
Sorry, but the agreement states that you agree to it automatically by hitting the "I agree" button. Signatures really are rarely necessary to create a legal contract (granted they help ensure them, but things are often contracts without them).
The agreement could state that you agree to it automatically just by reading it. Doesn't make it true.
No part of the law currently challenges the validity of the mechanism "press this button to indicate agreement." The reason saying that reading the text indicates agreement is twofold: one, the law does not allow the mechanism to discover the agreement to be the same mechanism as indicating agreement, and two, it's a lot easier to prove that you pressed the button.
I realize it's de rigeur to say "nuh-uh" to things other slashdotters said that sound legally shaky. Thing is, if you don't know the law either, it turns out not to work very well.
First of all, a language is not the thing that's "slow" or "fast".
Whereas the two examples you're arguing - C# and Java - are things with which I agree on your grounds, I should point out that there are in fact such things as slow languages. Sure, the quality of the compiler or interpreter has a lot to do with it, but there are other issues too. You can't really write a fast chess AI, for example, using Erlang, because there's no way to implement in-place zobrist hashing and because the fundamental datatypes don't allow you to write the kind of code that allow fast specific hashing. Erlang's actually a very fast language in general, but that's a clean case of language design providing a clear impediment to speed.
Other languages have similar problems. For example, pre-.NET Visual Basic had no serious support for real data structures, nor to client datastructures, meaning the programmers couldn't just implement their own (this has since changed.) Lua has no support for integer mathematics at all, something which can have an enormous impact on the speed of huge stretches of computing. Some languages fundamentally cannot be compiled at all, which does tremendous damage to their speed potential.
Then, you could get into talking to a Fortran/Fortress or Elm/Java or Prolog/Erlang designer about the changes between the two languages whose specific purposes were to enable optimizations for speed. A lot of people who aren't comfortable with the idea of a slow language are, oddly, still comfortable with the idea of a fast language.
In fact, one of the best examples I can give is C++: take a look into what Herb Sutter has to say about the problems caused by keyword export. He makes the surprisingly compelling case for removing the keyword based on a million different things. One of those things is the surprisingly long list of optimizations that compilers can no longer make if we just introduce that one keyword.
That one single keyword can and does make a huge difference in the speed of output binaries in those compilers such as Comeau/EDG and ICC which both implement export and are able to turn support for it off. That's a pretty clear indemnification, in my mind, of that language design cannot impact program speed.
Sure, maybe language design isn't the biggest issue. That doesn't mean it's a non-issue. I highly recommend you consider picking up a radical-difference language like Erlang or Mozart-OZ, and then go back to thinking about language impact on speed. The difference in approach of those two langauges to what you're probably used to is shocking, and can have tremendous impact on the fundamental design and structure of an application.
I'm with you - you and I both disagree strongly with the viewpoint of the person to whom you're responding. However, I suggest that you're oversimplifying the situation, in the zeal to make obvious to this third party what you disagree with, and in some situations the things that I believe you're oversimplifying can become very important.
and then using them in ways never intended that produce syntax that a plain C++ wouldn't even recognise
Boost is the future of "plain C++" by definition. If you can't follow this code, either get better at C++ or start learning a different language, because this is where C++ is going, whether you're ready or not. The purpose of Boost is to chart and test the future of the language. If you don't like the look of the future, well, y'know how we all react to Fortran programmers...
Speed isn't everything. If your server application is network or database bound then stability and API richness is considerably more important than speed of execution.
"Speed isn't everything. Why, if you start with a situation where other problems are choking you, you don't even have to think about speed!" That's called tautology.
By the by, the programming languages you just argued for are ADA, PHP and Visual Basic.NET, whose libraries are enormous in comparison to Java or C#. Now, I do a fair amount of PHP when I'm bored, so don't get up in arms when I say this. That said, I want to point something out: there are very, very few genuinely large scale services written in PHP, C#, Java, ADA, or any of those languages.
When it comes down to it, there are two costs: programmer time and hardware time. If you're network blocked, you buy a bigger network pipe; a dedicated box with a dedicated guaranteed ten megabit unmetered line for a year costs about a week and a half of a programmer's salary.
But, more importantly, you never, ever, EVER get network blocked. That just doesn't happen on engineered systems. The network moves faster than any software you or anyone you know will ever write. Sure, one given pipe might fill; you just upgrade the pipe. It's relatively straightforward to find gigabit, and if you know what you're doing you can go up from there; you have almost certainly never in your life seen a system that can push a gigabit of data. Even just filling static HTTP requests at that speed can bring a heavy duty, well tuned box to its knees. I happen to be friends with a tech at one of the giant shared hosting farms; his company has over 200,000 customers, and it takes them a Quad Athlon to service the average 100 megabit pipe filled with average wordpress blogs.
Now, I'm not saying the richness of the API doesn't matter. I'm just saying that positing a system based on filling the network is a little like designing the heater in the car in case the sun goes out. If you have enough users to fill a pipe, you can afford the next pipe up, or you need to be less retarded in setting your prices. The pipe has nothing to do with your selection of language.
And, frankly, the idea that you have to step away from real languages to get a real API is silly. Or, haven't you ever actually looked through the standard libraries of languages like C++ and Erlang?
After all, does it matter that your app completes 2ms faster if it has to wait 500ms for the database to return?
If your database is taking a half second to return, you've got incredibly serious problems. And yes, in the real world, a 2ms lag matters because of the queueing problem. Have a look at one of those graphs where a modern stage server like Lightstreamer or YAWS compares itself to Apache. Apache tends to drop off logarithmically. Every time you lag 2ms, that's two more MS of customers you have to deal with during the next query.
This is a limit flow problem, and most people get limit flow problems if you use a toilet as an analogy. Your webserver is similar to a toilet that doesn't have a stopgap. That means the bowl is always slowly filling with usage (ie, not water - say this is a train station) and you have to flush it every so often to keep things clean. The train station was well designed 50 years ago, but as population has gone up, the facilities are feeling the strain.
Now, there's a point at which you say "does it really matter if the toilet takes three minutes to flush, if it's 20 minutes between trains?" Well, actually, yes, because that means each toilet can only service six and two thirds people per train arrival. At home-bound rush hour, you're going to get an enormous line of people outside the bathroom that keeps getting longer and longer.
The problem with Apache is that the longer the line is, the slower the toilet flushes. See the issue now
By definition it is both. It is important to remember that no candidate library may be admitted to C++ if it isn't production ready. The idea that Boost is not meant for production use suggests that you too might do well with a bit of catching up on the ol' intents-and-philosophies set.
I used the Boost Graph Library for some research code... Getting it to compile was a bit of a nightmare too
Er. You do realize that the Boost Graph Library is not a compiled library, right?
What the hell is wrong with using make like everybody else?
Make cannot take into account compiler, platform or library differences. Boost JAM was created because the existing fix for this enormous well known problem in make, autotools/configure, is far more horrible than Make will ever be. Also, JAM is genuinely portable, whereas configure can sometimes be trusted on a different Unix than the one that created the package. There are of course documents that explain the purpose of JAM; perhaps you should read them.
I'm sure that once you become an expert, BGL is really powerful and efficient, but I found the learning curve too steep. I just want to get in and build a working prototype quickly so I can see what I'm doing, not spend hours wading through manuals and examples to build the simplest program.
That's a little like saying "I'm sure Oracle9i is really powerful and efficient, but I found the learning curve was too steep; I just wanted to keep a list of groceries." BGL is not a learning tool. It's a production tool. Production tools are never easy, and should never be used for experimental work.
Boost isn't there to help you learn. It's there to help you work. If you're still learning, well, then no wonder it scares the hell out of you.
Boost strikes me as the sort of library used by people who want to show off how up to date their skills are , not people who really need to write a program to get a job done
Then you obviously don't know much about boost. You use boost when you need smart pointers, strong portable randomness, graphing algorithms, runtime generic type behavior, CRC checks, binding behavior, type traits, prefab operators for classes, a prefab parser and/or tokeniser, finite state machines and state charting, memory pooling, portable thread wrappers, the lambda calculus, quaternions and octernions, interval mathematics, name parameterization and so on.
If that's your idea of tools that are there to just show off, then you ain't much of a programmer, kid.
Its bloated
Nonsense. I'd ask you to justify that with numbers, but I'm certain you are unable.
has a wierd syntax that differs from the C++ norm
No it doesn't. By the way, this is the candidate library for the next version of C++, which is only around a year or two off; most compilers implement huge stretches of Boost, and in a year or two, all of them will. That supposed mystery weird syntax is about to become a permanent fundamental part of the language. Sorry, Charlie.
and doesn't solve any problem that isn't already solved or could be done quite easily by standard C++ anyway
What is its point except as intellectual masturbation by its authors?
To test the future of C++ before making it permanent. This is something you'd know if you had the first clue about C++ or Boost. Unfortunately, as you've made plain to anyone reading, you don't.
What I find hilarious is that the people you're accusing of intellectual mastErbation are the very people you're silently putting on a pedestal. You talk badly about boost in favor of what C++ can already do, but the very people who created what C++ can already do are the same people creating Boost. Hell, the library was originally created by the C++ Standards Committee Library Working Group, not that I'd expect you to know who that is.
No this isn't a Troll
Perhaps not intentionally.
this is a post by someone who was forced to use Boost for a year
However, that's not quite what happened. Most of the advances in computer science and their practical applications have come from relatively small operations, compared to the hours and resources devoted by MS, IBM, Sun, Oracle, etc.
I've been hearing that mantra all of my life. It has no factual basis. If you take the time to write out a list of the things you think are important, *then* *afterwards* to research the list of origins, you'll find that not only are the vast bulk of these developments corporate, but that the ones that are from little teams virtually universally create large corporations that continue the innovation.
I think the cultural model people believed in the 20th century is that it's business and industry that drives innovation. But in the computing world, the opposite has happened.
No, it hasn't. Every single example you've given has been of large scale corporate innovation except FTP, and the idea that FTP is some huge step over what it replaced (UUCP) reveals an extremely poor understanding of the history of file transfer.
such as Bell labs developing Unix inside of Bell -- it wasn't management that drove the development of Unix; it seems to have been the researchers doing Comp Sci research under their own discretion -- perhaps you can correct me on this ).
The team under Kernighan and Ritchie which actually developed the first working UNIX was more than 30 people, and had corporate funding from AT&T in the hopes of taking Multics down a peg. Besides, if you're willing to pretend that development teams inside enormous corporations like AT&T, Bell and IBM are "small teams of programmers," then exactly what corporation doesn't fall under your definition of small teams?
You are rewriting what you said in the attempt to remove the error instead of to admit it. You wanted to believe that nearly everything under the sun was written by, and I quote, "small-time unix developers." Now, you're giving examples that have nothing to do with Unix or small time developers, and building increasingly absurd excuses to continue to call them small-time.
I mean, if you're willing to call a team of 30+ people in the late 1970s a small team, then there's just no such thing as a big team. Those kinds of populations were absolutely unheard of in that era; that's the age where a second programmer wouldn't be warranted unless you were taking on something like an operating system.
Please stop attempting to rewrite what you said. You were wrong. Be an adult and admit the error. The vast bulk of software, protocols, standards, free code and so on out there are written and donated by corporations. I know because I've done the chart that I suggested you do earlier.
Oh, and by the way, doing that chart doesn't count if you fill in origins from memory, because in this conversation you've attributed everything to the people you want to support, and gotten not a single one correct.
Believe it or not, you too can be in error about what happened before you were born.
No, it was a Macintosh. NeXT wasn't yet invented. I know because I bought a first generation NeXTslab, and it came with Mosaic pre-installed. You can call me an idiot all you like, and blame it on my "check your history" comment, but hey, Anonymous Coward, you should check your history too.
Anyone who has to say "you idiot" to make their point has an exceptionally poor control of the language.
On one project, [...] I had been hired as a consultant to fix their problems [...] and after watching the team [... ] spend literally almost a man-year [...] I finally [...] found the bug. It all took me about fifteen minutes. [... ] I made my point.
You've actually made several points here. I wonder if you realize how it looks for you to brag about taking almost a year to do a 15 minute job that other engineers needed your help with and were stuck on, when apparently that was the entire reason you were hired in the first place.
This sort of wasting time to try to make other people look bad is specifically why I refuse to hire outside consultants. Pitting one's own workers against one another leads to the most ridiculous, counterproductive and starkly sanctimonious destructive "I'm better than you" driven nonsense...
Is the US military a software development organization?
In this case, we're talking about a software development para-organization akin to RAND and Schlumberger, yes. The specific corporation in question is System Development Corporation, most commonly called SDC, and is the organization that did the actual creation of, among other things, email and ARPAnet for the military. The software development team in question was 47 people and they worked on a big-iron mainframe called AN/FSQ-32. The company employed thousands.
Unix was a reactionary movement to big iron (even its name, Unix, was a play on the canonical big iron of the time, Multics.) The development of email was undertaken by a large, well funded professional software development organization operating under the military on big iron hardware. This is about as close to the exact opposite of what you said as possible.
Is the Swiss particle physics laboratory a software development lab? No, they're a particle lab.
It may come as a surprise to you, but the volume of data produced by large particle colliders requires software development at a pace not seen in most areas. Indeed, the specific reason for the development of HTTP was to accomodate differential update for information, because the network infrastructure required to distribute all materials on a synchronized basis was becoming prohibitive.
Tim Berners-Lee designed the initial spec for the protocol that web servers use. To suggest that he single-handedly created the web is woefully misunderstood, and disposes of the central role that the software developers working with TBL at the time had in the ongoing development of the protocol. TBL himself has repeatedly said that his role in HTTP was relatively minor, and has repeatedly pointed out the similarity of his work to preceding work.
How much smaller of a Unix development 'team' can you get?
Tim Berners-Lee was working on a Macintosh. Check your history. By the way, this was before Macs were Unix boxes.
Whether you choose to look at HTTP as the result of one man, or the extremely large group (hundreds!) of scientists pitching into the system, again, we're talking about a well funded, well organized group of professionals, and you're either looking at a heterogenous system or a Mac.
Again, not a small group of Unix programmers, no matter how you look at it.
I don't know the history of FTP. Maybe you can fill me in -- how big was the team of guys that worked on it? How many years or man hours did they devote to it?
FTP is a college final project from MIT. It is supposedly the end result of almost three years of work, though that's apocryphal and I've never found citation. It isn't a team at all, it's one guy, and again, it predates UNIX. So, again, not a small team of Unix programmers and not a short development.
It strikes me as curious that you're asking me to defend my citation of a mistake you made about something you now admit you know nothing about. Do you not see the problem there? I mean, shouldn't you have to know about it before you start talking about where it started in the first place?
Like I said before, zero for three. I have you friended, and you have me friended, because in the past we have spoken well of one another and have respected one another's opinions. When you had something plain to say to me about my error, I took it on the chin like a man, and admitted my mistake.
You have no understanding of what you just said.
I should hope you learn not to speak this way to people. You'll find that in fact, frequently people who cite errors you made to you are, in fact, correct, and found the error because they have a longer history with these works than do you.
ftp, http, email, came from small-time unix developers.
Actually, email came from the US military, HTTP comes from Swiss particle physics laboratories, and FTP - which is RFC 114, April 1971, is older than the Unix Time Sharing System First Edition, November 3, 1971. I know it's de rigeur for Unix programmers to think that they're the root of all network stuff, but you're zero for three. Were I you, I'd look up the actual origins before citing them next time.
I'm not so sure about that. My take is that those four have been brainwashed by the Cylons to think they're Cylons too (the XO can't be a Cylon, he was fighting them before they evolved into skinjobs).
Presumably. For all you know, the skinjobs are older than that, or he's a prototype, or he's replaced the real Adama, or Scott Bakula installed him through a time rift, or god only knows what. It's science fiction. That's more flexible than magic.
On grounds of the systems in Erlang and Mozart-Oz, I disagree strongly that #1 is not appropriate for multicore application development. I cannot imagine an application development environment built around messages that took speed as priority over guaranteed delivery, frankly; that seems to me like building an application on UDP, which would so rarely be a good idea as to seem amazing to me.
I respect you, and I respect what you've said in the past. On this issue, we diverge.
Wait, lemme see if I can straighten this out. You think spammers make less money than filesharing companies, you think a quarter million dollars per infringement for a guy who's got potentially thousands of infringements is a small penalty, and you think that companies like Napster and Limewire, whose owners never served jail time or paid fines for their theft, are being treated more harshly than spammers, who are actually going to jail and paying fines in the eight digits?
Slashdot Mirror
- As the previous link makes clear, whether the guy actually read the EULA doesn't actually matter.
- What makes you believe Gateway never gave him the chance? He could have asked the retailer for a copy, called the 1-800 number, read the website, and I suspect if he asked nicely they'd send him a copy for free by mail or email. Don't confuse the inability with the unwillingness to bother; the two are extremely different in court.
Which he did.Er, no he wouldn't. What makes you come to this fantastically unlikely belief?Primarily because it's 100% incorrect, and seems to be entirely derived from the incorrect belief that because someone is liable to a contract they've agreed to, that they're legally assumed to have read it. I'm not sure why you believe a person must read a contract to agree to it; there's no such requirement.Repeating theoretical laws without citation is poison.They won last time. Please stop pretending to understand the law until you have at least a basic familiarity with case precedent.
Don't confuse that consumer goods have different protections than commercial goods with that commercial goods don't need commercial protections. The only reason you don't see it anywhere but computers is because computers are the only commercial goods you personally use. These kinds of clauses are all over shipping trucks, heavy equipment, generators, furnaces, even the gates that open and close parking lots.
Yes, business operated without EULAs for hundreds of years. That doesn't mean that we don't need them now; business has operated without the Internet, wire bank transfers and escrow for hundreds of years too, but if you pulled those, our current system would go straight to Hell.Wow, there's a kind of agreement that isn't an EULA? That must mean that EULAs are pointless! (cough)Nobody's been tricked here.
Ignorance isn't a defense under the law.
The hospital can't turn you away from treatment because you refuse to sign. If you don't speak english, if you can't read, if you're retarded, if you're stunned or mentally altered by drugs, injury or disease, maybe you just can't focus on holding the pen with that railroad spike through your leg. The hospital cannot say no. Therefore, there is no duress.
Back to the university of Matlock for you.
I don't understand why people believe that an EULA is only valid if read before purchase. The dividing line is not having seen the EULA, but rather having the opportunity to see the EULA. It doesn't matter whether you actually did it; only if you had the ability. That EULA was easy as pie to get. It stands.
Sloth almost never a defense under American law; similarly, ignorance only applies when it's not preventable.
I realize it's de rigeur to say "nuh-uh" to things other slashdotters said that sound legally shaky. Thing is, if you don't know the law either, it turns out not to work very well.
S'pose that's why you were AC, though.
Other languages have similar problems. For example, pre-.NET Visual Basic had no serious support for real data structures, nor to client datastructures, meaning the programmers couldn't just implement their own (this has since changed.) Lua has no support for integer mathematics at all, something which can have an enormous impact on the speed of huge stretches of computing. Some languages fundamentally cannot be compiled at all, which does tremendous damage to their speed potential.
Then, you could get into talking to a Fortran/Fortress or Elm/Java or Prolog/Erlang designer about the changes between the two languages whose specific purposes were to enable optimizations for speed. A lot of people who aren't comfortable with the idea of a slow language are, oddly, still comfortable with the idea of a fast language.
In fact, one of the best examples I can give is C++: take a look into what Herb Sutter has to say about the problems caused by keyword export. He makes the surprisingly compelling case for removing the keyword based on a million different things. One of those things is the surprisingly long list of optimizations that compilers can no longer make if we just introduce that one keyword.
That one single keyword can and does make a huge difference in the speed of output binaries in those compilers such as Comeau/EDG and ICC which both implement export and are able to turn support for it off. That's a pretty clear indemnification, in my mind, of that language design cannot impact program speed.
Sure, maybe language design isn't the biggest issue. That doesn't mean it's a non-issue. I highly recommend you consider picking up a radical-difference language like Erlang or Mozart-OZ, and then go back to thinking about language impact on speed. The difference in approach of those two langauges to what you're probably used to is shocking, and can have tremendous impact on the fundamental design and structure of an application.
I'm with you - you and I both disagree strongly with the viewpoint of the person to whom you're responding. However, I suggest that you're oversimplifying the situation, in the zeal to make obvious to this third party what you disagree with, and in some situations the things that I believe you're oversimplifying can become very important.
"Speed isn't everything. Why, if you start with a situation where other problems are choking you, you don't even have to think about speed!" That's called tautology.
By the by, the programming languages you just argued for are ADA, PHP and Visual Basic.NET, whose libraries are enormous in comparison to Java or C#. Now, I do a fair amount of PHP when I'm bored, so don't get up in arms when I say this. That said, I want to point something out: there are very, very few genuinely large scale services written in PHP, C#, Java, ADA, or any of those languages.
When it comes down to it, there are two costs: programmer time and hardware time. If you're network blocked, you buy a bigger network pipe; a dedicated box with a dedicated guaranteed ten megabit unmetered line for a year costs about a week and a half of a programmer's salary.
But, more importantly, you never, ever, EVER get network blocked. That just doesn't happen on engineered systems. The network moves faster than any software you or anyone you know will ever write. Sure, one given pipe might fill; you just upgrade the pipe. It's relatively straightforward to find gigabit, and if you know what you're doing you can go up from there; you have almost certainly never in your life seen a system that can push a gigabit of data. Even just filling static HTTP requests at that speed can bring a heavy duty, well tuned box to its knees. I happen to be friends with a tech at one of the giant shared hosting farms; his company has over 200,000 customers, and it takes them a Quad Athlon to service the average 100 megabit pipe filled with average wordpress blogs.
Now, I'm not saying the richness of the API doesn't matter. I'm just saying that positing a system based on filling the network is a little like designing the heater in the car in case the sun goes out. If you have enough users to fill a pipe, you can afford the next pipe up, or you need to be less retarded in setting your prices. The pipe has nothing to do with your selection of language.
And, frankly, the idea that you have to step away from real languages to get a real API is silly. Or, haven't you ever actually looked through the standard libraries of languages like C++ and Erlang?
If your database is taking a half second to return, you've got incredibly serious problems. And yes, in the real world, a 2ms lag matters because of the queueing problem. Have a look at one of those graphs where a modern stage server like Lightstreamer or YAWS compares itself to Apache. Apache tends to drop off logarithmically. Every time you lag 2ms, that's two more MS of customers you have to deal with during the next query.
This is a limit flow problem, and most people get limit flow problems if you use a toilet as an analogy. Your webserver is similar to a toilet that doesn't have a stopgap. That means the bowl is always slowly filling with usage (ie, not water - say this is a train station) and you have to flush it every so often to keep things clean. The train station was well designed 50 years ago, but as population has gone up, the facilities are feeling the strain.
Now, there's a point at which you say "does it really matter if the toilet takes three minutes to flush, if it's 20 minutes between trains?" Well, actually, yes, because that means each toilet can only service six and two thirds people per train arrival. At home-bound rush hour, you're going to get an enormous line of people outside the bathroom that keeps getting longer and longer.
The problem with Apache is that the longer the line is, the slower the toilet flushes. See the issue now
By definition it is both. It is important to remember that no candidate library may be admitted to C++ if it isn't production ready. The idea that Boost is not meant for production use suggests that you too might do well with a bit of catching up on the ol' intents-and-philosophies set.
Boost isn't there to help you learn. It's there to help you work. If you're still learning, well, then no wonder it scares the hell out of you.
If that's your idea of tools that are there to just show off, then you ain't much of a programmer, kid.Nonsense. I'd ask you to justify that with numbers, but I'm certain you are unable.No it doesn't. By the way, this is the candidate library for the next version of C++, which is only around a year or two off; most compilers implement huge stretches of Boost, and in a year or two, all of them will. That supposed mystery weird syntax is about to become a permanent fundamental part of the language. Sorry, Charlie.Dude, this is the official library for extending the parts of C++ that aren't handled yet, and you're saying it doesn't do anything C++ can't do. Can you look at this list and say C++ already does all this with a straight face?To test the future of C++ before making it permanent. This is something you'd know if you had the first clue about C++ or Boost. Unfortunately, as you've made plain to anyone reading, you don't.
What I find hilarious is that the people you're accusing of intellectual mastErbation are the very people you're silently putting on a pedestal. You talk badly about boost in favor of what C++ can already do, but the very people who created what C++ can already do are the same people creating Boost. Hell, the library was originally created by the C++ Standards Committee Library Working Group, not that I'd expect you to know who that is.Perhaps not intentionally.And yet, you seem still to know nothing about it.
You are rewriting what you said in the attempt to remove the error instead of to admit it. You wanted to believe that nearly everything under the sun was written by, and I quote, "small-time unix developers." Now, you're giving examples that have nothing to do with Unix or small time developers, and building increasingly absurd excuses to continue to call them small-time.
I mean, if you're willing to call a team of 30+ people in the late 1970s a small team, then there's just no such thing as a big team. Those kinds of populations were absolutely unheard of in that era; that's the age where a second programmer wouldn't be warranted unless you were taking on something like an operating system.
Please stop attempting to rewrite what you said. You were wrong. Be an adult and admit the error. The vast bulk of software, protocols, standards, free code and so on out there are written and donated by corporations. I know because I've done the chart that I suggested you do earlier.
Oh, and by the way, doing that chart doesn't count if you fill in origins from memory, because in this conversation you've attributed everything to the people you want to support, and gotten not a single one correct.
Believe it or not, you too can be in error about what happened before you were born.
No, it was a Macintosh. NeXT wasn't yet invented. I know because I bought a first generation NeXTslab, and it came with Mosaic pre-installed. You can call me an idiot all you like, and blame it on my "check your history" comment, but hey, Anonymous Coward, you should check your history too.
Anyone who has to say "you idiot" to make their point has an exceptionally poor control of the language.
This sort of wasting time to try to make other people look bad is specifically why I refuse to hire outside consultants. Pitting one's own workers against one another leads to the most ridiculous, counterproductive and starkly sanctimonious destructive "I'm better than you" driven nonsense...
Klingons don't use weak safety-oriented languages like C++.
GCC got TR1 support two weeks ago. MSVS got it two years ago. Look in stdext:: in MSVS2k5.
You are correct. My apologies.
You might be surprised.
In this case, we're talking about a software development para-organization akin to RAND and Schlumberger, yes. The specific corporation in question is System Development Corporation, most commonly called SDC, and is the organization that did the actual creation of, among other things, email and ARPAnet for the military. The software development team in question was 47 people and they worked on a big-iron mainframe called AN/FSQ-32. The company employed thousands.
Unix was a reactionary movement to big iron (even its name, Unix, was a play on the canonical big iron of the time, Multics.) The development of email was undertaken by a large, well funded professional software development organization operating under the military on big iron hardware. This is about as close to the exact opposite of what you said as possible.
It may come as a surprise to you, but the volume of data produced by large particle colliders requires software development at a pace not seen in most areas. Indeed, the specific reason for the development of HTTP was to accomodate differential update for information, because the network infrastructure required to distribute all materials on a synchronized basis was becoming prohibitive.
Tim Berners-Lee designed the initial spec for the protocol that web servers use. To suggest that he single-handedly created the web is woefully misunderstood, and disposes of the central role that the software developers working with TBL at the time had in the ongoing development of the protocol. TBL himself has repeatedly said that his role in HTTP was relatively minor, and has repeatedly pointed out the similarity of his work to preceding work.
Tim Berners-Lee was working on a Macintosh. Check your history. By the way, this was before Macs were Unix boxes.
Whether you choose to look at HTTP as the result of one man, or the extremely large group (hundreds!) of scientists pitching into the system, again, we're talking about a well funded, well organized group of professionals, and you're either looking at a heterogenous system or a Mac.
Again, not a small group of Unix programmers, no matter how you look at it.
FTP is a college final project from MIT. It is supposedly the end result of almost three years of work, though that's apocryphal and I've never found citation. It isn't a team at all, it's one guy, and again, it predates UNIX. So, again, not a small team of Unix programmers and not a short development.
It strikes me as curious that you're asking me to defend my citation of a mistake you made about something you now admit you know nothing about. Do you not see the problem there? I mean, shouldn't you have to know about it before you start talking about where it started in the first place?
Like I said before, zero for three. I have you friended, and you have me friended, because in the past we have spoken well of one another and have respected one another's opinions. When you had something plain to say to me about my error, I took it on the chin like a man, and admitted my mistake.
I should hope you learn not to speak this way to people. You'll find that in fact, frequently people who cite errors you made to you are, in fact, correct, and found the error because they have a longer history with these works than do you.
Please repair your tone when sp
The Sun Niagara, which has 80 cores, has been on the market for several years now.
On grounds of the systems in Erlang and Mozart-Oz, I disagree strongly that #1 is not appropriate for multicore application development. I cannot imagine an application development environment built around messages that took speed as priority over guaranteed delivery, frankly; that seems to me like building an application on UDP, which would so rarely be a good idea as to seem amazing to me.
I respect you, and I respect what you've said in the past. On this issue, we diverge.
Wait, lemme see if I can straighten this out. You think spammers make less money than filesharing companies, you think a quarter million dollars per infringement for a guy who's got potentially thousands of infringements is a small penalty, and you think that companies like Napster and Limewire, whose owners never served jail time or paid fines for their theft, are being treated more harshly than spammers, who are actually going to jail and paying fines in the eight digits?
One of us is very confused here.