- 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."
"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."
That definition seems to put the cart before the house. Techniques like "details of an object both its data and its code are sealed off" are used to obtain/produce modularity.
Video puts several disclaimers before giving that definition but it was shared at the end of the video like you a conclusion so I can see some viewers walking away with conflicting conclusions from the video.
Both wikipedia[1] and Cambridge Dictionary[2] have better more general definitions for modularity.
"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."
OO was already invented and Simula 67 is even referenced in the paper, but not yet recognized or understood in its significance; the claim about Algol 60 ("an improvement .. on nearly all its successors") is pretty bold.
And in what respect does this contradict my statement? The paper appeared in 1973.
(By the way: Simula 67 was mostly influenced by Simula I; both Simula versions are an extension of Algol 60; with some minor exceptions Algol 60 is a subset of Simula 67 - as later Stroustrup did it with C and C++).
> 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."
An interesting example of this I came across recently is Pico:
> Pico is a tiny but expressive programming language that was especially designed to teach advance computer science concepts to students in other sciences than computer science … Currently Pico is no longer used as a tutoring language for its target group, but this is more a consequence of politics than of the astounding results we got with teaching Pico. Today, Pico is used as a means to teach principles of language design, interpreters and virtual machines in a sophomore course for computer scientists and in an adjacent course in a masters program in applied computer science.
We, as a field, should be very careful about forgiving our tools of the sin of complex and tedious design because those flaws can possibly be remediate with LLMs.
The complexity of boilerplate does not only exist for the author but every future author.
It is not my experience that LLMs and other complex automations are nearly as good as refactoring and changes as they are at generating boilerplate in the first place. In the end this code lives on as a human concern despite the automation.
I agree. I also don't think there is a single perfect programming language yet.
I do think however that programming languages and libraries are the assembly language for AIs to interface with legacy systems targeting human usage.
So it's important for these to be easily understandable.
Go fills that sweetspot better imo. Until something else appears perhaps.
But you're absolutely right that we should make sure to still improve these languages and it is right to worry that LLM don't incentivize new languages (smaller code corpus, less data?). As for Go, it is improving steadily so I'm still confident in that regard.
I am new to go, but to me, the language looks bigger than it needs to be. Why do slices and maps need to be part of the language and not just part of a standard library? I suppose the reason is special syntax, but having to learn that special syntax makes the language feel bigger.
They are part of the language, because they require generics to be implemented if you want to implement them in the standard library. Go didn’t use to have generics, so those constructs were hacked into the core language.
I see. That makes sense. So maybe it is generics that are so fundamental that they need to be part of any language. Seems that Java, C#, and Go have all learned this lesson.
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.