Proposal: Ignore identifier lengths in iocccsize tool

[vog]

Currently, the length of identifiers (variable names, function names) counts heavily towards to overall size of the program. Is there a specific reason for that?

The downside is that this is pushing entries heavily towards using 1-char identifiers - either to stay within the iocccsize limit, or to have one's entry be assigned to a lower size category.

But why should a program like this:

int main() {
  int a = "Hello World!";
  printf("%s\n", a);
  return 0;
}

be considered shorter that that one:

int main() {
  int hello_world = "Hello World!";
  printf("%s\n", hello_world);
  return 0;
}

?

[ilyakurdyukov]

hello_world

This is Obfuscated Code Contest, not the Most Readable Variable Names or the Longest Variable Name contest. The current behavior of iocccsize makes sense.

I'm against this proposal.

[mame]

Just a note: in C, identifiers can also be used as data:

#include <stdio.h>
#define D(d) #d

int main() {
    char *str = D(this_long_identifier_can_be_used_as_a_data);

    puts(str); //=> this_long_identifier_can_be_used_as_a_data

    return 0;
}

A long identifier counting as 1 char leaves some room for creative abuse. Though the Gross Size Limit (4993 bytes) bounds how much data you can embed this way.

(Personally, I prefer simpler rules, so the Net Size Limit feels unnecessarily complex to me.)

[SirWumpus]

Personally, I prefer simpler rules, so the Net Size Limit feels unnecessarily complex to me.)

I agree based on the aesthetic that simpler is better, BUT having one or more constraints makes the contest more challenging. Personally its part of the fun of puzzling out a working solution - a battle of design and functionality within the bounds set by the Judges.

However we're in an IOCCC era ~2,5 KB now that maybe removing Rule 2b and lowering 2a (2503 < 2a << 4993) to compensate for 2b might yield the same overall desire for functionally interesting and stylised code and allow for some lee way on identifiers, especially those from libraries.

The issue of blob code can easily be a judging elimination step.

[xexyl]

Yes it is actually quite fun to keep the size down.

I also don't understand the problem at all because in addition to that part it actually helps with obfuscation in many ways.

Also ask yourself what is more impressive: doing something really creative in fewer bytes or more bytes?

Or more limited hardware or more powerful hardware?

Obviously fewer bytes and more limited hardware doing the same thing is FAR more impressive.

Old computer games with the limited CPUs were far more interesting and impressive than now when systems have hundreds of gigabytes of RAM and other computing power.

[uguu-org]

I feel that IOCCC rules are like chess in its growing complexity, compared to TRICK rules which are more like go in its simple elegance. I personally prefer simpler rules, but I understand IOCCC judges intentionally kept some complexity for people who seeks to find holes in the rules.

I am not sure if there are meta-guidelines on how the rules should evolve, but perhaps we can make some observations on whether there are a still new entries that abuse the current rules and iocccsize implementation in interesting ways. If so, the rules are probably working as intended. If not, it would be worth simplifying the rules to reduce barrier to entry.

[xexyl]

I feel that IOCCC rules are like chess in its growing complexity, compared to TRICK rules which are more like go in its simple elegance. I personally prefer simpler rules, but I understand IOCCC judges intentionally kept some complexity for people who seeks to find holes in the rules.

I am not sure if there are meta-guidelines on how the rules should evolve, but perhaps we can make some observations on whether there are a still new entries that abuse the current rules and iocccsize implementation in interesting ways. If so, the rules are probably working as intended. If not, it would be worth simplifying the rules to reduce barrier to entry.

Well Leo said he's dead set on the size rules not changing. Landon has told @SirWumpus and me twice and he also wrote it in the remarks of the entries from 2024.

I like them as they are personally. It's a fun challenge. Also frankly the size is quite large now. It seems to me that if someone wants them to be larger they're thinking in the wrong way.

Even if it was for 'formatting' we all know that's not what it would be used for ONLY. Others would use it for other things as well. That's not only historically the case in the IOCCC but it's how humans are in general throughout history.

[xexyl]

But why should a program like this:

be considered shorter that that one:

Because it IS shorter? It is not even just iocccsize:

$ cat 1.c ; wc -c 1.c  ; iocccsize -v 1 1.c ; cat 2.c ; wc -c 2.c  ; iocccsize  -v 1 2.c
int main() {
  int a = "Hello World!";
  printf("%s\n", a);
  return 0;
}
74 1.c
41 74 3
int main() {
  int hello_world = "Hello World!";
  printf("%s\n", hello_world);
  return 0;
}
94 2.c
61 94 3

Nobody is stopping anyone from using longer names in variables. It has been done before. For some good examples:

• https://www.ioccc.org/2005/chia/index.html
• https://www.ioccc.org/2000/primenum/index.html

... and the size limit was more strict then.

[vog]

We still do have the gross size limit of 4993 bytes, which this proposal doesn't question at all. That should be more than enough protection against entries_with_execessively_long_variable_and_function_names.

To my understanding, the net size limit of 2503, as measured by iocccsize, was introduced to level the playing field among entries with an interesting shape. For example, that entries with lots of whitespace to allow for interesting formatting will be considered to have roughly the same "net size" as their boring block-shaped counterparts.

My proposal is to do the same for variable and function names, such that it encourages that you provide a nicer shape not just by whitespace and comments, but also by choosing variable names (and especially their lengths) to make the code fit into a certain shape.

Of course we could also use a logarithmic scale here, or add extra penalty for variable names longer than e.g. 8 characters. But I believe that the gross size limit is already enough protection against that.

[xexyl]

We still do have the gross size limit of 4993 bytes, which this proposal doesn't question at all. That should be more than enough protection against entries_with_execessively_long_variable_and_function_names.

See below.

To my understanding, the net size limit of 2503, as measured by iocccsize, was introduced to level the playing field among entries with an interesting shape. For example, that entries with lots of whitespace to allow for interesting formatting will be considered to have roughly the same "net size" as their boring block-shaped counterparts.

I'm amazed that you're complaining about the smaller size since that tool actually counts many things that are multiple characters as ONE byte only. There also is the ;, { and } followed by whitespace that makes it 0 bytes. Whitespace is also free.

But then again I'm surprised you're complaining (or questioning?) the size at all. I think you're the first one but maybe I'm wrong.

The thing is this: winners are skilful and writing more interesting things in fewer bytes is part of that skill.

Additionally you do NOT need that for shapes. You should look at many of the other entries.

My proposal is to do the same for variable and function names, such that it encourages that you provide a nicer shape not just by whitespace and comments, but also by choosing variable names (and especially their lengths) to make the code fit into a certain shape.

Tell that to best one-liner and smallest program winners.

You don't even always need a nice shape. In 2018 I cheekily (via a comment) dismissed that my code was a blob.

Additionally there are MANY ways to make code into all sorts of shapes with shorter character identifiers. I don't mean this in a dismissive way but this just takes a bit of thought. Or if you're Yusuke Endoh or someone like him you might write your own code to do the formatting!

Of course we could also use a logarithmic scale here, or add extra penalty for variable names longer than e.g. 8 characters. But I believe that the gross size limit is already enough protection against that.

And further complicate the algorithm?

I rather LOVE both size limits. It takes more skill and it's a VERY reasonable thing.

Anyway to put several nails in your proposal's coffin:

0. Before last contest Leo had serious reservations about the size increase (which was a SIGNIFICANT increase).
1. Leo has made it clear he was not happy about the changes and Landon said because of this (and the history of the size change) it will NOT change anytime soon.

Honestly although I made use of the increase in size last year I always thought that 2053/4096 was extremely reasonable.

As for your understanding as to size rule you might wish to ask @SirWumpus because he wrote it as part of an entry MANY years ago. Landon has made mods over the years but it was not his work.

UPDATE

Typo fixes.

[SirWumpus]

As for your understanding as to size rule you might wish to ask @SirWumpus because he wrote it as part of an entry MANY years ago. Landon has made mods over the years but it was not his work.

iocccsize.c was never an entry. From https://codeberg.org/SirWumpus/iocccsize#history

Following my IOCCC 1991 Best Utility win I needed something to help with applying the IOCCC Rule 2 Size Limit during the development of my 1992 and 1993 submissions (combined with some sed(1) transformations). The tool kept being refined over the years as I kepted submitted entries to the IOCCC.

Sometime around 2012 or 2013 I was in contact with one of the IOCCC judges, Landon Court Noll, proposing Rule 2 Size Limit changes and mentioned I had this tool I used to help prepare my entries. Landon perked up to the idea of including the tool as part of the contest to help contestants (and judges) apply the Rule 2 Size Limit. The iocccsize tool first appeared in IOCCC 2014.

The IOCCC has now moved to retool its submission process by integrating a version of this tool into mkiocccentry with changes made to turn the core into a library function rule_count().

[xexyl]

As for your understanding as to size rule you might wish to ask @SirWumpus because he wrote it as part of an entry MANY years ago. Landon has made mods over the years but it was not his work.

iocccsize.c was never an entry. From https://codeberg.org/SirWumpus/iocccsize#history

I know not an entry. I thought it was included as a supplementary program though? However I see below it's far more interesting!

Following my IOCCC 1991 Best Utility win I needed something to help with applying the IOCCC Rule 2 Size Limit during the development of my 1992 and 1993 submissions (combined with some sed(1) transformations). The tool kept being refined over the years as I kepted submitted entries to the IOCCC.
Sometime around 2012 or 2013 I was in contact with one of the IOCCC judges, Landon Court Noll, proposing Rule 2 Size Limit changes and mentioned I had this tool I used to help prepare my entries. Landon perked up to the idea of including the tool as part of the contest to help contestants (and judges) apply the Rule 2 Size Limit. The iocccsize tool first appeared in IOCCC 2014.

This part I did not actually know. Interesting! I thought it was 2013 though?

Incidentally I love those old tools. I also love ./ant hill. Brilliant. I mean yeah it's anthill technically but ./ant hill (or in those days I guess ant hill was what it would have to be).

The IOCCC has now moved to retool its submission process by integrating a version of this tool into mkiocccentry with changes made to turn the core into a library function rule_count().

Yup.

[ilyakurdyukov]

There are many ways to create a "nicer shape", learn from others. Instead of thinking about how to solve the problem, you think about how to change the rules.

Name length won't help here, because variables are also used in places other than the one they're defined in. Adding the name length in one place will also add the length in other places where the variable is used.

[SirWumpus]

From https://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest on Rule 2 (I wrote that part):

In 1992, Rule 2 was split to distinguish between maximum overall size and maximum size ignoring white space and semicolons given certain conditions. In the early days, in order to make best use of space allowed, white space was stripped, often resulting in a compact blob of text, making it hard to read by humans, but served little purpose once passed through a C "pretty print" utility, which the judges did as part of their process. In 1992 the judges believed that form of obfuscation had played out[15] and they wanted to encourage people to explore other ways of formatting the code, such as an ASCII image themed after the entry, or simply more traditionally indented C source.

The Net Size Rule was created to encourage formatted code vs square blob of code.

[xexyl]

From https://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest on Rule 2 (I wrote that part):

In 1992, Rule 2 was split to distinguish between maximum overall size and maximum size ignoring white space and semicolons given certain conditions. In the early days, in order to make best use of space allowed, white space was stripped, often resulting in a compact blob of text, making it hard to read by humans, but served little purpose once passed through a C "pretty print" utility, which the judges did as part of their process. In 1992 the judges believed that form of obfuscation had played out[15] and they wanted to encourage people to explore other ways of formatting the code, such as an ASCII image themed after the entry, or simply more traditionally indented C source.

The Net Size Rule was created to encourage formatted code vs square blob of code.

Would that beautifier be cb? (I added the FAQ entry about it.)

I didn't know that it was also about (or strictly?) formatting though. Nonetheless single character identifiers work well for it. One does not need longer identifiers for it. It just takes a bit of creativity.

[SirWumpus]

I made an argument for counting based on characters instead of bytes / octets, which is a throw back to ASCII. The would not penalise the use of longer UTF-8 character encodings and provide a HUGE increase in possible identifiers. @lcn2 stated that the most recent size increase was sufficient for the next decade, so counting by characters, for which I have a version of the tool ready, is on the back burner or limbo.

[xexyl]

I made an argument for counting based on characters instead of bytes / octets, which is a throw back to ASCII. The would not penalise the use of longer UTF-8 character encodings and provide a HUGE increase in possible identifiers. @lcn2 stated that the most recent size increase was sufficient for the next decade, so counting by characters, for which I have a version of the tool ready, is on the back burner or limbo.

Yes that's when Landon told us Leo was not happy. Then Landon told me some additional things and the remarks by the judges in the last contest also stated some things.

He also told us earlier on that Leo was not sure about it prior to the contest opening.

Although UTF-8 characters would be interesting in the tool we still have a very large number. But the thing that also should be remembered @vog is the judges WANT smaller programs. Doesn't mean that larger programs don't have a chance but they like smaller programs. That is what Landon told me personally in fact: it wasn't about just rule 2b but also rule 2a.

So even if your proposal was not against Leo's dislike of the size increase it would be of this.

[vog]

My proposal is to do the same for variable and function names, such that it encourages that you provide a nicer shape not just by whitespace and comments, but also by choosing variable names (and especially their lengths) to make the code fit into a certain shape.

Tell that to best one-liner and smallest program winners.

Just to clarify: I am one of those winners (see 2019/diels-grabsch1).

And in preparation of my winning (and non-winning) entries I did study tons of previous winners.

And from exactly that experience I can say for sure that there is a very strong bias towards 1-char identifiers. You can see that in the past winners, you can feel this while coding yourself. Of course there are notable exceptions. But those are deliberate breakouts, and there's not much in between, except for entries with unicode identifiers, but even those have mostly 1-unicode-char identifiers.

I for myself can say that I could have created much more interesting entries if iocccsize would treat at least, say, 1-4 char identifiers just like 1-char identifiers. I was always feeling that strong bias towards 1-char identifiers through the iocccsize tool. And after some time I felt that this overly strong bias is a bit unnecessary and unhealthy as a whole, and that we might get more interesting shapes if e.g. using 2-4 char identifiers wouldn't increase the net size via iocccsize as heavily as it does right now (especially for often-occurring identifiers).

So I started this discussion to see if others (especially other past winners) feel the same.

But maybe that's indeed just me. And in this case, of course, it is correct to deny my proposal.

[SirWumpus]

there is a very strong bias towards 1-char identifiers. You can see that in the past winners, you can feel this while coding yourself.

Yes. The contest started when ASCII was the only sane game in town, POSIX was still young (I think) and C89 wasn't complete yet. However, 1 byte identifiers is part of obfuscation and compaction.

Of course there are notable exceptions. But those are deliberate breakouts, and there's not much in between, except for entries with unicode identifiers, but even those have mostly 1-unicode-char identifiers.

Well the only 1 byte UTF-8 characters are ASCII. Where longer UTF-8 characters comes in, the next size 2 byte encodings are the next most popular, because from an earlier point I made, the contest counts by bytes, not characters currently. I'm sure @mame would love to code using his native Japanese for identifiers, but those are 3 byte encodings. And all emojis that are permitted in identifiers are 4 byte encodings. That's most of the bulk of characters. There are some other Unicode encoding rules it appears that allows for longer sequences (I think, not researched that yet).

I like the idea of a simpler size rule, but doubt the Judges are ready to entertain that for a long while, at least not without some statistical study. The currently rule works for now until it doesn't or proven to be a hindrance for certain classes of source code/programs. Maybe some cool graphics or LLM (eww) library with 64 character identifiers (ugh Java) would push that point, but we're not there yet.

[xexyl]

My proposal is to do the same for variable and function names, such that it encourages that you provide a nicer shape not just by whitespace and comments, but also by choosing variable names (and especially their lengths) to make the code fit into a certain shape.

Tell that to best one-liner and smallest program winners.

Just to clarify: I am one of those winners (see 2019/diels-grabsch1).

Which is all the more reason you should get the point. Shapes are meaningless to these categories.

And in preparation of my winning (and non-winning) entries I did study tons of previous winners.

And from exactly that experience I can say for sure that there is a very strong bias towards 1-char identifiers. You can see that in the past winners, you can feel this while coding yourself. Of course there are notable exceptions. But those are deliberate breakouts, and there's not much in between, except for entries with unicode identifiers, but even those have mostly 1-unicode-char identifiers.

As there should be. As for unicode identifiers Leo also said he's against that too. Bytes. ASCII. You're welcome to use unicode characters if they compile (not all will). @SirWumpus did this last year. He was the first because the rules changed. But single character identifiers are more interesting and compact. The fact that the size limit was increased means this is less of an issue.

I for myself can say that I could have created much more interesting entries if iocccsize would treat at least, say, 1-4 char identifiers just like 1-char identifiers. I was always feeling that strong bias towards 1-char identifiers through the iocccsize tool. And after some time I felt that this overly strong bias is a bit unnecessary and unhealthy as a whole, and that we might get more interesting shapes if e.g. using 2-4 char identifiers wouldn't increase the net size via iocccsize as heavily as it does right now (especially for often-occurring identifiers).

I find this hard to imagine. And if you want to reuse more than one character more than once make a macro. Yes #define is costly but if you use it enough times it does save bytes.

So I started this discussion to see if others (especially other past winners) feel the same.

I don't anyway and I know others are the same way. Frankly it's a large number.

But maybe that's indeed just me. And in this case, of course, it is correct to deny my proposal.

Leo will whatever merit it has.

[xexyl]

there is a very strong bias towards 1-char identifiers. You can see that in the past winners, you can feel this while coding yourself.

Yes. The contest started when ASCII was the only sane game in town, POSIX was still young (I think) and C89 wasn't complete yet. However, 1 byte identifiers is part of obfuscation and compaction.

It also has its charm as one byte identifiers. It makes it more interesting. And let's be honest. If you have identifiers that are words even IF you have misleading names they are still MUCH easier to keep track of.

Also as for formatting and the need for longer names. This is not true. You can use whitespace. Lots of us do it.

Of course there are notable exceptions. But those are deliberate breakouts, and there's not much in between, except for entries with unicode identifiers, but even those have mostly 1-unicode-char identifiers.

Well the only 1 byte UTF-8 characters are ASCII. Where longer UTF-8 characters comes in, the next size 2 byte encodings are the next most popular, because from an earlier point I made, the contest counts by bytes, not characters currently. I'm sure @mame would love to code using his native Japanese for identifiers, but those are 3 byte encodings. And all emojis that are permitted in identifiers are 4 byte encodings. That's most of the bulk of characters. There are some other Unicode encoding rules it appears that allows for longer sequences (I think, not researched that yet).

I don't know all that are allowed but I do know some will not compile. I do not know how portable emojis are in identifiers but clang seems to be fine and gcc. Even so not all emojis will compile.

I like the idea of a simpler size rule, but doubt the Judges are ready to entertain that for a long while, at least not without some statistical study. The currently rule works for now until it doesn't or proven to be a hindrance for certain classes of source code/programs. Maybe some cool graphics or LLM (eww) library with 64 character identifiers (ugh Java) would push that point, but we're not there yet.

They're not. Landon told me also when I asked him whether the desire for smaller programs meant rule 2b, rule 2a or both and he not only said both but he capitalised it. And as you know Leo was against the size change of both.

As for me I don't find the size rule complicated. Just run the bloody tool and that's that. The algorithm explained is also very simple. I think if anything trying to add more exceptions or more details would only complicate the rule because then there is more to keep track of. NOT simpler. Depending on how it's done of course.

[SirWumpus]

Some where in the one or two discussions or issues prior to IOCCC28 I had made a similar suggestion of capping long identifier counting at 4 bytes. This had no support, mind you, no one outside of the Judges, @xexyl, and I were publicly talking about.

I think we first need support for counting by characters, not bytes, before Rule 2b could be retired.

Or as I suggested elsewhere above, retire 2b and lower 2a as a counter balance.

Pity this discussion was not raised before or during the contest, when the Judges could provide commentary; right now we'll have to wait till after Judgement Day (most likely).

[xexyl]

Some where in the one or two discussions or issues prior to IOCCC28 I had made a similar suggestion of capping long identifier counting at 4 bytes. This had no support, mind you, no one outside of the Judges, @xexyl, and I were publicly talking about.

I think we first need support for counting by characters, not bytes, before Rule 2b could be retired.

Or as I suggested elsewhere above, retire 2b and lower 2a as a counter balance.

Pity this discussion was not raised before or during the contest, when the Judges could provide commentary; right now we'll have to wait till after Judgement Day (most likely).

Yes which won't happen because Leo didn't even like the increase in the size limit.

Landon told us that too.

So this proposal is not going to happen. The judges made it very clear after IOCCC28 that the size rules are not going to change. And history shows us that it tends to be a long time in between.

Actually I was surprised it even stayed put because Leo was not happy about it before the contest even opened in 2024.

[vog]

Some where in the one or two discussions or issues prior to IOCCC28 I had made a similar suggestion of capping long identifier counting at 4 bytes. This had no support, mind you, no one outside of the Judges, @xexyl, and I were publicly talking about.

I think we first need support for counting by characters, not bytes, before Rule 2b could be retired.

Or as I suggested elsewhere above, retire 2b and lower 2a as a counter balance.

Pity this discussion was not raised before or during the contest, when the Judges could provide commentary; right now we'll have to wait till after Judgement Day (most likely).

Oh, that's good to know. Sorry, my bad. I actually waited on purpose with that discussion until after the deadline, to avoid misconceptions - as this is about possible future rules, not clarification of the current ones.

[xexyl]

Some where in the one or two discussions or issues prior to IOCCC28 I had made a similar suggestion of capping long identifier counting at 4 bytes. This had no support, mind you, no one outside of the Judges, @xexyl, and I were publicly talking about.
I think we first need support for counting by characters, not bytes, before Rule 2b could be retired.
Or as I suggested elsewhere above, retire 2b and lower 2a as a counter balance.
Pity this discussion was not raised before or during the contest, when the Judges could provide commentary; right now we'll have to wait till after Judgement Day (most likely).

Oh, that's good to know. Sorry, my bad. I actually waited on purpose with that discussion until after the deadline, to avoid misconceptions - as this is about possible future rules, not clarification of the current ones.

That makes sense that you did it that way. And it was a good call.

But you should take a look at the remarks by the judges in the comments on size. But bottom line is that the judges have made it clear that this will not happen. It's a guess of mine only but I would say a large part of that is because Leo wanted it to not be increased in the first place.

I made almost full use of the change and I was thankful for it but like it or not the judges stated that larger is not necessarily better. I think where it is a nice balance but I was also quite okay with it at the previous limit. And if we're honest we must remember what the judges said for 1998/banks:

What can we say? It's a flight sim done in 1536 bytes of real code.
This one is a real marvel. When people say the size limits are too
tight, well, we can just point them at this one. This program really
pushes the envelope!

... which might be remembered too considering how much it's increased.

[uguu-org]

I do find the qualitative discussion interesting, and I would like to add some numbers, so I made a spreadsheet:

https://docs.google.com/spreadsheets/d/e/2PACX-1vTYIMITHvH4VxIwoRvTfNylG9G2fkTqxjoq3avUwT_1kDadOJ0AN1DxrQqQVFArAOuz0NzXUpJkjJ6Y/pubhtml

• file path = paths from the .tar.bz2 files. I only counted files named ".orig.c"

• net limit, gross limit = size limits for that particular contest year.

• file size = raw file size.

• iocccsize = size as reported by the 2026 version of iocccsize tool.

• non-whitespace count = number of non-whitespaces. This cell is colored red if it it would exceed the net limit.

• identifiers count as 1 = sizes reported by iocccsize tool and non-whitespace counts, with all identifiers longer than 1 replaced by single character identifiers (e.g. "goto" -> "g").

• delta = number of bytes gained by counting identifiers as 1.

[xexyl]

I do find the qualitative discussion interesting, and I would like to add some numbers, so I made a spreadsheet:

https://docs.google.com/spreadsheets/d/e/2PACX-1vTYIMITHvH4VxIwoRvTfNylG9G2fkTqxjoq3avUwT_1kDadOJ0AN1DxrQqQVFArAOuz0NzXUpJkjJ6Y/pubhtml

• file path = paths from the .tar.bz2 files. I only counted files named ".orig.c"
• net limit, gross limit = size limits for that particular contest year.
• file size = raw file size.
• iocccsize = size as reported by the 2026 version of iocccsize tool.
• non-whitespace count = number of non-whitespaces. This cell is colored red if it it would exceed the net limit.
• identifiers count as 1 = sizes reported by iocccsize tool and non-whitespace counts, with all identifiers longer than 1 replaced by single character identifiers (e.g. "goto" -> "g").
• delta = number of bytes gained by counting identifiers as 1.

Very nice!

Not sure what spreadsheet application you use but if possible what might make it slightly easier to read is if you froze the header rows so that they are easier to see as there are over 300 entries over the years. Though maybe it's a google thing and not possible. That's not a criticism of course - it's very nice. And you obviously put effort and time in that as well. I certainly wouldn't have the patience for that. What would be VERY interesting is to have the size based on how the size was counted per year but that would be even more annoying I am sure.

Thanks for sharing.

[uguu-org]

I did freeze the header rows, but in the "publish to web" version it appears to have no effect. Here is another view:

https://docs.google.com/spreadsheets/d/1KEK8wIQI3qsWGKzJxfNLY5TFFabBwra3FWyIl3_k7Qo/edit?usp=sharing

I know the net size rule changed from year to year (used to be just semicolons and braces being discounted, new keywords got added later, etc), but it was a lot of trouble to gather year specific stats, so I didn't :P

My effort to count identifiers as 1 is also not perfect -- basically I just replaced all "[a-zA-Z_]\w+" with the first character. A lot of text inside strings and comments would be under-counted. But I hope it's useful as a rough estimate.

[xexyl]

I did freeze the header rows, but in the "publish to web" version it appears to have no effect. Here is another view:

That doesn't surprise me at all: neither part.

https://docs.google.com/spreadsheets/d/1KEK8wIQI3qsWGKzJxfNLY5TFFabBwra3FWyIl3_k7Qo/edit?usp=sharing

Thanks.

I know the net size rule changed from year to year (used to be just semicolons and braces being discounted, new keywords got added later, etc), but it was a lot of trouble to gather year specific stats, so I didn't :P

See below.

My effort to count identifiers as 1 is also not perfect -- basically I just replaced all "[a-zA-Z_]\w+" with the first character. A lot of text inside strings and comments would be under-counted. But I hope it's useful as a rough estimate.

Oh I know that. I was just saying it'd be interesting to see. Not worth it though. You did way more than I would do (i.e. nothing at all)!

I'll check it out tomorrow. Leaving now. Best wishes!

[xexyl]

.. and regardless of what my thoughts are, I want you to know @vog, that I do appreciate your thoughts and I hope that I did not sound too dismissive. I have been awake too long and my sleep is totally upside down which does not help. Not that that would be an excuse if it did sound dismissive but it might help explain some of it (but I hope it didn't come across that way obviously).

I PERSONALLY do think that smaller size (that is the way it is now) is more interesting because it is more of a challenge and I also don't see how your points are necessarily strictly correct (as in we don't need more bytes for formatting and other things) but that does not mean your view is wrong any more than my view is right (or not) because it's just your view and my view and everyone else who commented, it's their view also.

[vog]

.. and regardless of what my thoughts are, I want you to know @vog, that I do appreciate your thoughts and I hope that I did not sound too dismissive. I have been awake too long and my sleep is totally upside down which does not help. Not that that would be an excuse if it did sound dismissive but it might help explain some of it (but I hope it didn't come across that way obviously).

Thanks for the clarification! I found it indeed very annoying, as a contestant for so many years, to be belittled as if I was a newbie trying to bend the rules to their liking. I'm happy you brought this up on your own, though, as it saved me from having to do so myself.

I PERSONALLY do think that smaller size (that is the way it is now) is more interesting because it is more of a challenge and I also don't see how your points are necessarily strictly correct (as in we don't need more bytes for formatting and other things) but that does not mean your view is wrong any more than my view is right (or not) because it's just your view and my view and everyone else who commented, it's their view also.

Perhaps I should summarize my statement from a different angle:

I do find the proposal of abandoning iocccsize altogether very appealing as well, and would be happy with that.

But if we introduce something like a "net size", as a formatting-independent measure for telling how "large" a program actually is, so that submissions get a fair comparison among other submissions of roughly the same net size, then neither spaces, nor comments, nor identifier lengths should count into that measure.

It's not about the limits. It is about the relative comparison of programs with a similar net size, and the urge of every contestant to keep that as low as possible, no matter where the actual hard limit is.

(But I do see the danger of #define D(d) #d as noted by @mame for which I don't have a good solution.)

[xexyl]

.. and regardless of what my thoughts are, I want you to know @vog, that I do appreciate your thoughts and I hope that I did not sound too dismissive. I have been awake too long and my sleep is totally upside down which does not help. Not that that would be an excuse if it did sound dismissive but it might help explain some of it (but I hope it didn't come across that way obviously).

Thanks for the clarification! I found it indeed very annoying, as a contestant for so many years, to be belittled as if I was a newbie trying to bend the rules to their liking. I'm happy you brought this up on your own, though, as it saved me from having to do so myself.

Yes well I'm happy I did. I have said for years that sometimes when someone is passionate about something they can come across as too aggressive (even if it's not the intention). Whether that is what happened here or not I don't know but I think it probably contributed to it.

In general I do appreciate attempts to bring up points whether or not I agree with them. Obviously there are some exceptions but your feedback is not wrong or right. Whether the judges will do anything (as I think they probably won't given discussion with @SirWumpus, Landon and me, with Landon telling me personally and also @SirWumpus and me that Leo was not happy with the rule 2 changes and also the remarks at the end of IOCCC28 [that is after the winners were announced and in the remarks on size in particular]) is another matter.

And that holds for other things too - not just the contest. It can come up with non-technical things too. Not only can it but it does and has. I think anyone who says this is not possible has not given it enough thought OR they simply have never been in such a situation or they're not as passionate as they might believe!

Maybe I'm wrong though. I've certainly been known to be wrong: as all humans have.

I PERSONALLY do think that smaller size (that is the way it is now) is more interesting because it is more of a challenge and I also don't see how your points are necessarily strictly correct (as in we don't need more bytes for formatting and other things) but that does not mean your view is wrong any more than my view is right (or not) because it's just your view and my view and everyone else who commented, it's their view also.

Perhaps I should summarize my statement from a different angle:

I do find the proposal of abandoning iocccsize altogether very appealing as well, and would be happy with that.

That for certain will not happen. Landon and Leo would both tell you that flat out. As for me I quite like the tool because as I said it's easy to do (remember how it was decades ago when there was no tool telling you the size?) and now that mkiocccentry exists it does it for you (but you can still use the tool separately as you're developing OR you can use the -d or -s seed options) it's even easier (I remember when I had a rule in my Makefile for development - I had one for submission and one for development, and I had a submit/ subdirectory due to how we had to upload files individually which was REALLY not very pleasant). But not only that it makes for a challenge which is part of the contest!

But if we introduce something like a "net size", as a formatting-independent measure for telling how "large" a program actually is, so that submissions get a fair comparison among other submissions of roughly the same net size, then neither spaces, nor comments, nor identifier lengths should count into that measure.

To help out I won't say much more because I already know the judges' view. At least on this. But admittedly for this one I'm too tired to even parse this entirely so that's another reason.

It's not about the limits. It is about the relative comparison of programs with a similar net size, and the urge of every contestant to keep that as low as possible, no matter where the actual hard limit is.

Well it might be worth remembering this.

That is especially because of Leo's view I think but knowing Landon I also know that he rather agrees with it - just maybe not quite as much. In any case he told me that Leo is flat against it changing anytime soon and that means rule 2 both 2a and 2b.

[xexyl]

(But I do see the danger of #define D(d) #d as noted by @mame for which I don't have a good solution.)

I actually used that in what I found VERY amusing ways in 2020/ferguson1.

The most amusing one was this line:

static  const char*s  =Z(       ; +<>^v);

... and how I used it:

q X,Y,s[*D+2& (1        <<3)-!Q]);

where q was #define q mvaddch(. I explained the magic in detail in my obfuscation.md (I think that was it) file which the judges wrote (I am not adding bold here - this is what the judges put in):

Read ONLY if you really must give up trying to de-obfuscate!

[SirWumpus]

BTW for those who do not know or don't recall, the History Of Sizes (sounds like a Harry Potter spell book) is worth looking at.

[xexyl]

BTW for those who do not know or don't recall, the History Of Sizes (sounds like a Harry Potter spell book) is worth looking at.

I actually had that in mind when I was writing some of my replies.

(sounds like a Harry Potter spell book)

Please explain.