开源日报 - Page 93 of 262 - Open Source Daily

开源日报第670期：《Brackets》

18 1 月, 2020

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《Brackets》
今日推荐英文原文：《What Is Active Learning?》

今日推荐开源项目：《Brackets》传送门：GitHub链接
推荐理由：Brackets是HTML，CSS和JavaScript 内置的现代开源代码编辑器，用于HTML，CSS和JavaScript。这款编辑器具有简洁的UI界面，使得上手更加轻松；有强大的同步功能，使得您的代码能与浏览器同步；并且它是一款开源的软件，您可以将其打造成为您的个性化编辑器。
今日推荐英文原文：《What Is Active Learning?》作者：DANNY SHAPIRO
原文链接：https://blogs.nvidia.com/blog/2020/01/16/what-is-active-learning/
推荐理由：主动学习是一种用于机器学习的训练数据选择方法，可以自动找到这些多样化的数据。它只需花费人类整理时间的一小部分即可构建更好的数据集。主动学习与当下火热的自动驾驶有着密切的联系，通过相关文章的阅读，我们能更好的了解这些前沿的科技。
What Is Active Learning?

Finding the right self-driving training data doesn’t have to take a swarm of human labelers.
Reading one book on a particular subject won’t make you an expert. Nor will reading multiple books containing similar material. Truly mastering a skill or area of knowledge requires lots of information coming from a diversity of sources.

The same is true for autonomous driving and other AI-powered technologies.

The deep neural networks responsible for self-driving functions require exhaustive training. Both in situations they’re likely to encounter during daily trips, as well as unusual ones they’ll hopefully never come across. The key to success is making sure they’re trained on the right data.

What’s the right data? Situations that are new or uncertain. No repeating the same scenarios over and over.

Active learning is a training data selection method for machine learning that automatically finds this diverse data. It builds better datasets in a fraction of the time it would take for humans to curate.

It works by employing a trained model to go through collected data, flagging frames it’s having trouble recognizing. These frames are then labeled by humans. Then they’re added to the training data. This increases the model’s accuracy for situations like perceiving objects in tough conditions.

Finding the Needle in the Data Haystack

The amount of data needed to train an autonomous vehicle is enormous. Experts at RAND estimate that vehicles need 11 billion miles of driving to perform just 20 percent better than a human. This translates to more than 500 years of nonstop driving in the real world with a fleet of 100 cars.

And not just any driving data will do. Effective training data must contain diverse and challenging conditions to ensure the car can drive safely.

If humans were to annotate this validation data to find these scenarios, the 100-car fleet driving just eight hours a day would require more than 1 million labelers to manage frames from all the cameras on the vehicle — a gargantuan effort. In addition to the labor cost, the compute and storage resources needed to train DNNs on this data would be infeasible.

The combination of data annotation and curation poses a major challenge to autonomous vehicle development. By applying AI to this process, it’s possible to cut down on the time and cost spent on training, while also increasing the accuracy of the networks.

Why Active Learning

There are three common methods to selecting autonomous driving DNN training data. Random sampling extracts frames from a pool of data at uniform intervals, capturing the most common scenarios but likely leaving out rare patterns.

Metadata-based sampling uses basic tags (for example, rain, night) to select data, making it easy to find commonly encountered difficult situations, but missing unique frames that aren’t easily classified, like a tractor trailer or man on stilts crossing the road.

Caption: Not all data is created equal. Example of a common highway scene (top left) vs. some unusual driving scenarios (top right: cyclist doing a wheelie at night, bottom left: truck towing trailer towing quad, bottom right: pedestrian on jumping stilts).

Finally, manual curation uses metadata tags combined with visual browsing by human annotators — a time-consuming task that can be error-prone and difficult to scale.

Active learning makes it possible to automate the selection process while choosing valuable data points. It starts by training a dedicated DNN on already-labeled data. The network then sorts through unlabeled data, selecting frames that it doesn’t recognize, thereby finding data that would be challenging to the autonomous vehicle algorithm.

That data is then reviewed and labeled by human annotators, and added to the training data pool.

Active learning has already shown it can improve the detection accuracy of self-driving DNNs over manual curation. In our own research, we’ve found that the increase in precision when training with active learning data can be 3x for pedestrian detection and 4.4x for bicycle detection relative to the increase for data selected manually.

Advanced training methods like active learning, as well as transfer learning and federated learning, are most effective when run on a robust, scalable AI infrastructure. This makes it possible to manage massive amounts of data in parallel, shortening the development cycle.

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第669期：《云场景操作系统 TencetOS Server kernel》

17 1 月, 2020
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《云场景操作系统 TencetOS Server kernel》
今日推荐英文原文：《Well-Intentioned but Bad Advice for Beginner Programmers》

今日推荐开源项目《云场景操作系统 TencetOS Server kernel》：传送门：GitHub链接
推荐理由：TencentOS Server( 又名Tencent Linux 简称Tlinux) 是腾讯针对云的场景研发的 Linux 操作系统，提供了专门的功能特性和性能优化，为云服务器实例中的应用程序提供高性能，且更加安全可靠的运行环境。Tencent Linux 使用免费，在 CentOS（及发行版）上开发的应用程序可直接在 Tencent Linux 上运行，用户还可持续获得腾讯云的更新维护和技术支持。
今日推荐英文原文：《Well-Intentioned but Bad Advice for Beginner Programmers》作者：Ray Heberer
原文链接：https://medium.com/better-programming/well-intentioned-but-bad-advice-for-beginner-programmers-dc806edd20bd
推荐理由：对于程序员到底应该告诉新人什么呢？作者尝试从另外的角度看待已经成为传统的词语，指出了数个虽然善意却不太好的建议。
Well-Intentioned but Bad Advice for Beginner Programmers

(Photo by Riccardo Annandale on Unsplash)

I bet you didn’t wake up today expecting to be advised to reinvent the wheel.

These days, the internet is chock full of articles containing well-meaning tips directed toward aspiring programmers. Many of these articles contain solid advice, but many also carry pernicious statements that can be harmful to a beginner’s growth.

Often, it isn’t so much that the advice is generally bad or patently untrue; those giving it are smart and experienced enough not to commit such blatant errors. Rather, it’s the fact that the authors are experienced that leads them to present seemingly sound information in a way that may not be interpreted by a beginner in the way they would expect or hope. In my view, well-intentioned bad advice often has the following characteristics:
- It’s good advice for a professional’s day-to-day work, but it’s bad advice for someone learning.
- It’s based on truth, but it can be interpreted in a way that damages growth.
In this article, I’ll examine three pieces of advice I often see directed at beginner programmers (whether they want to be software engineers, data scientists, developers, etc.) and explain why I believe them to be dangerous. At the end of the day, what follows is my personal opinion. So, if you get anything out of this, I would prefer it to be the importance of approaching things with a healthily skeptical attitude rather than to not listen to some particular piece of conventional wisdom.

“Don’t Reinvent the Wheel”

You may have heard that good software engineers are productively lazy people. They automate processes that get repetitive, putting in work (but not too much work) now to avoid more later. They also reuse existing solutions that they or others have made in order to make solving new problems easier. Reusing existing solutions instead of building them from scratch every time is also known as “not reinventing the wheel.”

While avoiding unnecessary reinventions is good practice, I also don’t think it’s a practice that really needs to be shared as one of the main pieces of advice for beginners. In fact, I even think there are ways in which doing so can do more harm than good.

The first reason is related to the fact that our needs are different when we’re learning something new compared to when we’re using skills we already have. If you’re being paid to write a certain kind of code, then it’s certainly efficient and worthwhile to not spend too much time mucking around reimplementing solutions to linear algebra problems that have been around since the Vietnam War. But if your objective is to learn and grow, then you should be wary about passing up valuable opportunities to challenge yourself. Inventing wheels is surprisingly difficult. The fact that many solutions seem obvious in hindsight may mask the amount of value that can be gained by tackling a problem that others have solved.

Also, being too reluctant to get your hands dirty can be harmful long-term, even once you’ve landed the job. I fear that all the emphasis on not doing work others have already done, and focusing instead on honing search engine skills, is encouraging the bad practice of copying solutions from the internet without fully understanding what they do. This incurs technical debt every time it’s done, and it could end up seriously costing your organization.

Don’t get me wrong; I find myself typing into Google many times a day. But I almost never copy what I find. Usually, what I’m looking for is an approach to solving a general problem that can be adapted to my specific issue. This issue is typically too use-case specific to expect a perfect slot-in solution for.

Honestly, I’m good at looking things up, but those skills were acquired quickly and easily by reading a few cheat sheets. What allows me to gain value from non-exact solutions I find, and not get stuck even when nothing useful can be found, are the thousands of hours I spent building things from scratch when I didn’t need to.

Taking a crack at the problems you come across while learning programming — even if you know a solution exists that will almost certainly be more optimized and elegant than what you come up with — builds a sort of creativity and problem-solving intuition that’s hard to gain by just pushing toward the product (e.g. a portfolio project) at any cost.

“Don’t reinvent the wheel” is good advice for professionals, but it’s bad advice for learners.

“There’s No Such Thing as Bug-Free Software”

Before I get started, I’d like to say that I do recognize that some people very much need to hear phrases such as this, and there’s an intended audience for advice like this. It’s just like how a professor saying, “there’s no such thing as a stupid question,” is good for the perceptive yet shy students in the classroom, but bad for certain other students who simply like the sound of their own voice. I’ll expand on this general idea a little when I wrap up, but for now, I’ll focus on identifying the signs that someone is interpreting well-meaning advice in a way that hurts them.

Let’s first determine what one should take away from statements about the impossibility of bug-free software. For one, it should encourage a resilient attitude while learning, where one is not discouraged the moment something doesn’t work as intended. And in terms of a mindset that can be useful throughout a career, I think maxims like the above can encourage a healthy respect for the intellectual challenge of programming. One that leads to increased diligence in writing more unit tests and developing an intuition for the sort of bugs that can occur.

Now, what would I consider an unhealthy response? In my view, there are both productive and unproductive forms of humility. Humility that takes a form like, “it’s possible I made a mistake so I should take steps to safeguard against that” is productive. On the other hand, humility like, “there’s no such thing as bug-free software anyway, so why bother today when I’ll just have to fix things tomorrow no matter what” is unproductive.

When juxtaposed like that, it might seem like no one in their right mind would be unproductively humble. But be honest. Have you ever taken a class that had a reputation for being difficult, where because it was acceptable to struggle, people were fine with finishing the semester not understanding things? I think many of us — myself included — are more tempted to let difficulty encourage complacency than we think. For this reason, I think advice like “don’t expect to ever write bug-free software” can be interpreted in a way we don’t intend.

The ubiquity of bugs in code is less like a law of motion, and more like the second law of thermodynamics. By that I mean it’s more of a tendency than a physical guarantee. And it’s a tendency that can be mitigated by applying a little of our own energy.

Together, let’s think of a way to encourage people to respect the intellectual endeavour of programming without resigning themselves to striving for less than perfection — even if perfection may never be achieved.

“Premature Optimization Is the Root of All Evil”

Now, what would I have against the words of eminent and historically important computer scientist Donald Knuth? Surely I don’t disagree with him?

That’s right, I don’t disagree. What I do object to is passing on this one quote, out of context, to people who are still in the early stages of learning to code. Even aside from it being taken out of context, two basic questions stand out that more experienced engineers often forget to even address:
1. What is meant by “optimization?”
2. What is meant by “premature?”
To start, let’s get the paragraph that the line comes from. You should still read the full source, but I feel this is already an improvement.

“There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97 % of the time: pre mature optimization is the root of all evil.”

Already, this tells us a bit about what is meant by optimization. When writing code, some things to consider are:
- How much time does it take to run?
- How much memory does it require?
- How easy is it for a human to understand?
- How easily could the code be used to solve another problem somewhere else?
The first two points are related to how the software interacts with the machine (computational complexity). They most closely fit what Donald Knuth is referring to as optimization in his famous phrase. The third, however, relates to how the code interacts with other humans (including you, the author of the code, in a couple of weeks).

Making adjustments to code that make it easier to read and interpret is often worthwhile, and — I would argue — almost never premature. It’s definitely possible to write legible code from the start without wasting your own time. Remember, Donald Knuth is also the man behind the concept of Literate Programming!

As for making code more adaptable for use in other places, this is also something that can often be done without wasting time. Not from the beginning, but also not never.

Finally, one must realize that there does come a time to optimize the code’s actual performance. This can be when the scope of the problem is understood and a full prototype has been implemented.

“Premature” doesn’t apply at all times, and “optimization” doesn’t refer to all possible types of improvements.

I fear that beginner programmers might not have the context necessary to understand this. They may learn to take the principle of “move fast, break things” to its extreme in a way that’s ultimately inefficient and frustrating.

Conclusion

I hope that while reading this article, it became clear that I’m in no way pointing fingers at the experienced programmers among us who have said or written down advice like the three topics I covered. I’m not even saying they should necessarily stop.

What I do hope has been made clear is that communication, and especially communication across skill gaps, is a dynamic and difficult process. It’s hard to predict the outcome of giving advice — it depends on where the recipient is coming from and even on the frequency with which similar things have been said by others.

Many of us genuinely want to help others, and it warms my heart to see so many people out there sharing their knowledge, often more effectively than I’m currently capable of. What I wanted to achieve with this was another perspective on a few phrases that seem to have become conventional wisdom. I urge my fellow engineers to recognize that when something becomes conventional wisdom, it can be easy for us to forget to communicate the surrounding context needed to truly understand it.

And I urge my fellow learners to strive to find the most productive way to interpret every piece of information you come across. Happy coding. You’ve got this!

Resources
- The Curse of Knowledge — Wikipedia
- Project Euler: a great place to reinvent wheels
- Hindsight Bias — Wikipedia
- Structured Programming with go to Statements — Donald Knuth
- Literate Programming
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第668期：《这个是额外的 howto-make-more-money》

12 1 月, 2020

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《这个是额外的 howto-make-more-money》
今日推荐英文原文：《Getting Serious About Open Source Security》

今日推荐开源项目：《这个是额外的 howto-make-more-money》传送门：GitHub链接
推荐理由：如果你已经把你的技能树培养的非常粗壮了，兴许就可以考虑用它带来些额外收益。这个项目是关于如何用技术挣钱的技巧，当然了，在尝试之前自然需要足够的能力作为基础，不管是将技术变为产品再变为现金，还是直接出售自己的技术，追根究底的源头都是技术本身，获得了足够的商业能力却忽视了技术培养可以说是本末倒置的行为。
今日推荐英文原文：《Getting Serious About Open Source Security》作者：dlorenc
原文链接：https://medium.com/better-programming/getting-serious-about-open-source-security-1d15609478fa
推荐理由：当你的项目需要接触敏感数据时就要格外当心
Getting Serious About Open Source Security

A not so serious look at a very serious problem

A Blast From the Past
2019 was a crazy time to be writing software. It’s hard to believe how careless we were as an industry. Everyone was just having fun slinging code. Companies were using whatever code they found laying around on NPM, Pip, or Maven Central. No one even looked at the code these package managers were downloading for them. We had no idea where these binaries came from or even who wrote most of this stuff.

And don’t even get me started on containers! There was no way to know what was inside most of them or what they did. Yet there we were, pulling them from Dockerhub, slapping some YAML on them, and running them as root in our Kubernetes clusters. Whoops, I just dated myself. Kubernetes was a primitive system written mostly in YAML and Bash that people used to interact with before Serverless came and saved us all.

Looking back, it’s shocking that the industry is still around! How we didn’t have to cough up every Bitcoin in the world to stop our databases from getting leaked or our servers from being blown up is beyond me. Thankfully, we realized how silly this all was, and we stopped using whatever code had the most Github stars and started using protection.
We’re Under Attack
No, really. Every time you pip install, go get, or mvn fetch something, you’re doing the equivalent of plugging a thumb drive you found on the sidewalk into your production server.

You’re taking code from someone you’ve never met and then running it with access to your most sensitive data. Hopefully, you at least know their email address or Github account from the commit, but there’s no way to know if this is accurate unless you’re checking PGP signatures. And let’s be honest, you’re probably not doing that.

This might sound like I’m just fear-mongering, but I promise I’m not. This is a real problem that everyone needs to be aware of. Attacks like this are called supply-chain attacks, and they are nothing new. Just last month, an active RCE vulnerability was found in an open source package on PyPi that was being used to steal SSH and GPG credentials.

There are lots of variations on this same play that make use of different social-engineering techniques in interesting ways. One attacker used a targeted version of this to steal cryptocurrency from a few specific websites. Another group performed a “long-con” where they actually produced and maintained a whole set of useful open source images on Dockerhub for years before slowly adding, you guessed it, crypto-mining.

The possibilities are endless, terrifying, and morbidly fascinating. And they’re happening more and more often. If reading about attacks like these is your kind of thing, the CNCF has started cataloging known instances of them. Snyk also just published a post detailing how easy it is to inject code like this in most major languages — Github even hides these diffs in code review by default! Russ Cox has also been writing about this problem for a while.
Vision
OK, there’s a bit of hyperbole up there (Kubernetes doesn’t have that much bash in it), but open source is under attack, and it’s not OK. Some progress is being made in this area — GitHub and others are scanning repositories, binaries, and containers, but these tools all only work on known vulnerabilities. They have no mechanism to handle intentional, malicious ones before they are discovered, which are at least as dangerous.

The brutal fact is that there is no way to be confident about the code you find on most artifact repositories today. The service might be compromised and serve you a different package from the one the author uploaded. The maintainer’s credentials might have been compromised, allowing an attacker to upload something malicious. The compiler itself might have been hacked, or even the compiler that compiler used (PDF warning)! Or, the maintainer could have just snuck something in on purpose.

For any given open source package, we need to be able to confidently assert what code it’s comprised of, what toolchains and steps were used to produce the package, and who was responsible for each piece. This information needs to be made available publicly. A reliable, secure view of the supply-chain of every open source package will help make these attacks easier to prevent and easier to detect when they do happen. And the ability to tie each line of code and action back to a real individual will allow us to hold attackers accountable.
How Do We Get There?
We need to work as an industry to start securing open source software, piece by piece.

Artifact repositories need to support basic authentication best practices like 2FA, artifact signing, and strong password requirements. DockerHub, PyPi, and NPM support 2FA, but there’s no way to see if a maintainer of a package is using it. Most container registries don’t support signatures yet, though work is ongoing.

Software build systems need to make reproducible, hermetic builds possible and easy. Debian has started doing some great work here, but they’re basically alone. Every docker build gives you a new container digest. Tar and gzip throw timestamps everywhere. It’s possible to get reproducible builds in Go, Java, and most other major languages, but it’s not necessarily easy. See the recently published whitepaper on how Google handles much of this internally for more information.

SCM providers need strong identity mechanisms so we can associate code back to authors confidently. Git commit logs can be easily forged, and signed commits are not in common use. Even with them, you still have no idea who is on the other end of a PR, only that the signature matches. This isn’t just an issue for security. It can also be a licensing nightmare if you don’t know the real author or license of code you’re accepting.

There is value in allowing developers to work anonymously, but there is also a cost. We need to balance this with systems that apply a higher level of scrutiny to anonymous code. We also need to allow other individuals to “vouch for” patches that they’ve examined, maybe similar to how Wikipedia handles anonymous edits.

And finally, all of this needs to be tied together in secure CI/CD systems and platforms that implement binary transparency for public packages. Putting the packaging steps in the hands and laptops of developers leaves way too large an attack surface. The ability to push a package that will run in prod is the same as having root in prod. By moving the build and upload steps into secure CI/CD systems, we can reduce the need to trust individuals.
OK, but What Can I Do Now?
First, start by securing your code as much as possible. Make sure you have copies of every dependency you’re using stored somewhere. Make sure you review all code you’re using, including OSS. Set up and mandate the use of 2FA across your organization. Publish, and actually check the signatures and digests of the software you’re using.

Log enough information in your build system so you can trace back every artifact to the sources. And every deployment to the artifacts. Once you’ve done all of this, you’ll be pretty far ahead of everyone else. You’re not completely safe, though.

That’s where we need to work together. If you’re interested in helping out, there are many ways to get involved, and I’m sure there are a lot of efforts going on. We’re just getting started on several initiatives inside the Continuous Delivery Foundation, like our new Security SIG. We’re also hoping to make it easier to build and use secure delivery pipelines inside the TektonCD open source project.

We would love your help, no matter your expertise! For example, I’m far from a security expert, but I’ve spent a lot of time working on developer tools and CI/CD systems. Feel free to reach out to me directly if you have any questions or want to get involved. I’m on Twitter and Github.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第667期：《从零开始的编译器 acwj》

11 1 月, 2020
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《从零开始的编译器 acwj》
今日推荐英文原文：《Do You Need Math to Be a Software Engineer?》

今日推荐开源项目：《从零开始的编译器 acwj》传送门：GitHub链接
推荐理由：这个项目记录了作者自己编写编译器的过程。要弄清一个玩意是怎么回事，自己造出来是一个很好的办法，不管是拿来使用还是仅供学习参考，都能对其中玄妙有更深入的理解，如果的确对“其然”背后的“其所以然”感兴趣，不妨自己动手尝试一下。
今日推荐英文原文：《Do You Need Math to Be a Software Engineer?》作者：Devin Soni
原文链接：https://medium.com/better-programming/do-you-need-math-to-be-a-software-engineer-26694a11f7ea
推荐理由：并非雪中送炭，而是锦上添花
Do You Need Math to Be a Software Engineer?

In most cases, no, but it can help

What Do Software Engineers Do?
To understand the relationship between math and software engineering, it is first important to understand what the average software engineer actually does.

Most engineers end up working on web or business applications, either on the front end or back end (or both).

Working on these types of projects will require you to be familiar with languages such as Java, JavaScript, Python, C#, and Go, and query languages such as SQL dialects.

Within these languages, you will need to learn to use frameworks and libraries that enable you to quickly develop applications, such as React, Angular, Express, Django, and Spring.

Beyond this, you may need to learn things on the operations side of development, such as containerization products like Docker and Kubernetes, as well as how to use various cloud computing platforms such as Amazon Web Services or Google Cloud Platform.
Where’s the Math?
While it may sound daunting to learn all of these software engineering topics, the important thing to note is that none of these directly relate to math. While they may have theoretical roots in mathematical fields, none of them require you to know math to become proficient.

Most of the required knowledge for these technologies is self-contained, and will not require you to draw from theoretical content taught in university-level courses.

Even most computer science courses will only marginally help you to understand these technologies. They may give you background knowledge on their design and how they are implemented, but they rarely give you actionable knowledge on how to use them in practice.

With that being said, basic math concepts and abilities will still be relevant in most software engineering jobs (and even in most office jobs in general). None of these require any formal education in math, and can be easily learned through the internet.

These basic abilities and concepts include:
- Being able to make quick ballpark estimations (such as in Fermi problems) to estimate costs and system loads.
- Having a basic understanding of probability and statistics to make data-driven decisions (such as with A/B testing) and do basic data analysis to analyze results.
- Intuitive understanding of logic to write correct code and understand conditions written by others.
- Basic understanding of asymptotic analysis to ballpark the complexity of the code that you write, and steer yourself towards efficient solutions.
But Does Math Help?
Even though math is not required for most software engineering tasks, it certainly will not hurt you to have a background in math.

While there may not be much directly transferable information between math classes and typical software engineering activities, the process of learning and doing math helps you build important problem-solving skills.

Fundamentally, software engineering involves solving problems by writing code and designing software systems. Similarly, math, particularly proof-based math, involves solving problems by writing a series of correct statements in mathematical language.

At a high level, both of these activities involve translating logic and facts into some kind of expressed language. And in both situations, logical consistency and correctness are of the utmost importance.

However, this is not unique to math. Many other fields, such as philosophy, and other STEM fields such as physics, also involve similar skills. Even other activities, such as playing certain video games or solving puzzles, require similar logic and problem-solving skills.

Math is only one of many activities that allow software engineers to build up their critical thinking skills outside of programming.
What if I Want to Use Math?
Even though most sub-fields of software engineering do not directly use math, there certainly are some that do.

These include fields like machine learning, graphics, game development, robotics, and programming language development.

In these fields, you will work directly with tasks that require knowledge from math topics such as calculus, linear algebra, graph theory, probability, statistics, logic, and various discrete math topics.

However, even in math-heavy fields, it is rare to be directly translating math into code without using a library as an intermediary.

These libraries, such as the differentiable programming library TensorFlow, used primarily for neural networks, abstract away basic operations and let the programmer focus more on higher-level concepts.

As an engineer working with such a library, you will not have to write the code to carry out gradient descent, for example. You would only have to specify the architecture of your network along with how you want to train it.

So, even in these fields, you can still participate without knowing the specifics of all the underlying math. Oftentimes, just knowing the concepts and how to apply them is enough to be productive and useful in your job.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/