sepples

In general, I have to admit that I’m a little bit scared of language features that hide things. When you see the code

i = j * 5;

… in C you know, at least, that j is being multiplied by five and the results stored in i.

But if you see that same snippet of code in C++, you don’t know anything. Nothing. The only way to know what’s really happening in C++ is to find out what types i and j are, something which might be declared somewhere altogether else. That’s because j might be of a type that has operator* overloaded and it does something terribly witty when you try to multiply it. And i might be of a type that has operator= overloaded, and the types might not be compatible so an automatic type coercion function might end up being called. And the only way to find out is not only to check the type of the variables, but to find the code that implements that type, and God help you if there’s inheritance somewhere, because now you have to traipse all the way up the class hierarchy all by yourself trying to find where that code really is, and if there’s polymorphism somewhere, you’re really in trouble because it’s not enough to know what type i and j are declared, you have to know what type they are right now, which might involve inspecting an arbitrary amount of code and you can never really be sure if you’ve looked everywhere thanks to the halting problem (phew!).

When you see i=j*5 in C++ you are really on your own, bubby, and that, in my mind, reduces the ability to detect possible problems just by looking at code.

None of this was supposed to matter, of course. When you do clever-schoolboy things like override operator*, this is meant to be to help you provide a nice waterproof abstraction. Golly, j is a Unicode String type, and multiplying a Unicode String by an integer is obviously a good abstraction for converting Traditional Chinese to Standard Chinese, right?

>>1
Gee, that looks familiar.

http://www.joelonsoftware.com/articles/Wrong.html

yeah i agree. i find operator overloading to be a monumentally unnecessary and retarded idea. maybe there's an IDE out there that will offer you a different color code for operators it knows are overloaded for the type in the operation you're working on?

Stuff like this makes me glad that, if I ever need to, I can just call typeof() in javascript.

Stuff like this makes me glad that, if I ever need to, I can just use :t in ghci.

Stuff like this makes me glad that, if I ever need to, I can just avoid using 90% of C++'s features.  Or 100% since I mostly use C. And no, I do not mean "C compiled as C++" / procedural Sepples.

>>3
It sounds like a remarkably useful idea. But I avoid sepples like the plague, so what do I know.

Then again, in C the above could very well be something like foo_multiply(&i, j, 5)
And it still could be converting Chinese unicode strings. But that would be retarded, so no one does that.

>>8
delicious tears

>The only way to know what’s really happening in C++ is to find out what types i and j are

shouldn't you know this anyway?

>>10
They're unicode strings, of course. Why else would you use *?

>>10
Only if the codebase isn't shit.

Who implements operator overloading but not user-defined operators, anyway?

>>10
FUCK YOU! I program by typing random characters into my IDE and letting it decide what to do.

>>14
Wouldn't you still know the type in that case!?

… in C you know, at least, that j is being multiplied by five and the results stored in i.

No, you don't. You are now on a verge of a beautiful discovery, the discovery of your inner #define. Fag.

>>16
#define MY_ANUS

I absolutely luuuv @_____@ programming langauges <3 and my fav is sepples!!!

>>17
Fixed that for you.

#ifndef MY_ANUS
#define MY_ANUS
#endif

>>3
Sure, except that the clusterfuck that is C++ compilation makes it difficult to find an IDE that can reliably parse your code.

>>16
At least that's somewhat easy to identify (via code). Preprocessing C does not require essentially compiling the whole program. Never mind that, what fucking retard would #define j to something? (Or, for that matter, who would override = or * to do nonsensical things like >>1's examples? Actually, this whole thread is stupid.)

>>19
（　≖‿≖）

（≖ - ≖  ）;;

>>21
I am sure, in your total lack of industry experience, you have never come across idiots. Not everyone is so lucky. Languages like sepples that make even simple things wildly complicated tend to attract idiots in droves to brag about things like correctly parsing a string, or telling if a number in a dialog box violates some constraints. Oh, they don't say it like that, of course, they make it sound like a very difficult problem, but when you boil it down to its essentials, they're parsing a fucking string.

Enjoy wherever you are. The real world is shit.

>>24
you should change jobs

>>25
I just changed languages.

The real crime here is that >>2 memorizes Joel Sprolsky essays.

>>27
The real crime here is that people defend C++.

>>27
JOEL SPROLSKY IS A JEWISH FAGGOT DO NOT READ HIS ESSAYS OTHER WISE YOU WILL BECOME A JEWISH FAGGOT, IF YOU ARE NOT ALREADY

>>29
oh fuck

>>29
I read his unicode essay serveral months ago. I've been scrubbing, but the dirt won't come off HELP ME ?PROG?

>>27
Actually I had _just_ read it. I was linked there from the Cat's Eye page about Dieter. Given the esolang thread, that's probably where OP got it.

>>32
confirmed

Java does not have operator overloading.  Gets rid of one breed of idiots, but unwittingly invites a new breed of idiots.

I don't like operator overloading myself.  It obfuscates the code more times than it helps, and can easily be substituted for functions and methods.  As a former thread said, the only reason I can see justifying this is the wish to compose code with a mathematical format for when the code does mathematical things, such as vector and matrix work.

(define + -)

That's actually a good idea; you could use the * operator for translating strings, as long as the element on the right is a valid language identifier.

>>34
I like the idea of setting aside certain operators purely for the use of overloading. For example, prefix with # or something (whatever doesn't ruin your grammar.) Things can still get ugly there too. I'm not sure how common it is for that to really be a problem... I generally don't use such languages.

Overloading operators makes sense in very limited contexts. Most of the time where it's used, it is idiotic and only helps to make the code harder to read and maintain.

>>34
Which is the whole point.  If you use it right, operator overloading is beautiful.  It changes something like:

Vector *c = a->plus(b);

into

Vector *c = a + b;

It takes the same amount of time to look up what Vector::operator+ does and what Vector::plus() does.

Common Lisp does not support "operator overloading" by default for performance reasons (avoid adding a generic method dispatch on each operation, however, some implementations do provide ways to control that mechanism directly), but it's easy to implement it by making a new package and shadowing the symbols you want to override (or shadowing them in the current package), so in the end you can implement "operator overloading" without much trouble. I don't see people doing it too often, but it does have its uses. The problems which come with C++'s operator overloading are not that visible in CL, as the entire implementation can be easily inspected live, so you can find out what any symbol is supposed to be doing, and even where in the code it is defined if you compiled that specific piece of code with enough debug settings.

>>39
As true as that is, it speaks nothing for the problem of not knowing the type. (If it weren't possible to be ignorant of the type, I don't think many people would care about C++. Scary thought.)

>>39
It's retarded. If you want to make your own language, use a lisp.

>>39
This just highlights how dumb operators and dot-style method calls are.

>>43
This. Of course operator overloading looks better than sepples pointer method dispatch.

The bigger problems are infix notation and the lack of multiple dispatch. Where are the lispfags advocating plus(a, b)?

>>43
Haha, agreed.  I think we can all agree that it we can be thankful it isn't shitty Lisp style, though.

>>45
Even Lisp the way Ctarded newbies write it is better than the sort of thing you like, whatever that may be.

(map high-five (map prog-quote '(42 43 44 46)))

>>42-44,46,47
Make it less obvious when you multipost in the future!

>>48
Be more correct when you assume in the past!

>>49
CORRECT MY ANUS

Don't change these.

Name:		Email:
Entire Thread Thread List