GYAST

Stands for GYAST is yet another Sepples thread.

We all know that Sepples has very limited practical applications on the client end (device drivers and... games, that's about it). Is there a way to save Sepples from being such a black pit of death as far as the language goes?

I mean, looking at the problems:

1. Ridiculous, cloudy, shoddy, shitty, cluttered, pig-disgusting syntax. And they keep adding MORE to this every single standard revision. Sepples is supposed to provide only basic stuff, okay, I get it - that means you should not have to look up a list to get every single keyword. Furthermore, the stuff they're adding is utterly useless. constexpr, seriously? What about different keywords for the fuckin' 4+ semantic uses of static?

2. That ancient as fuck linking system. Drop backward compatibility already, it's not 19-fucking-70. Using such an ancient linker and requiring all these ridiculous forward/ass-backward declarations is a huge maintenance cost that doesn't need to be there. This should be more like D. This also removes about 90% of the necessity of the preprocessor, and then we can truly keep its use limited.

3. There should at least be minimal garbage collection in terms of exceptions. This isn't a matter of giving up control of the memory, it adds programmer control because you can actually USE exceptions as they were intended to be used.

4. Sepples is a hacked version of See, that needs to go away. They need to start treating it like an independent language, otherwise it's going to forever be shit because of this fact.

Nobody at this point that's still using See sees the benefit in switching, obviously (probably because there aren't many benefits). Nobody's writing See code for Sepples. Just end this tired relationship already. Nobody cares about portable to Sepples from See anymore. They've had plenty of time, they've made their choices, that's that. Move on.

5. The STL. Morph the STL into a standard library. Add things that everyone uses (such as the various classes of smart pointers). Add the standard libraries already (such as cmath, ctime, etc.) as modules of this standard library. This is somewhat like the D suggestion.

Understand that what's needed today isn't minimal, bare-bones languages, but powerful intrinsic features that you can use if you so choose instead of having to waste the resources programming your own.

6. Parsing of templates. There should not be one copy of the same exact class per each source file where it's used.

I'm sure there's more, but you probably see what I'm going for with this.

>>1
YHBT

7. Sepples needs to unify its object system and its template system. As it stands we've got foo.bar(a) and bar(foo, a). There's no call for this redundancy, and the less flexible dot notation should be dropped in favor of proper generic functions. We could forget our misunderstanding of information hiding as "using the compiler to prevent programmers from accessing innards they already know they ought not to", and drop the private member/friend class bullshit.

8. Sepples needs to add type inference and remove the need for every single variable and function to be explicitly typed.

9. Sepples should allow the definition of custom operators, including the use of Unicode characters for these. Considering it already allows operator overloading, not allowing the creation of new operators is just half-assery. Any time you're expressing standard mathematical formulas in a Sepples program, being able to use the traditional symbols would be a win.

10. Sepples should make its whitespace rules stricter, perhaps requiring whitespace around everything but braces of all kinds. Not only would it settle the int*a spacing debate once and for all, and prevent over-dense unspaced formulas, it would mean that variables and functions could be more flexibly named, which, IMO, is a very nice feature.

I know that Sepples stands for C++ but what does See stand for?

>>1,3
The solution to all these problems is to not use Sepples, something the rest of us figured out a long time ago.

>>4
Scheme of course.

>>5
I'm aware of this fact, I specified the thread asking if we can and what we could do to save Sepples from being such a pit of death.

The concept of being so close to the machine's workings while supporting powerful abstractions is a noble concept, it's just executed like shit in Sepples.

>>3
Speaking from a perspective of maintenance, the necessity for strong static typing is generally a plus. Sepplesox is adding the auto keyword for long, bulky, garbage, or confusing type definitions.

http://en.wikipedia.org/wiki/C%2B%2B0x#Type_inference

However, I fully support the rest of your points.

8. Sepples needs to add type inference and remove the need for every single variable and function to be explicitly typed.
Had me until here. 6/10

>>8
I think the second post is a troll.

>>1,3
:yawn:

I can see by you‘re painfully clichèd whining that your an EXPERT language designer.  Go ahead and implement you‘re ''ideas``.  Watch as nobody uses them, because its just another generic toy language thats not really good at anything.

>>10
That's what people said about Java, when it first implemented in toasters and microwaves.
That's also what people said about crazy beeyarney and his sepples, back in the 80's.
You can't expect innovation if you never try

>>11
True innovation is not what people want in a programming language. They just want AIDS.

>>12
False. If that were true, Sepples would be the godliest language. I would almost suggest that your position sounds similar to that of FrozenVoid, but he was always much more subtle about his trolling.

For that reason, 6/10. It didn't elicit strong feelings at all, but it was well-crafted.

>>12
Do you really think anything in >>1,3 is innovative?  Really?

>>7
Speaking from a perspective of maintenance, the necessity for strong static typing is generally a plus.
I never suggested they drop static typing. I suggested they add proper type inference to remove the need for manual type annotations on every single thing. It would still be statically typed as strongly as it ever was.

>>8
Is it possible that you're unclear on what that actually means?

>>13
Not trolling. Just bitter, bitter truth.

Excuse me while I tally up my old regrets and then wash down half a pound of Tylenol with a handle of cheap bourbon.

(The actual trolling here is that I'm not using sage.)

>>15
So... what? Some things are dynamically typed, but others aren't?

You're not making a whole lot of sense.

>>17
No. Nothing is dynamically typed and everything is statically typed. It's just not necessary to annotate all types.

>>18
Stop contradicting yourself. If you don't annotate types, how do you declare variables?

>>19
I guess there could be a non-specific keyword. Perhaps auto, indicating that the type will be automatically inferred.

Also I'm not contradicting myself.

>>20
So... you are pushing a hard right wing Sepplesox agenda? Sage for attempting to make a cluttered and contrived language even more cluttered and contrived, and also for being a troll.

>>21
Wut. Yes, I do happen to be aware that some form of type inference is being added to Sepplesox, and that it will be using that keyword. No, I'm obviously not suggesting more bullshit. In fact, if you read the thread, you'll notice that I'm proposing the deletion of some things to simplify the language.

>>1
3. There should at least be minimal garbage collection in terms of exceptions. This isn't a matter of giving up control of the memory, it adds programmer control because you can actually USE exceptions as they were intended to be used.

Wait, what? You mean, like, you throw an exception and all you're dynamic memory that should be free is freed? Like, as if you have used an std::auto_ptr that was in the Standard long before you where born? Oh, but wait, it is in the Standard, so you could use it!

>>23
I'm a grammar trolling meme fan, but I am not a non-FQA-reader trolling meme fan. Your post makes me sad.

Also, I recommend reading http://yosefk.com/c++fqa/ to any that feel like Sepples could, potentially, in a universe where Bjarne makes sense, be saved. The excerpt:

This could be a good idea in some cases if C++ exceptions were any good. They aren't, and can't be - as usual, because of another C++ "feature", the oh-so-efficient manual memory management. If we use exceptions, we have to write exception-safe code - code which frees all resources when the control is transferred from the point of failure (throw) to the point where explicit error handling is done (catch). And the vast majority of "resources" happens to be memory, which is managed manually in C++. To solve this, you are supposed to use RAII, meaning that all pointers have to be "smart" (be wrapped in classes freeing the memory in the destructor, and then you have to design their copying semantics, and...). Exception safe C++ code is almost infeasible to achieve in a non-trivial program.

Of course, C++ exceptions have other flaws, following from still other C++ misfeatures. For example, the above-mentioned lack of reflection in the special case of exceptions means that when you catch an exception, you can't get the call stack describing the context where it was thrown. This means that debugging illegal pointer dereferencing may be easier than figuring out why an exception was thrown, since a debugger will list the call stack in many cases of the former.

>>7
Kill everyone on the sepples committee.
No other solution to this spiral of bullshit exists.

>>24
The FQA is a troll in itself.  All of these things are solvable with a tiny bit of forethought.

>>26
All
0/10

>>26
FQA? Troll? Nice attempt. I'll give it a 1/10 for originality.

>>24
You'll be amazed, but I actually read the whole FQA.
And then I really learned C++.
You see, FQA is great for this kind of "programmer", who was taught C, then told that C++ is just the same, but with new/delete instead of malloc/free, tried to use it and predictably failed, switched to C# or Java or Python or whatever and lived happily ever after. Except that he still had this nagging suspicion, that it was all his fault, since there are a lot of C++ programmers somehow managing to create useful soft, and that's where FQA comes handily, kinda asserting that all these programmers are masochists and should have known better and are generally dumb. I mean, that's myself a year back I'm describing.

So. While FQA is generally right, C++ IS a terrible language with a metric shitload of quirks, ambiguities, WTFs and so on, it is still usable and in fact quite nice, moreover, has killer features, when you get to know it and use it the way it's supposed to be used (as an extremely powerful C preprocessor).

And right there he is plainly wrong. First, you don't write your own smart pointers, 90% of the time you just use std::auto_ptr, then switch to boost or, more recently, tr1. In a good C++ program there is not a single `delete`. I don't know what he meant by ''sufficiently complex``, I recently wrote quite a complex one that didn't have a single `delete`, using auto_ptr only. A bridge from tcp/ip-based service provider to Websphere MQ -- does that sound complex enough?

Second, you don't compare C++ to the GC languages like C#, Java, Python, whatever. It has different modus operandi. C++ should be compared to C, because it is C on steroids, it was made to be and it is. Do you want me to describe in a bloody details how error processing is routinely implemented in C and C++, and how C++'s RAII makes C to look like a not-very-high-level assembler, a something from the stone age of programming?

>>29
Who would call their standard library STD?

>>29
The point wasn't the first paragraph of the quote. The second paragraph references information from the first, which was the point of including the first paragraph.

I don't disagree that ONE of the problems is solved by using smart pointers. However, it still doesn't fix the other completely valid complaint that simply isn't fixable in the current revision of Sepples.

Also, I'm a faggot quote trolling meme fan. I approve of your post.

>>31
simply isn't fixable
Problem: a class in the standard library doesn't implement my entire application.
Solution: ???

>>32
The problem has nothing to do with smart pointers. The problem is the lack of context for call stack traversal in exceptions because of the way resources are handled.

That has nothing to do with the STL. I give you a 4/10, I raged a bit.

>>1
We all know that Sepples has very limited practical applications on the client end (device drivers and... games, that's about it). Is there a way to save Sepples from being such a black pit of death as far as the language goes?

SEPPLES is not recommended at all for device driver development. If you really want to use it for that, you'll have to use a limited subset of it and be very careful about what you do. You're better off using C for device driver development. This stands true for both *nix and Windows world.

>>34
gtfo apple fanboy

>>35
Apple? What? I simply said using Sepples in DECENT operating systems for driver development is not recommended. I have never done any Mac OS X development in my life.

>>33
Exceptions were not meant as a way to receive a nice stacktrace when your program fails. Their purpose was to banish C-style ''if (errorcode = dosomething()) goto cleanup`` (and no, it's THE most readable and robust way to deal with it, despite using two most abhorrent C features (or is it three, if I include ''zero return value indicates success``?), which renders C++ inconveniences in a new light, doesn't it?). That is accomplished.

Nonetheless, I find the impossibility to have a nice stack trace disturbing, yes. Well, I kind of work around that by

    #define LOGGED std::auto_ptr<Logger> __logobj = new Logger(__function__)

... with my Logger class logging "begin function %s"/"end function %s" in its respective constructor/destructor. And I do find "macros are evil" attitude of the C++ FAQ disturbing too. And I do find my ability to do something like that, even when I'm working around C++ limitations, to be, well, WHY I CANT HAS THAT IN C#??!!

>>1
I bet you probably don't even know where the Sepples meme came from.

I meant
    #define LOGGED std::auto_ptr<Logger> __logobj(__function__)
C++ is a bitch in respect to what it does to you, me failing is an example. But it is a [u][o][i][b]MAGNIFICENT[b][i][o][u] bitch, really.

I meant
    #define LOGGED std::auto_ptr<Logger> __logobj(__function__)
C++ is a bitch in respect to what it does to you, me failing is an example. But it is a MAGNIFICENT bitch, really.

>>33
I never said anything about the STL, and you're a goddamn moron.

>>41
Oh, okay, I guess there's some OTHER standard library that I don't know about.

>>37
Why not just
#define LOGGED Logger __logobj(__FUNCTION__);
?

>>29
nice ... has killer features
Let's not exaggerate here. I was with you up through "usable".

Second, you don't compare C++ to the GC languages like C#, Java, Python, whatever. It has different modus operandi. C++ should be compared to C, because it is C on steroids, it was made to be and it is.
Yes, I damn well do compare it to those languages, because they're competing in the same niche. Sepples is more comparable to them than to C, which is a reasonably good portable assembler.

C++ should be compared to C, because it is C on steroids, it was made to be and it is.
and it lacks features that c has had for 10 fucking years.

>>45
Name [u]one[/u].

>>46
Oh, [/u].

>>46
sepples can't do this:
http://dis.4chan.org/read/prog/1240769946/12

Bamperu. GYAST reminds me of yeast and gynecology.

>>48
Compiles and runs perfectly under G++.

>>50
Gepples? Seriously?

Horrible!

Gnipples

>>50
it shouldn't. that's horribly invalid as sepples code.
unless you're using sepplesox mode, but that's like compiling c code in c1x mode.

>>53
Besides the fact that it does compile, and compiles without warnings by changing not more than twenty characters, I would be delighted if you informed me how this example demonstrates something you can do in Se that is not possible in Sepples. That is, how is the exact function of this program- whether or not the actual implementation remains the same, not possible to achieve in Sepples?

>>54
yeah, it compiles if you rewrite half of it and make it look like shit.

>>54
EXPERT ANAL TOURING

EXPERT >>56

>>48
Why would you even want to do that?

>>56
That's funny because Alan Turing was gay.

>>58
That‘s funny because your gay.

>>59
What about my gay?

>>60
Hes gay.

>>61
His gay is gay? I suppose this makes logical sense.

>>62
It's a self-evident statement; a tautology.
And so life imitates art.

MORE LIKE
BLACK PIT OF MEMORY LEAKS
AMIRITE LOLLLLLLLLLLLLLLLLLLLLLLLZzz!!11oNE!!1ONE1!

>>64
eat dicks, fag

SEPPLES

/prog/ will be spammed continuously until further notice. we apologize for any inconvenience this may cause.