When I was a beginner, A Gentle Introduction to Symbolic Computation worked for me. As the title suggests, it gently introduces concepts in a very beginner friendly manner, so even macros are easy enough to grasp by the time you get there. The diagrams and examples are great.

https://www.cs.cmu.edu/~dst/LispBook/book.pdf

Thanks for the recommendation. I appreciate it. I’ll definitely check this out.

These are all great. If you need to do something more involved, pexpect is also worth mentioning. It's a reimplementation of expect in python that's easy to be productive with quickly.

I used it in a previous job to automate configuring thousands of network devices

I guess people downvoting this don't get the joke?

What's the joke?

dwm and the community around it tend to use patches for absolutely everything, unlike most other projects. For most projects/codebases, maintaining patch sets is done for security, customizations, etc., but rarely are users expected to configure their window manager by modifying the source code. dwm is well known for being very minimalist, with many features people would expect from other window managers not being included out of the box. To get something more fully featured, users are meant to cobble together their own version of dwm with multiple patches. I'm not saying this workflow doesn't work for dwm and other suckless software projects, it's just that it's pretty out of the ordinary.

So, having some experience with the project and how different x and wayland are, when I saw this commenter had brought up the idea of making the switch from x to wayland a patch, it made me laugh out loud. The idea of leaning even further into the borderline degenerate amount of patching already done with suckless software to the point where you're practically rewriting the majority of it was very funny, and so I was confused about the downvotes.

Everything is an object in Python as well

Human beings get by quite well with extremely oversimplified (low resolution) abstractions. There is no need whatsoever for something even approaching universal or perfect. Humans aren't thinking about fundamental particles or solving differential equations in their head when they're driving a car or playing sports.

Yes, but the main thing here is that ALL software development is now "profit" in the short term. In theory you've developed a capital good that benefits you over time, hence the amortization.

Simplified 2021 example before 174:

    100k Revenue
    100k Software Dev Costs
    No profit or tax

Simplified 2022 example after 174:

    100k Revenue
    100k Software Dev Costs
    90k "profit"
    18.9k taxes

Above example is year one of suddenly having these taxes, because if your software costs are the same or lower over time it gets easier. It's just extremely painful for smaller and especially fast growing companies like startups without a lot of cash, especially when interest rates are so high.

Accountants: If I am wrong about the above, please correct me

The profit is 80k, not 90k, but the principle is correct. This will affect cash flow.

I'm generally not a huge fan of inlining the command or cluttering up my local directory with little scripts to get around the fact that it must be a subprocess you can send a signal to. I use a wrapper like this, which exports a function containing whatever complex logic I want to time out. The funky quoting in the timeout bash -c argument is a generalized version of what aidenn0 mentioned in another comment here (passing in args safely to subproc).

    #!/usr/bin/env bash

    long_fn () { # this can contain anything, like OPs until curl loop
      sleep $1
    }

    # to TIMEOUT_DURATION BASH_FN_NAME BASH_FN_ARGS...
    to () {
      local duration="$1"; shift
      local fn_name="$1"; shift
      export -f "$fn_name"
      timeout "$duration" bash -c "$fn_name"'  "$@"' _ $@
    }

    time to 1s long_fn 5 # will report it ran 1 second

You need `"$@"`, not just `$@` at the end of the command. Otherwise it will split any arguments that have spaces in them. E.g. try

    long_fn() {
      echo "$1"
      sleep "$2"
    }

    to 1s long_fn "This has spaces in it" 5

My bad on that typo. I write "$@" so often in shell scripts that I should know better. Also would've been caught by shellcheck. Outside the hn edit window though, so my mistake is permanent :(

A bit confusing for sure, but I think (not sure) I get what they're saying. Training a nn (for visual tasks at least) consists of training a model with much more dimensions (params) than the input space (eg: controller inputs + atari pixels). This contrasts with a lot of what humans do, which is take higher dimensional information (tons of data per second combining visual, audio, touch/vibration, etc) and synthesizing much lower dimensional models / heuristics / rules of thumb, like the example they give of the 5 second per mile rule for thunder.

Actually no, it's not interesting at all. Vague dismissal of an outsider is a pretty standard response by insecure academic types. It could have been interesting and/or helpful to the conversation if they went into specifics or explained anything at all. Since none of that's provided, it's "OpenAI insider" vs John Carmack AND Richard Sutton. I know who I would bet on.

It seems that you’ve only read the first part of the message. X sometimes aggressively truncates content with no indication it’s done so. I’m not sure this is complete, but I’ve recovered this much:

> I read through these slides and felt like I was transported back to 2018.

> Having been in this spot years ago, thinking about what John & team are thinking about, I can't help but feel like they will learn the same lesson I did the hard way.

> The lesson: on a fundamental level, solutions to these games are low-dimensional. No matter how hard you hit them with from-scratch training, tiny models will work about as well as big ones. Why? Because there's just not that many bits to learn.

> If there's not that many bits to learn, then researcher input becomes non-negligible.

> "I found a trick that makes score go up!" -- yeah, you just hard-coded 100+ bits of information; a winning solution is probably only like 1000 bits. You see progress, but it's not the AI's.

> In this simplified RL setting, you don't see anything close to general intelligence. The neural networks aren't even that important.

> You won't see _real_ learning until you absorb a ton of bits into the model. The only way I really know to do this is with generative modeling.

> A classic example: why is frame stacking just as good as RNNs? John mentioned this in his slides. Shouldn't a better, more general architecture work better?

> YES, it should! But it doesn't, because these environments don't heavily encourage real intelligence.

I'm not sure what the moral is from this, but if Atari games are just too easy, at the same time the response of the machine-learning guys to the challenge of the NetHack Learning Environment seems to have mostly been to quietly give up. Why is generative modeling essential to finding harder challenges when NetHack is right there ...?

Alex Nichol worked on "Gotta Learn Fast" in 2018 which Carmack mentions in his talk, he also worked on foundational deep learning methods like CLIP, DDPM, GLIDE, etc. Reducing him to a "seething openai insider" seems a bit unfair

It's a OpenAI researcher that's worked on some of their most successful projects, and I think the criticism in his X thread is very clear.

Systems that can learn to play Atari efficiently are exploiting the fact that the solutions to each game are simple to encode (compared to real world problems). Furthermore, you can nudge them towards those solutions using tricks that don't generalize to the real world.

Right, and the current state of tech - from accounts I’ve read, though not first hand experienced - is the “black box” methods of AI are absolutely questionable when delivering citations and factual basis for their conclusions. As in, the most real world challenge, in the basic sense, of getting facts right is still a bridge too far for OpenAI, ChatGPT, Grok, et al.

See also: specious ethics regarding the training of LLMs on copyright protected artistic works, not paying anything to the creators, and pocketing investor money while trying to legislate their way around decency in engineering as a science.

Carmack has a solid track record as an engineer, innovator, and above the board actor in the tech community. I cannot say the same for the AI cohort and I believe such a distinction is important when gauging the validity of critique or self-aggrandizement by the latter, especially at the expense of the former. I am an outlier in this community because of this perspective, but as a creator and knowledgeable enough about tech to see things through this lens, I am fine being in this position. 10 years from now will be a great time to look back on AI the way we’re looking back at Carmack’s game changing contributions 30 years ago.

He did go into specifics and explained his point. Or have you only read his first post?

Do you have an X account, if you're not logged in you'll only see the first post in the thread.

x.com/... -> xcancel.com/...

I use a Chrome extension to auto replace the string in the URL, works very well.

It’s not vague, did you only see the first tweet or the entire thread?

> We studied 198 randomly sampled, real world fail- ures reported on five popular distributed data-analytic and storage systems, including HDFS, a distributed file system [27]; Hadoop MapReduce, a distributed data- analytic framework [28]; HBase and Cassandra, two NoSQL distributed databases [2, 3]; and Redis, an in- memory key-value store supporting master/slave replica- tion [54]

So, analyzing databases, we picked Java, Java, Java, Java, and one in C. This does not seem very random. I suppose this may provide insight into failure modes in Java codebases in particular, but I'm not sure I'd be in a hurry to generalize.