hazelnut-tree

This 1998 paper discusses the gap between Computer Science (theoretical and mathematical foundations) and everyday practical programming.

Here are some extracts from the paper:

> CS (Computer Science) emphasis is placed upon theoretical and mathematical foundations of computing, while IS (Information Systems) concentration focuses on pragmatic applications and business uses of computers. Each of these sub-disciplines has little use for the other.

> Computer scientists denigrate the inelegant nature of the typical COBOL or spreadsheet business application, while information systems specialists decry the inability of the computer scientist to communicate effectively with users.

> It’s probably a dangerous oversimplification to call CS adherents theorists and IS advocates practitioners, but as long as we remember the importance of both areas, as highlighted by the following paraphrased words of adult education specialist Dugan Laird, we can make use of the above terms: Theory without practice is mere speculation, while practice without theory is only anecdote.

----

Is Computer Science too distant from practice? Although this paper is from 1988, it's concerns are still relevant. I can recommend the following YouTube interview with Charles Severance (Dr Chuck) the instructor for the massive popular Coursera course: Python for Everyone from the University of Michigan (from the School of Information, not from the Computer Science division). It’s a fascinating discussion.

Computer Science isn't programming / How to become a Master Programmer / Featuring Dr Chuck - https://www.youtube.com/watch?v=z3o6yEzcnLc

I posted a talk on HN recently about four programming languages from the 1970s - Smalltalk was one of the languages discussed.

Smalltalk has a object-oriented programming model (OOP) with notable differences to the more familiar OOP model from languages like Java and C#. Smalltalk also has an windowing IDE (eschews separate text files), a consistent model, and minimal syntax (just 3 keywords). It's a very interesting language.

Here's a Smalltalk demo from the talk: Four Languages from Forty Years Ago (2018) (44min mark): https://youtu.be/0fpDlAEQio4?t=2641

This excellent and stimulating talk (including slides) examines four programming languages from the 1970s:

- SQL

- Prolog

- ML (Meta Language)

- Smalltalk

- A surprise bonus language revealed near the end of the talk

Presentation description:

"The 1970’s were a golden age for new programming languages, but do they have any relevance to programming today? Can we still learn from them?"

"In this talk, we’ll look at four languages designed over forty years ago — SQL, Prolog, ML, and Smalltalk — and discuss their philosophy and approach to programming, which is very different from most popular languages today."

Some quotes from the talk:

"So what can we learn from the 1970s? Some interesting things that we haven't really caught up [today]...Pretty much everything that we can think of as modern programming happened in the 1970s"

The following programming paradigms stabilised by the early-1980s: Imperative, Object-oriented, Functional, Symbolic, Logic, Stack-based:

"What's interesting is all these paradigms really solidified by the late 70s and early 80s, and these are the paradigms we still use today. We really haven't progressed that much."

Although I use syntax highlighting, I realise it's a habit I use without much thought. A counterpoint: most programming books are printed in black-and-white, and program listings (even with longer program listings) are perfectly readable in black-and-white.

An alternative to writing a formal specification: write you app's 'readme' before you start any coding. An 'readme' can be more approachable than a formal specification. The idea is called 'Readme Driven Development'.

This article describes more:

Readme Driven Development: https://tom.preston-werner.com/2010/08/23/readme-driven-deve...

The Microwriter is a one-handed portable digital word processor from 1978. It has an excellent 'New user's guide' that is easy-to-read and full of humour too.

The user guide is written as a conversation between the "author" and a cartoon picture of a key (button) with a face, arms and legs. The key represents the impatient and inquisitive user who can't wait to start using the device. It's worth remembering that most users where unfamiliar with computer jargon:

<author> Don't worry: correcting is easy but first you must learn about COMMANDS.

<cartoon key> Sounds a bit military!

---

<Section title> Carriage-returns

<cartoon key> Train going backwards?

<author> No!

---

Microwriter New user's guide [PDF, 18mb] https://www.microsoft.com/buxtoncollection/a/pdf/Microwriter...

Aside: Bill Buxton, the computer scientist and designer, had this to say of the guide: "I think that the New User’s Guide is one of the best examples of technical writing that I have ever seen in a user’s manual. I love the parallel use of different representations to get the message across. I really appreciated it when I was learning, and think that the manual is worth studying for its approach."

This is a long paper with lots of interesting insights. The authors also address the flaws in their method and data skew. These are listed at the end of the paper.

Below is a summary of the paper:

Purpose

This work is motivated by the need to understand the problems and difficulties that developers encounter in using Git commands.

Introduction

- We (the researchers) analyzed 80,370 questions from Stack Overflow (SO) about Git. We identified the Git commands frequently associated with difficult questions.

- We also surveyed 92 developers with experience of using Git commands both from academia and industry (qualitative survey).

- Git comes with a disputed and discussed issue about whether it is easy to learn.

- Some developers say Git is difficult to learn; Git commands are often used, but not fully understood.

- Three of the top-five questions on SO are about Git commands. The top question, “How do I undo the most recent local commits in Git,” has more than 22k votes and 9m views. This suggests there is some confusion about the use of Git commands.

Popularity of Git-related questions

There are 80,000 Git command-related questions on Stack Overflow from 2008 to 2020. The percentage of Git command-related questions and questioners has remained relatively stable. Meanwhile, Git command-related questions on Stack Overflow have higher average numbers of views, favorites, and scores.

Do Git questions come from novices or experienced developers?

Many Git questions are asked by developers who have been registered on Stack Overflow for a long time. After 2017, about 40% of the questioners of Git command-related questions had been registered for more than four years at the time of asking the questions, compared to that over 50% of all questioners on Stack Overflow had been registered for less than 2 years.

This suggests that even developers with years of development experience can have trouble using Git commands.

What Git commands are more popular among the questions asked by developers?

Git commands (e.g., git revert and git reflog) about recovery are among the most popular commands asked, followed by supporting Git commands (e.g., git clean and git help), and commands for branching and conflict resolution (e.g., git mergetool and git branch). Git commands are often used in combination to fulfill tasks.

Command difficulty

In terms of the percentage of questions with no accepted answers, some of the seldom used Git commands (e.g., git pack-redundant and git http-push) are ranked high.

Commands that are asked in quite a number of questions with low percentages of accepted answers (e.g., git credential and git submodule) tend to be those can be used in complex scenarios.

How do developers learn to use Git commands? (Responses from qualitative survey)

Most respondents (from both the academia and the industry) considered their expertise level of using Git commands to be only advanced beginner or competent. A vast majority (81.7%) of all the learning approaches used by our respondents were self-learning (i.e., from the internet and the documentation). Many respondents stressed the importance of understanding Git basic concepts and principles first.

Summary: Five short fun videos that kids (and the grown-ups) might enjoy. Created by 'BBC Teach'.

- What is decomposition?

- Recognising patterns

- What is abstraction?

- What is an algorithm?

- Checking your algorithm

Lot's of excellent critiques and comments in this thread.

Wirth has spent most of his life in an academic environment which have shaped his opinions on teaching programming. He believes strongly that teaching programming is most effective when students can grasp the entirety of a small language.

Below are a few quotes from Wirth taken from a 2018 interview. I find myself agreeing with his opinions:

On designing a programming language:

"...a language designer picks ideas from others, facilities, features, and has the task of putting them into a coherent whole, into a framework. And that is less easy than people might think, because you want to have as much power in the language as possible, yet a compact structure and compact syntax. And that you can get I think only through experience with language design."

On teaching a first programming language

"..as I did in the Pascal times, the foundations have been laid when a person learns his first programming language. That’s the key. In order to do a good experience, you have to have a clean language with a good structure concentrating on the essential concepts and not being snowed in. That is my primary objection to the commercial languages – they’re simply too huge, and they’re so huge that nobody can understand them in their entirety. And it’s not necessary that they’re so huge."

On further development of Oberon:

"The incentive came from colleagues mentioning that they had learned very, very much from my book called Project Oberon, which is one of the very few describe a full system and its development in detail. That’s something in computer science that is wrong. People learn to write before they have learned reading."

Niklaus Wirth is the creator of the languages Pascal, Modula-2 and Oberon. Wirth used Oberon to write a complete desktop computer system, documenting the software design of the system in a freely available book. The Project Oberon website succinctly describes the project:

"Project Oberon is a design for a complete desktop computer system from scratch. Its simplicity and clarity enables a single person to know and implement the whole system, while still providing enough power to make it useful and usable in a production environment. This website contains information and resources for exploring and using the system. The project is fully described in Project Oberon: The Design of an Operating System, a Compiler, and a Computer — written by the designers, Niklaus Wirth and Jürg Gutknecht."

http://www.projectoberon.com/

The Peter Principle states "In a hierarchy every employee tends to rise to his level of incompetence".

The principle was coined by Canadian educator Laurence J. Peter (1919 - 1990). Below are some quotes from Peter from the video:

"I saw that very often...the competent individual was promoted to something he couldn't do."

"I saw competent engineers getting promoted to supervisory positions - they were great at dealing with things, and incompetent at dealing with people. And over and over again I saw this this phenomenon and I called it the Peter Principle."

"The Peter Principle states very simply that in any hierarchy an employee tends to rise to his level of incompetence."

"I'm not saying people shouldn't accept promotions - some people should. Some people enjoy power, a joy [in] authority, enjoy responsibility. And others find it a burden - it drags them down. It makes them feel that they're responsible for more than they should be."

"Should we go throughout life being conditioned to keep on accepting that next reward? To keep on running like a squirrel in a cage to keep on striving for that carrot on the stick? Or should we use our ability to be rational and think about where am I going? What is the purpose of my life? Is reward through promotion the reward for me? Or are there other rewards through other aspects of living? This is the question."

"This is where the Peter Principle written as humour as satire to help people laugh at the problem can actually help people make some of these very important decisions in their own lives."

The following presentation called How to speak on YouTube is excellent and very popular. The talk is given by Patrick Winston (1943 – 2019) who was a professor at MIT (Massachusetts Institute of Technology).

Description: "The talk is intended to improve your speaking ability in critical situations by teaching you a few heuristic rules."

https://www.youtube.com/watch?v=Unzc731iCUY

Aardman's stop-motion TV series Shaun the Sheep also does not use speech and relies on visual comedy. There are even two feature-length films - both devoid of any dialogue or narration.

Niklaus Wirth is the creator of Pascal, Modula-2 and Oberon. He believe strongly that teaching programming is most effective when students can grasp the entirety of a small language.

Below are a few quotes taken from a 2018 interview with Wirth on the topic:

> "I thought, as I did in the Pascal times, the foundations have been laid when a person learns his first programming language. That’s the key.

In order to do a good experience, you have to have a clean language with a good structure concentrating on the essential concepts and not being snowed in. That is my primary objection to the commercial languages – they’re simply too huge, and they’re so huge that nobody can understand them in their entirety. And it’s not necessary that they’re so huge."

On further development of Oberon:

"The incentive came from colleagues mentioning that they had learned very, very much from my book called Project Oberon, which is one of the very few describe a full system and its development in detail. That’s something in computer science that is wrong. People learn to write before they have learned reading."

Niklaus Wirth is best known as the creator of Pascal, Modula-2 and Oberon. He received the ACM Turing Award in 1984.

A recurring theme in his career is the emphasis on simplicity and clarity in programming.

Below are a few quotes taken from the interview.

All language designers are influenced by other languages and ideas and hardware:

"...a language designer picks ideas from others, facilities, features, and has the task of putting them into a coherent whole, into a framework. And that is less easy than people might think, because you want to have as much power in the language as possible, yet a compact structure and compact syntax. And that you can get I think only through experience with language design."

Was the Oberon language and system created mostly for teaching purposes? Or was it intended for a wider audience?

"Well, by that time, my ambitions had become more modest. There was obviously no way to play an influence next to Java and C# and C++...But yes, I thought, as I did in the Pascal times, the foundations have been laid when a person learns his first programming language. That’s the key.

In order to do a good experience, you have to have a clean language with a good structure concentrating on the essential concepts and not being snowed in. That is my primary objection to the commercial languages – they’re simply too huge, and they’re so huge that nobody can understand them in their entirety. And it’s not necessary that they’re so huge. But people don’t want to see that. Particularly industry doesn’t. I think the industry thinks it’s a big asset to have a complex thing that increases their reputation of being sophisticated."

On further development of Oberon:

"The incentive came from colleagues mentioning that they had learned very, very much from my book called Project Oberon, which is one of the very few describe a full system and its development in detail. That’s something in computer science that is wrong. People learn to write before they have learned reading."

What are the unifying themes behind his work?

"Well, the unifying theme...is probably 'Make things as regular and as well-structured and as simple as they can be without losing sight of their purpose.'

Undue complexity is a bad thing. And it’s unnecessary. Except in the modern commercial world, it’s often used to hide inadequacies. If something is not transparent, it’s much harder to copy it."

This article (2011) about the Microwriter is from Bill Buxton, the well-known computer scientist and designer.

Computing history is full of interesting hardware and software ideas that have mostly forgotton - this is an intriguing device from that history.

Despite the age of this old technology, Buxton says the device has clever design touches that aid how users learn to use the device. Buxton says it takes about 60 minutes to learn touch type - impressive compared to a standard keyboard.

Also, the user's guide is excellent. Buxton again: "I think that the New User’s Guide is one of the best examples of technical writing that I have ever seen in a user’s manual. I love the parallel use of different representations to get the message across. I really appreciated it when I was learning, and think that the manual is worth studying for its approach."

New user's guide [PDF] https://www.microsoft.com/buxtoncollection/a/pdf/Microwriter...

I like the documentation first approach, but I understand that it does not work for everyone.

Designing a program (on paper or the screen) before you start coding is still the recommended textbook approach from university courses and books.

I think of documentation in the broadest form. For example, flow diagrams, or rough wireframes of screens in your app. Figma (and other tools) is good for creating rough app prototypes with short annotations describing features. You get the benefit of fleshing out flows and screens or pages (before coding) but without heavy documentation.

A popular UX technique you can try by yourself (or with colleagues) called 'Design The Box' can also be used before you start coding. It's an exercise to articulate the key features and benefits of your app: https://gamestorming.com/design-the-box/

Pinterest is still popular. When it adopted mandatory sign-in to browse the site many years ago, it undoubtedly turned some users away.

I've been using Pinterest for a long time and more recently it feels that adverts are more prevalent and more prominent than in earlier years.

Despite those changes, Pinterest is still useful for finding visual inspiration. It's a richer source of finding images compared to Google images.

Some popular image categories:

- Recipes (searching for recipes by photo results can be more effective than text-only search)

- Travel

- Architecture

- Interior design

- Anything relating to visual design (illustration, typography, web design, comics, etc.)

One final point: many 'pins' link to blogs and sites that would never turn up in a Google search (or are buried in Google results). Sometimes that makes Pinterest a more serendipitous browsing experience compared to Google search.

There is a difference between a simple language and a small language - sometimes they are the same thing, in other cases the language is small but not necessarily simple.

The C language is a relatively small language, but has been used to write complex databases and operating systems. So is C simple or complex? Or both? (Everyone has a different opinion).

Also, there's also a distinction from the small language core (the syntax and lanuage features) and the much bigger standard library that provides additional functionality.

Niklaus Wirth, the creator of Oberon (and Pascal and Modula-2) has been in the small programming camp all his professional life. I also agree with his views.

One of the advantages of small languages is that you can actually learn or master the whole language. However, small doesn't always mean simple. An example is the frequent discussion over Go's supposed simplicity. Other new languages fall in the medium-to-large size: Julia, Nim, Rust, Swift, Kotlin, Crystal.

Back to Niklaus Wirth and his thoughts on Oberon:

> There was obviously no way [for Oberon] to play an influence next to Java and C# and C++...But yes, I thought, as I did in the Pascal times, the foundations have been laid when a person learns his first programming language. That’s the key. In order to do a good experience, you have to have a clean language with a good structure concentrating on the essential concepts and not being snowed in.

> That is my primary objection to the commercial languages – they’re simply too huge, and they’re so huge that nobody can understand them in their entirety. And it’s not necessary that they’re so huge. But people don’t want to see that. Particularly industry doesn’t. I think the industry thinks it’s a big asset to have a complex thing that increases their reputation of being sophisticated.

(From a 2018 interview with Niklaus Wirth: https://www.youtube.com/watch?v=SUgrS_KbSI8)

This is a treasure chest of computer-related papers from 1951 - 2000. The topics span the full breadth of computing, including topics that might not immediately come to mind.

An example: I posted a 1984 paper about end-user documentation for all types of users (including developers) from the ACM archive. Despite the age of the paper, you'll recognise the questions about documentation even today.

'Those silly bastards': A report on some users' views of documentation (1984) https://news.ycombinator.com/item?id=31003306

Doh! I forget to include the URL when I submitted the entry. Apologies!

The link: https://dl.acm.org/doi/abs/10.1145/800060.801172

The full paper can be downloaded as a PDF or viewed online from the link above.

A partial summary of the paper:

- How can documentation be "user-friendly" to many different types of users: from very sophisticated programmers to brand new computer users?

- How useful are things like: reference cards, illustrations, extensive examples, sample sessions?

These are some of the questions in this short paper about (printed) documentation from Microsoft.

A focus group of thirty-four participants with varying computer experience were recruited to provide feedback on documentation on word processing, spreadsheets, database management systems, and programming language products.

Tutorials

- Everyone (including the programmers) want tutorials that show how to use the product or programming language.

- End-users also want tutorials for completing specific or common tasks.

Illustrations

- The programmers are mostly indifferent to pictures. End-users, however, want illustrations, especially program screenshots.

Reference

- Everyone agrees they want a "phone book" i.e. a book that tells everything about the product, including "tricks" and shortcuts.

- The programmers emphasise that any examples, especially sections of sample code, must include annotations to be useful.

Cookbook

- The cookbook includes models for solving many types of problems and for performing many types of tasks. (Interesting to note: in 1984 the term "cookbook" was a new, unfamiliar term in the context of documentation.)

- The "cookbook" potentially bridges the gap between tutorial and reference manual.

In conclusion, ideal documention looks like:

1. Tutorial

2. Cookbook

3. Reference

---

There is a lot more in the paper not included in the summary above. It's an excellent, readable paper. And it hasn't aged much despite being written in 1984.

Finally, the title of the paper "Those Silly Bastards" is a quote from a programmer who participated in the research. The full quote is included at the very end of the paper :-)