-
Notifications
You must be signed in to change notification settings - Fork 18.1k
proposal: new package simpleinput for Go education #54646
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
How about https://go.dev/doc/faq#x_in_std? Suggesting better fmt scanning APIs is one thing, but if these APIs are primarly for new Go users, perhaps they should be in a Go module that's aimed and promoted to them. At the same time, I would be conflicted with APIs targetting new users only. If I was learning a language, I would want to learn the "normal" or "proper" way to accomplish a task, not an oversimplified way that I should probably un-learn later. |
I think it's a fair question whether Go wants to target new users or just say that's out of scope. However, if the decision is made that targeting new users is in scope, then I don't think it makes any sense to use an external module. You can already find tons of simple input packages online. The forums are full of people who haven't found those modules because they are looking in the standard library for the equivalent of Python's |
I don't think it would be fair to say Go doesn't target new users. It has grown in users at a very fast pace for ten years now :) It is true that new users will tend to look at the standard library first, but ultimately they will follow the advice of the documentation they are reading. There are plenty of "blessed" modules outside of the standard library, such as |
The question of why should this be in the standard library seems really straightforward to me. A simpleinput package really only has value in the standard library. The point is to make learning Go easier, and as soon as modules are involved, it's not easier.
In Python, practically all learning material uses |
If we are going to do this, I think we should be more idiomatic and have |
After reading this proposal I tried to think about some typical "getting started"-type programs that I might write when learning a new language. It's harder for me to relate to "learning to program" because it's been some time, but I also tried to remember some early programs I wrote. Here's what came to my mind:
I don't really have a strong opinion about whether it's important to make these easy to achieve, but similar features do seem to help learners of Python as stated above, and Python is typically presented as an example of a good language for beginners. My examples above also lead me to think that the I share Ian's sense that it would be better to make these functions follow typical Go error handling patterns, because that seems like an important part of Go's design that I'd want to learn quickly as a beginner, rather than deferring until later. I think a |
I think this optimizes for the wrong thing especially with globals. |
Uh oh!
There was an error while loading. Please reload this page.
Problem:
Every few months, someone will post on Reddit that they're trying to make an intro-to-CS-style input prompt and they're confused why their code using
fmt.Scan*
doesn't work (inevitably because the input has a space and they're ignoring errors). I think that just for the use case of education, there should be something that does the thing that they want.Here are some typical posts
You can find more by searching site:https://reddit.com/r/golang fmt.scan.
New programmers aren't a huge source of new Go users. On the other hand, even if most Go programmers come from other languages, it is convenient when learning the language to be able to write simple intro-to-CS-style question/response programs to get a feel for the language. There ought to be something very simple that novice can find without knowing anything about Go or IO. Obviously, novices could and probably should be using bufio.Scanner already, but they aren't finding it today. Instead they look in fmt (because they are already using fmt.Println) and find the Scan family of functions. Then they are frustrated when it does not work the way they expect.
Proposed solutions
Proposed solution one is simple: mark the Scan functions as deprecated to hide them from the documentation. Even Rob Pike regrets adding the Scan functions.
Proposed solution two is to add a new package just for education purposes.
Obviously, none of this is strictly necessary, but it would help Go learners, particularly those new to programming.
Cf. #54620
Edit: Proposed API is now:
The text was updated successfully, but these errors were encountered: