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.

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