375 karma · joined May 1, 2011
Modern monetary theory disputes this commonly held idea that governments need to collect tax before they can spend it on public works. On the contrary, government creates money to pay for public works, which leads to money in circulation, and in turn allows tax to be paid. The purpose of tax is to redistribute wealth and lead to harmonious society.
On the other hand, in market capitalism, economy of scale is a powerful force for conglomeration that sometimes results in an anti-competitive reduction in consumer choice.
This is trouble for the example for calculating the average number of reviews across movies:
SELECT math::mean(
Movie {
description,
number_of_reviews := count(.reviews)
}.number_of_reviews
);
> Strictly speaking, EdgeQL sets are multisets, as they do not require the elements to be unique.
The relational model is firmly based on the idea of a relation as a "set of tuples", and a major criticism of SQL has been that it views data as an ordered sequence of tuples.
So I'm skeptical of the claim that EdgeQL is really based on the relational model.
(Not clear whether multisets are ordered - wondering about window functions etc...)
Assets = Net Equities
Nothing in the article suggests any agreement between the photographer and Twitter.
The phrase you mentioned is notable (with a slight edit) - so I suppose you mean you could index phrases by notability, then it may be tractable find tweets of notable phrases, since the number of notable phrases is relatively low.
But SQL and the relational model is meant to be a logical system, and I'm interested in preserving some conceptual integrity in the domain modelling.
In a sense, empty string is available as a marker, just as NULL is available as a marker, to satisfy either scenario. I think the possibility of three-valued logic applies in either scenario.
I'm not at all convinced empty (non-null) string is appropriate for many real world applications, just as empty (non-null) date is appropriate for similar scenarios.
Eg. Date of death: unknown - NULL; not dead yet - NULL
Take the middle name example: "What was U.S President Theodore Roosevelt’s middle name?" when you know he didn't have a middle name.
Are you suggesting that a blank is the correct choice here?
I don't think it's accurate to say they have a blank middle name. I think it's better to say they don't have a middle name.
Comment in situ has advantages:
- preserves context without duplicating it into an external system - promotes awareness of the issue when the surrounding code is changed in future, which can lead to serendipitous resolution. - particularly useful when the issue is one of internal quality (eg coupling, duplication, missing test case) that wouldn't ordinarily qualify as a bug or proposed functional enhancement.
In contrast, the bug tracker is a graveyard where such ideas go to die.
*it's fun issuing such rulings.
> Null-terminated strings are actually a very good choice of string representation that is to be directly manipulated by programs, instead of just through opaque handles via library functions.
You seem to be having it both ways.
As I see it, "NULL" is a valid ascii character, but not a valid element of a C string - except as a terminator external to the string of characters being represented. It's fundamentally broken as an abstraction for managing variable length strings of ASCII. It is incapable of representing all strings of ASCII characters.
At a basic level, you could think of it as providing the content for the audience - the inventory that is sold to advertisers. Twitter as we know it would not exist if all the users were tweet consumers, and none were tweet producers.
T-Mobile is great example of a business providing customer service over Twitter.
Compare scala's for-comprehension that feels more natural: `for (x <- xs) yield x + 1;`
Perhaps there's an argument that the shape of the result is defined up front, so it might be easier to comprehend the result if not the implementation.
When we solve problems using relations, we benefit by thinking in terms of relations.
We can ask: How well does SQL allow us to express an algorithm in relational terms? (Let's ignore that that SQL introduces some non-relational impurities that may have practical value - eg column order, row order, duplicate rows.)
When I examine an SQL expression, and then visualize the relational operators involved, I find a very poor correspondence between the SQL expression and the relational algebra. I need to basically read the entire statement to understand the parts. (Contast to the LINQ examples, or perhaps a shell pipline.) In a way, this is the substance of the original article.
This is one way in which I mean SQL is bad.