Syntax

What programming language has the best, cleanest and most beautiful syntax?

>>40
What can compile C11?
FVcc?

Also, the added keywords don't look like C.

Java

>>42
They shouldn't look like C, they're reserved by the implementation, if you use identifiers like them you're breaking the standard.

>>44
Backwards compatibility really pisses me off.
It's fucking 2012, both changing the source code or changing building rules isn't hard at all.

nullptr. über retarded.

>>45
Backwards compatibility really pisses me off.
Then you're a fucking retard.
Is it so hard to just include a fucking header? You know, like stdbool.h?

>>47

it can add up until it becomes a monster.

>>47
#include <stdbool.h>
#include <stdatomic.h>
#include <stdnoreturn.h>
#include <stdinline.h>
#include <stdconst.h>
...

>>49
So you would break enormous libraries of existing, efficient and well tested code just so you can avoid adding 3 or so line to your shitty toy programs?

Are you sincerely this retarded? Tell me, do you consider yourself to be a competent programmer?

>>50

>implying you can't link with libraries written in different langauges

>>50
So you think that it is good to have hundreads of programs that reimplement a standard feature instead of trivially fixing them?

Are you sincerely this retarded? Tell me, do you consider yourself to be a competent programmer? What would your mother think of you now?

>>51
Oh, I understand, you're from the imageboards, well that explains everything.

Of course only you could be this fucking retarded, what if you want to update a library to use C11 and keep working on it? With the current setup you may incrementally change the code to work with the new features, with your setup everything just breaks from the start, or you have to change all the existing code.

Oh you didn't even consider that option, did you? Because libraries to you are only these static things which don't change, because you're a fucking retarded piece of shit who write small toy programs all day. And what was that about backward compatibility, how are you even certain that you can link with other libraries if they aren't guaranteed to be binary compatible with your future binaries? Good thing you're not in charge then, isn't it? You fucking moron.

>>53

>implying porting to another language is any more difficult.
>implying the change couldn't be automated.
>implying we should include headers over and over again
>implying c syntax will still be used in 3 years.
>implying im from the imageboreds
>implying the textboreds are more mture than the imageboreds.
>implying implications that imply implications that imply contradictions.

>>52
Listen you piece of shit retard, making things like bool, noreturn and atomic keywords would break a lot of good code. Of course since you're only used to your shitty small toy programs you think migrating to a new standard is trivial. Well welcome to the real world you piece of shit retard, where programs are over 100 lines long and things need to work.

Oh wait, I just realized that you think the libraries I've been talking about actually implement standard features, holy shit, I had no idea someone could actually be this retarded. I'm going to enumerate the following so even someone of your intellectual level should be able to follow, I'll even write in all caps so the letters are nice and big.

- NORETURN IS A NEW FUCKING FEATURE YOU PIECE OF SHIT RETARD
- ATOMICS ARE A NEW FUCKING FEATURE YOU PIECE OF SHIT MORON

They weren't features before, so people implemented them, are you sincerely this fucking dumb?

ALL CHILDREN IN THE THREAD, SHUT THE FUCK UP!

C and C derivatives are shit, faggots. Get that through your thick skulls.

>>54
When we're not talking about your shitty toy programs the fix is anything but trivial, the fact that you actually believe that indicates that you have never written a program that's more than 100 lines. Libraries implement atomics differently, so you can't just do a simple regex replace over all the files.

Fuck off back to the imageboards you fucking retard.

>>57

>implying a context sensitive substitution of variable names couldn't resolve name collisions with the new reserved words

>>56

>implying c will meet all of your needs equally well as every c derivative that will ever exist, in every possible task that will ever exist

oh wait, that might actually be right. nevermind.

>>56
Pull my finger.

>>58
That's not the problem you god damned piece of shit moron, are you honestly this fucking dense? The problem is migrating to the new features, learn to read you fucking moron, the old features probably won't work exactly as the new ones do in the standard so there is some change needed. You want to use the new features in your project, why do you think the committee adds them, for fun? With the current setup you can incrementally change each file without breaking anything, with your retarded piece of shit setup everything just breaks instantly just because you're too fucking dumb to include a header file.

>>55
Heh, no point in arguing with you, it's apparent that you consider yourself such a competent programmer to not see the obvious advantage to change part of the source code for forwards compatibility.

Now, tell me, why aren't there <stdinline.h> and <stdrestrict.h>, yet we've got <stdbool.h> in the same standard (C99), and <stdatomic.h> and <stdnoreturn.h>? Were the people in the C99 committee made of competent programmers? Are the people in the C11 committee competent programmers, then?

>implying the old features couldn't still be used when appropriate.

>>60
（　≖‿≖）
Consider it pulled.

>>62
P.J. Plauger, who used to be on the C89 committee, is a programming god.

>>61
No, the point was exactly renaming any atomic and noreturn identifier into something else, since those are now reserved identifiers. Migrating to new features is indeed non-trivial, but that is not the point of this discussion.

>>63
It's never appropriate you fucking moron.

>>62
Are you seriously too fucking dumb to operate Google? The C99 committee decided that the existing de-facto definitions of inline and restrict were sufficient to be accepted without change while bool was often implemented differently so they used that setup. The two other headers weren't even in C99 but of course I don't expect your monkey ass to get even shit as simple as that right.

>>66
They're not reserved identifiers you god damned moron, they become reserved identifiers only if you include <stdatomic.h> or <noreturn.h> which is the entire fucking point of those fucking headers you fucking retard. Anyone could write a fucking #define noreturn _Noreturn, there's a reason for the headers being there, have you even read the fucking standard you fucking moron?

>>67
You still don't seem to understand what I'm trying to say.

>>68
Let me correct myself, then,
No, the point was exactly renaming any atomic and noreturn identifier into something else, if they were reserved identifiers.
The point still stands. Go back to /g/, now.

>>70
No learn to read you fucking moron, the discussion was about the necessity of the new standard headers. Try again you piece of shit retard, try following the links this time and educate yourself before posting.

So it seems that we have come to the conclusion that name collisions with new reserved words can be solved in two ways.

1. Include a header that introduces the reserved words in files that have been reviewed or updates to no longer use names that conflict with the words.

2. Use a script to parse your programs and substitute uses of reserved words for identifiers with other words that do not clash. This actually isn't necessarily that trivial, seeing how names can be used across many different files. Getting a consistent substitution name for atomic could be tricky. I guess it would entail ordering all words by how interchangeable they are with the word atomic, and then picking the one that is used nowhere else in the program. This isn't that different from going from C to seeples, for the keywords class and this, although there are a few syntactic differences as well. You wouldn't have to include a special language specific header file in every single C11 source file you write. Could you imagine having to include a special C++ definitions header file to ensure backwards compatibility with C?

Syntax is largely immaterial. Semantics is much more important. Homoiconicty is a good thing.

Haskell, CoffeeScript

>>74
I forgot Smalltalk

>>73
But (inconsistent) syntax surely affects readability. Just count how many argue about sexps.
I still think that following the original spirit and style is the best way to keep things uniform.

But, I'll just #include <void.h> for now.

>>15
END
END
END
END
...
MAKE IT STOP

>>55
#define stdc_atomic atomic
#define atomic some_non_reserved_identifier
Just two lines of code, ``faggot.''

>>78
So now both stdc_atomic and atomic get replaced with some_non_reserved_identifier, so now you're colliding even more code and you can't use stdatomic.h anywhere, even in code  without any pre-existing collisions, how does that make the situation any better?

Oh I get it, your monkey ass is too fucking retarded to even understand how something as simple as #define works, wow, you're really fucking dumb, go read any basic tutorial on the C pre-processor then come back you fucking moron. I actually didn't think it was possible for people to IQs in the negative, but I just think you've proved me wrong.