mamcx

No, Python has not the level of "correct" that rust has.

`sum(a:int, b:int)`

not guaranteed ANYTHING.

The gulf between how much correct Rust is and the vas majority of languages is HUGE.

That... is all on the language. In fact the main trouble now that you spelled out is the major blow against nix: is terrible at modularity!

Is mainly the language. Is not just weird like APL , that insanely make sense. is weird.

The more interesting part is that people "release" this "products" and market it even if were like version 1.

I think he means "software companies".

Large companies exist, but pure software companies or with heavy side of it?

mmm.. I remember was a issue to let `SET STEP ON` on the codebase and I assume it opens the debugger...

> Here’s my problem with reviving FoxPro in any form

And then it moves to the orthogonal problem:

> SQL DB

(that in fact means: An app made for end users that are not trusted by default but really are somehow that is a improper implementation of the relational model and more improper developer platform, more like wordpress, and because is mostly deployed "networked" suddenly need to worry about remote access, that is totally not the main point of old Fox/dbase apps!)

And the funny things: SQL injection is not a problem with a Fox app (use of a stringy api is a MAJOR issue that lack of a permission model)

---

As one that have long experience with FoxPro and try to revive the style, lets go to the core of the problem:

Imagine you say to a C developer:

"You can't use `fopen` and other filesystem APIs, because well you have access to to the whole filesystem"

Or even better, the user!:

"You should not own your own filesystem!"

The DB is like the filesystem, but not that dumb!

The permissions model is orthogonal. Maybe you (normal) filesystem is running on a networked deployment with access by spies with and other personal that should have top-notch security.

Or is just a embedded device.

WHAT DECIDE THE SECURITY MODEl?

The kind of storage?

Nope!

Is the deployment and use case.

Similarly, what decide the security of a database?, the fact is a "database"?

No!, that is ridiculous. If you need to layer some kind of access control or whatever, is outside of the kind of storage you choses.

In fact, see how Wonderfully could be all if the "filesystem" where an actual database and you can run relational queries on top: Millions of "cli utilities" suddenly are unnecessary, the user (and developers!) have more freedom and control, and your big corp with byzantine rules will be even more happy.

----

P.D: I'm very well aware of the limitations of Fox, is ancient software! but the style of programming? Is like have a taste of start trek

P.D.2: And note that the vector attack described here is a fault of the dumb filesystem, actually!

Remember when in movies getting access to this was THE THREAT?

Fun times.

The main kick is that there is not a way to "rewrite" a foxpro app without tons of stuff along the way!

(Example: You can ship an app that internally run `CREATE REPORT` and the report builder show up. You can invoke the debugger (that as I remember is the best I used a zero alternatives as good existed)) and so on

> Databases are a great piece of technology! Learning how to use them properly can have huge payoff in terms of business value generation.

Certainly.

Is a bit sad that the most well known are applications made for users (most RDBMS) instead of for developers, combined with a glorified DSL (SQL) that has never been made for make code at "large", not even at the scale of Lua or similar.

I worked with FoxPro and do all the DB code was not only a joy, it makes too much sense!

Thinking that interface with the network to store some meager byte on a disk is normal, that use terrible languages for data programming (not only SQL but JS, C# or whatever) is fine is baffling.

But well.

In terms of what is available:

* RDBMS despite being applications (including sqlite) and not developer frameworks are plenty flexible and powerful for at least solve most data-oriented coding

"DATA"-oriented is the key: Is wrong to say "this is backend, frontend, ui, etc" that is more a deployment issue and totally orthogonal.

The most obvious example is the effect of N+1 queries: You are not thinking in what is data-oriented and using a incorrect programming language to solve what even an anemic DSL like SQL do much better.

With the right mental model, is so easy to build a database schema with types, functions, procedures, views(that are so underused!) and such that make the clients DUMB.

IS MUCH EASIER!

And I work with ERPs, that are much more "complicated" than the median app.

Let the DB do what it does well and the rest will be simplified by leaps and bounds.

Even testing, just not commit the stupid mistake of use "mocks" that should be mocked and just spin ephemeral dbs/schemas. Is fast (even with PG) and will not create tons of churn because your regular langs is not ACID but the DB is.

Also reduce is a weird name.

This make too much sense!

In special when testing against a DB.