loganmhb

I’m an array language novice but my favorite one so far is BQN. Much better documented than K derivatives. Not sure you could characterize any array language as having a “healthy userbase” though.

There’s a KSP mod called Principia which does some kind of n-body simulation in which Lagrange points do exist iirc.

For any other array language novices, I've experimented with K and J but had the best experience so far with BQN. It is a bit on the Lispy side like K but much better documented, and I thought the APL-esque symbolic alphabet was mnemonically helpful enough while reading code to justify learning an editor keyboard integration. (Plus it's fun.)

Especially concerning in light of that METR study in which developers overestimated the impact of AI on their own productivity (even if it doesn't turn out to be negative) https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o...

I once saw an explanation which I can no longer find that what's really happening here is also partly "man" and "woman" are very similar vectors which nearly cancel each other out, and "king" is excluded from the result set to avoid returning identities, leaving "queen" as the closest next result. That's why you have to subtract and then add, and just doing single operations doesn't work very well. There's some semantic information preserved that might nudge it in the right direction but not as much as the naive algebra suggests, and you can't really add up a bunch of these high-dimensional vectors in a sensible way.

E.g. in this calculator "man - king + princess = woman", which doesn't make much sense. "airplane - engine", which has a potential sensible answer of "glider", instead "= Czechoslovakia". Go figure.

I respect the forecasting abilities of the people involved, but I have seen that report described as "astonishingly accurate" a few times and I'm not sure that's true. The narrative format lends itself somewhat to generous interpretation and it's directionally correct in a way that is reasonably impressive from 2021 (e.g. the diplomacy prediction, the prediction that compute costs could be dramatically reduced, some things gesturing towards reasoning/chain of thought) but many of the concrete predictions don't seem correct to me at all, and in general I'm not sure it captured the spiky nature of LLM competence.

I'm also struck by the extent to which the first series from 2021-2026 feels like a linear extrapolation while the second one feels like an exponential one, and I don't see an obvious justification for this.

Plenty of people are ragging (justifiably) on Clean Code, but I really admire by contrast Ousterhout's commitment to balanced principles and in particular learning from non-trivial examples. Philosophy of Software Design is a great and thought-provoking read.

Martin Kleppmann's book Designing Data-Intensive Applications is a great starting point if you're not familiar with it.

The roads might actually cost more than that:

https://www.strongtowns.org/journal/2019/4/30/my-city-has-ma...

I wonder how much of this is an illusion of precision that comes from pattern matching on content from filler sites like https://www.free-hosting.biz/division/16-divided-7.html (I do not recommend clicking the link, but the result appears there).

The question is not whether perceptions are true -- that's irrelevant. Undoubtedly perceptions present a skewed and unreliable view onto reality. It's whether they exist at all. You can't trick someone who isn't looking.

Except everybody knows there is no "I", you're just a bundle of atoms, and a bundle that's changing from moment to moment.

This is begging the question in the other direction.

I have heard excellent things about Crossfire but alas have not had the chance to play it -- hopefully one of these days!

I have this feeling sometimes too, but I think there is an important aspect of complex board games, in particular strategy games that is missing from computer games. When you play a board game, you are forced to understand the rules (because you are the one executing them) so you are able to more fully consider their implications on strategy. (Of course, the mechanics must be tasteful in addition to complex in order for this to actually be a benefit.) In a computer game, my experience is that it's much easier to revert to playing by feel and lose that effect, and much harder to design a game where the full mechanics are obvious to the players. As a wargamer this is the main reason I prefer playing board wargames, even though they are not able to simulate in nearly as much detail as computer wargames.

When reading about Elasticsearch I was fascinated to learn that the JVM can often use 32-bit object pointers to address about 32GB of RAM when running in 64-bit mode: https://wiki.openjdk.java.net/display/HotSpot/CompressedOops

My impression was that the implications of sexism were directed at Levy, for glorifying the hackers who made Hamilton's work more difficult while trivializing her work to some degree, not so much at the hackers themselves, who indeed just broke something because they had an incomplete understanding of the system they were working on.

Just because Facebook is making these decisions based on profitability doesn't remove them from the moral sphere, though. If the side effects of the decisions Facebook makes are substantial (which seems common to me with ad-based business models) people are perfectly justified in being outraged because of those side effects, regardless of whether the decisions are good for Facebook's profits.

I second the recommendation of Style: Lessons in Clarity and Grace. That book did more than any other to help me both write more clearly and explain to others how to do so (was a writing tutor in college). Many writing books give concrete advice on trivialities and retreat to vague prescriptions on subjects like elegance and clarity. This book is the only one I've read that actually studies those aspects of writing and offers actionable advice on how to make writing clearer, more graceful and more elegant.

One of the nice things about the Clojure standard library is that most everyday functions actually do fit the first/last category (by design). Functions operating on sequences (map, filter, reduce, etc) take the sequence as the last argument and are suited for use with the ->> macro, while functions operating on data structures in a non-sequence context typically take the data structure first (assoc, conj, update) and are good for ->. So you get either:

    (->> (range 10)
         (map inc)
         (filter even?)
         (take 2)) ;=> '(2 4)

    (-> {:body {:some {:json :data}}}
        (assoc-in [:body :some :more-json] :more-data)
        (assoc :status 200)
        (update :body json/generate-string))
    ;;=> {:body "{\"some\":{\"json\":\"data\",\"more-json\":\"more-data\"}}", :status 200}
        

One would think curing cancer ought to be amongst humanity's greatest concerted challenges.

One of the reasons "curing cancer" is so difficult is that cancer itself is not really one disease but many, with diverse causes and treatments. What works for one kind cancer doesn't work for another, so some kinds are fully curable and others unstoppable, with of course many in between. New research tends to chip away at variations of the disease without being able to cure it wholesale. If you're interested in the recent history of cancer and cancer medicine, the book "The Emperor of All Maladies" is a fascinating treatment of the subject.

That does not match my understanding of first class functions, nor Wikipedia's.[1] Python's inner defs are not anonymous functions (which is what people usually mean by lambdas) but they are definitely first class - they can be returned from a function, stored in a data structure and so on. I agree with the grandparent that the need to label the closure is just an inconvenience, not a disqualification.

You can't have anonymous lambdas that aren't first class (how would you reference them?) but you can have first class functions that are not technically anonymous.

[1]https://en.m.wikipedia.org/wiki/First-class_function

If you like Javascript and you want to try a language with a good static type system, you might like Elm (http://elm-lang.org/). As a bonus, it has fantastic documentation and examples of small in-browser projets -- a clock, Pong, and so on.

I think it's interesting how much people's aesthetic preferences differ on lisp syntax. Personally, I think the parentheses are visually appealing, but it's probably an acquired taste. Even more than that, I actually now find it much more difficult to parse infix notation for math, equality and so on (and not just operators in syntax-heavy languages like Haskell). Prefix notation, while requiring a different reading style, is incredibly clear and unambiguous as long as no one's gone macro-crazy on you.

Sometimes there are misunderstandings of economics involved, but just as often that kind of resistance stems from factors that "basic economics" glosses over or abstracts away. There's a lot of economic friction involved in shifts like this, and the pain tends to fall on people who have less power to do anything about it -- it's not trivial for a truck driver to go get a new job in a different industry, and our economic system is not very well set-up to encourage that kind of retraining and shifting, nor to support the basic needs of people who don't have much to contribute to "the economy". (All that's vaguely related to the fact that we've been (in the US) working more and more hours collectively despite higher and higher productivity, so that Keynes's prediction of a 15-hour workweek looks crazy even though his estimation of productivity increases was basically on point...)

There's a place in Chicago that teaches longsword classes based on the reconstructed fencing school of Fiore dei Liberi, who wrote this book.

Along these lines, for me one of the things that makes Clojure stand out is the careful thought that went into state, time and identity in the design of the language. It removes mutability as a default without forcing you to be purely functional all the way down, and gives you tools to manage state changes in ways that are easier to reason about (though still not necessarily easy of course).

Emacs has plenty of power here. My preferred Clojure workflow actually involves evaluating Clojure code in a buffer rather than directly at the REPL (so you don't have to do any copy/pasting to edit the code and eval it again). It's easy to build up complex functions piecewise this way.

Your objection to the segue would make more sense if those "imaginary points" didn't have the potential to e.g. purchase one of a limited number of tickets off the planet (or any number of other life-changing/saving things). There's a sense in which money isn't "real", but capitalism certainly isn't an imaginary game for imaginary points.

Excellent reply -- a small but important (and elegant, I think) proviso is that in the king-minting-coins scenario, it's not actually necessary to require that citizens exchange goods for the coins; requiring them to pay taxes in the coins accomplishes that on its own, if the only initial source of coins is from the soldiers. Their utility in paying taxes (which, because everyone has to pay taxes, extends to general utility as a medium of exchange) explains the difference in value between the coin itself and the metal content. (I recall a lot of interesting anthropological research on this in David Graeber's book, Debt: the First 5000 Years.)

There are some surprisingly direct debt->currency relationships that persist today; for example, the Bank of England, iirc, retains the ability to print money because it loaned £2 million in silver to the crown in 1697 or something like that (no guarantees on sums and dates) -- in other words, British currency is literally commodified debt owed by the crown (which is presumably the most trustworthy party in terms of ability to pay) to the Bank of England, which the bank has the power to distribute.