, on 27-09-2017 at 15:05 GMT said
The Art of UNIX Programming
I've just finished reading The Art of UNIX Programming, by Eric S. Raymond. Its a fascinating book, and if you haven't read it, I highly recommend it. While I was reading it, someone asked me what it was about. The analogy that I came up with, is that this book is to programming (on UNIX and it's descendants at least) as Literature is to Language. If you've never read Tolstoy, you cannot claim to be fluent in Russian. You might have the vocabulary, however being fluent in something requires a cultural understanding. The Art of UNIX Programming gives that cultural understanding to all aspects of life, not just on on UNIX and Linux, but on programming in general. There are lessons that can be learned across all Languages (the programming sort this time), and all Operating Systems from the lowest level embedded system, to the highest level application software.
The most striking point for me was the concept of optimisation. While we all know the famous quote, 'Premature optimisation is the root of all evil', what I hadn't realised was that the quote is taken out of context. The full quote is 'Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a negative impact when debugging and maintenance are considered. We should forget about the small efficiencies, say about 97% of the time: premature optimisation is the root of all evil. Yet we should not pass up our opportunities in that critical 3%'
This full quote, along with ESR's analysis of it finally drove the point home to me: yes, I should strive to produce the best code possible, however best and fastest are not always synonymous. I used to naively think that the fastest solution to a particular task was the best, and if that created an unmaintainable mess, then so be it. The overriding point that I took away from The Art of UNIX Programming was that the best solution is the cleanest and easiest to maintain. Shaving half a millisecond off the runtime is almost inconsequential (unless you have a very quick program to start with), however adding a bug because either you or your successor didn't quite understand the complex logic is definitely not inconsequential.
By the same token, make a program run in 1 second instead of 1.5 by rewriting the entire thing in C or even Assembler is probably not worth it, if you could write it in Python in a tenth the time. The bug count in software is directly proportional to the line count, and independent of the language.
Given this fact, writing in the highest possible language will reduce your lines of code, and thus your bug count. While in some cases, higher level languages are very slightly slower, paying even 1 programmer to spend a month creating something is significantly more expensive than just buying a better computer. This point is also made by Jeff Atwood on his blog, most specifically in
Hardware is Cheap, Programmers are Expensive
. Jeff is a VB.NET/C# developer, who blogs frequently about Windows relating things. The fact that he, from a totally different background, also makes the same point just reinforces it: spending huge amounts of time on tiny optimisations is rarely worth it. Jeff Atwood and Eric S. Raymond are both looking at this from different perspectives, one from a pure cost/benefit analysis point of view, and the other from the point of view of correctness and bug counts. This simply goes to show that not only is this specific point worthy of note, but also conveniently proves ESR's point that the design philosophies of UNIX work very well, even when not used in their fully intended way.
, on 29-08-2017 at 22:23 GMT said
Possibly the worst programming language in the world.
Origins of cantabscript: cantabscript was created out of a joke suggestion to use MS Word as an IDE, in the Cambridge University Computer Science Freshers 2017 chat. The initial ideas were to use fonts for syntactic purposes, colours for types, and for the final output source to be a docx file. From there, we decided to implement it as a scripting language which transcribes to Python (for portability), and thus this project was born. The code repo can be found
The syntax rules are fairly simple:
, on 16-07-2017 at 17:38 GMT said
Given that I wrote this site as a learning exercise, it seems appropriate that I write about how I made it. I’m running a LAMP Server, using Amazon Web Services to host it. There are various versions of LAMP, but given my familiarity with Python I decided to go with Python as my language of choice. I’m using MySQL and Apache for my database and webserver, and I’m using Ubuntu 16.04 LTS as my base OS. These are mostly because they’re all offered by Amazon as a pre-installed instance so it’s nice and simple. I’m a firm believe in the concept of only doing 1 new thing at a time, rather than everything at once. On the other hand, to totally contradict myself, I also agree with Elon Musk’s dictum that ’If things are not failing, you are not innovating enough’. I would argue that the prototypes of this site failed often enough for me to claim both! The saying about not testing in production also springs to mind.
The majority of the work of the server is done by Python, using the Flask framework. I think Flask is one of the best third party tools I’ve ever coded with: It’s genuinely simple to work with, and adding a new page to the server can be done in 3 lines of code. You have access to all of the utility of Python, without adding a huge amount of boilerplate code to achieve anything. I’ve learned everything I know about Flask from
Miguel Grinberg's Tutorial
, which walks through creating a blog. Once again, I have massively diverged from the guide (He is creating something akin to Twitter), but used it as a valuable source of background knowledge.
The Law of Leaky Abstractions
pretty well, meaning that when I’m writing backend logic I never have to think about HTML. I think the only HTML in my code is one section where I’m embedding 2 pages in 1 to create the index, and have to search through for a particular tag. For that purpose, I’m using
, a Python library designed for manipulating HTML (and XML, but I haven’t tried that).
The HTML is generated entirely using
, which is a templating language written for Python. I was initially dubious about learning yet another language, but it is basically just Python embedded in curley braces. It allows you to put any python variable into the HTML, and include other HTML files wherever. This massively benefits code reuse, and makes the file for each page very simple to write and maintain. It also makes it very easy to create a new page - I don’t have to worry about including the header and title - I just type the content I want and the templating engine does the rest.
, on 15-07-2017 at 23:10 GMT said
Good Evening All,
Firstly, welcome to my new website, 192-168.co.uk
I’ve built this partly to have a crack at web development, but mostly becuase I wanted somewhere that I could post my opinions. I’ve read quite a few people’s blogs, and like the idea of being able to have my say on things I think are important (and hopefully have someone read it!)
Based upon my interests, this will primarily be about programming, and wider Computer Science related matters. I’ll probably dip into current affairs occasionally, but not too often.
So, firstly, I thought I’d say a little bit about me. My name is Rosie Baish, I’m a programmer, and a bit of a general nerd. I mostly working in C++ and Python, but I am also currently writing an OS in ARM Assembly, as a project to learn about various things. When I’m not programming, I enjoy reading, rowing and going to the Gym. My Code repo can be found
, Currently only has a couple of projects in it, but I’ll make more of them public when they are in a vaguely acceptable state!