-
mgartner
4 months ago
|
link
| on:
Conceptual compression means beginners don’t need to know SQL — hallelujah!
I think DHH has a lot of accurate points here, but I think he’s wrong about not needing to write SQL or have an understanding of the database technology supporting your application. With applications that store few data in their database, then I agree it may be possible to have a completely opaque perception of the database technology. However, I don’t see a way to forgo knowledge of the database layer and avoid writing SQL for things like running migrations on tables with millions of rows.
As a simple example, creating an index on a large Postgres table without the CONCURRENTLY keyword is a surefire way to block reads and writes on a table while the index is created and cause downtime. I don’t work with ActiveRecord, but it appears there is an abstraction for this keyword (algorithm: :concurrently). But how would you know to use this option if you don’t have an understanding of the database and its transactional isolation behavior?
As another example, adding a NOT NULL constraint on a large table will also block reads and writes in Postgres, while it validates that all current rows conform to the constraint. You’re better off creating an INVALID check constraint to ensure a column is non-null, and then VALIDATE’ing that constraint later to avoid downtime. These are the type of things where knowledge of just an abstraction layer and not of the underlying database will cause problems.
To be fair, DHH does only mention that Basecamp 3 has no raw SQL in “application logic”, and he never mentions migrations in the post, so maybe he is ignoring migration-type SQL commands in this context.
-
As another example, adding a NOT NULL constraint on a large table will also block reads and writes in Postgres, while it validates that all current rows conform to the constraint. You’re better off creating an INVALID check constraint to ensure a column is non-null, and then VALIDATE’ing that constraint later to avoid downtime.
And this (among other things) is why I just can’t believe the claim that they could move from MySQL to Postgres and “not give a damn”.
-
-
-
I would love to know the validity of this claim. It seems fishy that a patent was filed but no white paper was submitted to journal for peer review (that I can find). If anyone with more expertise can provide their take on the matter, I would greatly enjoy it!
-
The inventor has a website called boundedfloatingpoint.com. There he describes it in a bit more detail than the article, but not much.
Note carefully how he describes it:
This invention provides a device that performs floating point operations while calculating and retaining a bound on floating point error.
And “[t]his invention provides error notification by comparing the lost bits”.
It’s a solution to the problem of “unreported errors”. His solution provides extra fields in the floating point representation to carry information about ’lost bits” and allows the operator to specify how many significant digits must be retained before an error is flagged.
This is an advantage over the current technology that does not permit any control on the allowable error. This invention, not only permits the detection of loss of significant bits, but also allows the number of required retained significant digits to be specified.
At a cursory glance one might be inclined to think he’s solved the problem of floating point, but the reality is he’s developed a standard for communicating error in floating-point operations that can be implemented in hardware.
Not to detract from his solution, but it doesn’t seem like he’s invented anything that will surprise hardware designers.
-
Thank you for that analysis. This is a real problem with floating point numbers, but hardly the only one.
People who haven’t seen it might be interested in this post from last year about a new number representation called “posits”, which addresses some completely orthogonal issues with fixed-size number representations. :)
-
-
It’s a solution to the problem of “unreported errors”. His solution provides extra fields in the floating point representation to carry information about ’lost bits” and allows the operator to specify how many significant digits must be retained before an error is flagged.
SIGNAL ON LOSTDIGITS; NUMERIC DIGITS 10; NUMERIC FUZZ 2;We just need to do all our math in REXX.
-
-
It seems to me like the problems with null all stem from the fact that it is implemented as a bottom type, not the fact that it exists at all. Are there languages that implement null as a separate type, and not a subtype of all types? Is there a good reason why most languages don’t do this?
At this point you’ve got option, because it’s no longer legal for a variable with type T to contain a null. Instead, to contain a null that variable must be of a union type T|Null, a.k.a. option a.k.a. maybe. There are lots of languages that do this (Kotlin, Swift, Haskell, Scala, Rust).
Ruby, but that’s probably not what you mean.
TypeScript does this with the strict null checks flag on.
Yes, in .NET F# is a good example of this if you’re not interoping with C#. In C# we’re finally reaching a point where nullable reference types will no longer be the default and must be explicitly declared and will have proper compile time checking. It will be a warning by default for new projects, and you can also choose to make it a compile time error if you want.