The canonical western text is Richard Wilhelm's german interpretation, translated to english by Cary Baynes. This site has the hexagram descriptions from that translation: https://www.iching.online/wilhelm.php
I recommend buying the book though. It is fascinating whether or not you buy into it.
In the medium to long term, if LLMs are unable to easily learn new languages and remap the knowledge they gained from training on different languages, then they will have failed in their mission of becoming a general intelligence.
> It clearly wasn’t ’that bad’ for most human history given how prevalent it was. But in the modern world we are trauma merchants.
What in the actual fuck kind of logic brought you here to that conclusion? I worry for you and whatever content you’ve consumed over the years that allowed you to build up this theory.
Well I did a Psych minor for lols back in the day and there's no doubt that almost all of current social psychology is made up of trauma merchants peddling their wares. 'Step 1: gaslight you into thinking you're fucked up Step 2: Convince you I'm the one who can help you' kind of shit. Psychologists obviously get upset by the suggestion.
But in terms of rape, as I said in my original comment it's just a suspicion. Happy to hear your counterarguments if you have any.
Was rape that common? Like in hunter gatherer times (most of human history) most mating would have been within the band. I don’t think intra-band mating would have been rapey, mostly. Incestuous by modern standards, for sure, but I don’t see why it would have been rapey. Inter-tribe conquest mating definitely happened, but was it really that common compared to the normal mode? It takes way more effort, at least.
My similarly controversial take is that modern rape is traumatic because rapists are no longer hung in public. I think public hangings might have had an under appreciated healing effect on the psyche. Like if a guy who attacked you is still out there, he might attack you again. But if you saw him hang, you just might feel better.
It's been extremely prevalent. In terms of prehistory, we have lots of evidence that young women were almost always spared if one group massacred another, and we have genetic evidence that invariably the winning male bloodline would become predominant in any conquered group.
If you look at the Columbia link and do other research it's pretty obvious that 'punishing' rapists has never really been about punishing them or giving women some kind of absolution. In the code of Hammurabi and with the Jews women who didn't scream so that others could hear were prosecuted for adultery or stoned lol. The idea of giving women the satisfaction of watching anything for their own benefit is a very modern notion and even now doesn't really exist anyway. That's just your personal fantasy. You can go back to the Assyrians to see that if, for example, you raped my virgin daughter then I could legally rape your wife. It's mostly been a property or bloodline issue. It's never been about the females and that's another reason I think it's massively overblown in modern times. It's been normal human behaviour for millions of years. To put it another way, if you were a young 19 year old female in a village that was being ransacked, say, 4000 years ago, you'd know what was going to happen to you if your males lost. I don't think it would have been that traumatising - the males in your village would have done it to the females in their village were the roles reversed. The 'trauma' is largely a modern phenomenon where everything has to be upsetting/triggering/trauma-inducing. Everybody has to be a victim these days.
As impressive as this analysis is by the compiler, I shudder to think how much time the compiler spends doing these kinds of optimizations. In my opinion, a better architecture would be for the compiler to provide a separate analysis tool that suggests source level changes for these kinds of optimizations. It could alert you that the loop could be replaced with a popcount (and optionally make the textual replacement in the source code for you). Then you pay the cost of the optimization once and have the benefit of clarity about what your code _actually_ runs at runtime instead of the compiler transparently pulling the rug out from underneath you when run with optimizations.
Side note: many years ago I wrote the backend for a private global surveillance system that has almost surely tracked the physical location of anyone reading this. We could efficiently track how often a device had been seen at a location in the prior 64 (days|weeks|months) in just 192 bytes and use popcount to compute the value. I am not proud that I built this.
I liked the first few paragraphs, but the article took a wrong turn for me when it pivoted to ir. Compiler ir need not be fiendishly complex, though modern compilers, particularly clang and gcc can create this impression.
There are two nice benchmarks that I use to measure the complexity of a compiler: how long is the compiler and how long does it take to self compile. Clang and gcc are abysmal on these benchmarks. In fact, I would argue that they fail the second benchmark entirely because they are not capable of self compilation because their build systems rely on external tooling. In other words, there is no implementation of gcc or clang that does not rely on an additional tool that is external to the compiler itself.
The main pedagogical value of these compilers is not as an exemplar, but rather an antithesis.
If the boosters are correct about the trajectory of llm performance, these objections do not hold.
Debugging machine code is only bad because of poor tooling. Surely if vibe coding to machine code works we should be able to vibe code better debuggers. Portability is a non issue because the llm would have full semantic knowledge of the problem and would generate optimal, or at least nearly optimal, machine code for any known machine. This would be better, faster and cheaper than having the llm target an intermediate language, like c or rust. Moreover, they would have the ability to self-debug and fix their own bugs with minimal to no human intervention.
I don't think there is widespread understanding of how bloated and inefficient most real world compilers (and build systems) are, burning huge amounts of unnecessary energy to translate high level code, written by humans who have their own energy requirements, to machine code. It seems highly plausible to me that better llms could generate better machine code for less total energy expenditure (and in theory cost) than the human + compiler pair.
Of course I do not believe that any of the existing models are capable of doing this today, but I do not have enough expertise to make any claims for or against the possibility that the models can reach this level.
It's sad but I generally agree. Scala was in my view pretty well positioned for an up and coming language ~2010-15. Not only did the scala 3 rewrite fail to address many of the most common pain points -- compile times and tooling immediately come to mind -- the rewrite took many years and completely stalled the momentum of the project. I have to wonder at this point who is actually starting a new project in scala in 2025.
It's really a shame because in many ways I do think it is a better language than anything else that is widely used in industry but it seems the world has moved on.
> It's really a shame because in many ways I do think it is a better language than anything else that is widely used in industry but it seems the world has moved on.
I'm really hoping that https://flix.dev/ will learn from the mistakes of Scala. I t looks like a pretty nice spiritual successor to Scala.
> It's really a shame because in many ways I do think it is a better language than anything else that is widely used in industry but it seems the world has moved on.
No it didn't. Scala is powering some of the biggest companies on this planet.
>It's sad but I generally agree. Scala was in my view pretty well positioned for an up and coming language ~2010-15
I used Scala for a bit around that period. My main recollection of it is getting Java compiler errors because Scala constructs were being implemented with deeply nested inner classes and the generated symbol names were too long.
> My main recollection of it is getting Java compiler errors because Scala constructs were being implemented with deeply nested inner classes and the generated symbol names were too long.
Sounds like you've used some beta version over 15 years ago.
Nothing like described happens in current Scala and it's like that as long as I can think back. Never even heard of such bugs like stated.
Coming up with such possibly made up stuff over 15 years later sounds like typical FUD, to be honest.
I'll answer with a question for you: what legitimate concerns might some people have about a private company working closely with the government, including law enforcement, having access to private IRS data? For me, the answer to your question is embedded in mine.
This design seems very similar to async in scala except that in scala the execution context is an implicit parameter rather than an explicit parameter. I did not find this api to be significantly better for many use cases than writing threads and communicating over a concurrent queue. There were significant downsides as well because the program behavior was highly dependent on the execution context. It led to spooky action at a distance problems where unrelated tasks could interfere with each and management of the execution context was a pain. My sense though is that the zig team has little experience with scala and thus do not realize the extent to which this is not a novel approach, nor is it a panacea.
> I did not find this api to be significantly better for many use cases than writing threads and communicating over a concurrent queue.
The problem with using OS threads, you run into scaling problems due to Little's law. On the JVM we can use virtual threads, which don't run into that limitation, but the JVM can implement user-mode threads more efficiently than low-level languages can for several reasons (the JIT can see through all virtual calls, the JVM has helpful restrictions on pointers into the stack, and good GCs make memory management very cheap in exchange for a higher RAM footprint). So if you want scalability, low-level languages need other solutions.
> If the value of human labor is going to zero, which some say ai will induce
These "some" are founders of AI companies and investors who put a lot of money into such companies. Of course, the statements that these people "excrete" serve an agenda ...
I recommend buying the book though. It is fascinating whether or not you buy into it.
reply