6 ms·

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 persi

by jasode 5y ago

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 like COBOL - programming languages in ERP systems like SAP ABAP, Oracle Financials - stored procedural languages inside the RDBMS engine such as T-SQL in MS SQL Server, PL/SQL in Oracle, sp in MySQL In the above, the "database" is the world the programming language is working in. The more general purpose programming languages like C++, Java, Javascript, Python omit db manipulation as a core language feature. This 2nd-class status requires 3rd-party libs, which means have extra ceremony syntax of #includes, imports, function calls with parentheses, etc. Some try to reduce the cumbersome syntax friction with ORMs. In contrast with something like SAP ABAP, the so-called "ORM" is already built in to process data tables without any friction. The author works a lot on CRUD apps so a language that has inherent db syntax would enable "Table-Oriented-Programming". But we can also twist the author's thesis around. A programmer is coding in SAP ABAP or a stored-procedure in MySQL and wonders why raw memory access where contiguous blocks of RAM can be changed with pointers is not easy to code in those languages. So an essay is written about advantages of "pointer-oriented-programming" because direct memory writes are really convenient for frame buffers in video games, etc. In any case, I don't see any trend where a general-purpose programming language will include DB SQL as 1st-class. Even the recent languages like Rust and Zig don't have basic SQLite3 db persistence as convenient built-in syntax. If anyone proposed to add such db syntax, they would most likely reject it.

BeFlatXIII 5y ago
Although it's not a relational database, MUMPS is another example of a language where there is nothing special whatsoever about manipulating the database compared to manipulating the same data but stored in a variable in RAM.
CRConrad 5y ago
> In any case, I don't see any trend where a general-purpose programming language will include DB SQL as 1st-class. Even the recent languages like Rust and Zig don't have basic SQLite3 db persistence as convenient built-in syntax. If anyone proposed to add such db syntax, they would most likely reject it. What poor old BottomFeeder missed was that with a good object library / framework, you can get so close that it almost doesn't matter. I tried to convince him to even try Delphi, with its marvellous TDataSet descendants in the VCL... But AFAIK he never even downloaded the free version I pointed him to, whatever it may have been called back then.
Groxx 5y ago
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 https://github.com/StardustDL/Linq-in-Rust linq!(from p in 1..100, where p <= &5, orderby -p, select p * 2).collect();
animal_spirits 5y ago
The "V" programming language has these features built in. https://github.com/vlang/v/blob/master/doc/docs.md#orm https://github.com/vlang/v/blob/master/doc/docs.md#orm
- duped 5y ago
  Does this doc misuse present tense or is it actually implemented? V's author has done this a bunch, so it's tough to take a doc at face value.
  - animal_spirits 5y ago
    I just copy+pasted the example given, it compiles and runs
srcreigh 5y ago
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 https://docs.racket-lang.org/sql/index.html
hdjjhhvvhga 5y ago
> In any case, I don't see any trend where a general-purpose programming language will include DB SQL as 1st-class. Which is a pity I'd say. The new languages you mention would benefit most from such a feature. I believe they won't do it not because it's not useful, but because it's difficult to make it right (efficient, safe, natural, scalable) and then maintain forever. There are many benefits of having this functionality working out of the box (and a few disadvantages, obviously). Many (if not most) apps are just CRUD apps with some added functionality. But a standard way of connecting the language to a database is still missing. The great success of the ActiveRecord back in the day shows that this is something many developers would benefit from (it was/is good, but still not ideal). And I don't believe patching the situation with a multitude of incompatible ORMs solves anything.
naasking 5y ago
> Examples where database syntax (i.e. SQL syntax) is 1st-class without noisy syntax of function calls, without command strings in quotes There more examples which I think qualify but don't quite fit into your categories: * The E language runs all code in "Vats", each of which is a single threaded compartment with transparent persistence. * Taking inspiration from E, the Waterken server did this for Java, but required annotating mutable fields in a certain way so the persistence layer could track them. * FoxPro doesn't neatly fit into your categories.
mwexler 5y ago
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 database as stored procedures. It was an odd melange of all of this. I ran into this in the 90s, and it was great for RAD. But it felt odd to have to code into tables, and each tool was proprietary such that moving off of the table system was a full rebuild. They usually allowed migration to new databases systems to scale, but that was all they had. I don't expect to see a language like this come around again anytime soon, but the ideas were really interesting in a world before git-ops and yaml configs.
- jasode 5y ago
  >, 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_ (aka the syntax) did that, it would naturally support table-oriented-programming (aka the philosophy). He starts the essay with critique of OOP-the-syntax. But to your point about config and code itself being persisted in the database, the SAP ABAP environment already works like that. SAP has over 10,000 db tables for configuration -- instead of YAML or JSON files. Change the values in the config tables to alter behavior instead of modifying IF/THEN/ENDIF statements in code. And when ABAP programmers hit "save", the code gets saved to a database table instead of a text file. So if one squints a certain way, the SAP system is a giant million-line stored procedure in the database.
  - mwexler 5y ago
    Well put. SAP is the big survivor from that mindset. And perhaps the best example of why we won't see another. :-)
ModernMech 5y ago
> In any case, I don't see any trend where a general-purpose programming language will include DB SQL as 1st-class. Even the recent languages like Rust and Zig don't have basic SQLite3 db persistence as convenient built-in syntax. There is a trend, but you’ll have to look further off the beaten path than even Zig to find it. Languages like Eve [0] tried to do this circa 2015 in the tradition of Datalog. Code was written in “blocks” that resembled Prolog horn clauses, but which featured set semantics on selected records. Natural joins happened automatically on records using identifiers. The whole language was actually a database! Eve died [1], but you’ll see many such projects that have the same ethos in communities in the web, such as this one [2]. There aren’t a lot of users of these languages, but this is where a lot of big ideas are percolating right now. And we can verify it’s a trend because the hallmark of all CS trends, the formation of a conference, has made itself known in this area [3]. 0: http://witheve.com/ http://witheve.com/ 1: https://groups.google.com/g/eve-talk/c/YFguOGkNrBo?pli=1 https://groups.google.com/g/eve-talk/c/YFguOGkNrBo?pli=1 2: https://futureofcoding.org/catalog/ https://futureofcoding.org/catalog/ 3: https://www.hytradboi.com/ https://www.hytradboi.com/
nine_k 5y ago
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.
- deleted 5y ago
  [deleted]
- CRConrad 5y ago
  > 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 citizens" of the language), which IMO made Delphi the natural and superior successor to those languages: Not just "lightweight", but fully advanced (i.e, ~C++-level) general computation. (And with transaction processing built into the RDBMS connection components.) > Then happened the internet and client-server architectures, and these do not map as neatly onto local, single-user, single-transaction tables. Weeelll... Seen the spate of recent posts on here about how SQLite is good enough for pretty much anything? :-) And arguably, that's where Delphi was at too, over twenty years ago: AFAICR, there was a "Fishbase" (facts about tropical fish) demo included with Delphi, which in one variant could be built as a standalone Web service / server. Also, AFAICS, that's where Free Pascal / Lazarus is at now, only using SQLite / Firebird / MySQL / PostgreSQL (and lots of other DBMSes) in stead of DBase / Clipper / FoxPro / Crystal Reports / Paradox. (I've been planning to look into that a bit closer myself, but haven't got around to it. Procrastinating away too much of my time on Hacker News, I suppose. :-( )
  - CRConrad 5y ago
    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.
gpderetta 5y ago
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.
- xwolfi 5y ago
  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 can read his own stuff 2 weeks later. Notwithstanding free tools to query force-expire every 3 months (QPad grrr) and as you said it's so closed they have to take webdevs like me to just help them maintain it all eventually. It's risky for the bank (and we're not a small one :s), it's expensive for the programmer, and it's misery for the quants (but they all feel like geniuses spending weeks on simple stuff on kdb, so their misery is only in people looking at them wasting away their brain like that).
  - rak1507 5y ago
    Why is it still used then? Are there just no good alternatives? Or legacy reasons?
    - beagle3 5y ago
      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 because it is hard to find people who are willing and able to work with it. Much like its predecessor APL, it’s a tool for thought more than a tool for implementation.
      - 5y ago
agumonkey 5y ago
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.
- badsectoracula 5y ago
  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.
- int_19h 5y ago
  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.
- mikewarot 5y ago
  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.
civilized 5y ago
> 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?
- CRConrad 5y ago
  > Is this what ORMs are about? Translating between the programmer model of data and the relational DB model? Pretty much, AFAICS. With varying degrees of success.
DenisM 5y ago
How about LINQ, in particular LINQ2SQL?
marcle 5y ago
Another relevant software category is the statistical analysis languages, including SAS, Stata and SPSS. Old-school SAS included only two data types (floats and character strings), but allowed for SQL and sequential data-steps to live together. Persistence was baked in. The floats could be used to represent dates, datetimes and other formats. I particularly appreciated being able to use macros to define a data-step view to split the follow-up for an individual from a table. Such a view could then be collapsed using SQL. More recently, R tools such as dplyr have brought together data-frames and relational operations. However, I miss the sequential coding in SAS, using macros as higher-level tools to define the logic, including corner cases. For strictly typed records, I have always wanted to spend more time with SML# [0] this allows for record updating, with close ties to SQL -- an under-appreciated version of SML. [0] https://github.com/smlsharp/smlsharp https://github.com/smlsharp/smlsharp

by jasode 5y ago

BeFlatXIII 5y ago

Although it's not a relational database, MUMPS is another example of a language where there is nothing special whatsoever about manipulating the database compared to manipulating the same data but stored in a variable in RAM.

CRConrad 5y ago

> In any case, I don't see any trend where a general-purpose programming language will include DB SQL as 1st-class. Even the recent languages like Rust and Zig don't have basic SQLite3 db persistence as convenient built-in syntax. If anyone proposed to add such db syntax, they would most likely reject it. What poor old BottomFeeder missed was that with a good object library / framework, you can get so close that it almost doesn't matter. I tried to convince him to even try Delphi, with its marvellous TDataSet descendants in the VCL... But AFAIK he never even downloaded the free version I pointed him to, whatever it may have been called back then.

Groxx 5y ago

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 https://github.com/StardustDL/Linq-in-Rust linq!(from p in 1..100, where p <= &5, orderby -p, select p * 2).collect();

animal_spirits 5y ago

The "V" programming language has these features built in. https://github.com/vlang/v/blob/master/doc/docs.md#orm https://github.com/vlang/v/blob/master/doc/docs.md#orm

duped 5y ago
Does this doc misuse present tense or is it actually implemented? V's author has done this a bunch, so it's tough to take a doc at face value.
- animal_spirits 5y ago
  I just copy+pasted the example given, it compiles and runs

srcreigh 5y ago

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 https://docs.racket-lang.org/sql/index.html

hdjjhhvvhga 5y ago

> In any case, I don't see any trend where a general-purpose programming language will include DB SQL as 1st-class. Which is a pity I'd say. The new languages you mention would benefit most from such a feature. I believe they won't do it not because it's not useful, but because it's difficult to make it right (efficient, safe, natural, scalable) and then maintain forever. There are many benefits of having this functionality working out of the box (and a few disadvantages, obviously). Many (if not most) apps are just CRUD apps with some added functionality. But a standard way of connecting the language to a database is still missing. The great success of the ActiveRecord back in the day shows that this is something many developers would benefit from (it was/is good, but still not ideal). And I don't believe patching the situation with a multitude of incompatible ORMs solves anything.

naasking 5y ago

> Examples where database syntax (i.e. SQL syntax) is 1st-class without noisy syntax of function calls, without command strings in quotes There more examples which I think qualify but don't quite fit into your categories: * The E language runs all code in "Vats", each of which is a single threaded compartment with transparent persistence. * Taking inspiration from E, the Waterken server did this for Java, but required annotating mutable fields in a certain way so the persistence layer could track them. * FoxPro doesn't neatly fit into your categories.

mwexler 5y ago

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 database as stored procedures. It was an odd melange of all of this. I ran into this in the 90s, and it was great for RAD. But it felt odd to have to code into tables, and each tool was proprietary such that moving off of the table system was a full rebuild. They usually allowed migration to new databases systems to scale, but that was all they had. I don't expect to see a language like this come around again anytime soon, but the ideas were really interesting in a world before git-ops and yaml configs.

jasode 5y ago
>, 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_ (aka the syntax) did that, it would naturally support table-oriented-programming (aka the philosophy). He starts the essay with critique of OOP-the-syntax. But to your point about config and code itself being persisted in the database, the SAP ABAP environment already works like that. SAP has over 10,000 db tables for configuration -- instead of YAML or JSON files. Change the values in the config tables to alter behavior instead of modifying IF/THEN/ENDIF statements in code. And when ABAP programmers hit "save", the code gets saved to a database table instead of a text file. So if one squints a certain way, the SAP system is a giant million-line stored procedure in the database.
- mwexler 5y ago
  Well put. SAP is the big survivor from that mindset. And perhaps the best example of why we won't see another. :-)

ModernMech 5y ago

> In any case, I don't see any trend where a general-purpose programming language will include DB SQL as 1st-class. Even the recent languages like Rust and Zig don't have basic SQLite3 db persistence as convenient built-in syntax. There is a trend, but you’ll have to look further off the beaten path than even Zig to find it. Languages like Eve [0] tried to do this circa 2015 in the tradition of Datalog. Code was written in “blocks” that resembled Prolog horn clauses, but which featured set semantics on selected records. Natural joins happened automatically on records using identifiers. The whole language was actually a database! Eve died [1], but you’ll see many such projects that have the same ethos in communities in the web, such as this one [2]. There aren’t a lot of users of these languages, but this is where a lot of big ideas are percolating right now. And we can verify it’s a trend because the hallmark of all CS trends, the formation of a conference, has made itself known in this area [3]. 0: http://witheve.com/ http://witheve.com/ 1: https://groups.google.com/g/eve-talk/c/YFguOGkNrBo?pli=1 https://groups.google.com/g/eve-talk/c/YFguOGkNrBo?pli=1 2: https://futureofcoding.org/catalog/ https://futureofcoding.org/catalog/ 3: https://www.hytradboi.com/ https://www.hytradboi.com/

nine_k 5y ago

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.

deleted 5y ago
[deleted]
CRConrad 5y ago
> 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 citizens" of the language), which IMO made Delphi the natural and superior successor to those languages: Not just "lightweight", but fully advanced (i.e, ~C++-level) general computation. (And with transaction processing built into the RDBMS connection components.) > Then happened the internet and client-server architectures, and these do not map as neatly onto local, single-user, single-transaction tables. Weeelll... Seen the spate of recent posts on here about how SQLite is good enough for pretty much anything? :-) And arguably, that's where Delphi was at too, over twenty years ago: AFAICR, there was a "Fishbase" (facts about tropical fish) demo included with Delphi, which in one variant could be built as a standalone Web service / server. Also, AFAICS, that's where Free Pascal / Lazarus is at now, only using SQLite / Firebird / MySQL / PostgreSQL (and lots of other DBMSes) in stead of DBase / Clipper / FoxPro / Crystal Reports / Paradox. (I've been planning to look into that a bit closer myself, but haven't got around to it. Procrastinating away too much of my time on Hacker News, I suppose. :-( )
- CRConrad 5y ago
  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.

gpderetta 5y ago

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.

xwolfi 5y ago
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 can read his own stuff 2 weeks later. Notwithstanding free tools to query force-expire every 3 months (QPad grrr) and as you said it's so closed they have to take webdevs like me to just help them maintain it all eventually. It's risky for the bank (and we're not a small one :s), it's expensive for the programmer, and it's misery for the quants (but they all feel like geniuses spending weeks on simple stuff on kdb, so their misery is only in people looking at them wasting away their brain like that).
- rak1507 5y ago
  Why is it still used then? Are there just no good alternatives? Or legacy reasons?
  - beagle3 5y ago
    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 because it is hard to find people who are willing and able to work with it. Much like its predecessor APL, it’s a tool for thought more than a tool for implementation.
    - 5y ago

agumonkey 5y ago

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.

badsectoracula 5y ago
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.
int_19h 5y ago
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.
mikewarot 5y ago
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.

civilized 5y ago

> 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?

CRConrad 5y ago
> Is this what ORMs are about? Translating between the programmer model of data and the relational DB model? Pretty much, AFAICS. With varying degrees of success.

DenisM 5y ago

How about LINQ, in particular LINQ2SQL?

marcle 5y ago

Another relevant software category is the statistical analysis languages, including SAS, Stata and SPSS. Old-school SAS included only two data types (floats and character strings), but allowed for SQL and sequential data-steps to live together. Persistence was baked in. The floats could be used to represent dates, datetimes and other formats. I particularly appreciated being able to use macros to define a data-step view to split the follow-up for an individual from a table. Such a view could then be collapsed using SQL. More recently, R tools such as dplyr have brought together data-frames and relational operations. However, I miss the sequential coding in SAS, using macros as higher-level tools to define the logic, including corner cases. For strictly typed records, I have always wanted to spend more time with SML# [0] this allows for record updating, with close ties to SQL -- an under-appreciated version of SML. [0] https://github.com/smlsharp/smlsharp https://github.com/smlsharp/smlsharp