3 ms·

> It's entirely valid to leave the schema implicit in many circumstances (but not all - generally not in a database, for example), but you still need the genera

> It's entirely valid to leave the schema implicit in many circumstances (but not all - generally not in a database, for example), but you still need the general structure of how data is represented. > ... > Essentially, "standardized structure but flexible schema" is the 'happy compromise' where the most fragile part is taken care of for you, but the least predictable and most variable part is still entirely customizable. You can see this work successfully in eg. nushell or Powershell, or even to a more limited degree in tools like `jq`. That's a fair point, thanks for putting emphasis on this! > I think there's a strong selection bias here. It's not without reason that so many people have an aversion to terminals today - they just aren't very good. And it's not just their terminal-ness either, because many people who cannot deal with a standard (eg. bash) shell will happily use terminal-like input systems in specialized software. The question then becomes what can be reasonably done about it? Or rather, can it even be realistically achieved (in an arbitrary time scale that we care about), given how much of the culture and tooling is currently centered around passing text from one command to another. Change for something so foundational surely wouldn't be quick. > But that's not a reason to downgrade the 'ideal' to fit the current reality, only a reason to acknowledge that we're just not there yet. In the end, this probably sums it up nicely. Even if that current reality, which often will be the lowest common denominator, is what most people will earn their paychecks with (and possibly leave edge cases for someone else to deal with down the line).

joepie91_ 4y ago
> The question then becomes what can be reasonably done about it? Or rather, can it even be realistically achieved (in an arbitrary time scale that we care about), given how much of the culture and tooling is currently centered around passing text from one command to another. Change for something so foundational surely wouldn't be quick. It definitely won't be quick, no. I think the tooling is actually not that big of a problem there; the functionality provided by the 'common tools' generally isn't that complex in scope (at least, in the context of modern development tools), and the many RIIR projects have shown that total do-overs for these sorts of tools are viable. The bigger problem is going to be cultural, and particularly that persistent (but often unspoken) belief that "computers peaked with UNIX in the 70s/80s and what we have now is the best it will ever be". It often results in people actively pushing back on improvements that really wouldn't have any downsides for them at all, thereby creating unnecessary friction. That same 'ideology', for lack of a better word, also makes it very difficult to talk about eg. hybrid terminal/graphical systems - because "GUIs are evil, text is better" and similar sentiments. That really gets in the way of advancing technology here. Ultimately, I think the actual interop and/or reimplementation problems are going to be a walk in the park, compared to dealing with the messy human and cultural/ideological factors involved that actively resist change.

joepie91_ 4y ago

> The question then becomes what can be reasonably done about it? Or rather, can it even be realistically achieved (in an arbitrary time scale that we care about), given how much of the culture and tooling is currently centered around passing text from one command to another. Change for something so foundational surely wouldn't be quick. It definitely won't be quick, no. I think the tooling is actually not that big of a problem there; the functionality provided by the 'common tools' generally isn't that complex in scope (at least, in the context of modern development tools), and the many RIIR projects have shown that total do-overs for these sorts of tools are viable. The bigger problem is going to be cultural, and particularly that persistent (but often unspoken) belief that "computers peaked with UNIX in the 70s/80s and what we have now is the best it will ever be". It often results in people actively pushing back on improvements that really wouldn't have any downsides for them at all, thereby creating unnecessary friction. That same 'ideology', for lack of a better word, also makes it very difficult to talk about eg. hybrid terminal/graphical systems - because "GUIs are evil, text is better" and similar sentiments. That really gets in the way of advancing technology here. Ultimately, I think the actual interop and/or reimplementation problems are going to be a walk in the park, compared to dealing with the messy human and cultural/ideological factors involved that actively resist change.