So the funniest thing happened recently: Risk of Rain, a well-acclaimed video game, has received an update 1.2.1 that introduced a silent bug that has significantly affected the gameplay. The circumstances are more than entertaining.
We’ve had a lot of discussions about what should go as a “bug” and what should be a “feature” in our tracker. Turns out there’s quite a big gray zone here.
“The Good Parts” has been a good read. The language has been described briefly and consistently from ground up, including a thorough explanation of objects, functions, closures and arrays. A great addition to the mix is a description of the numerous pitfalls and design problems. It seems opinionated at some points (more on this later), but very valuable as a whole. (That’s correct – “The Good Parts” actually has two appendices dedicated to the not-really-good ones.)
My commentary for selected parts of the book follows.
Recall methods. A method is some piece of code that can be “called on objects”. There are two things to methods: They’re meaningful with an object to call on, and their interface looks like “they can be called with some arguments to return a value”.
Properties are similar to methods, in that a property is meaningful when paired with an object. They have a different interface than methods, though: you don’t “call” them; instead you “get” and “set” their “current value”.
We normally consider properties and methods to be some abstract “traits” of objects. But why not treat them as first-class objects too? Imagine properties and methods as building blocks for object interfaces. A method would be an object that describes callable parts of other objects, while a property describes readable and assignable parts.
Glory is the code name of my prototype IDE for developing OpenGL-powered graphical effects. After half a year of work, it has entered a functional alpha stage (and awarded me the MSc.)
Unicode is a standard that defines several things. Here is a handful of some most important facts about it:
- There are thousands of “code points” that represent characters in various alphabets, numbers, punctuation, various symbols, etc. Each of these has a name and a number. Here are some examples:
- LATIN CAPITAL LETTER A
- LATIN SMALL LETTER C WITH ACUTE
- DIGIT SEVEN
- MINUS SIGN
- SUPERSCRIPT TWO
- RIGHTWARDS ARROW
- BLACK CHESS ROOK
- Different code points may share their appearance, or “glyph” (like OHM SIGN and GREEK CAPITAL LETTER OMEGA).
- Code points are grouped into blocks like “Basic Latin” or “Mathematial Operators”. They also are divided into categories like “Letter, Uppercase”.
- There are some “encodings” that provide a mapping between code points and their bitwise representation. The encodings have names like UTF-8, UTF-7 or UTF-32. Each of these has some interesting properties.
I couldn’t read my Git history today because I ran into this problem:
$ git log --oneline f1330fd Basic automation 7234c6e Textures work 3b18493 Fix combo defaults error: inflate: data stream error (incorrect data check) fatal: loose object 65d626bb82c8996f8fc5f659f7c207fee1d74948 (stored in .git/objects/65/d626bb82c8996f8fc5f659f7c207fee1d74948) is corrupted
The same message appeared when checking the repository with
My working copy and dozens of last commits were intact; this error showed up when trying to view more history or when trying to clone a repo. Some googling revealed that I should get the original (non-corrupted) object from somewhere and replace it.
So you want to make a project with the advantages of native code. You like the performance of fine-tuned C, you need some heavy pointer juggling or bit fiddling or SSE, or perhaps you just dream of the vast lands of C libraries available around there. But you’re in love with Python and really want to be able to glue your app together with elegant high-level code. Hard decision? Definitely.
But why can’t we have both? Using two languages together introduces complexity, but might have good payoffs for your project. Give it a shot.
A closure is basically a function that was defined in some local scope and has access to the local variables from that scope. Additionally when a closure (the function object) outlives the scope where the closed variables were defined, their lifetime gets extended (or not, depending on the language).
I find closures wildly useful, especially in prototyping. They also are welcome in production code, if you don’t get too carried away. However they are not exactly as intuitive as one might expect and if you decide to use them there’s a handful of details you must remember not to introduce bugs.
This article has two parts:
- Differences between closures in some languages
- Pitfalls related to closures that you should remember and avoid.
Also for a quick recap on closures see this gist.
Behaviour of Python objects can be customised in tons of ways using special functions. This article describes some of them, all confusingly starting with
__get and all having drastically different purposes.