Chalmers’ claim is that the fact that it really exists and the fact that we can talk about it are unrelated and basically a coincidence, which I think is completely absurd… If you really believe in qualia IMO you have to bite the bullet and say that there must be physics that we don’t yet understand.
We're approaching the definition of magic here aren't we. And I think this is what really divides this discussion. There is one set of people who insist that things must be explainable. And if something is explainable, it yields to science and is no longer magic.
On the other side, you have people who insist that there are things which do not yield to science. So whether they admit it or not, they insist upon the existence of magic.
In fact, the definition of magic might as well be, that which does not yield to explanation. The only question once you believe in magic is, what alternative epistemology do you accept? Scripture? Tradition? Divine revelation?
Not at all. Saying that science does not yet explain some observed phenomenon is precisely how one starts to make scientific progress. Saying that qualia don’t exist because they are “magical” is like someone telling you lightning doesn’t exist before the understanding of electromagnetism.
> On the other side, you have people who insist that there are things which do not yield to science. So whether they admit it or not, they insist upon the existence of magic.
This is a really valuable framing for this sort of conversation.
We don't experience the sun going up and down, we experience its direction changing relative to the horizontal plane, and it is not an illusion: it matches planetary motion. The mistake arises when interpreting the raw experience. Sensations don't lie.
Another example: Metal feels colder than plastic, but the sensation is right again: you are loosing more heat when touching metal.
But the sensation in a sense is a lie. Cold strictly speaking isn't real. And for much of human existence we spoke of it as if it was a substance due exactly to this specific sensatation.
Bounded collections still allow for useless reachings of their bounds, and corresponding memory and CPU wastes (and possibly functional/domain issues).
The main reason I saw around me for memory leaks in GC'ed languages, is devs only thinking about the 'add' part, not the 'when-to-remove' part. I always think of both and the only leaks I got were from slowdowns causing events to pile up in scheduler queues (deliberately not bounded).
Before, not after: when the code makes it hard to implement a new feature (the definition of technical debt: code that is properly designed but only for previous features), first refactor the code to make the feature easy to implement, then implement the feature.
The greatest barrier to understanding is not lack of knowledge but incorrect knowledge. That's why good names matter. And naming things is hard, which is why it makes sense to comment on variable names in a review.
Unless the naming convention were written in the 90s and all variable must follow a precise algorithm to be made of only abbreviation and a maximum length of 15.
Or for some, if it contains the value of a column in the db, it must have the same name as the column.
So yeah, instead of "UsualQuantityOrder", you get "UslQtyOrd" or "I_U_Q_O"... And you must maintain the comments to explain what the field is supposed to contain.
As John Carmack said: "if a lot of operations are supposed to happen in a sequential fashion, their code should follow sequentially" (https://cbarrete.com/carmack.html).
A single method with a few lines is easy to read, like the processor reading a single cache line, while having to jump around between methods is distracting and slow, like the processor having to read various RAM locations.
Depending on the language you can also have very good reasons to have many lines, for example in Java a method can't return multiple primitive values, so if you want to stick to primitives for performances you inline it and use curly braces to limit the scope of its internals.
I can guarantee you that I have been doing just that for 20 years, creating and working on the same codebase, and that it only got better with time (cleaner code and more robust execution), though more complex because the domain itself did.
We would have been stuck in the accidental complexity of messy hacks and their buggy side effects if we had not continuously adapted and improved things.
In manufacturing there are economies of scale and adding more people increases workforce, in mindfacturing there are diseconomies of scale and adding more people increases confusion, yet many managers view software with a manufacturing mindset.
When I do functional unit tests, they tend to include the same functional logic as the code to test. What I strive for is then to express it in a different and possibly clearer way, and I see the testing as mutual testing of two implementations, one more easily humanly checkable.
reply