modeler

It is the defecal standard though.

All junior devs should read OCs comment and really think about this.

The issue is whether is_number() is performing a semantic language matter or checking whether the text input can be converted by the program to a number type.

The former case - the semantic language test - is useful for chat based interactions, analysis of text (and ancient text - I love the cuneiform btw) and similar. In this mode, some applications don't even have to be able to convert the text into eg binary (a 'gazillion' of something is quantifying it, but vaguely)

The latter case (validating input) is useful where the input is controlled and users are supposed to enter numbers using a limited part of a standard keyboard. Clay tablets and triangular sticks are strictly excluded from this interface.

Another example might be is_address(). Which of these are addresses? '10 Downing Street, London', '193.168.1.1', 'Gettysberg', 'Sir/Madam'.

To me this highlights that code is a lot less reusable between different projects/apps than it at first appears.

Typically you need about 1GB graphics RAM for each billion parameters (i.e. one byte per parameter). This is a 405B parameter model. Ouch.

Edit: you can try quantizing it. This reduces the amount of memory required per parameter to 4 bits, 2 bits or even 1 bit. As you reduce the size, the performance of the model can suffer. So in the extreme case you might be able to run this in under 64GB of graphics RAM.

I think that's a better plan than physically printing keys. I'd also want to save the keys in another format somewhere - perhaps using a small script to export them into a safe store in the cloud or a box I control somewhere

You need at least two copies in two different places - places that will not burn down/explode/flood/collapse/be locked down by the police at the same time.

An enterprise is going to be commissioning new computers or reformatting existing ones at least once per day. This means the bitlocker key list would need printouts at least every day in two places.

Given the above, it's easy to see that this process will fail from time to time, in ways like accicentally leaking a document with all these keys.

I agree, so much legislation is broken, the legislators aren't doing shit, so we citizens need to fix it!

But we could start with the right to repair.

What about the people who lived in the Americas or the Pacific 1800 years ago? These people could not have heard of Jesus as missionaries could not have spread any word to them at this time.

(And while I'm about it, Christianity was a whole different thing back then - the Trinity hadn't been invented, there were multiple sects with very different ideas, what books would be in the New Testament had not been decided, etc etc. People with beliefs of that time would seem highly unorthodox today, and the Christianity of today would be seen as heretical by those in the 3rd century, so who's going to heaven again?)

Purgatory was invented for the purpose of not sending good people who had not heard of Jesus to hell. But still, these people were denied their chance to get to heaven which seems mighty unfair.

If you're pushing everyone's buttons it'll end badly.

I don't think that the anti-oop collective is attacking polymorphism or overloading - both are important in functional programming. And let's add encapsulation and implementation hiding to this list.

The argument is that OOP makes the wrong abstractions. Inheritance (as OOP models it) is quite rare on business entities. The other major example cited is that an algorithm written in the OOP style ends up distributing its code across the different classes, and therefore

1. It is difficult to understand: the developer has to open two, three or more different classes to view the whole algorithm
2. It is inefficient: because the algorithm is distributed over many classes and instances, as the algorithm runs, there are a lot of unnecessary calls (eg one method on one instance has to iterate over many instances of its children, and each child has to iterate over its children) and data has to pass through these function calls.

Instead of this, the functional programmer says, you should write the algorithm as a function (or several functions) in one place, so it's the function that walks the object structure. The navigation is done using tools like apply or map rather than a loop in a method on the parent instance.

A key insight in this approach is that the way an algorithm walks the data structure is the responsibility of the algorithm rather than a responsibility that is shared across many classes and subclasses.

In general, I think this is a valid point - when you are writing algorithms over the whole dataset. OOP does have some counterpoints encapsulating behaviour on just that object for example validating the object's private members, or data processing for that object and its immediate children or peers.

There is non-zero risk in every surgery, and this is a major surgery. There is non-zero risk of very very severe consequences: brain infection, stroke being just some. While these risks are low, they are non-zero. The volunteers have the possibility of losing everything.

Java programmers are also functionally illiterate

Elon Musk didn't build the company.

Elon Musk invested into the company,

That's what I said a couple of paragraphs later