27th International Obfuscated C Code Contest winners published
ioccc.org
ioccc.org
One area of technology that seems to have continued the work of discovering underhanded techniques is the realm of cryptocurrency, specifically the "Solidity Underhanded Contest". The results for 2020 are here[1], which links to (spoiler alert) a great trick on line 65 here[2] (select the line character by character with a mouse to reveal it).
[0] https://en.wikipedia.org/wiki/Underhanded_C_Contest
[1] https://blog.soliditylang.org/2020/12/03/solidity-underhande...
[2] https://github.com/ethereum/solidity-underhanded-contest/blo...
This has been crucial in debugging really strange issues students manage to create.
Two spaces when writing an email get converted into at least 1 non-breaking space and these make bash sad. Unfortunately there isn’t really a good way to have bash treat them as white space which is annoying.
https://99percentinvisible.org/episode/the-roman-mars-mazda-...
This made me reflect on whether good language design should limit expressiveness of code?
https://www.usenix.org/system/files/conference/usenixsecurit...
describing it as a way of circumventing security measures that try to ensure that a particular control flow is followed in a compiled binary. In that case the security goal could be seen as forcing the compiled program to behave in a way close to what a human writer (or reader) would expect, while this method gets around that. So in that way, it could still be a problem, because the programmer appeared to write specialized program X but it can potentially be induced to behave like unrelated program Y at run time.
Yes, I think so. "Smart" code is smart for 5 min, after that it becomes a liability
* Programming languages should be general.
* Programmers should be competent and disciplined enough not to misuse that generality.
I absolutely hate programming in languages like Java, designed for idiot programmers. I understand their place -- there are a lot of incompetent programmers, and we need to constrain them, and a lot of places with boring IT problems who won't be able to hire competent people -- but it's not something I'd ever want to touch. That sort of workplace and that sort of language would make me miserable.
> Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
Compare debugging something like git or hg (clever, simple data structure) to cvs or svn (non-clever, standard data structure).
Systems like git and hg don't just do more; they're also far more debuggable thanks to clever. That's not an IOCCC type of cleverness, but a deep, deep clever.
Likewise, consider general-purpose data stores (such as a KVS or an RDBMS) compared to a one-off data structures mapping directly to your data. The design of the original RDBMS was hyper-clever.
A wise man knows when to be clever and when not to be clever. I don't know of any programming language designer who can make that determination for me; it's too domain-specific. If you can rely on programmers to not be clever for inane reasons, you can allow them to be clever for architecturally-critical reasons.
You don’t think Brian Kernighan is wise?
So think more Python and less C, things like:
while (*a++)
I do a lot of my work in Python these days. One of the really nice things Python did is take the major design patterns in Lisp/Scheme, which were super-powerful but quite unreadable, and gave visually-distinct ways of expressing those.
For example, major design patterns like maps and filters are done as list comprehensions, which are nice.
Ditto for decorators.
The key thing is that I still have general-purpose functional programming (except for tail recursion, which I dearly miss), but I use constructs which don't have explicit Python semantic quite rarely. Still, there are times when I can do something which will e.g. cut architectural complexity in half, and that's well worth a little bit of magic code. I'll usually try to do that in an isolated, well-documented file which has the magic. That's enabled by having a language which relies on programmers having discipline rather than handcuffs.
It's a lot cleaner than the architectural contortions I see for any use of Java beyond its target (Java has a nearly ideal set of expressiveness for making an inventory management system, CRM, store web site, or similar types of database-backed applications).
As a footnote, the place for the type of C code you gave is low-level programming. That's a disappearing market, as even microwaves can now afford RISC chips in the tens of megahertz with modern memory managements, but for hardware, you really care not just what happens, but how it happens. I know what machine code while(*a++) will translate to, and for those sorts of systems, that's nice.
There's a magic to a sonnet that isn't found in blank verse. Limitations can do a lot to improve writing.
The "base language" would be boring, pedestrian, optimizing for zero surprises. But inside an expressive{} block, you could have macros, operator overloading, DSLs, first-class continuations, you name it.
Quite often there is something that "has not been seen before" - those entries do have a greater chance of being picked. The Ig-Nobels are seen as anti-Nobels. It is somewhat ironic that one of the few programming accolades you can be awarded is for writing code that will win an IOCCC award.
Of python: I am quite biased against the language - there are limited ways to speak or communicate it to a blind or deaf person. Python relies on the physical layout and structure to be semantically correct. (Python correctness does not survive whitespace or silence removal - which requires both working eyes and ears)
A Python screen reader would not have the same power. It would somehow have to communicate the significant whitespace to the user through sound. You cannot "remove the silence" when listening to a Python program, in the same way that you cannot strip out whitespace without changing the behaviour of the program.
However, I don't know if there are any screen readers that have been taught to do that.
If you are visually impaired you may have to use a screen reader. If that screen reader cannot correctly 'say' the whitespace, it may be difficult to understand languages such as Python where indentation is significant.