3 ms·
1. Your solution is incorrect. I said you need to be a member of all the groups associated with a forum, not one of them. How would your code handle a public
by dfranke 19y ago
1. Your solution is incorrect. I said you need to be a member of all the groups associated with a forum, not one of them. How would your code handle a public forum (one with no groups associated with it)?
2. Suppose you have one million users. Then you're sucking up an awful lot of RAM just for this tiny piece of functionality.
3. Your pseudocode makes a lot of convenient assumptions about what functionality is already provided in standard libraries and in the accessor methods for user.groups and group.forums. Let's see it written in a real language.
4. You say you don't care about how data is stored and accessed, but given the right set of reasonable assumptions, I can conclude that the running time of your algorithm is O(n^3). The beauty of relational databases is that you usually really don't have to care. The query optimizer is pretty good at figuring it out for you.
EDIT: nostrademons, I saw that peer reply before you deleted it. That was just spookily similar :-)
- mojuba 19y ago1. Again, easier than you think: allowed_forums = [] for each forum in forums if forum.groups <= user.groups // set comparison, like in Pascal allowed_forums |= forum // include an item 2. Let' say, I have a system that will do swapping and optimization for me. 3. My pseudocode is an assumption that it is possible to build some language/environment that would replace databases, only in theory so far. 4. Ok, maybe I'm going to use the "beauty of databases" in the implementation for my language. The goal is to eliminate SQL (and useless interview questions at the same time :)
- dfranke 19y ago1. Ok, that looks correct now. 2. There's a word for such a system. It's called a database :-). 3/4. Ok, sounds good. But like many others in this discussion, you're confounding SQL with the relational model. Your pseudocode above goes slightly outside the relational model because it's written in imperative style, but can be adapted to it easily enough just by replacing your for loop with set-builder notation and maybe a unary union operator. Sure, SQL has warts. It was originally designed as a language extension for COBOL for chrissakes. But the language you're inventing is just a prettier syntax for basically the same semantics.
- mojuba 19y agoBut the language you're inventing is just a prettier syntax for basically the same semantics. No offense, drfranke, but this reminded me of a conversation I had long-long ago, with a group of physicists. I was saying Fortran was going to die soon and their only argument was "see, you can do it in Fortran! you are just replacing one syntax with another!". Actually damn Fortran died a bit later than I expected, but those're just technical details :)
- pfedor 19y agoFortran is still very much in use in theoretical physics/quantum chemistry departments.
- mojuba 19y agoBecause nobody cares about creating a decent math library for one of the mainstream dynamic languages.
- dfranke 19y agoOk, let's leave it at this: my YC app is for a web-based distributed RDBMS. It's going to speak SQL because that's what everyone is used to, but I've long entertained the idea of designing something nicer to work with and supporting it as an alternate frontend for the query compiler. If you have good ideas about how to do this, and think you're capable of implementing them, then please do send me a resume.
- mojuba 19y agoThe query optimizer is pretty good at figuring it out for you. This is not true. Let's get back and compare the intellectual effort required to solve your task in SQL and in my imaginary language. The difference in complexity is exactly the amount of effort by which you help the SQL query optimizer to do its work.