111–120 of 149 posts
I don't know why he wants to waste so much space with twelve unsigned longs when he can do it in eight (one for each piece and two more masks for color).
Why waste space representing illegal positions?
Earlier quoted context omitted.
> The only argument against globals is testing No, the newer argument against globals is testing, but that's mostly a side effect of the older issue, that globals limit composability/reusability, which was the main objection to globals before TDD became a popular religion.
The "reusability" argument is just as wrong... True reusability (without any changes) is not possible in most cases anyway, and furthermore I don't see a reason why surrounding some static object (which can only exist once in a program, like a sound module, a network module, etc) with braces and a "class" keyword would somehow increase this vague idea of reusability. It's only a syntactic change. It's not changing wh…
Often, because the assumption that it can exist only once is wrong; this is particularly true of instances of some descriptive class of interface to an external hardware resource, which covers all of your examples.
> It's only a syntactic change.
No, it's usually not; while the syntactic change is usually necessary, it usually isn't the whole difference between the desirable modular code and the bad global-using code that should be made, and quite often if you aren't writing it as a global resource in the first place, you never make the other wrong decisions that would need to be changed.
Using globals may occasionally be justified (either as an optimization or, even more rarely, as “correct” from a fundamental design perspective), but most often it's a symptom of sloppy thinking.
The Bitboard is very abstract. The interface it instantiates will likely not let leak it’s concise internal representation and will discuss the operations on the game state at a domain level. This is abstraction. So this is a failure of OO abstraction. Why? OO abstraction is really complex and makes many forced moves that provide little value here. Inheritance and a focus on “nouns” makes idiomatic code highly specia…
OO design is often about the tradeoff between over-engineering and over-specialization. The rules of chess can usually be assumed to not changed, which is different to most programming tasks. If you would design for Chess 2.0 and you expect some game designers to change the rules every week (thinking up new kinds of pieces, changing the rules for existing pieces, changing the board layout, etc), would you still use B…
Earlier quoted context omitted.
No, my observation has nothing to do with composition vs/ inheritance. It's about defining what a class IS vs/ what a class HAS.
It's hard to ask this question without sounding snarky, but I hope you will understand that I'm seriously curious to hear what you think. > No, my observation has nothing to do with composition vs/ inheritance. > It's about defining what a class IS vs/ what a class HAS. What do you feel is the difference between these two sentences? In other words, why is inheritance vs composition not the same as what a class is vs…
I can use composition and inheritance to define an IS_A relationship and I can use them to define a HAS_A relationship.
For example, in Kotlin:
class A : B // IS_A via inheritance
class A(b: B) { // HAS_A via composition
class A(b: B) : B by b // IS_A via compositionEarlier quoted context omitted.
The guy is openly arguing with an interviewer after taking a question too literally. I suspect my interview impressions would've included "candidate may be on the spectrum". However, this entire thesis is founded on a false dilemma, because you can write an OO domain model with a compact representation.
sorry for going off-topic but I couldn't shake out of the back of mind. you said "candidate may be on the spectrum", do you discriminate against people based on their medical conditions?
Earlier quoted context omitted.
I have the sinking feeling that your first paragraph is probably what the original author had in mind all along… He advocated for a representation of the entire board, and that's apparently what you would do as well. I originally though you were advocating for a representation of each piece on the board, were "messages" were "sent" to individual pieces, not the entire board. I was curious about how you'd map that int…
I am. You should definitely be able to send messages to piece objects. That's not incompatible with the Board object having a bitboard for its internal representation of board configuration. The piece objects have contextual identity based on the board configuration. Hint: they don't have positional state.
Earlier quoted context omitted.
First, let us agree on what OOP might even mean. http://loup-vaillant.fr/articles/taboo-oo http://loup-vaillant.fr/articles/deaths-of-oop
I prefer the Treaty of Orlando, which is much more inclusive, and underlies our entire community. http://web.media.mit.edu/~lieber/Publications/Treaty-of-Orla... It is scary that the broad definition given in the 80s has been supplanted by a narrow “java or C++” definition today. If that what you mean by it, then no we aren’t talking about the same thing. I’ve built plenty of OO systems that don’t correspond to that…
Earlier quoted context omitted.
> The only argument against globals is testing No, the newer argument against globals is testing, but that's mostly a side effect of the older issue, that globals limit composability/reusability, which was the main objection to globals before TDD became a popular religion.
The "reusability" argument is just as wrong... True reusability (without any changes) is not possible in most cases anyway, and furthermore I don't see a reason why surrounding some static object (which can only exist once in a program, like a sound module, a network module, etc) with braces and a "class" keyword would somehow increase this vague idea of reusability. It's only a syntactic change. It's not changing wh…
Earlier quoted context omitted.
The "reusability" argument is just as wrong... True reusability (without any changes) is not possible in most cases anyway, and furthermore I don't see a reason why surrounding some static object (which can only exist once in a program, like a sound module, a network module, etc) with braces and a "class" keyword would somehow increase this vague idea of reusability. It's only a syntactic change. It's not changing wh…
> I don't see a reason why surrounding some static object (which can only exist once in a program, like a sound module, a network module, etc) with braces and a "class" keyword would somehow increase this vague idea of reusability. Often, because the assumption that it can exist only once is wrong ; this is particularly true of instances of some descriptive class of interface to an external hardware resource, which c…
The key here is how to understand the word "can". It's "only" a design decision! Of course you can do almost anything on a computer. However, most programs don't make sense with two sound modules or network modules or graphics modules. So "can" here means, "it absolutely makes no sense, and I'm never realistically going to instance two or more of this thing". (And if I really want to do that later, 1 in 1000 times, I'll just edit the code).
> it usually isn't the whole difference between the desirable modular code and the bad global-using code that should be made, and quite often if you aren't writing it as a global resource in the first place, you never make the other wrong decisions that would need to be changed.
Give an example: I don't think there are any. I can easily give you some bad things that happen when avoiding globals to represent static resources: Much more input and output arguments to type. Then, the syntactically ugly, useless, meaningless Singleton. I've seen it many times, and it is the best proof that it made no sense to avoid the global in the first place, and it even potentially leads to nondeterministic initialization.
And more importantly, an occasional reader has a much harder time browsing through the code because she never knows where the local variables are pointing at.
Earlier quoted context omitted.
OO design is often about the tradeoff between over-engineering and over-specialization. The rules of chess can usually be assumed to not changed, which is different to most programming tasks. If you would design for Chess 2.0 and you expect some game designers to change the rules every week (thinking up new kinds of pieces, changing the rules for existing pieces, changing the board layout, etc), would you still use B…
The point of abstraction is to not be tied to Bitboard--or any concrete representation whatsoever. Chess 2.0 changing its rules is exactly what can be protected against.
In practice, if code uses a Queen object, you put costly indirections in front of the Bitboard and thus already lost performance.