10 ms·

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

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 that adds nothing. If you're doing simple things over and over, with the objective function being minimal rejection/loss rate, the anti-intellectual/industrial get-your-boss-off-your-back-oriented development works. Complex work is different. You need to invest a lot of additional energy into elegance and quality that most companies won't pay for. However, what we do is so intensely collaborative if it's done right that we are teachers more than anything else. Not engineers or programmers. Our job doesn't end when we build the thing: we have to teach people how to use it, so that it's not mindless complexity being inflicted upon them (as is true of many enterprise products) but something that actually makes their lives better (most software doesn't, because bosses have a tendency to force people to use bad software and this makes engineers' lives, and thus products, worse). It's sad to me that this is an extreme minority viewpoint, and that almost no software manager on earth will actually pay for things to be this way.

oinksoft 14y ago
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.
- michaelochurch 14y ago
  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.
  - oinksoft 14y ago
    What is this `FactoryVistor' straw man and why do we assume that its behavior is not referentially transparent?
    - chimeracoder 14y ago
      I'm pretty sure none of these are referentially transparent: http://stackoverflow.com/questions/186964/java-core-api-anti-patterns-what-is-wrong#answer-891589 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).
      - irahul 14y ago
        > [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). In clojure, loop..recur and trampoline does the job. Tail recursion is not automatic, but still, it's there and quite straight forward to use with the added benefit of recur cribbing if your call isn't a tail call.
        chimeracoder 14y ago
        This has been discussed to death already, so without opening Pandora's box too much: (1) If a compiler can't automatically eliminate tail calls, that's either a design flaw or a bug, and (2) If I wanted to write a loop, I wouldn't be asking for recursion - even if they're executed in the same way by the machine, I'm expressing something different by writing my code that way.
frozenport 14y ago
There aren't enough humans that can do math, and there are more openings for jobs than intellectuals. Programming is not necessarily a job for intellectuals, any more than painting or automotive repair is reserved for intellectuals. Have you heard of the balmer peak? This stuff we call code ain't that hard. I don't like your complexity argument. If you are a gear in a watch you do not deal with complexity. You are well insulated, dealing with your 1 or 2 immediate neighbors. Most programmers are gears, they are attempting to deal with the complexity inherent in your company is a great way to procrastinate, waste time remaking the build system, and get fired. I am sure we have all see this happen.
- papsosouid 14y ago
  >There aren't enough humans that can do math On what basis do you make that assertion? "Lots of people program who didn't bother to learn maths" doesn't mean they aren't able to learn maths. >This stuff we call code ain't that hard. Then why do we so consistently fuck it up horribly?
  - AnIrishDuck 14y ago
    > Then why do we so consistently fuck it up horribly? This is the crux of it. Coding these days "ain't that hard" because the current generation of programmers sneer at formal methods. They believe providing even semi-rigorous proofs that their code works is not worth their effort. The result? Testing code with arbitrary input is the best practice; even semi-rigorous proofs are a "luxury". Would your high school geometry teacher accept "well, here's three triangles whose angles sum to 180 degrees. QED."? Then why are we so content as professionals to provide similar "proofs" of correctness? Unfortunately, there's a strong feedback method here. Formal methods receive little treatment because there is little enthusiasm for their application. There is little enthusiasm for their application because the tools aren't advanced enough. The core problem is still the same though: programmers don't take math seriously.
    - gnaritas 14y ago
      I'd say blaming programmers is a bit wrong, blame the business; most businesses don't pay programmers to write good code, they pay for fast code that generally works. They don't want to pay too much because how hard can it be to put database data onto the screen. Most programming simply doesn't require math beyond elementary arithmetic. You think most programmers have time for formal proofs?
aGHz 14y ago
The part about us being teachers more than engineers or programmers jumped at me. I've long held the belief that code should be written far more for those reading it than for the machine executing it. Your comment builds on that and made me think of this mantra: "The machine executing my code to produce an application is a side-effect. The main purpose of my code is to teach others how I control the machine into producing the application". This, of course, holds in a setting where multiple people work together to build a sizeable codebase. There are many other settings where adopting this mantra would be counter-productive.
- gosub 14y ago
  "Our design of this introductory computer-science subject reflects two major concerns. First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute. Second, we believe that the essential material to be addressed by a subject at this level is not the syntax of particular programming-language constructs, nor clever algorithms for computing particular functions efficiently, nor even the mathematical analysis of algorithms and the foundations of computing, but rather the techniques used to control the intellectual complexity of large software systems." -- SICP From here http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-7.html http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-7.html , second paragraph. The second part also responds to the original topic.
  - aGHz 14y ago
    Right down my alley :) That's a long overdue reading for me. Thanks!
31reasons 14y ago
>anti-intellectualism of our industry is its downfall I just curious to find out, what downfall are you talking about ? Isn't software eating the world and Silicon Valley making billions ?
- shurane 14y ago
  But there's an astounding lack of mathematical rigor in software. It may all call crumbling down like a house of cards. And it does. People don't know theory, nor do they want to learn it. They just want to get work done. Although all theory is dangerous too, I think a healthy mix is a good order.
  - 31reasons 14y ago
    All softwares are not created equal. Some are born as the law and some as graffiti on the wall. A lot of code these days is just disposable.Its only used for few months and thrown away for something new. The internet and mobile apps always stays in a fluid state as user requirements, devices and the environment keep changing. It would be unimaginably hard to provide mathematical rigor to every html page-scrapping script I write. Sure there must be mathematical rigor in software that has some serious uses like in real-time systems, rockets, cars etc. I would be very upset if my car vendor does not apply some serious math to their code for car's critical systems and I think they do. and as far as my mobile app is concerned I am happy with the Xcode's static analyzer.
kamaal 14y ago
>>I think that the mathematical ignorance and, more generally, anti-intellectualism of our industry is its downfall. For the kind of human scalability our industry is currently demanding, there is no other choice but to see this as a inevitable consequence.

oinksoft 14y ago

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.

michaelochurch 14y ago
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.
- oinksoft 14y ago
  What is this `FactoryVistor' straw man and why do we assume that its behavior is not referentially transparent?
  - chimeracoder 14y ago
    I'm pretty sure none of these are referentially transparent: http://stackoverflow.com/questions/186964/java-core-api-anti-patterns-what-is-wrong#answer-891589 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).
    - irahul 14y ago
      > [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). In clojure, loop..recur and trampoline does the job. Tail recursion is not automatic, but still, it's there and quite straight forward to use with the added benefit of recur cribbing if your call isn't a tail call.
      - chimeracoder 14y ago
        This has been discussed to death already, so without opening Pandora's box too much: (1) If a compiler can't automatically eliminate tail calls, that's either a design flaw or a bug, and (2) If I wanted to write a loop, I wouldn't be asking for recursion - even if they're executed in the same way by the machine, I'm expressing something different by writing my code that way.

frozenport 14y ago

There aren't enough humans that can do math, and there are more openings for jobs than intellectuals. Programming is not necessarily a job for intellectuals, any more than painting or automotive repair is reserved for intellectuals. Have you heard of the balmer peak? This stuff we call code ain't that hard. I don't like your complexity argument. If you are a gear in a watch you do not deal with complexity. You are well insulated, dealing with your 1 or 2 immediate neighbors. Most programmers are gears, they are attempting to deal with the complexity inherent in your company is a great way to procrastinate, waste time remaking the build system, and get fired. I am sure we have all see this happen.

papsosouid 14y ago
>There aren't enough humans that can do math On what basis do you make that assertion? "Lots of people program who didn't bother to learn maths" doesn't mean they aren't able to learn maths. >This stuff we call code ain't that hard. Then why do we so consistently fuck it up horribly?
- AnIrishDuck 14y ago
  > Then why do we so consistently fuck it up horribly? This is the crux of it. Coding these days "ain't that hard" because the current generation of programmers sneer at formal methods. They believe providing even semi-rigorous proofs that their code works is not worth their effort. The result? Testing code with arbitrary input is the best practice; even semi-rigorous proofs are a "luxury". Would your high school geometry teacher accept "well, here's three triangles whose angles sum to 180 degrees. QED."? Then why are we so content as professionals to provide similar "proofs" of correctness? Unfortunately, there's a strong feedback method here. Formal methods receive little treatment because there is little enthusiasm for their application. There is little enthusiasm for their application because the tools aren't advanced enough. The core problem is still the same though: programmers don't take math seriously.
  - gnaritas 14y ago
    I'd say blaming programmers is a bit wrong, blame the business; most businesses don't pay programmers to write good code, they pay for fast code that generally works. They don't want to pay too much because how hard can it be to put database data onto the screen. Most programming simply doesn't require math beyond elementary arithmetic. You think most programmers have time for formal proofs?

aGHz 14y ago

The part about us being teachers more than engineers or programmers jumped at me. I've long held the belief that code should be written far more for those reading it than for the machine executing it. Your comment builds on that and made me think of this mantra: "The machine executing my code to produce an application is a side-effect. The main purpose of my code is to teach others how I control the machine into producing the application". This, of course, holds in a setting where multiple people work together to build a sizeable codebase. There are many other settings where adopting this mantra would be counter-productive.

gosub 14y ago
"Our design of this introductory computer-science subject reflects two major concerns. First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute. Second, we believe that the essential material to be addressed by a subject at this level is not the syntax of particular programming-language constructs, nor clever algorithms for computing particular functions efficiently, nor even the mathematical analysis of algorithms and the foundations of computing, but rather the techniques used to control the intellectual complexity of large software systems." -- SICP From here http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-7.html http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-7.html , second paragraph. The second part also responds to the original topic.
- aGHz 14y ago
  Right down my alley :) That's a long overdue reading for me. Thanks!

31reasons 14y ago

>anti-intellectualism of our industry is its downfall I just curious to find out, what downfall are you talking about ? Isn't software eating the world and Silicon Valley making billions ?

shurane 14y ago
But there's an astounding lack of mathematical rigor in software. It may all call crumbling down like a house of cards. And it does. People don't know theory, nor do they want to learn it. They just want to get work done. Although all theory is dangerous too, I think a healthy mix is a good order.
- 31reasons 14y ago
  All softwares are not created equal. Some are born as the law and some as graffiti on the wall. A lot of code these days is just disposable.Its only used for few months and thrown away for something new. The internet and mobile apps always stays in a fluid state as user requirements, devices and the environment keep changing. It would be unimaginably hard to provide mathematical rigor to every html page-scrapping script I write. Sure there must be mathematical rigor in software that has some serious uses like in real-time systems, rockets, cars etc. I would be very upset if my car vendor does not apply some serious math to their code for car's critical systems and I think they do. and as far as my mobile app is concerned I am happy with the Xcode's static analyzer.

kamaal 14y ago

>>I think that the mathematical ignorance and, more generally, anti-intellectualism of our industry is its downfall. For the kind of human scalability our industry is currently demanding, there is no other choice but to see this as a inevitable consequence.