Name: Anonymous 2009-04-27 17:04
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.
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.