The future of TTM
I want to add that for many years I have considered and still consider Git to also be a good option for a transactional/ACID storage engine that one can layer bespoke data models / relational on top of.
In particular I have long envisioned Git as a foundation for a multi-versioned DBMS that natively keeps multiple versions of a database at once.
What I particularly liked is that the idea of Git allowed me to conceive and break down the concept of database transactions into at least 2 distinct operations:
- Durable persistence of the changes that any concurrent user wants to make; this takes the form of a new branch with a commit having the changes.
- The second step is merging that user's changes back into the trunk so others see it combined with their changes.
Quite often it seems database engines like to combine the above 2 steps into one from the user's point of view, and I feel that makes things way more complicated, while doing it conceptually how I propose would actually be simpler to implement, letting one tackle 2 distinct problems separately, and also allowing new features, branched multiple versions, that can be visible to users.
Doesn't have to be Git, could be any storage method that basically implements a logical graph of nodes that are deltas from or merges of others.
This system also bakes in speed in a sense and bakes in very effective replication with multiple masters etc.
We can layer any data model etc on top we want.
Keep in mind Git is a system with multiple libraries or components layered and has a few abstraction levels in internally. Our DBMS can be written against any of those, its not like we have to explicitly save files in the file system and call a command-line git command to do its work, we can skip the intermediate files etc.
What are thoughts on this?
Quote from Darren Duncan on August 1, 2021, 5:38 am...
What are thoughts on this?
Build it and see what you get.
As an aside, and not directed at you (and directed at myself as much as anyone...)
Time to stop cackling and lay an egg.
We do a lot of cackling and not much egg laying here. If we were a bunch of hens, we'd have been branded useless and tossed in the soup pot long ago.
Write some code and get it on github or wherever and try to use it to do real things. Whether it starts with the relational model and a search for applications, or starts with solving a problem or requirements and uses the relational model as a solution, or something else, doesn't really matter.
What matters is that if there's to be any future in TTM ideas, it will be in the form of written and working and useable code, not endless cackling about code-that-might-be.
Quote from Dave Voorhis on August 1, 2021, 8:35 amAs an aside, and not directed at you (and directed at myself as much as anyone...)
Time to stop cackling and lay an egg.
We do a lot of cackling and not much egg laying here. If we were a bunch of hens, we'd have been branded useless and tossed in the soup pot long ago.
Write some code and get it on github or wherever and try to use it to do real things. Whether it starts with the relational model and a search for applications, or starts with solving a problem or requirements and uses the relational model as a solution, or something else, doesn't really matter.
What matters is that if there's to be any future in TTM ideas, it will be in the form of written and working and useable code, not endless cackling about code-that-might-be.
You are right. Speaking for myself I actually am pushing through on writing code as I can afford the time. And I actually do try to limit my time talking here, as any time I do its highlighting my lack of delivered code. My rarer posts I considered more strategic. In this thread, in case anyone else trying to code, maybe my last few might help those efforts.
Quote from Darren Duncan on August 1, 2021, 5:38 amI want to add that for many years I have considered and still consider Git to also be a good option for a transactional/ACID storage engine that one can layer bespoke data models / relational on top of.
In particular I have long envisioned Git as a foundation for a multi-versioned DBMS that natively keeps multiple versions of a database at once.
What I particularly liked is that the idea of Git allowed me to conceive and break down the concept of database transactions into at least 2 distinct operations:
- Durable persistence of the changes that any concurrent user wants to make; this takes the form of a new branch with a commit having the changes.
- The second step is merging that user's changes back into the trunk so others see it combined with their changes.
Quite often it seems database engines like to combine the above 2 steps into one from the user's point of view, and I feel that makes things way more complicated, while doing it conceptually how I propose would actually be simpler to implement, letting one tackle 2 distinct problems separately, and also allowing new features, branched multiple versions, that can be visible to users.
Doesn't have to be Git, could be any storage method that basically implements a logical graph of nodes that are deltas from or merges of others.
This system also bakes in speed in a sense and bakes in very effective replication with multiple masters etc.
We can layer any data model etc on top we want.
Keep in mind Git is a system with multiple libraries or components layered and has a few abstraction levels in internally. Our DBMS can be written against any of those, its not like we have to explicitly save files in the file system and call a command-line git command to do its work, we can skip the intermediate files etc.
What are thoughts on this?
Does Git have a relational model to expose? Or do you propose offering Git as an engine for general application development? Whose problem does that solve? Who will use it?
Quote from Dave Voorhis on August 1, 2021, 8:35 amQuote from Darren Duncan on August 1, 2021, 5:38 am...
What are thoughts on this?
Build it and see what you get.
As an aside, and not directed at you (and directed at myself as much as anyone...)
Time to stop cackling and lay an egg.
We do a lot of cackling and not much egg laying here. If we were a bunch of hens, we'd have been branded useless and tossed in the soup pot long ago.
Write some code and get it on github or wherever and try to use it to do real things. Whether it starts with the relational model and a search for applications, or starts with solving a problem or requirements and uses the relational model as a solution, or something else, doesn't really matter.
What matters is that if there's to be any future in TTM ideas, it will be in the form of written and working and useable code, not endless cackling about code-that-might-be.
Afer some thought, I have to disagree. Writing code is easy, the hard things are (a) knowing what code to write and (b) getting others to use it.
You have produced a high quality implementation of a TTM/D. It has a strong usage case as a teaching aide, backed up by D&D textbooks. But does anyone else use it?
Erwin's SIRA_PRISE is an impressive piece of coding, but does anyone use it? My Andl and two subsequent related products are a major investment in time and effort, but does anyone use it? This is working and usable code but the answer is no, not even me. It doesn't solve anyone's problem.
So, IMO what matters is that if there's to be any future in TTM ideas, it will be in the form of code that solves someone's problem. Writing the code is easy, it's finding the right problem that's hard. And that's what I've been trying to do.
Quote from dandl on August 2, 2021, 12:00 amDoes Git have a relational model to expose? Or do you propose offering Git as an engine for general application development? Whose problem does that solve? Who will use it?
What I'm proposing is that Git might be a good bottom layer to implement a storage system for application data, and a layer over it could implement a relational model, or otherwise.
This would be an alternative to using BerkleyDB or other lower level key-value stores etc.
Features that Git would provide for us include the critical aspects of transactions / ACID, including nested transactions, as well as multi-master replication.
A stand-out feature is native support for graph-based multi-versioning for the data such that making changes persistent and merging different users/tasks changes are separate operations.
An example real world use case where this kind of thing can be useful is an end user is working their way through a multiple part form to make a batch of changes, the system can separately save their work in progress as they do it, and later on when they say they're done it gets merged so everyone else sees it.
Or an example real world use case is someone could try doing several alternative changes and save each one before finally deciding on what they want to keep, or they can keep several.
In contrast, typical DBMS are entirely linear. Granted that's typically what one wants, but it can also be constraining.
Quote from dandl on August 2, 2021, 12:10 amQuote from Dave Voorhis on August 1, 2021, 8:35 amQuote from Darren Duncan on August 1, 2021, 5:38 am...
What are thoughts on this?
Build it and see what you get.
As an aside, and not directed at you (and directed at myself as much as anyone...)
Time to stop cackling and lay an egg.
We do a lot of cackling and not much egg laying here. If we were a bunch of hens, we'd have been branded useless and tossed in the soup pot long ago.
Write some code and get it on github or wherever and try to use it to do real things. Whether it starts with the relational model and a search for applications, or starts with solving a problem or requirements and uses the relational model as a solution, or something else, doesn't really matter.
What matters is that if there's to be any future in TTM ideas, it will be in the form of written and working and useable code, not endless cackling about code-that-might-be.
Afer some thought, I have to disagree. Writing code is easy, the hard things are (a) knowing what code to write and (b) getting others to use it.
You have produced a high quality implementation of a TTM/D. It has a strong usage case as a teaching aide, backed up by D&D textbooks. But does anyone else use it?
Erwin's SIRA_PRISE is an impressive piece of coding, but does anyone use it? My Andl and two subsequent related products are a major investment in time and effort, but does anyone use it? This is working and usable code but the answer is no, not even me. It doesn't solve anyone's problem.
So, IMO what matters is that if there's to be any future in TTM ideas, it will be in the form of code that solves someone's problem. Writing the code is easy, it's finding the right problem that's hard. And that's what I've been trying to do.
I think you're trying to solve someone else's problem.
Write code to solve your own. Then you're guaranteed at least one happy user.
Any more than that is a bonus, but I suspect you'll be much more likely to get more users by solving your own real problems than trying to find someone else's problems to solve.
Quote from Dave Voorhis on August 2, 2021, 7:27 amQuote from dandl on August 2, 2021, 12:10 amQuote from Dave Voorhis on August 1, 2021, 8:35 amQuote from Darren Duncan on August 1, 2021, 5:38 am...
What are thoughts on this?
Build it and see what you get.
As an aside, and not directed at you (and directed at myself as much as anyone...)
Time to stop cackling and lay an egg.
We do a lot of cackling and not much egg laying here. If we were a bunch of hens, we'd have been branded useless and tossed in the soup pot long ago.
Write some code and get it on github or wherever and try to use it to do real things. Whether it starts with the relational model and a search for applications, or starts with solving a problem or requirements and uses the relational model as a solution, or something else, doesn't really matter.
What matters is that if there's to be any future in TTM ideas, it will be in the form of written and working and useable code, not endless cackling about code-that-might-be.
Afer some thought, I have to disagree. Writing code is easy, the hard things are (a) knowing what code to write and (b) getting others to use it.
You have produced a high quality implementation of a TTM/D. It has a strong usage case as a teaching aide, backed up by D&D textbooks. But does anyone else use it?
Erwin's SIRA_PRISE is an impressive piece of coding, but does anyone use it? My Andl and two subsequent related products are a major investment in time and effort, but does anyone use it? This is working and usable code but the answer is no, not even me. It doesn't solve anyone's problem.
So, IMO what matters is that if there's to be any future in TTM ideas, it will be in the form of code that solves someone's problem. Writing the code is easy, it's finding the right problem that's hard. And that's what I've been trying to do.
I think you're trying to solve someone else's problem.
Write code to solve your own. Then you're guaranteed at least one happy user.
Any more than that is a bonus, but I suspect you'll be much more likely to get more users by solving your own real problems than trying to find someone else's problems to solve.
That may work for you, it doesn't for me. I just don't have any problems that need this kind of tech to solve. If I did, I would do just enough to scrape by, never enough to be good enough for someone else to use.
We have just had the most successful unicorn ever. Afterpay founded in 2014 and just sold for $A39 billion. The founders of Afterpay did not write software so that they personally could 'buy now pay later', or to use in their own retail business. They wrote software to solve someone else's problem: retailers who wanted to make online sales with instant credit and minimal regulation.
My formula is always: find a customer with a problem (or need), solve the problem, get paid, rinse and repeat. That's business in a nutshell. The rest is implementation detail -- it's that first step of finding the customer that really matters if you want your business/software to succeed.
You Rel product came with a ready-made customer and problem: teachers using D&D textbooks. It's simple, it works (but it's not easy).
Quote from dandl on August 2, 2021, 2:15 pmQuote from Dave Voorhis on August 2, 2021, 7:27 amQuote from dandl on August 2, 2021, 12:10 amQuote from Dave Voorhis on August 1, 2021, 8:35 amQuote from Darren Duncan on August 1, 2021, 5:38 am...
What are thoughts on this?
Build it and see what you get.
As an aside, and not directed at you (and directed at myself as much as anyone...)
Time to stop cackling and lay an egg.
We do a lot of cackling and not much egg laying here. If we were a bunch of hens, we'd have been branded useless and tossed in the soup pot long ago.
Write some code and get it on github or wherever and try to use it to do real things. Whether it starts with the relational model and a search for applications, or starts with solving a problem or requirements and uses the relational model as a solution, or something else, doesn't really matter.
What matters is that if there's to be any future in TTM ideas, it will be in the form of written and working and useable code, not endless cackling about code-that-might-be.
Afer some thought, I have to disagree. Writing code is easy, the hard things are (a) knowing what code to write and (b) getting others to use it.
You have produced a high quality implementation of a TTM/D. It has a strong usage case as a teaching aide, backed up by D&D textbooks. But does anyone else use it?
Erwin's SIRA_PRISE is an impressive piece of coding, but does anyone use it? My Andl and two subsequent related products are a major investment in time and effort, but does anyone use it? This is working and usable code but the answer is no, not even me. It doesn't solve anyone's problem.
So, IMO what matters is that if there's to be any future in TTM ideas, it will be in the form of code that solves someone's problem. Writing the code is easy, it's finding the right problem that's hard. And that's what I've been trying to do.
I think you're trying to solve someone else's problem.
Write code to solve your own. Then you're guaranteed at least one happy user.
Any more than that is a bonus, but I suspect you'll be much more likely to get more users by solving your own real problems than trying to find someone else's problems to solve.
That may work for you, it doesn't for me. I just don't have any problems that need this kind of tech to solve. If I did, I would do just enough to scrape by, never enough to be good enough for someone else to use.
We have just had the most successful unicorn ever. Afterpay founded in 2014 and just sold for $A39 billion. The founders of Afterpay did not write software so that they personally could 'buy now pay later', or to use in their own retail business. They wrote software to solve someone else's problem: retailers who wanted to make online sales with instant credit and minimal regulation.
Conversely, two of the biggest wins in terms of scoring everybody-uses-it market share levels are Slack and git, both of which were developers scratching their own -- or at least their development team's -- itches.
Some months ago, you were looking for something to do desktop data dicing and slicing. That, if I recall correctly, led you to work on extending KNIME. But at the time it sounded to me like a perfect opportunity to dust off Andl and reshape it to solving the problem -- and the general category of problems like it -- with or without KNIME.
Then, you talked about a colleague using Excel to awkwardly track something, so you wanted automatic CRUD-UI-generation. Not sure what happened with that.
To me, rather than "I just don't have any problems that need this kind of tech to solve", it sounds like you have exactly the sort of "problems that need this kind of tech to solve" popping up under your nose and shouting "me me me me!"
Otherwise, trying to land big fish in the general problem-solving world is either standard consulting -- which is almost 100% off-the-shelf platforms and tools -- or new products that demand lottery-win levels of luck and fortuity, along with bet-your-life-savings-and-all-your-assets levels of marketing and promotion.
Indeed, for every unicorn that succeeds wildly, there are a million or so expensive attempts that don't.
My formula is always: find a customer with a problem (or need), solve the problem, get paid, rinse and repeat. That's business in a nutshell.
That's (software) engineering consulting in a nutshell, which uses standard toolchains and good marketing and a strong reputation to succeed.
Entrepreneurial innovation based on a new product is rather different, particularly as you may not even be solving a problem as much as creating a new problem space in which new problems can be solved.
Quote from dandl on August 2, 2021, 12:10 am
Afer some thought, I have to disagree. Writing code is easy, the hard things are (a) knowing what code to write and (b) getting others to use it.
You have produced a high quality implementation of a TTM/D. It has a strong usage case as a teaching aide, backed up by D&D textbooks. But does anyone else use it?
Erwin's SIRA_PRISE is an impressive piece of coding, but does anyone use it? My Andl and two subsequent related products are a major investment in time and effort, but does anyone use it? This is working and usable code but the answer is no, not even me. It doesn't solve anyone's problem.
So, IMO what matters is that if there's to be any future in TTM ideas, it will be in the form of code that solves someone's problem. Writing the code is easy, it's finding the right problem that's hard. And that's what I've been trying to do.
Erwin's SIRA_PRISE does solve a problem that everyone is having : the fact that they need programmers/coders to get the business rules enforced (and the miserable quality and reliability of the data that inevitably ensues). But for one reason or other, it doesn't seem to be seen as a real problem by those experiencing it. Well, their loss not mine.
I had my personal reasons for doing that project and that was mainly I wanted to know purely for myself how far I could get. I have done so and I know it.