Don't assume people don't know what Linux is just because they aren't in an IT field,
Don't assume that's why I came to the conclusion I did.
It's a safe bet that the averge small claims court judge doesn't know what Linux is. Why do I say that? Because all the people I know who work in the law offices tell me that their judges (and in one case, the judge himself saying this) aren't really aware of things like "operating systems".
If you get a tech-savvy judge, great. But on average, in the current times, don't make any bets.
You conveniently forgot to include the next few sentences.
Two things should be noted about this case. [...] The second thing to note is he didn't ask me what Linux was.
Two conclusions are possible: the judge in question already knew what Linux was. (Doubtful.) Or the judge was simply satisfied that the plantiff had installed something (i.e., not pirated the original software), and that he could name it easily (i.e., didn't pause to invent a name).
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
"Nice try."? I'm completely serious. The issues of GNU extensions versus standard code have come up time and time again, all the way back to the start of the archives. Usually at least one "discussion" avery five or six weeks.
Where "ugly" == "causes surprises for the user and maintainence difficulties for the maintainers, due to lack of forethought in design."
GCC has had a number of features added because they looked cool at the time and the then-maintainers (often RMS himself) didn't consider things like how such extensions could possibly interact with other features. They've been mostly weeded out slowly.
Here's my favorite: Pre-EGCS-fork versions of the GCC manual would encourage coders to not worry about ANSI or ISO C standards, but rather to use as many GNU extensions as they wished, because "it's trivial to simply install GCC." Removing the uglier extensions from GCC has occasionally entailed a fight with RMS, because he feels we shouldn't "slavishly" follow standards such as ISO, ANSI, and POSIX.
That kind of argument does have merit in other arenas, though... for example, POSIX make is so woefully underspecified that restricting the Makefile syntax to only the forms specified by POSIX is impossible for anything but small projects. It simply doesn't scale. Automatic dependency generation, for instance, requires either a form of "#include" for Makefiles, or rules for the Makefile to rewrite itself. So every implementation of "make" has added file inclusion -- but the syntax is different for each one! So sometimes it's easier to just say, screw it, install {GNU,BSD} Make and use their features.
RMS tends to take this viewpoint to a political extreme, but then, he's RMS.
since RMS was behing the original/usr/group that gave birth to POSIX.
Additional trivia: the name "POSIX" itself was suggested by RMS.
Unfortunately, in the years since then, his idea of "portable" seems to have become "don't care about other systems, only write your code for GNU/<kernel>, because then users can always just install the GNU system (and will have to if they want your program)."
...is that you have to have faith in a stochastic process.
Now, I haven't looked at their code, so I don't know what the selection fitness criteria are. Obviously humans play a part in selection for survival; selection for reproduction seems to be completely random -- and that's okay.
But, assuming that the selction mechanism isn't completely asswacked, I feel sure that some "good" poetry will be eventually produced. ("Good" in the eyes of the same people who made the selection choices, of course. If you never vote, you have no place to complain.) Why do I feel this?
Because I have faith in evolutionary programming. It's remarkably good at solving problems with a nonlinear fitness landscape. Finicky local minima, discontinuous fitness evaluation -- all that nasty stuff that kills traditional problem-optimization algorithms, and tends to show up in all the "interesting" problems -- genetic approaches are all over that stuff.
It isn't completely random, of course, and that's the saving grace. That's the part that we have faith in.
Yes, as you say, two good poems interchanged at random snip points will statistically be likely to become bad poems. But bad poems die. (Again, assuming the selection mechanism isn't horked over by a sixth-grader who votes for anything containing the word "boobies" no matter how poor the poetry.) And there will be lots and lots of poems. Most of them will be bad. They die, and over time, eventually, statistically, the good ones gain an edge.
Currently lists over 2300 packages, located right over here, and thankfully has a good search engine, because the "categories" aren't that helpful to me. (YMMV)
The article author didn't say anything about which OSes were being used, so *shrug*.
He will receive no rewards, little contact, no secret knowledge, and he will not see his efforts rewarded within his lifetime. He will just serve, and then die.
I believe that's the same disclaimer that was handed to me when I started volunteering my unpaid time for open source software.
LaTex is a crufty document markup language hacked on top of a very limited language used for page processing.
I almost marked this down as trolling flamebiat, but then got bored and figured, okay, I'll bite.
This is pure uninformed drivel. TeX is an extraordinarily powerful typesetting language. Not "page processing," but complete typesetting. Think books, not webpages.
It isn't very easily extensible, it doesn't really have good style sheet support, and it's remarkably easy to mix presentation and content.
Okay, now that is a good troll. I needed the laugh, thanks!
By taking the same content, and changing the package name ("style sheet" for those whose world ends at the edge of the web browser), I get a journal article instead of a book. Or a set of overhead slides instead of a book. Or <whatever> instead of a book.
It's reaching end of life, and all of the new standards that have come out in the last 20 years have really made it long in the tooth. Unicode, PostScript, XML, Hypertext, and the now-ubiquitous Gui all came to age post-LaTex, and [...]
And they all still suck when compared to LaTeX.
I don't know what flavor crack you have to smoke to say that it's "reaching end of life." I haven't yet found a document-related problem that TeX/LaTeX can't solve, but I've found plenty that make HTML and whatnot just curl up in a whimpering ball. And every time I print a document using LaTeX, my colleagues look at it and say, "DAMN, now I understand why you think Word bites... this is {gorgeous,simple,amazing,powerful}..."
C++ on the other hand can have all the extra stuff it wants and it doesn't affect my project. If I don't wan to use templates or whatever, I don't have to. And the compiler won't force me to include anything.
You're absolutely right. One of C++'s critical strengths is the zero-overhead principle.
The part you're overlooking is this: consider a language with two features. Then, for any given user program, there are four possibilities that the compiler (and thus, the compiler vendors, and thus, the language standard) has to be prepared to handle: the user uses none of them, or A, or B, or both A and B.
It's the last one that gets interesting. Feature A (say. run-time binding) has nothing directly to do with Feature B (say, "pointer to array is same as pointer to single thing", which we got from a different language). But their interaction can be surprising (say, deleting an array of Derived through a pointer-to-Base, which usually causes segfaults if sizeof Derived > sizeof Base).
Now consider a language with three features. Eight possibilities (none, A, B, C, AB, BC, AC, ABC).
Now consider C++. It's not forcing anybody to use features #3, #12, and #57, but if you use them in combination, the result had better be mentioned in the standard. And it had better make sense.
That's why the committee (and the compiler writers) are worried about adding new features to C++. Or any other language. It's not the features themselves that cause problems, it's the surprising ways in which they all interact. As a user of the language, it would behoove you to also be worried, because you could be relying on feature #22 without realizing it, and brand-new feature #107 just shot #22 in the ass.
Most packages, including g++, configure
themselves to run in one location, and they'll get confused if you
move 'em.
Huh? No they don't. Most packages don't give a rat's ass where the binary is located. Historically, GCC was one of the few that did, and recent versions have changed that so that you can move the install tree around.
The remaining few packages that care are mostly just suffering from bad design. Fortunately, as you say, they usually pay attention to environment variables telling them where to look.
Here's a better writeup than what I can fit here, at sunfreeware.com. They've been repackaging open source stuff as Solaris-style pkg files for a long time, so they've good experience with these sorts of questions.
It doesn't matter what the programmer meant. The type of 'i' is Derived. Type inference isn't complicated. The type of the object is whatever the type of the right hand side expression is. Also, type inference isn't terribly useful for OO code. Where pointers to base types are common. However, C++ is a multi-paradigm language, and type inference makes dealing with code that focuses mostly on value types. The STL is very value-type oriented, and if you follow the style it naturally engenders, you'll end up writing code that may not use operator new or polymorphism or inheritence a single type.
You still didn't answer my question: What is the compiler supposed to guess for the blank?
Yes, I agree that type inference is not difficult. I disagree that it's "not terribly useful" for OO code, but that's beside the point.
What should the compiler actually do when faced with the code above?
If your answer is, "print error: type inference may not be used with any kind of inheritance and fail to compile," then say so.:-)
As for the rest of your note, I dont agree with all of it, but I don't disagree with all of it, either. However, this is the first day without thunderstorms we've had here in 10 days, so I'm going outside for as long as I can. Longer responses will have to wait.
EDG are some really smart people, but their comments have since then been disproven.
export in itself (specifically, the idea which export is trying to implement) is a good idea. Where the committee screwed up was mandating its existence without any prior experience.
Keep in mind that the point of an ISO standard is not to require/"legislate" new ideas, but to standardize existing practice. Everything in C++98 had already existed by the time the standard was even close to being done, except export.
Not quite sure what you mean by "allow code-generation at compile time," since that's exactly what template functions allow. Also, C++ is already the only mainstream language which permits execution of semi-arbitrary code during compilation, making it a compile-time Turing machine in addition to a run-time Turing machine (which is what everything else is). Think recursive templates or take a look at the Alexandrescu text, you'll see what I mean.
You probably won't see continuations, but you might see closures. Those tend to destroy performance and can be tricky to implement correctly on oddball hardware. But some changes to the language (relaxations of existing rules, mostly) have already been proposed, specifically to ease the implementation of lambdas.
The existing language already permits things awfully close. Local anonymous classes with static functions, for example, come very close to local functions. Also, check out the Boost lambda library.
Many compilers already support __typeof to do type inference.
As for your "so surprised that languages still make you do stuff like foo i = new foo;", I think you were absent the day the taught "Basics of Object-Oriented Design." Given two classes, Base and Derived, fill in the blank:
____ i = new Derived;
(Hint: no matter what you guess, the programmer really meant "the other one".) Now, how is a compiler supposed to guess, if you can't?
The most popular suggestion, during the original standards process, was: every time someone proposes a new feature, they have to also propose an existing feature to be removed.
The followup suggestion: every time someone proposes a new feature, they have to donate a kidney. This ensures that proposals will be given serious thought, and that a serious idiot can only propose, at worst, two extensions.
No, I'm not joking. Those were some of the suggestions that received rare unanamous agreement.
Seriously, everyone on the committee, from Stroustrup and Koenig on out, agrees that the language is too complicated. They even said so before it was standardized. But...
Let's hear your suggestions on which stuff should be removed. Remember that no matter what you choose, people somewhere are currently using it, and you will break their code. No matter what you change, it will cause incompatabilities, which future generations of/. will then bitch and moan about.
Also, since compiler vendors don't like pissing off their customers, they can't really completely remove stuff even when the standard says it's okay.
Everyone knows the history of C, coming from B, which came from A.
Everyone but you, friend.
The language C was descended from the language B, which was descended from the language BCPL. Dennis Ritchie never decided whether C followed B because it was alphabetical (in which case C++ would have been D), or whether C followed B because it was the next letter in BCPL (in which case C++ would have been P).
As for the C++0x thing, it's quite common to call languages by the year of their standardization, thus "FORTRAN77", "FORTRAN90", "C89", "C99", "C++98". The next cycle for C++ will be completed sometime in the next seven years, but we don't know exactly which year, so "0x".
Either way, it doesn't look too exciting judging from these proposals. It's certainly nothing on the scale of Perl 6 compared to Perl 5, so yeah, maybe I've answered my own question. This is just a routine standards adjustment, rather than a real 'development.'
Again, uh, no. If it doesn't look "exciting," perhaps you're simply looking at the wrong proposals. Or perhaps you simply still think of C++ as "C with more type checking, and those// comments."
The routine standards adjustment came in the form of "TC1", which was just recently published. Basically, "C++98.0.3p4rc2", to put it in Linux terms. Just bugfixes. C++0x is a different story.
(And I don't know that I'd call Perl 6 particularly innovative, either.)
Slashdot Mirror
Yes... I believe I just said that Linux had nothing to do with the judgement. We seem to be in violent agreement here. (Smarty?)
Don't assume that's why I came to the conclusion I did.
It's a safe bet that the averge small claims court judge doesn't know what Linux is. Why do I say that? Because all the people I know who work in the law offices tell me that their judges (and in one case, the judge himself saying this) aren't really aware of things like "operating systems".
If you get a tech-savvy judge, great. But on average, in the current times, don't make any bets.
You conveniently forgot to include the next few sentences.
Two conclusions are possible: the judge in question already knew what Linux was. (Doubtful.) Or the judge was simply satisfied that the plantiff had installed something (i.e., not pirated the original software), and that he could name it easily (i.e., didn't pause to invent a name).
So, don't think Linux is what won here.
One of my favorite Kernighan quotes of all time:
"Nice try."? I'm completely serious. The issues of GNU extensions versus standard code have come up time and time again, all the way back to the start of the archives. Usually at least one "discussion" avery five or six weeks.
http://gcc.gnu.org/ml/gcc/
Where "ugly" == "causes surprises for the user and maintainence difficulties for the maintainers, due to lack of forethought in design."
GCC has had a number of features added because they looked cool at the time and the then-maintainers (often RMS himself) didn't consider things like how such extensions could possibly interact with other features. They've been mostly weeded out slowly.
Here's my favorite: Pre-EGCS-fork versions of the GCC manual would encourage coders to not worry about ANSI or ISO C standards, but rather to use as many GNU extensions as they wished, because "it's trivial to simply install GCC." Removing the uglier extensions from GCC has occasionally entailed a fight with RMS, because he feels we shouldn't "slavishly" follow standards such as ISO, ANSI, and POSIX.
That kind of argument does have merit in other arenas, though... for example, POSIX make is so woefully underspecified that restricting the Makefile syntax to only the forms specified by POSIX is impossible for anything but small projects. It simply doesn't scale. Automatic dependency generation, for instance, requires either a form of "#include" for Makefiles, or rules for the Makefile to rewrite itself. So every implementation of "make" has added file inclusion -- but the syntax is different for each one! So sometimes it's easier to just say, screw it, install {GNU,BSD} Make and use their features.
RMS tends to take this viewpoint to a political extreme, but then, he's RMS.
Additional trivia: the name "POSIX" itself was suggested by RMS.
Unfortunately, in the years since then, his idea of "portable" seems to have become "don't care about other systems, only write your code for GNU/<kernel>, because then users can always just install the GNU system (and will have to if they want your program)."
Some versions would print:
...is that you have to have faith in a stochastic process.
Now, I haven't looked at their code, so I don't know what the selection fitness criteria are. Obviously humans play a part in selection for survival; selection for reproduction seems to be completely random -- and that's okay.
But, assuming that the selction mechanism isn't completely asswacked, I feel sure that some "good" poetry will be eventually produced. ("Good" in the eyes of the same people who made the selection choices, of course. If you never vote, you have no place to complain.) Why do I feel this?
Because I have faith in evolutionary programming. It's remarkably good at solving problems with a nonlinear fitness landscape. Finicky local minima, discontinuous fitness evaluation -- all that nasty stuff that kills traditional problem-optimization algorithms, and tends to show up in all the "interesting" problems -- genetic approaches are all over that stuff. It isn't completely random, of course, and that's the saving grace. That's the part that we have faith in.
Yes, as you say, two good poems interchanged at random snip points will statistically be likely to become bad poems. But bad poems die. (Again, assuming the selection mechanism isn't horked over by a sixth-grader who votes for anything containing the word "boobies" no matter how poor the poetry.) And there will be lots and lots of poems. Most of them will be bad. They die, and over time, eventually, statistically, the good ones gain an edge.
I also work in a USAF research lab. Powdering shredders are cool, but only permitted for low level stuff.
Antimatter.
Currently lists over 2300 packages, located right over here, and thankfully has a good search engine, because the "categories" aren't that helpful to me. (YMMV)
The article author didn't say anything about which OSes were being used, so *shrug*.
Yes, working with Perl is very much like peeling an onion. After five minutes I walk away crying.
Listening to Larry's speeches also leaves me crying, but it's crying with laughter.
I believe that's the same disclaimer that was handed to me when I started volunteering my unpaid time for open source software.
*yawn* *grin* *hack*
I almost marked this down as trolling flamebiat, but then got bored and figured, okay, I'll bite.
This is pure uninformed drivel. TeX is an extraordinarily powerful typesetting language. Not "page processing," but complete typesetting. Think books, not webpages.
Okay, now that is a good troll. I needed the laugh, thanks!
By taking the same content, and changing the package name ("style sheet" for those whose world ends at the edge of the web browser), I get a journal article instead of a book. Or a set of overhead slides instead of a book. Or <whatever> instead of a book.
And they all still suck when compared to LaTeX.
I don't know what flavor crack you have to smoke to say that it's "reaching end of life." I haven't yet found a document-related problem that TeX/LaTeX can't solve, but I've found plenty that make HTML and whatnot just curl up in a whimpering ball. And every time I print a document using LaTeX, my colleagues look at it and say, "DAMN, now I understand why you think Word bites... this is {gorgeous,simple,amazing,powerful}..."
You're absolutely right. One of C++'s critical strengths is the zero-overhead principle.
The part you're overlooking is this: consider a language with two features. Then, for any given user program, there are four possibilities that the compiler (and thus, the compiler vendors, and thus, the language standard) has to be prepared to handle: the user uses none of them, or A, or B, or both A and B.
It's the last one that gets interesting. Feature A (say. run-time binding) has nothing directly to do with Feature B (say, "pointer to array is same as pointer to single thing", which we got from a different language). But their interaction can be surprising (say, deleting an array of Derived through a pointer-to-Base, which usually causes segfaults if sizeof Derived > sizeof Base).
Now consider a language with three features. Eight possibilities (none, A, B, C, AB, BC, AC, ABC).
Now consider C++. It's not forcing anybody to use features #3, #12, and #57, but if you use them in combination, the result had better be mentioned in the standard. And it had better make sense.
That's why the committee (and the compiler writers) are worried about adding new features to C++. Or any other language. It's not the features themselves that cause problems, it's the surprising ways in which they all interact. As a user of the language, it would behoove you to also be worried, because you could be relying on feature #22 without realizing it, and brand-new feature #107 just shot #22 in the ass.
Huh? No they don't. Most packages don't give a rat's ass where the binary is located. Historically, GCC was one of the few that did, and recent versions have changed that so that you can move the install tree around.
The remaining few packages that care are mostly just suffering from bad design. Fortunately, as you say, they usually pay attention to environment variables telling them where to look.
Here's a better writeup than what I can fit here, at sunfreeware.com. They've been repackaging open source stuff as Solaris-style pkg files for a long time, so they've good experience with these sorts of questions.
You still didn't answer my question: What is the compiler supposed to guess for the blank?
Yes, I agree that type inference is not difficult. I disagree that it's "not terribly useful" for OO code, but that's beside the point. What should the compiler actually do when faced with the code above?
If your answer is, "print error: type inference may not be used with any kind of inheritance and fail to compile," then say so. :-)
As for the rest of your note, I dont agree with all of it, but I don't disagree with all of it, either. However, this is the first day without thunderstorms we've had here in 10 days, so I'm going outside for as long as I can. Longer responses will have to wait.
EDG are some really smart people, but their comments have since then been disproven.
export in itself (specifically, the idea which export is trying to implement) is a good idea. Where the committee screwed up was mandating its existence without any prior experience.
Keep in mind that the point of an ISO standard is not to require/"legislate" new ideas, but to standardize existing practice. Everything in C++98 had already existed by the time the standard was even close to being done, except export.
Point by point, then.
Not quite sure what you mean by "allow code-generation at compile time," since that's exactly what template functions allow. Also, C++ is already the only mainstream language which permits execution of semi-arbitrary code during compilation, making it a compile-time Turing machine in addition to a run-time Turing machine (which is what everything else is). Think recursive templates or take a look at the Alexandrescu text, you'll see what I mean.
You probably won't see continuations, but you might see closures. Those tend to destroy performance and can be tricky to implement correctly on oddball hardware. But some changes to the language (relaxations of existing rules, mostly) have already been proposed, specifically to ease the implementation of lambdas.
The existing language already permits things awfully close. Local anonymous classes with static functions, for example, come very close to local functions. Also, check out the Boost lambda library.
Many compilers already support __typeof to do type inference.
(Hint: no matter what you guess, the programmer really meant "the other one".) Now, how is a compiler supposed to guess, if you can't?As for your "so surprised that languages still make you do stuff like foo i = new foo;", I think you were absent the day the taught "Basics of Object-Oriented Design." Given two classes, Base and Derived, fill in the blank:
The most popular suggestion, during the original standards process, was: every time someone proposes a new feature, they have to also propose an existing feature to be removed.
The followup suggestion: every time someone proposes a new feature, they have to donate a kidney. This ensures that proposals will be given serious thought, and that a serious idiot can only propose, at worst, two extensions.
No, I'm not joking. Those were some of the suggestions that received rare unanamous agreement.
Seriously, everyone on the committee, from Stroustrup and Koenig on out, agrees that the language is too complicated. They even said so before it was standardized. But...
Let's hear your suggestions on which stuff should be removed. Remember that no matter what you choose, people somewhere are currently using it, and you will break their code. No matter what you change, it will cause incompatabilities, which future generations of /. will then bitch and moan about.
Also, since compiler vendors don't like pissing off their customers, they can't really completely remove stuff even when the standard says it's okay.
Everyone but you, friend.
The language C was descended from the language B, which was descended from the language BCPL. Dennis Ritchie never decided whether C followed B because it was alphabetical (in which case C++ would have been D), or whether C followed B because it was the next letter in BCPL (in which case C++ would have been P).
As for the C++0x thing, it's quite common to call languages by the year of their standardization, thus "FORTRAN77", "FORTRAN90", "C89", "C99", "C++98". The next cycle for C++ will be completed sometime in the next seven years, but we don't know exactly which year, so "0x".
Again, uh, no. If it doesn't look "exciting," perhaps you're simply looking at the wrong proposals. Or perhaps you simply still think of C++ as "C with more type checking, and those // comments."
The routine standards adjustment came in the form of "TC1", which was just recently published. Basically, "C++98.0.3p4rc2", to put it in Linux terms. Just bugfixes. C++0x is a different story.
(And I don't know that I'd call Perl 6 particularly innovative, either.)
Read the fucking article. The first page and half talks specifically about storage growth versus access growth.
On the other hand, that fucking paperclip seems to do whatever the fuck it wants.