Investors Get Ready for the Coming Electric Car Revolution - <AUTHOR> http://www.wsj.com/articles/mind-the-shock-as-auto-investing-turns-electric-1481626699 <comment><USER2> I believe the two legacy issues are:

1) automakers have very little control over their product any more. They rely heavy on Tier 1 suppliers for major component development and production so they ship hodgepodge product

2) they look at a car as a product that is shipped and forgotten. They never have looked at it as a platform for continuous future improvement. This similar to the iPhone vs feature phone analogy-- cars from legacy manufactures are the best they will ever be the day they leave the manufacturing line.

Without changing these fundamental mindsets, they are in deep trouble.

<comment><USER3> Disclaimer up front: I work for GM, but not on vehicle development.

For #1, what would you do? Ship a much simpler product or ship a worse product?

In the current system Tier 1 supplier can concentrate expertise in a single area and spread development costs across many OEMs. A single OEM cannot effectively compete with this cost structure.

Tesla is notable for many things; one of them being its vertical integration. So far Tesla has been able to compete by both building simple cars (excluding the X, which is another story entirely) and charging quite a lot of money. They have also had serious quality issues, probably relating to their vertical integration. These quality issues may be resolved, but by that time either they or their competitors will have developed a new product, and then they will have to go through the development and refinement cycle again, at huge cost.

Regarding #2: the iPhone came out in 2007. Since then, there have been about 7 development cycles. For most automobile platforms there have been 3 or fewer development cycles since 2007. Before the iPhone, there was no real concept of remote update of mobile devices.

Automakers have caught onto the trend and you will see more mainstream OEMs doing remote updates pretty soon.

<comment><USER4> >They have also had serious quality issues.

This is not accurate. Their early models often suffer from issues, but not long term.

<comment><USER5> He works at GM. He has to repeat what he is told in company meetings.

<comment><USER3> I don't think anyone has mentioned Tesla in any company meetings that I've been to.

To be perfectly clear: Tesla and Elon have done many amazing things, and I like their approach in many areas: Marketing EVs as luxury vehicles is genius, remote updates are amazing, etc.

Elon has a daring attitude that is very refreshing to see, launching or running many companies simultaneously, making big bets on things like the Gigafactory, etc.

But they also do some silly stuff too, like the falcon wing doors on the X, and some of their vehicle assembly systems, while cool looking may be a bit too cutting edge. There's some stuff that you just don't try to prove on the production line while it is making your bread and butter.

Anyway, while my original comment may not have been nuanced, I do have a nuanced view of Tesla.

<comment><USER4> the falcon wing doors were a little wonky and the source of delays.... but the factory automation... i'm curious what you think.... because i think that is where they are really innovating. they say general assembly will be completely automated and no workers will touch these cars within a year or two.

<comment><USER3> Anything can be automated if it is designed for automation. The corollary is that if it cannot be automated, you don't do it (this will probably be an expensive lesson).

The question is: Will the automation pay off?

A machine that replaces 1 worker may cost $100,000 to $500,000 (factoring robotics, machine vision, and error proofing). The design for the part and design for automated assembly may be comparable. Now you've spent $1,000,000 to automate your carpet install. Congratulations. You could have installed carpet for 10 years manually at that price.

The big question to me is: Can Telsa learn Design for Automation in a scalable way? Other companies have tried it before and has never really payed off. iPhones are still largely hand-assembled for instance. I think the approach may pay off in the next 10-20 years, especially in light of how cheap small components have become due to the rise of smartphones; and the rise of Machine Learning.

To be clear,these are just my impressions from observations.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> The decision makers in big auto are around 10y from their retirement. Reluctance makes sense for them. It's similar to the consulting project I had at uni with an O&G company: everyone knows they should pivot for the sake of the next generation. On the other hand, upper echelons just want to simplify their life.

Now it's the labor unions that are pushing german auto makers over the EV cliff. Ironically, they have the greatest incentives to innovate/follow.

It's bothering though, that redundancies will be massive no matter what exactly they do about EVs. Can anyone offer a growth perspective for that sector (=not some kind of UBI vision)? My initial thoughts were space. But this is not really were to retool design prowess and factories either.

<comment><USER7> > Reluctance makes sense for them. It's similar to the consulting project I > had at uni with an O&G company: everyone knows they should pivot for the > sake of the next generation.

Honestly, I think the issue is that auto execs and the general public have very different views of the world.

From an executives perspective, EVs are an over-saturated, incredibly niche market that's nearly impossible to make money on. They already spend a ton of money investing in EVs and the general public doesn't care about their EV offerings and they barely sell.

The general public seem to hold Telsa up on this pedestal of innovation and point to them as an example of how automakers need to be if they don't want to be seen as dinosaurs. But I bet if you talked to Mark Fields, he'd say something along the lines of, "Nobody is going to buy an $80,000 Ford EV."

The general public is clearly not interested in actually buying EVs right now. Heck, they don't even like hybrids. Instead Americans are happily buying pickup trucks and crossovers, then complaining about about a company's lack of innovation.

Ford has the biggest lineup of EVs (with a sedan, van, and compact hatchback offering) and probably the best availability of EVs in the USA, yet they only moved 24,000 EVs this year. Telsa moved about 38,000 Models S & X in the same time period. Total USA EVs sales were a hair over 133,000. This is in a country where pickup trucks easily sell over a half-million units a year and a beige family sedan will move 200,000.

So I don't feel like the large automakers are reluctant to adopt EVs for any other reason besides the fact that the market needs decades of double-digit percent grow in order to support more than two key players.

<comment><USER8> Have you looked at the Fird Fusion Energi? The trunk is just large enough to fit a pair of shoes. This car was clearly an afterthought. That they could shove the battery in any place and get away with it. No one wants to put down a serious amount of money for an afterthought.

I see the current generation of EVs he same as early desktop computing. Clearly it's getting there but it's still too expensive for the common person.

<comment><USER9> Yeah, this is such a huge issue it's worth mentioning twice.

When it comes to EVs, Ford's efforts are afterthoughts at best. They just take their existing hybrids, drop a underpowered-and-oversized battery in the trunk, and ship it to California. It's easy to have the biggest lineup (in terms of number of models) when you aren't actually putting any thought or effort into the EV portion of any of the vehicles. Ford doesn't really make EVs, they make _compliance cars_.

Chevy has plenty of issues too (the Spark EV, for instance). But in contrast to Ford, Chevy also sells some _real EVs_. It's immediately obvious that someone at Chevy spent more than 5 minutes thinking through the Volt / Bolt _as an electric vehicle for people who really want an electric vehicle_ (and not just a compliance car) before it was shipped, which does not seem to be true of Ford's offerings so far.

<comment><USER10> > Chevy has plenty of issues too (the Spark EV, for instance).

Hey now, take that back!

I loved my Spark EV. When the lease ended I purchased a new Spark EV.

The Spark EV may have been slapped together as a compliance car or a prototype to learn from, but it is a great Bay Area car. The Spark form factor is really space efficient. It seats four and still fits into all the leftover parking spots that are too small for everyone else. It's not a perfect car, because except for the fantastic packaging the base Spark is pretty ordinary, but the electric version is massively better. The drive train is delightful, powerful, refined, responsive, and silent. One pedal driving with regen is a revelation. The Spark has been trouble free and requires no maintenance other than tires and wiper fluid.

I think there is a place for 100 mile range class EVs. The Spark EV makes the round trip from Oakland to San Jose which is the longest routine trip I make. I don't need to drive 300 miles in one go, and I don't need or want to pay for and haul around an extra 60kWH of battery pack.

Teslas are great and all, but they are _huge_. For getting around Oakland, Berkeley and SF the Spark EV is a better fit.

</comment></comment></comment></comment></comment><comment><USER3> China largely owns the supply chain for electronics. Electric cars run on... electronics.

Either western countries such as Germany, USA and Mexico will develop advanced electronics supply chains, or China will own the EV market.

<comment><USER11> > Electric cars run on... electronics.

Batteries I'd say. Electronics - I'd imagine the complexity is comparable to a normal care roughly speaking so don't foresee any major power shift based on that from the status quo.

<comment><USER3> There's also a lot of things like rare earth metals in there, which China has fewer qualms about things like local environmental concerns or worker's rights or safety.

Also, complexity is not the main issue; China simply has the inertia to continue to be the leader in the electronics supply chain

</comment></comment></comment><comment><USER12> Nissan and Tesla have proved the concept, I'd be surprised if investors are just now 'getting ready'.

<comment><USER13> Warren Buffet is an investor in China's BYD, I see electric BYD taxis in my city (Montevideo, Uruguay) everyday.

[http://www.byd.com/la/auto/e6.html](http://www.byd.com/la/auto/e6.html)

[http://www.byd.com/na/](http://www.byd.com/na/)

Edit: seems Buffet made a killing

[http://www.forbes.com/sites/russellflannery/2016/08/30/warre...](http://www.forbes.com/sites/russellflannery/2016/08/30/warren- buffett-backed-byd-rises-to-14-month-high-after-electric-car-sales-soar/)

Second edit: seems that the rest of the world is leading electric car adoption way ahead of the U.S. . Electric cars still represent a tiny fraction of the overall market (1/300th of the world's car sales). Surprisingly, it's China that leads the way.

<comment><USER14> > seems that the rest of the world is leading electric car adoption way ahead > of the U.S.

In parts of Europe, this is due to incredibly high taxes on ICE vehicles - that dwarf the US EV credits.

One of the reasons this is politically possible is because in areas with good public infrastructure, car ownership is a luxury (Or even a burden), while in most of the US, it is a necessity.

<comment><USER15> Could also be related to population density. Fewer vehicle miles travelled per capita = less range anxiety. More people living in urban-ish environments means these 'costly' electric cars are less relatively costly. Their typically smaller size makes them easier to park. Charging infrastructure is easier to locate. Etc.

<comment><USER16> Is there really a case for range anxiety in America? Getting exact numbers seems to be difficult but here in California it's about 15 miles each way. Seems like even the cheaper vehicles could handle this with a weekly charge.

<comment><USER15> Like other kinds of anxiety, it may not be fully rational :)

But one reason I own a nice car is to effortlessly drive across the state and to distant states with the comfort, power, etc of a modern car. "Just rent a car for those longer journeys" becomes less compelling when it's more than a handful of times a year.

For my commute, I could just keep driving the same 15 year old car forever -- though the butt warmers and bluetooth and so on of newer cars is a "nice to have".

</comment></comment></comment></comment></comment></comment><comment><USER17> I sometimes feel like i'm the only person in tech who loves driving and loves internal combustion engines.

<comment><USER18> You can build an app that makes ICE sounds as you accelerate in your electric car.

<comment><USER19> Fake engine noise is a thing. Ford now puts it in their trucks.[1] A DSP synthesizes V8 engine sounds, which are played through the audio system. Here's how to disable it.[2] (This is for engine noise inside the cabin, not for pedestrians. Outside noise generators may be required for very quiet cars, but they will shut down around 35MPH.)

Modern engines just are not that noisy. People need to get over this. They got over sudsy laundry detergents. In the 1960s, it was a selling point for detergents that they generated lots of foam. This was a holdover from the soap era. Laundry detergents don't need foam to work, but people expected them. And customers wanted long-lasting foam, which resulted in sudsing agents which would survive all the way through the sewerage disposal plant and into lakes and rivers. That resulted in EPA regulations which ended the suds wars. Now, nobody wants suds from laundry detergents.

[1] [https://www.washingtonpost.com/business/economy/americas- bes...](https://www.washingtonpost.com/business/economy/americas-best-selling- cars-and-trucks-are-built-on-lies-the-rise-of-fake-engine- noise/2015/01/21/6db09a10-a0ba-11e4-b146-577832eafcb4_story.html?utm_term=.3ceaf28c0d54)

[2] [http://www.f150forum.com/f118/active-noise-control-fake- engi...](http://www.f150forum.com/f118/active-noise-control-fake-engine- disable-how-312261/)

</comment></comment></comment><comment><USER20> I'm amused by the dissonance here between developing US policy w.r.t. subsidization and development of electric-first transportation and international investing houses willingness to invest.

I imagine they see it as a major opportunity to force better terms on companies developing these solutions for the US market. Which is probably exactly the goal in the first place.

</comment><comment><USER21> Google and presumably Apple have decided not to build their own cars (most likely electric). Two companies that easily have the resources to do it if they thought it made sense for themselves.

I'm no Tesla hater but cars are not phones.

</comment><comment><USER22> Somebody figured out the best ETF around today to invest in this trend?

</comment><comment><USER4> tesla has zero competition from big auto.

[https://medium.com/@andrewt3000/tesla-has-zero- competition-f...](https://medium.com/@andrewt3000/tesla-has-zero-competition- from-big-auto-a9d314830ca6#.i7kuu1n41)</comment>


Not Paying Attention in Class? China's "Smart Eye" Will Snitch on You - <AUTHOR> https://futurism.com/smart-eye-china-facial-recognition/ <comment><USER2> Just wait until this starts impacting the parents' social credit rating.

</comment><comment><USER3> One of the great challenges facing us in this 21st century is that we're going to have to come face-to-face with some of our casual assumptions about the world, now that we've got machines that can manifest them, and learn how to start clearly distinguishing between goals and methods.

Usually I'm talking about this in the context of laws, one of the easiest examples of which is the speed limit. The purpose of the speed limit is not to ensure that all cars are going 65 miles per hour or less. That is, on its own, a pointless goal. The purpose of a speed limit is to _keep people safe_ , and to give police a mechanism to exert pressures to keep people safe. That's why if the speed limit is 65 and you're driving 40 on ice and slip off the road, you still may get a speed citation even though you're "25 under"; because the law is not really about speed. It's why you might cruise by a cop when everyone around you is doing 75, and the cop doesn't simply leap out and grab the first one they see, because the law is not about speed so much as it is about safety.

In this case, consider classroom expectations. Obviously, if we have a machine that can perfectly gauge how much attention a student is paying to the teacher, bigger numbers are better than smaller numbers, right? The student who is 100% engaged is clearly better than the one 95% engaged, who is better than the student 60% engaged, who is better than the student 5% engaged. But what are you going to _do_ with those numbers? 100% almost certainly means "this student has figured out how to game the system somehow". 95% is probably still a bit high, but they may be a student who is just at the limit of their ability and learning. Meanwhile, 60% may be the one who mastered the material last week and is currently bored.

In theory one could hope that these numbers would be examined holistically, and compared to a control group against the final outcomes of the education process. In reality, ha! You've got these bright shiny _concrete_ numbers, and you've got them _now_ , and they will overshadow everything else. And in general, numbers should be larger rather than smaller, and the whole system can't hardly help but set all the goals too high. And you've got teachers looking at the numbers, and principles looking at the numbers for the school, and the school superintendent looking at the numbers across schools, and the regional government looking at the superintendant's numbers, at every step of the way the goals will creep up because Numbers should be Bigger.

Buckle in for some decades of this sort of thing before we finally become wise enough to figure out how to use these systems, or, perhaps, learn _not_ to use these systems.

<comment><USER4> Depending on the road, the purpose of the speed limit might be fuel conservation rather than safety. 55 mph was imposed in the 1970s to mitigate the oil crisis; it was not driven by safety concerns. Current consensus is that posting speed limits is neither a useful nor effective tool for promoting road safety. Instead, engineers focus on the physical characteristics of the roadway to modulate the speed at which drivers will feel comfortable.

</comment></comment><comment><USER5> as someone who didn't get diagnosed with ADHD until later in life, one naively optimistic take on this, is that perhaps it'll allow for teachers and parents to catch signs of the condition earlier in kids, and then be able to treat it better.

Unfortunately, I have a hard time believing this would actually happen. But it's better than thinking being born with ADHD is now borderline illegal in China, I guess.

</comment><comment><USER6> Just seems like the sort of product that delivers a bunch of facts you already know. It's not as if the teaching staff doesn't know what kind of expressions are on their students faces, or which ones don't pay attention.

If the administration wants data, paying someone to sit in classes to observe once in a while is probably cheaper.

</comment><comment><USER7> Just wait until some student will start wearing a specific T-shirt to trick the camera - oh wait - everyone needs to wear the same uniform too.

</comment><comment><USER8> " _It approves of re-reading._ "</comment>


How a thought leader makes money. - <AUTHOR> http://www.scottberkun.com/blog/2010/how-i-make-a-living-in-detail/

<comment><AUTHOR> I know Scott would probably never refer to himself as a "thought leader."

I picked that title because I thought "book author" wouldn't be as descriptive.

I like him because I find his _thinking_ interesting. I rarely find people referred to as "thinkers," though, so I went with thought leader.

</comment><comment><USER2> Scott says that speakers aren't generally paid for the quality of their speeches. I think that constantly being around these types of events may have given him a distorted perspective of what a "good" speaker is. Most people are absolutely awful at effectively conveying information of any sort orally. I'd almost call good speaking a lost art in an age where someone like Obama is praised for it. If you can go up on stage and present a complex subject in an understandable way to a large audience you probably are worth a couple grand at the very least.</comment>


Why wordpress does not support Google adwords as well as Amazon affiliate ads? - <AUTHOR>

I am trying to get ads for my site http://techbiztrends.info/ from Amazon and Google adwords, but could not use it :( <comment><USER2> Things may have changed in the last few years as blogspam is still pretty lucrative and has continued to advance, but I remember reading a study a few years ago (found here: [http://www.plagiarismtoday.com/2007/04/09/why- wordpresscom-i...](http://www.plagiarismtoday.com/2007/04/09/why-wordpresscom- is-virtually-spam-free/)) that made the conclusion that by barring Wordpress.com bloggers from using AdSense and other advertising services, they significantly cut down on the amount of spam Blogger and other services had to deal with. Wordpress.com does have WordAds (<http://en.blog.wordpress.com/2011/11/29/wordads/>).

Otherwise, if you don't qualify for WordAds, self-hosting may be your best option.</comment>


Apple's upending the iPhone with a $1000 model - <AUTHOR> https://qz.com/921034/apple-aapl-is-expected-to-launch-three-iphones-in-2017-without-home-buttons-and-usb-c-charging-ports/ <comment><USER2> Maybe, maybe not. Nobody knows. All speculation.</comment>


Gateway PCs Are Back - <AUTHOR> https://www.engadget.com/gateway-pc-walmart-exclusives-110039676.html <comment><USER2> I still remember those massive cow themed boxes kicking around the attic for years</comment>


Windows 98 – Still Running It (2016) - <AUTHOR> http://rlogin.dk/sites/windows-98-best-os/ <comment><USER2> Yikes, unlike the author, I'm pretty sure I would not be getting an Ethernet cable anywhere close to a system running Windows 98, much less driving an ancient web browser on the high seas of 2016. That seems like a recipe for disaster. That said, maybe most the security vulnerabilities are no longer being actively exploited in the wild...

<comment><USER3> > much less driving an ancient web browser on the high seas of 2016.

From the site:

> Can support USB2 and flash in older versions + newest firefox with KernelEx

I wouldn't even attempt to use a browser from that era on the web today. Aside from security concerns, it just wouldn't work on many sites.

</comment></comment><comment><USER4> Windows 98 truly did have the best UI of any Windows version. The newer versions of Windows all look like something Fisher-Price would design.

<comment><USER5> It was very gray and cyan by default. Those which came after are better IMO. I grew up in the DOS-Win3-9x era. Even nostalgia can't overcome how ugly the oldies are in comparison.

</comment></comment><comment><USER6> I missed win98 sometimes. It was light, easy and it has best ui in my opinion.</comment>


Why there is no Hitchhiker's Guide to Mathematics for Programmers - <AUTHOR> http://jeremykun.com/2013/02/08/why-there-is-no-hitchhikers-guide-to-mathematics-for-programmers/ <comment><USER3> > _Perhaps one of the most prominent objections to devoting a lot of time to > mathematics is that it can be years before you ever apply mathematics to > writing programs. On one hand, this is an extremely valid concern. If you > love writing programs and designing software, then mathematics is a nothing > more than a tool to help you write better programs._

Calling it an "extremely valid concern" is understating it. The dilemma is that programmers have many, many roads to follow if they want to improve their product, all of them discrete, deep fields in their own. Math is great, and certainly studying it will expand your mind...but so will studying engineering practices, statistics (which yes, is a kind of math, but not as theoretical as the kind the OP is advocating for), user interface design, and knowledge domains (medicine, legal, earth sciences, etc.)...all of which, as far as most programmers can tell, will yield concrete rewards much more easily than will mastering higher level mathematics.

<comment><USER4> Abstract math is somewhat special just like studying programming languages and semantics is somewhat special: it's something of a meta-science, applicable to _all_ the programming you do.

Everything else is specific to the domain you're programming in; these "meta" fields (I need a better name for them) have programming or reasoning _itself_ as the domain.

</comment></comment><comment><USER5> I've come up against this recently and I think a lot of imperative programmers will. For me, the basic pattern, starting from a career based on perl/php/java was this series of realizations:

\- EECS circuit design is based on a conceit that gives chips a speed limit

\- as a result, chips aren't getting much faster and that multi-cores are happening instead

\- parallel programming will become more and more essential to make a buck as a programmer

\- imperative languages aren't great for parallel programming due to mutable variables

\- functional languages are better for parallel programming due to immutable variables

\- functional languages are a lot closer to math concepts than imperative languages

\- uh-oh

So for me it's been a fun few months of stumbling through self-directed study in stats, probability, and math. Bayesian probability from some articles by Yudkowsky. Fast, clumsy review of 0th-order, 1st-order, and zfc set theory. Anki decks out the wazoo. Now I'm plodding through Learn You A Haskell.

I would _like_ to work more with actual mathematical proofs but I'm finding that tough to get into myself. It was fun paging through metamath for a few days, though.

<comment><USER6> Message passing is an ancient and well-understood mechanism for producing parallel, scalable, mutable-state imperative programs. Feel free to continue to not learn math :)

<comment><USER5> But that's not as much fun. :-)

</comment></comment></comment><comment><USER7> Actually, there _is_ something that comes pretty close to this--it's called The Princeton Companion to Mathematics, curated by T. Gowers but mostly written by about a hundred of the top mathematicians in their respective fields, and is one of the most beautiful books I've ever read.

</comment><comment><USER8> > "The proof is trivial." This is the mathematician's version of piping output > to /dev/null.

Heh heh. Never thought about it like that. Amazing write-up, btw. As somebody who dabbled in both CS & Math, I'd say the cultures are vastly different. You can spend years, decades even, just teaching undergrad calc courses while having barely 1-2 papers to your name, and yet you'd be considered a legitimate mathematician & get paid & all that. I know scores of math professors who are in that category. With CS, if you don't have productive output in a week, you are just idling & companies will fire you. CS academia isn't a whole lot different...the paper output is a lot more, though much of it is backed by programatic machinery.

As a consequence, a standardized notation/syntax has developed out of sheer pragmatic necessity. Everybody knows what you mean when you say its a hash, or a bst, or an lfsr, or a trie or a monad ( you wish :) Well atleast some of these are standard concepts across all pgmming languages.

With math, you can labor for years in some obscure field ( heh heh a mathematician will kill for that pun!) in which less than ten people know what you mean. At a conference, Hilbert was supposed to have gotten up and asked a speaker "What do you mean by a Hilbert space?". That should tell you something. The syntax is remarkably nonstandard & even simple things like edges, nodes, edge weight, graph correspondingly become arcs, vertices, payload, network depending on where the literature originates from. When I studied a few math papers in grad school, I had a lurking suspicion the author was going out of his way to obscure his thought process & result. With CS papers, you atleast get straightforward pseudocode & you can run off to your favorite language whether php or haskell & give it a shot. There are math texts out there where you pick up one of them, you feel like a complete fool, you pick up the other, you instantly get the point, and they are both talking about the same exact thing !! artin vs dummit & foote vs herstein comes to mind...i got 1000% more out of herstein than the other two.

I agree with the author that in the absence of standard math terminology, I'm afraid programers struggling to learn advanced math just learn bits & pieces necessary to get their job done & move back to fighting their daily battles with git rebase & jira tickets.

<comment><USER9> I've seen CS papers that use mainstream programming languages directly, instead of pseudocode, so you can just copy/paste it.

However, many CS papers aren't an easy lecture either, even if they talk about something really practical. I remember reading the paper on String B-trees, which is a data-structure for string search optimized for external storage (so you don't have to fit the whole index in RAM) and even if I understood all the concepts, the language was rather obtuse for no reason.

<comment><USER10> Writing prose, even highly structured prose, is an unevenly distributed skill. Thankfully, it's also perfectly possible to get better at it. Would that more academics (lawyers, &c.) would try.

<comment><USER11> Amen to that. I can't tell you how many research papers I read which muddle around with all the wrong words.

</comment></comment></comment></comment><comment><USER6> If this is intended as a defense of Math culture, I think it falls short. He does a good job of pointing out the corresponding problems in the state of programming:

 _Indeed, the opposite problems are familiar to a beginning programmer when they aren't in a group of active programmers. Why is it that people give up or don't enjoy programming? Is it because they have a hard time getting honest help from rudely abrupt moderators on help websites like stackoverflow? Is it because often when one wants to learn the basics, they are overloaded with the entirety of the documentation and the overwhelming resources of the internet and all its inhabitants? Is it because compiler errors are nonsensically exact, but very rarely helpful? Is it because when you learn it alone, you are bombarded with contradicting messages about what you should be doing and why (and often for the wrong reasons)?_

The difference is that the CS community recognizes that these are problems; every single thing he's complaining about are open problems being taken seriously and attacked from multiple directions, and there is hope for serious improvement in the coming decades. Anyone who thinks rude snobs, bad documentation, or useless compiler errors are a beneficial is rightly ridiculed as a smug weenie or accused of having an ulterior motive.

By contrast, mathematicians are defensive and complacent about their arcane, non-inclusive notation and communication: "At this point you might see all of this as my complaining, but in truth I'm saying this notational flexibility and ambiguity is a benefit." Look at the litany of problems he just presented. Consider the fact that mathematics is _not_ the only complicated subject that requires complicated, flexible, and rigorous notation. It just isn't credible that the shitty state of mathematical notation is either necessary or unavoidable. The occasional counterexample, where someone with a good understanding of a subject presents it in full rigor without resorting to the usual obfuscation, is a hint of what could be.

If your publications cannot be read without an expert interpreter, they are defective. Hypertext has been around for decades, if you're going to invent your own ad-hoc (or even standardized!) syntax to solve a problem your readers have a right that you document the meaning of your notation.

<comment><USER12> This isn't entirely true. Numerous mathematicians have publicly bemoaned the difficulty of communication between mathematicians in different specialties. So it's definitely not something that is ignored.

The question is what to do about it. We're not just talking about confusion arising from different notation between mathematical specialties (resolving that would be as easy as defining your notation in an appendix), but different, equally valid ways of mathematical thinking.

In some ways, it may be better to think of different mathematical specialties as different programming languages. Proficiency in one will help you, but won't guarantee that you can interpret another. Except that in mathematics, the differences are more extreme. If you have two Turing-complete programming languages, then you have two different tools that can solve the same class of problems. But different fields in mathematics deal with entirely different mathematical objects which require a _conceptual_ instead of _notational_ leap on the part of the reader. It's not simply a matter of figuring out how to write for loops or manipulate strings in the new language. You actually have entirely different ideas in each, and trying to impose some common notational standard among them is fraught with problems.

<comment><USER13> Fair enough. But even though there's no hope of coming up with a single programming language for everything, we do have quite good tools for popular areas. It seems like being able to mechanize the error-checking of proofs in certain of the more useful and popular subfields of math might be just what's needed by non-mathematicians?

<comment><USER4> Well, we do have proof assistants. I think people are starting to use those in more diverse fields of math now--I remember seeing an article about an algebraic proof in Coq, but I don't remember any of the details.

</comment></comment></comment></comment><comment><USER14> _"For the programmer who is truly interested in improving their mathematical skills, the first line of attack should now be obvious. Become an expert at applying the basic methods of proof"_

This may be good advice if you want to get into pure mathematics, but huge parts of maths are not pure.

Applied mathematics is very relevant for programmers - especially game programmers. It's not a sin to sacrifice mathematical rigour for the sake of discovery.

It doesn't even have to be a direct map (e.g. actual implementations of calculus or such). Just understanding various bits and pieces in granular detail can help you get precise and testable quantitative ideas for problems.

For instance, a while ago I wanted to implement a kind of smooth up-and-down motion for an object in my game. Almost immediately I thought of equations of this form:

(y position) = (some amplitude)* sin((some frequency)*(time)) + (some value to denote the origin)

This is a first step for some fairly interesting up-and-down motion - the rest is all a matter of finding suitable constants.

Similar things come to mind when you want to move an object smoothly to another position along a line, with a decreasing speed:

position = ((position you want to move to) - (current position)) / (some constant) + (some minimum speed)

This stuff just flashes before your mind if you've done plenty of physics (or 'mechanics' in mathematics) before. What's more, you'll know countless other ways of increasing the complexity of your equations without having to do much trial & error hacking (except to find things like constants and such).

For games, I'm convinced that there's still an incredibly huge variety of mathematical behaviour that has yet to be harnessed for the implementation of actual game mechanics. (Games usually just use some game engine's implementation of only some parts of classical mechanics, for instance.)

Never underestimate the relevance of applied mathematics to real-world programming, even though it doesn't really occupy a spectacularly prominent position in CS-focused courses.

</comment><comment><USER15> I think the biggest stumbling block for me was all of the stupid tricks involved in the proofs I had to do for school.

"If I add sin(x) to both sides of the equation, then I can use such-and-such identity which makes this equal foo."

If you don't make the correct mental leap, then you get completely stuck and it's really easy to give up.

<comment><USER16> It is sometimes useful for me to break down this type of problem into:

* enough memory to remember the identities * fast enough recall of identities from memory @ * fast enough exploration of possible solutions @

@ Fast enough is when you can do it all within the amount of time it takes for solving the problem to give enjoyment rather then ending a frustration.

Without the above I have to use different, usually more intentional, strategies.

</comment></comment><comment><USER17> I don't know about the OP's point on the value of proof to programmers. I do optimization and machine learning, and I _use_ all kinds of math on a regular basis. But I don't prove things, and rarely need to follow someone else's proof either. You can get a lot out of applied math without touching a proof. And if it isn't applied, then you really don't need it ;-).

I agree there is value in learning how to read math notation, so there is a valid point in there somewhere.

<comment><USER18> An analogous case is the programmer who relies on libraries and abstraction and "knows just enough to be dangerous." Statistics and optimization mathematics in particular are vulnerable to this. If you haven't read the proofs or you cannot prove it yourself, then you truly don't understand it. I'm not claiming this is you since your post doesn't imply that.

However as an example, if someone is solving linear or non-linear programs using <insert software or library here> but hasn't bothered to thoroughly study the mathematics underlying either and is just plugging in numbers from the constraint equations they came up with, then I would not want that person doing any sensitivity analysis. There would just be no way to be confident that they are interpreting the results correctly.

<comment><USER17> I've benefited from lots of theoretical classes, and you're absolutely right that you need to understand the theory of what you're doing. For example, I took a lovely class from Prof. John Hooker (at CMU) that derived Linear Programming duality as a natural consequence of Farkas' Lemma, rather than just mechanically grinding through LP tableau. I certainly followed the proofs discussed in many classes.

However, I can honestly say I got that understanding without doing hardly any proofs of my own. Graph theory was the only class where I "did proofs", and I didn't find it my favorite. (Later I did algorithmic graph theory and network flows - and that was fantastic, with no proofs.)

I guess my point is just that an engineer can understand and use a lot of pretty advanced math without spending much effort learning about proof techniques. That certainly wouldn't be how I'd spend my time. (Of course, if you enjoy doing that then knock yourself out.)

</comment></comment></comment><comment><USER19> > It's as if the syntax of a programming language changed _depending on who > was writing the program!_

This isn't unique to mathematics; it's the reason it's hard to scale the number of programmers working together on a Lisp codebase. Each programmer writes their own notation (macros), and ends up down their own rabbit-hole of a sub-language that nobody else can immediately understand.

</comment><comment><USER20> This seems like a problem of terminology. It is valid to desire a better acquaintance with the theorems others have proven, just as it is valid to desire a better acquaintance with the user-facing features of Chrome, iTunes, Excel, etc. I guess "using math" is different than "doing math", and most people are more interested in the the former.

There is a bit of a continuum, though. Using Excel effectively involves a smidgen of programming, similar to how "using math" effectively really means using other peoples' theorems to "prove" things, very informally, about your own domain. Maybe that's why people are more likely to get confused between "using" math and "doing" math.

</comment><comment><USER21> There's a lot of interesting and valuable stuff in this post (enthusiastically upvoted!), but I think there are a lot of errors, too.

First of all, let's acknowledge that many (the great majority of?) programmers have little or no use for math, and know it, and are correct. That's totally fine. I think danso's comment captures this well, with references to UI design, domain knowledge, engineering practices, etc, and dxbydt similarly mentions "git rebase and jira tickets". So let's assume we're restricting ourselves to programmers who do have a use for math (and hopefully know it).

FIRST PROBLEM

TFA's introductory claim is apparently that there are programmers who say "math is useful, I want to use it, I don't want to read or write proofs", and that this is ludicrous. It's absolutely not ludicrous.

Yes, a working mathematician's job is to explore and understand the space of mathematics, and yes, that is inextricably bound up in proof. And I would suggest that learning more about math proof is a soul-enriching use of anyone's time (in the same broad vein as learning Latin). But techniques of calculation are one of the valuable outputs of mathematicians, and it is reasonable and effective for a person with a task to say "I would like to have more powerful techniques of calculation, and I don't want to learn proofs".

For example. Certainly it is possible to learn how to do Gaussian elimination, and use it to solve systems of linear equations, to good effect, without being able to _prove_ that elementary row operations preserve the system. Maybe it helps? Maybe it doesn't? If you want to invent a new technique, I imagine that in that case being able to prove the correctness of the existing technique probably helps a great deal. But what's unreasonable about the person who says "I have these equations, I need to find the values (if any) of these variables here that make all the equations true, and I'm too busy to learn any proofs today (and too busy to write any proofs ever)"?

For a simpler example, we used arithmetic just fine before ZFC.

SECOND PROBLEM

Maybe this is actually two problems, intertwined. And maybe both of these problems are quibbling.

Primus, he says "Mathematics is cousin to programming in terms of the learning curve, obscure culture, and the amount of time one spends confused". I think this is highly questionable. Mathematics is far harder and more baroque than programming, not least because as a discipline it's nearly one hundred times older.

Secundus, after acknowledging the insanely annoying tendency of math papers to make up their own notation without ever defining it, he claims that the non- mathematician's confusion is comparable to the non-programmer's confusion at for(;;);. No, it's not comparable. The math case is hard because someone failed to tell you what you need to know, and no one wrote it down anywhere. The for-loop is only hard if you did the opposite: failed to read what was actually written down (e.g. in K&R) and took someone's word for it that the standard and general form of the for-loop is for(int i=0;i<LIMIT;i++){ / _do stuff with i_ / }

My claim here is that the learning math - even just the calculation techniques - is genuinely inherently hard. Partly that's because it's so overwhelmingly useful that if it wasn't, we'd already know it; clever students know more calculation technique by age 15 than most professional programmers know about programming. But on the other hand it's also contingently hard, because mathematicians aren't generally very interested (nor incented) to export their product so that outsiders can make use of it. Which I guess isn't so terrible; once someone else labours mightily to learn all that very-hard math, you can hire her at an exorbitant rate to make use of the calculating techniques she has learned. Or if you want to get that benefit without paying the exorbitant rates to outsource the math, you can roll up your own sleeves. Good luck!

<comment><USER11> OP here. My point was that if you want to be _better_ at math, then you need to get comfortable with proofs. There are lots of instances of using math for useful things, but if you don't do proofs you won't get any better at understanding mathematics. There are a lot of times when people want to know more about a particular mathematical fact (they genuinely want to understand why it is the way it is) but the minute you tell them, they stop wanting to hear it. This is what I think is ludicrous.

The for loop analogy may be a bit of a stretch, but the reasons for it are as wacky as for the mathematical syntax of inventing or dropping indices. Literally the C99 standard says that if a test expression is missing in a for loop, it's replaced by a nonzero constant. In my mind as a programmer and as a mathematician, that's as arbitrarily confusing as dropping the limits of an indexing variable in a summation. They both just allow you to write/type less and have the expression still mean something.

<comment><USER22> > if you don't do proofs you won't get any better at understanding mathematics

There is a vast world of mathematical understanding available to programmers who don't like proofs. I think there is some miscommunication here about what constitutes mathematics. Mathematicians tend to think of the art of proving things, whereas engineers (and programmers, and scientists) think of equations and how to solve them. I think mathematicians actually do a disservice to engineers by trying to beat them over the head with real analysis and set theory (which is why most physics and engineering departments end up having to teach their own mathematical methods courses).

The "foundational" knowledge of mathematics -- epsilons, deltas, Cantor sets, Banach spaces, etc. -- is irrelevant to almost all practitioners. Newton, Taylor, Euler, Gauss, Laplace, Bessel, Maxwell and the gang got pretty far without it. When programmers say they want to learn math, they mean they want practical knowledge: interesting functions, how to compute them, and their properties that can be applied with utility. They don't want -- or need -- to spend time poring over proofs.

<comment><USER11> It seems you're under the impression that real analysis is the foundation of mathematics (I certainly wouldn't consider Cantor sets or Banach spaces in there).

Let's say you invent a new machine learning algorithm, how can you know how well it does? If you invent an algorithm to do anything, how can you be sure it's correct? Well you can always test it some things, but if it's really a new algorithm, then you need to prove it does what you say it does in all possible cases.

It's fine and dandy if someone tells you that there is this function that you can compute and use in this way and it's the best for its purpose, but this is an extremely rare case. I believe I have mentioned this elsewhere in comments, but there is almost never a clear-cut answer in mathematics that someone can just use out of the box. It almost always involves tweaking to fit a particular application, and to really understand how to tweak an algorithm you need to understand why the algorithm works the way it does.

<comment><USER21> I agree with you that if you want to prove the correctness of a new algorithm, you need to _prove_ the correctness of that new algorithm. You're gonna want some proving skills there.

How often are programmers developing new algorithms? I guess it depends on where you draw the line for "algorithm", but let me propose two possible places for the line. On the one hand, you might use existing techniques in a new function. In this case, the proving technique you need is the theory of invariants and so on, as Dijkstra ranted about. You're not gonna need a lot of practice with higher-level math proofs for that. That's even assuming you care about "proving that it does what you say it does in all possible cases", which of course we all know is done by roughly 0% of programmers, especially with emphasis on the "in all possible".

On the other hand, you might make a bigger development, that requires more mathematical expertise. I suggest for your consideration that the correct description of a person doing this latter work is not "programmer", but "professor" (or grad student), and that this is relatively rare, and if this is what you meant all along, you've been using misleading language. I think you have it absolutely backwards when you say "this is an extremely rare case"; I think the case where you need real mathematical proof techniques is the extremely rare case, even in relatively math-heavy areas, e.g. numeric simulation. What you need, as I've said before, are techniques of calculation.

Also, my ML knowledge is weak, but from my modest knowledge, I don't think any of it works provably. It works pro _b_ ably. :) Seems a weird example to choose.

At this point, btw, I acknowledge that I'm thoroughly into "quibble" territory. =]

</comment></comment></comment></comment></comment><comment><USER23> This is good advice for programmers _who want to become better mathematicians_. That seems to me to be distinct from wanting to be better at applying mathematics to programming problems. In the same way that wanting to be a better gardener is distinct from wanting to understand the aspects of gardening that will help you write programs relevant to that domain, with the obvious caveat that mathematics-related knowledge is relevant to a much wider range of problems people try to solve using software than gardening-related knowledge.

In school I appreciated the sorts of classes that stressed proof the most, like topology or real analysis 2, because they made me a better mathematician. When programming, I am frequently glad that I took some upper level math class, but generally for reasons unrelated to whether I've actually _done mathematics_ in that area. For instance, I could take advantage of the equivalence of the square metric and the Manhattan metric in a 2-space (up to a 45 degree rotation of the space) regardless of whether my topology class had emphasized proofs. The attitude portrayed as absurd in the article ("I don't want to write or read proofs, just use theorems") doesn't seem that far off from one that would work pretty well. The main issue with that attitude is the belief that a large body of theorems can be understood without understanding any of their proofs. Programmers don't need to be able to write proofs that aren't extremely trivial, but people who want to apply ideas from some area of mathematics probably need to understand it in a deeper way than memorizing theorems.

</comment><comment><USER24> The argument of the author sounds like an argument of someone who is addicted to writing ugly Perl one-liners. Many, many, complicated and co-dependent one- liners. "But I need this expressive power to do things!" Perhaps you primary concern should be about explaining things you did, rather than doing them. Especially if your job it to explain something to people.

</comment><comment><USER25> I feel like so much of this discussion is way too general. It's impossible to debate how/how much math is needed for "programming" without speaking about a particular (programming) domain and the subset of math, if any, needed for it.

In other words, "no math is needed" and "you need proofs" are probably both true. There's some realm of programming in which no math is needed, ever. And then there's other programming that requires lots of math. But the math required, might be linear algebra in some cases and some other specific branch of math in another area. This fact is a just a reflection of the fact that "programming" is an extremely wide area. There are some realms of programming, where the "programming" aspect of it is virtually subsidiary to the math. The programming is just automating or systemizing some math which is the real work is taking place.

So, my take away from seeing this discussion and similar comments so many times is that everyone can agree that math is an enriching subject. However, from the standpoint of its relationship with your programming, going really deep into one particular area of math without a clear idea of if/how it's going to help you accomplish something previously unattainable is probably not the best use of your time.

</comment><comment><USER26> He's analogizing to the fictional "Hitchhiker's Guide to the Galaxy". There does exist an analog to the real world "Hitchhiker's Guide to the Galaxy": Carl E. Linderholm's "Mathematics Made Difficult". Utterly hilarious.

Regrettably, it's out of print, and you have a choice of paying upwards of $138.50 (abebooks.com) for a used copy of a book of jokes, or finding the pirated pdf I once encountered in a search (I've no idea how complete that was).

<comment><USER11> My upstairs neighbor has this book, and I've been meaning to steal it from him for a few months now :)

</comment></comment><comment> alok-g +1 for the book recommendation alone [1]. I finally see a book on set theory that explicitly states that the term "set" by itself is undefined.

Reading the first chapter preview at Amazon, I already see the need for a human to explain something to me:

Two sentences from the book [1]: "A possible relation between sets, more elementary than belonging, is equality." and "Two sets are equal if and only if they have the same elements". These already seem to be contradicting each other -- how can equality be more basic than belonging if the former is defined in terms of the latter.

While I agree with OP on the difficulty I face when learning advanced mathematics (notation, generally tacitly assumed by the authors), one thing that also bugs me is use of human language (!) as a part of the proofs. How do I know that the proof is correct and is not impacted by something fundamental about the language itself? Merely via inclusion of a human language in the proof, a lot more axioms "may" have been included than what meets the eye. Probably not, but I often find it hard to convince myself of this.

[1] www.amazon.com/Naive-Theory-Undergraduate-Texts-Mathematics/dp/0387900926

<comment><USER27> _Two sentences from the book [1]: "A possible relation between sets, more elementary than belonging, is equality." and "Two sets are equal if and only if they have the same elements". These already seem to be contradicting each other -- how can equality be more basic than belonging if the former is defined in terms of the latter._

Axiom of extensionality states that the sets A and B are equal _if and only if_ they have the same elements.

The point here is this: if A and B are the same set, then whenever some x belongs to A, it also belongs to B, because B is just a different name for A. Similarly, if something belongs to B, it also belongs to A. So, the implication "A is B implies A and B have the same elements" is just a logical tautology, axiom of extensionality does not say anything new in this case.

Now suppose you have two sets, C and D, such that whenever something belongs to C, it also belongs to D, and when something belongs to D, it also belongs to C -- in other words, they have the same elements. Can we conclude that C is the same set as D? Without extensionality axiom, no. That's why we usually assume axiom of extensionality, which tells exactly that whenever sets the same elements, they are the same, so that we don't end up with a weird situation where we have two sets that are indistinguishable with set theory, yet are different.

</comment></comment><comment><USER28> I know this is a bit off topic, but does anyone know of a source (book, video, website, etc) which you could use to review the math from 0 to Calculus in one day? A sort of big picture overview of how math evolves from simple to complex. I've always wanted to do it, just to keep the math in my head fresh.

<comment><USER29> I'll do an outline here - then follow each outline item to Khan Academy for steps and details

* numbers - natural numbers, integers +ve/-ve numbers addition subtraction

* numbers - rationals, reals, multiplication/division

* numbers - fraction and decimal representations - addition/subtraction/mult/division of fractions and decimals

* sets and functions - mappings, single valued and multivalued, domain and range

* powers and exponents

* algebra - functions and equations linear equations, quadratic equations, simultaneous equations

* geometry and trig

^^ althat was pre-calculus and I may have condensed the steps a lot

* limits <\-- this is basic stuff for calculus - all of calculus is about starting with finite expressions and then taking limits as something becomes infinite or infinitesimal.

* continuity of functions

* derivatives

mean value theorem

* integrals

integration and differentiation is often taught in that order but integration is much easier to understand intuitively since areas and volumes are more concrete and tangible velocity as a vector tangent to the direction of motion is less tangible to most.

After this point you take a sidestep and start the process again at a higher level with * sequences and series (limits on steroids) * linear algebra (simultaneous equations on steroids) * multivar calc (calculus on steroids)

Then there's complex analysis, differential equations, partial differential equations and so on.

Note here I am taking the usual more 'applied' approach to math which is tangible. The more 'pure' approach' - abstract and much harder for most is to go

logic and number systems real analysis algebra complex analysis measure theory / probability functional analysis ... which is what you'd do if you were on a pure math rather than an engineering math track.

Hope that helps.

<comment><USER28> Wow, thanks. You took the time to write all that. That is awesome.

</comment></comment></comment><comment><USER30> I work with mathematics applied to various applied computer science problems with a couple startups.

If anyone is interested in learning a bit of mathematics to structure programs (for real-world usage, even!) feel free to let me know what you'd be looking for. I'd love to help!

</comment><comment><USER31> The Hitch-Hiker's Guide to the Galaxy already parodies Maths:

<http://hhgproject.org/entries/bistromathics.html>

Clearly, Douglas Adams spent a lot of time in Bistros, as the second review on this site echoes his sentiments about the odd behaviour of waiters and nonabsolute numbers such as time of arrival:

<http://www.yelp.co.uk/biz/giannis-italian-bistro-san-ramon>

</comment><comment><USER32> I think contest math is the best kind of math for a programmer since it sets out to solve problems and not to necessarily come up with theories like regular math.

</comment><comment><USER29> Re: the original post IMHO, I find it has many logical flaws and while it is trying to draw attention to the fact that programmers need to learn math it may end up scaring people away.

Background: I have a BS in EE from IIT Bombay, An MS in Applied Math from USC and an almost PhD(everything but thesis) in Pure Math.

I also loved teaching math as a TA and was able to teach engineers multivariable calculus and differential equations so that they lost their fear of it.

But for the last 20 years have been in the database business. I am very enthusiastically returning to math in the form of data science in the last year.

I find that especially today it is necessary for math to be made accessible without having to prove theorems - that's for professional mathematicians.

Programmers use hardware often without knowing diddly-squat about semiconductors. And that's just fine if you don't want to or need to. We drive cars, use mobile phones and all sorts of machinery without needing to know anything about internal combustion or the CDMA algorithms or even how theory of relativity figures into GPS.

I think the insistence on setting a high bar for people to learn/use/apply math is unnecessary mystification and obscurantism.

Math is beautiful, useful and powerful. If you know math you should be wanting to simplify it's teaching and instruction, thinking hard about making it useful for the non-mathematician and also making it easier to access in a breadth-first fashion rather than the depth-first fashion in which it is currently practiced.

I know many people, engineers and mathematicians who believe that simplification is "dumbing down". I disagree vehemently.

Today if you are a programmer and want to learn math I have a few of suggestions

a) If you want to apply it in engineering take a couple of classes on Coursera/Udacity - it will be a slow an steady way to re-activate your math neurons (it's also insurance against Alzheimers to keep learning new and hard stuff).

b) Learn some statistics, learn to use R. (Coursera again)

c) Learn some linear algebra, minimal, then learn MATLAB (Andrew Ng's Machine Learning class on Coursera or a similar one by AbuMustaffa (sp?) of Caltech)

d) If you absolutely don't want to learn a new language then look at Machine Learning by Marsden which uses Python and then pick up NumPy/SciPy and look up the exciting stuff that's happening with the IPython Notebook.

e) If your focus is on pure CS the take the Algorithms track(s) by Roughgarden (Stanford) or Sedgewick (Princeton) on Coursera

This way you dont have the notation issues - R has a syntax, MATLAB has a syntax just learn it. Python hopefully is note even an issue.

Start using your math brain a little at a time - absolutely no proofs required - and THEN once you see the beauty and want to learn more and want to learn why, THEN dig deeper with the fundamentals. If you don't that's fine too - <USER2> it, put its power to use and become a better developer and engineer. Math is not trivial but it's not as hard as it's made out to be. There's way too much noise in the channel.

Good luck.

(feel free connect with me on twitter if you want to get more help (@nitin))

<comment><USER11> I certainly don't think programmers need to learn math. The vast majority of programming requires no math, and there are tons of out of the box theorems and algorithms that can be used successfully by programmers to do wonderful things.

I am just pointing out why math can scare programmers away. The first step in overcoming that fear is to identify it.

And the fact is that programmers do need to tweak the algorithms they use. Your analogy with a car works perfectly: can you expect someone who only knows how to drive a car be able to convert a sedan into something that can go off road? Then how can you expect someone who only knows how to call a function to alter its contents to suit their particular application?

I also think that I haven't set a high bar. The basic four methods of proof is quite a low bar (this could, and should be taught in high school mathematics, and it baffles me why it's not). Learning common syntax will come as you learn.

<comment><USER29> It's true you may have set a low bar re: proofs, I just don't think any formal proofs are needed at the first step.

Learning about numerical convergence and computer arithmetic so you can understand why your MATLAB Linear Algebra program is not giving a useful result is far more valuable and doesn't need any proofs. It needs a knowledge of how to _use_ theorems and results and what the conditions are for a result to be applicable. But there is no need to do the proof. Especially since many many proof sare quite idiosyncratic and give no help in suggesting how one thinks like that.

Using the analogy of the car I am talking about teaching someone who rides a bike to drive a car. My explicit non-goal is being a mechanic of _any_ kind. So your example of modifying your car is a strawman. That's exactly what I assert a student-driver doesn't need and *shouldn't have to do. It is going to be pretty much useless in actually learning how to steer and how to follow traffic rules. One is about proper usage, the other is about understanding internals. Sorry I still disagree and reassert that proofs are no use at all and a huge distraction for programmers trying to learn math. There is so much valuable and useful work a programmer can do even using existing mehods without ever modifying them. Especially with special purpose languages like R and MATLAB - the underlying algorithm are very mature and a first time user is not expected to modify them.

Quite separately I think it's extremely valuable to learn/relearn the foundations of math but this is for anyone and not specific to what a programmer needs to do useful things with math. Yes and it should be taught in high school math. It's not taught bec the teachers didn't learn it that way and so it goes ...

</comment></comment></comment><comment><USER33> Sorry, but Helvetica Neue and font weight 300 make the page unreadable for a number of people.

</comment><comment><USER34> Math is just obfuscated code that you have to run in your head.

</comment><comment><USER35> tl;dr: i'm a snobby research student who is trying to trash developers who didn't need college. (yeah. that was an ad hominem. come at me.)

<comment><USER36> That's not at all what the author is trying to say. He's pointing out the shortcomings of mathematics notation and why that can be off-putting to otherwise motivated programmers.

<comment><USER37> Not only is it not at all what the author is trying to say, I'm honestly confused at how you could arrive at that.</comment></comment></comment>


Ask HN: Is OpenAI research the latest wargames? Why not vs. climate change? - <AUTHOR> OpenAI released their latest algo baselines to the general public yesterday. Their AI is also playing top Dota 2 human teams at The International from later this day. My question as a member of the general public is pretty simple: are these the latest wargames instalments (you know, the Matthew Broderick kool-aid from his 1983 film and so on)? Is it possible to make these AIs play army vs army other than synthetic army vs synthetic army? AIs playing Civilization by Sid Meier is fascinating enough and Youtube is full of demos, but real-life scenarios? At the very least, the weakest links in real plans would be discovered. If so, why not let these latest AIs play vs climate change, for example? Just interested in HNers tech wisdom. Thanks. <comment><AUTHOR> Adding a bit of internet research from this morning, hopefully it helps. Of course, AIs are not a magic wand and we should not expect this. Deep reinforcement learning for stochastic dynamic systems is still extremely difficult, most of all it is the Markov chains modeling / unmodeling to make scenarios ultimately unreliable. Running a number of these scenarios to achieve the statistical grade maybe? Weather forecasting seems a viable analogy and a first order approximation, at this time, even if time-series predictions are passive while rl agents interact and optimize (that's why climate change with human's effect, agents playing humans or any other stakeholder). We will see.

</comment><comment><USER2> Their github repo codebase is too unreadable to be useful. Some of worst software engineering out there. The irony of some org trying to push openness but giving near unusable code.

<comment><USER3> is this by design or it just doesnt matter having bad code?</comment></comment>


Ask HN: I am a PHP Newbie, Why do most developers hate it - <AUTHOR> Could you please explain me in the terms that would make sense to me. :) that Why do most people prefer Ruby/Rails or Python over PHP.
I like PHP because it's quite easy to learn, moreover, all of the major open source CMS (wordpress) are based on PHP, since most of the websites I deal with run on wordpress so it makes my job easier too. Moreover, I am believing, PHP is the most suitable language for 'web applications' because it does not rely on frameworks etc (rails) and can develop web applications at its own.
I want to know in layman terms, why Ruby/Rails or Python are better than PHP. Since I can not figure this out, perhaps due to the fact, I do not have major experience in programming languages. I appreciate if you could explain it to me. <comment><USER2> I would keep an open mind. PHP is a stepping stone in the natural progression of a web developer and is a good skill to have.

If you are working with websites you will naturally learn HTML and CSS, then javascript, then jQuery.

Next you might move to wordpress based websites so PHP and MySQL would be the next things to learn.

Next step would be your own web application. PHP and MySQL will work for your own web application. And I would recommend developing a few from scratch with just PHP and MySQL. Creating a login system and CRUD features. Creating these without a framework will give you a good foundation to know what's going on behind the scenes when you move on to a framework. Before developing a web app from scratch it's harder to understand what Rails is doing and why it's valuable.

Once you do this then the next natural progression will be using a framework to create a web application. I recommend giving Rails and/or Laravel (PHP Framework) a try. Even though you will know more PHP than Ruby it's a good experience to see how Rails works and why it's so popular. Laravel is a good PHP framework similar to Rails if you want to stick with PHP.

I wouldn't limit yourself to PHP though. Once you have been creating web applications it should be pretty easy to learn any framework/language. I prefer Rails and Laravel but that's just a personal preference.

Back to your question. Ruby and Python (and their frameworks) are more elegant than PHP. But those choices have positives and negatives of course and depends on your clients as well. PHP is easy to learn so you have lots of bad code and bad practices out there. And there are things inherently wrong with PHP compared to other languages. But I think it's worth learning especially if you're involved with Wordpress.

Check out TeamTreehouse.com and you'll learn some good programming practices to get you on the right track. If you're just getting started the Oreilly Head First books are really good for learning HTML and CSS and their Head First PHP & MySQL is good as well.

After that you can check out railscast.com and laracast.com.

There is lots of tutorials and information out there for all languages.

Good luck.

<comment><AUTHOR> @sauuki, Thanks for the in depth reply, and this exactly answers my question.

I am already member of both treehouse and T+ and they are both awesome places to learn quickly and making sure you follow the best practices.

</comment></comment><comment><USER3> PHP is not perfect but it gets the job done. The biggest problem with PHP is that too many developer write really bad code with it. PHP is just too easy to get into without understanding how to write clean code.

If you follow best practices and use modern frameworks like Laravel, then there should be nothing to complain about PHP.

</comment><comment><USER4> The problem with PHP is its design, or lack of it to be precise. It's inconsistent and quite verbose. But it's made for the web, so it's very easy to deploy, and the workflow is straightforward, put file in a folder on a server and refresh the page. If you're new to web development but already have some programming experience, PHP is a good language to learn because it's ubiquitous and very easy to get started. If you're new to programming, I'd suggest you learn Python first; it's a beautifully designed general purpose language, and will guide you through the right path before diving into the PHP jungle.

<comment><AUTHOR> Yes I am very much interested in learning Ruby/RoR and Python too. I had a brief look over the both of them, and my first impression was their syntax is very simple and easy to learn too, compared to the objective C, which literally gave me a heart attack ;)

Perhaps, I have not developed a lengthy web application myself yet, therefore I can not determine the inefficiencies of PHP over RoR or Python. And this was the reason I posted it here, to see, How PHP can be troublesome in complex web applications and how RoR or Python handle them more efficiently.

<comment><USER4> PHP can handle as well or better than Python and Ruby. The performance difference is not that important when choosing between these languages, because they are all slow anyway. If you compare PHP vs Java or Ruby vs NodeJS, then performance gain might be an important factor when choosing. Python is used more outside of webdev than PHP and Ruby, so that might be something to consider, because there are more libraries for making UIs, games, graphics, etc.

</comment></comment></comment><comment><USER5> I'm a non-technical founder, so I have to outsource my development. I tried to work with Python and Ruby developers, but never had any luck, they seemed like hacks - and I tried to work with several of them.

PHP developers, in my experience, have their shit together. This is just my OWN personal experience. I would never hire a Python/Ruby guy again, I'm always going for PHP developers now.

<comment><USER6> Wow. Pretty broad generalization of Python and Ruby developers. Would love to get more details beyond "seemed like hacks".

<comment><USER5> Yeah, I admit it's a very broad generalization. I suspect it's because PHP developers are probably older developers with a bit more experience. Many python and ruby folks are new, and as a non-technical person, I can't really determine if they're good or not until they start working on a project.

</comment></comment></comment><comment><USER7> Some of it is due to age. People like shiny, new things. PHP isn't shiny and new any more.

Some of it is due to security. Several of the things which made PHP very accessible to new developers also encourage poor security practices. For example, sending SQL queries to the database as a raw string, rather than a parameterized query, makes for injection vulnerabilities. There are ways to work around it, but often the 'unsafe' way is a lot easier and more obvious than the safe way.

Some of it is due to the early proliferation of beginner code. PHP was _the_ language of the web right when every man and his dog were learning just enough code to make something work, then selling themselves as experts. That resulted in a lot of people writing very hacky spaghetti code, which rapidly became legacy.

Some of it is due to the switch from its procedural roots to its object oriented alternative (while maintaining backwards compatibility). This isn't really a great thing for a language to do, because it means that people who are less than completely clear as to how to solve problems in both procedural and OO versions of the language often end up writing a confusing mish-mash of code.

Most of this should not be a problem for a sensible, well learned and disciplined developer building a new system. (The security thing can still be a thing, but there are ways to handle it now).

PHP now has a fantastic culture of building fast, usable systems. Thanks to the big PHP CMSs and frameworks, there's also a lot of great interoperability (and extendability) patterns in PHP which don't really show up anywhere near as much as in other languages. It's extremely easy to deploy, it's well documented, and it's cheap to run.

If you like it, and it meets your requirements, then go for it.

</comment><comment><USER8> Whom are you providing service? Do your customers care about what language do you use? Will selection of a language make a difference in your customer's impression or satisfaction?

If not, then ignore what others say! They are are not your target market or stakeholders in your projects. Listening to them will only detract you for your main goals of having customer and having them satisfied.

</comment><comment><USER9> It all depends on what you want to do. If you search HN, you can find a presentation called "Taking PHP Seriously" from one of the guys at Facebook, discussing the enhancements that Facebook has done with a PHP virtual machine, and making the case for PHP as a tool.

There are languages I prefer. Perl does a number of things better than PHP, so does Python. But it is possible to write cogent, maintainable PHP, and there can be sound reasons to do so.

If you wish to find out why the HN crowd tends to look down on PHP, I'd suggest that you put some time into experimenting with other languages. But I'd suggest you put time into learning how to do PHP well first.

</comment><comment><USER10> In my opinion php is really bad designed, and if you google just "why php is bad designed" you can find a lot of discussions and blog posts about it, very well documented.

I can also tell you that there are a lot of really good php framework (laravel, yii, symphony, etc) that allow you to develop mvc sites very easily making php again fun and not a pain in the ass.

Personally I would never touch php code that is not in a form of mvc framework (also a personal one).

The advantage of other serverside languages like c#, ruby, python, javascript/node.js is that they are also widely used for other purposes and not only serverside, so when you learn them you also have the chance to explore other solution in more different areas.

Basically any of them is good for what you want to do, just choose one, stick with it for some time and learn it well.

</comment><comment><USER11> An aspect not mentioned yet is that for a long time php and major projects had well known security problems. It also has a poor tooling culture, in part because writing CLI scripts feels awkward.

</comment><comment><USER12> Just carry on learning it. Then when you get more experience in other languages you'll understand its short comings. But youll appreciate it for what it is.

</comment><comment><USER13> It's because a lot of people are pretentious.</comment>


My 5 Favorite Free Tools for Working Remotely - <AUTHOR> http://blog.debugme.eu/free-tools-working-remotely/ <comment><USER2> Not much to see here - if you haven't heard of Skype, Slack and Asana, you're probably very new to online collaboration. The Moleskine is an interesting addition, but I'm not sure how it counts as a "free" tool unless someone gave it to you.</comment>


Show HN: Breaking a flawed audio CAPTCHA in JavaScript - <AUTHOR> https://github.com/vladc/RoTLD-Captcha

<comment><USER2> Ahhh so they just concatenated the various MP3 segments together.

Back in the 90s I used to have great fun chopping and splicing music using disk writing utilities, thanks to MP3's progressive encoding.</comment>