Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Table Oriented Programming (2002)

web.archive.org

Post reply on HN
Print view View original

21–30 of 91 posts

Re: Table Oriented Programming (2002)

#21

Post by marcosdumay »

naasking wrote: post #17
gpderetta wrote: post #9

My wish-list for my ideal (non-system) programming language: - first class tables and named tuples as the primary datastructure. Includes the full set of relational operations, and transaction support. Optional persistence. Everything is not a table though. Tables are great but pragmatism trumps dogmatism. - structural typing (ties neatly with the above) and support for row polymorphism - shared nothing, distributed,…

I'm no longer convinced of the need for row or record polymorphism. It encourages passing around types that have no clear domain or purpose, so I think it inhibits understanding in general. Do you have any examples where it's indispensable?

Nothing is indispensable as long as you have a Turing complete language. That is a really bad mindset to use.

Anyway, are you complaining that the types are abstract? (That is as bad a complaint as it sounds.) Or do you have something different in mind?

Re: Table Oriented Programming (2002)

#22

Post by nine_k »

jasode wrote: post #5

I remember reading this essay when it first came out. To try and reword it using modern terms: The author wishes that programming languages had database persistence capabilities as 1st-class built-in syntax instead of cumbersome bolted-on API functions. Examples where database syntax (i.e. SQL syntax) is 1st-class without noisy syntax of function calls, without command strings in quotes, etc : - business languages li…

Such tools existed and were popular in 1990s: DBase, Clipper, FoxPro.

They worked pretty well in their domain: data entry and report generation, with lightweight transaction processing and general computation.

Then happened the internet and client-server architectures, and these do not map as neatly onto local, single-user, single-transaction tables.

Re: Table Oriented Programming (2002)

#23

Post by gpderetta »

naasking wrote: post #17
gpderetta wrote: post #9

My wish-list for my ideal (non-system) programming language: - first class tables and named tuples as the primary datastructure. Includes the full set of relational operations, and transaction support. Optional persistence. Everything is not a table though. Tables are great but pragmatism trumps dogmatism. - structural typing (ties neatly with the above) and support for row polymorphism - shared nothing, distributed,…

I'm no longer convinced of the need for row or record polymorphism. It encourages passing around types that have no clear domain or purpose, so I think it inhibits understanding in general. Do you have any examples where it's indispensable?

I don't think it is indispensable, I think it is convenient and still better than what is done today were types without clear domain and purpose are already passed around.

At the very least with row polymorphism, a function can declare which subset of the type it actually care about instead of taking an unwanted dependency on the whole blob.

In particular I'm considering the scenario were a large application (or better a collection of applications) evolve without a central plan and messages tend to grow to accommodate orthogonal requirements (the alternative is splitting the messages, but it has performance, complexity and organizational overhead).

In theory the alternative is message inheritance, but in my experience it has never worked well and it is very hard to retrofit anyway.

Re: Table Oriented Programming (2002)

#24

Post by gpderetta »

jasode wrote: post #5

I remember reading this essay when it first came out. To try and reword it using modern terms: The author wishes that programming languages had database persistence capabilities as 1st-class built-in syntax instead of cumbersome bolted-on API functions. Examples where database syntax (i.e. SQL syntax) is 1st-class without noisy syntax of function calls, without command strings in quotes, etc : - business languages li…

The K language of kdb also count, but being proprietary and having a fairly impenetrable and alien syntax haven't helped it branching out of the niche where it is very successfully.

Re: Table Oriented Programming (2002)

#25

Post by scotty79 »

> Fundamental and Consistent Collection Operations

I recently discovered that Scala collection library was designed with this exact goal in mind.

Interface of collections is highly consistent between various types and you can create custom collections using the same interface with very little custom code.

I found this very insightful https://docs.scala-lang.org/overviews/core/architecture-of-s...

Slick library pretty much turns database access into first class part of the Scala through this collections api

https://scala-slick.org/doc/3.3.3/introduction.html#what-is-...

Re: Table Oriented Programming (2002)

#26

Post by chrisaycock »

rscho wrote: post #20
chrisaycock wrote: post #16

Earlier quoted context omitted.

Missing and poorly formatted input is given a type-specific value. Eg., Float64 is nan and Int64 is nil. >>> Int64("5") 5 >>> Int64("5b") nil If inferencing cannot determine a consistent type from a CSV file, then the column will just be a String. I don't know what you mean by "embedding" a Dataframe.

On the website you linked: "Embedding Dataframes into an existing language would not be possible." I don't think it would be an issue for languages with good metaprogramming facilities.

Ah, I see what you're referring to.

The hardest thing is the load() function, particularly in the REPL. It looks dynamic, but is actually static. Pulling off this slight-of-hand requires both type providers and automatic compile-time function evaluation on arbitrary expressions.

F# is the only other language I know of that has type providers. They invented it.

As for CTFE, languages like Zig and D require the user to indicate when to evaluate something ahead of time. I wanted this to happen automatically and still be available for compound expressions, user-defined functions, user-defined types, etc. Doing that requires tracking purity (no state or IO) in an expression, plus a mechanism to actually do the evaluation. I've never seen a language take it to the extreme that Empirical does.

So an existing statically typed language would need (1) a REPL interface, (2) purity tracking, (3) compile-time function evaluation, (4) some kind of types-as-parameters setup, and (5) array notation. Most existing statically typed languages don't have a REPL; the ones that do generally lack array notation. I couldn't find a language that did all of that plus type providers and automated CTFE on arbitrary expressions.

Hence, I had to create my own language.

Re: Table Oriented Programming (2002)

#27

Post by bob1029 »

We do a thing where we project all of the domain state (i.e. for a given user's session/work) into an in-memory database and then execute the business's SQL queries against it in order to determine logical outcomes.

I wouldn't really call it low/no code, since developing effective queries is non-trivial for many cases, but it does make it much more feasible for a non-developer to add incremental value to our product.

Re: Table Oriented Programming (2002)

#28

Post by naasking »

gpderetta wrote: post #23
naasking wrote: post #17

Earlier quoted context omitted.

I'm no longer convinced of the need for row or record polymorphism. It encourages passing around types that have no clear domain or purpose, so I think it inhibits understanding in general. Do you have any examples where it's indispensable?

I don't think it is indispensable, I think it is convenient and still better than what is done today were types without clear domain and purpose are already passed around. At the very least with row polymorphism, a function can declare which subset of the type it actually care about instead of taking an unwanted dependency on the whole blob. In particular I'm considering the scenario were a large application (or bett…

> At the very least with row polymorphism, a function can declare which subset of the type it actually care about instead of taking an unwanted dependency on the whole blob.

This is the argument I no longer find convincing. Do you have an example where this is so much clearer than alternate, simpler ways of doing it?

For instance, in principle you could easily rewrite a function that works on a record with 3 fields to just accept 3 parameters. The only additional "burden" is that the caller has to pass in those 3 fields, where before they could just pass in the record.

Re: Table Oriented Programming (2002)

#29

Post by agumonkey »

jasode wrote: post #5

I remember reading this essay when it first came out. To try and reword it using modern terms: The author wishes that programming languages had database persistence capabilities as 1st-class built-in syntax instead of cumbersome bolted-on API functions. Examples where database syntax (i.e. SQL syntax) is 1st-class without noisy syntax of function calls, without command strings in quotes, etc : - business languages li…

Didn't pascal have a way to persist/reload records. Not SQL-like but still something.

Also it's interesting you mention cobol. It really was a cool feature.

Re: Table Oriented Programming (2002)

#30

Post by civilized »

jasode wrote: post #5

I remember reading this essay when it first came out. To try and reword it using modern terms: The author wishes that programming languages had database persistence capabilities as 1st-class built-in syntax instead of cumbersome bolted-on API functions. Examples where database syntax (i.e. SQL syntax) is 1st-class without noisy syntax of function calls, without command strings in quotes, etc : - business languages li…

> I remember reading this essay when it first came out. To try and reword it using modern terms: The author wishes that programming languages had database persistence capabilities as 1st-class built-in syntax instead of cumbersome bolted-on API functions.

This reminds me of M/MUMPS, used by Epic to power the biggest EHR system by market share in the US.

Perhaps the big difference is that the M "database" is key-value structured. True tables are flat and do not distinguish part of the tuple as the "key" and part as the "value".

I wonder if this is the source of the oft-discussed "mismatch" between the programmer's model of data and the relational model of data. Programmers like to assign values to things, while relational DBs like to do CRUD operations on records. (This is sometimes called the "object-relational impedance mismatch" but I've always found this term silly - needlessly jargon-laden and scoped overly narrowly to the OO paradigm.)

There's clearly some kind of "isomorphism" or translation between the two models, but they're not quite the same.

Is this what ORMs are about? Translating between the programmer model of data and the relational DB model?

Post reply on HN