3 ms·

Re: ...we called Bill "the bad idea fairy". He always brought a slightly-off-kilter view of technical problems, which triggered endless discussions of fascinat

by tabtab 7y ago

Re: ...we called Bill "the bad idea fairy". He always brought a slightly-off-kilter view of technical problems, which triggered endless discussions of fascinating, if usually implausible, alternatives. I've been "accused" of similar. Although, I can't claim I'm as successful as Bill. I tend to ruffle sacred cows. It's not like I'm trying to agitate people, I just view the world a bit different from established opinions. For example, we have dynamic programming languages, but not dynamic RDBMS (that use SQL or a close variation). Why not? And we have XML as a fairly flexible meta-standard for data structures, but why not something comparable for C-like-syntax programming languages? You could roll your own programming language without creating a parser from scratch (and hopefully mix and match behavior based on "part kits"). Both of these seem like logical extensions of existing tools to me, but I get a lot of vague flack. It's like the universe is calling for them, not just me, yet nobody cares. It's not outright inventing new concepts, it's just taking concepts that worked well in one computing domain and applying them to another. They might fail, but so might every other IT experiment going on currently.

samatman 7y ago
> For example, we have dynamic programming languages, but not dynamic RDBMS (that use SQL or a close variation). Why not? Depending on what you mean, SQLite is exactly this. It is relational, so one does have to structure tables, but I consider this equivalent to naming variables. Unlike most (all?) other SQL databases, however, the 'types' of the data are just suggestions, and have some influence on how SQLite stores and retrieves them internally. But you can put a string in an INTEGER field, SQLite won't stop you.
- tabtab 7y ago
  But you have to pre-specify the columns. In a truly dynamic DB, you could enter "INSERT INTO foo (myNewColumn) VALUES (123)" and both the table "foo" and "myNewColumn" are created on the fly. SqlLite doesn't do this. Further, one could add restrictions as needed to "lock down" both new column creation, and add type-like validation ("parse" check). Thus, as requirements solidify, it can act more like a traditional RDBMS.
paulmd 7y ago
> For example, we have dynamic programming languages, but not dynamic RDBMS (that use SQL or a close variation). Why not? JSON datatypes essentially serve that need nowadays. Postgres even lets you write queries against them. Generally, a lot of the value from RDBMS in fact comes from strong guarantees that you can make about the data you're storing (datatypes, constraints, unique indexes, etc). That's what makes them inherently better than MongoDB or whatever. But if you really just want a "misc" column (or to use PG as a key-value-store) then you can do that with a JSON column. What use-case are you looking at that wouldn't be solved by a JSON column? > And we have XML as a fairly flexible meta-standard for data structures, but why not something comparable for C-like-syntax programming languages? You could roll your own programming language without creating a parser from scratch (and hopefully mix and match behavior based on "part kits"). Well, isn't that lex and yacc?
- tabtab 7y ago
  Re: JSON datatypes essentially serve that need nowadays. Postgres even lets you write queries against them. Yes, but JSON columns are treated mostly different than regular columns. They are like second-class citizens that require more verbosity to work with. Dynamic Relational won't have this dichotomy. Columns are columns. Re: Well, isn't that lex and yacc? No. You could make a parser for C, Lisp, Fortran, Datalog, etc. with them. They don't offer a standard. I'm proposing a standard syntax or meta syntax. Then the common existing languages could offer a parser for this meta language similar to how they offer an XML parser. You don't have to build the XML parser yourself nor give it the parsing rules for XML, like you have to with lex/yacc. You couldn't do that with lex and yacc in a practical way, they are too big and open-ended. Re: a lot of the value from RDBMS in fact comes from strong guarantees that you can make about the data you're storing There is a time and place for static and a time and place for dynamic. Further, Dynamic Relational can incrementally apply constraints to "lock down" various aspects, as I mentioned nearby. For example, you could add a "parse check" to a given column to ensure its parse-able as a integer upon insert and/or updates. Thus, out of the box it's loosey goosey, but doesn't have to stay that way. I'm working on a write-up to explain this all with SQL examples.
JoelMcCracken 7y ago
Re: mixing and matching parts, you are describing Lisp. And probably Racket.
- tabtab 7y ago
  They are not "C-like" in their syntax, at least in an enforced kind of way. (What I proposed had to deviate from C-like a bit to ensure NON-reliance on key-words to know where block-groups start and end. I had to find a middle ground between being "meta" and being C-like. I nicknamed it "moth" based on the shape of the primary "atomic" structure.)
einpoklum 7y ago
> And we have XML as a fairly flexible meta-standard for data structures Are you a time traveler from 15 years ago? :-)
averros 7y ago
We actually do have dynamic databases (Snowflake has native VARIANT type which is automagically sharded internally into columns so it's processed in pretty much the same way as "normal" relational data).
jacquesm 7y ago
More often than not those 'bad ideas' lead with a bit of twisting to good ideas. I've seen quite successful companies started like this multiple times, and it is an essential component in a good pivot.
deleted 7y ago
[deleted]

by tabtab 7y ago

samatman 7y ago

> For example, we have dynamic programming languages, but not dynamic RDBMS (that use SQL or a close variation). Why not? Depending on what you mean, SQLite is exactly this. It is relational, so one does have to structure tables, but I consider this equivalent to naming variables. Unlike most (all?) other SQL databases, however, the 'types' of the data are just suggestions, and have some influence on how SQLite stores and retrieves them internally. But you can put a string in an INTEGER field, SQLite won't stop you.

tabtab 7y ago
But you have to pre-specify the columns. In a truly dynamic DB, you could enter "INSERT INTO foo (myNewColumn) VALUES (123)" and both the table "foo" and "myNewColumn" are created on the fly. SqlLite doesn't do this. Further, one could add restrictions as needed to "lock down" both new column creation, and add type-like validation ("parse" check). Thus, as requirements solidify, it can act more like a traditional RDBMS.

paulmd 7y ago

> For example, we have dynamic programming languages, but not dynamic RDBMS (that use SQL or a close variation). Why not? JSON datatypes essentially serve that need nowadays. Postgres even lets you write queries against them. Generally, a lot of the value from RDBMS in fact comes from strong guarantees that you can make about the data you're storing (datatypes, constraints, unique indexes, etc). That's what makes them inherently better than MongoDB or whatever. But if you really just want a "misc" column (or to use PG as a key-value-store) then you can do that with a JSON column. What use-case are you looking at that wouldn't be solved by a JSON column? > And we have XML as a fairly flexible meta-standard for data structures, but why not something comparable for C-like-syntax programming languages? You could roll your own programming language without creating a parser from scratch (and hopefully mix and match behavior based on "part kits"). Well, isn't that lex and yacc?

tabtab 7y ago
Re: JSON datatypes essentially serve that need nowadays. Postgres even lets you write queries against them. Yes, but JSON columns are treated mostly different than regular columns. They are like second-class citizens that require more verbosity to work with. Dynamic Relational won't have this dichotomy. Columns are columns. Re: Well, isn't that lex and yacc? No. You could make a parser for C, Lisp, Fortran, Datalog, etc. with them. They don't offer a standard. I'm proposing a standard syntax or meta syntax. Then the common existing languages could offer a parser for this meta language similar to how they offer an XML parser. You don't have to build the XML parser yourself nor give it the parsing rules for XML, like you have to with lex/yacc. You couldn't do that with lex and yacc in a practical way, they are too big and open-ended. Re: a lot of the value from RDBMS in fact comes from strong guarantees that you can make about the data you're storing There is a time and place for static and a time and place for dynamic. Further, Dynamic Relational can incrementally apply constraints to "lock down" various aspects, as I mentioned nearby. For example, you could add a "parse check" to a given column to ensure its parse-able as a integer upon insert and/or updates. Thus, out of the box it's loosey goosey, but doesn't have to stay that way. I'm working on a write-up to explain this all with SQL examples.

JoelMcCracken 7y ago

Re: mixing and matching parts, you are describing Lisp. And probably Racket.

tabtab 7y ago
They are not "C-like" in their syntax, at least in an enforced kind of way. (What I proposed had to deviate from C-like a bit to ensure NON-reliance on key-words to know where block-groups start and end. I had to find a middle ground between being "meta" and being C-like. I nicknamed it "moth" based on the shape of the primary "atomic" structure.)

einpoklum 7y ago

> And we have XML as a fairly flexible meta-standard for data structures Are you a time traveler from 15 years ago? :-)

averros 7y ago

We actually do have dynamic databases (Snowflake has native VARIANT type which is automagically sharded internally into columns so it's processed in pretty much the same way as "normal" relational data).

jacquesm 7y ago

More often than not those 'bad ideas' lead with a bit of twisting to good ideas. I've seen quite successful companies started like this multiple times, and it is an essential component in a good pivot.

deleted 7y ago

[deleted]