smithkl42

I don't know that I would draw that sharp of a distinction between archaeological and Biblical evidence. Pretty much every strata of the Bible that we have, from pretty much every age, assumes that even Yahweh's worshipers are aware of and frequently worshiping other gods. Rachel has her period on a pile of household idols (Gen. 31:26-35). Jacob gives up all his household's idols at God's request (Gen. 35:1-4). The Israelites in the desert worship first a golden calf (Ex. 32) and then the Baal of Peor (Numbers 25). David's wife Michal has an idol just sitting around, available to be used in a subterfuge (1 Sam. 19:11-17). And that's before we get to the prophets, whose message everywhere assumes that other gods are present in Israelite civil religion.

The question isn’t whether ancient Israelites worshiped other gods. Every single source we have, including the Bible, says that they did. The real question is how early and how consistently such behavior was objected to, and on what grounds. And there, the evidence shows that even the earliest traditions seem to expect loyalty to YHWH alone, even if they don’t always explain why. Over time, those objections become sharper, more theological, and more absolute. But there is no point in the biblical tradition, early or late, where YHWH is not a jealous God; just as there is no point where he doesn’t have cause to be.

The Wikipedia article is a good place to start:

https://en.wikipedia.org/wiki/Baal

Like all matters concerning the gods in the ancient near east, it's complex, and every answer has to be qualified. So apparently in some traditions, Baal was the son of Dagan (another fertility god), and in some the son of El (the head of the Canaanite pantheon, often identified with Yahweh even by orthodox Yahwists).

"Baal" was less a name than a title. In modern Hebrew, it just means "lord" or "husband". It was also apparently a title that could, at some stages of Israel's history, even be applied to YHWH, much like "Adonay" ("My lord"). For instance, the individuals named "Mephibosheth" and "Ish-bosheth" (two of the sons of Saul, a clear if imperfect Yahwist) were originally named "Meribaal" and "Ish-baal". Whoever put together 1 and 2 Samuel changed their names from "May Baal Contend" and "Man of Baal" to various plays on "shame" (bosheth). Their original names are preserved, oddly enough, in 1 Chronicles.

If you could go back and ask, say, Samuel or David or Saul about how many gods existed and what their names were, I suspect all of them would have been clear that YHWH was the chief of the gods, and the only one that Israelites should worship, but beyond that you would have gotten some complicated and perhaps confused answers. Even some parts of the Bible take for granted that other gods besides YHWH exist - see, for instance, Psalm 82.

https://www.biblegateway.com/passage/?search=Psalm%2082&vers...

Over time, "Baal" began to denote a specific agricultural deity, and it became less appropriate to use as a title for YHWH. That seems to have kicked off (or was kicked off by) the well-known conflict between Yahwism and Baal worship - see, ad infra, 1 Kings 18.

https://www.biblegateway.com/passage/?search=1%20kings%2018&...

"missing for a millennium" - according to both the article and the journal piece, the most recent of these fragments is nearly two millennia old.

https://www.cambridge.org/core/journals/iraq/article/literar...

We're paying for Copilot for Office365. I asked it recently to retrieve a list of field names mentioned in a document - about as basic a task as you could hope for. It told me it couldn't do so.

My precise request: "Extract the list of field names in Exhibit A."

Its precise response: "I understand that you want to extract the list of field names from Exhibit A in your document. Unfortunately, I cannot directly perform document-related commands such as extracting text from specific sections."

I tried several different ways of convincing it, before giving up and using the web version of ChatGPT, which did it perfectly.

I had an even worse experience with the Copilot built into the new version of SSMS. It just won't look at the query window at all. You have to copy and paste the text of your query into the chat window ... which, like, what's the point then?

I used VSS for a few years back in the late 90's and early 2000's. It was better than nothing - barely - but it was very slow, very network intensive (think MS Access rather than SQL), it had very poor merge primitives (when you checked out a file, nobody else could change it), and yes, it was exceedingly prone to corruption. A couple times we just had to throw away history and start over.

I don't know how well this holds out, but one thing I've noticed is that the very best developers I've worked with are all fast on the keyboard - not just fast at typing code or comments or emails or whatever, but they have all the keyboard shortcuts memorized, and they navigate through their IDE of choice faster than you can follow (even if you're a pretty good dev yourself).

This doesn't actually sound encouraging. Judgment is not actually independent of skill, and the sort of music that this approach produces (i.e., nearly everything you hear on the radio these days) is a pretty solid proof of that.

Maybe kinda analogous to the difference between declarative and imperative languages. They (supposedly) don't do step-by-step reasoning to get at the truth, they just "see" it. Like the old story about Bhaskara's proof of the Pythagorean Theorem being, just, "Behold."

Heading out on Friday to do a black bear hunt in two of those Grizzly recovery zones...

Did you sleep all night, and work all day?

And in the process, they ended up creating an extremely powerful type system that ~nobody outside of that original team can (fully) understand.

I made the observation back in the 90's that Word will always take several seconds to load. Any longer and it becomes too painful, so Microsoft will figure out a way to fix it. Any shorter and it just means that there are more bloated features that Microsoft can stuff into it.

Absolutely LLMs can reason. There are limitations on their ability to reason, as you and everyone else has discovered. But they can absolutely reason about both concepts and the physical world in ways that, say, animals can't - even though presumably animals have at least some sort of self-consciousness and LLM's do not.

The Chinese Room argument is a great thought experiment for understanding why the computational model is an inadequate explanation of consciousness and qualia. But it proves nothing about reason, which LLMs have clearly shown needs to be distinguished from consciousness. And theories fall into the category of reason, not of consciousness. Or another way of putting it that you might find more acceptable: maybe a computer will never, internally, know that it has developed a theory - but it sure seems like it will be able to act and talk as if it had, much like a philosophical zombie.

We've been asked that question before on security questionnaires, and our answer has always been, "Forcing users to change passwords regularly is widely regarded as a very bad security practice, and we don't engage in bad security practices." We've never had anyone complain.

In C#-land, we just have it as a standard that ~every table inherits from `ITrackable`, and we wrote a little EF plugin to automatically update the appropriate columns.

public interface ITrackable { DateTime CreatedOn {get; set;} DateTime ModifiedOn {get; set;} }

Saves so much time and hassle.

Completely agreed. All the nonsense about getting just exactly the right soil composition, letting the soil "age", and what-not, seems bizarre and silly. If an animal needs to use the bridge, it'll learn to use the bridge. Spending so much extra money and time to get the vegetation just right is a waste of taxpayer dollars.

FWIW, that doesn't appear to be a "hasty rebrand" - Oracle has had this distinction for a long time.

https://docs.oracle.com/en/cloud/saas/enterprise-performance...

I'm the CTO of a US-based insurance company. Apart from some reinsurers in London and Bermuda, and a couple contractors in Canada, we don't do business outside the US. We've blocked all countries except those, and it has cut down massively on the folks attacking us.

I don't know the details, but it sounds like there's a legitimate discussion to be had there. But the author's tone makes it difficult to trust that her reporting is in good faith. If there were extenuating circumstances, I wouldn't trust her to have included them.

I think it really is a problem if they're getting artifacts without clear provenance. They've had to return some manuscripts, and I thought that they'd cleaned up their acquisition process. But perhaps not?

https://www.christianitytoday.com/2020/04/bible-museum-steve...

https://www.artsy.net/article/artsy-editorial-museum-bible-w...

https://www.smithsonianmag.com/smart-news/museum-of-the-bibl...

I wish the author was a little less over-wrought in her descriptions of the Green family's religious commitments. I've heard complaints before about the Green's artifact acquisition process, and they've had to return some manuscripts: it's a story worth investigating and telling. But it distracts from the author's main point when she's making snide comments about their faith. Yes, they're Christians who are successful at business and who take their faith seriously - so? If the author is trying to convince people she's an even-handed reporter, she'd do better to drop the sarcastic tone.

I run the tech org for an insurance company. We've got a team of about 30 folks working on a system that manages hundreds of thousands of policies. Apart from the API's we call (a couple of them internal, belonging to our Analytics team), it's one big monolith, and I don't see that changing anytime soon. At our scale, a monolith is more stable and performant, easier to understand, easier to deploy, easier to test, easier to modify, and easier to fix when something goes wrong.

I only ever played with DCOM and Transaction Server, and never in production, but I do wonder what about that tech stack made it so absolutely unworkable, and such a technological dead-end? Did anyone ever manage to make it work?

Or more simply: "Science progresses one funeral at a time."

"I first tried to write a story when I was about seven. It was about a dragon. I remember nothing about it except a philological fact. My mother said nothing about the dragon, but pointed out that one could not say “A green great dragon,” but had to say “a great green dragon.” I wondered why, and still do." - J. R. R. Tolkien

Swyfft Insurance | C# Developers | Full Time | 100% Remote (US only, sorry!)

https://www.swyfft.com/careers

Salary: $100K-180K

Swyfft is an Insurtech, primarily focused on Homeowners. We're not as well known as Lemonade and Hippo (we'd rather keep our equity than give it away, if it's all the same), but from an actual business perspective, we're arguably doing better. We've already got a number of smart, friendly and hard-working developers on our team, and need more.

Our backend is C#/.NET Core/SQL, our front-end is TypeScript/React. The positions we've got are mostly focused on the backend, but some good full-stack or front-end skills would be great. Insurance experience would be great too, but, well, I didn't have any when I started either.

If you check out our jobs (https://swyfft.bamboohr.com/jobs/), ignore the "city" in the job description - that's a limitation of the HR platform we're on. We've been fully remote since long before Covid, and you can work from anywhere in the US.

As it turns out, Daniel Bennett is an atheist materialist crank who has developed evasive "materialist arguments" which apparently tell us that the universe has no cause of existence, which turns out (shock, horror!) to be the standard atheist cant that he already believes, and so his arguments tell us nothing else...

(Sorry, couldn't help myself.)

Heck, still is. C# is a nice, pragmatic, practical language, and the VS/Resharper combination can't be beat anywhere, period. I love how lazy it lets me be.