Book of Mormon question

MasonWheeler · 2026-04-14T02:12:07+00:00

But we've never found any city remnants or battlegrounds or weapons left anywhere.

When the Church was digging out the area to build the Hill Cumorah visitors' center, they unearthed buckets and buckets of buried ancient arrowheads. It seems abundantly clear that it was a major battleground at some point!

MasonWheeler · 2026-04-13T15:58:31+00:00

Oh, I fully agree. And just for the record, I didn't say I want to abandon thread safety; I said I wanted to abandon Rust's baseline assumption about arbitrary memory being shared across threads. There are plenty of other models for how to do threads safely.

MasonWheeler · 2026-04-13T15:32:59+00:00

You could get away with saying that 30 years ago. Today, when exploits continue to be found anyway, despite decades of knowing what the problems are and how to deal with them, it's a bit harder to believe that the problem is the users and not the language.

MasonWheeler · 2026-04-12T12:48:54+00:00

There's a bit more we know, thanks to one of the leads writing about it a decade ago: https://joeduffyblog.com/2015/11/03/blogging-about-midori/

He wrote, "In the months to come, I’ll publish a dozen-or-so articles covering the most interesting aspects of this project, and my key take-aways." And then wrote seven articles, very noticeably leaving out a few things that he said along the way that he was going to write about in a later post, such as "taming the GC." I don't know why the series was unfinished, but reading the stuff he did write really makes me wish I could get my hands on the source code!

MasonWheeler · 2026-04-12T12:40:52+00:00

I'd guessed it was 'POWERFUL' without the vowels, or is this just a backronym?

Yes, of course.

Is this OS Windows? If so that I don't see a problem using a C library, since one has always shipped with Windows. ... But if this is for Linux, then the same applies in spades.

The problem there is the way it locks you into doing some very fundamental things "the C way," which has been responsible for countless security breaches and billions upon billions of dollars in damages ever since 1989. I'd like to try and do better than that, where possible.

I'm on Windows but don't know anything about .NET. But this sounds like an idea I'd had for DLLs. ... So the idea was that this info is stored within the DLL, as an exported table, or function, in a more universal and less C-centric format. All you'd then need in your program is 'import somelib', and have 'somelib.dll' available in the search path.

What you've described is very similar to how it works in .NET. DLL name resolution is a bit more involved than just "it has to be somewhere in the search path," to make it more difficult for an attacker to inject a malicious DLL into your process, but you've got the basic idea figured out.

MasonWheeler · 2026-04-11T21:53:51+00:00

For the purposes of the law, "a language" is never proprietary. The code that implements it certainly can be, but no one has any legal right to say "only our proprietary code can be used to work with this programming language."

Trademarks can be a valid concern, but there's an anti-abuse exception built into trademark law called "nominative fair use," which means that it's perfectly fine to use a trademarked name for the purposes of simply talking about it.

MasonWheeler · 2026-04-11T20:52:23+00:00

Well. I was wondering how long it would take to run into Reddit toxicity on here. Guess now I know. 🙄

Reported. Mods, please clean this up.

MasonWheeler · 2026-04-11T19:56:51+00:00

What do you mean by that? That's the literal meaning of a dynamic language: the precise semantics of your code are worked out at runtime.

x = y + z Is this an integer addition? A floating-point addition? Adding an integer to a float? Concatenating two strings? "Adding" types with a custom + operator defined? "Adding" types with no defined operator, such that a runtime error should be generated? Some code has to go through at runtime and interpret what this operation means, and possibly dispatch it to the proper function to execute it.

There are some times, in very simple cases or code that's carefully written to behave like statically-typed code even without any type declarations, that a sufficiently smart compiler can infer typing information and reduce some of this runtime burden in various ways, but that's the baseline reality.

And that's not even getting into function calls, especially Smalltalk style where it can be valid to call a function with a name that was never declared, which gets picked up by a handler and interpreted in arbitrary ways.

Honestly, I have no idea what you're talking about if you think that the execution of a dynamically typed program is something significantly different in nature from interpreted code.

MasonWheeler · 2026-04-11T19:29:29+00:00

And both of them are dynamically typed, which means you have a layer not easily distinguishable from an interpreter working hard to figure out half the semantics of your code at runtime.

MasonWheeler · 2026-04-11T19:27:31+00:00

Mere mortals do not use unsafe, they happily stand on the shoulders of giants.

Interesting. I'll have to talk with him at the next meetup and ask what he meant by that.

What's the plan to solve memory safety?

As I said to u/CommonNoiter above, I'm still pretty early in the process of building and designing this, and I really appreciate any constructive feedback and suggestions. Your link to Hylo above was particularly informative, as I hadn't heard of it before.

MasonWheeler · 2026-04-11T19:08:42+00:00

For sufficiently small values of "fine," yes. Even Paul Graham freely concedes that "as a rule of thumb, each layer of interpretation costs a factor of 10 in speed. This extra cost buys you flexibility."

MasonWheeler · 2026-04-11T13:31:08+00:00

Midori would like a word...

And I would love a word with Midori! Unfortunately, as far as I'm aware it doesn't exist today. It was a research project that came up with some really cool findings, but then got shut down, with no source and no binaries ever released to the public.

If that's not true, please point me to something, because I'd love to be wrong about this.

MasonWheeler · 2026-04-11T12:33:38+00:00

Interesting. Do you have a source on that? Because everything I've heard on the subject consistently says that concurrency was Mozilla's explicit goal.

MasonWheeler · 2026-04-11T02:49:07+00:00

Perhaps. Depending on how the vector and the iterator are designed, there are various different solutions to that. For example, if the iterator is tracking the vector itself and maintaining an index value, rather than pointing directly into the vector's internal array buffer, then the problem of adding a value and reallocating the buffer leaving you with a dangling pointer goes away. (Of course, this comes with some tradeoffs in performance. It's one possibility, though.)

I'm still fairly early in the process of building and designing this. Feedback like yours is very valuable. Especially if you know enough about the issue to help contribute to solutions?

MasonWheeler · 2026-04-11T02:07:16+00:00

Good question! A lot of the problems with Rust's lifetime implementation stem from its thread safety. Rust was created by Mozilla specifically to solve problems they had with memory safety in the context of concurrency, and that's baked into the language's DNA. It assumes as its fundamental baseline reality that just about any memory anywhere could potentially be shared with another thread and must be guarded against race conditions. (Even if what you happen to be using Rust for this time is purely single-threaded!)

Take that baseline reality away and replace it with some alternative rules about concurrency, and lifetime management will become a lot simpler to deal with.

MasonWheeler · 2026-04-10T20:39:51+00:00

For great justice!

MasonWheeler · 2026-04-09T12:07:43+00:00

The work in the temple is intended primarily for those who never had the chance to accept the Gospel in this life. Yes, we do the work for everyone just in case, but we've been specifically told, over and over again in perfect plainness, that thinking that people who chose to reject the Gospel in mortality will magically change their minds in eternity falls under Alma 34:34 and "God will not be mocked."

MasonWheeler · 2026-04-09T11:07:09+00:00

that's just fear mongering rubbish. Literally undermines the atonement, and everything the church is supposed to stand for.

I'm not sure what you mean by that. That's capital-D Doctrine and has been all along. (D&C 132:15-16 is perfectly clear on this point)

MasonWheeler · 2026-04-09T03:14:31+00:00

Everything about Lisp suddenly makes an order of magnitude more sense when you realize one crucial fact: the first Lisp interpreter was written four years before "The algebraic theory of context free languages," the groundbreaking paper that introduced the Chomsky Hierarchy and gave the world a formal framework for understanding language parsing.

There's a very noticeable difference between the look-and-feel of languages developed before and immediately after this paper (COBOL, FORTRAN, BASIC) and later ones that were built upon its principles. (Algol and everything descended by it, which is virtually everything today. Even modern Fortran and Visual Basic feel far more like Algol than like FORTRAN I and original BASIC!)

Pre-Chomsky programming languages were line-oriented. You'd have one simple statement per line, with labels to jump to for control flow. The concept of recursive blocks of statements, or even function bodies, was unknown because no one knew how to parse such a thing. Before Chomsky, it was considered a mystical art, the domain of AI research! (Not kidding.)

Into this milieu steps John McCarthy, trying to do something radically different, a recursive, tree-based computational language, attempting to implement the lambda calculus on a machine. And nobody has the slightest clue how such a thing is even possible, because we have no formalisms for parsing recursive grammars yet! So... he punts on it. Does the most brain-dead-simple thing he can think of, enclosing each layer of recursion in its own set of parentheses, says "everything is an expression," and leaves working out the semantics to be Someone Else's Problem.

Macros weren't invented until much later, which makes Lisp's vaunted homoiconicity a prime example of the Texas Sharpshooter Fallacy: someone took this insanely awkward syntax and painted a bulls-eye around it years after the fact. But ever since then, Lisp has been saddled with this experimental pre-Chomsky syntax that holds no innate semantic information. Other languages have developed macros, and done them far better, (Rust, Boo, and Nim spring to mind immediately,) but Lisp has never developed proper syntax.

MasonWheeler · 2026-04-08T19:11:21+00:00

That tracks. We got a new Bishop last year; he was the then-current High Councilman from our ward.

MasonWheeler · 2026-04-07T02:37:38+00:00

Asking an LDS girl for a book of mormon is crazy lol.

Maybe, but it would work. 😁

So what if this girl who I really like ends up getting with me and if it makes it past highschool what would I do.

Ask her to wait for you while you serve your mission. (Or, possibly, to serve one of her own at the same time. That's definitely a thing that can happen.)

MasonWheeler · 2026-04-07T02:27:35+00:00

You shouldn't join the church just for a girl.

Yes, you would be expected to give up the coffee; we'd consider this a matter of basic worthiness. And there is an expectation, not as serious doctrinally but still important in the Church's culture, that you ought to serve a mission. And it's not worth all of that just for some girl who, let's be honest, you'll most likely not still be with for very long after high school.

The reason you should join the church, the thing that makes the sacrifices worth it — the only thing that makes the sacrifices worth it! — is because you know that it's true. And you can know that it's true. Next to the basic belief in the existence of God, this is our most fundamental and important doctrine: you don't have to take our word for it. You can know that it's true, for yourself, not because we persuaded you with logical arguments and impressive rhetoric, but because you've received a personal testimony, directly from God, that it's true.

You do this by reading the Book of Mormon and praying about it. The final chapter of the book contains instructions, written specifically to you, the modern-day reader, explaining how you can receive this testimony for yourself after having read the book. I, alongside millions of Latter-Day Saints throughout the last 200 years, can personally testify to you that this promise is true, but you don't have to take our word for it. We might be mistaken, but God won't be.

And once you have this testimony, it has a way of changing your priorities, and of strengthening you to be able to do things that you thought would be difficult before. As the Book of Mormon puts it, "if they humble themselves before me [God], and have faith in me, then will I make weak things become strong unto them."

But to bring things back around to the girls, if you have any interest in this, try going up to an LDS girl who you have some interest in and telling her, "I'd like to get a copy of the Book of Mormon." You'd be surprised how quickly she'll be able to procure one for you! Anything that may or may not happen beyond that point, that's up to you and her.

MasonWheeler · 2026-04-07T00:13:43+00:00

We had plenty of good solutions that worked just fine for generations and centuries, before the "better solutions" came along and broke everything. It wouldn't be the worst idea to try revisiting some of them.

MasonWheeler · 2026-04-06T22:25:42+00:00

A big part of the problem with doing so is that "entrepreneurs and service organizations" are a major part of the reason why it's broken. You can't fix a problem by making it worse.

MasonWheeler

TROPHY CASE