mamcx
Also available for custom software development
Location: Medellín, Colombia · Remote: Yes · Willing to relocate: No
Software engineer with 30+ years of experience building production-ready business applications and 3+ years as a core database engineer working on high-performance RDBMS technology.
Experienced across database engines, query processing, transactions, storage, performance optimization, ERP systems, and business applications. Driven to learn new domains quickly and choose the simplest effective architecture, tools, and paradigms for each problem.
ERP systems built from scratch · eCommerce platforms built from scratch · Business applications
* Résumé / CV: https://www.linkedin.com/in/mario-alejandro-montoya-cortés-6... * Email: [email protected] * Website: https://www.elmalabarista.com
`sum(a:int, b:int)`
not guaranteed ANYTHING.
The gulf between how much correct Rust is and the vas majority of languages is HUGE.
Location: Medellín, Colombia · Remote: Yes · Willing to relocate: No
Software engineer with 30+ years of experience building production-ready business applications and 3+ years as a core database engineer working on high-performance RDBMS technology.
Founder and principal engineer of a small ISV, with a long track record of owning complex systems end-to-end—from low-level design and implementation to production deployment and reliability.
Experienced across database engines, query processing, transactions, storage, performance optimization, ERP systems, and business applications. Driven to learn new domains quickly and choose the simplest effective architecture, tools, and paradigms for each problem.
Product Development:
ERP systems built from scratch · eCommerce platforms built from scratch · Business applications
* Résumé / CV: https://www.linkedin.com/in/mario-alejandro-montoya-cortés-6...
* Email: [email protected]
* Website: https://www.elmalabarista.com
Large companies exist, but pure software companies or with heavy side of it?
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!
Fun times.
(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
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 open to do custom software development!
Location: Medellín, Colombia Remote: Yes! Willing to relocate: No
Technologies: * System engineer: Rust · query engines · programming languages · VMs · transactions · storage · performance optimization · data modeling · ERPs · Business Apps
* Databases: RDBMs · PostgreSQL · SQL Server · SQLite · SpacetimeDB
* Backend: Business logic · APIs creation · integration · orchestration · ETLs
* Additional: Python, F#, Swift, Web assembly, Git, Jujutsu, macOS, Linux (NixOS, Debian), Windows
* ERP/eCommerce building from scratch
Résumé/CV: https://www.linkedin.com/in/mario-alejandro-montoya-cortés-6... Email: [email protected] https://www.elmalabarista.com
Software engineer with 30+ years building production-ready business applications and 3+ years as a core database engineer building high-performance RDBMs.
Founder and principal engineer of small ISV with a long track record of owning complex systems end-to-end, from low-level design to production reliability.
Driven to learn new domains quickly and choose the simplest effective architecture, tools and paradigms for each problem.
Think on this: You imagine yourself writing a regular website with ONLy sql? no, because SQL is not a "programming language" for developers.
Is possible you could think in various ideas about why is "nonsensical" to make an app with a relational language (that SQL clearly is not) but is the same as with OOP or functional: there is not reason to be a problem, and there is a lot of things that will be far easier if a proper relational language is used, like for example, is unnecessary and ORM and/or is not complicated and confusing to make one.
In special when testing against a DB.
Correct.
> you insist that your data demands bags.
No, I insist that real data needs both. You can bias the language/engine in one way or other.
The underlying problem is that once you say:
> if we want to support bags, its trivial to add a counter for the number of identical records as an additional column.
Then it means that this is second-class.
The main gripe I have, is that the relational model has this beautiful promise of "make the storage invisible" but need to have a coherent semantics about the data.
If you say "2 identical values/rows can't exist" then we adding the same problem that all the rdbms has: None implement the relational model, and none can deal with "relation on relations".
Imagine how crazy if I tell you a language can't do `[[1,2], [1, b10000]]` and to get into `b10000[:1] where ...` is necessary to switch to another paradigm.
P.D: note how "2 identical values can't exist" break when you have 2 columns, of numerical values, where the slice of both are the same value pair-wise: Are the 2 columns wrong?. And if both are called the same? same type? from different or same table? etc. "Duplicated" values are everywhere and is trivial to get there.
And if you "add a column" then it breaks the soundness of the language:
IN: [1, 1] != OUT: [1: 1, 2: 1]* It again ignore the best solution for nulls: Algebraic types. Once you have this much get solved for free
* The argument against bags:
The best idea of the paper is that a RDBMS in fact internally do different data structure and temporal representations that are not of concern to the user. Correct.
THEN it jumps to the conclusion that bags should not be presented to the user, despite the fact acknowledge it need to display them.
This is wrong, and the major reason that is always overlooked is that assume that 2 identical values are wrong to exist.
I can have "Jhon, Jhon", be 2 separate persons, not know at this time more to disambiguating, adding a Id do nothing to help me, and yet, this data is correct as is.
The language MUST allow me to deal with this. It will absurd to claim an array language, procedural, functional, imperative, declarative, etc can and a relational can't.
It say the lang is intentionally limited for purity, that true, is ideal in some cases, but that purity is what the engine/compiler should track, but not distort MY DATA for this.
And the part where the perf of having bags dismissed is easy to debunk: implement a dbms and profile.
P.D: Is true that set unlocks lots of benefits, and in some cases are ideal. But very fast once you hit the real world you see that need both, similar how btrees alone is not enough, and then there is hash-based indexes and many others.
it sucks, but reality is unfriendly to pure pure languages
P.D.2: And to clear misunderstanding, I agree with the points in the same way Rust say the borrow checker is ON by default, but I argue we CANT make a strict rule, in special because data is not ideological pure
There is NOT other *good reason*.
P.D: But, why? Well, at first SQL was truly small. Then the cost of "just adding" something look easier than redo another lang.
TODAY, SQL is insanely bad and complex.
To the point that you can, literally, learn Rust faster than SQL.
Seriously! look for example how many reserved words you need to be aware of:
https://en.wikipedia.org/wiki/List_of_SQL_reserved_words
P.D: I implement parts of the SQL support for a RDBMS. I think the teams expect >5 years to fully do it.
I bet is possible to implement Rust way faster than that (ie: I mean here for both: Parsing and correctly executing, not all optimization and other concerns)
This is compounded by the fact that you need the semantics involved, the environment (ie: everything on scope), the source (that means you need to keep carrying big strings around).
And what is efficient means to be destructive, but you need instead the opposite for semantics, error messages, optimizations and the like.
Also open to do custom software development!
Location: Medellín, Colombia Remote: Yes! Willing to relocate: No
Technologies: * System engineer: Rust · query engines · programming languages · VMs · transactions · storage · performance optimization · data modeling · ERPs · Business Apps
* Databases: RDBMs · PostgreSQL · SQL Server · SQLite · SpacetimeDB
* Backend: Business logic · APIs creation · integration · orchestration · ETLs
* Additional: Python, F#, Swift, Web assembly, Git, Jujutsu, macOS, Linux (NixOS, Debian), Windows
* ERP/eCommerce building from scratch
Résumé/CV: https://www.linkedin.com/in/mario-alejandro-montoya-cortés-6... Email: [email protected] https://www.elmalabarista.com
Software engineer with 30+ years building production-ready business applications and 3+ years as a core database engineer building high-performance RDBMs.
Founder and principal engineer of small ISV with a long track record of owning complex systems end-to-end, from low-level design to production reliability.
Driven to learn new domains quickly and choose the simplest effective architecture, tools and paradigms for each problem.
And I bet DB engines can go far than normal OS.
You don't know how much is still waiting for somebody to try, and how much is not applied. And how many of that DBs are not even doing, because all are constrained be being "apps" with so poor interface (sql).
Fun fact: Not exist a viable true relational DBs implemented, neither exist one with a viable programming language AND apis that is for developers.
ZERO.
All UI, honestly, is only meaningful in what the screen size and our vision permit. END.
UNFORTUNATELY, you can't avoid that a user is writing "a___" and the source data has millions of things that start with `a` and all the others are dozens.
So, you can end with a massive influx of data, and sure the user see that big mess and wanna dial in, but in the meantime is nice if the UI not die in the process.
From developers this is how in-house frameworks work, that are mostly reusing other frameworks and libraries and create a sort of pseudo DSL.
A good example of the actual tool is FoxPro and similar (even better than MS Access based on the ideals of the article) and I observed being actually used by occasional "developers" that need more than Access/Vb/Excel.
I'm on the hunt for it with https://tablam.org but the main major pain point is to bring the actual UI. You can go anywhere with syntax and such, is how you connect to the rest where the magic must prove is real.