Well, there's a few things I should probably get around to adding to CNoEvil[0] and ogw[1]... There always seem to be more every few months when this project reappears.
Given the idea behind this repo is to cause pain, why not add a shebang to your file [0] to make it executable.
I saw a blog post a long time ago that went into the details of how ./foo worked, and how it executed an elf file. You could register `.c` programs in the same way to be compiled and run?
Reminds me of a C++ codebase I once had to inspect that was entirely written as if it were written in Java. With camelcase naming for everything, getters and setters for every class variable, interfaces everywhere.
Also because the special characters were (and are) difficult to type on European keyboards.
Characters like []{}\|~ are behind multi-finger access and often not printed at all on the physical keys (at least in the past). You can see how this adds a hurdle to writing C…
Pascal was designed by a European, so he preferred keywords which could be typed on every international keyboard. C basically just used every symbol from 7-bit ASCII that happened to be on the keyboards in Bell Labs.
Just as example, on my slovenian QWERTZ layout: [ - altgr+f, ] - altgr+g, { - altgr+b, } - altgr+n, \ - altgr+q, | - altgr+w, ~ - altgr+1.
You get used to them, though you start feeling like a pianist after a short coding session. The one most annoying for me are the fancy javascript/typescript quotes, which I have to use all too often: ` - altgr+7.
I tried switching to US a few times, but every time muscle memory made me give up soonish - especially since there are big benefits to using same keyboard layout as other people in your office are using.
Also practically everytime I need to write a comment, commit message or email I need my č, š and ž. It's kinda nice to have them only a single keypress away.
There’s so many assumptions here about a person who’s starting to learn programming.
For starters, that they’re on Linux, they feel comfortable running complex CLI commands, they can memorize the U.S. layout just like that, and that they can type without looking at the physical keys (because changing the virtual mapping means keys produce something else than what the label says).
In reality, the learner’s first exposure to C family languages is more likely to be a website where you can run some JavaScript in a text box. And the first hurdle is to figure out how to even type {}. American developers just completely forget about that.
I've seen similar codebases as well written by people who have spent way too much time with Java. One even had it's own String class which was just a wrapper for std::string with Java-like methods.
> camelcase naming for everything, getters and setters for every class variable, interfaces everywhere
This is not far off from the guidelines in many cases, e.g. Windows code (well, not every variable of course.) A lot of Java design was copied from C++.
Can someone clarify whether this is intended as a joke or whether the author is actually confused? I mean, nothing about this makes sense: it's not "scripting"; it claims to introduce "strong typing" while it does nothing about typing; it introduces all kinds of operator aliases "modeled after Lua and Lisp" that are present in neither of these languages. But it's not an obvious parody either, so I'm genuinely not sure.
I mean he has to be serious, right: "Deprecate Lua, Python, JavaScript, Ruby and a dozen other languages, because Pretty C is the ultimate scripting language, but lightning-fast and strongly typed!!"
With C23 (nullptr, auto typing, typeof) and C11 (generics) it got more guarantees and type-related primitives. You can still do void*, but you are strongly discouraged from it.
#include "pretty.h"
void print_int(int value){
println(value);
}
int main (int argc, string argv[])
{
long value = 23849234723748234;
print_int(value);
}
How is this strongly typed?
$ cc test.c -o test && ./test
-1411401334
And to be clear, weak vs strong isn't a boolean property but a spectrum, but would be hard to argue with a straight face than C is a strongly typed language.
> The word "REPEAT" should not be used in place of "SAY AGAIN", especially in the vicinity of naval or other firing ranges, as "REPEAT" is an artillery proword defined in ACP 125 U.S. Supp-2(A) with the wholly different meaning of "request for the same volume of fire to be fired again with or without corrections or changes" (e.g., at the same coordinates as the previous round).
I was hoping to see a “this is just for fun” disclaimer but didn’t see one. Please never actually use this in a project that other people will have to read or contribute to.
Yes, code blocks in Org are executable, but I was aiming for simple embedding and zero build-time, thus conservative choice of separating README and the actual header.
You can use the Boehm-Demers-Weiser GC with C. It's conservative, because it has to be with C, so it may/will miss things (it will treat integers etc. as potential pointers, and so avoid freeing anything "pointed to" by them), and so it works best as an extra layer of protection/leak detector, but it can be used as a replacement for freeing memory too.
I've seen this implementation of defer a few times now. I really dislike calling this defer (like the keyword in Go) as the given code won't be executed on return.
Does "strong typing" now just mean "static typing"? Afaik both lua and python are already strongly typed. Javascript is not and I have no clue about ruby.
> Does "strong typing" now just mean "static typing"?
The distinction strong and weak typing is irrelevant in practice.
Weak (but present) static typing beats strong dynamic typing every single time, because what is valuable is NOT"Do I see a type mismatch error only when a user accesses it?", it's "does this mismatch prevent a deployment?"
IOW, the only distinction in production is dynamic typing vs static typing, not strong typing vs weak typing.
This code is incorrect, but I don't blame them. :) Probably one of the most common float-related mistakes, even among people who "know how floats work".
FLT_EPSILON is the difference between 1.0 and the next larger float. It's impossible for numbers less than -2.0 or greater than 2.0 to have a difference of FLT_EPSILON, they're spaced too far apart.
You really want the acceptable error margin to be relative to the size of the two numbers you're comparing.
Also, everyone should read the paper "What, if anything, is epsilon?" by Tom7
Indeed, FLT_EPSILON is not a one-size-fits-all solution, but it's good enough for frequent case of comparing big enough numbers, which is not covered by regular ==. So it's a convenience/correctness trade-off I'm ready to make.
I would go even further and say that any equality comparison of float numbers has to be a one-off special case. You need to know how much error can arise in your calculations, and you need to know how far apart legitimately different numbers will for your particular data. And of course the former has to be smaller than the latter.
Picking out an obvious define function that compares a float with a float sum of that nature should indicate an good understanding of why that might be called wizardry and deserving of a second look.
Hats off to the peer comment that suggested scaling against epsilon rather than simpliy regurging the substitution "as was" from the header.
The scaling is better in general, optional in some specific contexts.
it uses absolute difference epsilon equality ('close enough to be considered equal'):
static int pretty_float_equal (float a, float b) { return fabsf(a - b) < FLT_EPSILON; }
static int pretty_double_equal (double a, double b) { return fabs(a - b) < DBL_EPSILON; }
static int pretty_long_double_equal (long double a, long double b) { return fabsl(a - b) < LDBL_EPSILON; }
Type names are nice; Perfect choice for the in-built func macros (like min); Len -- love it. Named boolean operators -- might be a bit much but go for it; Ternaries are illegible so you can only improve them; Not completely sold on all your loop definitions but some make sense to me; Resource tracking is impressive; The for... look a bit ugly -- could probably call it something else.
All in all: quite a solid attempt. I'll give you 8/10 for the design of this. The way you sketched this out in C using macros is really elegant. This actually looks like good code. Would I use it? It's a new language and I like C already. It could help people learn C and think about language design. Since the way you've done this is very clear.
Well, you don't have to use it all. My projects mostly use booleans, len(), max/min, and some operator aliases, because there wasn't much need for other tasty stuff yet. So give it a shot, even if for a couple of operator macros!
I feel compelled to try it out in a serious way and contribute to it. I have strong knowledge of python and am learning C. Are there good reasons -apart from attracting the ire of c-programmers- to not use it?
> Deprecate Lua, Python, JavaScript, Ruby and a dozen other languages, because Pretty C is the ultimate scripting language, but lightning-fast and strongly typed!
If you find this interesting, you might like libcello.h aswell! https://www.libcello.org
Well, there's a few things I should probably get around to adding to CNoEvil[0] and ogw[1]... There always seem to be more every few months when this project reappears.
[0] https://git.sr.ht/~shakna/cnoevil3/
[1] https://git.sr.ht/~shakna/ogw
It claims to be a scripting language but you still have to compile the programs. Boo! Add CINT (https://root.cern.ch/root/html534/guides/users-guide/CINT.ht...) and you can have instantaneous execution and even a REPL!
Given the idea behind this repo is to cause pain, why not add a shebang to your file [0] to make it executable.
I saw a blog post a long time ago that went into the details of how ./foo worked, and how it executed an elf file. You could register `.c` programs in the same way to be compiled and run?
[0] https://gist.github.com/jdarpinian/1952a58b823222627cc1a8b83...
I'd prefer just using tcc [0]. Far lighter weight than that monster. And C, not C++.
[0] https://bellard.org/tcc/tcc-doc.html
Well, who said that scripting language cannot be compiled? And yeah, Clang-REPL is another way to make it REPL-friendly.
Reminds me of a C++ codebase I once had to inspect that was entirely written as if it were written in Java. With camelcase naming for everything, getters and setters for every class variable, interfaces everywhere.
You ain't seen nothin. Check out the bourne shell source code from unix seventh edition. https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd... I can't believe it's not ALGOL.
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd...
wow.
thanks for this gem.
Wow, I was not expecting that! Was this style of C common back then?
Before he wrote the Bourne shell the author wrote an ALGOL compiler, and ALGOL inspired Bourne syntax:
https://en.wikipedia.org/wiki/ALGOL_68C
There were article suggesting #define BEGIN { and #define end }; to make C look more like Pascal.
I think in Europe C was not as common as other languages at the time so the terseness looked odd.
Also because the special characters were (and are) difficult to type on European keyboards.
Characters like []{}\|~ are behind multi-finger access and often not printed at all on the physical keys (at least in the past). You can see how this adds a hurdle to writing C…
Pascal was designed by a European, so he preferred keywords which could be typed on every international keyboard. C basically just used every symbol from 7-bit ASCII that happened to be on the keyboards in Bell Labs.
Just as example, on my slovenian QWERTZ layout: [ - altgr+f, ] - altgr+g, { - altgr+b, } - altgr+n, \ - altgr+q, | - altgr+w, ~ - altgr+1.
You get used to them, though you start feeling like a pianist after a short coding session. The one most annoying for me are the fancy javascript/typescript quotes, which I have to use all too often: ` - altgr+7.
Today I learned that there exist people who use non-US layouts when coding. That’s spectacular!
I tried switching to US a few times, but every time muscle memory made me give up soonish - especially since there are big benefits to using same keyboard layout as other people in your office are using.
Also practically everytime I need to write a comment, commit message or email I need my č, š and ž. It's kinda nice to have them only a single keypress away.
My hack: use caps key to switch to local keyboard layout while holding it.
How did you think people outside the US learn programming?
There’s so many assumptions here about a person who’s starting to learn programming.
For starters, that they’re on Linux, they feel comfortable running complex CLI commands, they can memorize the U.S. layout just like that, and that they can type without looking at the physical keys (because changing the virtual mapping means keys produce something else than what the label says).
In reality, the learner’s first exposure to C family languages is more likely to be a website where you can run some JavaScript in a text box. And the first hurdle is to figure out how to even type {}. American developers just completely forget about that.
On the long term, using the native keyboard hinders yourself a lot. I tried to do so with the Spanish (es) layout, it's pretty much unergonomical.
It's looks like being deliberately designed for press/office usage and not for proper programming.
I've seen similar codebases as well written by people who have spent way too much time with Java. One even had it's own String class which was just a wrapper for std::string with Java-like methods.
Good job they weren't using MSVC I guess...
https://learn.microsoft.com/en-us/cpp/cpp/property-cpp?view=...
I had that as well but also Java passes strings in as f(String *) so the C++ code was f(new String("Hello")
> camelcase naming for everything, getters and setters for every class variable, interfaces everywhere
This is not far off from the guidelines in many cases, e.g. Windows code (well, not every variable of course.) A lot of Java design was copied from C++.
The code asumes that C17 has C++-style auto (https://github.com/aartaka/pretty.c/blob/master/pretty.h#L11...), it does not (in C auto is storage specifier that is equivalent to no storage specifier).
C17 doesn't have auto, but C23 does, and thus my `__STDC_VERSION__ > 201710L` (notice the greater than sign, it doesn't include C17 itself.)
Ha, apparently the N2310 working draft is not the last one :)
Can someone clarify whether this is intended as a joke or whether the author is actually confused? I mean, nothing about this makes sense: it's not "scripting"; it claims to introduce "strong typing" while it does nothing about typing; it introduces all kinds of operator aliases "modeled after Lua and Lisp" that are present in neither of these languages. But it's not an obvious parody either, so I'm genuinely not sure.
I do not at all think the author is confused. Being confused is OK though.
I mean he has to be serious, right: "Deprecate Lua, Python, JavaScript, Ruby and a dozen other languages, because Pretty C is the ultimate scripting language, but lightning-fast and strongly typed!!"
Author here. I don't see any problem with this
Well, as a starter C is rarely considered as "strongly typed". Statically typed yes, but strongly typed not so much.
With C23 (nullptr, auto typing, typeof) and C11 (generics) it got more guarantees and type-related primitives. You can still do void*, but you are strongly discouraged from it.
That's pretty clearly said jokingly
> ifnt for if(!...).
"unless" seems more readable than "ifnt".
Another bikeshed is the infinite for(;;) loop being called "always"
I've seen "loop" in other languages. But Qt calls it "forever", and that is indeed very pretty. Very Qt, even
> I've seen "loop" in other languages. But Qt calls it "forever", and that is indeed very pretty. Very Qt, even
You can break a "forever" loop so I think "loop" is a better name.
I don’t know why “repeat” isn’t very common in place of while/loop/etc; it works out nicely grammatically.
One possible reason:
> The word "REPEAT" should not be used in place of "SAY AGAIN", especially in the vicinity of naval or other firing ranges, as "REPEAT" is an artillery proword defined in ACP 125 U.S. Supp-2(A) with the wholly different meaning of "request for the same volume of fire to be fired again with or without corrections or changes" (e.g., at the same coordinates as the previous round).
https://en.wikipedia.org/wiki/Procedure_word#Say_again
More seriously, PASCAL has repeat-until loops, similar to do-while loops in C.
Pretty C does aliases "repeat" for "do", so yeah, I've got you covered!
"loop" added in commit 626408b, thank you!
"indefinitely" might be a better name. (But I think loop is indeed a better name.)
Added in commit ef510ca!
"forever" added in commit 67ff9ef, thank you!
Indeed! But I've reserved "unless" for a ternary conditional, which is more useful anyway.
Oh shit wait, you're John Tromp, BLC creator! I'm a fan!
> turn any codebase into a beginner friendly one
Okay then.
I was hoping to see a “this is just for fun” disclaimer but didn’t see one. Please never actually use this in a project that other people will have to read or contribute to.
> Provide so much syntactic sugar as to cause any C developer a diabetes-induced heart attack.
seems like its obvious to me that its a joke
It's a joke that I would happily use.
C is funny, in many ways.
You're welcome!
Not everything needs to be stated explicitly, where's the fun in that?
> if (argc above 1)
I give up.
You're welcome!
I have not decided how I feel in general, but:
> Everyone defines these, so why not provide them?
Honestly, that's fair.
Is it possible to tangle the Readme into pretty.h? In other words, are the codeblocks in the orgfile exhaustive.
I love the literate way you have explained your thought process in the readme.
Yes, code blocks in Org are executable, but I was aiming for simple embedding and zero build-time, thus conservative choice of separating README and the actual header.
Wow, neat! The wildest part to me is
> And it’s backwards-compatible with C and all of its libraries!
I can't wait to give it a shot! This looks like a riot.
Have you heard of Zig?
It requires a different compiler. This is just a collection of C preprocessor macros
All that is missing is a garbage collector. Should be possible to implement one by overriding malloc & friends?
You can use the Boehm-Demers-Weiser GC with C. It's conservative, because it has to be with C, so it may/will miss things (it will treat integers etc. as potential pointers, and so avoid freeing anything "pointed to" by them), and so it works best as an extra layer of protection/leak detector, but it can be used as a replacement for freeing memory too.
This should have been invented 50 years ago!
Yes, and it's a shame that underlying features were only shipped in C11 (generics) and C23 (auto type inference!)
This made me immediately think whether MIT Loop of Common Lisp was an inspiration here. Checked the user's profile and sure enough, a lisper!
Yes, LOOP is a huge inspiration and my favorite programming language!
I've seen this implementation of defer a few times now. I really dislike calling this defer (like the keyword in Go) as the given code won't be executed on return.
Scoping defer to a block is actually more useful and explicit than function-exclusive that Go does, so I consider that a feature.
Does "strong typing" now just mean "static typing"? Afaik both lua and python are already strongly typed. Javascript is not and I have no clue about ruby.
> Does "strong typing" now just mean "static typing"?
The distinction strong and weak typing is irrelevant in practice.
Weak (but present) static typing beats strong dynamic typing every single time, because what is valuable is NOT "Do I see a type mismatch error only when a user accesses it?", it's "does this mismatch prevent a deployment?"
IOW, the only distinction in production is dynamic typing vs static typing, not strong typing vs weak typing.
This is terrifying
Thanks!
`equal(0.3, 0.2 + 0.1); // true`
how is this wizardry possible?
It uses type dispatch to perform an epsilon comparison:
So it’s https://docs.python.org/library/math.html#math.iscloseThis code is incorrect, but I don't blame them. :) Probably one of the most common float-related mistakes, even among people who "know how floats work".
FLT_EPSILON is the difference between 1.0 and the next larger float. It's impossible for numbers less than -2.0 or greater than 2.0 to have a difference of FLT_EPSILON, they're spaced too far apart.
You really want the acceptable error margin to be relative to the size of the two numbers you're comparing.
Also, everyone should read the paper "What, if anything, is epsilon?" by Tom7
Indeed, FLT_EPSILON is not a one-size-fits-all solution, but it's good enough for frequent case of comparing big enough numbers, which is not covered by regular ==. So it's a convenience/correctness trade-off I'm ready to make.
I would go even further and say that any equality comparison of float numbers has to be a one-off special case. You need to know how much error can arise in your calculations, and you need to know how far apart legitimately different numbers will for your particular data. And of course the former has to be smaller than the latter.
Is What Every Computer Scientist Should Know About Floating-Point Arithmetic wrong ??!!
addendum: why are obviously rhetorical questions are taken so literally here?
Because text doesn't convey sarcastic voice tonality, so the intent is far from obvious.
Sarcastic? Okay, if you say so.
Picking out an obvious define function that compares a float with a float sum of that nature should indicate an good understanding of why that might be called wizardry and deserving of a second look.
Hats off to the peer comment that suggested scaling against epsilon rather than simpliy regurging the substitution "as was" from the header.
The scaling is better in general, optional in some specific contexts.
It's meant as both humorous and a nerd snipe :)
it uses absolute difference epsilon equality ('close enough to be considered equal'):
This is wrong code. It only works somewhat correctly when a and b around 1.
Yeah, should be scaled like |x - y| <= ε * max(|x|, |y|)
Will do.
If both terms are infinites and of same sign, subtraction will give NaN and it will fail.
static int pretty_float_equal (float a, float b) { return fabsf(a - b) < FLT_EPSILON; }
Evil, yet beautiful. Hats off to you.
Thanks!
That is pretty cool
I feel like this would have been cool 25 years ago
Type names are nice; Perfect choice for the in-built func macros (like min); Len -- love it. Named boolean operators -- might be a bit much but go for it; Ternaries are illegible so you can only improve them; Not completely sold on all your loop definitions but some make sense to me; Resource tracking is impressive; The for... look a bit ugly -- could probably call it something else.
All in all: quite a solid attempt. I'll give you 8/10 for the design of this. The way you sketched this out in C using macros is really elegant. This actually looks like good code. Would I use it? It's a new language and I like C already. It could help people learn C and think about language design. Since the way you've done this is very clear.
Well, you don't have to use it all. My projects mostly use booleans, len(), max/min, and some operator aliases, because there wasn't much need for other tasty stuff yet. So give it a shot, even if for a couple of operator macros!
You know I expected your macro file to be unreadable moon math. But it actually doesn't look bad.
I feel compelled to try it out in a serious way and contribute to it. I have strong knowledge of python and am learning C. Are there good reasons -apart from attracting the ire of c-programmers- to not use it?
Author here. I'll be glad to accept any contribution that makes C more readable, so PR away!
as someone that just started C, it looks pretty :)
Thanks!
> Deprecate Lua, Python, JavaScript, Ruby and a dozen other languages, because Pretty C is the ultimate scripting language, but lightning-fast and strongly typed!
Umm… that’s quite the goal.
I’ll stick with deprecated Python.
Deprecate Python?! You'll have to deprecate me first! ;-)
We will all reach this status at some point, though the silly code we produced might stick a bit longer in some legacy codebase. :D
I'm reminded of the guy who did
and a whole bunch of other macro-larkey just to make C look more like Pascal. Only then would he deign to code in it.https://en.wikipedia.org/wiki/Stephen_R._Bourne
https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh
Now that's just silly. And I see the backwards keyword terminators (LOOP/POOL).
I have wondered why we have case/esac, if/fi but while/done. I imagine the author himself figured that while/elihw would just be entirely ridiculous.
> I have wondered why we have case/esac, if/fi but while/done.
With the reverse-keyword convention we'd get "od", not "elihw", though.
The 'od' utility already existed, apparently, so Bourne opted for "done".[edit: typos]
Just call it wyl/lyw. Pronunciation maintained, problem solved.
This is as horrific as it is wonderful.
Thanks!
I cannot wait to show this to a colleague of mine. He will kill me XD
Can't wait to learn of how it went!
love. It.
Thanks!
So sweet :))
Yeah, I love sugar ;)
Can we just pascal?
I won't stop you, so be my guest.
Meta: the naming is ... strange.
The actual name of the repo is "pretty.c", but the name used for the language/dialect/result/horrorshow[*] is "Pretty C".
The actual code file you include is called "pretty.h", which makes sense since it's a header, of course. Confusing!
Edit: escapes.
[*] Yes, I'm a C programmer, currently hunting for black-marked insulin to combat the rapid-onset diabetic attack from all that sugar. Sorta.
I mean, don’t say the repo didn’t warn you!
> The goals for Pretty C are: Provide so much syntactic sugar as to cause any C developer a diabetes-induced heart attack.