I've been asking myself this question for over 20 years: who are these people that click on ads anyway?
Ads are inherently going to be the opposite of Google's values, yet Google depends on them for the vast majority of their revenue. They show you some search results in line with their values, and if you can't get to the top of that "intrinsically", you buy ads or SEO. The folks that use that system to exploit the least intelligent win here, and Google takes a share of the profit.
Based on my Google search results in the recent past, Google isn't doing a good job of making sure the "best" websites (by my own value system, of course) make it to the top. I find myself having to go into second and third page results to get legitimate information. I'm seeing pages of medical quackery that "sounds good" but isn't based on science when I try to find diet or exercise advice.
As technology becomes more democratic, more people will use it. That means that the people that spend more time trying to sell you shit are going to win, because they're the ones that are willing to reverse-engineer the algorithm and push stuff up to the top. They add less value to society because they're spending all their time on marketing and promotion.
I wish I knew how to solve this problem. By imposing morals, Google "bites the hand that feeds".
This is clearly not a good-faith effort for Google to have you stop wasting time. Youtube has been around for over a decade and they're just getting to this now? I think this is clearly a minimum amount of effort to prevent backlash, and it is against their interests to invest in technology that helps you use their technology responsibly.
I feel like this is going to make the world even flakier than it already is. If I can waste people's time without even the few minutes it normally takes to make a phone call, what's to stop a restauranteur from effectively denial-of-service attacking competing restaurants, or what's to stop me from booking 100 dinners for Friday evening because I'm not exactly sure what I'm going to want to eat (or who I'm going to take out for that matter -- smartphones make it easy to punt on that decision too), so I retain optionality.
What stops a restauranteur from abusing Google's Gmail service? Presumably Google won't allow you to do spam with Duplex either.
If you are going to be more enterprising then you can already do this. Just put some HITs on Mechanical Turk and let them place calls. Should cost you a few bucks to flood hundreds of calls.
I don't need reservations that badly. But the difference between having to specify Mechanical Turk work and just talking to a Google appliance is pretty huge... We're talking hours vs. minutes of work.
But I am saying that it is unlikely Google will let you spam reservations. This idea that some kid will now be able to make 1000 reservations via Google is not probable.
I think it's highly probable that either the technology will be rebuilt in a way that makes abuse possible (Google being relatively open with their technology has this side effect), or that Google won't put in enough safeguards to force people to use it responsibly, but we will see. Maybe you need too many AI experts and too much data to build this technology for yourself, and maybe that only exists at Google.
Easy for him to say. If you're at the bottom, you get little satisfaction or recognition for performing well, and are instead judged based on things like how much time you've spent in the office, how much code you've written, and how much your superiors like you.
Don't listen to what the guy at the top is telling you to do with your life. Ever. But do nod and smile when he says it.
I agree with all of this, except for "nod and smile."
If you don't work there, then I think it's best to hold leaders emotionally accountable for their effect on the world. If you do work there, then it's really up to you, but there's a middle ground where you don't legitimize the system but don't rock the boat.
For example, you could just not nod, and not smile. And only pretend to clap after the next announcement. And if everybody does this, it adds up without anybody being a target.
> For example, you could just not nod, and not smile. And only pretend to clap after the next announcement. And if everybody does this, it adds up without anybody being a target.
Exactly. Doesn't take much thought to realize that a guy with $100 billion dollars has no idea what the average life is like, and has no reason to be giving life advice.
"If you're at the bottom for long / You're doing something wrong."
Definitely don't listen to the people at the bottom telling you how to run your life. Ideally, listen to people who started where you started, and rose to where you want to get.
> Definitely don't listen to the people at the bottom telling you how to run your life. Ideally, listen to people who started where you started, and rose to where you want to get.
There's a lot of bad advice there too. People like to attribute their success to something they did but most people have no clue why they are successful. Luck has a lot to do with it and sometimes people succeed in spite of things they think might help.
Who would you rather be: the person who attributes their success to their actions, or the person who complains about not being successful?
You don't necessarily have control over whether you're successful, but you have a lot of control over how you see yourself and your personal narrative.
I think if you're a programmer wondering what math will help you in your career, which is the question this article is trying to answer, this article is misleading.
Most working programmers won't have to know any math beyond arithmetic.
For instance,
"Also, how does one distribute a large computation across globally distributed data centers? You have to understand some physics to do this well: at Internet scale, the speed of light starts to be a bottleneck. Heat dissipation, density of electrical current draw per unit area, etc, are all real world considerations that go into what programmers do"
Come on, let's be real. In grade school we learned that light goes around the earth 8 times a second. That means 1/16 of a second (63ms) to go around to the other side of the world. That doesn't set a useful lower bound since this is the ballpark of latency within a country anyway. You're just going to ping between the two servers and measure the latency.
That being said, programming could in theory require any kind of math. If you're doing machine learning, you'll need to understand statistics. If you're doing graphics programming, you'll need to understand trigonometry, linear algebra, etc.
If you're writing software for the medical industry you'll presumably have to understand a little bit about how that industry works, but I wouldn't suggest programmers go learn that just for the sake of improving their "general" programming skills.
Here's a more realistic take:
1) Learn math as necessary for a field you're interested in
2) Know binary and hexadecimal representations of numbers.
3) If you're going to use a lower-level language, understand how signed/unsigned arithmetic works, boolean algebra, and some basics of the floating point representation (in a nutshell, don't assume that computations are exact, so don't rely on equality (==)).
4) Understand time and space complexity. For most programmers, this is going to be simple: don't nest too many for-loops. I'm guessing 90% of programmers will never have to construct an algorithm whose complexity involves a logarithmic function, except for maybe binary search. Even then, most programmers will rely on libraries to do those things.
5) Be able to do back of the envelope calculations, and understand that order of magnitude is more important than exact numbers. Try to do them in your head so you can quickly evaluate possibilities.
6) Increasingly, statistics and machine learning are becoming important for programmers to know. Learn some basic statistics and it will make you much more desirable. Play around with R or Octave or numpy and don't make the mistake of applying too much statistics without thinking, unless you're in the marketing department.
Programmers use tons of math, they just don't recognize it. Partially because you can still come out of even a bachelor's program in computer science and still think "math is just about numbers", but some of it is also just excessive familiarity and not realizing the easy things that you're doing that are actually mathematical because school trained you that Math must be Hard and you have to be Sitting There and Thinking Very Hard or you're not Doing Math.
Every day I'm using mathematical reasoning such as "I reached this line of code, and since this is a structured program I am guaranteed that this variable was initialized by the time I got here", "this function can only return either a non-empty string XOR an error and has nowhere it can throw an exception so if I handle those two cases I have fully handled everything this function can do", "the error string has the username in it, and values like that must come from somewhere, so even though I've been looking for an hour and can't find it, mathematically the thing generating the error message must have access to the username", "if I construct this as a pure function that does no IO, on the flip side, no users of this function will have to worry about what errors could arise during IO, reducing the mathematical cognitive load of using this function for users".
Then you start stringing together those steps by the dozens and hundreds and thousands and millions (and you get qualitative differences there too, but those don't fit into a little post like this anywhere near as well), and you can build software.
You don't have to realize you're reasoning mathematically (proof: look around), but you're leaving useful tools in the toolchest if you don't. Even if you won't believe me about building systems this way, I can assure you those magical stories about people who can debug systems at a glance that have defeated others for hours or days comes back to someone who either formally or by experience has a fairly mathematical understanding of the system in question and was able to apply some sort of logic, even if only intuitively, to arrive at that conclusion.
But that's mostly logic, at best mathematical logic. I don't think anyone formally reasons when writing code anyway, we mostly rely on intuition. Maths isn't about numbers but it's not about intuition neither.
Programmers doing actual math would be modeling problems and creating proofs for their solutions. Usually we clasify those problems based on the field of math we use to model them.
Saying we do tons of math implies we use a lot of knowledge from a lot of those fields. But most of the time, programmers use only the introductory notions of those fields. We are usually guided by a domain expert anyway so that the math part is correct.
Programmers don't use a ton of math. They use some math.
I think most modern mathematicians would be taken aback if you told them logic is not math. You might be surprised what some logicians have gotten up to.
And sure, if you define what I talked about as not math, then you don't use math. If you don't want to use the tools of mathematical thought, be my guest. It's one of my competitive advantages in the marketplace.
But I think Dijkstra would be pretty surprised to hear that structured programming wasn't math, and you might be interested in budgeting six months or so to play with Coq or something like it, where you'll learn that the difference between proving code and what you do in just trying to make code work and debug code is much more a quantitative difference than the qualitative difference you think. There's no magic in how code proofs work... it's the same processes you use all the time if you code at any scale beyond a single screen of code, just taken to their logical conclusion.
Propositional logic / zeroth-order logic is like arithmetic. You didn't consider numbers (by which I gathered you meant arithmetic) as math, and I'm the same in saying this type of logic is not math.
Logic is a VAST field, and most programmers don't get to use most of it, that was my point.
I already played with Coq (that feels weird to say :)) ). It is a very specialized tool useful in very specific cases. I don't think it will ever be adopted as the standard way of programming since it's really unproductive.
Just because you use math that is really heavy does not mean you understand the math behind completely. We can view a ball throw as a complex quantum-mechanical physical process but we don't call ourselves theoretical physicists for being able to throw a ball.
Some of your points remind me of Underwood Dudley's 2010 article "What is Mathematics For?" [1]. Briefly, he argues that we greatly exaggerate how much math you actually need in most jobs that people usually think of as needing math, but nevertheless learning math is worthwhile and important because of what it teaches you about how to think.
I agree. It's (usually intuitively learned) reasoning that's very similar to the logical reasoning of mathematics. I think if you were to study, say, calculus in a manner typical of a first course in college, you'd be missing out on that sort of problem solving, but you'd definitely get that if you took a proofs-based class in analysis ("This function is continuous on this interval, so it must have a maximum. How can I use that to prove what's being asked?").
> Come on, let's be real. In grade school we learned that light goes around the earth 8 times a second. That means 1/16 of a second (63ms) to go around to the other side of the world. That doesn't set a useful lower bound since this is the ballpark of latency within a country anyway. You're just going to ping between the two servers and measure the latency.
> 1) Learn math as necessary for a field you're interested in
I think this a Rumsfeldian problem: you can address the known unknowns, but what about the unknown unknowns?
There's no great answer to this, and it's why I think the original post was advocating the broad fields of math.
Just knowing math exists, though, doesn't address the depth to which you study it. I've gone at monads about five times now and I think I get it, to where I see why a promises library works the way it does. Same with databases, learned SQL, then stumbled across the wonderfully cranky dbdebunk.com, read Date's book, finally spent some months working on an implementation of the relational algebra and finally grokked it.
The problem with some of these deeper subjects is you'll have many "aha" moments only to look back at your early "ahas" and realize you had no idea what you were doing.
I'm not so sure. Programming is isomorphic to mathematics (via logic) as proven by the Curry-Howard Correspondance, and so is not just applicable to ones problem/industry domain—it's applicable in a much more general sense. In my experience, the learnings on both sides of the coin filter back to the other in surprising and often highly insightful ways.
> Most working programmers won't have to know any math beyond arithmetic.
If your job is to write code that moves information back and forth between a database and a web page, this may be somewhat true. However, once you get beyond that to the point you are actually solving problems in code (not just moving information) you are going to need math beyond arithmetic. Algebra, boolean logic, and statistics are just a few things programmers use all the time--almost to the point that they may not think of them as "using math" because it is just built into the way they think.
I think this is how we should revamp science education. Teach people how to examine the evidence and how one can fool themselves. Less inclined plane problems, more scientific reasoning.
This book made proof based math approachable for me. There are mechanical aspects to proofs that are probably best practiced in a structured way and this book does that by also acquainting you with set theory.
Do NOT read Rudin. He is terse and unless you are already well versed in mathematics it is simply incomprehensible.
My recommendation would be Spivak’s calculus. There are a million great exercises and the book is beautifully typeset and overall a pleasure to read. Don’t let the title fool you, there are analysis exercises in there.
1 - you want to learn to prove things. Then yes, Rudin is a shitty text to learn by yourself because he really likes a certain type of, for lack of a better phrase, "beautiful" proof that requires a bunch of insightful jumps to get to. He'll then show the proof and really not discuss about how he got there. What a student needs is the ability to string facts/theorems that he or she knows together and how to turn that into a proof. Without a good professor, Rudin is (imo) terrible for that.
2 - you want to learn analysis, and care less about proving things. Reasons for this may be you need a bit the underpinnings for various reasons, and you care less about proving things and more about understanding. I think Rudin is a pretty good text then.
Spivak's calculus is a great book but be prepared to spend a lot of hours on it.
Everyone gets into coding a different way. If she is inclined toward design, I would definitely start with HTML and go from there.
As a new coder even things like learning the tree-like structure of HTML, the brutality of an errant slash or missed closing tag, or the frustrations of bringing a visual idea to fruition with plain text are challenging enough. I wouldn't worry too much about HTML "not being real code".
If time is on your side (more than a year), I would gently nudge her into HTML and see what she comes up with. If she finds it tedious maybe try another route, but if it sticks I would segue into simple Javascript or CSS after that depending on what she wants. If she wants more control over how the page looks, naturally she'll want to learn CSS. If she wants more control over functionality and making the page "do" something, Javascript.
As a completely radical idea, you could show her LOGO. I remember that being incredibly inspirational when I was a kid and appealing to the artistic side.
If time is on your side, you are lucky in that she can afford to play around and not go down the bootcamp route which will inevitably lead to burnout. I say nurture the interest as gently as possible.
My wife actually got into programming using netlogo, then processing. It's all about agents, and her work was trying to explain how aggression leads to sociality. It provided a nice clean (and fun) interface for tweaking parameters and seeing how creatures "evolve".
From there she learned some python and Ruby. It was a pretty naturual progression, she just wanted to "do stuff"
