It isn't at all clear that (1) is true. Until recently, no-one was particularly concerned about companies which link advertisers and purchasers. Unless you say the hypothetical benchmark company is a company which tries to track you and build a database on you and basically spy on you, Google seems to be overtly more evil than any hypothetical benchmark company.
Effectively you've defined yourself into a corner were the hypothetical benchmark company is Google, since they must be substantially identical in all relevant ways. It isn't sufficient that they are advertising mediators: no, they must be advertising mediators who track every detail of their users life.
But even if we decide to compare within their business methods - not just their product space - and say, "given that they're Big Brother, are they an evil Big Brother or relatively more benign", it's not clear that they're benign. I have heard stories that leave my concerned (trying to produce a censored version for China, for instance, and gagging former workers who don't feel comfortable with that). I cannot provide evidence that they operate an evil business in an evil way, but it isn't clear that they don't. The absence of evidence is not evidence of absence.
Google worries me more and more, even though I'm tied to them more and more.
I think most people can see that there's a huge gulf between "everything is lawful" and "the government regulates ideas and risks doing so in their favor".
Most people accept that you cannot say "how unfortunate it would be for him if Jack ate seafood tonight" to your Mafia henchmen. Nor can you say "we will storm parliament at dawn using these weapons" if you are part of a plot to replace the state with a capitalist anarchy.
And in the same manner, it seems that there are plenty of laws in place already against saying "if white people are to defend ourselves and survive as a race, our immune system must go to work" in an 8chan manifesto.
But that's different than saying "Jack has betrayed me", "representative democracy is defective and must be replaced by capitalist anarchy" or "the white race is superior; non-whites are traitors and should be dealt with harshly; vote for me".
(Whether a text advocates violence cannot necessarily be reduced to a few words, as I hope my first example demonstrates. The context in which the words are uttered and the interpretation the speaker can reasonably intend are relevant. Fortunately, no legal system has been replaced by a computer program, but are generally interpreted by intelligent human beings.)
Free speech absolutism was never intended by the Voltaire or the American founding fathers - as can be seen by their other actions. It is a recent populist view without warrant of careful analysis. I support free speech; but I do not support free speech absolutism.
I have a hope of remembering about:performance. I can bookmark it, and it's there in autocomplete. You can make a link to it in your webpage or in a nice plugin (which, once it gets a couple thousand users, you can sell to an honest businessman for tens of thousands).
Shift-Escape? what? I'm supposed to just randomly press every key combination till something happens?
The Faq says "If your data doesn’t have graph structure, i.e., there’s only one predicate, then any graph database might not be a good fit for you."
I know what a predicate is, but I don't understand how it is being used here. Can someone explain how I can determine if my data has a graph structure? What sort of predicate do we have here?
Think of a JSON map as a document or an entity. Then the keys would be predicates, and the values would be either references to another JSON map (document/entity) or a value (like a string, int or something).
This is a valid JSON for Dgraph. It means, the overall JSON map is an entity of UID, 0xabcd. It has friends (other maps), name "HN user", and age 21. Here, "friend", "name", "age" are predicates.
Thanks for the reply mrjn. So a predicate includes a relation, but we take it from its logical point of view. (Rather than in an RDBMS, where we contort the relation so that we can see it from the perspective where it has a cardinality of 1.)
And the notion of one-ness of the predicate comes not from the fact that there's only one relation, but the fact that there's only one _logical value per predicate_ - here, we have two values of `friend` which cannot be conveniently coded in an RDBMS without the use of a join table.
So do I correctly interpret your faq "when not to use Dgraph" as saying "Dgraph is probably overkill if predicates naturally have a single value - that is, join tables are rare and you can naturally put foreign keys in the object they logically belong with, rather than in the table where they have a cardinality of 1".
This makes me think my other by @thundergolfer is probably wrong (sorry) - actually, an ecommerce site would benefit from an efficient graph db since you have an order, and now you want to find all the items in it, so the link from an order to an item should be associated with the order. Yet in the standard model, as with his, once you've found the order now you have to filter through the items to find the ones which reference the relevant orders; indeed, this is almost the only way that relation will ever be travelled - logically backwards.
I appreciate your time @mrjn. I like to hope you can benefit from answering my silly questions because someone can improve that faq. I'm trying to pick the right db for a personal project but I never expect to make money from it so I don't feel like I can give you any direct benefit from your time.
I’m not 100% sure, but a basic ecommerce site I think would be a classic example for a relational data model or key-value data model if you want to be fancy. Assuming the former, we’d then expect that in this data domain we could only come up with one maybe two predicates.
Without thinking too hard and deep, this seems true. An Order HAS Items, an item HAS a price, a customer HAS Orders, Addresses, etc.
I think you’d get quite far modelling the entire problem just with HAS.
But "has" isn't a predicate. "Has" is a relation. If we take "has an item" an "has a price" and "has an order" to be predicates, then we already have three predicates. So that can't be the definition of predicate.
Yes HAS is a relation, but in my example it's also the predicate.
A predicate is a statement that may be true or false depending on the values of its variables. In my example we'd have HAS(order_i, item_2), where both the order and the item are variables (or vertices) in our graph.
It wouldn't make sense to model with HAS_AN_ITEM(order_i), because as you say you'd proliferate predicates all over the place when you introduce new entities.
So yes, HAS is a predicate, and it handles nicely models a shopping cart.
DGraph models this with a 'PostingList' anchored on the predicate (they call it the "attribute"). This model is not particularly advantageous though in this shopping cart case as using a single HAS predicate means that in practice almost every 'PostingList' will have the same predicate and thus we will more often find ourselves joining across PostingLists when doing single predicate queries, which shouldn't happen.
I think it's more productive to not care about the formatting. Allow redundant, pointless spaces that serve only to keep things out of alignment. Once it doesn't matter if the code is pretty - or if the autoformatter has been run - you just read the content.
I thought the point of code is to make it more difficult for the non-initiate to read it...
Actually, I think a good, justly polymorphic function should probably have a word of a reasonable length and parameters that are called `a`, `x`, `f`, since the parameters convey almost no information. If they have any greater length, it's just a restatement of the known information about the type.
The more unique information a name conveys, the less information the types convey and the bigger a chance you have of bugs or coding yourself into a hole.
But also, if you've called it `x` hopefully there's only one thing it can be and its scope is just one or two lines so you've written a single unit. If there's anything else `x` could be, then you've got a problem - your unit is too much.
Not every piece of code should be written this way, but your vocabulary should be built up of pieces like this.
That isn't an inherent issue of composition though. You could say
{...students(ajaxDb), ...teachers(ajaxDb)}
to create an object that can handle both students and teachers. Or you could say
public class StudentsAndTeachers extends Students implements IStudents, ITeachers {
private _teachers;
public constructor(Database db, Teachers teachers) {
super(db);
_teachers = teachers;
}
public getTeacher(TeacherId teacherId) {
return _teachers.getTeacher(teacherId);
}
}
new StudentsAndTeachers(ajaxDb, new Teachers(ajaxDb));
It seems clear that the features of the language define what is verbose and what isn't verbose. Even the inheritance in the language that encourages inheritance is more verbose than the composition in the neutral language.
(More likely, you wouldn't write this, but every example that is colloquial in inheritance is non-colloquial in composition. The composition oriented solution can be used cleanly with strong guarantees provided to its users; whereas all inheritance oriented solutions are so tacky and hard to use that you will demand a framework with dependency injection which half your team won't be able to understand and will have to treat as magical incantations.)
I'm not sure I agree with your thesis. For instance, Javascript has recently added an OOP class syntax, and Typescript extends the result with strict types. (JS was of course in some sense object oriented beforehand, but it wasn't recognisable to most working OO programmers as OO.) Moreover, I think you need a deliberately hamstrung language to get a genuinely OOP language - C++ and Javascript are both fully capable of writing OO code, but most people shy from calling them OO languages because they're not limited. A more interesting question is whether new programs are object oriented, and I guess the answer here remains, broadly, yes. This is why Javascript got class syntax.
But I will assume you're a better observer than me, and make the following claims:
I think there's two reasons: Object-oriented style inheritance is unsound (inheritance is not subtyping), so academics don't like it. Moreover, classical OO is not composable or extensible - unless you write your own primitives in every application and end up with Java-like verbosity. Therefore, research in new features tend not to be object oriented. Therefore, new languages tend to adopt non-OOP styles.
The other reason is probably that there's enough OOP languages. The effort it takes to create a new OOP language exceeds the effort it takes to shoehorn your OOP algorithm into an existing OOP language. Therefore, there's less motivation from the engineering side.
On the other hand, there's still lots of scope for better functional style languages; that marketplace isn't exhausted yet. Rust, for instance, merges a lot of academic techniques trialled on functional languages with a systems programming architecture.
Effectively you've defined yourself into a corner were the hypothetical benchmark company is Google, since they must be substantially identical in all relevant ways. It isn't sufficient that they are advertising mediators: no, they must be advertising mediators who track every detail of their users life.
But even if we decide to compare within their business methods - not just their product space - and say, "given that they're Big Brother, are they an evil Big Brother or relatively more benign", it's not clear that they're benign. I have heard stories that leave my concerned (trying to produce a censored version for China, for instance, and gagging former workers who don't feel comfortable with that). I cannot provide evidence that they operate an evil business in an evil way, but it isn't clear that they don't. The absence of evidence is not evidence of absence.
Google worries me more and more, even though I'm tied to them more and more.