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

81–90 of 91 posts

Re: Table Oriented Programming (2002)

#81

Post by mikewarot »

agumonkey wrote: post #29
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.

I wrote CRUD apps that did this in Turbo Pascal back in the days of MS-DOS. I copied the idea of screen fields that I had seen in DBASE II, and make a set of field editors for each record type, I could put together a database pretty darned quick back in the day.

Re: Table Oriented Programming (2002)

#82

Post by timemachine »

teleforce wrote: post #74

Just wondering about the meaning of the satements from the article "Arrays are evil! Arrays are the Goto of the collections world". Anyone know exactly what it means? Is it referring to the raw array with pointers in C/C++ or array in C++ collections?

I took the meaning as: Array processing can cause hidden bugs (like GOTO). The bugs are usually introduced when the size of the array changes while processing.

Also ‘find’ing and ‘filter’ing arrays is more error prone (like not properly handling a miss on a find).

I don’t completely agree with the author, but the idea that more care needs taken when dealing with arrays is worth considering.

Arrays will always have important uses. Tuples, enumerations, and the like. However, ‘n’ database records shoved into an array and then iterated over in a for-loop is a cumbersome way to structure a program.

That’s my take on it.

Re: Table Oriented Programming (2002)

#83

Post by DemocracyFTW »

WalterBright wrote: post #64
DemocracyFTW wrote: post #63

The proliferation of field types has made data more difficult to transfer or share data between different applications and generates confusion. ITOP has only two fundamental data types: numeric and character, and perhaps a byte type for conversion purposes. (I have been kicking around ideas for having only one type.) The pre- and post-validators give any special handling needed by the field. A format string can be pr…

The way to deal with dates is not by having separate fields. It's by having a single value represent the time (in Linux it's time_t). Every other format gets translated to time_t, all processing is done with time_t, and then the time_t gets translated to the desired output format. Any other scheme is doomed to working 99% of the time, and that last 1% will be impossible to fix.

This is of course exactly what I've been meaning to say here. We want more specific datatypes (e.g. a true date(time) ADT) with better functionality (say interval computation) and constraint checking (AKA domains, such as 'let n be an even, positive integer gt zero').

Re: Table Oriented Programming (2002)

#84

Post by tluyben2 »

gpderetta wrote: post #40
xwolfi wrote: post #36

Earlier quoted context omitted.

Isn't Q the language, and Kx the company ? I have to use it at work, helping quants try to actually maintain production code rather than just vomit horrible one-time scripts they patch together in an endless stream of layers on top of layers. This thing should be banned. Everything is one-letter, it's impossible to Google, it takes the opposite decision of every imaginable convention, I have yet to see someone who ca…

You are right. As far as I understand Q is K plus the additional sql-like syntax. And yes, it is nigh-unreadable. I have yet to learn it, but I think there is value in succinctness at least for throwaway scripts.

If you use k a lot, you start to automatically recognize idioms/stanzas; it just becomes automatic to recognize a group of chars. And then it becomes readable. The throwaway nature, in my experience and opinion, comes not from it being unreadable (as many people who never used languages like this seem to think), but rather from the fact that the code you are are changing is so short that thinking it up and typing it in (by combining idioms) is faster than placing your cursor and actually editing existing code. Also you are on a repl or editor that can run code on the cursor, so interactive development even makes that case stronger: before you know it, you have produced a new version of a function without actually even looking at the old one.

For a nice intro, read Nils' excellent book: https://www.t3x.org/klong/book.html it even has an idioms table in the back.

Re: Table Oriented Programming (2002)

#85

Post by tluyben2 »

beagle3 wrote: post #60
rak1507 wrote: post #59

Earlier quoted context omitted.

Why is it still used then? Are there just no good alternatives? Or legacy reasons?

On the things it does well - being a memory mapped column store, it hardly had any competition a few years ago (clickhouse might be getting there these days, perhaps) And if your fluent in K, one-of scripts and queries are significantly shorter and easier to get right. But it is not good as a general purpose language in a commercial setting - not because of the language itself which is fine if a bit spartan - but bec…

I think many people would work in it, but the job market for it is limited and driven by who knows who as far as I noticed. I hope Shakti will make things better: so far it's nice and definitely it's pricepoint is a lot better. Not sure where it will go.

Re: Table Oriented Programming (2002)

#86

Post by tluyben2 »

xwolfi wrote: post #36
gpderetta wrote: post #24

Earlier quoted context omitted.

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.

Isn't Q the language, and Kx the company ? I have to use it at work, helping quants try to actually maintain production code rather than just vomit horrible one-time scripts they patch together in an endless stream of layers on top of layers. This thing should be banned. Everything is one-letter, it's impossible to Google, it takes the opposite decision of every imaginable convention, I have yet to see someone who ca…

> but they all feel like geniuses spending weeks on simple stuff on kdb

They are not experienced in the environment then? It is not that hard. Sure it is spartan as the tooling is not what you expect in 2021, but this seems a bit over the top?

> I have yet to see someone who can read his own stuff 2 weeks

http://nsl.com/ can, years later even (as can I but he has an impressive portfolio which makes it obvious).

Re: Table Oriented Programming (2002)

#87

Post by rak1507 »

tluyben2 wrote: post #85
beagle3 wrote: post #60

Earlier quoted context omitted.

On the things it does well - being a memory mapped column store, it hardly had any competition a few years ago (clickhouse might be getting there these days, perhaps) And if your fluent in K, one-of scripts and queries are significantly shorter and easier to get right. But it is not good as a general purpose language in a commercial setting - not because of the language itself which is fine if a bit spartan - but bec…

I think many people would work in it, but the job market for it is limited and driven by who knows who as far as I noticed. I hope Shakti will make things better: so far it's nice and definitely it's pricepoint is a lot better. Not sure where it will go.

How do you know the price point is better? It's not on the website. Are you a customer?

Re: Table Oriented Programming (2002)

#88

Post by mwexler »

jasode wrote: post #19
mwexler wrote: post #14

Earlier quoted context omitted.

I think you are missing the big twist. It's not just tables as 1st class citizens, but allowing logic to be driven by the tables. Instead of config files, you update the table. Changes to the processing flow? Update the table, including dates for when the new rules apply. The tables held code which drove the processing, along with tables holding data. It's not just orm or persistence, and not just programming in the…

>, but allowing logic to be driven by the tables. Instead of config files, you update the table. Changes to the processing flow? Update the table, [...] I didn't miss that angle and I think it's actually a minor part of his thesis. If you look at the entire essay, the vast majority of his bullet points and supporting examples are mostly about ergonomics of builtin syntax to manipulate tables . If his ideal _language_…

Well put. SAP is the big survivor from that mindset. And perhaps the best example of why we won't see another. :-)

Re: Table Oriented Programming (2002)

#89

Post by srcreigh »

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…

Racket has a first class SQL query DSL. [0]

With some kinda dynamic naming system, you could probably load SQLite table schemas at runtime and provide bindings to columns automatically. Or maybe that's best done once at the compile step. Either is possible with racket :-)

[0]: https://docs.racket-lang.org/sql/index.html

Re: Table Oriented Programming (2002)

#90

Post by CRConrad »

CRConrad wrote: post #56
nine_k wrote: post #22

Earlier quoted context omitted.

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.

> Such tools existed and were popular in 1990s: DBase, Clipper, FoxPro. Also Crystal Reports, Paradox... > They worked pretty well in their domain: data entry and report generation, with lightweight transaction processing and general computation. Having bought Ashton Tate, Borland got DBase and Interbase in addition to Paradox, and built data access components into the VCL class library (in effect "almost-first-class…

Duh, forgot to mention: "Fishbase" was based on a Paradox (IIRC; could have been DBase) file.

Edit: Also, for FP/Lazarus that's probably SQLite and newer RDBMSes not "in stead of" but in addition to the old file formats and RDBMSes.

Post reply on HN