Comment by frankjr
1 year ago
The code looks heavily obfuscated. It's more like "source available" than open source. E.g.
g(_M,W-=1<<f;xx=M[f];M[f]=x)Ui(M_,Ux=M[i];x?(W+=1<<i,M[i]=xx,x):30>i?_M(i,M_(i+1))+(2*n0<<i):OO())f(_r,pt?x:65535&rx?(--rx,x):e(if(!Tx)n(_r(xU))_M(mx,x-n0);x))f(r_,pt?x:65535&++rx?x:OO())
Edit: Looking at it a bit more, I can't tell if the code is obfuscated or if the author really wrote it like this...
That's the "Whitney style". See: https://code.jsoftware.com/wiki/Essays/Incunabulum
It's writing C in array-language style rather than intentional obfuscation.
Thanks. I'm now reading this where people are trying to explain what happened in the ref/ directory.
https://github.com/kparc/ksimple/blob/main/a.c
Thanks for that link. The comments there help a lot. If I understand them, this is a minimal implementation of K with a lot of limitations, such as:
"the only supported atom/vector type is 8bit integer, so beware of overflows"
Still, it's fascinating how an interpreter can be written with such a small amount of code.
4 replies →
Personally I believe in a sort of "evolution" of software that operates independently of intentions of the programmers.
I can totally believe that he didn't intentionally obfuscate it, but its incomprehensibility made it harder for other people to make a knockoff and thats why it survived and became successful.
You may not believe it, but that's how K/Q/J people write C code.
Bonus: Go visit and do "View Source" on that website. Even HTML has fragrance of K.
I don't understand how. How do you debug something this? How do you go about fixing a bug? There are no docs nor tests. It seems like one would spend hours just trying to understand what's going on. Is there a good source on their methodology? Because my mind is blown.
Try J or APL, K, BQN, or April, and be prepared to rethink how you implement solutions to problems you've tackled in other PLs. I am an array language user and fan. I have been playing with April and I use J regularly at home and sometimes for work when I can.
From the April github site: "April compiles a subset of the APL programming language into Common Lisp. Leveraging Lisp's powerful macros and numeric processing faculties, it brings APL's expressive potential to bear for Lisp developers. Replace hundreds of lines of number-crunching code with a single line of APL."
I recommend checking out more of the APL family language family and the history of the notation, highly interesting. Almost like a parallel universe of computing, when you look past the syntax.
11 replies →
You do actually spend hours to understand what's going on. Basically, the idea is that your implementation will be so short and condensed that you'll just rewrite from scratch to fix bugs.
The environment is very interactive. It also helps when you can fit do much more on screen, quite possibly the entire program.
Using a debugger is basically out of the question. The theory is that the conciseness and lack of fluff makes it easier to reason about once you’ve mustered the requisite focus.
Does writing in this way has any advantage in practical terms (not aesthetically reasons)?
I've heard it said that it becomes easy to spot common patterns and structures in this style. Without knowing the idioms it's difficult to read but apparently once you know the idioms, you can scan it and understand it well.
It is for APL/k/j; you see patterns popping up in very dense code which does a lot, which does make it readable really once used to it. But most people never get to that point (or even ever look at APL of course).
1 reply →
The only possible advantage I can think of is that you can fit more code on one screen so I guess in theory you can see your context more easily. But that seems pretty minor compared to... well, look at it!
I read a couple of other threads and some people try to claim less code = fewer bugs, but that's pretty clearly nonsense otherwise minifiers would magically fix bugs.
As for why people actually use this (it seems like they really do), my guess would be that it's used for write-only code, similar to regexes.
Like, using a regex you can't deny that you get a lot of power from not many keystrokes, and that's really awesome for stuff you're never going to read again, like searching code in your editor, one throwaway shell commands.
But they also tend to be completely unreadable and error prone and are best avoided in production code.
It's not that any method of reducing code length fixes bugs, it's just happens that optimizing code to be read and worked on by domain experts leads one toward patterns that secondarily end up manifesting as terse expressions. The terseness is certainly shocking if you're not accustomed to it, but it's really not a terminal goal, just a necessary outcome.
The disbelief on first encounter is totally reasonable, but from personal experience, once you've gotten past that and invested the time to really grok the array language paradigms, code like this Whitney style actually ends up feeling more readable than whatever features our current SE culture deems Good and Proper.
There are a whole lot of moving parts to the why and how of these ergonomics, so I don't expect to be able to convince anyone in a simple, short comment, but if you're at all interested and able to suspend disbelief a little bit, it's worth watching some of Aaron Hsu's talks to get more of a taste.
1 reply →
I suppose in our new world of LLMs, using as few tokens as possible means you can cram more in a small context window, which could be helpful in various ways.
2 replies →
> But they [regexes] also tend to be completely unreadable
Regular expressions can be constructed using various syntaxes. Some are optimized for writing them out quickly, and some are not. Choose the latter when going to production, and you'll be fine.
As for K/J/APL - it's similar. You can write incredibly terse code which works wonderfully in a REPL (console). Working in an interactive manner is the default mode of operation for those languages. If you ever worked with Numpy/Pandas or similar, in a REPL, you likely concocted similarly terse monstrosities. Check your %hist the next time you have a chance. Going to production, you naturally rewrite the code instead of just committing the first one-liner that produces the desired results.
2 replies →
That's just how Arthur Whitney writes code.