3 ms·

>Unrelated to the root post, but I’m so glad that time is over. There was a ~1year period where it was nearly impossible to have a conversation about solving so

by vram22 3y ago

>Unrelated to the root post, but I’m so glad that time is over. There was a ~1year period where it was nearly impossible to have a conversation about solving something that didn’t involve someone scheming about how to reframe the problem as an ... Like NoSQL some time before that, and GPT / "AI" nowadays.

pfdietz 3y ago
I wonder if these LLMs have been trained on the DejaNews/Google usenet archive.
DaiPlusPlus 3y ago
Those who have never read Edgar Codd's seminal paper on RDBMS are doomed to repeat the sounds-good-if-you-dont-think-about-it-too-much mistakes that NoSQL makes people sleepwalk into - and this will never end because database-theory is always an unpopular elective for CS undergrads (and a very dry, unappealing, subject-matter at that) - everyone wants to do Graphics or NLP or even Haskell instead - and if that's what CS degree-holders are like think about how even less well-prepared (for formal-modelling, etc) that a self-taught or bootcamp attendee would be: my point being that people with the right knowledge are always in the minority in this industry). I say this isn't new because on the desktop in the 1990s, both Apple and Microsoft's dev platforms included some form of "object storage" based around their respective OLE/COM systems[1] and before then in the 1970s and 1980s it was people building business-systems on AS/400 (going back to the System 360...) where too many people never had a clue how to persist data on-disk (which was the whole impetus for Codd's paper, after-all) - so I think the 2000-2010 years where PHP+MySQL was dominant - and where most of us cut-our-teeth - was the exception: SQL is hard, relational theory is harder, relational calculus is harder-still (I think I got a B grade in that course...). Non-experts have a very reasonable expectation that platforms should make it straightforward to save and load structured data without needing to spend a year of CS spending hours on exercises about functional-composition, surrogate keys, and decomposing tables to their 6th Normal Form - the embarrassment here isn't the non-experts you might think I'm dunking on, but it's the opposite: I'm very disappointed in the experts: the database-vendors and the platform-vendors, that they haven't solved the object-graph persistence library design problem. ------------ [1]: OLE/COM was for more than just composition, embeddeding Excel worksheets in Word documents and GUI design-tools: COM/OLE also featured a binary object structured storage API ( https://en.wikipedia.org/wiki/COM_Structured_Storage https://en.wikipedia.org/wiki/COM_Structured_Storage )
- pitched 3y ago
  Because I was curious and you didn’t link to it, here is A Relational Model of Data for Large Shared Data Banks by EF Codd: https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
  - vram22 3y ago
    Thanks, must read.
- vram22 3y ago
  Cool, thanks for mentioning it.

by vram22 3y ago

pfdietz 3y ago

I wonder if these LLMs have been trained on the DejaNews/Google usenet archive.

DaiPlusPlus 3y ago

Those who have never read Edgar Codd's seminal paper on RDBMS are doomed to repeat the sounds-good-if-you-dont-think-about-it-too-much mistakes that NoSQL makes people sleepwalk into - and this will never end because database-theory is always an unpopular elective for CS undergrads (and a very dry, unappealing, subject-matter at that) - everyone wants to do Graphics or NLP or even Haskell instead - and if that's what CS degree-holders are like think about how even less well-prepared (for formal-modelling, etc) that a self-taught or bootcamp attendee would be: my point being that people with the right knowledge are always in the minority in this industry). I say this isn't new because on the desktop in the 1990s, both Apple and Microsoft's dev platforms included some form of "object storage" based around their respective OLE/COM systems[1] and before then in the 1970s and 1980s it was people building business-systems on AS/400 (going back to the System 360...) where too many people never had a clue how to persist data on-disk (which was the whole impetus for Codd's paper, after-all) - so I think the 2000-2010 years where PHP+MySQL was dominant - and where most of us cut-our-teeth - was the exception: SQL is hard, relational theory is harder, relational calculus is harder-still (I think I got a B grade in that course...). Non-experts have a very reasonable expectation that platforms should make it straightforward to save and load structured data without needing to spend a year of CS spending hours on exercises about functional-composition, surrogate keys, and decomposing tables to their 6th Normal Form - the embarrassment here isn't the non-experts you might think I'm dunking on, but it's the opposite: I'm very disappointed in the experts: the database-vendors and the platform-vendors, that they haven't solved the object-graph persistence library design problem. ------------ [1]: OLE/COM was for more than just composition, embeddeding Excel worksheets in Word documents and GUI design-tools: COM/OLE also featured a binary object structured storage API ( https://en.wikipedia.org/wiki/COM_Structured_Storage https://en.wikipedia.org/wiki/COM_Structured_Storage )

pitched 3y ago
Because I was curious and you didn’t link to it, here is A Relational Model of Data for Large Shared Data Banks by EF Codd: https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
- vram22 3y ago
  Thanks, must read.
vram22 3y ago
Cool, thanks for mentioning it.