I read the J Incunabulum before encountering this, and the point that stands out is that you don't start by jumping into the middle of it like many programmers who are familiar with C will do; the macros defined at the beginning will confuse you otherwise. They also build upon previous ones, so the code ends up climbing the "abstraction ladder" very quickly. I personally like the Iterate macro (i), for how it compresses a relatively verbose loop into a single character; and of course in an array language, the iteration is entirely implicit.
In other words, I believe the reason this code is hard to read for many who are used to more "normal" C styles is because of its density; in just a few dozen lines, it creates many abstractions and uses them immediately, something which would otherwise be many many pages long in a more normal style. Thus if you try to "skim read" it, you are taking in a significantly higher amount of complexity than usual. It needs to be read one character at a time.
As someone who has spent considerable time working with huge codebases composed of hundreds of tiny files that have barely any substance to them, and trying to find where things happen becomes an exercise in search, this extreme compactness feels very refreshing.
I also spent some time with the Incunabulum and came away with a slightly different conclusion. I only really grokked it after going through and renaming the variables to colorful emojis (https://imgur.com/F27ZNfk). That made me think that, in addition to informational density, a big part of the initial difficulty is orthographic. IMO two features of our current programming culture make this coding style hard to read: (1) Most modern languages discourage or forbid symbol/emoji characters in identifiers, even though their highly distinctive shapes would make this kind of code much more readable, just as they do in mathematical notation (there's a reason APL looked the way it did!). (2) When it comes to color, most editors default to "syntax highlighting" (each different syntactic category gets a different color), whereas what's often most helpful (esp. here) is token-based highlighting, where each distinct identifier (generally) gets its own color (This was pioneered afaik by Sublime Text which calls it "hashed syntax highlighting" and is sometimes called "semantic highlighting" though that term was later co-opted by VSCode to mean something quite different.) Once I renamed the identifiers so it becomes easier to recognize them at a glance by shape and/or color the whole thing became much easier to follow.
> (2) When it comes to color,
Call me boomer if you wish, but if you can't grasp the value of having your code readable on a 24 rows by 80 columns, black and white screen, you are not a software developer. You are not even a programmer: at most, you are a prompt typist for ChatGPT.
I also joke God made the VT100 with 80 columns for a reason.
That said, ~60 characters per printed line has been the typographer’s recommendation for much longer. Which is why typographers dislike Times and derivatives when used on normal-sized single-column pages, as that typeface was made to squeeze more characters into narrow newspaper columns (it’s in the name).
And yet I still have a utility named "~/bin/\uE43E"
I prefer having a consistent information density regardless of zoom level. When I would like to see more details, I would like to achieve that by zooming in. When I want the overview, I'd prefer to zoom out and have certain details omitted from the map.
Having a clear and by-convention code organization is one way to achieve this. Then to drill into the details, just navigate the project directory to the right file.
For rabbit Hole style hunting, following references/symbol usage/definition is ideal, which is enabled by modern IDEs.
K and family are made for data analysis. Data analyses are relatively simple software projects that don't have a very wide scope. I think this dense style of programming falls apart when you consider the breadth of requirements of typical modern application software.
Depends on your viewpoint. For some a car is just 4 wheels that take you somewhere. For a mechanic it is a world full of valves and pipes.
But I hope not every team builds a car from scratch.
It seems like developers actually prefer large codebases and having to use recursive search through multiple layers of sub directories
I prefer no sub directories and being able to just grep against *.[ch] with no recursion
I think projects in Java languages are the worst when it comes to having to search through numerous small verbose files having barely any substance to them. IDEs probably make this easier but I don't use one
Years ago I read that Whitney's "IDE" is something like the Windows console and Notepad. He has said in interviews that he wants all the code to fit on a single page
APL taught me the importance of comments - if I didn’t comment my code thoroughly I would forget how it works and what it did as soon as I moved away from the keyboard. It is a cruel language.
This is the main insight in my breakdown of the J Incunabulum:
https://blog.wilsonb.com/posts/2025-06-06-readable-code-is-u...
When I first encountered it years ago, the thing was impenetrable, but after learning APL to a high level, it now reads like a simple, direct expression of intent. The code even clearly communicates design tradeoffs and the intended focus of experimentation. Or more on the nose, to me the code ends up feeling primarily like extremely readable communication of ideas between like-minded humans. This is a very rare thing in software development in my experience.
IMHO, ideas around "readable code" and "good practices" in software development these days optimize for large, high-turnover teams working on large codebases. Statistically speaking, network effects mean that these are the codebasese and developer experiences we are most likely to hear about. However, as an industry, I think we are relatively blind to alternatives. We don't have sufficient shared language and cognitive tooling to understand how to optimize software dev for small, expert teams.
> DO defines our basic loop operation, so iterations will probably all naïvely be O(1);
Shouldn't that be "naïvely be O(n)"?
Ah, like Stephen Bourne
It’s probably more accessible than APL since its symbols can be found on conventional keyboards.
The C pre-processor is probably one of the most abused pieces of the C toolchain and I've had to clean up more than once after a 'clever' programmer left the premises and their colleagues had no idea of what they were looking at. Just don't. Keep it simple, and comment your intent, not what the code does. Use descriptive names. Avoid globally scoped data and functions with side effects.
That doesn't look smart and it won't make you look smart, but it is smart because the stuff you build will be reliable, predictable and maintainable.
Is it possible to command the preprocessor to take the source files as input and print them out with that one particular macro expanded and no other changes?
Intuitively, it sounds like it should be possible, and then you'd end up with a code base with a bunch of repetition but one fewer too-clever abstraction - and refactoring to deal with repetition (if necessary!) is a far more approachable and well-understood problem.
(Kind of like how some fancy compiles-to-javascript languages have a literal 'mytool --escape' command that will turn the entire code base into a plain, non-minified javascript in case you ever want to stop using them.)
I found this on SO:
https://stackoverflow.com/questions/59553295/selective-macro...
Maybe that would work for your use case?
What I like about your question is that I always assumed the answer was a hard 'no' but that appears not to be the case.
Even if a whitelist is not available (the SO question involves a particular C++ preprocessor and may not apply to others), a hacky approach might be to comment out all the #defines in the codebase, uncomment the ones you want to get rid of, and then run the full preprocessor task on it. Ugly but probably doable for a one-time refactoring.
Do you think the article meant to say it was more likely that the code wasn't inspired by APL?
I do agree that Whitney was inspired to some extent by APL conventions (not exclusively; he was quite a Lisp fan and that's the source of his indentation style when he writes multi-line functions, e.g. in [1]). The original comment was not just a summary of this claim but more like an elaboration, and began with the much stronger statement "The way to understand Arthur Whitney's C code is to first learn APL", which I moderately disagree with.
[0] https://aplwiki.com/wiki/List_of_open-source_array_languages
That's backing for a claim.
Also, I haven't once written APL. I think this might've been borderline trolling, just because of how little investment I have in the topic in reality. Sorry.
I wondered if I was missing something, so looked at the source, to find the following:
<div style='font-family:monospace'>k
Example: https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh...
And in every field they work well for the average case, but are rarely the best fit for that specific scenario. And in some rare scenarios, doing the opposite is the solution that fits best the individual/team/project.
The interesting takeaway here is that crowd wisdom should be given weight and probably defaulted if we want to turn off our brains. But if you turn on your brain you will unavoidably see the many cracks that those solutions bring for your specific problem.
Just because you succeed at one says nothing about other practical and important metrics.
The proper way to read it is to understand the problem and its pros and cons.
Without going long in the speculation, the situation likely was: there's only one guy who really can deliver this because of his knowledge, cv and experience and we need it.
And at that point your choice is having a solution or not.
But even if we grant that only one person could deliver a solution, it wouldn’t change the fact that you’re giving up on certain things to get it.
This was a very fun read that I'm fairly convinced I will have to come back to.
and I do like `#define _(e...) ({e;})` – that's one where I feel the short macro name is OK. But I'd like it better if that were just how C worked from the get-go.
Very nice discussion at the end of the article. There are good things to be learnt from this code and its discussions even if you disagree with some or even most of the style.
conditional-expression:
logical-OR-expression
logical-OR-expression ? expression : conditional-expression
expression:
assignment-expression
expression , assignment-expression
assignment-expression:
conditional-expression
unary-expression assignment-operator assignment-expression
unary-expression:
postfix-expression
++ unary-expression
-- unary-expression
unary-operator cast-expression
sizeof unary-expression
sizeof ( type-name )
alignof ( type-name )
assignment-operator: one of
= *= /= %= += -= <<= >>= &= ^= |=
... and so on ...
$ cat foo.c
int main(void) {
if () {}
}
$ clang -std=c17 -pedantic -Wall -Wextra foo.c && ./a.out
foo.c:2:9: error: expected expression
2 | if () {}
| ^
1 error generated.
$ cat bar.c
#include <stdio.h>
int main(void) {
printf("%d\n", 0 ?: 99);
printf("%d\n", 1 ?: 99);
}
$ clang -std=c17 bar.c && ./a.out
99
1
$ clang -std=c17 -pedantic bar.c && ./a.out
bar.c:3:23: warning: use of GNU ?: conditional expression extension, omitting middle operand [-Wgnu-conditional-omitted-operand]
3 | printf("%d\n", 0 ?: 99);
| ^
bar.c:4:23: warning: use of GNU ?: conditional expression extension, omitting middle operand [-Wgnu-conditional-omitted-operand]
4 | printf("%d\n", 1 ?: 99);
| ^
2 warnings generated.
99
1
[2] https://groovy-lang.org/operators.html#_elvis_operator
[3] https://gcc.gnu.org/onlinedocs/gcc/Syntax-Extensions.html
[4] https://gcc.gnu.org/onlinedocs/gcc/Conditionals.html
[5] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3299.pdf
#define _(e...) ({e;})
#define x(a,e...) _(s x=a;e)
#define $(a,b) if(a)b;else
#define i(n,e) {int $n=n;int i=0;for(;i<$n;++i){e;}}
```
>These are all pretty straight forward, with one subtle caveat I only realized from the annotated code. They're all macros to make common operations more compact: wrapping an expression in a block, defining a variable x and using it, conditional statements, and running an expression n times.
This is war crime territory
#define $(a,b) if(a)b;else
due to not having brackets. So it's just extremely lazy to.
> Some of these are wrong to[o] <- that needs an extra 'o' > due to not having brackets. <- that one is fine > So it's just extremely lazy to[o]. <- that needs an extra 'o' too
'to' comes in two versons, 'too' and 'to', both have different meanings.
The whole point of the piece seems completely lost on some readers. Yes, we all know that #define $(a,b) if(a)b;else is questionable. I don't need a crash course on C macros in the comments, thank you. The author already acknowledges that Whitney's style is controversial. Do we really need to keep rehashing that point in every comment, or can we finally focus on how all this unconventional code fits together beautifully to form a working interpreter?
This is an enduring great & terrible thing about sites like HN and reddit: As people become more senior & experienced, junior engineers come in to fill the ranks. You and I don't need a crash course on C macros in the comments. But I promise you, a lot of people here have no idea why #define $(a,b) if(a)b;else is a weird C macro.
How much should HN cater to junior engineers?
The assumption that HN should cater to junior engineers is curious. It implies a purpose the site has never claimed to have.
People have a silly need to point out the obvious as a crutch to their ego.
'Hey, look at this interesting way of using the CPP to create a DSL'
I'm fine with that. But this is precisely what aspiring C programmers should avoid at all costs. It's not controversial. It's bad.
I believe “oo” is probably an infinity error condition or some such not 100% sure. I didn’t see the author discuss it since they said it’s not used. Was probably used during development as a debug printout.
>These are all pretty straight forward, [...] wrapping an expression in a block, defining a variable x and using it, conditional statements, and running an expression n times.
Making your reader learn some ad-hoc shorthands you wrote to avoid declaring blocks, defining variables or writing conditions in my book is very impolite
Style doesn't need to be innovative.
I’ve never seen code written like this in real-world projects — maybe except for things like the "business card ray tracer". When I checked out Arthur Whitney’s Wikipedia page I noticed he also made the J programming language (which is open source) and the code there has that same super-dense style https://github.com/jsoftware/jsource/blob/master/jsrc/j.c
This is indeed Whitney's distinctive coding style, well known for its use in his various array programming language interpreters. His coding style is famously minimalist and idiosyncratic often fitting entire implementations of interpreters in a few pages.
This has been discussed a number of times on HN. I have collected some of the interesting comments on this topic from previous threads here in this meta comment: https://news.ycombinator.com/item?id=45800777#45805346
Lucky you. I've seen far worse (at least this is somewhat consistent). But this isn't C anymore, it is a new language built on top of C and then a program written in that language. C is merely the first stage compilation target.
When I see stuff like this, personally, I don't try to understand it, as code like this emerges from basically three motivations:
- The other person wanted to write in some other more (functional|object oriented|stack) language but couldn't, so they did this.
- The person couldn't be bothered to learn idioms for the target language and didn't care about others being able to read the program.
- The person intentionally wanted to obfuscate the program.
And none of these are good reasons to write code in a particular way. Code is about communication. Code like this is the equivalent to saying "I know the grammatical convention in English is subject-verb-object but I feel like speaking verb-object-subject and other people will have to just deal with it"—which, obviously, is a horrible way to communicate if you actually want to share ideas/get your point across.
That all said, the desire to have logic expressed more compactly and declaratively definitely resonates. Unfortunately C style verbosity and impurity remains dominant.
More like 10 days understanding 100K loc or 30 days stabbing yourself in the eye over 4K loc
https://github.com/KxSystems/javakdb/blob/8a263abee29de582cd...
There's a decent chance your broker (or their dealers) are using stuff built on this.
- you have no interest in maintaining your code
- your code will never be maintained by someone else
- you know your C preprocessor better than you know your C compiler
- your favorite language isn't available for this particular target
- you don't mind object level debugging
- your idea of a fun time is to spend a few hours per day memorizing code
- you really are smarter than everybody else
Something like JCON (originally from mongodb, see https://blogs.gnome.org/chergert/2016/10/21/jcon/) is actually pretty nice IMO.
As developers we have to decide where and when this makes sense, just like with other language features, libraries, architectural patterns, etc.
At first, I thought it looked like line noise. $var on the left of the = sign? Constructs like $_ and @_? more obscure constructs were worse.
But I had to keep going and then one day something happened. It was like one of those 3d stereograms where your eyes have to cross or uncross. The line noise became idioms and I just started becoming fluent in perl.
I liked some of it too - stuff like "unless foo" being more a readable/human of saying if not foo.
perl became beautiful to me - it was the language I thought in, and at the highest level. I could take an idea in my mind and express it in perl.
But I had some limits. I would restrain myself on putting entire loops or nested expression on one line just to "save space".
I used regular expressions, but sometimes would match multiple times instead of all in one giant unreadable "efficient" expression.
and then, I looked at other people's perl. GAH! I guess other people can "express themselves in perl", but rarely was it beautiful or kind, it was statistically worse and closer to vomit.
I like python now. more sanity, (somewhat) more likely that different people will solve a problem with similar and/or readable code.
by the way, very powerful article (even if I intensely dislike the code)
The stated reason Whitney does this is - https://news.ycombinator.com/item?id=32202742
I wholeheartedly concur with popular opinion. It's like writing a program in obfuscated code.
Hmmm... his way of basically making C work like APL made me wonder: Is there a programming language out there that defines its own syntax in some sort of header and then uses that syntax for the actual code?
The company was originally a bunch of Access/VB6 programmers.
Then they wrote their VB code in PHP.
And then they wrote their PHP code in Python. It was disgusting.
The code registers a bit like FORTH in concept.
Ok, so this article is tongue in cheek. Good to know that up front.
you would add a special "typeball" into your IBM Selectric Typewriter. Some pics:
https://www.duxburysystems.org/downloads/library/texas/apple...
What a flex of patience!
I got too much other stuff to do than decode the voynich manuscript...
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?
"Which line was that again? Oh... "
Pics up the phone, dials.
"Honey, I won't be home in time for dinner."
The C preprocessor gives you enough power to shoot yourself in the foot, repeatedly, with anything from small caliber handguns to nuclear weapons. You may well end up losing control over your project entirely.
One nice example: glusterfs. There are a couple of macros in use there that, when they work are magic. But when they don't you lose days, sometimes weeks. This is not the way to solve coding problems, you only appear smart as long as you remember what you've built. Your other self, three years down the road is going to want to kill the present one, and the same goes for your colleagues a few weeks from now.
yes! like any craft, this works only if you keep practising it.
various implementations of k, written in this style (with iterative improvements), have been in constant development for decades getting very good use out of these macros.
And the C pre-processor has figured prominently in more than one such case in my career. And it was precisely in the kind of way that is described in TFA.
For something to be doable it needs to make economic sense as well and that's the problem with nightmare trickery like this. Initially it seems like a shortcut, but in the long run the price tag keeps going up.
What do you base that guess on?
I'm not saying it couldn't be done, I'm just saying that it sometimes just isn't worth it.
> People not tools write programs.
Yes. And just like people sometimes write crazy manifestos there isn't much point in fixing them, the purpose that they might have served is most likely better addressed by replacing them entirely.
> Also any serious discussion here ends up in politics.
Everybody knows HN doesn't do politics ;)
> If you design your software so that the programmers are fungible then the software suffers regardless of your choices.
Programmers are fungible not because they are cast from the same mold, but because - assuming they are responsible people - they can look past their present day horizon to the future, where after a lot of context switching they have to revisit that which they have made before, or, where they have to take over someone else's project, either because that person moved to a different role or because they've moved on entirely.
It is with such a future in mind that you can, if you want, make the life of that person a little bit easier by focusing on clarity of thought rather than terseness in expression. Nobody ever died for want of a few keystrokes more, but I'd have been a lot happier if some people made a habit of writing down first what the pile of executable spaghetti they wrought was supposed to be doing in the first place.
If you have not seen how bad it can get then more power to you.
Just one anecdote, which I may have posted on HN before, but a long time ago I worked for a game studio where there was a programmer who got into a fight with management. He left and I had to take over his project. All of the variable names were fruits and all of the functions were vegetables (or the reverse, as I said, it is long ago). There were no comments. But there were some bugs that needed fixing.
Clearly in his mind programmers were not fungible, and in my view the software suffered from his choices. So the one isn't necessarily a guarantee of the other (ok, n=1), though you might find them together every now and then.
I've seen some absolutely brilliant code that was clever and clear. That's the kind of thing that I aspire to, not to see how far I can push the CPP to do stuff it was never intended to do in the first place. We have contests for that sort of thing but it isn't the kind of construct that you should foist off on others in your line of work. Not if we're ever going to get serious about that engineering thing.
Recreational programming, that's a different story. Go wild, and I really hope you enjoy it. But if you submit your preprocessor based magical DSL as a pull request I'll nix it.
As much as one can use a given style for a personal project so can one for a professional one so long as it fills the given need. Too often (in my view) fungibility is seen as a preeminent requirement and layers and layers of self justifying processes are built on top of that. I’m only saying that’s a choice and the costs and benefits are not as obvious as most suppose.
Also you can minimize risks with redundancy but most presume those costs to be too high. But again this quickly becomes about politics.
I'd imagine a chef or a competent musician would still use their hard won skill when cooking for themselves or making music for their own enjoyment.
https://github.com/openzfs/zfs/blob/master/include/os/freebs...
See P2PHRASE() and friends. They were inherited from OpenSolaris.
I'm seeing this on multiple fronts, and it's quickly becoming an unsustainable situation in some areas. I expect I'm not alone in this regard.
Here's one from one of my favourite HN commenters posted at https://news.ycombinator.com/item?id=25902615#25903452 (Jan 2021):
"Its density is many times higher than most C programs, but that's no big obstacle to understanding if you don't attempt to "skim" it; you need to read it character-by-character from top to bottom. It starts off defining some basic types, C for Character and I for Integer, and then the all-important Array. This is followed by some more shorthand for printf, return, and functions of one and two arguments, all of the array type. The DO macro is used to make iteration more concise. Then the function definitions begin. ma allocates an array of n integers (this code is hardcoded for a 32-bit system), mv is basically memcpy, tr (Total Rank?) is used to compute the total number of elements, and ga (Get/Generate Array) allocates an array. This is followed by the definitions of all the primitive operations (interestingly, find is empty), a few more globals, and then the main evaluator body. Lastly, main contains the REPL. While I don't think this style is suitable for most programmers, it's unfortunate that the industry seems to have gone towards the other extreme." -- userbinator
Here's another from the same commenter on a different story at https://news.ycombinator.com/item?id=39026551#39038364 (Jan 2024):
"There's something very satisfying about how this style seems to "climb the abstraction ladder" very quickly, but all of those abstractions he creates are not wasted and immediately put to use. I think much of the amazement and beauty is that there isn't much code at all, and yet it does so much. It's the complete opposite of the bloated, lazy, lowest-common-denominator trend that's been spreading in many other languages's communities." -- userbinator
Another from the story at https://news.ycombinator.com/item?id=40544283#40544491 (Jun 2024):
"For people not accustomed to the style of Whitney, you can read various HN threads from the past to learn more about why he writes programs the way he does. It's deliberate and powerful." -- hakanderyal
One more from the same story at https://news.ycombinator.com/item?id=40544283#40545004 (Jun 2024):
"Whitney is famous for writing code like this, it's been his coding style for decades. For example, he wrote an early J interpreter this way in 1989. There's also a buddy allocator he wrote at Morgan Stanley that's only about 10 lines of C code." -- papercrane
This parades all the reasons why you may want to avoid C like the plague, and then some. This stuff gives me nightmares.
Practically speaking, if people can't understand you, than why are you even on the team? Some problems can't be solved alone even if you live to a 116 years old.
Also, folks could start dropping code in single instruction obfuscated C for the lols =3
He's a software developer from a different era, when individual programmers wrote tiny (by today's standard) programs that powered entire industries. So for what he's been doing his entire career, neither lack of accountability, job security, or working with teams are really applicable.
Ivory tower politics is never an excuse, and failure to adapt to the shop standards usually means your position ends. Inflicting a goofy meta-circular interpreter on people is a liability.
Anyone competent would normally revert that nonsense in about 30 seconds, as it looks like a compressed/generated underhanded payload. "Trust me bro" is also not a valid excuse. =3
If you need help understanding what I mean, look at the credits of computer games released in the 80s and early 90s. You'll usually find a single programmer, with maybe one or two others, who contributed specialised parts like sound/music processing or special effects. No one cared about your particular programming style, because there were no big teams, no code reviews, no PRs. If you had questions, your fellow programmer would simply sit down with you and go over the details until you got familiar with their style and -code.
> failure to adapt to the shop standards usually means your position ends
Well, he runs his own company and has been his own boss for the past 32 years so again - this simply doesn't apply to him.
Code is read more than it is written, and most of us don’t and wouldn’t write in this style. This could mean he’s much smarter than the rest of us, or he could just be a jerk doing his own thing. In either case I’ve never had a good experience working with coders who are this “clever”. Real brilliance is writing code anyone can understand that remains performant and well tested. This is more like the obfuscated Perl contest entries. I guess it’s cool that you can do it, but good sense dictates that you shouldn’t.
As to OPs endeavor to understand this style, it is an interesting learning approach, but I think reading a lot of code in many styles that are actually used by more than one guy is likely to get make you “smarter”.
Which is why there's annotated and reformatted versions of the code. There's basically a "clean" version for those who care about such things and his "development"-version, which looks like executable line noise to the uninitiated.
> This could mean he’s much smarter than the rest of us, or he could just be a jerk doing his own thing.
Or - and I know this is difficult to comprehend these days - he cultivated this style over decades and it's just easier for HIM to work with code like this. No teams, no code reviews, no systems upon systems that need to interact. Just a single page program that does one thing and that he (the only contributor and his own boss) is able to understand and work with because that's what he did for past 50 years.
> In either case I’ve never had a good experience working with coders who are this “clever”.
Neither have I and I wouldn't write code like that either. I also don't think that reading and understanding such code makes you "smarter".
It's more of a peek into a different era of software development and one particular person's preferences.
Still it's amusing how Whitney's style seems to personally offend people. It's just a different way of programming that works for this one guy due to very specific circumstances. Neither the OP nor Whitney himself advocate for emulating this style.
So it was for the lols after all... Notably, a Lisp interpreter written in Lisp is a common assignment for second year CS students. In a production setting, there is little reason to misappropriate resources for such toys.
Bud Haggert still teaches smart people something very important about communication with interdisciplinary crowds:
https://www.youtube.com/watch?v=Ac7G7xOG2Ag
Doug Zongker's presentation similarly instructs people how to make better presentations to peers by demonstrating what not to do:
https://www.youtube.com/watch?v=yL_-1d9OSdk
Best of luck =3
I’ve personally never worked in an environment where code was only thrown out and replaced instead of modified.
It may be profitable having systems only a few people in the world could understand, but the scope of development is constrained.
I respect your opinion, but also recognize languages like Forth/Fortran actually killed people with 1 character syntax errors. People need to be as unsurprising as possible on large team projects. Sure, all our arrays today could be written in only l's , I's, and 1's like lIl1Il1lI[I1lI11l]... and being a CEO is also still not a valid excuse. =3
most startups are in the opposite situation. you need three different engineers to understand what you built last quarter because two people quit and one went to a different team. your clever abstractions become technical debt when the person who made them isn't around to explain them.
here's the real question: are you optimizing for the code or the business? sometimes boring, verbose, googleable patterns beat clever compression because your constraint isn't keystrokes - it's hiring, onboarding, and velocity when half your team is new. that's startup reality.
Perhaps I will start to playing with this macro style ladder of abstraction with the help of LLM. Such as literate programming with an AI agent. Computer is much better at parsing than us. We can stand on highest rung of the ladder.