Table based programming.

[Malcolm McLean]

I want this to be a serious, fruitful thread. Sabateurs will be plonked.

Table-based programming is a new paradigm, similar to object-orientation,
procedural decomposition, or functional programming.

The idea is that all the data in the program comes in "tables". A table
consists of records and fields, and is thus a 2d entry. Fields may be
numbers or strings, and have names, descriptors, prevalidation conditions
and postvalidation conditions, and the like.
Note that this means that each field in the table is described by a "data
dictionary" which is itself a table, with one record for each field.

Tables are completely transparent to disk caching, sharing, database
support, and the like. They can have tiny of massive numbers of records.

There are no other structures. Queues, stacks, trees and the like are things
that you do to tables, not the format that the table is in. The idea is
that, given a dictionary, you can write automatic editors, viewers, savers
and things like that. So most code can be reused. They are designed with
business applications in mind, but could be used more broadly.

Now obviously C is not a "table-based programming language" and has no build
in support. However paradigms are independent of the language they are
implemented in.

My question is, is it practical to design a "TABLE" library for C?

 

[Lothar Behrens]

I want this to be a serious, fruitful thread. Sabateurs will be plonked.

Table-based programming is a new paradigm, similar to object-orientation,
procedural decomposition, or functional programming.

The idea is that all the data in the program comes in "tables". A table
consists of records and fields, and is thus a 2d entry. Fields may be
numbers or strings, and have names, descriptors, prevalidation conditions
and postvalidation conditions, and the like.
Note that this means that each field in the table is described by a "data
dictionary" which is itself a table, with one record for each field.

Tables are completely transparent to disk caching, sharing, database
support, and the like. They can have tiny of massive numbers of records.

There are no other structures. Queues, stacks, trees and the like are things
that you do to tables, not the format that the table is in. The idea is
that, given a dictionary, you can write automatic editors, viewers, savers
and things like that. So most code can be reused. They are designed with
business applications in mind, but could be used more broadly.

Now obviously C is not a "table-based programming language" and has no build
in support. However paradigms are independent of the language they are
implemented in.

My question is, is it practical to design a "TABLE" library for C?

Hmm,

is it not simpler to use existing approaches for TABLE's used in C ?

There are many SQL implementation's that let you store all your data
in a / some table / tables.

Lothar

 

[Joe Wright]

I want this to be a serious, fruitful thread. Sabateurs will be plonked.

Table-based programming is a new paradigm, similar to
object-orientation, procedural decomposition, or functional programming.

The idea is that all the data in the program comes in "tables". A table
consists of records and fields, and is thus a 2d entry. Fields may be
numbers or strings, and have names, descriptors, prevalidation
conditions and postvalidation conditions, and the like.
Note that this means that each field in the table is described by a
"data dictionary" which is itself a table, with one record for each field.

Tables are completely transparent to disk caching, sharing, database
support, and the like. They can have tiny of massive numbers of records.

There are no other structures. Queues, stacks, trees and the like are
things that you do to tables, not the format that the table is in. The
idea is that, given a dictionary, you can write automatic editors,
viewers, savers and things like that. So most code can be reused. They
are designed with business applications in mind, but could be used more
broadly.

Now obviously C is not a "table-based programming language" and has no
build in support. However paradigms are independent of the language they
are implemented in.

My question is, is it practical to design a "TABLE" library for C?

Have you any experience with xBASE tables, usually .DBF files? They've
been around for nearly thirty years and are the basis for dBASE, FoxPro,
Clipper, xHarbour, et. al.

Practical or not, it is doable and perhaps interesting.

 

[jacob navia]

I want this to be a serious, fruitful thread. Sabateurs will be plonked.

Table-based programming is a new paradigm, similar to
object-orientation, procedural decomposition, or functional programming.

A Programming Language

APL.

In that computer language, proposed by Iverson, everything is a table.
As lisp treats lists, the table is the fundamental concept of APL.

Tables are inherently parallel, and well adapted to parallel processing.
I am preparing an adaptation of APL according to the ideas of
"SIMD programming for linux and windows" of Cockshott and Renfrew.

The idea is that all the data in the program comes in "tables". A table
consists of records and fields, and is thus a 2d entry. Fields may be
numbers or strings, and have names, descriptors, prevalidation
conditions and postvalidation conditions, and the like.
Note that this means that each field in the table is described by a
"data dictionary" which is itself a table, with one record for each field.

Tables can come in different dimensions.
Vectors are one dimensional, then you have 2, 3, 4 dimensional tables.

Tables can be "ragged" also, as you propose above. In that case we have
the pointer tables of C.

Tables are completely transparent to disk caching, sharing, database
support, and the like. They can have tiny of massive numbers of records.

In a VM system this can be done easily but I would suppose a RAM
based approach.

There are no other structures. Queues, stacks, trees and the like are
things that you do to tables, not the format that the table is in. The
idea is that, given a dictionary, you can write automatic editors,
viewers, savers and things like that. So most code can be reused. They
are designed with business applications in mind, but could be used more
broadly.

Now obviously C is not a "table-based programming language" and has no
build in support. However paradigms are independent of the language they
are implemented in.

My question is, is it practical to design a "TABLE" library for C?

I am doing it (slowly, because I am very much alone in this).

 

[CJ]

I am doing it (slowly, because I am very much alone in this).

Indeed you are. The life of a proprietary-software developer is a lonely
one, by his own choice.

 

[jacob navia]

Indeed you are. The life of a proprietary-software developer is a lonely
one, by his own choice.

Yes. I do not try to use the work of other people for my own benefit.
I am not like RedHat, /suse / and all other "free software" companies
that rely people that work for them for free.

 

[user923005]

I want this to be a serious, fruitful thread. Sabateurs will be plonked.

Table-based programming is a new paradigm, similar to object-orientation,
procedural decomposition, or functional programming.

The idea is that all the data in the program comes in "tables". A table
consists of records and fields, and is thus a 2d entry. Fields may be
numbers or strings, and have names, descriptors, prevalidation conditions
and postvalidation conditions, and the like.
Note that this means that each field in the table is described by a "data
dictionary" which is itself a table, with one record for each field.

Tables are completely transparent to disk caching, sharing, database
support, and the like. They can have tiny of massive numbers of records.

There are no other structures. Queues, stacks, trees and the like are things
that you do to tables, not the format that the table is in. The idea is
that, given a dictionary, you can write automatic editors, viewers, savers
and things like that. So most code can be reused. They are designed with
business applications in mind, but could be used more broadly.

Now obviously C is not a "table-based programming language" and has no build
in support. However paradigms are independent of the language they are
implemented in.

My question is, is it practical to design a "TABLE" library for C?

Sure, just interface to any SQL database. This paradigm literally
dates from the 1980's. It sounds like someone is trying to reinvent
it.
Look up "Date and Codd" (they guys who invented it).

 

[user923005]

Sure, just interface to any SQL database. This paradigm literally
dates from the 1980's.  It sounds like someone is trying to reinvent
it.
Look up "Date and Codd" (they guys who invented it).

Err...
Make that the 1970's:

[Date and Codd, 1974]
C. J. Date, E. F. Codd: The Relational and Network Approaches:
Comparison of the Application Programming Interfaces. SIGMOD Workshop,
Vol. 2 1974: 83-113 BibTeX

 

[Chris Dollin]

I want this to be a serious, fruitful thread. Sabateurs will be plonked.

Table-based programming is a new paradigm, similar to object-orientation,
procedural decomposition, or functional programming.

The idea is that all the data in the program comes in "tables". A table
consists of records and fields, and is thus a 2d entry. Fields may be
numbers or strings, and have names, descriptors, prevalidation conditions
and postvalidation conditions, and the like.
Note that this means that each field in the table is described by a "data
dictionary" which is itself a table, with one record for each field.

You appear to be reinventing relational databases and/or CSVs. Don't
do that. You might want to look at SQLite. For different reasons,
you might want to look at RDF. For yet other reasons, you might want
to look at (Ruby on) Rails, to see another way of coupling programs to
persistent relational data.

As for a C interface to tabular data, naturally you /can/ write such a
thing: proof by precedent.

 

[Malcolm McLean]

Malcolm McLean wrote:
You appear to be reinventing relational databases and/or CSVs. Don't
do that. You might want to look at SQLite. For different reasons,
you might want to look at RDF. For yet other reasons, you might want
to look at (Ruby on) Rails, to see another way of coupling programs to
persistent relational data.

It's not my invention. It seems to have been devised by business programmers
who are very familiar with database-driven systems, bascially as an
alternative to object-orientation.
http://www.geocities.com/tablizer/top.htm
Here's the link.

As for a C interface to tabular data, naturally you /can/ write such a
thing: proof by precedent.

You'll see that there's more to it than that, unless this guy is really just
wrapping a very simple idea in layers of unnecessary elaboration, which
might be the case. Part of the idea of this thread is to find out.

 

[Bart C]

It's not my invention. It seems to have been devised by business
programmers who are very familiar with database-driven systems, bascially
as an alternative to object-orientation.
http://www.geocities.com/tablizer/top.htm

I've tried hard but can't grasp the ideas. It needs some more complete
examples. One GUI example looks very much like an ordinary record. Another
actual table looked like an extract from a spreadsheet. There's the table,
but now what?

If he's talking about 'table-driven' techniques, that's nothing new.

OOP seems to be 'sold' much better: examples that make perfect sense (until
you get mired in the complications)

Perhaps 'business programmers' and 'C' don't mix.

Bart

 

[cr88192]

I want this to be a serious, fruitful thread. Sabateurs will be plonked.

Table-based programming is a new paradigm, similar to object-orientation,
procedural decomposition, or functional programming.

tables are something, but I don't expect them to be "that" fundamental...


what if someone else were to come along, and, say, propose spreadsheets as
the new fundamental way of organizing data?...

as one can quickly notice, a table and a spreadsheet are not exactly
equivalent...

The idea is that all the data in the program comes in "tables". A table
consists of records and fields, and is thus a 2d entry. Fields may be
numbers or strings, and have names, descriptors, prevalidation conditions
and postvalidation conditions, and the like.
Note that this means that each field in the table is described by a "data
dictionary" which is itself a table, with one record for each field.

Tables are completely transparent to disk caching, sharing, database
support, and the like. They can have tiny of massive numbers of records.

possibly, could be useful.
to what extent?
built in support for relational logic and the like at a language level could
be interesting (saves us from endlessly recreating them).

There are no other structures. Queues, stacks, trees and the like are
things that you do to tables, not the format that the table is in. The
idea is that, given a dictionary, you can write automatic editors,
viewers, savers and things like that. So most code can be reused. They are
designed with business applications in mind, but could be used more
broadly.

now, here is the issue:
about the time you limit what can be done in said language, you nearly
immediately give yourself little more than a toy.

that is a major reason why I don't personally expect to see "pure"
functional languages gaining much ground.
now, if more mainstream languages had a few more functional features, that
could be nice.
but, about as soon as one takes away things like assignment, one can't
expect too many people to go along with this.


what if, for example, we take away from the programmer, say, the programming
language, and instead give them a copy of MS Access and force them to start
implementing masses of forms?...

Now obviously C is not a "table-based programming language" and has no
build in support. However paradigms are independent of the language they
are implemented in.

but this does not mean they will come out nicely...

we can implement Prototype OO, Dynamic Typing, GC, and lexical binding
capture/closures in C, but does this mean you have transformed C into
JavaScript? no, it is by no means even close.

My question is, is it practical to design a "TABLE" library for C?

practical? probably.
useful? maybe.
something that will fundamentally change the coding experience? unlikely.

one first has to address how they will represent and interact with said
tables.
there are many tradeoffs, such as performance, usability, and flexibility.


for example, what if all the table structures are hard-coded?
then it can be fast and usable, but hardly flexible.

what if we have some approach based on manipulation of records represented
as raw data (lots of pointer ops and casts)?
then it can be fast and flexible, but hardly usable.

what if we have an opaque API, based on templating and name-based
field-access?
well, then it can be usable and flexible, but not very fast.

 

[SM Ryan]

#
# > Malcolm McLean wrote:
# > You appear to be reinventing relational databases and/or CSVs. Don't
# > do that. You might want to look at SQLite. For different reasons,
# > you might want to look at RDF. For yet other reasons, you might want
# > to look at (Ruby on) Rails, to see another way of coupling programs to
# > persistent relational data.
# >
# It's not my invention. It seems to have been devised by business programmers
# who are very familiar with database-driven systems, bascially as an

Actually it was invented in days of yore (late 1980s) when
people saw connections between OOP, RDBMS, and logic programming.
You can look up some old papers (they were still using English
way back then).

 

[CBFalconer]

You appear to be reinventing relational databases and/or CSVs.
Don't do that. You might want to look at SQLite. For different
reasons, you might want to look at RDF. For yet other reasons,
you might want to look at (Ruby on) Rails, to see another way of
coupling programs to persistent relational data.

As for a C interface to tabular data, naturally you /can/ write
such a thing: proof by precedent.

Malcolm might want to take a look at the sort of thing that can be
done with hashlib(.zip), written in pure standard C, and available
under GPL. Look at the usage examples in the zip distribution, and
also in id2id-20.zip. All is available at:

<http://cbfalconer.home.att.net/download/>

 

[Richard Bos]

I want this to be a serious, fruitful thread. Sabateurs will be plonked.

^^^^^^^^^
Are those people who make mackerel sushi?

Table-based programming is a new paradigm,

No, it bloody well isn't. It's at least well over a decade old. Also,
it's off-topic here unless you have specifics rather than vague
promises.

Richard

 

[Kelsey Bjarnason]

Yes. I do not try to use the work of other people for my own benefit.
I am not like RedHat, /suse / and all other "free software" companies
that rely people that work for them for free.

You really haven't got a clue how the open source world works, do you?

 

[David Thompson]

A Programming Language

APL.

In that computer language, proposed by Iverson, everything is a table.
As lisp treats lists, the table is the fundamental concept of APL.

Not quite. The fundamental structure in classic APL is the _array_
(although more recent versions have added some other options; 'recent'
in this context may be something like 1990). Arrays have one element
type across possibly multiple dimensions. (C's 'array' limited to one
dimension is a parochial and sometimes misleading restriction, and
might better have been called 'vector'. In fact, IIRC BCPL used the
keyword 'vec'.) Tables have possibly-different element types along
one dimension (columns, across) but not the other (rows, down).

(Nit: 'Lisp' should be at least initial-cap. Perhaps all-caps.)

Tables can come in different dimensions.
Vectors are one dimensional, then you have 2, 3, 4 dimensional tables.

Arrays.

As already noted, the common table-based language is SQL.

- formerly david.thompson1 || achar(64) || worldnet.att.net