Replies: 6 comments 23 replies
-
|
Yes it does especially if it's something that looks like something else. That's just one example. Also it makes the program more compact even if it's not more obscure. That has some nice benefits too. Plus the size increase is not at this point final as they have said. Besides, even if it doesn't help obscure the code it doesn't mean it's bad to have it. I think it does, though, because it's a lot harder to keep track of single letter identifiers than names. Also, as they say, they like well rounded obfuscation. If it was just single letter identifiers that would not win anyway. |
Beta Was this translation helpful? Give feedback.
-
|
Another example would be an entry where the identifiers are UTF-8 multibyte characters, consider how obfuscated an entry would look written in mix of Japanese, German, and Sanskrit. It certainly would be obfuscated to most readers. |
Beta Was this translation helpful? Give feedback.
-
The 'private tool' I was asked to write (and that's all I'll say :-) ) actually has some German in it but not noticeable as German. There certainly are cases where longer names can help with obfuscation but so too can single letters. It's not about JUST identifier names either. Consider this too: it's been over four years since the contest was open. I bet many people have already written code for the contest and to make them not use single letter identifiers would be really cruel and not fair. |
Beta Was this translation helpful? Give feedback.
-
Compact code is not necessarily interesting any more, consider the Rule 2b changes to move away from "blob" code. |
Beta Was this translation helpful? Give feedback.
-
True but the judges also don't like code that is bigger than it has to be. Compact code doesn't have to be a blob either. It certainly can be but just because code is compact doesn't mean it's blobby. I do like code in the contest that has longer identifiers but I also appreciate single character names. In the case of my entries it helps fit them on shirts. But that part is obviously a more personal reason (that also doesn't change anything above). |
Beta Was this translation helpful? Give feedback.
-
I'm not saying to disallow single letters, just allow moving away from it. Note:
I said |
Beta Was this translation helpful? Give feedback.
-
In fact it would have been very fun to do for the Enigma machine of 2020! I would have probably enjoyed that. |
Beta Was this translation helpful? Give feedback.
-
For the purpose of C I would think each character with/without diacritics would be treated differently, much like upper and lower case is different. In a French dictionary they group the words by e, ë, é, è (not as just 'e'). Same would be true of Hirigana and Katakana, same alphabet, but different glyphs (katakana is used for foreign words typically). |
Beta Was this translation helpful? Give feedback.
-
And then there's the debate in German: are they part of the alphabet or not. And then there's the Eszett (ẞ). I am not fluent in German (far from it!) but I know a bit and I find it a beautiful language (I know many people find it the opposite though); French I know absolutely nothing about except I don't know that I like it. I don't know if that's true and I know there are some really funny things about it (something to do with numbers to not get into rude things) but maybe I just don't like the sound of it. Maybe I haven't heard it enough to let it grow on me. Either way I know next to nothing if not nothing about it. I did have a thought that (and this is just a thought that popped into my head - I have absolutely no idea whether it's a good idea or not) maybe characters with diacritics (or the Eszett) might be counted as 2 bytes (or N+1 where N is what we had valid in the contest before) but I don't know what I would think about it either. It just popped into my head. If the size limit went back down I would definitely not want it but I guess that's not any more certain than your idea here. I do really appreciate the dialogue btw and your clarifying things too. |
Beta Was this translation helpful? Give feedback.
-
No point. Once you start talking characters, the idea of byte counting is pointless for text. Anyway most european alphabets are UTF8 2 byte sequences, while the Asain ones I think are 3 and/or 4 byte sequences. If you count by bytes, you penalise non-europeans for using their native alphabet. |
Beta Was this translation helpful? Give feedback.
-
That's true enough. It just popped into my head and thought I'd mention it. It would in a way penalise them but on the other hand they get to use extra characters. But then again ... that's not really nice and your point about size is also valid of course. Admittedly this was another concern of mine here anyway. |
Beta Was this translation helpful? Give feedback.
-
|
@lcn2 Any thoughts on #903 (reply in thread) ? |
Beta Was this translation helpful? Give feedback.
-
None at this time that we wish to make. Although is almost certain that such a shift would not occur without a lot of internal IOCCC judge discussion. The changes to rule 2 sizes were controversial and complex enough (and are still not fully settled, BTW). Our guess that anything close to what is being discussed might be post IOCCC28 at best (if it happens at all), but that is just a guess. That's why we remain silent observers in this discussion. |
Beta Was this translation helpful? Give feedback.
-
No longer silent though! :-) It makes sense what you say though. |
Beta Was this translation helpful? Give feedback.
-
That would be an interesting discussion to hear. Though I see no conflict or issue between the size changes and UTF8 support. One concerns size, the other embraces multibyte characters like the C standard. The more I think about the idea to move from octets to characters, the more I believe its time to make an effort to move from 1980's thinking in terms of ASCII only. UTF8 multibyte support has been around a long time now. But that is just me. |
Beta Was this translation helpful? Give feedback.
-
I'd like to hear that discussion too but I guess it's something only judges get to hear. The other part is a nice idea and I'm starting to like it too .. though I guess not sure entirely. Have a great rest of your day and thanks for the dialogue! Off for the night. |
Beta Was this translation helpful? Give feedback.
-
I've been thinking about this the past couple of years and how the judges feel about the following question:
Does compacting a program to use single letters for identifiers really help with obfuscation any more or is it a tired "trope"?Back in the day compacting functions and variables to single letters helped get the program within the size limits of Rule 2. There was a time too that this would aid in obfuscation (I remember one winner using combinations of
ofor all the identifiers). But has its time as an obfuscation technique become tired?Do the judges still find this interesting or are they now more interested in interesting concepts, data structures, and techniques and less so in the visual appearance (excluding the best layout winners). Would the use of proper meaningful (for some definition thereof) identifiers be just as good?
Imagine for example someone using all the words from "Jabberwocky" as identifiers in some order. You'd blow Rule 2 limit easy, but it should prove different. Is it worth considering for some future contest (not necessarily the next, maybe the next next one?) adding a new clause to Rule 2b such that:
All identifiers count at most two (2) octets towards Rule 2b.?Not sure if C library et al. should be count as-is or subject to the rule, just the developer's identifiers?
This would mean programs would start to appear more de-obfuscated for reading, while still bound in size. With a refocus on teaching and learning is this something to consider? (Maybe a new side contest? The IDCCC = Intl. Deobfuscated C Code Contest 😁).
Beta Was this translation helpful? Give feedback.
All reactions