Unity Programming Side-notes: The use of Resource.Load
So one afternoon I was configuring the subtitle controls for my narrative. My method was putting all the subtitle text in a .txt file and load it in via script in game.
Then I stumbled upon this error:
And my code looks like this:
Looks perfectly fine. If you don’t know how Resources.Load works, this function ONLY loads assets and files that are placed under a folder “Resources”. This folder also has to be at root level, which is directly under the Assets folder.
So why in the world did this error pop out?
Turns out that the Resource.Load does not recognize file extensions. Which means that if you pass in a file path like above, it’s not going to find your file.
So, the correct way to do it is:
(murmurs)
This reminds me of a class I took at CMU last year, in which Josh Bloch (The Great Java Master) mentioned the principle of least astonishment. It basically means that don’t design something (like API) that would have users astonished (frightened) by how it behaves every time. This is probably a good example?
You can read more about the Principle of Least Astonishment here:
"Q: What changes do you think are going to occur as CPU speed remains fixed or possibly even drops a little bit and the number of cores increases?
A: People are going to have to learn how to make effective use of those cores or are going to have to be used to the fact that programs aren’t going to get any faster. We had this free ride, this is almost trite at this point to say, but Moore’s Law gave us a free ride for a couple of decades where programs would just get faster with no effort on our part. And that’s over. At this point we are going to have to change the programs to make them run faster. There are some cases where it’s reasonably easy to do it - so called embarrassingly parallelizable problems - but many problems are not embarrassingly parallelizable and I do really see it as an open question how we’re going to make use of those processors.
A lot of excellent work has been done. I would single out Doug Lea’s Java.util.concurrent and in particular his Fork/Join framework as examples of that. They help a lot, but they take us only so far. Years ago I had a conversation with Bob Caldwell who was the lead designer of the P6 core (that is the Pentium Pro and then up through Pentium 3 were built using that core) and he told me he was really worried because for the first time that the mainstream chip industry (by which I guess he meant Intel and AMD) were producing a product for which no demand had been established.
They were producing a product because it was what they knew how to do rather than because it was what the customers had been asking for. At that time I thought "It will be OK. The techniques that we’re working on now will enable us to make use of these processors." Now I’m not so sure."
This is a video interview from two years ago (+transcript) with Josh Bloch, chief Java architect at Google. It touches a lot of very interesting topics, like for example language changes in Java 7 (Project Coin), or adding closures to Java, or the idea of a next big language after Java and C++, or the future of the Java platform in general, and many other things.
