每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文，歡迎關注開源日報。

今日推薦開源項目：《把你的錢放在你的愛的地方——Thanks》

今日推薦英文原文：《Learning to program is getting harder》

今日推薦開源項目：《把你的錢放在你的愛的地方——Thanks》

GitHub 項目鏈接：https://github.com/feross/thanks

推薦理由：「把你的錢放在你愛的地方.」感恩之人如是說。

Thanks是一個基於js的項目，其目的是提供網路上開源項目開發及維護者者的名單。

「開源維護人員的工作使我們的應用程序，網站和項目成為可能，許多作者花費無數小時來開源。讓我們來幫助作者，讓我們中意的軟體能健康發展。」這是項目發起者的初衷。

如果你是需要幫助與支持的開源作者，你也當然也可以拉取請求將自己添加到CLI中。

使用：

  1. 運行 npx thanks 在你的項目里
  2. 得知那些開源工作者在募捐；；

兩種安裝：

  1. 用 npx thanks
  2. npm install -g thanks

效果演示：

開源項目精選: 把你的錢放在你愛的地方——Thanks

今日推薦英文原文：《Learning to program is getting harder》

推薦理由：那麼多編程語言、框架，如何選擇？該在哪裡敲代碼？敲完代碼後怎麼跑起來？一層又一層的封裝（IDE、雲、圖形界面等）將計算機工作原理隱藏了，初學編程的人沒法很自然地學習起來。

以下為轉載原文（推薦點擊原鏈接查看）

I have written several books that use Python to explain topics like Bayesian Statistics and Digital Signal Processing.  Along with the books, I provide code that readers can download from GitHub.  In order to work with this code, readers have to know some Python, but that's not enough.  They also need a computer with Python and its supporting libraries, they have to know how to download code from GitHub, and then they have to know how to run the code they downloaded.

And that's where a lot of readers get into trouble.
Some of them send me email.  They often express frustration, because they are trying to learn Python, or Bayesian Statistics, or Digital Signal Processing.  They are not interested in installing software, cloning repositories, or setting the Python search path!
I am very sympathetic to these reactions.  And in one sense, their frustration is completely justified:  it should not be as hard as it is to download a program and run it.
But sometimes their frustration is misdirected.  Sometimes they blame Python, and sometimes they blame me.  And that's not entirely fair.
Let me explain what I think the problems are, and then I'll suggest some solutions (or maybe just workarounds).
The fundamental problem is that the barrier between using a computer and programming a computer is getting higher.
When I got a Commodore 64 (in 1982, I think) this barrier was non-existent.  When you turned on the computer, it loaded and ran a software development environment (SDE).  In order to do anything, you had to type at least one line of code, even if all it did was another program (like Archon).
Since then, three changes have made it incrementally harder for users to become programmers
1) Computer retailers stopped installing development environments by default.  As a result, anyone learning to program has to start by installing an SDE -- and that's a bigger barrier than you might expect.  Many users have never installed anything, don't know how to, or might not be allowed to.  Installing software is easier now than it used to be, but it is still error prone and can be frustrating.  If someone just wants to learn to program, they shouldn't have to learn system administration first.
2) User interfaces shifted from command-line interfaces (CLIs) to graphical user interfaces (GUIs).  GUIs are generally easier to use, but they hide information from users about what's really happening.  When users really don't need to know, hiding information can be a good thing.  The problem is that GUIs hide a lot of information programmers need to know.  So when a user decides to become a programmer, they are suddenly confronted with all the information that's been hidden from them.  If someone just wants to learn to program, they shouldn't have to learn operating system concepts first.
3) Cloud computing has taken information hiding to a whole new level.  People using web applications often have only a vague idea of where their data is stored and what applications they can use to access it.  Many users, especially on mobile devices, don't distinguish between operating systems, applications, web browsers, and web applications.  When they upload and download data, they are often confused about where is it coming from and where it is going.  When they install something, they are often confused about what is being installed where.
For someone who grew up with a Commodore 64, learning to program was hard enough.  For someone growing up with a cloud-connected mobile device, it is much harder.
Well, what can we do about that?  Here are a few options (which I have given clever names):
1) Back to the future: One option is to create computers, like my Commodore 64, that break down the barrier between using and programming a computer.  Part of the motivation for the Raspberry Pi, according to Eben Upton, is to re-create the kind of environment that turns users into programmers.
2) Face the pain: Another option is to teach students how to set up and use a software development environment before they start programming (or at the same time).
3) Delay the pain: A third option is to use cloud resources to let students start programming right away, and postpone creating their own environments.
In one of my classes, we face the pain; students learn to use the UNIX command line interface at the same time they are learning C.  But the students in that class already know how to program, and they have live instructors to help out.
For beginners, and especially for people working on their own, I recommend delaying the pain.  Here are some of the tools I have used:
1) Interactive tutorials that run code in a browser, like this adaptation of How To Think Like a Computer Scientist;
2) Entire development environments that run in a browser, like PythonAnywhere; and
3) Virtual machines that contain complete development environments, which users can download and run (providing that they have, or can install, the software that runs the virtual machine).
4) Services like Binder that run development environments on remote servers, allowing users to connect using browsers.
On various projects of mine, I have used all of these tools.  In addition to the interactive version of "How To Think...", there is also this interactive version of Think Java, adapted and hosted by Trinket.
In Think Python, I encourage readers to use PythonAnywhere for at least the first four chapters, and then I provide instructions for making the transition to a local installation.
I have used virtual machines for some of my classes in the past, but recently I have used more online services, like this notebook from Think DSP, hosted by O'Reilly Media.  And the repositories for all of my books are set up to run under Binder.

These options help people get started, but they have limitations.  Sooner or later, students will want or need to install a development environment on their own computers.  But if we separate learning to program from learning to install software, their chances of success are higher.

UPDATE: Nick Coghlan suggests a fourth option, which I might call Embrace the Future: Maybe beginners can start with cloud-based development environments, and stay there.

UPDATE: Thank you for all the great comments!  My general policy is that I will publish a comment if it is on topic, coherent, and civil.  I might not publish a comment if it seems too much like an ad for a product or service.  If you submitted a comment and I did not publish it, please consider submitting a revision.  I really appreciate the wide range of opinion in the comments so far.

每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文，歡迎關注開源日報。交流QQ群：202790710