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

61–70 of 91 posts

Re: Table Oriented Programming (2002)

#61

Post by Groxx »

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…

Rust has rather sophisticated macros, which let you do stuff like this outside the core language implementation, which is IMO very much where such things belong.

E.g. a linq clone in rust can look like this: https://github.com/StardustDL/Linq-in-Rust

    linq!(from p in 1..100, where p

Re: Table Oriented Programming (2002)

#63

Post by DemocracyFTW »

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 provided for various items like dates ("99/99/99"), Social-Security-Numbers ("999-99-9999"), and so forth. (Input formats are not shown in our sample DD.) Types like dates and SSN's can be internally represented (stored) just fine with characters or possibly integers. For example, December 31, 1998 could be represented as "19981231". This provides a natural sort order.

This is very nineties and I must disagree. The datetime-as-string example shows it most clearly: wanting to sort by full date is only one thing you want to do with calendar data; often you will want to compare, say, things that happened on Mondays vs things that happened over the weekend, or things that happened within so-and-so many hours around a given point in time and so, not to mention the complexities of DST and timezones. You can do all that with text-based strings but you'd have to write quite a bit of logic that will get applied to strings over and over again, or else you can store the results of parsing a date string into separate fields. Dates expressed as text also don't allow you to validate "19990229" or "20020631" in a very straightforward manner.

I think our collective and by now decades-old experience with duck/weakly-typed languages like Python, JavaScript, Ruby and so on clearly shows that what you gain in simplicity you lose in terms of assured correctness.

Re: Table Oriented Programming (2002)

#64

Post by WalterBright »

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.

Re: Table Oriented Programming (2002)

#66

Post by int_19h »

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.

Not as any kind of standard, or even a popular extension.

Microsoft BASIC implementations for DOS however had ISAM in some of the editions (PDS and VB for DOS) which were similar: you'd declare a struct type, and then open a file with that type as the record type.

Re: Table Oriented Programming (2002)

#67

Post by badsectoracula »

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.

Pascal's records are basically like C's structs: you can use them to make a database (and many did) but there isn't any real support from the language, though some implementations may have had their own extensions since the original Wirth Pascal had no support for files at all and the standard had some very limited support.

Re: Table Oriented Programming (2002)

#68

Post by int_19h »

naasking wrote: post #28
gpderetta wrote: post #23

Earlier quoted context omitted.

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 t…

Having it as a single parameter precludes the mistake of passing unrelated values, though.

Re: Table Oriented Programming (2002)

#70

Post by badsectoracula »

nine_k wrote: post #22
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.

I have a ton of games, bought or downloaded from a variety of places, some even for different systems and some more than once (e.g. Steam or GOG or sometimes some Humble Bundle bundle giving a game i already had) and in some cases a different version. Most of them are on my external HDD.

One thing i want to do is to make a database of all of them since they're easily more than a thousand and i want it on my PC. I want to be able to have a title, description, tags, screenshots, overall category, target platform info, links to the setup/archive files, the versions i have, extras like wallpapers, ringtones, music or even perhaps any box pictures or ads if they are available (some sites like Zoom Platform do provide those with the games you buy), reviews, patches (official and unofficial), links to folders with any mods i might have, etc.

This sounds like something that back in the day would be perfect for dBase or Fox Pro, except for the part where i want it to be graphical (remember: i want screenshots, wallpapers, etc). But if those were made with a GUI in mind, i'd expect them to be perfect. So basically, i think Access would be it. But AFAIK Access is now dying, last time i checked the UI it seemed like a massive downgrade compared to what i remember from when i first saw it back in Access 97 days (look, some stuff really work better with nested windows / MDI applications - having a two field form or 5 field table take up the entire available application space when 90% of is empty space makes no sense when you could have a bunch of windows with those things visible at the same time). And it is limited on Windows and TBH it looks like a massive program anyway.

Some alternatives mentioned are too much "programming" and not enough "database-ing" IMO. Ideally i should only need to bother with code to cover for any missing functionality not provided by the GUI but most of the DB and UI design (for the forms, etc) and ideally most simple behavioral stuff should be done from the GUI without using any code.

But i don't think there is anything really like that and the modern computing world feels way too "incompatible" with what i have in mind - e.g. whenever i mention this to some friends of mine they start thinking in terms of wiring together stuff like SQLite (or even worse, PostgreSQL), Python/PHP/whatever, some web-based framework, etc and other "mass-of-unrelated-software-held-together-by-duct-tape" solutions, when what i really want is a completely self contained program with no external dependencies (aside from the basic stuff for showing a GUI, etc, i mean not requiring stuff like setting up a PostgreSQL DB), no servers, etc, just a binary/EXE, saving the DB somewhere on the filesystem (ideally in a single file like Access so it is easy to copy/backup/pass around), being able to interact with the rest of the OS (remember that bit about keeping track of setup programs / archives /etc ? I'd like being able to run those directly from the DB GUI), etc.

Well, one of the 28378423 things i want to work on at some point in the future. Hopefully those life extension studies that are posted on HN now and then will eventually move on from rats :-P

Post reply on HN