mamcx

2 小時前discuss

> When writing an API, it’s easy to unknowingly introduce a dangerous, implicit assumption: that the database is the ultimate source of truth. If a record is in the database, an application often treats it as authoritative. I want to explain in this post why that might be a very bad idea.

This premise is weird at best.

"the database is the ultimate source of truth" is not a "dangerous, implicit assumption", is the best rule you can get (and the rest of the post say so: all useful data comes from it!)

Instead the rest of the article is interesting on how to choose what to use for the hash, but not follow with this first paragraph :shrug:

mamcx

昨天discuss

I live in the ERP-adjacent world, and the vast majority don't have any of that, never have, and I pray most don't.

P.D: the business world is the one that needs AND tries everything, and most attempt to implement something is much worse than the simpler previous thing.

For most that I know and most I bet (even without knowing) add "high availability" or "warm standby" WILL CERTAINLY lead to worse availability.

In fact, the best setup for most people, and consider things from today (that you will see, not that different from mainframe days!):

- Single server on a *nix LTS/immutable distro with just the RDBMS + App backend, on decent hardware. Fast, lots of ram or whatever optional

- A true reliable backup system

- A decent network setup, ideally a VPN one for connect everybody, with good firewall, SSL and that is

More complex than this and is 90% certain is much worse, other 8% until the dude that do it and care leaves.

mamcx

前天discuss

Yeah, I think was algebraic + pattern matching that break the ghetto. Suddenly types were far more useful without going crazy like Haskell!

P.D: Before, the exposure of types was from C++/Java, and special C++ is always a horrible exponent of anything except how make a overly complex language.

Once you see what good application of types look like, is far better sell!

mamcx

4 天前discuss

Sure, the point I try to make is that if you add things useful for OLAP to a OLTP system you could pessimist the OLTP system (that most often is the source of truth)

mamcx

4 天前discuss

YES!

The problem of all the datastores is that are applications (like Wordpress) so you are too late to fix anything deep.

We need "frameworks" (so each sub-component can be used as-is or even swapped) and even wondering what a "system level" data engine could be.

mamcx

8 天前discuss

In general you WANNA see any people using your app.

Read an "accessibility" spec or a requirement or a UX "good practice" is not a substitute for see how people use it!

One of my anecdotes from back in the day: The secretary of a school that use the app I help develop call about problems reading data, that comes in CD. We can't do much by phone so I travel to the town to try to debug on site (bring dev tools in the day where that means diskettes and cds, we were transitioning from FoxPro 2.6 DOS to Visual Fox Windows 95).

Eventually after some time the secretary put the coffee cup in the CD tray.

Go figure!

mamcx

9 天前discuss

The same with NixOS and in production. Even less than 15 minutes month.

mamcx

14 天前discuss

LOL!

Something I learn doing this stuff +25 years is that support and custom development eat you alive, and is not profitable for small ISV like mine.

Sadly, I can't use Fox now so I more constrained and unable to give the same. That is why I rebuilding the erp as an engine (fancy name: "headless erp") and working in make a lang and maybe a custom RDBMS. But then I need a GUI builder to get the same idea!

Just a minor inconvenience!

mamcx

14 天前discuss

Cool!

I have this dream of revive this kind of spirit (https://tablam.org).

I started with Foxpro 2.6 and it was a blast.

One of the very cool things Fox allow us was to ship their ability to `CREATE FORM, CREATE REPORT, BROWSE, etc` so the users can customize the app with the same power as us. This is one of the most important advantages of ERPs and such made with Fox and is still unmatched.

mamcx

17 天前discuss

Aside: what is the best to read receipts/bank statements/invoices?

mamcx

18 天前discuss

The other way is to make the tool UX do the semantic, ie:

`git split`

Something that I enjoy with jujutsu is that the semantics is the tool itself. ONCE you do that, the rest become easier!

mamcx

19 天前discuss

> Now why can't compilers do this sort of thing automatically?

Because they are not query compilers, ie: They don't know the data.

For example a query compiler could swap index to full scan because it "see" (by runtime statistics) the data not benefit for it.

In the other hand, an optimization here can pessimism there. So optimizers in general should be very conservative because butterfly effects!

mamcx

22 天前discuss

I have read TONS of material about it*, and none of that is part of the majority of that!

In fact, the "backend" be compiler or interpreter is nearly always left as "exercise to reader".

You can't imagine how much is left to be discovered, from how make a closure, track environment, do pattern matching, memory representation, etc.

EVERYTHING interesting is something you need to look for.

P.D: This only one of the years:https://gist.githubusercontent.com/mamcx/e1743571b9a1ea163a7...

mamcx

27 天前discuss

Reworking my ERP so is becoming more a "system" than an "app" and has composable units to build any kind of business transaction.

Think like https://plaintextaccounting.org but with more metadata so it can model the flow from manufacturing/production to sales.

Is build with Rust and hope to launch this year.

mamcx

28 天前discuss

Ok this looks like interesting, and now rebuilding my ERP it sounds the kind stuff I need to look at.

Question: Could this be useful to store history of changes? One pesky trouble is that after you close an invoice all the data there becomes immutable but you need to continue change the base tables.

So, I have a convoluted way of double write rows and keep the "current" as main. All for "just" the case that an invoice need to see the data as was when finalized.

Is this feature for this case too?

mamcx

上個月discuss

I do tenant per PG schema, most are smallish some are bigger (not much, can do all in a single box) but moving forward eventually will need something like this. Also plan to provide "get your own VPS" for more enterprise customers.

This kind of tool will help in this case?

mamcx

上個月discuss

This is a misunderstanding of what serializable in an ACID datastore does, neither that trust developers without FK is always trouble, and that the suggestion of Redis show how much is lost here.

Big point: Serializable not exist alone in a decent ACID datastore, and no, less strict rules for the MOST important thing you have(your data) is NOT a good idea.

Over and over again Acid RDBMS have proven that trying to "relax" the rules in pursuit of performance or worse, mystical holy grails that have never been right or correct for a primary datastore, is a mistake. And then people goes back to them, because is the best tool for ALL the primary data store jobs. ALL OF THEM.

Is like the mythical C developer that "not need safety", that at least has more chance of be possible (after MANY passes over the code) that a datastore without safeguards.

mamcx

上個月discuss

yeah, lets be clear:

Most of the proc macros non-sense is to be able to annotate the enum or struct without wrapping it.

So that is why I use this hack:

https://docs.rs/macro_rules_attribute/0.2.2/macro_rules_attr...

P.D: Is there a true actually reason for proc-macros apart for this weird restriction?? And even if yes, how much nice things will be if this kind of scenario was already present so most not need to reach for proc-macros

mamcx

上個月discuss

How is this done?

mamcx

上個月discuss

> How does CQL differ from SQL?

Most attempts to replace/improve SQL derive from the fact SQL was a poorly conceived and designed interface, that originally was meant to be a very small DSL for end users, but unfortunately, was allowed to become a poor, complicated, confusing mess for app developers:

https://cacm.acm.org/research/50-years-of-queries/

    SQL is not an orthogonal language... This is because, in the early days, Ray Boyce and I did not think we were designing a language for programmers. ..
 As it turned out, Ray and I were wrong about the predominant usage of SQL...

(same problem from JS, php, etc: Creators don't anticipate that developers will suffer and torture their needs with such anemic ideas!)

---

So the #1 thing any actual replacement or alternative to SQL is how actually become a good language for development, so it is actually composable, can be actually be used to reason about it, has minimal foot guns, etc.

There is a lot of misunderstanding and pushback, similar to how people in the past fight improvements over JS/C/C++ until typescript, rust comes.

But, oh boy, SQL need their typescript!

Submissions

Ask HN: Web editor that operate with AST?

comments