Re: introductions, ideas

>   What's everyone else thinking?

welcome to the list!

definitely interested in minimalist and effective C libs. great to hear youre interested and experienced here. i think its the missing link needed to eliminate ORMS and SQL engines for the other ~2% of cases.

ive found for the vast majority (~98%) of (my, and client) apps (stuff like mail browsing, blog hosting, multi-source aggregation and merging, bug trackers, eg anything Rails apps typically do), RDF-platform beasts (in compile-time, memory use, configuration time, JVM requirements) like Virtuoso or Sesame are unnecessary, as is the typical SQL-ORM cocktail of AST->AST transforms, buffered network client communication, remote deemon reparsing, execution, serialization, original ORM client parsing and object/value creation, in light of vfs triple schemae queried via universally-available stdlib offerings.


i wouldnt mind agreeing on a spec for filesystem layout so RDF can be shared amongst different libs via tar/AFS/git/SCP/fuse and 39 years of other tools that can do one thing and do it well for the VFS

i currently use Ruby for all my RDF needs (in the process of reading Okasaki's DS book and proably going to write a better query engine in Haskell, rather than Ruby coupled with annoying, implementation-specific and fragile FFI/C-bindings). i push changes to :element on repo.or.cz. i like to refactor and sometimes regret deleting over a year of history, since it would be an interesting documentatin of evolving a ruby API for working with RDF.


> [1] http://www.clickcaster.com/items/so-how-s-about-that-metaprogramming

 
- good news is these (pretty (browsing/query DSLs) are very simple to implement in Ruby or JS (among others)
- bad news is how their flexibility (and looks) are dictated by the language's evaluation strategy and syntax (unless youre just writing out a string to fire over the network to the _real_ engine, with its own DSL. i'm talking about eliminating all the steps mentioned in paragraph 2). at least you need nice list comprehension and the ability to mix and match evaluation strategies (Standard ML with Lazy annotations, or Haskell with strict annotations, etc). which leaves Ruby out in the cold on both counts. otherwise youre dropping down to rewriting to get around these deficiencies (Which isnt a huge cost, but something i wont personally write, as i have nothing staked on Ruby or promoting SQL daemons or hosted AMZN/GOOG Sequoia/Benchmark-stealth borg-DBs or whatever) and am a client of the 'suckless' philosophy.


i encourage you heartily with your C lib to handle the grunt pattern intersection work. i'd be happy to try it out and write adaptors to other libs, too.


for the 98% of normal needs (distributing computation back to the workgroups and out of the google borgbrain) im finding even slow-ass ruby is enough, doing everything inline. since most people just want the most recent instances of a particular class sorted by date, not ad-hoc complicated SPARQL on DBPedia dataset. but for fun i want to be able to do that in half a second using only a single language and the VFS. and thats certainly not going to happen with Ruby (prove me wrong!)..


>
> Cheers,


C
> J.
>

Received on Monday, 11 February 2008 06:27:28 UTC