- 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?
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.
> How can you create a class hierarchy in a language that doesn’t have classes? The Go (Golang) language doesn’t have classes and doesn’t do inheritance so when I tried to write an adventure game in Go, it looked as though I wouldn’t be able to get very far.
> I’ve previously written adventure game sin object oriented languages such as Java and C#. In those languages I can create class hierarchies in which one class (say a Room) inherits the features of another class (say Thing) and adds on any new features. Go doesn’t let me do that……or does it?
> In this video, I show how I created a ‘class hierarchy’ in Go even though it doesn’t have classes and so, in principle, it shouldn’t be possible to create a class hierarchy.
"This paper describes a flowchart technique, which supports the method of program development by stepwise refinement. Flowcharts made by this technique have a tree structure, which simplifies program test and coding the chart into a programming language. For design of the overall control structure the basic forms concatenation, selection, repetition and restricted GOTO statements are available."
"What is modularity? Dividing code into separate files? No! Hiding data? Well, up to a point...protecting implementation details? Well, that’s a bit nearer the mark. But what does that really mean? How do you protect the implementation details of a module or an object? And why does it matter?"
"In this lesson, I look at some of the ideas and the history of modular programming. From Smalltalk to Modula-2, and onwards to C#, Ruby, Java and Object Pascal, I’ll try to explain what modularity is and why your code will be more reliable if you make use of it."
A summary at the end of the video:
"There is no one clear definition of modularity. Modules mean different things in different languages and different things to different programmers."
"But when I talk about modularity I mean a style of programming in which the internal details of an object both its data and its code are sealed off from the code outside that object. And to communicate with an object you have to use precisely defined ways into and out of that object. In some languages those ways into and out may be declared as interfaces. To an object-oriented language like Smalltalk the interfaces to an object are provided by methods that respond to messages."
"This paper must clearly be read in the context of its date of composition (1973). The relative weight of comment on debugging and reasoning about programs clearly changed as a result of his own later research. Also, a richer notion of types would be appropriate today. But the sound advice in this paper transcends any minor aspects in which it might be considered to be out of date."
> We describe a system, 'ExplainThis', that automatically generates contextualized language documentation, structured based on our study of language documentation but specialized to the particular code at the cursor.
> This system is integrated into the structure editor of Hazel (https://hazel.org/), a live functional environment.
----
> Potential use cases of 'ExplainThis' include code reading and comprehension (e.g. a user trying to understand existing functions in a library or examples in instructor-created tutorials); writing new code (e.g. a user trying to modify starter code to complete an assignment); or debugging (e.g. a user trying to understand unexpected behavior of a function).
Polymorphism and inheritance: simple or complex ideas? Or is meaning depending on the lanuage? I really like the following video: OOP principles (and why so much jargon).
> Abstraction, Polymorphism, Inheritance and Encapsulation… Yikes! What the heck does all that mean and why should anyone care?
> Programming is full of jargon. Object Oriented Programming takes jargon to a whole new level. But even so, that list of the “four fundamentals of object oriented programming” is missing something important. In this video, I explain what the four principles are. And I then explain why they are making a big deal out of something that is essentially quite simple."
Later in the video:
> I'd say polymorphism is probably a hundred dollar word for a 50 cent idea. These days computer science teachers and writers have extended the meaning of polymorphism to such an extent that it's often hard to figure out what the heck they're trying to describe.
"Abstraction, Polymorphism, Inheritance and Encapsulation… Yikes! What the heck does all that mean and why should anyone care?
Programming is full of jargon. Object Oriented Programming takes jargon to a whole new level. But even so, that list of the “four fundamentals of object oriented programming” is missing something important. In this video, I explain what the four principles are. And I then explain why they are making a big deal out of something that is essentially quite simple."
Later in the video:
"I'd say polymorphism is probably a hundred dollar word for a 50 Cent idea. These days computer science teachers and writers have extended the meaning of polymorphism to such an extent that it's often hard to figure out what the heck they're trying to describe"
Although I have not read DEC's (Digital Equipment Corporation) documentation, but I've come across a 1990 book that mentions DEC's approach to documentation:
> Digital Equipment Corporation noted in their 1983 internal documentation guidelines that user documentation should be written first — not last as is traditionally done — because the user documentation is an excellent way to debug the design of a system or a program. “If a writer finds it difficult to document a system, the problem is probably the system not the writer. Holes in design, obscure constructions, and apparent contradictions become starkly visible in the documentation.”
(From book: Writing better computer user documentation, 1990)
There is something very appealing about learning a small(ish) language. However, a small language does not always mean simple. And it means code can be difficult to unravel.
Niklaus Wirth, the creator of Pascal, Modula-2 and Oberon, believe strongly that teaching programming is most effective when students can grasp the entirety of a small language.
From a 2018 interview with Wirth on the topic:
> "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."
This TV programme from the Open University (OU) is a model of clarity and explanation. The visual examples are excellent and well thought out. This TV programme was broadcast almost 40 years ago and yet beats many online video computing courses, lectures and tutorials today.
Video summary (from a Rust-focussed YouTube channel)
"We're going to compare Rust to seven other languages that you probably haven't tried. Each and every one of these seven languages gave me a different surprise that I didn't see coming."
- Rust
- Nim
- Julia
- Elixir
- Zig
- Haskell
- Lua
- Crystal
Challenge: "The program we're going to implement reads a line of space to limited numbers from standard input, and process some of those numbers. It's a simple program but one that quickly surfaces the idiosyncrasies of a programming language"
Impressions from the presenter:
- Most concise language: Haskell
- Coolest language features: Elixir's pipe operator
- Most underrated languages: Nim and Crystal
Disclaimer: "It's important to note that this isn't really a fair comparison. Each of these languages caters to a specific need. And in a sense we're comparing them in a way that some might consider surface level. But you do need to look at the surface at some point."
Although the language is not widely known, the language creator posted to Hacker News in 2018:
> Hi all, this is Andreas Stefik (I invented Quorum)....First, people saying Quorum was originally designed for blind children are correct. Originally, we were toying with the idea of adjusting syntax to make it easier to read out loud through a screen reader. That stemmed from observing young blind programmers use a variety of programming languages on one of my first National Science Foundation projects. Phrases like, “for int I equals semicolon, I less then semicolon I plus plus” or other phrases can be extraordinarily difficult to listen to, especially if you are child.
> This is one reason why Quorum is used so heavily at schools for the blind or visually impaired in the U.S. and elsewhere. We haven’t been just for the blind in a long-time, but I still care about that community quite a bit and we work hard to make things accessible. There’s a ton more to discuss in that area, but I want to move on to “evidence."
> "Ten years ago, only Linux kernel committers and other early adopters used Git. Almost everyone else used Subversion. Ten years later, Git is the most popular product. Which makes me wonder: what will we use another ten years from now? And what features would YOU want from your version control software in 2032? No history rewrites? Faster? No merge conflicts ever?"
Here's an high-level overview. There's more detail in the video.
Why is Git so popular?
- Git in 2010 = 25% usage
- Git in 2021 = 75% usage
Fossil:
- Distributed version control, bug tracking, wiki, forum
- Contributions from a team of 4 vs Git with 5000+ contributions
- Written in C and SQL - supports SQLite version control
I still think the biggest user interface (UI) change from Microsoft was the change from Windows 3.1 to Windows 95. There were so many features and improvements e.g. the re-designed Open/Save dialog (not much changed since then). Later versions of Windows have never made the same leap between new versions of Windows. Sure, there are refined or tweaked features (or regressed!), but each new version of Windows felt like an incremental update from the previous version.
I think the next leap in UI and visual design from Microsoft was...Windows Phone 8 (2012). It was a refreshing and different approach to mobile design. The visual language 'Metro' worked well on mobile touch screens. But Microsoft took the bad decision to transplant 'Metro' (flat design) to the desktop. The result is a clumsy, jumble of inconsistent screens. It simply doesn't work.
- 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
- Programmers are mostly indifferent to pictures (I wonder if this is true today among programmers?). For end-users, illustrations are essential - 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, but today is a familiar documentation pattern.)
- 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 detail in the paper. This an excellent, readable paper. And it hasn't aged much despite being written in 1983.
Finally, the title of the paper "Those Silly Bastards" is a quote from a programmer who participated in the research. From the paper:
> I want to finish by explaining the title of this paper - "Those Silly Bastards." During the focus group on programming languages, one of the programmers said:
They obviously are trying to give you something, but those silly bastards don't know what they are trying to do. Just give us a complete, accurate manual that tells us everything we need to know.
You can still rotate PDF pages using the Reader desktop app. However, as other posters have recommended, there are many alternative PDF apps. Avoid Adobe if you can.
I agree. In fact, many open source (and closed source) codebases are understood by only a handful of developers with deep understanding of the design and code (e.g. the original developer or a developer with many contributions). The rest of us (including me) have a superficial understanding of the code at best. There's even a word that developers use to describe popular open source frameworks: 'magic'. A euphemistic way to say: 'I have no-idea how the code fit together, but this code library or framework is popular and it all works'.
There are not many languages (in active use) with a small surface area. Go is small, Lua is another. However, a small language does not always mean simple - you may still encounter code that is difficult to unravel.
New programming languages tend to range from medium-to-large in size.
Here are number of keywords in some languages. Note: this is a bit of a blunt measure of a language's size so you may not consider it a measure of small surface area:
Introduction
- 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?
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.