Live data from Hacker News

The Mathematical Hacker

evanmiller.org

41–50 of 135 posts

Re: The Mathematical Hacker

#41

I'm in the Yegge school, so far as I think that the mathematical ignorance and, more generally, anti-intellectualism of our industry is its downfall. We see it in the lack of design sense and the awful code that is produced. VisitorFactory nonsense is something that was invented by people who hated math and wanted to tear programming away from its mathematical/problem-solving roots with a bunch of junk complexity tha…

I'm not sure why you think that math is somehow divorced from design patterns (in the abstract sense, not GoF). Some systems just need more moving parts than others, and math won't save you from that. Design sense and mathematical aptitude are complementary, not opposed, to one another.

I think that "industrial get-your-boss-off-your-back-oriented development works" and "Complex work" is a false dichotomy.

Re: The Mathematical Hacker

#42
post #29

The problem with the article is that it dreams up a false conflict and then buries its thesis, a very valid and solid one, by trying to force a contentious narrative onto that just isn't there. Very few people these days are ignorant of the points he makes and neither Yegge nor Graham are posts of some imagined counter applied math camp. I would tend to think they are pro - Yegge's interested in bio, Graham did spam…

To add to your claim that math is fundamental to computer science, I think there's a big factor that isn't being mentioned: knowing math future-proofs your career better than knowledge of any technology or language.

Mathematical depth is the irreducible core of a computer scientist's value. Fundamentally, what computers provide is the mechanization of knowledge. In the same way that robotics came along and mechanized all of the entry-level manufacturing jobs (the root of the current "skills gap" in manufacturing, more so than outsourcing in my opinion), over the coming few decades I expect that computers will mechanize most entry-level knowledge workers' jobs, if they haven't already.

And the wacky thing about comp. sci. is that our entry level positions are in fact basic knowledge-work. As the field matures, the fields that are the bread-and-butter of basic vocational computer science are increasingly swallowed by more sophisticated technical solutions that are more mechanized and productized. Comp. Sci. is an ouroboros, eating its own tail of unskilled positions.

The most obvious example currently is sysadmins: computing infrastructure is being productized and sold under the umbrella of "cloud computing," and its main value proposition is that you can cut your sysadmin budget by a huge margin. Similarly, QA and software testing departments are having their lunch eaten by better testing practices and automated solutions such as CI: the jobs aren't disappearing entirely, they are just being consolidated into a tiny department (maybe even one dev, part time) that can maintain an automated infrastructure. At a more basic level, data entry positions started drying up years ago with the advent of OCR, and now most of the big easy targets are entirely mechanical (ex. the post office/shipping).

In short, the best way to provide enduring value is to provide mathematical insight that can't be mechanized. If you can recognize optimizations and opportunities that take advantage of the unique structure of your domain, you are unlikely to be swallowed by someone with a productized version of your livelihood. If all you can manage is CRUD apps for enterprise, then when someone comes along with a general product that reduces your department from many guys writing software to one guy managing the product, you aren't gonna convince anyone of your value. At that point your only defense is the behemoth of bureaucracy, but the competitive nature of business suggests that it won't be a great defense for long.

Re: The Mathematical Hacker

#43
The irony is that the best way to find out if mathematics is actually useless to either programming or real world problem solving is to know a lot of it.Just staring at it from a safe window and then making catholic pronouncements does not help.

Re: The Mathematical Hacker

#44

I'm in the Yegge school, so far as I think that the mathematical ignorance and, more generally, anti-intellectualism of our industry is its downfall. We see it in the lack of design sense and the awful code that is produced. VisitorFactory nonsense is something that was invented by people who hated math and wanted to tear programming away from its mathematical/problem-solving roots with a bunch of junk complexity tha…

I'm not sure why you think that math is somehow divorced from design patterns (in the abstract sense, not GoF). Some systems just need more moving parts than others, and math won't save you from that. Design sense and mathematical aptitude are complementary, not opposed, to one another. I think that "industrial get-your-boss-off-your-back-oriented development works" and "Complex work" is a false dichotomy.

Mathematics isn't about numbers or even proofs. It's about simplifying until you get that class of problems down to a conceptual "nub", while thinking in a very rigorous way. Instead of five oranges plus nine oranges being 14 oranges, you just say 5 + 9 = 14, and that applies to any countable quantity.

It's because of these abstractions that we can predict the motions of planets or build computers.

This also explains the "why" of functional programming. Referentially transparent functions are just simpler than methods that are constantly changing. Of course, in the real world, it's neither desirable nor possible to eliminate mutable state: you sequester and manage it.

The opposite of mathematical rigor (defined semantics, reproducible behavior) is the sloppy, ad-hoc, corporate FactoryVisitor stuff that is tolerated under the assumption that programming has nothing to do with math.

Re: The Mathematical Hacker

#45

Earlier quoted context omitted.

I'm not sure why you think that math is somehow divorced from design patterns (in the abstract sense, not GoF). Some systems just need more moving parts than others, and math won't save you from that. Design sense and mathematical aptitude are complementary, not opposed, to one another. I think that "industrial get-your-boss-off-your-back-oriented development works" and "Complex work" is a false dichotomy.

Mathematics isn't about numbers or even proofs. It's about simplifying until you get that class of problems down to a conceptual "nub", while thinking in a very rigorous way. Instead of five oranges plus nine oranges being 14 oranges, you just say 5 + 9 = 14, and that applies to any countable quantity. It's because of these abstractions that we can predict the motions of planets or build computers. This also explains…

What is this `FactoryVistor' straw man and why do we assume that its behavior is not referentially transparent?

Re: The Mathematical Hacker

#46
post #40
post #38

Earlier quoted context omitted.

It's certainly not like that in Germany. There is usually one Java course in the first semester. The rest is math and cs theory.

It's the same in France. But the language is not necessarily Java, it may also be C, OCaml, Scheme, Python… depending on your university.

To be fair, France is insanely biased towards maths. The typical curriculum if you want a correct career in CS outside of research is to go through an engineering school and the amount of maths (and physics) you need to enter and then to graduate is mostly equivalent to a BSc. I did an engineering degree in France and an MSc in the UK, I can compare. Globally, a French student leaving high school has done slightly more maths than a UK/US first year university maths major (calculus and basic linear algebra are taught in high school). A typical CS major in France, independently of the cursus, will most likely have done the same amount of maths than someone with a maths MSc in the UK (I am talking of a 5 years curriculum which is standard for a CS degree in France). If you take a country still using the old French curriculum like Marocco, the difference is even worse. Part of the high school maths program of Marocco are only taught in advance algebra course in the UK (stuff like cyclic groups).

Everytime I read this kind of article, I can't prevent myself from thinking it's mostly a UK/US problem.

Re: The Mathematical Hacker

#47
"advanced mathematics seems completely unnecessary to existing practitioners, but only until someone figures out that a particular mathematical concept is the right way to think about the problem at hand."

Re: The Mathematical Hacker

#48
"If you are a systems and network programmer like Raymond, you can do your job just fine without anything more than multiplication and an occasional modulus."

A good network programmer should have at least passing knowledge about graph theory (the network is a graph), queueing theory (how else are you going to size your buffers?), and also some statistics (given these numbers, how much bandwidth will be taken by resends? How much data can we send per hour? How many 9s do we get for 'probability that a messages is handled within 10 seconds'?)

Good systems programmers should have some knowledge of all of these for essentially the same reasons. They also will need some knowledge of Petri nets (for deadlock avoidance), formal languages (how else are you going to spec a language or some complex protocol?)

Also, an article on this subject that mentions neither Knuth nor Dijkstra? Weird. Is that because they do not have a blog (yes, Dijkstra does not live anymore, but I doubt he would have a blog if he did)?

Re: The Mathematical Hacker

#49
post #34

There's also the simple fact that programming literally is math. http://ncatlab.org/nlab/show/computational+trinitarianism

Programming is math, in the same way that accounting is.

Doing programming all day will not make you a mathematician.

Re: The Mathematical Hacker

#50

Earlier quoted context omitted.

Mathematics isn't about numbers or even proofs. It's about simplifying until you get that class of problems down to a conceptual "nub", while thinking in a very rigorous way. Instead of five oranges plus nine oranges being 14 oranges, you just say 5 + 9 = 14, and that applies to any countable quantity. It's because of these abstractions that we can predict the motions of planets or build computers. This also explains…

What is this `FactoryVistor' straw man and why do we assume that its behavior is not referentially transparent?

I'm pretty sure none of these are referentially transparent: http://stackoverflow.com/questions/186964/java-core-api-anti... [1]

Less sarcastically, the mere existence of the builder pattern in Java, which undermines referential transparency to its core, is proof that the design of Java as both a language and community is strongly biased against a functional, referentially transparent, mathematical approach to programming, even if such a style were theoretically possible[1].

[1] eg. com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState

[2] Scala and Clojure being proof that it is still possible (though only to a lesser extent - tail call elimination and corecursion being an example where it fails completely).

Post reply on HN