[MrDosu]

I think the major problem with this approach is trying to solve the general Problem.

These graphical abstractions can be excellent when tailored to a domain. We are shipping a product right now that abstracts the database away through a little graphical graph editor like this one to transform it into the domain language of the people (non programmers) that are consuming the data.

It is quite excellent.

[nekopa]

Can you explain more, or even share your project? It sounds quite interesting.

[MrDosu]

Unfortunately I cannot share code.

It is actually quite simple. There is a graphical designer that connects to a data warehouse. There someone defines a graph like structure with nodes that contain a collection of data rows and relations to other nodes of data rows. This results in a library that you can interop with in existing software tools of the customer to query that graph model naturally (Stuff like Location('airport')=>Car('sedane')=>RentalHistory). It's basically a glorified ORM mapper with a graphical programming language for the codegen of the objects to produce a kind of data DSL.

[nekopa]

Thanks for the explanation, no worries about not being given able to share code.

You do make it sound simple, so therefore I will make a typical HN comment (god help my karma :) :

If you can abstract it away enough, make it SaaS, sounds like a startup idea!

[dman]

What is the domain in question? Have you run into issues where the power users who are non programmers want to do more programming like tasks over time to exert more control?

[MrDosu]

The domain is (non technical) government data analysts.

Yes we ran into this a lot with people wanting more control. There are several hooks and extension points in the software. Basically every graphical element has the equivalent of being replaced with an actual code file that you can substitute at runtime. This gets never used by the customer, usually we just provide extension libraries that abstract the concepts of whatever they want to do.