Password:
Title:
Whoops again. Apparently it was the first day of the quarter, not of actual instruction, which starts on Thursday. All right. So instead I wandered around campus, wandered around the SEAS (School of Engineering / Applied Science) complex, found all my classes, and then went back to the coffee shop I posted from yesterday and worked on some code I've been working on for a new website. Since I'm using this to reflect on CS topics and my own self-education in general, I did have an interesting experience yesterday, although it is a fairly elementary observation to most experienced programmers who use multiple languages. Anyway, somehow, in the course of people talking about coding, and which language is better for x or y (x, obviously), or which language is awful (usually Perl) or wonderful (often Python), and in trying to think more abstractly about what programming languages do and why, somehow I had gotten on the path of thinking that different languages are just different ways to approach the same problem and, at least in well-developed general purpose languages the process of coding in those languages is roughly equivalent. But then I tried to convert a shell script into a python program (but I could as well have been converting to Perl). While it was possible to make it work, it got much more complicated to "say" the same thing in python than in bash. I realize this is not because what the computer does is actually simpler (ignoring different methods of run-time compiling scripts between bash and python) but because of what bash (by necessity as a shell scripting language) hides from the user or provides because of its design (i.e. using mixed types, scoping, easy access to the output of a command, etc.). I am sure there are a multitude of examples of this kind of thing, but it was enlightening for me because I had never thought concretely about how language design choices very directly affect the suitability of that language for different applications.