Uh, make the device GPLv3 incompatible. Did you forget about v3's ramifications for manufactured goods? A manufacturer may not use GPLv3 code in any machine in which restricts the user's right to modify and execute that code.
Kate is a terrible rehash of TextMate, which itself takes ideas from the OS X GUI environment and Emacs. I like TextMate a lot. I use Vim at work. In both cases, it's just muscle memory for me. I know the OS X environment very well, so a powerful text editor that follows OS X conventions is a great fit; and I've been using Vim long enough to have memorized lots of useful macros and written some commands.
Besides, intX and complexNumberX examples you gave are almost exactly the same: they just tell you what kind of number you are dealing with, not what it means within your program.
You get my nitpicky point about Hungarian notation with respect to semantic typing. But the consequences don't seem to have sunk in. As we know from our university days, a type is (roughly -- it depends on the axiomatization of your type theory) the extension of a predicate. Equivalently, the type is the predicate. We are free to choose our predicates when defining our types for a program. Perhaps complex numbers weren't a good choice for the example (I happen to think they are, because of the ambiguity). The question is, who is to say that a program doesn't use complex numbers as "primary" objects? Who is to say that a program doesn't use integers as primary objects? You can't tell that just by looking at the Hungarian notation prefix.
Suppose you have a program that requires both (x,y)-coordinates (say, for screen drawing) and complex numbers (for summing over). Then, presumably, complexNumbers and (x,y)-pairs deserve different sorts of variable names (since they are internally the same data structure but are not functionally interchangeable). So Hungarian notation would prescribe some abbreviated form of ComplexNumberX and OrderedPairX, where X is a context and variable dependent "root" for the variable name. Still, 'ComplexNumberX' is about as informative as 'OrderedPairX' or 'intX'.
But what's the point? If you don't have to refer to many instances of either by name in a given scope/block/context, you might as well drop the X. And in most cases, you shouldn't have to refer to many variables by name in a given scope/block/context.
The best solution I've found so far is to just use typing information in your variable names. The "abstract" we-define-the-predicate kind of type is the important part of the variable name. You don't add temperatures to weights unless you know what you're doing, so you really shouldn't expect to see a line like temperature += weight; in any program. By default, in this naming scheme, things of the Record class are called 'record' unless there's a name collision in a block/scope/context. Collections of records (with a few benign restrictions) are called 'records'. Adjectives can be used. And so on. Obviously, Hungarian notation wouldn't add to this.
My opinion about Apps Hungarian notation is that it is a good, but incomplete idea. Yes, it gets at the notion of using "semantic typing". But it misses the key insight: usually, semantic typing information is enough.
Types, types, types, you keep talking about TYPES! That's where you're running into trouble. App Hungarian is about semantics, not typing.
Types are a semantic concept, not a syntactic one. Indeed, for every predicate P, there is a type associated with it. The set of all objects for which P is true is called the extension of P, and this set determines a type; and by construction, members of the the extension are of type P.
If you have read Programming Ruby, this is why they make such a big deal of saying that "Classes Aren't Types" -- classes, by construction in a message passing object system, don't define extensions. On the other hand, an object's "singleton class" -- the 'class' consisting of the canonical list to the methods to which an object will respond -- is a type.
So pick a predicate "IsABoolean" and another "IsADifferentiableCurveInTheComplexPlane". Both define types. Neither is a particularly good prefix.
I have to admit I like that show. It has a mysterious quality to it, despite being a vacuous soap opera. Also, it's mesmerizing somehow. The production is very slick.
In any case, the secret of the island is that it will do what the writers tell it to.
I am not a lawyer, and this is not legal advice. Talk to your lawyer (immediately!) if you ever find a bug in your vicinity. Especially if you suspect law enforcement is involved. The subject is murky, and you do not want to incriminate yourself. That said, there are a few reasons why destroying a bug is not an admission of guilt. First, you might not realize what you're destroying is a bug. Second, you might think someone other than law enforcement planted it. There are more.
On the other hand, the destruction of a bug can be used as evidence against you. Coming up with a plausible example is difficult since bugs are usually only used for drug dealer/mafia/corporate pirate types of crimes. But suppose, hypothetically, that a person was charged with murder after having destroyed a bug. If they claim to be guilty by reason of insanity (or some other lack of mens rea), the act of destroying a bug can demonstrate that you knew what you did was wrong, With the proviso that you might not have realized what you were destroying was a bug, or who planted it, or that you might be a paranoid schizophrenic (actually supporting your claim).
You might be surprised how valuable the perception of safety can be.
Today, while waiting at a busy bus stop on my way home from work, a deranged looking black Muslim man wearing a large back pack came up, kneeled on the corner, and prayed. It made me realize two things: 1) being a Muslim in the US must be tough, because 2) everybody (including me, unfortunately) went OH SHIT when they saw this.
In retrospect, I was in no danger the entire time. But my perception of safety was ruined momentarily.
That would be an excellent point, if it wasn't that there's a lifetime's worth of non-RIAA music being released every day of the week.
By who? Unless its bands I actually want to listen to, they can release several hundred million lifetimes and it wouldn't matter to me one bit. Let me know when Faust or Jimi or Can or My Bloody Valentine sign on indie labels.
Until you've managed some memory yourself, it's very hard to get what Java's up to,
Not if you understand hashing, sorting, and counting algorithms -- the things all memory management systems depend on essentially. It is the specifics that vary. Knowing what's going on under the hood amounts to knowing what the interpreter you're using does, and presumably coding to fit that behavior. This is not a good idea, unless you have a reasonable assurance that the garbage collection mechanism won't change dramatically between releases.
It's more important to choose robust data structures and algorithms for those data structures to solve your problem.
In short, memory management is a non-issue unless it is an issue. And you'll know when it is.
Well, you were one of "them". That's why you paid your union dues. Granted, "they" might have collectively approved, and in that case telling them to fuck off and then quitting would have been appropriate. But you really should have tried a positive action first. Oh well, live and learn, right?
Well, they would certainly be free to do that, but if their business was predicated on a guarantee of security, it wouldn't be a very rational thing to do. They'd protect you just as long as it was profitable to do so; until the revenue hit from the bad PR of selling you out was less than they'd be paid to sell you out.
But who says their business would be predicated on a guarantee of security? Extreme privacy is a niche market. Most people just want a fast connection. You are unlikely to find an ISP anywhere that promises extreme privacy unless it is mandated by law. Sweden is a good choice. They have "strong" as opposed to "Libertarian" privacy laws.
I got charged union dues when I got a lowly $8/hr wage to work at Save-On-Foods, at Scottsdale Mall, in Delta, BC. My supervisor was very abusive. So obviously, the union didn't work for me at all, in any way or form.
And what did you do about it? Call your union rep? Or did you just sit there and take it?
Slashdot Mirror
The comment is not the subject
Uh, make the device GPLv3 incompatible. Did you forget about v3's ramifications for manufactured goods? A manufacturer may not use GPLv3 code in any machine in which restricts the user's right to modify and execute that code.
Kate is a terrible rehash of TextMate, which itself takes ideas from the OS X GUI environment and Emacs. I like TextMate a lot. I use Vim at work. In both cases, it's just muscle memory for me. I know the OS X environment very well, so a powerful text editor that follows OS X conventions is a great fit; and I've been using Vim long enough to have memorized lots of useful macros and written some commands.
Mere preference, but a strong one.
Besides, intX and complexNumberX examples you gave are almost exactly the same: they just tell you what kind of number you are dealing with, not what it means within your program.
You get my nitpicky point about Hungarian notation with respect to semantic typing. But the consequences don't seem to have sunk in. As we know from our university days, a type is (roughly -- it depends on the axiomatization of your type theory) the extension of a predicate. Equivalently, the type is the predicate. We are free to choose our predicates when defining our types for a program. Perhaps complex numbers weren't a good choice for the example (I happen to think they are, because of the ambiguity). The question is, who is to say that a program doesn't use complex numbers as "primary" objects? Who is to say that a program doesn't use integers as primary objects? You can't tell that just by looking at the Hungarian notation prefix.
Suppose you have a program that requires both (x,y)-coordinates (say, for screen drawing) and complex numbers (for summing over). Then, presumably, complexNumbers and (x,y)-pairs deserve different sorts of variable names (since they are internally the same data structure but are not functionally interchangeable). So Hungarian notation would prescribe some abbreviated form of ComplexNumberX and OrderedPairX, where X is a context and variable dependent "root" for the variable name. Still, 'ComplexNumberX' is about as informative as 'OrderedPairX' or 'intX'.
But what's the point? If you don't have to refer to many instances of either by name in a given scope/block/context, you might as well drop the X. And in most cases, you shouldn't have to refer to many variables by name in a given scope/block/context.
The best solution I've found so far is to just use typing information in your variable names. The "abstract" we-define-the-predicate kind of type is the important part of the variable name. You don't add temperatures to weights unless you know what you're doing, so you really shouldn't expect to see a line like temperature += weight; in any program.
By default, in this naming scheme, things of the Record class are called 'record' unless there's a name collision in a block/scope/context. Collections of records (with a few benign restrictions) are called 'records'. Adjectives can be used. And so on. Obviously, Hungarian notation wouldn't add to this.
My opinion about Apps Hungarian notation is that it is a good, but incomplete idea. Yes, it gets at the notion of using "semantic typing". But it misses the key insight: usually, semantic typing information is enough.
Please read http://plato.stanford.edu/entries/type-theory/.
Every predicate defines a type. That's what a type is! The extension of a predicate.
Types, types, types, you keep talking about TYPES! That's where you're running into trouble. App Hungarian is about semantics, not typing.
Types are a semantic concept, not a syntactic one. Indeed, for every predicate P, there is a type associated with it. The set of all objects for which P is true is called the extension of P, and this set determines a type; and by construction, members of the the extension are of type P.
If you have read Programming Ruby, this is why they make such a big deal of saying that "Classes Aren't Types" -- classes, by construction in a message passing object system, don't define extensions. On the other hand, an object's "singleton class" -- the 'class' consisting of the canonical list to the methods to which an object will respond -- is a type.
So pick a predicate "IsABoolean" and another "IsADifferentiableCurveInTheComplexPlane". Both define types. Neither is a particularly good prefix.
http://plato.stanford.edu/entries/type-theory/
OMG First post!
The average is adult is just average.
Wow that sounds really fun!
Great, now I have tailor my words because some people have poor vocabularies
You already had to do that if you meant to communicate with other people. You're not very smart if you didn't realize that.
I have to admit I like that show. It has a mysterious quality to it, despite being a vacuous soap opera. Also, it's mesmerizing somehow. The production is very slick.
In any case, the secret of the island is that it will do what the writers tell it to.
I am not a lawyer, and this is not legal advice. Talk to your lawyer (immediately!) if you ever find a bug in your vicinity. Especially if you suspect law enforcement is involved. The subject is murky, and you do not want to incriminate yourself. That said, there are a few reasons why destroying a bug is not an admission of guilt. First, you might not realize what you're destroying is a bug. Second, you might think someone other than law enforcement planted it. There are more.
On the other hand, the destruction of a bug can be used as evidence against you. Coming up with a plausible example is difficult since bugs are usually only used for drug dealer/mafia/corporate pirate types of crimes. But suppose, hypothetically, that a person was charged with murder after having destroyed a bug. If they claim to be guilty by reason of insanity (or some other lack of mens rea), the act of destroying a bug can demonstrate that you knew what you did was wrong, With the proviso that you might not have realized what you were destroying was a bug, or who planted it, or that you might be a paranoid schizophrenic (actually supporting your claim).
On the other hand, it has it's uses. There's not much reason why I should have to press my PIN into a publicly visible terminal when I use an ATM.
Oh the irony. They already knew you respect them.
Destroying a bug is not an admission of guilt.
I haven't been following KDE4 very much, but if what you say regarding Mickey and Mario is true, I'll have to build it at work.
You might be surprised how valuable the perception of safety can be.
Today, while waiting at a busy bus stop on my way home from work, a deranged looking black Muslim man wearing a large back pack came up, kneeled on the corner, and prayed. It made me realize two things: 1) being a Muslim in the US must be tough, because 2) everybody (including me, unfortunately) went OH SHIT when they saw this.
In retrospect, I was in no danger the entire time. But my perception of safety was ruined momentarily.
Interesting, thanks for the tip. (Yes, that's the same Faust).
That would be an excellent point, if it wasn't that there's a lifetime's worth of non-RIAA music being released every day of the week.
By who? Unless its bands I actually want to listen to, they can release several hundred million lifetimes and it wouldn't matter to me one bit. Let me know when Faust or Jimi or Can or My Bloody Valentine sign on indie labels.
As someone who warezed *everything* as a kid and is now trying to make a living in the arts, I find it ironic that I can't afford a hat now.
Maybe you should, I don't know, make something worth buying? Or is that too hard for you?
Until you've managed some memory yourself, it's very hard to get what Java's up to,
Not if you understand hashing, sorting, and counting algorithms -- the things all memory management systems depend on essentially. It is the specifics that vary. Knowing what's going on under the hood amounts to knowing what the interpreter you're using does, and presumably coding to fit that behavior. This is not a good idea, unless you have a reasonable assurance that the garbage collection mechanism won't change dramatically between releases.
It's more important to choose robust data structures and algorithms for those data structures to solve your problem.
In short, memory management is a non-issue unless it is an issue. And you'll know when it is.
Well, you were one of "them". That's why you paid your union dues. Granted, "they" might have collectively approved, and in that case telling them to fuck off and then quitting would have been appropriate. But you really should have tried a positive action first. Oh well, live and learn, right?
Well, they would certainly be free to do that, but if their business was predicated on a guarantee of security, it wouldn't be a very rational thing to do. They'd protect you just as long as it was profitable to do so; until the revenue hit from the bad PR of selling you out was less than they'd be paid to sell you out.
But who says their business would be predicated on a guarantee of security? Extreme privacy is a niche market. Most people just want a fast connection. You are unlikely to find an ISP anywhere that promises extreme privacy unless it is mandated by law. Sweden is a good choice. They have "strong" as opposed to "Libertarian" privacy laws.
In a truly libertarian system, they wouldn't dare do that, because then nobody would use their services; ...
They wouldn't? It doesn't seem to stop American companies.
I got charged union dues when I got a lowly $8/hr wage to work at Save-On-Foods, at Scottsdale Mall, in Delta, BC. My supervisor was very abusive. So obviously, the union didn't work for me at all, in any way or form.
And what did you do about it? Call your union rep? Or did you just sit there and take it?