OU blog

Personal Blogs

Christopher Douce

The changing face of the computing classroom: BCS, London, December 2017

Visible to anyone in the world
Edited by Christopher Douce, Thursday, 7 Dec 2017, 08:33

On 24 November 2017 I found some time to visit a book launch event at the British Computer Society headquarters in London. The book was entitled: Computer Science Teacher, and was written by Beverly Clarke (who is, of course, a computer science teacher). 

The timing of this event was significant: it happened a couple of days after the UK government budget where there was particular emphasis on the need to develop and computer science teaching in schools.

This blog comes from a set of notes that I made during the event. The aim of this post is to write something to help me to remember what CPD events I’ve attended during the year, and also to share a set of useful links to colleagues who might be interested in researching the subject of computing education (I know there are a couple of colleagues who have a particular interest in this area).

Introduction

The event was introduced in the context of the changing computing curriculum. It had been five years since the new curriculum for 5 to 16 year olds had been introduced in 2013. The curriculum changes occurred as a result of a Royal Society report entitled Shut down or restart? It is interesting to note that the Royal Society site has a whole section that is dedicated to the subject of computing education  (Royal Society)

Following the report and the introduction of the curriculum, there was the publication of a new report, entitled After the Reboot – Computing Education in UK School (Royal Society) which aimed to evaluate the changes.

There remain significant challenges, and it was these that were echoed in government announcements. A key point is that have to know how to teach this stuff, and it was reported at only 30% of teachers have any background in computing. A particular challenge is primary school, where I understand that teachers have to present lessons from across the curricula. There is, however, some help at hand. There is an organisation called Computing at School and, of course, there is this new BCS book which is intended to try to help by describing the role of a computer science teacher. We were told it covers subjects such as origins of the curriculum, the importance of knowledge, attitude and skills, government teaching policy, tools, points about pedagogy and issues relating to diversity and inclusion. 

Computer Science Teacher

A really interesting (and important) point was that computing gives teachers the opportunity to develop what was presented as ‘cross-curricula engagement’. From a personal perspective, I think this is one of the things that makes computing such a great subject: it touches on every subject and aspects of our lives.

The book, Computer Science Teacher, was introduced by its author, Beverly Clarke. Beverly shared a number of useful pedagogic tips, such as the use of a wall display to emphasise women in computing and practical engagement with organisations such as Cisco. There were other tips, such as making computing resources visible in classrooms and ensuring that resources that relate to the subject are clearly available in the library. There was also initiatives such as Ada Lovelace day (FindingAda). I also made a note of the idea of: students gathering and sharing stories; a pedagogic approach where students connect their studies to current and ongoing media stories.

An important question that I had was about how to extend the appeal of computing as a subject to girls. The numbers are stark: only 20% of GCSE students and 9% of A level students are female. One approach (along with increasing the visibility of role models) is for teachers to try to directly connect with the interests of learners, whatever they may be. 

Another key point was that learning about teaching doesn’t stop when you have a PGCE and have Qualified Teacher Status; there are other things to aim for, such as the National Professional Qualification for Senior Leadership (NPQSL). 

Some interesting resources were mentioned, such as Code Club which is described as ‘a nationwide network of volunteers and educators who run free coding clubs for young people aged 9-13’ and Barefoot Computing, which appears to be a part of Computing at School.

Reflections

What I really liked about this event was that there were a number of pedagogic approaches that I recognised along with others that I hadn’t really thought about: I recognised the importance of contextualising the teaching by the use of media stories, but given that I don’t work in the school sector, the importance of wall displays (and how they can offer encouragement) had passed me by. I was also struck by the number of resources that teachers can look at, not to mention those two very big reports: if you’re interested in computer science teaching, my sense is that you really need to read them.

Other than learning about the book, there were two another reason why I went to the event: the first is to learn more about the current computing curriculum (since some younger students may begin to arrive on the level 1 computing modules having studied the new curricula; to teach well, we need to know what they know). The second reason was to put the word out that the university had been recruiting for some new computing tutors; an event where computing teaching was discussed seemed like a great place to make some contacts.

A final note is that computing in the school sector remains an interest, but since I work in higher education, I feel somewhat disconnected from it. I do feel that there’s a lot that can be learnt and shared between both of the sectors. A challenge is trying to find the time to read more and to try to develop or facilitate cross sector collaboration.

Update, 7 December 2017: After attending the workshop, I visited the Royal Society website to see what I could discover. I found there was a way to receive subject specific updates. A week or so after the event I received my first email update, which contained not only a reference to After the Reboot report, but a link to a blog entitled: Improving computing education in our schools by Sue Sentance (Kings). The email update also contained a whole host of other things too! A challenge remains, of course, trying to find the time!

Permalink Add your comment
Share post
Christopher Douce

Digital accessibility in higher and further education conference, April 2016

Visible to anyone in the world
Edited by Christopher Douce, Thursday, 5 May 2016, 12:06

I’ve been to a couple of events at the British Computer Society (BCS) before. This one was especially interesting for a number of reasons. Firstly, there are over ten thousand students with disabilities studying at the Open University, and it’s important to know what is going on in the field. Secondly, accessibility in higher education is central to a module that I tutor (H810 accessible on-line learning). Another reason, of course, was to catch up with colleagues in other institutions who work in the digital accessibility sector.

This blog post is intended for internal (and external) colleagues, and students who are studying this area. What follows is a quick summary of all the talks I attended. I also hope this summary might be useful for anyone who was at the conference.

Introductions and opening talks

The conference had the subheading: ‘meeting the needs of the increasing number of students with disabilities’. Lord Addington, spokesman for Special Educational Needs (SEN) at the House of Lords, introduced the event. He spoke about the political context, highlighting the importance of employers. A really important point was: ‘please make sure everyone knows what you can do, to make someone’s life slightly easier; let them know you have practical solutions when you talk to people outside this room’.

Accessibility for students with disabilities

The first speaker was Majid Kahn, who spoke about his experience as an undergraduate student who has a visual impairment. An early point that directly resonated with my own knowledge was the difficulties that can surround acquiring assistive technology through the UK Disability Support Allowance (DSA). Due to delays that are inherent in the process, Majid had to obtain a ‘loan’ computer from the RNIB, which arrived one month after the start of a course.

Majid said (according to my notes) that some software not was accessible through a screen reader. An accompanying challenge was accessing text books (and some books that published in PDF format are not accessible). A practical solution was to directly email the author, who could send a Word version (which would then be accessible). Since many documents and resources are accessed through institutional learning environments, Majid commented that ‘Moodle seems to be inaccessible at the moment’. This was a point that I found interesting, since I know the OU has been putting a work into trying to make Moodle accessible. Perhaps there might be differences between how Moodle is set up and used by different institutions.

Another key point was that the training available at university (in terms of how to use systems, products and assistive technologies) is not adequate. This was connected with the view that although things are heading in the right direction, there is a long way to go, and there is a lack of awareness. Awareness is connected to the importance of communication, and the acceptance that every student is different. In some situations, students may be reluctant to ask for help and advice, and some lecturers might be unwilling to offer additional support. To help to facilitate understanding it was considered important to share information; to help university staff to become more aware of the needs of students. 

An industry perspective on what to teach and how

David Sloan is an ‘accessible user experience engineer’. I know David through his publication on the notion of holistic web accessibility (Word doc, University of Bath). David’s job is to provide advice on how to develop and support digital accessibility, which is something that is often thought of ‘very late in the day’, or is considered as an afterthought.  Put another way: ‘organisations pay us to give bad news’. Rather than reporting on what doesn’t work, organisations and universities shouldn’t really focus on ‘evaluating and repairing’, but should instead focus on ‘improving practices and processes from the beginning’.

Some key problems include the lack of web development skills, understanding that not everyone uses a mouse for access, the use of colour, and media accessibility, i.e. offering alternative (useful) descriptions for graphics.

A fundamental problem can relate to the organisational perspective; accessibility not being connected to good experience design, or accessibility being ‘hived off’ into another part of interaction design. The key point is that accessibility needs to be built into development processes, and this relates to the idea of an ‘accessibility design maturity continuum’ http://uxfor.us/mature-it (Paciello group); accessibility shouldn’t be added as an afterthought.

There are a number of challenges for educators: the importance of integrating accessibility into the curriculum, that digital literacy and accessibility communication should be embedded into all subjects (and not just information technology or computing sciences), and that it should be integrated into learning activities, experiences and assessment. It is also important to include accessibility as a core professional skill.  David went on to suggest that there might be increased professionalization of accessibility, and mentioned something called TeachAccess.org (TeachAccess website).

As David was talking, I had a thought which relates to the complexities that are inherent in accessibility. Whilst it is possible to create accessible resources and accessible software, every learner is different in terms of their personal needs and their learning strategies. Learners need to develop expertise and mastery over their tools. This is, of course, something that takes time.

Accessible STEM: Anticipating and resolving barriers

Emma Cliffe works in the accessibility resource centre in the University of Bath. Emma helps to provide accessible solutions for maths, computing, and subjects that present a lot of diagrams.

When it comes to maths, a really important point is that students are expected to produce assignments that their lecturers can read; students invariably need to show their working to demonstrate their understanding of mathematical concepts. One of the issues is that some digital formats (such as PDFs, for example) are ‘lossy’, which means that they lose some of their important semantic information when PDF documents are created.

Lecturers need to provide materials in a format that retains the ‘semantic structure’ (or meaning) of the maths that they aim to teach. Emma mentioned a range of tools and formats: structured Word documents, structured HTML documents, MathML, or Tex plus something called MathJax, Markdown, or ePub3. 

As a brief aside, Tex is a typesetting language which is used with Latex, which mathematicians often use to write technical papers. I’ve used Latex in anger only once, and found it very difficult! I hadn’t heard of something called MathJax before.

 A key question is: how do you author mathematics? The answer is: it is a skill that needs to be learnt (and, of course, takes time to master). This area is one that is rapidly changing, and is difficult for disabled support allowance (DSA) assessors to keep up.

Emma moved onto looking at a subject that that cropped up in my undergraduate studies: finite state automata, which are usually represented through diagrams (using circles and arrows). A finite stage machine is an abstract machine that moves between different states of operation. The thing is, it’s pretty difficult to describe them. To emphasise this point, we were shown different types of descriptions, some more descriptive and wordy than others.

Reflecting on David’s session, I noted that we need to help students to find a choice of tools that work for them. We also need to embed accessibility into procurement processes, and figure out how to integrate accessibility in our teaching (since non accessible students can also benefit from any adjustments that we make). Collaboration is, of course, important too.

Accessibility and MOOCs

EA Draffan from the University of Southampton spoke of a range of different issues that related to accessibility. One point (and I don’t know whether this is true) is that the majority of learners are either middle aged, or elderly.

EA made the really important point that all technologies can be assistive. Some important questions to ask those working in the academic context are: why are we using certain types of multimedia? What are its barriers for use? Do all learners need it? Is personalisation possible?

Rather than presenting research findings, the main point of EA’s presentation seemed to be: MOOC designers and developers need to be mindful about the importance of accessibility. EA went onto talk about different types of accessibility checkers. (There is, of course, the accompanying issue that it can be sometimes difficult to understand and interpret the results from these checkers).

On the subject of MOOCs, I have a couple of research questions (one of which was touched on by EA). The first one is: what do MOOCs about accessibility actually teach? And, secondly, are MOOCs themselves accessible? What are the practical barriers that learners face, and what do they do to get around them?

Parallel session: accessible and adaptable materials and content

The afternoon parallel session consisted of three presentations. The first talk was about ‘how to make PDF documents accessible in virtual environments’, and was given by colleagues from AbilityNet (AbilityNet website). The advice was simple, familiar and effective: create documents using accessible tools, know your audience, don’t use long paragraphs, use headings, use bullet points to break up text, avoid graphics of text, don’t use colours to provide information, and use alternative text for images. Importantly: always consider the semantic structure of a document.

Next up, was an accessibility consultant called Ted Page, who said there were differences between technical accessibility and content accessibility. I think this means that event though something might be accessible through assistive technology, the corresponding content, if read out by a screen reader, might not make any sense at all. PDFs are, apparently, a reasonable solution, but I was interested to hear that MathML is coming to PDF documents (which should add more semantic structure to documents). This echoes Emma’s point that this is a fast moving area.

The third presentation from this session was by Joanna Hunt, from Blackboard. Joanna spoke about a new on-line real-time conferencing system that may replace Elluminate (which is the basis of OU Live, the OU’s real-time tutorial system), which relies on a Java plug-in. This additional bit of Java software can sometimes be a barrier for users. This connects to a wider point that usability and accessibility are intrinsically connected. Unfortunately, I didn’t get a feel for how the new Blackboard system may work (and its accessibility) since it is still under development.

Closing Keynote: Employment prospects of STEM graduates with Disabilities

Peter Looms, from the Technical University of Demark addressed a range of wider issues. Not only is accessibility important in terms of learning resources and classroom activities, but equal access to social activities (of course) is also important. This point is related to the social model of disability. There should be a movement away from solving problems, to removing barriers.

Other points related to the costs of exclusion: there are societal and economic impacts. Assistive technology and digital tools can often be expensive. There are also benefits to inclusion. Peter mentioned Kyle Schwanke, a Microsoft Xbox engineer who has ASD, and touched on the importance of diversity and recruitment. (More information about Kyle Schwanke can be found in a Microsoft People article). The point is that diversity should be viewed as an asset, not a burden. 

Discussion and reflections

During each of the two parallel sessions, each group was asked to consider what might be four points (or steps) to digital accessibility.

Here is a list of the combined points: the importance of consultation (with students), professionalise good teaching practice, improve access to information, put skills before disability (and use the social model of disability), consider using game technology for educating tutors, the importance of doing things the right way, the importance of standards, the importance of involving users, training tutors, and working together.

The final discussions centred upon whether the BCS could embed more accessibility into its core mission, and the extent to which the Teaching Excellent Framework (Times Higher article) may influence practice.

My main concluding thought is that there was one aspect to the conference that wasn’t a surprise, and another aspect that was a surprise. In some respects, all of the subjects and issues that were discussed were quite familiar to me: I am aware of the challenges that surround mathematics, and that we should not be ‘retrofitting’ accessibility to digital materials (but should, instead, think about accessibility from the outset). The surprise was the feeling that there is still a long way to go when it came to educating people about the importance of accessibility.

There are (at least) two reasons why it is important. Firstly, making something accessible, makes things easier for everyone. Secondly, we a moral and a legal responsibility to do something about it. 

For those who are interested, resources from the conference have been made available on the BCS website.

Permalink Add your comment
Share post
Christopher Douce

HEA new to teaching workshop

Visible to anyone in the world

On 19 February 2015, I went to something called the HEA new to teaching workshop which was a part of a larger HEA ‘transitions conference’.  Now, I’ll be the first to admit that I’m not new to teaching, but there was a bit of the workshop that I was really interested in: a section that was about how to teach introductory programming.  The reason for my interest is that teaching programming is pretty difficult: some students excel, whereas other students struggle.

The session was facilitated by Karen Fraser from the HEA.  I’ve met Karen numerous times before, but I have never been to a session that Karen ran entirely on her own.  Instead, her role has been always to facilitate and introduce other speakers.

The aims of the day were to think about and reflect on our teaching practice, consider different ways of teaching, consider what things we are doing well, and share practice between each other.  This is a quick blog summary of the event.  I’ve written it for a number of reasons: it’s a set of notes that also contains links to useful resources, a way to tell my line managers what I’m getting up to, and to share some personal reflections about the event with Open University and other colleagues.

Professions

Karen opened the session by asking us a couple of questions: ‘is computing a profession?’ and ‘is academia a profession?’  My immediate response to the first question is: yes, because there’s a body called the British Computer Society (BCS.org) which aims to develop the professionalism of those working within the computing and IT industry.

I noted down that the purpose of the HEA is to enhance professionalism in higher education.  There are a number of issues that it addresses: reward and recognition, career progression, and continuing professional development.  In some respects, these areas can be connected to something called the Professional Standards Framework (PSF) where HE professionals can apply to gain different levels of professional recognition.  Karen briefly summarised the PSF, telling us that it contained six aspects of core knowledge, five areas of activity, and four professional values.

Returning to the original question, did we hold the view that higher education is a profession?  From memory, I believe the consensus was that higher education should be viewed as one.  It was also interesting to hear that the HEA has applied for a charter to become a professional society in the same way that the BCS is.

Teaching and learning

It might sound obvious, but one of the key aspects of professionalism in higher education is the need to foster and continually update knowledge and understanding about how students learn, both generally, and within their subject or disciplinary areas.

These key points led us to a discussion about the different types of teaching techniques that we could use in our discipline.  These ranged from the use of role play, applying a technique called action learning and demonstrating, such as showing students what code looks like in a debugger.  At this point I had a thought about the virtues of animations.  When I was industry I learnt a lot when I watched another more experienced programmer at work.  This short discussion was immediately making me think about what might help students to get to grips with the fundamentals of computing.

In my notes, I made the comment: ‘pair programming: advantages and disadvantages’.  I’m not exactly sure what I meant by this, but gently picking apart this theme immediately suggests a broad range of different issues: the importance of continuous learning within the computing and IT industry, the question of what skills industry is looking for and what universities can do to help, and the importance of soft skills in subjects such as IT and computing.

Teaching introductory programming

The next part of the session moved from considering the academic as a profession to the specifics about teaching of introductory programming.

We discussed some of the problems and challenges: students need to know about different programming languages and tools, and there is also the necessity to develop problem solving skills and increase student’s awareness of strategies of programming design and implementation.  A key point was that programming is a creative exercise; it’s all about the solving of new problems.  A perpetual challenge is how to map (or translate) real world problems into code.

Karen showed us a slide that asked a single question: ‘where do students struggle and what do you think their problems are?’  During the resulting discussion, I made a note of the following points: as lecturers we can’t teach programming, we can only help students to learn it; students need to put ‘the hours in’ (since programming is like any skilled activity).  Also, the context for learning is important: we need to explain why we’re doing what we’re doing.

Other key points were: the importance of expectations, inexperience and confidence; the importance of how to decompose problems, and asking students whether they are fundamentally interested in the subject.  An interesting question (to students) could be: ‘are you prepared to be confused?’ and asking students to reflect on their own experience with computing devices and their knowledge of hardware and software.

Some other interesting points related to the activity (or exercise) of ‘making a cup of tea’, to learn the idea of problem decomposition (this, incidentally, is an exercise that some of our Open University TU100 tutors use at a programming day school).  Other skills might include the ability to identify sequences, patterns and steps (along with understanding how to do, and translate into computer code basic arithmetic).  Finally, MOOCs (free on-line courses) were mentioned as possible way to allow students to acquire background knowledge.  One thought was that perhaps a MOOC might help students transition between A-level and degree level study.

Another question was introduced: why is teaching (or learning) programming so difficult?  Some tentative suggestions were that programming is a skill, and it is something that is learnt by doing, and also programming isn’t a prerequisite for computing modules.  There is also the challenge of dealing with the syntax (or structure) of programming languages, and that students might not have experience of important concepts, such as data typing.

We were taken through two other slides: thoughts about problems with students (a lack of analytical, reasoning and planning skills?), and thoughts about problems with lecturers (a disconnect in terms of communication and issues surrounding instructional materials, teaching methods and teaching strategies). These problems can have impacts.  These might be students becoming disillusioned and the waning of enthusiasm which could lead to a failure to attend practical classes.   But what could we (as lecturers or educators) do?  Some thoughts related to the importance of learning design, early identification when students get lost, the importance of fast feedback, and the encouragement of reflection.

All this led to a discussion that had the title: ‘what delivery techniques could we use to engage students and help them understand difficult concepts?’  The group came up with the following thoughts (amongst others):  Use of the institutional virtual learning environment and flipped classrooms (Wikipedia),  the use of small groups, facilitated debates, use of media stories, the creation of animation to demonstrate ideas, translation of algorithms into ‘physical theatre’ (pretending students are different values based on height), use of robots, the idea of ‘code as a performance’ (as something the lecturers, or students create front of others, potentially also demonstrating failure), application of peer assessment, use of in-class question and response systems, helping students to create their own resources, and inviting students to present different ideas to each other.

An important point was made: research (I’m not sure which research!) has shown that students have a hierarchy of pedagogical preferences when it comes to learning programming: students like programming lab sessions more than they like working on projects.  Lectures, it seems, isn’t viewed as an effective way to teach programming.  Thinking back to my own experience as an undergraduate (when I had to learn a programming language called Pascal), I can completely relate to this.

On the subject of peer assessment, we were introduced to a system called Peerwise (University of Auckland).   I hadn’t heard of this system before.  We were shown a brief introductory video about the system (Peerwise website).   I have heard of other peer assessment systems, such as WebPA which (I understand) used to be funded by JISC.  An idle thought is that it would be interesting to do a comprehensive review of these peer assessment systems (since I seem to think there are a few other systems out there).  

After lunch…

A provocative question was posed in the first session after lunch: should programming be taught in the first year of a degree?  An alternative perspective was that perhaps we ought to first teach other subjects, such as data structures and algorithms before moving onto programming.  This way, students get the opportunity to understand more about some of the fundamental concepts of software and computing.  My own view is one that connects back to earlier discussions, namely, that since programming is a fundamental skill, and it’s something that takes a long time to master, we need to give students the experience of what is meant by programming early on in the curriculum.

The next session was about sharing good practice in lecturers.  One of the biggest take away tips from the day was the idea of changing something every fourteen minutes: divide an hour lecture into different sections that are punctuated by videos, run discussion activities or question and answer sessions, get willing students to come to the front of the class, or change the entire tenor (or tone) of a lecture by telling a story or an anecdote, or take a bit of time to introduce other resources, such as MOOCs.   Another thought is to ask students to prepare something for a tutorial (but always remember that you’ve done this! On the subject of videos, we were offered an example: a clip entitled The Friendship Algorithm (YouTube) from the comedy series The Big Bang Theory.

The workshop ended with a chat about a range of different issues.  We chatted about the importance of reflection so we can understand more about our performance as lecturers, and also the importance of reflecting on what our students have learnt from our teaching practice.  Another topic was the importance of feedback, and how feedback is perceived by students. 

A final take away point was a reference to a paper by Chickering and Gamson entitled Seven Principles for Good Practice in Undergraduate Education (Washington news centre, PDF).  Although there isn’t anything in this paper that struck me as substantially new (which was published around twenty five years ago), it does represent a neat set of principles that can be fairly easily remembered and internalised.  When I was looking through the paper, one thought was: ‘how might these principles be translated or adapted to the on-line distance education context?’ or ‘what attributes of a module design might adhere to these principles?’

Final thoughts

Not long after I joined this session, Karen said to me, ‘you’re not new to teaching, are you Chris?’ In some respects this question was a challenge.  It was also a challenge that immediately led to a reflection.  The answer was: ‘I’m not new to teaching, but I’m here to see if there is anything new I can learn’.  

I was there for two reasons.  The first reason is that one of my jobs is to help to induct new tutors to the university and to help to run associate lecturer development sessions, which means it would be useful to know how the HEA does things.  Secondly, as mentioned earlier, I have an interest in the teaching of introductory computing and programming.

The whole day turned out to be useful: Karen’s discussion about the professionalisation of higher education was interesting and informative, and the day turned out to be a useful opportunity to share teaching practice and to learn about new resources.  By the end of the day I ended up coming out of the session with more questions than I went in with.  This, of course, is a sign of a good day.

Permalink Add your comment
Share post
Christopher Douce

BCS Lecture: The Power of Abstraction

Visible to anyone in the world
Edited by Christopher Douce, Friday, 10 Aug 2018, 14:41

When I was a graduate student at the University of Manchester (or the bit of it that was once known as UMIST) I was once asked to show some potential computer science students around the campus.  At the end of the tour I ushered them to lecture which was intended to give the students a feel for what things would be like if they came to the university.

The lecture, given by one of the faculty, was all about the notion of abstraction.  We were told that this was a fundamental concept in computing.  In some respects, it felt less of a lecture about computing, but more of a lecture about philosophy.  I had never been to a lecture quite like it and it was one that really stuck in my mind.  When I left the lecture, I thought, 'why didn't I have this kind of lecture when I was an undergraduate?'  As an undergrad I had spent many a hour creating various kinds of computer programs without really being told that there was an essential and fundamental idea that underpinned what I was doing.

When I saw the British Computer Society (BCS) advertising a lecture that was about the 'power of abstraction', I knew that I had to try to make time to come along. The lecture, by Professor Barbara Liskov, was an annual BCS lecture (the Karen Spärck Jones lecture) that honours women in computing research.

All this sounds great, right?  But what, fundamentally, is abstraction?  An 'abstract' at the top of a formal research paper says, in essence, what it contains.  Abstraction, therefore, can be thought of as a process of creating a representation of something, and that something might well be a problem of some kind.  Admittedly, this sounds both confusing and vague...

Barbara began her lecture by stating that abstraction is the basis of how we implement computer software.  The real world is, fundamentally, a messy place.   Since computers are ultimately mathematical machines, we need a way to represent problems (using, ultimately, numbers) so that a computer can work with them.  As a part of her lecture, Barbara said that she was going to talk through some developments in the way that people (or computer programmers) could create and work with abstractions.  I was intrigued; this talk wasn't just about a history of programming languages, it was also a history of thought.

So, what history was covered?  We were immediately taken back to the 1970s.  This was a period in computing history where the term 'software crisis' gained currency. One of the reasons was that it was becoming increasingly apparent that creating complex software systems was a fundamentally difficult thing to do.  It was also apparent that projects were started, became excruciatingly late and then abandoned, costing astronomical amounts of money. (It might be argued that this still happens today, but that's a whole other debate which goes beyond this pretty short blog post).

One of the reasons why software is so fundamentally hard to create is that it is 'mind stuff'.  Software isn't like a physical artefact or product that we can see. The relationships between components can easily become incredibly complicated which can, in turn, make things unfeasibly difficult.  Humans, after all, have limited brain capacity to deal with complexity (so, it's important that we create tools and techniques that help us to manage this).

We were introduced to a number of important papers. The first paper was by Dijkstra, who wrote a letter to the Communications of the ACM entitled, 'Goto considered harmful'.  'Goto' is an instruction that can help to create very complicated (and unfathomable) software very quickly.  Barbara described the difficulty very clearly. One of the reasons why software is so hard is that there is a fundamental disconnect between how the program text might be read by programmers and how it might be processed or executed by a machine.  If we can create a program representation that tries to bridge the difference between the static (what is described should happen) and the dynamic (what actually happens when software does its stuff), then things would be a whole lot easier.

Another paper that was mentioned was Wirth's 'program development by stepwise refinement'. Wirth is famous for the design of two closely related languages: Pascal and Modula-2. It certainly is the case that it's possible to write software without the 'goto' instruction, but Barbara made the interesting point that it's also possible to write good, well-structured software in bad languages (providing that you're disciplined enough). The challenge is that we're always thinking about trade-offs (in terms of program performance and code economy), so we can easily be lured into doing clever things in incomprehensible ways.

Barbara spoke about the importance of modules whilst mentioning a paper by Parnas entitled, 'information distribution aspects of design methodology'. One of the great things about modules, other than that they can be used to group bits of code together, is that they enable the separation of the implementation and the interface.   This has reminded me of some stuff from my undergrad days and time spent in industry: modules are connected to the term 'cohesion'.  Cohesion is, simply, the idea that something should do only one thing.  A function that has one name and does two or more things (that are not suggested in its name) is a recipe for confusion and disaster.  But I fear I'm beginning to digress from the lecture and onto one of my 'coding hobbyhorses'.

Through a short mention of a language called Simula-67 (Wikipedia) we were then introduced to a paper by Liskov and Zilles entitled, 'programming with abstract data types'.  We were told that this paper represented a sketch of a programming language which eventually led to the creation of a language called CLU (Wikipedia), CLU being short for Clusters.

There is one question Barbara clearly answered, which is: why go to all the trouble of writing a programming language?  It's to understand whether an idea works in practice and to understand some of the barriers to performance.  Also, whenever a language designer describes a language in natural language there are always going to be some assumptions that the compiler writer must make. Only by going through the process of creating a working language are language designers able to 'smoke out' any potential problems.

Just diverting into programming language speak for a moment, CLU implemented static type checking, used a heap, and doesn't support concurrency, the goto statement or inheritance.  What it does implement is polymorphism (or the use of generics), iterators and exception handling.

Barbara also mentioned a very famous language called Smalltalk, developed by Alan Kay.  Different developments at different times and at different places have all influenced the current generation of programming languages.  Our current object-oriented languages enable programmers to define abstractions, or a representation of a problem in a way that wasn't possible during the earlier days of software.

Research directions

Barbara mentioned two research topics that continue to be of interest.  The first was the question of what might be the most appropriate design of a programming language for novices?  In various years, these have been BASIC (which introduced the dreaded Goto statement), Pascal, and more recently Java.  Challenges of creating a language that helps learners develop computational thinking skills (Wikipedia) include taking account of programming language design trade-offs, such as ease of use vs. expressive power, and readability vs. writeability, and how to best deal with modularity and encapsulation.

Another research subject is languages for massively parallel computers.  These days, PCs and tablets, more often than not, contain multiple processor cores (which means that they can, quite literally, be doing more than one calculation at once).  You might have up to four cores, but how might you best design a programming language that more efficiently allows you to define and solve problems when you might have hundreds of processors working at the same time?  This immediately took me back to my undergrad days when I had an opportunity to play with a language called Occam (Wikipedia).

There was one quote from Barbara's lecture that stood out (for me), and this was when she said, 'you don't get ideas by not working on things'. 

Reflections

I should say at the point that I haven't done Barbara's speech justice.  There were a whole lot of other issues and points that were mentioned but I haven't touched on.  I really enjoyed being taken on a journey that described how programming languages have changed.  I liked the way that the challenges of coding (and the challenge of using particular instructions) led to discussions about modules, abstract data types and then to, finally, object-oriented programming languages.

It's also possible to take a broader perspective to the notion of abstraction, one that has been facilitated by language design.  During Barbara's lecture, I was mindful of two related subjects that can be strongly connected to the notion of abstraction.  The first of these is the idea of design patterns.

Design patterns (Wikipedia) take their inspiration from architecture. Rather than design a new building from scratch every time you need to make one, why not buy a pre-existing design that has already solved some of the problems that you might potentially come up against?  There is a strong parallel with software: developers often have to solve very similar problems time and time again.  If we have a template to work from, we might arguably get things done more quickly and cheaply.

Developers can use patterns to gain inspiration about how to go about solving common problems.  By using well understood and defined patterns, the communication between programmers and developers can be enhanced since abstract concepts can be readily named; they permit short-cuts to understanding.

In some cases, patterns can be embedded into pre-existing code that can be used by developers to kick-start a development.  This can take the form of a framework, software code that solves well known problems that ultimately enables developers to get on and solve the problems that they really need to solve (as opposed to dealing with stuff such as reading and writing to databases).

Abstraction has come a long way in my own very short career as a developer. One of the biggest challenges that developers face is how to best break down a problem into structures that can be represented in a language that a machine can understand.  Another challenge lies with understanding the various tools that developers now have at their disposal to achieve this.

Note: The logo at the top of the blog is used to indicate that this blog relates to a BCS event and this post is not connected with the BCS in any other way. All mistakes and opinions are my own, rather than that of the OU or the BCS.

Permalink Add your comment
Share post

This blog might contain posts that are only visible to logged-in users, or where only logged-in users can comment. If you have an account on the system, please log in for full access.

Total visits to this blog: 2375191