And of course many of us geeks miss the old solid IBM keyboards from the early 80s, t
You can buy them today, too. They are not cheap though (as back then). I think it is Keytronic that makes these days.
I, too, remember that exact quote, except it was 1960's that made the wonderful goods. I actually read it twice before I believed my eyes:) I didn't know it went back quite so far, though.
As for amplifiers etc.... you can still get the good stuff, though not from NAD anymore, they moved their production to the far east with the predictable results. Some with Denon. Many companies goes through that cycle:
Start making quality hardware
Get a reputation for good hardware
Experiment with cheaper production (no change in sales)
Conclude that cheaper is just as good and move production to cheap mode
The law in question is about circumventing DRM. I am, since I am using libdecss to view them. Now, our cultural minister has written that this should be legal, but the law is not very clear.
Besides, the GPL is essentially a form of DRM (digital rights[sic] management).
That is just silly. GPL is pure copyright, nothing else. There are no digital restrictions management involved. As with the GPL, copyright should be more than sufficient. The trouble is a matter of enforcement; and in that regard DRM and related laws are just as bad.
If we could make a (e.g. ISO) standard based DRM that everyone could implement then fine, but I fear that is impossible. As it is now, DRM is just vendor lockins in disguise, and I believe the strong reactions you see from many people are caused by this.
This is from someone who *doesn't* pirate, but do watch my DVDs on a linux box (I don't think this is illegal here, but neither am I sure. Another sign that the laws about DRM are bad... I should be able to at least tell if I am breaking the law with such a basic usecase).
High-level assemblers provide high-level-language abstractions such as:
Advanced control structures
High-level procedure/function declarations and invocations
High-level abstract data types, including structures/records, unions, classes, and sets
Sophisticated macro processing
Seems to fit the bill:p
More to the point, when I need to know exactly which machine I will get, I use C. Or maybe really simple C++. Once, I would have used an assembler for this, but with a solid grasp of C and assembly, this is no longer necessary (for me, anyway)
*Sigh* I already wrote once that I am well aware of these distinctions. I admit to not be 100% exact, but my usage of the word is very common (it's the top suggestion on wikipedia e.g.), and anyway, it was not important. Strongly typed languages in your sense are too impractical as far as I can see. I don't know any offhand.
And 4-dimensional? You could go on. E.g, some type systems have const/non-const capabilities, which are othogonal to everything mentioned above.
As for the 100%, all those except the fluffy safe one (sounds more like marketing than computer science) are either-or. Either you allow an implicit conversion, or you do not. Either you infer the type solely from the methods, or you do not.
Making a class is just as efficient as using primitives, at least in C++. The end assembler code would be identical. Anyway, 'a'+3 makes pefect sense... it should be 'd' if it is a character or if it is a number (such as in C++), it should be 'a'+3. Why? Because a+3 = (((a+1)+1)+1)=(b+1)+1)=c+1=d. That is how it works for page numbers, e.g. What makes it hard in C++ is the shorthand 'a' for the "the character code for a". It does not mean the character a, which is *not* in accordance with the principle of least surprise, and that is indeed a bad thing. Just syntatic sugar gone a bit sour. Likewise, char is just a type suitable for representing a character code... it is not a character. Remember that , and you will do fine.
In C++, 2 is not an object. In Ruby, e.g., it is. In my humble opionion, there is no good reason to have anything but objects in an oo language. Class should be an Object, Object should be an Object, methods should be an object etc. There is no reason not to. (The Java people will tell you otherwise. That is because every Java object lives on the heap, while primitives can live on the stack, and stacks are much more efficient. This is a language thing, and one of the weaker points of Java, imho).
You are right that retrofitting C++ with a real character object would be an uphill battle; I think it is worth it, some do not. However, getting strings representation changed from char* -> const char* to std::string has gone reasonable smooth, so I remain hopeful:)
I will refrain from commenting on Haskell until I have tried it:)
Hey! You leave my wife alone! Her computer has run for a long time without updates (I really should switch her to Kubuntu) and with a windows option she never uses, too:)
I am very much aware of the dynamic/static issue. C++ is (almost, if you ignore dynamic_cast and friends) statically typed language. That is hardly the point.
A strongly typed language is a very poor term, as it is used for so many things. The Java crowd, especially, uses it as a bagde of honour, even though Java allows some implicit casts (which is usually their definition, strangely enough) But the definition I use is that a language is strongly (statically) typed, if a) every variable has a type b) conversion from one variable to another is only accepted if there exist a conversion operator from a to b. I know this one is only one in dozens, but it makes more sense than most. Most languages are strongly typed in this sense, but many are only so dynamically. In the example above, signed->unsigned succeeds since there is a (implementation defined) conversion operation between the two. Just like you can assign a float to a double in Java. You might, as I do, think that there is too many of those between primitive types in C++, but the difference is a more vague of "making sense" or similar.
About the C++... primitive types are an abomination in any language (except C, which I regard as an assembler). I never consider them when I talk about strongly and loosely typed languages. It's the way that languages handles objects, which I am happy to see that most of the newer languages sees it this way too, thus 2.my_int_method() or equivalent is legal, like it should be. In your example, it would be relatively easy to make Character in C++ which would do the correct thing, quite unlike char:)
As for Haskell.... those example looks like Haskell could be a real pain to work in:) Still, I suspect that same implicit casting would take place. Like casting from B to A, where A inherits for B. I still want to try it someday, but right now I'm having fun in Ruby on rails. That is one very smooth framework, I must admit.
Yeah, I was thinking of Haskell... which turns out to be strongly typed. Oh, well, I still want to try it out some day:)
As for strongly typed... I don't usually take it to degrees:) C++ has lots of built-in conversions, but still a function takes types as parameters, and the compile will fail if an appropriate conversion cannot be found. (I find that this typed function is the most important part of the strongly typed system, as it is here most mistakes are made.) I have yet to encounter a language with no implicit type conversion at all... usually, at least something like float->double or B->A where B inherits from A is allowed. Working in such a language, I think, would be too tedious.
Strange. After trying dozens of languages, I still return to C++, and I still think it is my favorite strongly typed language (yeah, I know, nobody can agree on strongly typed, but you know what I mean).
For loosely typed, I'm more torn. Ruby is nice, so is Perl. Python seems a bit limited to me, and the indention thing is just braindead, but maybe that is just a matter of adjustment. I haven't tried Scheme or that functional language that is so popular these days, but I will get around to it.
I do have 3 gripes with C++: No closures, no closures and no closures. Oh yeah, a way to statically initialize arbitrary objects would be nice. I have seen few other valid complaints with it, but lots of silly ones.
For the worst language I have tried yet, I nominate PL/I. For the worst that anybody still uses for new projects, Java, especially it's "let's throw all our type info away" implementation of templates, sorry, generics. And no closures there either. Horrible language.
For best assembler, I nominate C.
As for the question, doing real design by contract would require a pre-processor or manual insertion of suitable code in the beginning and end for every function. Neither is exactly pretty, but I believe lots of other languages do it this way. Personally, I think that excessive preconditions is a sign of poor OO design, but testing invariants do make sense for certain cases. Postconditions are better handled with an ordinary testframework.
And remember that lots of ideas looks awsome on paper, and turns out to be more bother than they are worth in real life.
I don't see *any* difference between the.deb problem, and the mac one. If I'm the author of a.deb, and I want to be nasty, why can't I crypographically sign the nasty version of the code ?
The difference, such as it is, is that few debian/kubuntu/gentoo/etc users install any packages except from the "official" repositories. Anyway, I think that was the point my granparent was trying to make.
However, the real reason why MacOs'ians are a lost case, securitywise, is that most of the source code is unavailable to them in a compilable form. The above trick would not help a Mac user, as noone would be able to peerreview the code in the hypothetical central mac repositories. That said, I think Mac is reasonable secure given that it is a binary-blob based system.
These questions would perhaps be better answered on linuxquestions.org or similar, but a few points...
2. Why the hell do I have to install a new kernel? Why? I've never had to on Windows - why is Linux different? Is it so buggy? I installed with a factory version something ending 054. Now I have something ending 122 I believe. I did it OK, but that's not the point I'm making; were there really 68 cock-ups so great in the kernel build from release-time until that now they had to re-release 68 times? I'm guessing probably not, but still.
Would you really now if windows update installed a new kernel in windows? Anyway, most of the upgrades are new drivers, new functionality, workarounds for chipsets and stuff like that. The kernel handles a lot of stuff.
3. Point 2 also breaks my Nvidia drivers. I don't want to re-compile new drivers everytime there's a new 'patch'. For the love of god, why?!
Because the Nvidia drivers are not open source. Various distros handle this more or less gracefully, in Kubuntu I have just checked off the appropriate checkbox and from there it works automatically. But it sure does suck.
4. X-Windows. What a mess. Why do I have to tell it my x & y refresh rates for my monitor? Windows just 'knows'. Many more things here I feel that X-Windows should just 'know' - the number of buttons on my USB mouse for-instance. If Windows can do it, there's no reason why Linux can't. Also, X-Windows 'feels' slower than Windows. I'm sure there's good reasons for this, but I don't care; Windows is snappier.
The short answer is... you don't have to. You can, if you like, though. I agree about the mouse, that is just leftover silliness from the serial days. Some day, someone will get annoyed enough to fix that, I'm sure. As for your feelings for snappiness, it depends a lot on what you use, which features etc.
After reading this... I have the feeling you are using Gnome, and would be happier with KDE. You might want to try it out. In fact, for someone with your background, try Kubuntu's liveCD. Just burn the CD, stick in the drive, boot and see if you like it when it boots. Understand that I'm just taking a wild guess at your personality and matching it to your distribution and desktop environment here, so I might be totally off. Still, CDs are cheap:)
Counterexample: Regular polyhedron in ( 3 dimensions ): The tetrahedron, hexahedron, octahedron, dodecahedron, icosahedron. That's 5, and all there is.
And on the topic at hand: The claim were that these things are common. If they are really rare, there might still be a lot of them.
See, for example, the overhaul of the type system that was necessary to get containers to work nicely.
And even then, the type system is still not up to scratch. E.g, there is no way to cast from Object to Map in a typesafe way. That is, you can cast, but the object might turn out to be a Map or similar. This is because the Java type system cannot carry around the parametric types.
There's still something to bending words to obscure the truth that gets under my skin.
You are not alone there:/ Like in Danish, we have the world's easiest rule for nouns: All nouns are one word. Still, the English + American influence makes more and more people put nouns in several words (like house cat) which should be in one ( in Danish that is!). Still, it is pretty hopeless fighting it.
We have an institution here that monitors and documents the Danish language. (Wonderful waste of money except for the humoristic content). They once said "Most (danish) people believe that their language was at the best around their twenties, and then has been in a steady decline ever since." Right, I think so too!;)
examine the concept of theft and the rampant misuse of it (theft = bad, here's something that's bad, therefore it must be theft).
I am not an native English speaker, so besides being able to tell your from you're;), I can maybe shed some light on this:)
For many people (including me), theft is synonymous to misappropriate, to take what is not yours. Extending this slightly you arrived at accessing what is not yours, or even just copying what is not yours. Thus theft comes to include copyright infringement, data theft and such stuff where nothing was actually removed (which I understand is the bit that is missing for something to be theft in the official definition).
As this usage is so widespread, I would not be surprised if the dictionaries (though maybe not the legal system) at some future point will updated, whether people who like to do illegal-access or illegal-copying likes to be called thieves or not. That's how languages work, and there is little we can do to change it, the mores the pity.
As for wiki, let's have a look at the word. A wiki is a webpage that can be very freely edited by a wide audience. It seems logical to call something "more wiki" if it is more freely edited by a larger audience. Thus, I do not think the word is being misused here, in so far a so recently invented words can be misused.
;) Hint: the app uses the IE rendering engine, just like konqueror above uses KHTML. It's easy to be small if all your work is being done by a shared object file or it's local equivalent.
He can't be accused of a crime for hate propaganda, but it would be a tip for the security official to be more suspicious.
Except that it seems this took place after the plane was cleared by the bomb squad, the ipod was recovered (and offered back, no less!), in customs to Canada. The officer was apparently (as in, that's what he said) looking for contraband. For my money, that guy was having a very bad day or was just not a very nice person.
older system such as KDE usually have GTK installed.
What sort of flame is this? KDE (and lots of other toolkits) are currently developed, and are thus quite new. It's not as if GTK is even a superior toolkit, meaning that it has some points where it is better, and some where it is worse. Thus personal opinion matters much; e.g, the printer support in GTK is pretty horrid.
On the subject, I think that rendering the image to PNG or even GIF is the only option that produce consistent, if non-scalable, results. Inkscape will probably do the job just fine for that. Unless we are talking printer output, in which case, I just don't know.
Slashdot Mirror
You can buy them today, too. They are not cheap though (as back then). I think it is Keytronic that makes these days.
I, too, remember that exact quote, except it was 1960's that made the wonderful goods. I actually read it twice before I believed my eyes :) I didn't know it went back quite so far, though.
As for amplifiers etc.... you can still get the good stuff, though not from NAD anymore, they moved their production to the far east with the predictable results. Some with Denon. Many companies goes through that cycle:
Case in point: NAD is pretty cheap these days.
The law in question is about circumventing DRM. I am, since I am using libdecss to view them. Now, our cultural minister has written that this should be legal, but the law is not very clear.
That is just silly. GPL is pure copyright, nothing else. There are no digital restrictions management involved. As with the GPL, copyright should be more than sufficient. The trouble is a matter of enforcement; and in that regard DRM and related laws are just as bad.
If we could make a (e.g. ISO) standard based DRM that everyone could implement then fine, but I fear that is impossible. As it is now, DRM is just vendor lockins in disguise, and I believe the strong reactions you see from many people are caused by this.
This is from someone who *doesn't* pirate, but do watch my DVDs on a linux box (I don't think this is illegal here, but neither am I sure. Another sign that the laws about DRM are bad... I should be able to at least tell if I am breaking the law with such a basic usecase).
Seems to fit the bill :p
More to the point, when I need to know exactly which machine I will get, I use C. Or maybe really simple C++. Once, I would have used an assembler for this, but with a solid grasp of C and assembly, this is no longer necessary (for me, anyway)
wikipedia on strongly typed. Check the first item on the list :p But I agree, I should have used the much more precise term, statically typed.
*Sigh* I already wrote once that I am well aware of these distinctions. I admit to not be 100% exact, but my usage of the word is very common (it's the top suggestion on wikipedia e.g.), and anyway, it was not important. Strongly typed languages in your sense are too impractical as far as I can see. I don't know any offhand.
And 4-dimensional? You could go on. E.g, some type systems have const/non-const capabilities, which are othogonal to everything mentioned above.
As for the 100%, all those except the fluffy safe one (sounds more like marketing than computer science) are either-or. Either you allow an implicit conversion, or you do not. Either you infer the type solely from the methods, or you do not.
Making a class is just as efficient as using primitives, at least in C++. The end assembler code would be identical. Anyway, 'a'+3 makes pefect sense... it should be 'd' if it is a character or if it is a number (such as in C++), it should be 'a'+3. Why? Because a+3 = (((a+1)+1)+1)=(b+1)+1)=c+1=d. That is how it works for page numbers, e.g. What makes it hard in C++ is the shorthand 'a' for the "the character code for a". It does not mean the character a, which is *not* in accordance with the principle of least surprise, and that is indeed a bad thing. Just syntatic sugar gone a bit sour. Likewise, char is just a type suitable for representing a character code... it is not a character. Remember that , and you will do fine.
In C++, 2 is not an object. In Ruby, e.g., it is. In my humble opionion, there is no good reason to have anything but objects in an oo language. Class should be an Object, Object should be an Object, methods should be an object etc. There is no reason not to. (The Java people will tell you otherwise. That is because every Java object lives on the heap, while primitives can live on the stack, and stacks are much more efficient. This is a language thing, and one of the weaker points of Java, imho).
You are right that retrofitting C++ with a real character object would be an uphill battle; I think it is worth it, some do not. However, getting strings representation changed from char* -> const char* to std::string has gone reasonable smooth, so I remain hopeful :)
I will refrain from commenting on Haskell until I have tried it :)
Hey! You leave my wife alone! Her computer has run for a long time without updates (I really should switch her to Kubuntu) and with a windows option she never uses, too :)
I am very much aware of the dynamic/static issue. C++ is (almost, if you ignore dynamic_cast and friends) statically typed language. That is hardly the point.
A strongly typed language is a very poor term, as it is used for so many things. The Java crowd, especially, uses it as a bagde of honour, even though Java allows some implicit casts (which is usually their definition, strangely enough) But the definition I use is that a language is strongly (statically) typed, if a) every variable has a type b) conversion from one variable to another is only accepted if there exist a conversion operator from a to b. I know this one is only one in dozens, but it makes more sense than most. Most languages are strongly typed in this sense, but many are only so dynamically. In the example above, signed->unsigned succeeds since there is a (implementation defined) conversion operation between the two. Just like you can assign a float to a double in Java. You might, as I do, think that there is too many of those between primitive types in C++, but the difference is a more vague of "making sense" or similar.
About the C++... primitive types are an abomination in any language (except C, which I regard as an assembler). I never consider them when I talk about strongly and loosely typed languages. It's the way that languages handles objects, which I am happy to see that most of the newer languages sees it this way too, thus 2.my_int_method() or equivalent is legal, like it should be. In your example, it would be relatively easy to make Character in C++ which would do the correct thing, quite unlike char :)
As for Haskell.... those example looks like Haskell could be a real pain to work in :) Still, I suspect that same implicit casting would take place. Like casting from B to A, where A inherits for B. I still want to try it someday, but right now I'm having fun in Ruby on rails. That is one very smooth framework, I must admit.
Yeah, I was thinking of Haskell... which turns out to be strongly typed. Oh, well, I still want to try it out some day :)
As for strongly typed... I don't usually take it to degrees :) C++ has lots of built-in conversions, but still a function takes types as parameters, and the compile will fail if an appropriate conversion cannot be found. (I find that this typed function is the most important part of the strongly typed system, as it is here most mistakes are made.) I have yet to encounter a language with no implicit type conversion at all... usually, at least something like float->double or B->A where B inherits from A is allowed. Working in such a language, I think, would be too tedious.
Hehe, I have no doubt RPG/III is worse :) I've never had the misfortune to try anything worse than PL/I.
Strange. After trying dozens of languages, I still return to C++, and I still think it is my favorite strongly typed language (yeah, I know, nobody can agree on strongly typed, but you know what I mean).
For loosely typed, I'm more torn. Ruby is nice, so is Perl. Python seems a bit limited to me, and the indention thing is just braindead, but maybe that is just a matter of adjustment. I haven't tried Scheme or that functional language that is so popular these days, but I will get around to it.
I do have 3 gripes with C++: No closures, no closures and no closures. Oh yeah, a way to statically initialize arbitrary objects would be nice. I have seen few other valid complaints with it, but lots of silly ones.
For the worst language I have tried yet, I nominate PL/I. For the worst that anybody still uses for new projects, Java, especially it's "let's throw all our type info away" implementation of templates, sorry, generics. And no closures there either. Horrible language.
For best assembler, I nominate C.
As for the question, doing real design by contract would require a pre-processor or manual insertion of suitable code in the beginning and end for every function. Neither is exactly pretty, but I believe lots of other languages do it this way. Personally, I think that excessive preconditions is a sign of poor OO design, but testing invariants do make sense for certain cases. Postconditions are better handled with an ordinary testframework.
And remember that lots of ideas looks awsome on paper, and turns out to be more bother than they are worth in real life.
I never had! My gaming rig runs linux! ;)
On the other hand, I've never owned a console. What's the point with them? Computers are better value for the money, as I see it :)
The difference, such as it is, is that few debian/kubuntu/gentoo/etc users install any packages except from the "official" repositories. Anyway, I think that was the point my granparent was trying to make.
However, the real reason why MacOs'ians are a lost case, securitywise, is that most of the source code is unavailable to them in a compilable form. The above trick would not help a Mac user, as noone would be able to peerreview the code in the hypothetical central mac repositories. That said, I think Mac is reasonable secure given that it is a binary-blob based system.
These questions would perhaps be better answered on linuxquestions.org or similar, but a few points...
Would you really now if windows update installed a new kernel in windows? Anyway, most of the upgrades are new drivers, new functionality, workarounds for chipsets and stuff like that. The kernel handles a lot of stuff.
Because the Nvidia drivers are not open source. Various distros handle this more or less gracefully, in Kubuntu I have just checked off the appropriate checkbox and from there it works automatically. But it sure does suck.The short answer is... you don't have to. You can, if you like, though. I agree about the mouse, that is just leftover silliness from the serial days. Some day, someone will get annoyed enough to fix that, I'm sure. As for your feelings for snappiness, it depends a lot on what you use, which features etc.
After reading this... I have the feeling you are using Gnome, and would be happier with KDE. You might want to try it out. In fact, for someone with your background, try Kubuntu's liveCD. Just burn the CD, stick in the drive, boot and see if you like it when it boots. Understand that I'm just taking a wild guess at your personality and matching it to your distribution and desktop environment here, so I might be totally off. Still, CDs are cheap :)
I was referring to an ancestor, not the article...
Counterexample: Regular polyhedron in ( 3 dimensions ): The tetrahedron, hexahedron, octahedron, dodecahedron, icosahedron. That's 5, and all there is.
And on the topic at hand: The claim were that these things are common. If they are really rare, there might still be a lot of them.
I meant, of couse, Object to Map<String,String>.
And even then, the type system is still not up to scratch. E.g, there is no way to cast from Object to Map in a typesafe way. That is, you can cast, but the object might turn out to be a Map or similar. This is because the Java type system cannot carry around the parametric types.
You are not alone there :/ Like in Danish, we have the world's easiest rule for nouns: All nouns are one word. Still, the English + American influence makes more and more people put nouns in several words (like house cat) which should be in one ( in Danish that is!). Still, it is pretty hopeless fighting it.
We have an institution here that monitors and documents the Danish language. (Wonderful waste of money except for the humoristic content). They once said "Most (danish) people believe that their language was at the best around their twenties, and then has been in a steady decline ever since." Right, I think so too! ;)
I am not an native English speaker, so besides being able to tell your from you're ;), I can maybe shed some light on this :)
For many people (including me), theft is synonymous to misappropriate, to take what is not yours. Extending this slightly you arrived at accessing what is not yours, or even just copying what is not yours. Thus theft comes to include copyright infringement, data theft and such stuff where nothing was actually removed (which I understand is the bit that is missing for something to be theft in the official definition).
As this usage is so widespread, I would not be surprised if the dictionaries (though maybe not the legal system) at some future point will updated, whether people who like to do illegal-access or illegal-copying likes to be called thieves or not. That's how languages work, and there is little we can do to change it, the mores the pity.
As for wiki, let's have a look at the word. A wiki is a webpage that can be very freely edited by a wide audience. It seems logical to call something "more wiki" if it is more freely edited by a larger audience. Thus, I do not think the word is being misused here, in so far a so recently invented words can be misused.
Just my 2 early morning eurocents :)
;) Hint: the app uses the IE rendering engine, just like konqueror above uses KHTML. It's easy to be small if all your work is being done by a shared object file or it's local equivalent.
Except that it seems this took place after the plane was cleared by the bomb squad, the ipod was recovered (and offered back, no less!), in customs to Canada. The officer was apparently (as in, that's what he said) looking for contraband. For my money, that guy was having a very bad day or was just not a very nice person.
What sort of flame is this? KDE (and lots of other toolkits) are currently developed, and are thus quite new. It's not as if GTK is even a superior toolkit, meaning that it has some points where it is better, and some where it is worse. Thus personal opinion matters much; e.g, the printer support in GTK is pretty horrid.
On the subject, I think that rendering the image to PNG or even GIF is the only option that produce consistent, if non-scalable, results. Inkscape will probably do the job just fine for that. Unless we are talking printer output, in which case, I just don't know.