cartlidge · HackerTrans

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.

cartlidge

7 lat temudiscuss

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.

cartlidge

7 lat temudiscuss

Cloudfare didn't cut off service to a home, so you haven't provided relevant information.

cartlidge

7 lat temudiscuss

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?

cartlidge

7 lat temudiscuss

Hi thundergolfer. mrjn is the person who created dgraph, so I think he knows what the terminology is.

cartlidge

7 lat temudiscuss

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.

cartlidge

7 lat temudiscuss

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.

cartlidge

7 lat temudiscuss

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?

cartlidge

7 lat temudiscuss

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.

cartlidge

7 lat temudiscuss

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.

cartlidge

7 lat temudiscuss

That relates to my comment in what way?

cartlidge

7 lat temudiscuss

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.)

cartlidge

7 lat temudiscuss

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.

comments