Logs: freenode/#haskell
| 2021-04-06 09:42:19 | <Maxdamantus> | Things like "counting AST nodes" *might* be simpler, but I think the usual things you expect to do with ASTs will likely be harder, since you've got a less direct representation. |
| 2021-04-06 09:42:29 | <merijn> | Maxdamantus: I disagree, recursive things work very well in relational databases |
| 2021-04-06 09:42:40 | <mettekou> | Maxdamantus: an adjacency list works fine with a recursive CTE query. |
| 2021-04-06 09:42:48 | <merijn> | Recursive CTEs are great |
| 2021-04-06 09:43:02 | <merijn> | SQLite has a bunch of nice example applications of recursive CTEs for Fossil |
| 2021-04-06 09:43:32 | <mettekou> | merijn: I'm using PostgreSQL, so I have good recursive CTE support as well. |
| 2021-04-06 09:43:57 | × | sedeki quits (~textual@unaffiliated/sedeki) (Quit: Textual IRC Client: www.textualapp.com) |
| 2021-04-06 09:45:51 | → | lotuseater joins (~user@p200300e78705e200e5bac9463b911ab3.dip0.t-ipconnect.de) |
| 2021-04-06 09:47:04 | → | molehillish joins (~molehilli@2600:8800:8d06:1800:b54a:36bf:7632:87f4) |
| 2021-04-06 09:47:04 | × | heatsink quits (~heatsink@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Read error: Connection reset by peer) |
| 2021-04-06 09:47:20 | → | heatsink joins (~heatsink@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-04-06 09:47:41 | → | mikoto-chan joins (~anass@gateway/tor-sasl/mikoto-chan) |
| 2021-04-06 09:48:43 | × | Pickchea quits (~private@unaffiliated/pickchea) (Ping timeout: 260 seconds) |
| 2021-04-06 09:51:14 | × | molehillish quits (~molehilli@2600:8800:8d06:1800:b54a:36bf:7632:87f4) (Ping timeout: 245 seconds) |
| 2021-04-06 09:51:23 | × | mice-user quits (b4960d8b@180-150-13-139.b4960d.syd.static.aussiebb.net) (Ping timeout: 240 seconds) |
| 2021-04-06 09:51:31 | → | p4trix joins (~p4trix@19.red-83-49-45.dynamicip.rima-tde.net) |
| 2021-04-06 09:51:56 | → | DavidEichmann joins (~david@47.27.93.209.dyn.plus.net) |
| 2021-04-06 09:52:31 | × | heatsink quits (~heatsink@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-04-06 09:52:53 | → | clog joins (~nef@bespin.org) |
| 2021-04-06 09:53:18 | <mettekou> | merijn: iTasks seems interesting, but it may be overkill for my use case (really, the DSL I have doesn't have procedural abstraction, not even branching currently, it's very close to a flow process chart, with only 3 types of nodes). |
| 2021-04-06 09:53:33 | → | haskellstudent joins (~quassel@213-225-9-45.nat.highway.a1.net) |
| 2021-04-06 09:54:30 | → | kiweun joins (~kiweun@2607:fea8:2a62:9600:615f:d2ef:3b34:54be) |
| 2021-04-06 09:54:40 | <Maxdamantus> | merijn: still seems like unnecessary cognitive overhead. That's all stuff that is abstracted away when dealing with structures in normal programming languages. |
| 2021-04-06 09:54:58 | <merijn> | It should have branching? Pretty sure I saw that years ago already during one of the NL-FP days...at any rate, you can at least steal their design ;) |
| 2021-04-06 09:55:09 | <Maxdamantus> | merijn: when writing recursive structures in Haskell or whatever, you're not having to produce the pointer values for cross-referencing. You can't even inspect them. |
| 2021-04-06 09:55:26 | <merijn> | Maxdamantus: I don't think it's overhead at all, I find recursive CTEs (and really all of SQL) very natural with a purely functional mindset |
| 2021-04-06 09:55:49 | <merijn> | Maxdamantus: heh? |
| 2021-04-06 09:55:50 | <Maxdamantus> | merijn: so why do programming languages normally abstract these things away? |
| 2021-04-06 09:56:23 | <merijn> | Maxdamantus: Have you seen how those recursive CTEs look like? They're...like...the most purely functional thing you can imagine :p |
| 2021-04-06 09:56:43 | <mettekou> | merijn: Yeah, iTasks has branching and much more, I was talking about my own DSL. It doesn't have anything fancy at all. |
| 2021-04-06 09:57:08 | <kuribas> | merijn: but representing stuff like ASTs in a database involves many small tables, and corresponding overhead. I'd just serialize to JSON, and do any processing in haskell. |
| 2021-04-06 09:57:08 | <mettekou> | merijn: No procedural abstraction, no branching, and just 3 "statements" or "expressions". |
| 2021-04-06 09:57:37 | <merijn> | Maxdamantus: See the 3.2, 3.3 and 3.4 examples here: https://sqlite.org/lang_with.html |
| 2021-04-06 09:57:38 | <mettekou> | kuribas: That works fine until you want reporting over executions. |
| 2021-04-06 09:57:47 | <merijn> | kuribas: WHo says "many small tables" |
| 2021-04-06 09:57:55 | <merijn> | kuribas: How many nodetypes does your AST have? |
| 2021-04-06 09:58:02 | <merijn> | kuribas: I'd say 20 is already way high |
| 2021-04-06 09:58:06 | <Maxdamantus> | merijn: admittedly, not, sorry. But if I just imagine fundamentally what the model of a relational datastore is, it seems like if you want to represent recursive things, you need to be exposed somehow to things that are for good reason abstracted away already in typical programming languages. |
| 2021-04-06 09:58:14 | <merijn> | kuribas: And you can probably compact several nodetypes into the same tables |
| 2021-04-06 09:58:44 | <kuribas> | merijn: I was just thinking about my previous company, where they implemented a static schema (for taxes) using many tables.. |
| 2021-04-06 09:58:57 | <kuribas> | merijn: it was more than 20 I believe... |
| 2021-04-06 09:59:08 | <merijn> | kuribas: For an AST? |
| 2021-04-06 09:59:16 | <Maxdamantus> | (eg, creating identifiers to be used essentially as pointers) |
| 2021-04-06 09:59:20 | <tdammers> | SQL schemas in the wild are a never-ending source of cruel entertainment |
| 2021-04-06 09:59:24 | × | kiweun quits (~kiweun@2607:fea8:2a62:9600:615f:d2ef:3b34:54be) (Ping timeout: 258 seconds) |
| 2021-04-06 09:59:31 | <kuribas> | merijn: it was a static schema for tax reports. |
| 2021-04-06 09:59:47 | <merijn> | kuribas: How does that relate to the number of tables you'd need for an AST? |
| 2021-04-06 09:59:55 | <merijn> | Also, many tables isn't *inherently* bad |
| 2021-04-06 09:59:58 | × | mkDoku quits (~TheMule@aftr-37-201-195-134.unity-media.net) (Ping timeout: 265 seconds) |
| 2021-04-06 10:00:07 | <kuribas> | merijn: because an AST tend to have many branches as well. |
| 2021-04-06 10:00:09 | <merijn> | As with all tech things: "It Depends (TM)" |
| 2021-04-06 10:00:30 | <tdammers> | my favorite antipattern in this regard is to create tables dynamically, and store their names in columns, as quasi-foreign keys |
| 2021-04-06 10:00:38 | <merijn> | Anyway, the freshly baked bread for lunch is done and it smells better than any tech discussion ;) |
| 2021-04-06 10:00:39 | <Maxdamantus> | I really can't imagine myself looking at a spreadsheet denoting an AST and seeing something more obvious than an AST represented in JSON. |
| 2021-04-06 10:01:09 | <Maxdamantus> | if a spreadsheet is denoting an AST with a bunch of cross-referencing identifiers, I can probably transform it into some JSON that is easier to understand at a glance. |
| 2021-04-06 10:01:19 | → | Rudd0 joins (~Rudd0@185.189.115.108) |
| 2021-04-06 10:01:26 | <kuribas> | merijn: the primary reason for using database tables is searchability. |
| 2021-04-06 10:02:05 | × | justanotheruser quits (~justanoth@unaffiliated/justanotheruser) (Ping timeout: 250 seconds) |
| 2021-04-06 10:02:07 | <kuribas> | if you don't need that, I don't see any reason at all for dividing you structures into tables. |
| 2021-04-06 10:02:54 | <kuribas> | the haskell typesystem already takes care of consistency. |
| 2021-04-06 10:03:09 | <mettekou> | kuribas: The primary reason for using database tables is eliminating data redundancy, not searchability. |
| 2021-04-06 10:03:13 | × | tomboy64 quits (~tomboy64@unaffiliated/tomboy64) (Ping timeout: 260 seconds) |
| 2021-04-06 10:03:18 | <tdammers> | ^ |
| 2021-04-06 10:03:57 | → | royal_screwup21 joins (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) |
| 2021-04-06 10:04:02 | <kuribas> | mettekou: why would you have data redundancy in a static scheme, or AST? |
| 2021-04-06 10:04:41 | <mettekou> | kuribas: Network and hierarchical databases (i.e. CODASYL) had indices before Codd came up with the relational model, so they were searchable. The problems were access path dependence and data redundancy. |
| 2021-04-06 10:05:22 | <mettekou> | kuribas: I mean data redundancy in the relational model sense, i.e. the result of unnormalized data. |
| 2021-04-06 10:05:31 | <tdammers> | and in fact modern tree-shaped noSQL databases have the same problem |
| 2021-04-06 10:05:43 | <tdammers> | (or document databases, for that matter) |
| 2021-04-06 10:05:52 | <mettekou> | tdammers: Indeed, as Stonebraker pointed out in "Those that do not learn from the past..." |
| 2021-04-06 10:06:26 | <tdammers> | if you're smart about noSQL, you realize that that's a tradeoff, and that tradeoff may, under certain circumstances, be worth it |
| 2021-04-06 10:06:50 | <tdammers> | but it certainly ruins the idea that noSQL databases are unambiguously superior |
| 2021-04-06 10:06:52 | → | Tops2 joins (~Tobias@dyndsl-095-033-088-082.ewe-ip-backbone.de) |
| 2021-04-06 10:06:58 | <aldum> | if you are smart, you realize everythng is a tradeoff, there are no solutions :) |
| 2021-04-06 10:07:28 | <tdammers> | there are solutions alright, it's just that as an adult, you realize at some point that "solution" doesn't mean what you thought it did |
| 2021-04-06 10:07:36 | <kuribas> | tdammers: I just wonder what advantage they have over storing JSONs in a RDBMS. |
| 2021-04-06 10:07:59 | <mettekou> | tdammers: The problem with the NoSQL term is that MongoDB ends up together with Apache Cassandra and Redis. |
| 2021-04-06 10:08:28 | <mettekou> | Whereas relational or SQL is pretty narrow as a category, NoSQL is just anything else. |
| 2021-04-06 10:08:29 | <tdammers> | mettekou: agree completely. couchdb has about as much in common with mongodb as it does with postgres, if not less |
| 2021-04-06 10:09:15 | <kuribas> | mettekou: right, and a good NoSQL database would be complementary to a RDBMs, not a replacement. |
| 2021-04-06 10:10:00 | → | royal_screwup211 joins (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) |
| 2021-04-06 10:10:11 | <tdammers> | kuribas: not necessarily. they do serve the same general concern, that of persisting large data sets for efficient partial querying and modification |
| 2021-04-06 10:10:47 | <kuribas> | tdammers: but a RDBMs works well for most cases. |
| 2021-04-06 10:11:04 | <kuribas> | I often think people want NoSQL because they don't understand SQL. |
| 2021-04-06 10:14:00 | <tdammers> | because they don't understand SQL, because they don't understand NoSQL, because they believe in unicorns and silver bullets, because they are practicing hype-driven development, because management makes them, ... |
| 2021-04-06 10:15:51 | <Maxdamantus> | in all seriousness though, why are compilers not using SQL? |
| 2021-04-06 10:16:15 | <Maxdamantus> | 21:16:10 < Maxdamantus> I find it hard to imagine that it would be simpler to maintain these things in a relational database, otherwise people would be generally using relational database when writing compilers. |
| 2021-04-06 10:16:19 | × | shalokshalom quits (~quassel@2a02:1748:dd5e:7f60:cf49:8384:7c93:3106) (Remote host closed the connection) |
| 2021-04-06 10:16:35 | → | shalokshalom joins (~quassel@2a02:1748:dd5e:7f60:cf49:8384:7c93:3106) |
| 2021-04-06 10:16:42 | <Maxdamantus> | If these relational models are so great, why not replace general data structures in programming languages with relational ones? |
| 2021-04-06 10:17:39 | <Maxdamantus> | You almost never see relational patterns used in memory. They're normally just used for querying larger sets of data stored outside of the main program's memory. |
| 2021-04-06 10:18:03 | <kuribas> | Maxdamantus: I sometimes use a relational model in haskell, for example storing IDs and a map of ID to the object. |
| 2021-04-06 10:18:06 | <tdammers> | relational data structures in memory are a thing in game programming |
| 2021-04-06 10:18:09 | <haskellstudent> | kuribas: do you think high availability requirements is a legitimate reason because of schema migrations? if i store everything as json in a kv store or a kv table in a rdbms i never have to do a schema migration in the db and pause it |
| 2021-04-06 10:19:02 | <kuribas> | haskellstudent: well, you may need to do migration if your datatype that the JSON represents changes. |
| 2021-04-06 10:19:21 | <haskellstudent> | sure, but not in the db |
| 2021-04-06 10:19:56 | <kuribas> | depends, you may want to make sure that the JSON types all have the same structure. |
| 2021-04-06 10:20:06 | <kuribas> | which would require migration |
| 2021-04-06 10:20:49 | <haskellstudent> | which means i can have a newer version of a service write and read a newer version of e.g. an event json in the db while the older versions just ignore any fields in the json they dont know yet. |
| 2021-04-06 10:21:05 | × | coni quits (d4338494@212-51-132-148.fiber7.init7.net) (Quit: Connection closed) |
All times are in UTC.