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.

>>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.