b-decoded

I use a concise language that I know well. When your language doesn't have so much boilerplate junk, you don't need an AI to generate it for you. Try working in a really concise language, e.g. an APL-family one, for a bit. Once you get used to it you might take the style back to other languages, it's possible to write fairly concise code in most languages if you actually try. See e.g. https://github.com/tlack/b-decoded/blob/master/b.c

A previous HN thread on Arthur Whitney's "B" is relevant here. Follow my previous comment here - https://news.ycombinator.com/item?id=30416737 where user "yiyus" goes through the code line-by-line adding detailed notes for comprehension. Also see https://github.com/tlack/b-decoded

I used to believe this but i don't anymore. From https://github.com/tlack/b-decoded Arthur is famous for his very dense programming style. Most C programmers would scream when seeing this code. In his view (and others in the terse scene), it is much better to have everything in your application readable on the screen at once than to have great names for things or a lot of white space to comfort the first timer reader. To them, once you've sufficiently studied that screen or two of code, you can understand all of it at the same time. If it's spread out over thousands of files, it's very difficult to understand all of it, which leads to bugs, unnecessary abstraction, and the need for advanced tooling just to work with your own project's code. He wants to see the code "all at once" so he can understand all of its behavior without paging arou

Here's some links relating to this style of code that you may find useful: https://docs.google.com/document/d/1W83ME5JecI2hd5hAUqQ1BVF3... https://github.com/tlack/b-decoded https://chat.stackexchange.com/rooms/90748/conversation/ngn-... They're not 1.5 paragraphs per line, but enough to give a taste of the implementation style.

Courtesy of 'yiyus: https://docs.google.com/document/d/1W83ME5JecI2hd5hAUqQ1BVF3... Also 'tlack's attempt at it: https://github.com/tlack/b-decoded

That is true. There are some I never edit as long as they continue to work. Others I am continuously editing on a regular basis. Others are really "one-offs" that I keep just in case. If I need them again in the future, I might rewrite from scratch if my learning has changed significantly since the last edit. I have found the best thing I can do for the "future me" is to keep programs relatively small and keep the number of files low. This is one reason I like terseness and the idea of keeping "everything" (almost) on one page/screen. I am just not capable of understanding a large project as deeply as I would like. I thought this paragraph summarises the issue well: "To them, once you've sufficiently studied that screen or two of code, you can understand all of it at the same time. If it's spread out over thousands of files, it's ve

For those interested but needing a little help deciphering Thomas Lackner has a handy repo: https://github.com/tlack/b-decoded