Follow Slashdot stories on Twitter


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:Deliberately missing the forest for the trees (Score 1) 379

The weather comment was meant as a joke. I should have put a smiley in to make that clearer.

What I wear has no bearing on this discussion.

The simple fact is that when a place has expensive housing costs, it's because there is a lot of competition for that housing. And the reason for a lot of competition for housing is that a lot of people want to live there. And believe me, people have reasons that they want to live in a place, it's not "peer pressure" or whatever reason you're making up because you can't think of one.

I'm genuinely happy that you like where you live and that it's an inexpensive place to live. Many young people, especially those who are "upwardly mobile" because they work in a high paying industry, really want to live in an urban place with alot of "action". When they get to be old guys many of them lose interest in that and the equations change, and they move elsewhere. I'm quite certain that you've seen this pattern already even if you don't recognize it.

You sound a lot like my dad, who I feel is very lucky to have the mindset he does: he really loves living in one of the cheapest places in the U.S. (northeastern Ohio). His cost of living is absurdly low and he was able to retire to a comfortable life of doing whatever he wants, alot of which involves outdoor activities like boating, fishing, and hunting that are plentiful and cheap in that area. It's the lucky person who naturally wants to live in the place that many other people are fleeing, because their cost of living will be so low.

Well he bought a house in Florida recently because he couldn't stand Ohio winters any more, but half a year in Ohio and the other half in Florida really is the best of both worlds for him, and it's all doable because of the low cost of living of the areas he lives in.

Now I could spout off about how I cannot comprehend how someone would want to live in a place where the housing is cheap because it mostly sucks there, but I won't. I recognize that different people like different things and I'm not going to assume that other people are unjustified in their choices. That feels alot like a superiority complex trying to get out.

Comment Re:Deliberately missing the forest for the trees (Score 1) 379

"Yes, the weather is generally nice"

You're a liar. You've never actually been to San Francisco.

Also, why do you think it's worth your time to pontificate on why you don't understand why someone else likes something that you don't? I mean if you're really "just another old guy" surely you've gathered enough wisdom in your time on earth to realize that a lot of different people like a lot of different things, and if you can't understand why someone likes something, the reason is probably NOT because they are deluded, but it's actually because you're just not familiar enough with the thing to know it's good qualities, or maybe it's just fundamentally not your cup of tea.

I mean, seriously. I think your entire post was just to make yourself fell better about your house payment. That's how it reads anyway.

Comment Re:One obvious improvement (Score 1) 190

Yeah but at least with Add I know that a function is being called, whereas overloaded operators are exactly and specifically designed to make operations that have "normal" functionality pre-defined as part of the language, actually do something else, without any indication at the point of usage that this is occurring.

Sure if you are intimately familiar with the types involved you will not be caught off-guard very often. But "it doesn't usually bite you if you know what you're doing" is not a great argument for a language feature if you ask me.

I have written code with matrix math and I actually found it clearer to spell out what's going on more explicitly than to use overloaded operators. But that's a personal choice for sure.

Comment Re:One obvious improvement (Score 1) 190

The index() form makes it very clear that a function is being called.

Overloaded [] does not.

Pretty simple really.

The worse of all is overloaded ->, which is an operator which can normally be applied to a dereferenceable type, so you would really have no idea to even look for an overloaded operator to see if something unexpected is happening, versus [] which if you know the type is not a C style array, must be an overloaded operator.

In my experience, if there are bad paradigms available in the language, people will use them, even celebrating their ability to do something "clever" and obtuse, and eventually they will make their way into the code base. Very often it may not even be in your code base, that you have control of, but in some open source software that you have to read and understand.

Absolutely, the intelligent and rational use of language features is the responsibility of the programmer; but it's pragmatic to recognize that in a world of imperfect programmers, it's better to not have language features that generally lead to hard to understand code.

Comment Re:One obvious improvement (Score 1) 190

a + b for complex types isn't really the trouble, since we know that the compiler can only accept that syntax if the + operator has been overloaded.

What's worse is overloading [] or -> and competely fooling the programmer who has no way of knowing, without exhaustively scanning all source files, whether or not those operators are doing something unusual.

Information hiding. It's bad.

Comment Re:One obvious improvement (Score 1) 190

"so why does Nim need a feature only useful in video game inner loops"

yeah that is a bit of a straw man, I admit. We never established that operator overloading is a feature only useful in video game inner loops.

But I will say that I think it's generally only useful in a narrow and small subset of programming problems: those for which mathematical constructs already exist and for which math operators are meaningful. Most people don't write code using quaternions and matrices. General control logic and data flow algorithms are far far more common.

The worst kind of overloading in C++ is overloading for things like brackets and parenthesis and dereference. You're taking an operator which implicitly only has meaning within the language, since these are not mathematical operators, and allowing the meaning to be changed. I can buy that in narrow circumstances there is value in overloading the math operators, but the rest of them, forget it. Way more rope than necessary to hang yourself and anyone else who is unfortunate enough to read your code.

Comment Re:One obvious improvement (Score 1) 190

That's only because of some weird syntactical rules of the functional language you are using in your example.

So in:

'let a = 5 if a = 2 else a'

the variable 'a' from that point on in the scope will I guess refer to this *new* 'a' introduced by the let expression, instead of the 'a' that was passed in? That's freaking confusing.

And the 'a' in the right hand side of the let expression is the function parameter 'a', not the 'a' being introduced in the left hand side of the let expression?

Sorry that's just obtuse.

Comment Re:One obvious improvement (Score 1) 190

The ways that + can behave in C can be enumerated without knowing anything else about the program. But overloaded operators in C++ cannot be enumerated without knowing the types involved and doing an inspection on those types to see if the operator is overloaded.

It's a trade-off. Sure operator overloading allows some concise representations. But it's information hiding. That's not a trade-off that I think is wise to make. Other people obviously differ in their opinion.

Comment Re:One obvious improvement (Score 1) 190

Well I guess we've had different experiences then.

matrix.multiply(other) doesn't seem that much worse to me than matrix * other, and in my opinion is more self-documenting since I know that a function is being invoked. And have you tried to actually write coherent operator overloading for any class? My god it's ridiculous in C++; the syntax for doing so is awful and the number of niggly details you have to get right or leave yourself open to weird bugs that will only show up much later when someone else tries to do something that you didn't even think of ...

Also "smart pointers" is not a particularly good reason in C++ since it's just a memory management technique to get around C++'s lack of good memory management support.

Yeah. I'll take the "matrix.multiply" form. It's a little extra typing but in my opinion operator overloading is a fragile crutch that is ready to break at any moment and leave you flailing about on the floor.

Another point would be that the vast, vast majority of code being written is not video game inner loops. So languages that are optimized for video game inner loops are not really the most practically useful languages to the largest number of people.

Finally - if you want all of the "raw power" of C++ -- well we already have C++. Other languages do not need to duplicate those "features" that are really only useful in such a narrow domain. I mean you're not going to be writing your video game inner loops in Nim anyway, so why does Nim need a feature only useful in video game inner loops?

Comment Re:One obvious improvement (Score 1) 190

How so? There's only one name associated within the parameter internal to the function. So there's no ambiguity about which value is being assigned to.

I've *never* been confused about what it means to assign a value to an input parameter. Something like this is a common pattern and pretty useful:

function doSomething(a : String)
      if (a == "") {
          a = "some default";
    } // Now operate knowing that a is not empty

That kind of code has never confused me.

But thinking that an assignment is to the 'x' of some outer scope, when in fact I didn't realize that 'x' was re-declared within this scope and the assignment has no effect outside of this scope ... that's bitten me I don't know how many times. Especially for commonly used variable names like i, n, x ...

Comment Re:One obvious improvement (Score 1) 190

I do like that kind of polymorphism because it allows the "same" operation to be applied to different types; however, readability becomes a bit more difficult because I have to know, in my head, all of the types of all arguments to a function call in order to know which form of the function is being called, if I am reading the code and trying to follow the flow to understand what the code is doing.

So it's a trade-off. To be honest, the number of times that I've really, really wanted that kind of polymorphism versus the number of times that it's just confused me, lead me to conclude that I'd prefer to live without it. doubleToString(), intToString() really isn't *that* much more to type ...

Comment Re:One obvious improvement (Score 1) 190

Here's another unnecessary weakness:

"Parameters are constant in the procedure body. By default, their value cannot be changed because this allows the compiler to implement parameter passing in the most efficient way. If a mutable variable is needed inside the procedure, it has to be declared with var in the procedure body. Shadowing the parameter name is possible, and actually an idiom:"

Re-using parameters as variables is very useful for writing concise code. I see no reason to limit things in this way. If the compiler thinks it can do something clever to optimize parameters when they are not modified, then it can detect when parameters are not modified and just do it, without limiting the programmer.

And forcing programmers to shadow variable names to get around this limitation is just awful. Shadowing of variable names is dubious to begin with as it can lead to confusion when reading the code (you can easily lose track of the fact that there are two 'x' variables in scope, one shadowing the other), and a language "feature" that actually encourages this bad practice is awful.

Yeah I think I'm done reading about nim. My conclusion: it's designed by programmers without a whole lot of programming experience, who do not realize the more subtle design points that should be adhered to in language design. I don't need another language designed by novices.

Slashdot Top Deals

You scratch my tape, and I'll scratch yours.