Object oriented programming language native to EAV

[sergei....@gmail.com]

A project dedicated to a nested key-value pair programming language native to the Entity Attribute Value database schema. The environment is a Relational Database Management System specifically Postgres 9. Wholly implemented with Procedural SQL. Employs key-value translator vernacular to the EAV data model. Stores data objects, object metadata definitions and program code. Programs are executed with SQL commands. Has characteristics of a column-oriented database.

http://sproutpl.wordpress.com/

[Roy Hann]

sergei....@gmail.com wrote:

> A project dedicated to a nested key-value pair programming language native to the Entity Attribute Value database schema. The environment is a Relational Database Management System specifically Postgres 9. Wholly implemented with Procedural SQL. Employs key-value translator vernacular to the EAV data model. Stores data objects, object metadata definitions and program code. Programs are executed with SQL commands. Has characteristics of a column-oriented database.
>
> http://sproutpl.wordpress.com/

Are you back with this again Sergei?!

Are you invincibly stupid?

--
Roy

[sergei....@gmail.com]

>
> Are you back with this again Sergei?!
>
>
>
> Are you invincibly stupid?
>
>
>
> --
>
> Roy

I posted a topic about an object oriented programming language built with RDBMS. There is a link to articles about memory allocation, call stack management and other subjects relevant to making a programming language. You may choose to post flames, Roy and I'll call it your freedoms so don't let me stop you.


Here is the link again: http://sproutpl.wordpress.com

[Roy Hann]

sergei....@gmail.com wrote:

>>
>> Are you back with this again Sergei?!
>>
>>
>>
>> Are you invincibly stupid?
>>
>>
>>
>> --
>>
>> Roy
>
>
>
> I posted a topic about an object oriented programming language built
> with RDBMS. There is a link to articles about memory allocation, call
> stack management and other subjects relevant to making a programming
> language. You may choose to post flames, Roy and I'll call it your
> freedoms so don't let me stop you.

That's really generous of you, but instead of playing the suffering,
misunderstood genius, tell us why the well understood and thoroughly
tested solutions to data management problems are so incomprehensible to
you that EAV seems like the answer.

--
Roy

[sergei....@gmail.com]

Turns out EAV provides effective means for storing and managing program code, call stack and addressing. It is there to enable the language translator.

Sergei.

[Evgeniy Grigoriev]

zadornov skazal "kakie zhe oni tupie". U menya v sosedney gruppe "comp.database.theory" vetka, gda i predlagay im posmotret realno rabotayushiy prototip SUBD, polnostuy obyedinyaushiy OO i RM. Ya ne sprashivayu pravilno ili net. Net, korchat iz sebya znatokov, uhodyat v debry, zayavlyaut, chto eto nevosmozhno. Blin, nu ty posmotri, glaza razuy, pered tem kak govorit' chto eto nevosmozhno. Nu raz chelovek zayavlyaet, chto on eto sdelal, navernor on v etom ponimat chto to, i vozmozhno luchshe tebya.

Hi from Moscow :)

[sergei....@gmail.com]

Задоронов видимо прав :(

[Ed Prochak]

EAV as the storage for executing code?! Why?

What kind of problems would this programming language solve? It better be highly efficient because even the best algorithms programmed in it are going to be SLOW.

[sergei....@gmail.com]

It extends DBMS procedural language with object oriented programming features. So far I do not see that it is slow. EAV stores program code and is used to retrieve program call stack.

[Ed Prochak]

On Friday, May 3, 2013 9:22:55 AM UTC-4, sergei....@gmail.com wrote:
> It extends DBMS procedural language with object oriented programming features.

Well, so did C++ (extend a procedural language with OOP features). so nothing related to EAV here.

> So far I do not see that it is slow. EAV stores program code and is
> used to retrieve program call stack.

You say you don't see it as slow, but have you run any benchmarks?

Is this a RAM based DBMS? Otherwise it has to be slower than normal programming which executes from RAM.

Sounds a little like emulating content addressable memory. An interesting idea, but not likely to solve many problems.

[Roy Hann]

Ed Prochak wrote:

> Sounds a little like emulating content addressable memory.

Ignore him. He's isn't even a retard.

--
Roy

[sergei....@gmail.com]

> Well, so did C++ (extend a procedural language with OOP features). so nothing related to EAV here.
>

My language is translated by standard SQL/PSM (Persistent Stored Modules) which is native to a DBMS. It is not a language add-on.

Furthermore all program code is stored as nested key-value pairs in normal form, inside database tables. It is an EAV schema that stores either sets of single node values such as program code, structured documents, xml, html, rdf, etc., or EAV database tables.

> You say you don't see it as slow, but have you run any benchmarks?
>

I will have benchmarks later because the prototype is not yet fully optimized. I have tons of work there in development.

> Is this a RAM based DBMS? Otherwise it has to be slower than normal programming which executes from RAM.
>

Short answer is no, although CAM microchips is something I research in context of this language. There may be possibilities there.

> Sounds a little like emulating content addressable memory. An interesting idea, but not likely to solve many problems.

Column-level locking in INSERT statements in content addressable memory may shed light onto possibilities of solving a problem or two. Immediate goals are more down to earth though.

[sergei....@gmail.com]

Hello Roy,


Invincibly :) sorry took so long to get back, project finally under way since less than two months ago.

You may finally see it at http://visualdatasynthesis.com


The Gui will expand a lot, and server side is still in development. So check back to the website soon again! :)