benfle

Is it a good idea to base your GraphQL schema on your database schema?

Isn't the point of GraphQL to decouple your interface (who should not break) from your backend implementation details?

Allen Wirfs-Brock summarizes it perfectly: https://twitter.com/awbjs/status/1107678004757430272

I don't see those quotes as contradicting Kay's point about data.

My interpretation of what Torvalds and Pike are saying is that we should spend time designing our programs to find the right way to think about our problems. And this is done by finding the right data structures and their relationships (architecture) so that the code (algorithms) is minimal.

This is very close to what Kay was advocating with object-oriented programming (OOP). The data that Alan Kay wanted to get rid of is what Clojure people calls place-oriented programming (PLOP). Which is funny because they often use PLOP to mean OOP. What Kay meant by "data" is setting and getting values in memory slots (assignment). He realized that moving data around like this did not scale because most of your code will be busy doing those mundane things. This is the "code" and "algorithm" part in Pike's and Torvalds's quotes. Your software is cluttered by code moving things from one place to another because you don't have the right "data structure" or "architecture" or "object design".

Unfortunately, a lot of modern OOP languages are PLOP and make it even worse by encouraging developers to create a class for every single piece of data they want to compute with. Calling `setName` on an instance of a Person class is not OOP but the "data" that Kay wanted to get rid off in the first place.

So I think they're all talking about very similar things but with slightly different terms. The goal of programming should be to find the point of view that will give us the most leverage to solve our problem. We should spend more time designing our programs to find the right concepts as opposed to start coding as soon as possible with whatever abstractions we're familiar with or that our programming environment makes available.

My personal favorite about how to get conceptual efficiency of our software is from David P. Reed's "Get the verbs right". See https://users.cs.duke.edu/~rodger/articles/AlanKay70thpoints...

Aren't we lucky to have stumbled upon the "correct tool for the job" at our first attempt.

If "age" is an important property in your system shared among different kinds of entities then you need to have an Interface or a Protocol to retrieve the age of an entity.

The same way you would create a keyword in Clojure to represent the age of an entity (e.g. ':entity/age') that can be put in a map describing a person or a cat.

In both cases you minimized the interface between your modules and you have less coupling.

I don't see the difference between sending a Person instance and sending a map of keywords about a person. The coupling is the same.

I think Rich is talking more about data structures than data abstractions here. In particular, he's saying that he favors sound data models (RDF, datalog, relational) to manipulate information in our programs over specific data structures.

To me it is related to Alan Perlis's saying on the power you get from uniformity:

"It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."

I totally agree with him on this point and I also agree that for some of us a lot of our programs are about manipulating static information structures. But let's not reduce programming to that.

Other things that occur both naturally and in simulations: revenge, jealousy, violence, territoriality, oligarchy, thumb sucking...

The author is obviously more interested in telling entertaining stories (in the boardroom) than telling the truth.

Tufte is not only about data viz. and powerpoint bashing. Integrity is central to his work.

I would not trust someone who present me a graph like in the second example (whether as a pie chart or as a bar chart). There is no way to know if the classes have the same attendance. Hence his conclusions could be completely wrong.

I had the exact same reaction. It is unfortunate Chris didn't take time to respond to your comment...

It is always interesting to see different object systems being used. I just hope we will get a honest review of it in a few months after it has been used to develop a large application like Light Table.

That's effectively unfortunate to compare your design to OOP because we tend to have different opinions of what OOP is. If you see OOP simply as message passing and polymorphism then your "all-e" and "renderer" functions just reimplement these ideas (as opposed to have your function simply assign different values to your data). Why isn't your "render-player" not a method?

It would have been interesting to go into more details about the CES design. For example, how do the components interact with each other? How is "position" updated when interacting with "walker" and "jumper"?

What would be very interesting to talk about (instead of entering into the details of an innocent analogy) is a toolkit that would make very easy to create new higher level languages on top of JavaScript.

Unfortunately, JavaScript and its VMs have limitations that would not allow us to create very performant languages for some domains but I think we could have a lot of other useful higher level language to program (the web).

How complex would it be to execute a javascript function callback against each published document on the hub instead of a query and return the document to the subscriber if the function returns true?