note: this was a post I wrote about 6 months ago and never published.
Ever since deciding to pursue a computer science/IT degree, I've been trying to remember what my first encounters with computers were like. I've been using Mac computers all my life and since it's Apple's 30th birthday this year, I thought it'd be a good time to try and write about my Mac usage over the years.
My parents had a lot of historic Mac computers. In fact, even the computer that got used on a daily basis probably became historic after a while, considering the amount of time it took before OS X was adopted in our household (I don't know the year exactly, but I can estimate).
One of our historic computers still turned on. It was a Macintosh LC and we referred to it as 'the Dinosaur'. I have no idea what I actually did on it, but I remember the computer itself vividly - especially the purple stripes on the screen when it failed to boot (which was most of the time) and the creaking noises it made.
There's a long list of computer failures in my memory: dead backlights, video cards, hard drives, power cords, you name it. I experienced several iBook deaths and I still remember the events leading to them in detail. One iBook started making a horrible grinding noise; I'm pretty sure the hard drive got replaced shortly afterwards. One refused to boot after I'd been carrying it around all day in 40 degree weather. One particularly bizarre and prolonged death involved behaviour similar to a broken record: everything would freeze, weird graphics glitches would appear and the last few seconds of any playing audio or video would loop endlessly.
I think the iBook that replaced that one was my last, and it was a great little computer. After my mum gave me her old Macbook, I gradually stopped using the iBook, which became more and more lethargic and eventually died peacefully from loneliness.
About a year ago, the trackpad on the Macbook became very slow and unresponsive and eventually got 'stuck', forcing me to turn it off and use a mouse instead. The trackpad functionality intermittantly returned, and currently seems stable. Meanwhile, during the last couple of months something inside the laptop has started making a gentle growling noise, leading to the nickname "ol' growly".
That Macbook is 8 years old now, still running Tiger, and it's going a similar way as the
last iBook. I have a policy of turning it on every now and then to keep
it alive, but it's hard to find a reason to do that. Its replacement, running Kubuntu, is the first non-Mac I've ever had. I miss many things about OS X, but I'm enjoying the Linux Experience. Er, I mean using Linux.
Showing posts with label tech. Show all posts
Showing posts with label tech. Show all posts
Tuesday, 26 August 2014
Friday, 14 March 2014
In defense of the command line and the humble text editor
I recently embarked on a new university subject - an introduction to Java programming - as part of my CS/IT degree, and cringed slightly when I heard we were advised (though not forced, thankfully) to use Eclipse. I've had some experience with Eclipse already, using it for Android development, and my overall impression was that it has almost as many features as it does bugs/'features'.
I wasn't looking forward to battling with that again, but it occurred to me that a lot of the things I find annoying about Eclipse could probably be customised/turned off in the preferences, so I decided to give it a go. After all, it does have some useful features, and I thought manually compiling code from the command line would be impractically tedious for assignments later on in the course.
In spite of some ridiculous issues which I can't be bothered relating (long story short: the only version of Eclipse I can use crashes if I try to modify the preferences), for the first week of my new subject I did, in fact, use Eclipse. If I'd been able to do so without it crashing, I might have turned off a lot of its autocompletion features and other things that save typing and make for lazy coding. However, it's hard to resist being lazy, and the way Eclipse is designed also means it's almost difficult to write classes and main methods yourself. Eclipse wants to do everything for you. That's very nice - and very bad for a newbie like me. I'll explain why in a minute.
Today I finally decided I wasn't going to put up with Eclipse anymore, so I moved all my source code out of the Eclipse workspace into appropriate folders for each week of my uni subject, opened up a terminal and Sublime Text, and tried to write a main() method.
I realised I had no idea how to.
It's not like I haven't seen hundreds of them by now; it's just that I've never had to remember how to write them because I've never needed to write them. Eclipse auto-generates these things.
I spent all day manually compiling and running Java code, and I've learnt more than I did in a week of writing similar programs in Eclipse. I consider it a privilege to be able to learn by trial and error, see exceptions and syntax errors pop up and try to figure out what's going on all by myself without the little lightbulbs and red 'X's that Eclipse gives you. I relish the fact that I can leave a variable unused for as long as I like without being given a wiggly yellow line and a warning that says 'you haven't used this variable yet!' I enjoy being able to make mistakes without being admonished. But most of all, I love having to remember how to do things.*
It turns out that Sublime Text - an excellent programmer's text editor - has many of Eclipse's better features, including autocompletion, so perhaps it's not so humble after all. However, the fancier features are unobtrusive enough that I barely noticed they were there.
The only autocompletion I use is for variables and methods I've already typed out at least once; Sublime Text doesn't seem to offer autocompletion for things you haven't already typed. I discovered an exception to that rule (and there are probably others) - it does offer autocompletion for the main() method, which I only allowed myself to use once I was confident I knew how to write it by myself. There's also an option for auto-closure of brackets and strings, but that was one of the features I hated in Eclipse so I'm leaving it off. For now, closing brackets and quotes are too firmly embedded in my muscle memory.
It's slightly scary to realise that if I'd gone on letting Eclipse practically write code for me, if someone had sat me down in front of Vim and asked me to write a Java program I probably wouldn't have been able to.** Until I know enough about Java to be able to work on the kind of big projects that Eclipse is essential for, I refuse to succumb to laziness.
*the whole 'not crashing' thing is pretty great, too.
**without googling anything!
I wasn't looking forward to battling with that again, but it occurred to me that a lot of the things I find annoying about Eclipse could probably be customised/turned off in the preferences, so I decided to give it a go. After all, it does have some useful features, and I thought manually compiling code from the command line would be impractically tedious for assignments later on in the course.
In spite of some ridiculous issues which I can't be bothered relating (long story short: the only version of Eclipse I can use crashes if I try to modify the preferences), for the first week of my new subject I did, in fact, use Eclipse. If I'd been able to do so without it crashing, I might have turned off a lot of its autocompletion features and other things that save typing and make for lazy coding. However, it's hard to resist being lazy, and the way Eclipse is designed also means it's almost difficult to write classes and main methods yourself. Eclipse wants to do everything for you. That's very nice - and very bad for a newbie like me. I'll explain why in a minute.
Today I finally decided I wasn't going to put up with Eclipse anymore, so I moved all my source code out of the Eclipse workspace into appropriate folders for each week of my uni subject, opened up a terminal and Sublime Text, and tried to write a main() method.
I realised I had no idea how to.
It's not like I haven't seen hundreds of them by now; it's just that I've never had to remember how to write them because I've never needed to write them. Eclipse auto-generates these things.
I spent all day manually compiling and running Java code, and I've learnt more than I did in a week of writing similar programs in Eclipse. I consider it a privilege to be able to learn by trial and error, see exceptions and syntax errors pop up and try to figure out what's going on all by myself without the little lightbulbs and red 'X's that Eclipse gives you. I relish the fact that I can leave a variable unused for as long as I like without being given a wiggly yellow line and a warning that says 'you haven't used this variable yet!' I enjoy being able to make mistakes without being admonished. But most of all, I love having to remember how to do things.*
It turns out that Sublime Text - an excellent programmer's text editor - has many of Eclipse's better features, including autocompletion, so perhaps it's not so humble after all. However, the fancier features are unobtrusive enough that I barely noticed they were there.
The only autocompletion I use is for variables and methods I've already typed out at least once; Sublime Text doesn't seem to offer autocompletion for things you haven't already typed. I discovered an exception to that rule (and there are probably others) - it does offer autocompletion for the main() method, which I only allowed myself to use once I was confident I knew how to write it by myself. There's also an option for auto-closure of brackets and strings, but that was one of the features I hated in Eclipse so I'm leaving it off. For now, closing brackets and quotes are too firmly embedded in my muscle memory.
It's slightly scary to realise that if I'd gone on letting Eclipse practically write code for me, if someone had sat me down in front of Vim and asked me to write a Java program I probably wouldn't have been able to.** Until I know enough about Java to be able to work on the kind of big projects that Eclipse is essential for, I refuse to succumb to laziness.
*the whole 'not crashing' thing is pretty great, too.
**without googling anything!
Monday, 16 December 2013
notes vs. tones, digits vs. numbers
There is a little linguistic problem that I've been puzzling over quite a lot recently. It concerns what can probably be best described, in abstract terms, as differentiation between quantity and value in sets.
I first ran into this with number theory, working with the different numerical bases - hexadecimal, binary, decimal - that are relevant in computer science, as I needed to be able to refer to the length of, say, a bit pattern or hexadecimal number separately to the actual values that appeared in it.
In binary this is pretty easy, as there are only 2 possible values. However, if I said 'a byte has 8 digits', and you didn't have the assumed knowledge about binary, it could be misunderstood to mean a byte has 8 values, which would be incorrect, since a byte can only contain some combination of 2 values: 0 and 1. This confusion arises out of the ambiguity of the term digit: does 'digit' refer to the value of an item in the byte, or to the number of items in the byte regardless of their value? In this case, if you know anything about binary, the meaning is obvious, but there are other similar situations where it may not be.
It seems that most often digit is understood to refer to a quantity of items and number is understood to refer to the value of any item. However, all the dictionaries I've checked in seem reluctant to make such a clear distinction, the two words are listed as synonymous, and in reality they are often used interchangeably, making use of either one subject to misinterpretation.
The problem crops up again in music. For example, when we say '4 notes', are we referring to any 4 instances of an item (for example, four B flats), or are we referring specifically to 4 unique values (for example, a set of 10 items in which only four values, say A, F, D and B flat, occur)?
Officially there are separate words to describe quantity and value in music: note is to tone* what digit is to number - the former describes a quantity, the latter a unique value. But again, the two terms get used interchangeably, making it difficult to ensure any description of musical patterns is absolutely unambiguous. What am I missing here?!
In writing this blog post, I made an unsettling discovery: I kept trying to use general words that describe quantity or value, only to discover they could potentially be misinterpreted. Range is one such word. I was initially going to use this term instead of quantity, until I realised it could be misinterpreted in much the same way as digit or number. Are we referring to the number of items in the set, or the number of values occurring in the set? Range is perfectly correct in either context.
Also note how it's almost impossible to discuss these issues without using that pesky term number. In this post I've replaced as many occurrences of the word as possible with quantity, but I've left the ones in the previous paragraph untouched to demonstrate how much we rely on potentially ambiguous language.
One final thought, venturing into even more abstract territory: consider that we say 'number of digits'. This requires some recursive thinking: the digits are a set in which various values, known as numbers, can be stored. Another set, called a number, contains the digits which contain the numbers...see the problem with this terminology?
*gotta love that tone is an anagram of note eh
I first ran into this with number theory, working with the different numerical bases - hexadecimal, binary, decimal - that are relevant in computer science, as I needed to be able to refer to the length of, say, a bit pattern or hexadecimal number separately to the actual values that appeared in it.
In binary this is pretty easy, as there are only 2 possible values. However, if I said 'a byte has 8 digits', and you didn't have the assumed knowledge about binary, it could be misunderstood to mean a byte has 8 values, which would be incorrect, since a byte can only contain some combination of 2 values: 0 and 1. This confusion arises out of the ambiguity of the term digit: does 'digit' refer to the value of an item in the byte, or to the number of items in the byte regardless of their value? In this case, if you know anything about binary, the meaning is obvious, but there are other similar situations where it may not be.
It seems that most often digit is understood to refer to a quantity of items and number is understood to refer to the value of any item. However, all the dictionaries I've checked in seem reluctant to make such a clear distinction, the two words are listed as synonymous, and in reality they are often used interchangeably, making use of either one subject to misinterpretation.
The problem crops up again in music. For example, when we say '4 notes', are we referring to any 4 instances of an item (for example, four B flats), or are we referring specifically to 4 unique values (for example, a set of 10 items in which only four values, say A, F, D and B flat, occur)?
Officially there are separate words to describe quantity and value in music: note is to tone* what digit is to number - the former describes a quantity, the latter a unique value. But again, the two terms get used interchangeably, making it difficult to ensure any description of musical patterns is absolutely unambiguous. What am I missing here?!
In writing this blog post, I made an unsettling discovery: I kept trying to use general words that describe quantity or value, only to discover they could potentially be misinterpreted. Range is one such word. I was initially going to use this term instead of quantity, until I realised it could be misinterpreted in much the same way as digit or number. Are we referring to the number of items in the set, or the number of values occurring in the set? Range is perfectly correct in either context.
Also note how it's almost impossible to discuss these issues without using that pesky term number. In this post I've replaced as many occurrences of the word as possible with quantity, but I've left the ones in the previous paragraph untouched to demonstrate how much we rely on potentially ambiguous language.
One final thought, venturing into even more abstract territory: consider that we say 'number of digits'. This requires some recursive thinking: the digits are a set in which various values, known as numbers, can be stored. Another set, called a number, contains the digits which contain the numbers...see the problem with this terminology?
*gotta love that tone is an anagram of note eh
Friday, 23 August 2013
Seeing music through the eyes of a programmer
I always intended this blog to have a music-only focus. I've often found myself wanting to blog about other things that interest me, but always refrained because it would have been outside the scope of the topic. However, I'm going to make a slight exception for this post because although it isn't exclusively music-related, music does come into it and I think it might be of interest to the very few people who read my blog.
A couple of years ago I did a web design course, learned about HTML and CSS, and loved it. This encouraged me to pursue IT further, and 3 months ago I enrolled in an introductory computer programming course which is just coming to an end at the time of writing. Although the course only taught the very basics of programming, even within a few weeks of starting it I had begun to 'think like a programmer'. Let me provide a few examples of what I mean.
There is a weatherboard house in my street which has always fascinated me because of the unusual staining of the wood. It appears that over time the stain on the boards exposed to the weather (furthest away from the eaves) wore off. The result is a perfect gradient, with the boards near the bottom of the house very pale and those directly under the eaves still a dark brown color. I found myself trying to figure out how I could write a program to manipulate an image to create the same effect. I never actually did it, but later on in the course we worked with gradients so I got to experiment then.
More recently, I attempted to draw parallels between music and programming from a conceptual point of view. In case any geeks are curious to know what I actually came up with, it was along these lines (I added the 'print' statement just to make it do something; it's kind of cool because it shows you the bars and the strong beats in each bar):
for bar in range (120):
for note in range(1, 4, 2):
print bar, note
The idea is a piece 120 bars in duration, where each bar is in 4/4 time and contains 2 minims. Obviously a very boring piece of music (where every note is the same duration!) but I needed something that simplistic to be able to translate it to this context at all.
The thing I love about studying programming is it's given me a whole new perspective, not just on music but on EVERYTHING. It's made me think about everything from a logical, even a slightly mathematical, perspective, and it's also made me realise that, contrary to what I've always thought, I don't actually hate maths.
Learning Jython has been intense and pretty stressful at times, but in the past 3 months I've discovered that although programming can be incredibly frustrating, the thrill when you finally solve a problem you've been scratching your head over for weeks is huge. I can't wait to move on to learning Java. In the meantime, to relax a little (haha, we'll see about that...) I'm returning to web design, this time to learn JavaScript.
A couple of years ago I did a web design course, learned about HTML and CSS, and loved it. This encouraged me to pursue IT further, and 3 months ago I enrolled in an introductory computer programming course which is just coming to an end at the time of writing. Although the course only taught the very basics of programming, even within a few weeks of starting it I had begun to 'think like a programmer'. Let me provide a few examples of what I mean.
There is a weatherboard house in my street which has always fascinated me because of the unusual staining of the wood. It appears that over time the stain on the boards exposed to the weather (furthest away from the eaves) wore off. The result is a perfect gradient, with the boards near the bottom of the house very pale and those directly under the eaves still a dark brown color. I found myself trying to figure out how I could write a program to manipulate an image to create the same effect. I never actually did it, but later on in the course we worked with gradients so I got to experiment then.
More recently, I attempted to draw parallels between music and programming from a conceptual point of view. In case any geeks are curious to know what I actually came up with, it was along these lines (I added the 'print' statement just to make it do something; it's kind of cool because it shows you the bars and the strong beats in each bar):
for bar in range (120):
for note in range(1, 4, 2):
print bar, note
The idea is a piece 120 bars in duration, where each bar is in 4/4 time and contains 2 minims. Obviously a very boring piece of music (where every note is the same duration!) but I needed something that simplistic to be able to translate it to this context at all.
The thing I love about studying programming is it's given me a whole new perspective, not just on music but on EVERYTHING. It's made me think about everything from a logical, even a slightly mathematical, perspective, and it's also made me realise that, contrary to what I've always thought, I don't actually hate maths.
Learning Jython has been intense and pretty stressful at times, but in the past 3 months I've discovered that although programming can be incredibly frustrating, the thrill when you finally solve a problem you've been scratching your head over for weeks is huge. I can't wait to move on to learning Java. In the meantime, to relax a little (haha, we'll see about that...) I'm returning to web design, this time to learn JavaScript.
Subscribe to:
Posts (Atom)