Little did they know that the universe is four dimensional and even the orbit of planets is an illusion produced when straight motion in a four dimensional space is projected into three dimensions (or something).
immediately reminded me about projective geometry which is one of the most beautiful systems of mathematics.
So the universe is 4D? I don’t know. But if it was true then we could use the concepts of projective geometry to interpret something interesting.
So the universe is 4D! But how can we imagine a 4D space? It’s nearly impossible to get a perception of 4D without going out of the current 3D space. What would we meet when we went out of the 3D space? Intuitively, the answer is points at infinity, lines at infinity and a plane at infinity. This begs a question: what are the coordinates of these infinite stuff? Of course using 3 components like (x, y, z) is insufficient. That’s why we need 4 components (x, y, z, w) to represent all points/lines/planes including finite and infinite ones. Hence the name 4D.
The funny part is when you travel to a point at infinity and meet a stranger there. If you ask him about the coordinates of the current point you may get a very different answer: the point is not at infinity in his eyes! What does this mean?
The 3D world we are living in and perceiving is just one particular 3D space projected from a 4D space – the universe. Infinite points of this world are finite ones of other worlds. The only way to move from a world to other worlds is travelling to infinity of that world. The number of worlds may be infinite too.
Points at infinity do not exist. It is just a notion to refer to a certain subset of points in 4D space that cannot be projected into a certain 3D space and therefore are missed and non-existed in that 3D space. In 4D space every point is treated equally, nothing is called infinity.
Null is clearly evil. We as human tend to forget to check null, and boom … crashhh! Documentation may help, but again we still forget reading documents. Worse, not all documents are correct and up-to-date 100%. Even if we remember to do every null check, our code would be very messy.
Exceptions are a very common concept in most of languages nowadays. In this article we will discuss why exceptions are needed, checked vs unchecked exceptions, and why C# doesn’t have checked exceptions.
This article is about my personal explanation of the reputed design patterns: Model-View-Controller, Model-View-Presenter, and Model-View-ViewModel; followed by a judgement, and a discussion for the applying of those patterns to the Web.
Builder Pattern and Factory Pattern are pretty similar in a way: both of them encapsulate the details of object-creation processes. However, in cases there are many complicated processes to create various representations of objects, and those processes share a common trait, Builder Pattern is the better choice.
In recent years, Entity-Component Systems (ECS) has been recognized as the most notable architecture for game development. There are many good articles about the architecture that can be found on the Internet, some of them are:
Of course these articles are excellent and well-written, but one thing I don’t like about them is that they are not fair at comparing OOP and ECS. They think that inheritance is fundamental to OOP thus they blame OOP in order to praise ECS as a preference of composition over inheritance.
Many software developers – especially .NET developers – have a habit of putting the “I” prefix when naming interfaces. At first glance, this is good because it helps us to identify quickly whether a class is an interface or not.
But why do we – as clients of the class – need to know about this?
Clearly, typical clients really don’t care. Just invoking the methods provided, and that’s it, knowing that it is an interface is useless. However, there are special clients who do care so that they know the class cannot be instanced – by the new keyword – and need to be implemented or extended.
In most cases, the typical force dominates the other one, thus the “I” prefix is unnecessary. Sometimes it is annoying: if we decide to change the interface to a normal class (or abstract class), we have to remove the prefix. As we know, renaming a type is often awkward!
As a rule of thumb, good names come from problem domains, not solution domains.