Still, databases and file systems are both based on concepts that predate electronic computers.
When Windows and Macs came along the document metaphor became prevalent, but in practice this was always just a "user friendly" name for a file. The layers and layers of slightly broken metaphors never gets simpler. They interact in unpredictable and inconvenient ways that people adapt to, because people are far more adaptable than the machines we build. The rather intense focus on usability in recent years is probably the most powerful tool we have to sweep away all these partially implemented and poorly thought out concepts. User experience is even now the main driving force behind the evolution of programming environments. Even without auto-completion and fancy debuggers, there is a profound growth in the use of dynamic languages. The millions of hours of development that have gone into the tools the major computer vendors have been using to lock people into their platforms are no match. What matters for developers is quick turnaround for debugging problems and code that expresses its intention in a concise and elegant manner. This is a profound change in the past 5 years. So how can you make simple languages simple to use? Developers have been rejecting complex GUIs in favour of plain text. If Google and Apple are right, every program component isn't a file on a disk, but rather some network accessible resource. On the other hand, a cynical person would say that the "cloud" is just another broken metaphor to pile onto the heap, because all this stuff is going to be built on top of the concepts we are already stuck with. Virtual environments might also be a good way to keep the detritus of the past from cluttering the future, but a cynic might have some opinions about that too :-) Cheers Steve On Tue, Jun 21, 2011 at 7:30 PM, Julian Leviston <[email protected]> wrote: > Yeah I've been using this DBMS on and off for years. I have a copy of it > installed on my machine. It's INCREDIBLY fast. > > The interesting thing for me recently was that they've built an > implementation of Ruby on top of it, and called it MagLev, and it's now > possible to have persisted, fast, pure object-oriented data store in Ruby > and/or Rails applications... and as we know, there's an implementation of > O/Meta for Ruby... ;-) > > Julian. > > On 22/06/2011, at 4:58 AM, Steve Wart wrote: > >> Also of interest might be GemStone/S, an ODBMS that is still heavily >> used in at least two large Investment Banks (JP Morgan and UBS), as >> well as several large shipping companies (OOCL, Coscon, and NYK). >> Marketing blurb here >> http://seaside.gemstone.com/docs/OOCL_SuccessStory.pdf >> >> Basically it's an environment that replaces the limitations of SQL >> with the limitations of Smalltalk. It's interesting that the debate >> about O/R mapping is still stuck in the same place it was in 1990. >> After all these years I still think it would be easier to implement >> relational semantics on top of this sort of environment than >> vice-versa, but last time I checked Oracle and Microsoft weren't >> taking my calls. >> >> This paper is kind of old, but it describes the implementation of a >> DBMS inspired by the description of Smalltalk in the famous 1981 issue >> of Byte magazine. >> >> http://portal.acm.org/citation.cfm?id=602300 >> >> Making smalltalk a database system >> >> To overcome limitations in the modeling power of existing database >> systems and provide a better tool for database application >> programming, Servio Logic Corporation is developing a computer system >> to support a set-theoretic data model in an object-oriented >> programming environment We recount the problems with existing models >> and database systems We then show how features of Smalltalk, such such >> as operational semantics, its type hierarchy, entity identity and the >> merging of programming and data language, solve many of those problems >> Nest we consider what Smalltalk lacks as a database system secondary >> storage management, a declarative semantics, concurrency, past states >> To address these shortcomings, we needed a formal data model We >> introduce the GemStone data model, and show how it helps to define >> path expressions, a declarative semantics and object history in the >> OPAL language We summarize similar approaches, and give a brief >> overview of the GemStone system implementation >> >> Cheers, >> Steve >> >> On Tue, Jun 21, 2011 at 11:38 AM, Max OrHai <[email protected]> wrote: >>> There are certainly practical differences between "conventional" relational >>> databases and hierarchical filesystems, without having to get into >>> implementation details. I'm sure at least a few people on this list are >>> familiar with the BeOS filesystem, which acted much more like a relational >>> DBMS than most filesystems do... over a decade later, we've now got >>> hacked-on DBMS-like functionality in the form of (e.g.) Spotlight, but most >>> users are stuck with the little walled-off databases presented by their >>> media library and email application software. Once again, it's not a >>> technical issue so much as a matter of perspective. >>> http://www.theregister.co.uk/2002/03/29/windows_on_a_database_sliced/ >>> -- Max >>> >>> On Mon, Jun 20, 2011 at 11:31 PM, BGB <[email protected]> wrote: >>>> >>>> On 6/20/2011 9:19 PM, Julian Leviston wrote: >>>>> >>>>> Hi... (see below)... >>>>> >>>>> On 21/06/2011, at 3:42 AM, BGB wrote: >>>>> >>>>>> On 6/20/2011 3:22 AM, Julian Leviston wrote: >>>>>>> >>>>>>> On 20/06/2011, at 8:06 PM, BGB wrote: >>>>>>> >>>>>>>> hmm... S-Expression database?... >>>>>>>> sort of like a hybrid between a database and a persistent store. >>>>>>>> >>>>>>>> >>>>>>>> or such... >>>>>>> >>>>>>> I'd like to know if you think there's a difference between a filesystem >>>>>>> and a database... conceptually... >>>>>>> >>>>>>> or such... >>>>>> >>>>>> interesting thought... >>>>>> >>>>> Note that I asked if you think there's a difference not how they differ. >>>>> I'd be surprised if there were any people on this list who didn't know how >>>>> they differed. >>>>> >>>>> I don't consider there to be much of a difference between the two, >>>>> conceptually - they are both concerned with the retrieval and storage of >>>>> data (I'm using the term 'data' here to mean any form of raw information >>>>> at >>>>> all, useful or otherwise, including programs). >>>>> >>>> >>>> (I got sidetracked and forgot to answer earlier...). >>>> >>>> >>>> but, well, I consider them as different, as they serve different roles... >>>> >>>> filesystems serve a very narrowly defined role, so possible variation is >>>> limited before one risks compromising compatibility with existing software >>>> (both WRT removing features, or adding too many fundamentally new ones). >>>> compromising this compatibility would also severely compromise the general >>>> usability of the system. >>>> >>>> >>>> however, one could argue that filesystems are probably a fairly narrowly >>>> defined subset of databases, so in this sense there is overlap. >>>> >>>> for example, humans are mammals, but not all mammals are humans (tigers >>>> aren't hosting TV shows, there are no cities of bears, elephants aren't >>>> doing construction work, ...). >>>> >>>> so, it seems a similar level of difference... >>>> >>>> >>>> >>>> _______________________________________________ >>>> fonc mailing list >>>> [email protected] >>>> http://vpri.org/mailman/listinfo/fonc >>> >>> >>> _______________________________________________ >>> fonc mailing list >>> [email protected] >>> http://vpri.org/mailman/listinfo/fonc >>> >>> >> >> _______________________________________________ >> fonc mailing list >> [email protected] >> http://vpri.org/mailman/listinfo/fonc > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
