The Daily WTF: Curious Perversions in Information Technology

ammoQ · 2005-10-23 Reply Admin

Anonymous:

Hopefully none. But in a language where you can't do output like above you will instead be forrced to multi-line behemoths or class/function multiplication hell.

In a language that allows variable numbers of method parameters, your example could read like that:
cout.write(Stream.hex, a, "--", b, Stream.dec, c, Stream.endl);

The STL stream operators is a good example of the entire discussion: they are easy to make into both good examples on the benefits of operator overloading and anti-examples of the horrors of operator overloading. Again, we come down to that good programmers are capable of making judicious use of language features. But it is poor languages-or a poor language philosophy- that restricts the programmer's toolset .Toolset restriction might preempt b0rked coders from shooting themselves in the foot in certain ways (though they will always find other means to that) but it will also limit and restrain the good programers.

ammoQ · 2005-10-23 Reply Admin

Grrr, the forum ate the 2nd part of my post...

Anonymous:

Toolset restriction might preempt b0rked coders from shooting themselves in the foot in certain ways (though they will always find other means to that) but it will also limit and restrain the good programers.

On the other hand, if the toolset is too rich, there are too many different ways to do something, so programmers have a hard time reading other programmers' code. Most programmers choose their subset of the toolset, so they are not familiar with all features of overly comprehensive languages like C++

2005-10-23 Reply Admin

kipthegreat:

Now that I think about it, Integer.parseInt("3").toString() would never compile... Integer.parseInt("3") is an int, which is primitive, so .toString() couldn't compile....

Just to be argumentative, 1.5 has autoboxing, so the int would be promoted to an Integer, and .toString() would work. (I think so, anyway... it may not be promoted when you try to call a method on it; I don't particularly care for Java, though, so I won't test it).

2005-10-24 Reply Admin

ammoQ:
Anonymous:

Hopefully none. But in a language where you can't do output like above you will instead be forrced to multi-line behemoths or class/function multiplication hell.

In a language that allows variable numbers of method parameters, your example could read like that:
cout.write(Stream.hex, a, "--", b, Stream.dec, c, Stream.endl);

Elegant. And unfortunately unusual in "live" languages.

ammoQ:
Anonymous:

Toolset restriction might preempt b0rked coders from shooting themselves in the foot in certain ways (though they will always find other means to that) but it will also limit and restrain the good programers.

On the other hand, if the toolset is too rich, there are too many different ways to do something, so programmers have a hard time reading other programmers' code. Most programmers choose their subset of the toolset, so they are not familiar with all features of overly comprehensive languages like C++

Philosophical dispute: "freedom" versus "safety". Of course, if there was infinite ways of doing something you'd have an infinate number of different solutions. However, we do not see more of this in C/C++ production code than in other languages. The larger toolset of C++ means pragmatically that a wider set of problems can be effectively addressed in the best way, not that the code will tend toward chaos. Yes, even though you become advanvced in C++ you might still find things you do not know about, but this does not mean that you (1) will be unable to understand the code, nor (2) that you personally would be less productive for not knowing about that feature beforehand. Think of it like this, would you prefer to speak a natural language, say English, restricted to a subset deemed easy and harmless enough for someone's definition of "proper use", or accept a more unrestricted tounge for greater application, freedom and efficiency in particular areas at the price of knowing that there are aspects you might not understand? This captures the clash of philosophies; some would prefer the narrower language, while some prefer the wider. And some are forced to use the narrower but work from within to extend it, which, if they are successful, often results in the extensions breaking the narrower language's original principles.

ammoQ · 2005-10-24 Reply Admin

Anonymous:
ammoQ:

In a language that allows variable numbers of method parameters, your example could read like that:
cout.write(Stream.hex, a, "--", b, Stream.dec, c, Stream.endl);

Elegant. And unfortunately unusual in "live" languages.

Java5 as well as C# allow variable length argument lists, as well as auto boxing, so in those languages it's an easy execise to implement that.

ammoQ:

On the other hand, if the toolset is too rich, there are too many different ways to do something, so programmers have a hard time reading other programmers' code. Most programmers choose their subset of the toolset, so they are not familiar with all features of overly comprehensive languages like C++

Philosophical dispute: "freedom" versus "safety". Of course, if there was infinite ways of doing something you'd have an infinate number of different solutions. However, we do not see more of this in C/C++ production code than in other languages. The larger toolset of C++ means pragmatically that a wider set of problems can be effectively addressed in the best way, not that the code will tend toward chaos. Yes, even though you become advanvced in C++ you might still find things you do not know about, but this does not mean that you (1) will be unable to understand the code

You don't need knowledge of templates to write C++ programs, in fact, they did not work well in some of the early compilers.
But without that knowledge I doubt you can understand programs that use templates extensively.
Adressing everything in the best way is a desireable goal, but IMO readability is the most important goal, since most programs are more often read than written. Having too many features in a language threatens readability just as much as a lack of good (powerfull, elegant) features.

Think of it like this, would you prefer to speak a natural language, say English, restricted to a subset deemed easy and harmless enough for someone's definition of "proper use", or accept a more unrestricted tounge for greater application, freedom and efficiency in particular areas at the price of knowing that there are aspects you might not understand?

Since I'm not a native speaker, my usage of the English language is naturally limited to a subset known as "broken international English" ;-)

This captures the clash of philosophies; some would prefer the narrower language, while some prefer the wider. And some are forced to use the narrower but work from within to extend it, which, if they are successful, often results in the extensions breaking the narrower language's original principles.

Keeping the balance is one of the more important tasks of any creator.

brazzy · 2005-10-24 Reply Admin

Anonymous:
brazzy:

Yes, it is. Let's look at it in detail:

1. it's syntatctic sugar - simple fact.

2. it is useless - Not 100% true, but 95%. The only advantage it offers is terser code, but this is actually a grave DISadvantage (see 3.) unless the operator's meaning is ovbious and/or well-known to everyone who reads the code. This is the case only for mathematics, and only for the small subset of mathematics where ASCII symbols are used. There's a reason why nearly everyone arguing the usefulness of operator overloading will use the same example (complex numbers).

3. it obfuscates code - operators are less descriptive than method names in nearly all cases, and implicity operator precedence is a minefield. Yes, it allows you to cram more mode on one line. No, that's not a good thing.

1. The more experienced developers who wrote the C# engine which I doubt you could do did not think so. You are just regurgitating sweeping statements with no established references.

Apparently you do not even know what "syntactic sugar" means. Operator overloading IS syntactic sugar, period. BTW, "Feature X must be good because language Y has it" is no argument at all, and neither is appeal to authority.

Anonymous:

2. Again a rigmarole of sweeping and unsupported statements. Any application with insufficient comments or documentation is going to be a nightmare to be maintained. That more than anything else makes for obfuscation in any application. NOT operator overloading. Your argument is considerably a very specious one.

Funny then that you are unable to argue against it, and instead change the topic.

Anonymous:

3. Self describing methods (with descriptive names) is not half as useful as proper application of patterns and juducious commenting and documentation.

Again you have to change the topic to make an argument, but fine: I disagree strongly. Descriptive names are the single most important aspect of clear and maintainable code. Comments can complement them and add detail, but the best comment is one that is unnecessary because names of the method and its parameters make the functionality obvious.

brazzy · 2005-10-24 Reply Admin

Anonymous:

Not if it is part of a constructor / instance initializer or method body. But what this discussion was about (as I understood it) was whether the return value of the toString() call would be the same object or a different one. It is not; try it out. The only way for it to be the same object would be if the toString() method used intern() on its result. This is, I have to admit, not explicitly forbidden by the JLS or the API spec, but I cannot imagine that any sane implementation does it, since it would lose a lot of performance for little or no gain.

This is true to some extent. I'll bet that "you're" implementation indeed returns false for Integer.parseInt("3").toString() == "3".
As you noted, this behaviour is not guaranteed by the specification.
However, to suggest that there is a performance penalty in doing so is blatantly false.
In fact, that is exactly what the "autoboxing within the range of a byte" hack does, only in a different context.
Specifically, keys a value (the primitive) to an object (the wrapping type) with O(1) lookup - an attempt to prevent redundant objects - simply, all Integer instances with the same underlying int representation need not be replicated (this is ultimately a result of the constructor semantics of the language guaranteeing a new instance - an implicit requirement defect).

Related fun: http://jqa.tmorris.net/GetQAndA.action?qids=7

Interesting, but have you thought about why they do that only for such small numbers? I can tell you: because it can then be implemented by indexing into a table of premade Integer objects, which is faster than a hash lookup you'd otherwise have to do, and (far more importantly) because it limits the number of objects you have to keep in memory to do it. You do NOT want to keep millions of Integer objects in memory when someone creates throwaway objects in a loop, just because some of them may reoccur.

brazzy · 2005-10-24 Reply Admin

Anonymous:

I was referring to the statement: "Actually, it isn't the same in ANY spec-conforming Java implementation. The former will create a different object each time it is executed, while the latter is taken from the class's constant pool. Or, in code:"
This is indeed untrue. No "object is created" in one and not the other [refer to J2SE API Specification java.lang.Integer.parseInt(java.lang.String)] unless of course, you're referring to object created at class load time, which is created in both (whichever way you look at it, the statement is false).

No, it is your statement here which is false whichever way you look at it.

parseInt() of course does not create an object, since it returns a primitive, which is why I said we should be talking about Integer.valueOf() instead, because you cannot invoke toString() on an int (not even with autoboxing). I think you mean valueOf() when you refer to the API doc, because it says something about caching, but if you look at the source code (in 1.5.0 at least) you'll see that, just like what we talked about in the other posting, it only caches values between -128 and 127.

But even then, Intege.toString() creates a new Object each time it is executed, at least in 1.5.0.

2005-10-24 Reply Admin

ammoQ:
Anonymous:
ammoQ:

In a language that allows variable numbers of method parameters, your example could read like that:
cout.write(Stream.hex, a, "--", b, Stream.dec, c, Stream.endl);

Elegant. And unfortunately unusual in "live" languages.

Java5 as well as C# allow variable length argument lists, as well as auto boxing, so in those languages it's an easy execise to implement that.

Good to hear! That would indeed be one way around some of the limitations, though I still hold that proper use of operator overloading would is more appealing. However, it is gratifying to hear that, for certain areas at least, roughly similar functionality exists.

ammoQ:

You don't need knowledge of templates to write C++ programs, in fact, they did not work well in some of the early compilers.
But without that knowledge I doubt you can understand programs that use templates extensively.
Adressing everything in the best way is a desireable goal, but IMO readability is the most important goal, since most programs are more often read than written. Having too many features in a language threatens readability just as much as a lack of good (powerfull, elegant) features.

The fundamental principles of C++ are efficiency, versatility and flexibility. Native language-like readability is not. These principles have never been compromised and constitute great aesthetics for me. Other languages might have different principles, like easy beginner accessibility or readability, and must thus be judged according to their own principles. (Interestingly enough, in the context of the Java vs. C++ origin of the heated debate (continuing around us as we speak), is that Java increasingly are losing grasp of its own original principles.)

Anyway, do you mean you think that templates is a superfluous "feature", an unnecessary bloat, on C++? I, and many with me, including many of the more influential bigwigs, consider templates to be one of the most powerful language innovations ever. There is no single feature in any language ever that has allowed me such code reuse, such generic programming, such flexiblity, and so aesthetic solutions as templates. The most problematic compiler, as usual, is MS's VC++; that one always lags quite far behind the Standard, which is a bother since it is a big platform that has to be considered.

Think of it like this, would you prefer to speak a natural language, say English, restricted to a subset deemed easy and harmless enough for someone's definition of "proper use", or accept a more unrestricted tounge for greater application, freedom and efficiency in particular areas at the price of knowing that there are aspects you might not understand?

Since I'm not a native speaker, my usage of the English language is naturally limited to a subset known as "broken international English" ;-)

Hehe, funny argument in context of my analogy :) Reminds me of the quote "the international language of academic research is Bad English".

This captures the clash of philosophies; some would prefer the narrower language, while some prefer the wider. And some are forced to use the narrower but work from within to extend it, which, if they are successful, often results in the extensions breaking the narrower language's original principles.

Keeping the balance is one of the more important tasks of any creator.

Aye, however, most of us recognise that we are quite incapable of determining what would be a good balance. Thus, we make languages that suit ourselves, at the moment, and arrogantly believe that our preferences are representative of everyone's best. That is why I respect Stroustrup, because he accepted that there is no One Best Style (no absolute "balance", if you will), and accomodated most everything by leaving that to the programmers. The lack of such freedom is probably the reason for the big feuds from and within the Java camp: some people have found what they like and defend it entrenchedly because they are simply incapable of understanding that other people have different problems, needs or preferences, or don't consider it the best thing since toast; others continuously revolt due to feelings of claustrophobia. Basically, it has nothing to do with which language is "better", they're for different things!, it has to do with philosophies that has been channeled into a medium: some who loathed C++ due to agoraphobia loves Java for its clearer delimitations; conversly, some loathe Java due to claustrophobia.

Good discussion, btw.

ammoQ · 2005-10-24 Reply Admin

Anonymous:

The fundamental principles of C++ are efficiency, versatility and flexibility. Native language-like readability is not. These principles have never been compromised and constitute great aesthetics for me. Other languages might have different principles, like easy beginner accessibility or readability, and must thus be judged according to their own principles. (Interestingly enough, in the context of the Java vs. C++ origin of the heated debate (continuing around us as we speak), is that Java increasingly are losing grasp of its own original principles.)

IMO C++ carries too much C legacy with it. That hurts, especially since C++ is already bloated. As a result, some basic things (that were poorly implemented in C) like strings are re-invented in every framework.

Anyway, do you mean you think that templates is a superfluous "feature", an unnecessary bloat, on C++? I, and many with me, including many of the more influential bigwigs, consider templates to be one of the most powerful language innovations ever. There is no single feature in any language ever that has allowed me such code reuse, such generic programming, such flexiblity, and so aesthetic solutions as templates. The most problematic compiler, as usual, is MS's VC++; that one always lags quite far behind the Standard, which is a bother since it is a big platform that has to be considered.

I aggree that templates are a powerfull and usefull feature, but I think that they also add a great amount of complexity to C++ programs using them. But, as you have noted, a similar feature - generics - has also appeared in supposedly "clean" languages like C# and Java.

Keeping the balance is one of the more important tasks of any creator.

Aye, however, most of us recognise that we are quite incapable of determining what would be a good balance. Thus, we make languages that suit ourselves, at the moment, and arrogantly believe that our preferences are representative of everyone's best. That is why I respect Stroustrup, because he accepted that there is no One Best Style (no absolute "balance", if you will), and accomodated most everything by leaving that to the programmers. The lack of such freedom is probably the reason for the big feuds from and within the Java camp: some people have found what they like and defend it entrenchedly because they are simply incapable of understanding that other people have different problems, needs or preferences, or don't consider it the best thing since toast; others continuously revolt due to feelings of claustrophobia. Basically, it has nothing to do with which language is "better", they're for different things!, it has to do with philosophies that has been channeled into a medium: some who loathed C++ due to agoraphobia loves Java for its clearer delimitations; conversly, some loathe Java due to claustrophobia.

I see you point, but on the other hand, by leaving it all to the programmers (and frameworks like MFC), the style of C++ is somewhat blurry; actual usage, frameworks and "best practices" determine the actually used language, which can greatly differ between one site and another.

Cyresse · 2005-10-25 Reply Admin

brazzy:

Apparently you do not even know what "syntactic sugar" means. Operator overloading IS syntactic sugar, period. BTW, "Feature X must be good because language Y has it" is no argument at all, and neither is appeal to authority.

Hey, I like syntatic sugar. Writing

j = "[" + foo + "]"

to put brackets around a string is nice and simple. I never really got into Javascript too much, but I can recall doing something like

j = "[".concat(foo.concat("]"))

which isn't nice and simple. I've seen some hideous usages of overloaded operators, but when used in a logical manner, it's nice and simple. You can do hideous things with nearly any feature a language gives you.
(Case in point,TinyP2P - code that abuses some features in Python to produce a working Bittorrent client in fifteen lines, but would probably make Guido cry as it completely ignores the why of Python syntax and semantics.)

Technically dot notation is also syntatic sugar. I can access a GUI widget's attributes via

mainframe.panels.leftpanel.buttons.quitbutton.text

or

mainframe["panels"]["leftpanel"]["buttons"]["quitbutton"].text

If the framework designer has been nice, I can use dot syntax which looks cleaner and is a bit more intuitive. And yes, that's an incredibly obtuse example, but I'm just trying to make a point here.

Again you have to change the topic to make an argument, but fine: I disagree strongly. Descriptive names are the single most important aspect of clear and maintainable code. Comments can complement them and add detail, but the best comment is one that is unnecessary because names of the method and its parameters make the functionality obvious.

Whole-heartedly agree. Hence why I hate languages that make get/sets compulsory, because then when I'm looking at a class description there's a bunch of methods under g and s that I have to scroll past. But logical attribute & method names free of weird prefixes are desirous.

2005-10-25 Reply Admin

ammoQ:

IMO C++ carries too much C legacy with it. That hurts, especially since C++ is already bloated. As a result, some basic things (that were poorly implemented in C) like strings are re-invented in every framework.

Yeah, this is a common grieviance. I agree to an extent, the C legacy-compatibility requirement put some unfortunate restrictions on C++. So what is the conclusion here? All languages entail certain restrictions. In this light it should be considered that, originally, Java was a more aesthetic language in the sense that it was more strictly defined. This, however, is no longer true, and recent trends seems to indicate that it will grow increasingly less so.

As to that string classes are reinvented in every framework, that is a practice which should have ended with the STL string. MFC introduced its own CString (I think it is called) to the great consternation of most Win32 programmers, but then again MFC is not standard in any way other than that many Windows programmers are forced to deal with it.

Back to the topic: Cyresse provided some good examples for the inclusion and against the abscence of operator overloading in his post above. As a large part of this entire debate seems to revolve around the argument that operator overloads are really "nothing but" syntactic sugar, it should be considered that a large extent of what we now use in our daily programming is "mere" syntactic sugar. Assembler is sugar for opcodes. Englilshish commands are sugar for opcodes and assembler commands. Functions are sugar for jump statements. Classes are sugar for data structuring.

Yet, how many here would say that "classes are just syntactic sugar and are redundant"? Stricly speaking we do not need classes, but they make programming immensly more convenient and lends themselves to the addressing of particular problems. As do operator overloads. And as operator overloads, classes, when taken to far, can result in very strange code. As ammoQ above told us he choked on the C++ Hello World, in all honesty, Java's hello world with a main() artificially shoehorned into the class is very strange and forced syntax. I had great difficulties explaining for my gf how it worked and I finally made her understand by rewriting the code as it would be in C++... ;)

Anyone reading this who would consider that natural string operations (without violating the language's principles), natural arithmatic operations on mathematicalish entities and natural set operations do not constitute solid reasons for the benefits of operator overloading would be difficult to involve in a rational discussion.

2005-10-25 Reply Admin

Sorry for double-posting, but everyone else seems to do that too, here...

ammoQ:
Mikademus:

Aye, however, most of us recognise that we are quite incapable of determining what would be a good balance. Thus, we make languages that suit ourselves, at the moment, and arrogantly believe that our preferences are representative of everyone's best. That is why I respect Stroustrup, because he accepted that there is no One Best Style (no absolute "balance", if you will), and accomodated most everything by leaving that to the programmers. The lack of such freedom is probably the reason for the big feuds from and within the Java camp: some people have found what they like and defend it entrenchedly because they are simply incapable of understanding that other people have different problems, needs or preferences, or don't consider it the best thing since toast; others continuously revolt due to feelings of claustrophobia. Basically, it has nothing to do with which language is "better", they're for different things!, it has to do with philosophies that has been channeled into a medium: some who loathed C++ due to agoraphobia loves Java for its clearer delimitations; conversly, some loathe Java due to claustrophobia.

I see you point, but on the other hand, by leaving it all to the programmers (and frameworks like MFC), the style of C++ is somewhat blurry; actual usage, frameworks and "best practices" determine the actually used language, which can greatly differ between one site and another.

That is the whole point, in fact. There is no particular "C++ style", because there is no particular problem or field specifically targeted by the language. C++ was designed to be applicable in as many situations to as many problems as possible. A stricter definition ("style") would have hamstrung that ambition. One consequence is also that C++ has been put to use addressing more diverse problems than any other language, except C; however, another inescapable consequence is that a plentifora of personal and targeted styles have resulted.

Limiting a language to one "style" probably creates greater consistency and code familiarity but it also limits its potential application space.

ammoQ · 2005-10-25 Reply Admin

Anonymous:

Yet, how many here would say that "classes are just syntactic sugar and are redundant"? Stricly speaking we do not need classes, but they make programming immensly more convenient and lends themselves to the addressing of particular problems.

Classes (with inheritance, virtual methods etc.) are obviously more than syntactic sugar. It's rather difficult to do the same e.g. in C.

Anyone reading this who would consider that natural string operations (without violating the language's principles), natural arithmatic operations on mathematicalish entities and natural set operations do not constitute solid reasons for the benefits of operator overloading would be difficult to involve in a rational discussion.

Aggreed. Just like templates/generics are great for all kinds of containers. But then there is always this tempation: "If operator overloading does such a great job for mathematicalish entities, why shouldn't I use them for everything else? Saves a lot of typing..."

Cyresse · 2005-10-25 Reply Admin

ammoQ:

Classes (with inheritance, virtual methods etc.) are obviously more than syntactic sugar. It's rather difficult to do the same e.g. in C.

Just to be difficult, I use Python, which is OO. And, it's implemented in C. [:P]

Cyresse · 2005-10-25 Reply Admin

Gammy bloody font sizes.

ammoQ · 2005-10-26 Reply Admin

Cyresse:
ammoQ:

Classes (with inheritance, virtual methods etc.) are obviously more than syntactic sugar. It's rather difficult to do the same e.g. in C.

Just to be difficult, I use Python, which is OO. And, it's implemented in C. [:P]

True, but I guess it was a lot of work to implement Python. I can hardly imagine a C programmer implementing Python every time he wants to write an OO program.

brazzy · 2005-10-26 Reply Admin

Anonymous:

Anyone reading this who would consider that natural string operations (without violating the language's principles), natural arithmatic operations on mathematicalish entities and natural set operations do not constitute solid reasons for the benefits of operator overloading would be difficult to involve in a rational discussion.

As is anyone implying that people who disagree with him are necessarily irrational.

My opinion on this is that "mathematicalish entities" are the only really solid reason, and that's it. Using '+' to concatenate strings or add an element to a set may look "natural" to you, but it really isn't - what's the meaning of '-' between strings? What's a negated set? What's the result of adding a null pointer to a string? Or a set?

And for that one case which most programmers very rarely encounter, do we really need a special language mechanism?

2005-10-26 Reply Admin

brazzy:
Anonymous:

Anyone reading this who would consider that natural string operations (without violating the language's principles), natural arithmatic operations on mathematicalish entities and natural set operations do not constitute solid reasons for the benefits of operator overloading would be difficult to involve in a rational discussion.

As is anyone implying that people who disagree with him are necessarily irrational.

Probably yes. Good thing no-one has suggested that, then... Point was really tautological - reason is reason: anyone who would disagree with that rational arguments merits consideration would almost per definition be unsusceptible to reason.

My opinion on this is that "mathematicalish entities" are the only really solid reason, and that's it. Using '+' to concatenate strings or add an element to a set may look "natural" to you, but it really isn't - what's the meaning of '-' between strings? What's a negated set? What's the result of adding a null pointer to a string? Or a set?

And for that one case which most programmers very rarely encounter, do we really need a special language mechanism?

We "add" strings to other strings. We subtract a subset from another set. And much programming revolve around arithmatic-like problems. To once again boil this down the core: the facility is there becuase it is the best solution for certain problems - not all problems. It is up to you not to misapply it. And I deal with these situation in my daily programming. Apparently you do not, and I respect that you have little use for this facility. Please show the same repect and acknowledge that you're not prepresentative for all programmers and that quite a few of us DO need it.

After all, if no-one used it, if it was really redundant or only problematic, it wouldn't really be debated. Sort of like C++ and Java, wouldn't you agree?

AJR · 2005-10-26 Reply Admin

brazzy:
Anonymous:

Anyone reading this who would consider that natural string operations (without violating the language's principles), natural arithmatic operations on mathematicalish entities and natural set operations do not constitute solid reasons for the benefits of operator overloading would be difficult to involve in a rational discussion.

As is anyone implying that people who disagree with him are necessarily irrational.

My opinion on this is that "mathematicalish entities" are the only really solid reason, and that's it. Using '+' to concatenate strings or add an element to a set may look "natural" to you, but it really isn't - what's the meaning of '-' between strings? What's a negated set? What's the result of adding a null pointer to a string? Or a set?

Sets are a really bad example to use there, since operations on sets are well defined. Sure, the symbols "+" and "-" might not be the standard ones used by mathematicians, but using "setA + setB" for union and "setA - setB" for set difference is entirely reasonable. The negation of a set could then quite reasonably be the complement set (which would, admittedly, be tricky to represent in some circumstances.)

Adding a null pointer to a set? That would depend on how you decide to implement sets. If a null pointer represents the empty set, then the operations will work fine with it, since the empty set is just a set with nothing in it. If, OTOH, you have an object EmptySet (for example) to represent the empty set, then an attempt to treat a null pointer as a set object would result in a NullPointerException, or a segfault, or whatever form of "Go boom! now" the language you're using does when you try to dereference a null pointer.

As for strings, why does the fact that "-" doen't have an obvious meaning affect the meaning of "+"?

brazzy · 2005-10-26 Reply Admin

AJR:

Sets are a really bad example to use there, since operations on sets are well defined. Sure, the symbols "+" and "-" might not be the standard ones used by mathematicians, but using "setA + setB" for union and "setA - setB" for set difference is entirely reasonable. The negation of a set could then quite reasonably be the complement set (which would, admittedly, be tricky to represent in some circumstances.)

Adding a null pointer to a set? That would depend on how you decide to implement sets. If a null pointer represents the empty set, then the operations will work fine with it, since the empty set is just a set with nothing in it. If, OTOH, you have an object EmptySet (for example) to represent the empty set, then an attempt to treat a null pointer as a set object would result in a NullPointerException, or a segfault, or whatever form of "Go boom! now" the language you're using does when you try to dereference a null pointer.

As for strings, why does the fact that "-" doen't have an obvious meaning affect the meaning of "+"?

Because it's "natural" that if you have addition, you also have subtraction.

The first who breaks down laughing at the statement above gets a cookie. :)

Anway, my point is that arguing with certain operations being "natural" and therefore "naturally" represented by certain operators doesn't hold all that well except for a pretty small number of concepts. And that the absence of a feature that has only a small range of non-abusive uses is a very poor reason to denigrate a language.

2005-10-26 Reply Admin

brazzy:
And that the absence of a feature that has only a small range of non-abusive uses is a very poor reason to denigrate a language.

That operator overloading only has a very small set of "valid" utility is subjective. I for one have used it in many and diverse situations, yet I have yet to have any programmer consider my solutions improper. I'd even go as far as to say that given forethought, sanity and judgement on the part of the programmer the set of valid uses for operator overload (to reflect "natural" syntax, to enhance code efficiency and readability, to represent certain problemsand data, etc) is principally infinite. Again, it is very arrogant to presume that one's understanding or usage pattern is representative of the situation "as it really is" or should be. However, humility is almost always the first victim when discussions turns to debates. Now, this might be false, but I get the feeling that you argue rather from idealism than from pragmaticism. And is so, perhaps is should be considered that another of the very code C++ principles is pragmaticism rather than idealism.

Conversely, related to your argument, one could just as well argue, from the other side, that if there is a well defined set of common problems to which a certain facility is an obvious solution and that solution does not complicate the compiler (which operator overloading does not - it is "sugar" for functions, as has been argued here) then it is neglectful, depending on the facility perhaps even criminally neglectful, to withold that solution from the programmers.

Anyway, I can't speak for the rest of the posters here, but I at least have not "denigrated" Java for lacking operator overloads. Yes, I miss the feature when I code Java, and I do consider the operator overloads for Java's strings an unaesthetic break with the languages's principles, but ti is a design principle of an established language and I live with it. Again, there is no debade whether Java or C++ is "better", they are for different things. Pragmatics.

brazzy · 2005-10-26 Reply Admin

Anonymous:
Now, this might be false, but I get the feeling that you argue rather from idealism than from pragmaticism. And is so, perhaps is should be considered that another of the very code C++ principles is pragmaticism rather than idealism.

I'd say that it is important to find a balance between idealism and pragmatism. Unmaintainable ad hoc kludges are very pragmatic, or at least they seem to be to the people who write them, even if they are not, in the long run.

And isn't it quite pragmatic to forego an easily abusable feature that you might be useful to you, but not every often, because you'll ALSO have to maintain code written by people who will abuse it horribly? The usual answer is that they can and will write horrible code anyway, but at least it won't be quite as complex and easily overlooked.

2005-10-26 Reply Admin

brazzy:
Anonymous:
Now, this might be false, but I get the feeling that you argue rather from idealism than from pragmaticism. And is so, perhaps is should be considered that another of the very code C++ principles is pragmaticism rather than idealism.

I'd say that it is important to find a balance between idealism and pragmatism. Unmaintainable ad hoc kludges are very pragmatic, or at least they seem to be to the people who write them, even if they are not, in the long run.

And isn't it quite pragmatic to forego an easily abusable feature that you might be useful to you, but not every often, because you'll ALSO have to maintain code written by people who will abuse it horribly? The usual answer is that they can and will write horrible code anyway, but at least it won't be quite as complex and easily overlooked.

As I said, and as is shown reply upon reply, this is a fundamental difference in philosophies. In the one design philosophy the programmers are trusted, in the other programmers are trusted to be incompetent. With freedom comes responsibility. When C++ programmer have leveled enough to implement operator overloading they usually understand how to use it properly. It is no use trying to protect against Machiavelli, and it often imposes grave restrictions to protect against Murphy. I myself prefer languages where the programmer is trusted.

Point in case, look at the code posted at TDWTF: it is basically Java, C#, VB and JavaScript/SQL. C and C++ is dramatically underrepresentated. The feature basically is very seldom misapplied in real life. That is the reason I suggested you might be arguing more from ideology than pragmaticism.

I, and most experienced programmers, concede that C++ is a difficult language filled with powerful facilities that can be horribly misapplied. And newbie programmers sometimes produce monstrosities. However, most programmer, and principally all experienced ones, put the power of these features to proper use. Likewise, Java too incorporates powerful (framework) features, as well as inconsistencies, strange design decision and mild to severe restrictions. And as for C++, newbie Java programmers often misapply language features and toolsets, and produce utterly repulsive freaks of codeture. However, most experienced programmers will not, instead producing beautiful and functional code; as will all programmers with the proper skill and intellect regardless of platform.

Java, too, has toolsets that lends to horrible and incomprehensive code. These, however, are often outside the language; Javabeans (not to speak of enterprise beans!), and the myrriad of other frameworks becoming required practice, as well as the enthusiastic but often misguided berserk creation and application of patterns. In my opinion, this is a severe issue of much more acute significance than that some malicious coder with a pink slip and a grudge or a 1337 kiddie misapplying operator overloads.

Maurits · 2005-10-26 Reply Admin

AJR:

using "setA + setB" for union and "setA - setB" for set difference is entirely reasonable. The negation of a set could then quite reasonably be the complement set (which would, admittedly, be tricky to represent in some circumstances.)

Unfortunatly, it would also be quite reasonable -- but WRONG* -- to expect that
setA - setB = setA + (-setB)

* unless setB is the complement of setA

2005-10-27 Reply Admin

Anonymous:
This happens when you have to follow brain dead coding standards and design rules. I bet that poor guy had been hit over his head with a 200 page style guide, because he once hard coded a number greater 3. This was his little revenge: Code in full compliance with the rules, so no quality clown could reject the code.

Hard-coding strings is as bad as hard-coding numbers.

ammoQ · 2005-10-27 Reply Admin

brazzy:

Because it's "natural" that if you have addition, you also have subtraction.

For natural numbers, subtraction is _not_ defined. Of course, we tend to apply the subtraction for integers also on natural number (where it can be applied) but that is not at all part of the mathematical definition of natural number.

The first who breaks down laughing at the statement above gets a cookie. :)

Gimme gimme gimme ;-)

ammoQ · 2005-10-27 Reply Admin

Maurits:
AJR:

using "setA + setB" for union and "setA - setB" for set difference is entirely reasonable. The negation of a set could then quite reasonably be the complement set (which would, admittedly, be tricky to represent in some circumstances.)

Unfortunatly, it would also be quite reasonable -- but WRONG* -- to expect that
setA - setB = setA + (-setB)

* unless setB is the complement of setA

the following also doesn't hold in general:

setA - setB + setB = setA
setA + setB - setB = setA

setA + setB = setA -> setB = 0
setA - setB = setA -> setB = 0

(setA + setB) - setC = setA + (setB - setC)
(setA - setB) + setC = setA - (setB - setC)

brazzy · 2005-10-27 Reply Admin

ammoQ:

Gimme gimme gimme ;-)

Here ya go: [pi]

(Always wanted to try that, and it's the closest we have)

ammoQ · 2005-10-27 Reply Admin

AJR:

Sets are a really bad example to use there, since operations on sets are well defined. Sure, the symbols "+" and "-" might not be the standard ones used by mathematicians, but using "setA + setB" for union and "setA - setB" for set difference is entirely reasonable. The negation of a set could then quite reasonably be the complement set (which would, admittedly, be tricky to represent in some circumstances.)

Thinking about it, the bitwise operators "&", "|" and "~" would be much better symbols for set intersection, union and complement.

emptyset · 2005-10-27 Reply Admin

ammoQ:
Thinking about it, the bitwise operators "&", "|" and "~" would be much better symbols for set intersection, union and complement.

ampersand was employed successfully by the legions of cobra-la.

DrCode · 2005-10-27 Reply Admin

OneFactor:
But keep in mind that counting to Integer.parseInt("010") is not the same as counting to 010. [H]

I guess if you really want to you can count to Integer.parseInt("010", 8), or Integer.decode("010").intValue().

DrCode · 2005-10-27 Reply Admin

Alex Papadimoulis:

caseMgr.setValDesc(result.getResults().elementAt(Integer.parseInt("3")).toString());

In addition to the obvious, I don't think anyone has commented on the fact that it appears to be using Vector (elementAt) rather than List. Of course, there could be a good reason for that, but in my experience Vector is often used when synchronization is neither needed nor wanted, by people who just don't know any better. Given the other things wrong with this code I'd be willing to bet that's the case here.

DrCode · 2005-10-28 Reply Admin

Cyresse:
Hey, I like syntatic sugar. Writing

j = "[" + foo + "]"

to put brackets around a string is nice and simple. I never really got into Javascript too much, but I can recall doing something like

j = "[".concat(foo.concat("]"))

Why? The normal way to do

j = "[" + foo + "]"

in Javascript is

j = "[" + foo + "]"

brazzy · 2005-10-28 Reply Admin

DrCode:

In addition to the obvious, I don't think anyone has commented on the fact that it appears to be using Vector (elementAt) rather than List. Of course, there could be a good reason for that, but in my experience Vector is often used when synchronization is neither needed nor wanted, by people who just don't know any better.

Absolutely. I'd say that in upwards of 95% of all cases where Vector is used, it's because the programmer got used to it reading code and tutorials written by people who got used to it reading code and tutorials written when List didn't exist (i.e. before 1999).

ammoQ · 2005-10-28 Reply Admin

brazzy:
DrCode:

In addition to the obvious, I don't think anyone has commented on the fact that it appears to be using Vector (elementAt) rather than List. Of course, there could be a good reason for that, but in my experience Vector is often used when synchronization is neither needed nor wanted, by people who just don't know any better.

Absolutely. I'd say that in upwards of 95% of all cases where Vector is used, it's because the programmer got used to it reading code and tutorials written by people who got used to it reading code and tutorials written when List didn't exist (i.e. before 1999).

*blush*
gotta check some of my sources...

yawmark · 2005-10-28 Reply Admin

"==" that will compare the objects themselves

<nitpick>
The == operator in Java - when used with reference variables - compares reference values, not objects.
</nitpick>

2005-11-01 Reply Admin

I love you all you guys are my bestest friends in the whole world!!! I love you sooo much

2005-11-01 Reply Admin

you are nasty you perv. Yuck!!~~~ ~~~ ~~~~ ~~~~ ~~~~~ ~~~ ~~~~ ~~~~ ~~~~ ~~~~[:'(]

Pewwwwwwww

o well i love ya

2005-11-01 Reply Admin

maybe the 3 is bad and he is gay.

(jkasdjh;jd::klghd(f fmd<,fjakkuh88756888/vV?sdjslri

uehf;a t

i dont understand this site at all~~~

foxyshadis · 2005-11-01 Reply Admin

Anonymous:
(Interestingly enough, in the context of the Java vs. C++ origin of the heated debate (continuing around us as we speak), is that Java increasingly are losing grasp of its own original principles.)

If losing sight of its origins means dropping a carnival funhouse set of evolutionary extensions to the class structure in favor of a well-planned, rational formulation, and a set of powerful, easy-to-use, and nice-looking GUI apis, then I'm all for it. Sadly, all 5 gives us is little more than hodge-podge language and api evolution in random directions. (I'm assuming you mean ~Java2 origins, which is "Java" to most everyone, and not Java 1 era, which really was fairly simple and elegant for the needs of embedded software. It only became a mess when they tacked a ton of extensions on it, called it cross-platform, and got the create-and-depreciate train rolling.)

2005-11-04 Reply Admin

foxyshadis:
Anonymous:
(Interestingly enough, in the context of the Java vs. C++ origin of the heated debate (continuing around us as we speak), is that Java increasingly are losing grasp of its own original principles.)

If losing sight of its origins means dropping a carnival funhouse set of evolutionary extensions to the class structure in favor of a well-planned, rational formulation, and a set of powerful, easy-to-use, and nice-looking GUI apis, then I'm all for it. Sadly, all 5 gives us is little more than hodge-podge language and api evolution in random directions. (I'm assuming you mean ~Java2 origins, which is "Java" to most everyone, and not Java 1 era, which really was fairly simple and elegant for the needs of embedded software. It only became a mess when they tacked a ton of extensions on it, called it cross-platform, and got the create-and-depreciate train rolling.)

Which I personally think is very interesting. So, in the Java vs. C++ spirit, of this conversation, it should be noted that C++ has never compromised its original principles, and the new standard is scrutinising itself incredibly hard to maintain that.

The original Java adaptations were good and beneficial, but given the latest iterations the language has become unwieldy, unfocused and actually quite difficult for beginners -perhaps arguably even as difficult as C++- which is amusing since it is increasingly used as the first language, replacing C++, in CS edu.

Several of my Java developer friends are expressing frustration over the current state of affairs, some going as far as to say that "Java is the legacy language of tomorrow starting today", and some are already looking for or turning to replacement favorite languages, like Ruby.

Manupuri · 2007-02-28 Reply Admin

how do they get hired..

2008-07-14 Reply Admin

Simple:

He just mixed bit with byte. He thougth that int just has to bit#s : 00 0 01 1 10 2 11 3

and numbers wich are geater than 3 must be stored in a text variable of any sort...

Magic Number Superstition

Leave a comment on “Magic Number Superstition”