I don't think the RISC/CISC comparison really matters (though I'd expect a lot of specialized, non-orthogonal instructions, CISC-style). The main difference is that graphics chips can have very deep pipelines because the branching involved in rendering is more "handleable" and is a very small part of what it has to do when compared to the raw computation that goes on.
For those heavily into graphics and games, using a GPU as a CPU (or a CPU as a GPU) might not be all that good a solution,
as the GPU is a specialised bit of silicon whereas the CPU is a general piece of silicon.
And your solution is...
..one or more CPU(s) can be assigned to work as the GPU(s) if needed..
Does that even make sense?
How is this different from just having a quad-pentium system? Operating systems already support this. If you have a lot of graphics computing to do, then naturally, your processors will end up doing more graphics processing. Superscalar processors already do better than this ("HyperThreading" included).
Unless, of course, you have come up with a way to morph the silicon of a general-purpose CPU to transform it into a processor with a specialized graphics pipeline (kinda like T-1000). In that case, you are a genius.
Why not just double it to 256-bits so that every atom in our galaxy can have 100 million addresses?
The parent poster is simply trying to be reasonable, though I'm not sure I would agree that 183 per person is enough. It would be nice to have more addresses so that you can organize things heirarchically (lots of addresses will get lost here). Also, NAT is a hack to get around the 32-bit limit so I wouldn't want to have to rely on it again. But I think that 64-bits is more than enough to handle our needs for a very long time. 64-bits isn't really that hard to type in either (xxxx.xxxx.xxxx.xxxx).
calling OS X new and original is a load of crap. It's new to the Mac hardware, but it's all old ideas.
So, everything old is therefore bad...[snip irrelevant rant]
That is possibly one of the stupidest inferences I have ever seen. It's seems almost like you picked that misguided interpretation simply because you happened to have an argument prepared.
Well, he was being consistent in that he didn't consider the library to really be part of a lanugage. Aside from generics and assertions, the changes you've listed aren't really changes to the language.
I think that Sun is considering some other additions such as automatic boxing and unboxing and enumerated data types (probably just because C# has them).
The JVM (which is the component that sets a kind of limit on what Java can do efficiently) does allow for some expansion.
I don't think the JVM necessarily needs to be modified to support boxing/unboxing and generics since other projects that support such features have been able to produce regular Java bytecode. I'd love to see closures and I don't think even those require and changes to the JVM.
Even so, a very fundamental part of the language is the type system and I don't think that this has changed much. Java's type semantics (tied closely to the JVM's inner workings) is kind of rigid and while it may seem fine now now, I don't "feel" that it is the language to end all languages.
By the way, you didn't mention (separately, at least) my favorite addition to the Java libraries: collection classes (in 1.2).
I do not have any experience with Swing... [ but I decided to shoot my mouth off anyway. ]
The problem with what you are saying is that the original post had assumed some context, namely knowledge of Swing or even UI programming in general.
I like simple solutions why should I use not-so-simple solutions?
Because simple solutions aren't always the most efficient. If you had a 32-processor machine, you could write your application the simple way, using only one thread and leave 31 processors to idle. The not-so-simple way to do this would be to write a threaded application which would take better advantage of the machine's resources. Now are you going to blame the hardware or the OS for not automatically running your single thread on 32 processors? Well, maybe you might, but it is pretty unreasonable to do so. Though in an ideal world, the simplest way would be the best way, this is probably impossible (unless you think quicksort/mergesort/heapsort are the simplests ways to sort a list).
I think most GUI toolkits suggest that you don't hold up the event loop. This is a standard model. If you want to do something that takes a while, some toolkits suggest using an idle function to incrementally do the things you need to do. This is slightly harder because you have to manually split up the algorithm. Swing makes this easier by levaraging Java's simple thread API to let you do background processing with minimal pain.
If most people 'don't get' UI Delegates I would think that UI delegates are poorly designed and/or documentation is vague.
First of all, UI delegates are present (in one form or the other) in many UI toolkits.
The reason it may appear that "too many" (he didn't say "most") people find certain features of Swing hard to use may have to do with the fact that Java is just really easy to use. The Swing API is simpler than many other toolkits and it's not difficult to get started so there's a lower barrier to entry. The people who have problems with writing good Swing code are probably the same people who would have problems with GTK or Win32 (and definitely Xaw). The reason that "bad programmers" seem to be Swing's weakness is possibly that inexperienced programmers are drawn to Swing (because Java in general is more forgiving).
New features are necessarily not backwards compatible.
I guess my choice of words was poor. What I intended to say was that I thought the new Python features/changes made old code behave differently.
That's why, I believe, some Python applications ask that you use an older version of Python. Again, I'm not saying that this is necessarily bad, but the original poster seemed to claim that newer Python runtimes are completely backward compatible in every way.
...Python runs circles around it when it comes to backwards-compatability...
Really? I thought that all the new features were not backwards compatible. I'm not fanatical about strict backwards compatibility, but it seems like the Python developers aren't either. I've noticed that Debian keeps a python1.5 packages and that some applications require this older version.
Well...HTML is mostly 7-bit ASCII. So the high bit could be thrown away resulting in a 1/7 compression ratio, partially lossless.
You should probably say 7/8 compression ratio. Saying 1/7 is probably one of the most misleading ways to say it. In the end, however, using that "compression scheme" is kind of pointless since:
Huffman encoding is better.
Lots of servers and browsers support compressed streams anyway (zlib-style, I believe), which is even better than plain Huffman.
I came across a simpler example of this (I think) when I tried to write a C parser. Take the following code:
f ( g );
This can mean one of two (or possibly more) things:
An invocation of function 'f' with parameter 'g'. OR
A declaration of the variable 'g' of type 'f'.
The meaning depends on what 'f' represents. If 'f' is a type, then it is a variable declaration. Otherwise, it is a function call. I think this is what makes C impossible to parse with a plain context-free grammar. You need to do some weird stuff in your YACC production rules to get the proper result.
As far as I can tell, it's really a silly thing that could have easily been avoided by changing the pointer syntax a little. As a matter of fact, I think that the thing causing problems is the way pointer-type variables are declared (Java doesn't have this issue). I guess the reason the problem exists is that the original parser was hand-written and so the Bell Labs guys didn't bother with the computational-theory side of things.
A predictive bottom-up LR parser is more powerful than top-down LL.
In terms of grammars alone, I believe that is somewhat correct but we're talking about a compiler here. LL parsing is often helpful because it can create and use inherited attributes. A top-down parser can perform some of the semantic work that an LR bottom-up parser cannot.
I also don't think that the recursive call stack should be of much concern because GCC will probably do something like that anyway (though maybe not as fine grained) in the next compiler pass. As said before, it might actually reduce the amount of work.
What do you mean by 'huge memory requirements (non-deterministic)'? Yes, an LL parser will maintain a deeper stack but the memory usage is by no means unbounded.
I don't know how you can classify changing GCC's internal structure as 'feature-creep'. LL grammars are usually considered easier to read/understand and despite what some wannabe-macho programmers may think, readability/clarity is good. It is also easier to write meaningful error messages because an LL parser kind of models the way we naturally think.
Now I'm not saying that LL parsers are better. The workings of LR grammars are extremely interesting (Knuth is a god). However, don't knock it for no reason at all (stick to 2.95? gimme a break). I'm sure the GCC guys know more than both of us about compiler design and have good reasons for their design decisions.
As for properly indented code, using <pre> and <tt> tags does wonders...
That's what I normally use, but Slashdot doesn't seem to allow the <pre> tag. Now I see that there is a 'Code' posting option but that effectively puts the whole comment within <pre> and <tt> tags. How exactly do you do it?
Also not sure about the intrinsic thing in Phobos - isn't it the job of the compiler to spot processor specific optimisations and apply them in a transparent manner?
It still is transparent. You don't have to do anything processor specific. 'intrinsic' is just essentially a namespace for certain functions that are good candidates for manual optimization. As is especially the case with CISC instruction sets, there are often very specific instructions that will do what you want but that the compiler isn't smart enough to make use of.
IfStatement:
if ( Expression ) BlockStatement
if ( Expression ) BlockStatement else BlockStatement
as a rule for IfStatements would avoid a lot of error cases. Not even mentioning the fact it would solve the "which else?" ambiguity.
Your grammar doesn't allow for the if-else-if-else-if-else chain. A special case could be made for this but I don't see a reason to because enforcing BlockStatement seems unnecessary anyway.
I think a better solution would be in the next compiler pass instead of in the parser. The compiler could ensure that the code triggered by the 'if' has a side-effect (or could have a side-effect). This will probably produce better error messages as well.
I have also sometimes thought that '0o' should be used as the octal prefix. Though I've never made the mistake of prepending a zero to a decimal value, it seems a little more uniform to use '0o'. I am also interested in what reason Burton has in mind.
By the way, how do you include properly-indented code in a Slashdot post?
Now, I'm walking a semantic line here, because you can presumably do all that by writing header files, includes, classes, etc. that contain new logic within the structure of the language. But what I mean is a language that by its nature is abstracted and modular, even to the point where the syntax of, say, control structures could be modified in a module?
I am interested in exactly this. It would be nice if regular expressions were simple a syntactical plugin to the language. Extensions could make it easier to specify things that don't quite fit the existing function/expression syntax.
So far, the only example of this I have found is Perl. Though I'm not sure exactly how it is done, I believe that the interpreter just delegates control to a custom parser. The Perl 'Switch' statement is/was implemented this way. You may also have heard of the extension that lets you (kind of) code Perl using Latin (written by the same guy).
- An extra keyword is needed to specify a constructor. Whoop-dee-doo, *that* will certainly gain us a 10% productivity gain!
- The baseclass constructor can now be called from any point within the child constructor - or presumably, not at all. I'm not sure what prompted this odd notion, but I can see a new class of bug here: forgetting to call the baseclass constructor.
I don't think he claimed that using 'this' to specify a constructor would increase productivity. That said, I like the feature.
Firstly, it doesn't add any extra keywords. The 'this' keyword is already used to call other constructors within a constructor. Also, I think it is slightly more orthogonal than using the class name. While using the class name makes it mesh better with the 'new ClassName()' instantiation expression, using 'this' matches the syntax used to call alternate constructors from within a constructor.
A real tangible advantage of using 'this' is that it doesn't rely on the class name. If you end up changing the class name (something I find myself doing often), you don't have to worry about about changing all the constructor calls (superclasses included).
Being allowed to call the superclass constructor anywhere in the constructor is definitely a good thing. Since calling the superclass constructor is essential, I'm sure the compiler will insert it in there for you if you don't explicitly do so (this is how it works in Java).
Requiring the superclass constructor call to be at the top is really a pain-in-the-ass restriction. Sometimes, you will want to do some calculations on what parameters to pass to the superclass constructor.
In Java, for example, the following code cause a compiler error:
class ErrorMessage { ErrorMessage(String message) { ... } }
class MyError extends ErrorMessage { static String MESSAGES[] = { "file not found", "blah",... }<br>
Even though the code before the 'super(...)' call doesn't touch any instance variables, it is still not allowed. The dumb thing is that you can actually achieve the desired result with the following constructor code:
In this situation, the second example's code may or may not actually be more stylistically pleasing, but I'm often stuck in situations where I have to create these truely monster expressions. Sometimes, it is simple impossible to create an equivalent expression because of the imperative nature of what has to be done (resorting instead to creating external functions just so I can fit it all into a single expression).
Sorry about the unreadable formatting. Couldn't figure out how to post code on Slashdot. I tried nesting <blockquote> tags but encountered the junk filter. I didn't try characters but assumed that they would aggravate the filter even more than the <blockquote> tags.
Um, no. He's caching the result of a combination of both calls, which will take longer than either one separately. It would stupid to only cache the glGetString().
I re-read my post. It does suffer from severe ad hominem. Unsubstantiated ad hominem at that. Sorry (I think it was the "taking away minutes of my life" that really got to me).
Ok, I agree that advertisers are aware that they are "taking a chance" and their commercials might be ignored or might be the victim of regular channel flipping. And, in principle, something like Replay TV just further reduces the chances that a given commercial is watched. However, I don't think that the current system can tolerate a device like that. It's not completely black and white; degree does matter. I'm not saying that it is or isn't illegal (since, as you said, no contract has been signed), but it seems like it just wouldn't work.
Of course not all marketing is directed towards everyone. Advertisers of baby food probably don't really care whether you watch their commercials or not. But a system that lets you skip commercials that you "don't want to see" is hard. Do you enter your sex, age and ethnicity into a government-controlled set-top box which then lets different commercials through -- depending on which person's electronic wristband signals it picks up? A PVR, as far as I know, allows you to skip all commercials. Unless there is some metadata that comes along with the video feed that says what type of commercial it is, I don't think we currently have the signal-analysis knowhow to figure out who it is targeting (ironically, metadata could just make for easier and more reliable commercial-skipping).
In your newspaper analogy, a PVR is like a device that blanks out all newspaper advertisments before giving it to you. It's actually almost like reformatting the whole newspaper so you can barely tell that advertisments were there in the first place. Newspaper advertisers are aware of the differences in impact a TV commercial has (since it's more modal) but that system has been working fine for years). Hmm...I wonder (really, no sarcasm here) how much newspapers would cost if there were no advertisements.
If there were no commercials, the amount you pay for cable/satellite could go up. The amount you currently pay isn't necessarily enough to cover the cable channel's total costs.
If, however, a television channel did not contain advertisements (or monthly begging-for-money sessions) then you can probably assume that the money you pay covers their expenses and that you are free to do what you want.
If you are saying that I am stealing from advertisers by not watching commercials, I say commercials are stealing from me by taking away minutes of my life. They should pay me to watch their crap.
You are mentally disabled, right?
They, indirectly, are paying you. In the end, you receive entertainment, but that entertainment is paid for by advertising money. I'm afraid your precious Friends characters do not do it for free.
Oh wait...you're right, we should have government sponsored programming. That's right...forget the marketplace, let's let old white people decide what we want to watch. For Mother Amerika!
As I said in my post, I can think of only one reason for why using Free Software in schools is bad: if the whole idea of Free Software itself is bad to the core.
I now see how the "GNU discount" may be a misleading. But whether it is a "trick" or not depends on whether the FSF is really pushing for socialism or if they are simply deluded. Just curious...I haven't really thought about the politics of it but do you have a similar argument against BSD-style licensing?
Obviously, learning concepts is more important than learning the specifics of a certain piece of software. However, I think that initially, students who have little prior experience with using computers will be hindered when faced with different applications every time.
It may be counter-productive to force a person to use different environments all the time. For example, if different code editors were present on different machines, it may be harder to get used to and will just stand in the way of writing code. I constantly type "ls" into the Windows DOS box and have resorted to making a batch file called "ls.bat" that runs "dir". I also hate the fact that the campus Sun machines have keyboards with backspace key one row lower than it is on most PC keyboards. It just gets in the way.
That said, I have found that the government computer syllabus does teach the use of a particular software. In Tamil Nadu (a southern state), the CS textbooks really, really stink. Aside from the many errors, they contain totally useless sections that read like propoganda straight from the Microsoft Press or from a Sun approved publication. They also have totally software-specific stuff like how to change your background wallpaper in Windows 98 and which menu headers and footers are under in Word and the worst of it is that students are tested on this crap. Oh yeah, all that is part of the high school "Computer Science" curriculum. While they do teach programming, they approach it with the concept "first we'll teach C, then Java, then Visual Basic" because how many languages you "know" is easier to quantify than how well you know how to program. After they "learn" C, the Java book starts from the very beginning again with loops, case statements and all, totally ignoring the fact that students should already know that from C.
The Central (see Federal) government's CS syllabus is much better but just the fact that the State board of education's syllabus is crap shows the current mentality of some of the decision makers. It's all about the buzz words ("I know Oracle,.NET and EJB"). Intel and Microsoft really have a stranglehold on the average Indian consumer (Intel's "our chip makes the internet, digital video editing and everything else better and easier" advertising is rampant). The situation could be very different in Kerala but I wouldn't bet on it. After all, that letter was from some Free Software Users Group.
1. If MSFT giving away some software is a "marketing trick", how much more of a marketing trick is it when the Free Software advocates give away an entire OS and suite of applications?
The Microsoft discount is a marketing trick. They are betting on the fact a person will not look at the long term effects. Initially, the free copy of Office is enticing, but later on he will realize that he is too used to Microsoft software and resigns to start paying through his ass for licenses.
With free software, users are offered what they will always be offered: software free of charge (among other things).
2. Why does the government have to standardize on one set of applications and an OS? At the school I went to, we had MS PCs, Sun clusters, Macintoshes, mainframes, and probably some research machines running obscure stuff that I've never even heard of. An educational system should expose students to what they will see in the real world.
I think that the target is around 10-20 computers per school. Do you think that having 15 computers running 5 significantly different sets of software is useful in grade school? How about 15 computers running 3 different sets of software? Do you not think that there should be a standard? Should different versions of textbooks be written and published to accomodate the 10 different systems?
What it boils down to is that, even if students initially get used to one particular set of free software applications, getting hooked on a free software application doesn't cause as much harm as getting hooked on proprietary application. Hmm...what exactly is the danger of getting hooked on free software? (Aside from "free software is communist and is a bad thing for all of humanity").
Slashdot Mirror
I don't think the RISC/CISC comparison really matters (though I'd expect a lot of specialized, non-orthogonal instructions, CISC-style). The main difference is that graphics chips can have very deep pipelines because the branching involved in rendering is more "handleable" and is a very small part of what it has to do when compared to the raw computation that goes on.
And your solution is...
Does that even make sense?
How is this different from just having a quad-pentium system? Operating systems already support this. If you have a lot of graphics computing to do, then naturally, your processors will end up doing more graphics processing. Superscalar processors already do better than this ("HyperThreading" included).
Unless, of course, you have come up with a way to morph the silicon of a general-purpose CPU to transform it into a processor with a specialized graphics pipeline (kinda like T-1000). In that case, you are a genius.
You have to be reasonable though...
Why not just double it to 256-bits so that every atom in our galaxy can have 100 million addresses?
The parent poster is simply trying to be reasonable, though I'm not sure I would agree that 183 per person is enough. It would be nice to have more addresses so that you can organize things heirarchically (lots of addresses will get lost here). Also, NAT is a hack to get around the 32-bit limit so I wouldn't want to have to rely on it again. But I think that 64-bits is more than enough to handle our needs for a very long time. 64-bits isn't really that hard to type in either (xxxx.xxxx.xxxx.xxxx).
That is possibly one of the stupidest inferences I have ever seen. It's seems almost like you picked that misguided interpretation simply because you happened to have an argument prepared.
Well, he was being consistent in that he didn't consider the library to really be part of a lanugage. Aside from generics and assertions, the changes you've listed aren't really changes to the language. I think that Sun is considering some other additions such as automatic boxing and unboxing and enumerated data types (probably just because C# has them).
The JVM (which is the component that sets a kind of limit on what Java can do efficiently) does allow for some expansion. I don't think the JVM necessarily needs to be modified to support boxing/unboxing and generics since other projects that support such features have been able to produce regular Java bytecode. I'd love to see closures and I don't think even those require and changes to the JVM.
Even so, a very fundamental part of the language is the type system and I don't think that this has changed much. Java's type semantics (tied closely to the JVM's inner workings) is kind of rigid and while it may seem fine now now, I don't "feel" that it is the language to end all languages.
By the way, you didn't mention (separately, at least) my favorite addition to the Java libraries: collection classes (in 1.2).
Geez. Look at the very first line:
The problem with what you are saying is that the original post had assumed some context, namely knowledge of Swing or even UI programming in general.
Because simple solutions aren't always the most efficient. If you had a 32-processor machine, you could write your application the simple way, using only one thread and leave 31 processors to idle. The not-so-simple way to do this would be to write a threaded application which would take better advantage of the machine's resources. Now are you going to blame the hardware or the OS for not automatically running your single thread on 32 processors? Well, maybe you might, but it is pretty unreasonable to do so. Though in an ideal world, the simplest way would be the best way, this is probably impossible (unless you think quicksort/mergesort/heapsort are the simplests ways to sort a list).
I think most GUI toolkits suggest that you don't hold up the event loop. This is a standard model. If you want to do something that takes a while, some toolkits suggest using an idle function to incrementally do the things you need to do. This is slightly harder because you have to manually split up the algorithm. Swing makes this easier by levaraging Java's simple thread API to let you do background processing with minimal pain.
First of all, UI delegates are present (in one form or the other) in many UI toolkits.
The reason it may appear that "too many" (he didn't say "most") people find certain features of Swing hard to use may have to do with the fact that Java is just really easy to use. The Swing API is simpler than many other toolkits and it's not difficult to get started so there's a lower barrier to entry. The people who have problems with writing good Swing code are probably the same people who would have problems with GTK or Win32 (and definitely Xaw). The reason that "bad programmers" seem to be Swing's weakness is possibly that inexperienced programmers are drawn to Swing (because Java in general is more forgiving).
To be fair, he wasn't really assuming that. He statement is clearly a conditional one.
I guess my choice of words was poor. What I intended to say was that I thought the new Python features/changes made old code behave differently.
That's why, I believe, some Python applications ask that you use an older version of Python. Again, I'm not saying that this is necessarily bad, but the original poster seemed to claim that newer Python runtimes are completely backward compatible in every way.
Really? I thought that all the new features were not backwards compatible. I'm not fanatical about strict backwards compatibility, but it seems like the Python developers aren't either. I've noticed that Debian keeps a python1.5 packages and that some applications require this older version.
You should probably say 7/8 compression ratio. Saying 1/7 is probably one of the most misleading ways to say it. In the end, however, using that "compression scheme" is kind of pointless since:
I came across a simpler example of this (I think) when I tried to write a C parser. Take the following code:
This can mean one of two (or possibly more) things:
The meaning depends on what 'f' represents. If 'f' is a type, then it is a variable declaration. Otherwise, it is a function call. I think this is what makes C impossible to parse with a plain context-free grammar. You need to do some weird stuff in your YACC production rules to get the proper result.
As far as I can tell, it's really a silly thing that could have easily been avoided by changing the pointer syntax a little. As a matter of fact, I think that the thing causing problems is the way pointer-type variables are declared (Java doesn't have this issue). I guess the reason the problem exists is that the original parser was hand-written and so the Bell Labs guys didn't bother with the computational-theory side of things.
In terms of grammars alone, I believe that is somewhat correct but we're talking about a compiler here. LL parsing is often helpful because it can create and use inherited attributes. A top-down parser can perform some of the semantic work that an LR bottom-up parser cannot.
I also don't think that the recursive call stack should be of much concern because GCC will probably do something like that anyway (though maybe not as fine grained) in the next compiler pass. As said before, it might actually reduce the amount of work.
What do you mean by 'huge memory requirements (non-deterministic)'? Yes, an LL parser will maintain a deeper stack but the memory usage is by no means unbounded.
I don't know how you can classify changing GCC's internal structure as 'feature-creep'. LL grammars are usually considered easier to read/understand and despite what some wannabe-macho programmers may think, readability/clarity is good. It is also easier to write meaningful error messages because an LL parser kind of models the way we naturally think.
Now I'm not saying that LL parsers are better. The workings of LR grammars are extremely interesting (Knuth is a god). However, don't knock it for no reason at all (stick to 2.95? gimme a break). I'm sure the GCC guys know more than both of us about compiler design and have good reasons for their design decisions.
That's what I normally use, but Slashdot doesn't seem to allow the <pre> tag. Now I see that there is a 'Code' posting option but that effectively puts the whole comment within <pre> and <tt> tags. How exactly do you do it?
It still is transparent. You don't have to do anything processor specific. 'intrinsic' is just essentially a namespace for certain functions that are good candidates for manual optimization. As is especially the case with CISC instruction sets, there are often very specific instructions that will do what you want but that the compiler isn't smart enough to make use of.
Your grammar doesn't allow for the if-else-if-else-if-else chain. A special case could be made for this but I don't see a reason to because enforcing BlockStatement seems unnecessary anyway.
I think a better solution would be in the next compiler pass instead of in the parser. The compiler could ensure that the code triggered by the 'if' has a side-effect (or could have a side-effect). This will probably produce better error messages as well.
I have also sometimes thought that '0o' should be used as the octal prefix. Though I've never made the mistake of prepending a zero to a decimal value, it seems a little more uniform to use '0o'. I am also interested in what reason Burton has in mind.
By the way, how do you include properly-indented code in a Slashdot post?
I am interested in exactly this. It would be nice if regular expressions were simple a syntactical plugin to the language. Extensions could make it easier to specify things that don't quite fit the existing function/expression syntax.
So far, the only example of this I have found is Perl. Though I'm not sure exactly how it is done, I believe that the interpreter just delegates control to a custom parser. The Perl 'Switch' statement is/was implemented this way. You may also have heard of the extension that lets you (kind of) code Perl using Latin (written by the same guy).
I don't think he claimed that using 'this' to specify a constructor would increase productivity. That said, I like the feature.
Firstly, it doesn't add any extra keywords. The 'this' keyword is already used to call other constructors within a constructor. Also, I think it is slightly more orthogonal than using the class name. While using the class name makes it mesh better with the 'new ClassName()' instantiation expression, using 'this' matches the syntax used to call alternate constructors from within a constructor.
A real tangible advantage of using 'this' is that it doesn't rely on the class name. If you end up changing the class name (something I find myself doing often), you don't have to worry about about changing all the constructor calls (superclasses included).
Being allowed to call the superclass constructor anywhere in the constructor is definitely a good thing. Since calling the superclass constructor is essential, I'm sure the compiler will insert it in there for you if you don't explicitly do so (this is how it works in Java).
Requiring the superclass constructor call to be at the top is really a pain-in-the-ass restriction. Sometimes, you will want to do some calculations on what parameters to pass to the superclass constructor. In Java, for example, the following code cause a compiler error:
Even though the code before the 'super(...)' call doesn't touch any instance variables, it is still not allowed. The dumb thing is that you can actually achieve the desired result with the following constructor code:
In this situation, the second example's code may or may not actually be more stylistically pleasing, but I'm often stuck in situations where I have to create these truely monster expressions. Sometimes, it is simple impossible to create an equivalent expression because of the imperative nature of what has to be done (resorting instead to creating external functions just so I can fit it all into a single expression).
Sorry about the unreadable formatting. Couldn't figure out how to post code on Slashdot. I tried nesting <blockquote> tags but encountered the junk filter. I didn't try characters but assumed that they would aggravate the filter even more than the <blockquote> tags.
Um, no. He's caching the result of a combination of both calls, which will take longer than either one separately. It would stupid to only cache the glGetString().
I re-read my post. It does suffer from severe ad hominem. Unsubstantiated ad hominem at that. Sorry (I think it was the "taking away minutes of my life" that really got to me).
Ok, I agree that advertisers are aware that they are "taking a chance" and their commercials might be ignored or might be the victim of regular channel flipping. And, in principle, something like Replay TV just further reduces the chances that a given commercial is watched. However, I don't think that the current system can tolerate a device like that. It's not completely black and white; degree does matter. I'm not saying that it is or isn't illegal (since, as you said, no contract has been signed), but it seems like it just wouldn't work.
Of course not all marketing is directed towards everyone. Advertisers of baby food probably don't really care whether you watch their commercials or not. But a system that lets you skip commercials that you "don't want to see" is hard. Do you enter your sex, age and ethnicity into a government-controlled set-top box which then lets different commercials through -- depending on which person's electronic wristband signals it picks up? A PVR, as far as I know, allows you to skip all commercials. Unless there is some metadata that comes along with the video feed that says what type of commercial it is, I don't think we currently have the signal-analysis knowhow to figure out who it is targeting (ironically, metadata could just make for easier and more reliable commercial-skipping).
In your newspaper analogy, a PVR is like a device that blanks out all newspaper advertisments before giving it to you. It's actually almost like reformatting the whole newspaper so you can barely tell that advertisments were there in the first place. Newspaper advertisers are aware of the differences in impact a TV commercial has (since it's more modal) but that system has been working fine for years). Hmm...I wonder (really, no sarcasm here) how much newspapers would cost if there were no advertisements.
If there were no commercials, the amount you pay for cable/satellite could go up. The amount you currently pay isn't necessarily enough to cover the cable channel's total costs.
If, however, a television channel did not contain advertisements (or monthly begging-for-money sessions) then you can probably assume that the money you pay covers their expenses and that you are free to do what you want.
Misspelling "Wil" is no big deal, but incorrect nitpicking is truely pathetic.
You are mentally disabled, right?
They, indirectly, are paying you. In the end, you receive entertainment, but that entertainment is paid for by advertising money. I'm afraid your precious Friends characters do not do it for free.
Oh wait...you're right, we should have government sponsored programming. That's right...forget the marketplace, let's let old white people decide what we want to watch. For Mother Amerika!
As I said in my post, I can think of only one reason for why using Free Software in schools is bad: if the whole idea of Free Software itself is bad to the core.
I now see how the "GNU discount" may be a misleading. But whether it is a "trick" or not depends on whether the FSF is really pushing for socialism or if they are simply deluded. Just curious...I haven't really thought about the politics of it but do you have a similar argument against BSD-style licensing?
Obviously, learning concepts is more important than learning the specifics of a certain piece of software. However, I think that initially, students who have little prior experience with using computers will be hindered when faced with different applications every time.
It may be counter-productive to force a person to use different environments all the time. For example, if different code editors were present on different machines, it may be harder to get used to and will just stand in the way of writing code. I constantly type "ls" into the Windows DOS box and have resorted to making a batch file called "ls.bat" that runs "dir". I also hate the fact that the campus Sun machines have keyboards with backspace key one row lower than it is on most PC keyboards. It just gets in the way.
That said, I have found that the government computer syllabus does teach the use of a particular software. In Tamil Nadu (a southern state), the CS textbooks really, really stink. Aside from the many errors, they contain totally useless sections that read like propoganda straight from the Microsoft Press or from a Sun approved publication. They also have totally software-specific stuff like how to change your background wallpaper in Windows 98 and which menu headers and footers are under in Word and the worst of it is that students are tested on this crap. Oh yeah, all that is part of the high school "Computer Science" curriculum. While they do teach programming, they approach it with the concept "first we'll teach C, then Java, then Visual Basic" because how many languages you "know" is easier to quantify than how well you know how to program. After they "learn" C, the Java book starts from the very beginning again with loops, case statements and all, totally ignoring the fact that students should already know that from C.
The Central (see Federal) government's CS syllabus is much better but just the fact that the State board of education's syllabus is crap shows the current mentality of some of the decision makers. It's all about the buzz words ("I know Oracle, .NET and EJB"). Intel and Microsoft really have a stranglehold on the average Indian consumer (Intel's "our chip makes the internet, digital video editing and everything else better and easier" advertising is rampant). The situation could be very different in Kerala but I wouldn't bet on it. After all, that letter was from some Free Software Users Group.
The Microsoft discount is a marketing trick. They are betting on the fact a person will not look at the long term effects. Initially, the free copy of Office is enticing, but later on he will realize that he is too used to Microsoft software and resigns to start paying through his ass for licenses.
With free software, users are offered what they will always be offered: software free of charge (among other things).
I think that the target is around 10-20 computers per school. Do you think that having 15 computers running 5 significantly different sets of software is useful in grade school? How about 15 computers running 3 different sets of software? Do you not think that there should be a standard? Should different versions of textbooks be written and published to accomodate the 10 different systems?
What it boils down to is that, even if students initially get used to one particular set of free software applications, getting hooked on a free software application doesn't cause as much harm as getting hooked on proprietary application. Hmm...what exactly is the danger of getting hooked on free software? (Aside from "free software is communist and is a bad thing for all of humanity").