Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
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) 307

"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 but wait; there are markings (Score 1) 128

The abos are not so innocent as the liberals want to portray them after all.

Here's the thing: the upside of inventing a writing system is world domination; the downside is finally having to admit in public that you are a real ass (and always have been).

In the above, "you" is a set of nesting dolls, innermost being the fifty-year-old white male technocrats of western European origin who treat Wikipedia as their private, personal playgrounds (thence to aging white European males, white European males, white males, whites altogether, etc.)

Here's the second thing: after a society invents writing, soon the society has written myths (with serious legacy entrenchment) that innocence preceded the current sad state of affairs (how-far-I-have-fallen porn, not that the larger consequences can't be remedied by kneeling under the right cumulus cloud for a thoroughly abject sixty seconds).

Society will re-invent writing over and over again (movable type, Movable Type) before the reversal of true illumination makes the least headway: that the human asshole apogee was attained circa the advent of the original edged weapon.

As far as the abos go, they all need to repeat to themselves "there but for the grace of God go I", unless they think their ancestors truly enlightened enough to not have had even the most remote possibility of inventing any form of written record, whatsoever (best if you're not much past the wreathie leafy loin cloth, because any loose thread threatens to quipu a long record, and then immediately you're on the outie asshole train along with every other post-prehistoric posse of mugs, pugs, and thugs).

Comment Re:Important milestone (Score 1, Flamebait) 142

Google's AI is literally leaps-and-bounds ahead of the game in that respect as the search space is so much unbelievably huger than chess that chess is laughable in comparison.

Most people are too nice to point this out, but what you just wrote here amounts to waving a bright red "I'm an idiot" flag.

Consider this: the search space of Go 25x25 is so much unbelievably huger than Go 19x19 that Go 19x19 is laughable in comparison.

But wait, I'm not done.

Consider this: the search space of Go 37x37 is so much unbelievably huger than Go 25x25 that Go 25x25 is laughable in comparison.

Just two strides, and I'm already breaking into a Cantor.

Consider this: the search space of AES 512 is so much unbelievably huger than AES 256 that AES 256 is laughable in comparison.

Are you still laughing?

Check out Game complexity. By your chosen criteria, Connect6 19x19 two decimal orders of magnitude more manly than mere Go.

Really? That's the standard you judge by?

Comment Re:One obvious improvement (Score 1) 186

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) 186

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) 186

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:How large?!? (Score 1) 293

The journalism curriculum needs a lot more basic science in it.

The problem wasn't in TFA, it was in the submitter's headline and the consequent lack of editing or fact-checking that it received from a Slashdot "editor." I'm unsure whether that bespeaks more of a need for basic science/math education among Slashdot submitters or a need for a Turing test for Slashdot editors to see if they're just bots approving random submissions based on flamebait keywords. I'm pretty sure I could just completely fabricate a story titled "Trump iPhones Zuckerberg's Laid Off IT Workers and Stallman To Net Neutrality Android Is Awesome" and see it sail through unchecked.

Comment Re:One obvious improvement (Score 1) 186

"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) 186

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) 186

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.

Slashdot Top Deals

For every bloke who makes his mark, there's half a dozen waiting to rub it out. -- Andy Capp

Working...