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.

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.