5 ms·

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 ot

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.
        spacemanaki 14y ago
        > If a compiler can't automatically eliminate tail calls, that's either a design flaw or a bug You may know this already, but my understanding is that Clojure opts to not automatically eliminate tail calls in order to use Java calling conventions, which I imagine simplifies or eases interop. I'm not defending this decision, as I don't have much of an opinion on it, but to call it a design flaw or a bug seems a bit disingenuous as there is definitely a tradeoff to be made.
        chimeracoder 14y ago
        Yes, and a "tradeoff" and a "design flaw" are just two sides of the same coin!
        lolcraft 14y ago
        I don't know why Clojure does not do TCO, but I would be surprised if the Java VM has something to do with it. I mean, why? TCO is just an AST transformation. Takes a function, returns a function and a for loop. Yeah, yeah, the easy implementation needs goto, but it's not necessary. AFAICT any tail-recursive function can be implemented as a for loop plus continue, break and return. Now, while Clojure just not implementing automatic TCO would not be a bug or a design flaw per se -- clisp does fairly well without it, because the developers just didn't bother -- if implementing such an AST transformation in the Clojure compiler is impossible, then the compiler's design is faulty. It's like programming FizzBuzz so that you can't later modify it to add a case for multiples of 7. OK, yeah, TCO without goto is not such a piece of cake, but you get the idea. And I don't think it's a trade-off in the least. If so, what are Clojure programmers winning now? The glorious overhead of thousands of function calls? Those tasty "stack overflow" back-traces, with thousands of calls to the same function?
  - pekk 14y ago
    I imagine it is the problem endemic to the culture of some languages, where tons of clunky boilerplate is built around a task which can be done much simpler, so that most of the code is about some contentious, cargo-cult methodology or dogma rather than the problem that is being solved. If you were writing a virtual guestbook for a company which has many factories, you would have an excellent reason for having objects with names like FactoryVisitor.
- sbi 14y ago
  I respectfully beg to differ that "mathematics isn't about numbers or even proofs." Why are the math books on my shelves full of numbers and proofs? What was it I was wasting my time on in graduate school? This sort of definition (really a non-definition) is so vague that it robs mathematics of its character. Is mathematics important merely because many people believe that mathematicians are clever?
  - jk4930 14y ago
    Mathematics itself is about structures and operations, properties of mathematical objects (like closedness and completeness) a.s.o. Numbers and proofs are just the tools of mathematics to work with those things.
    - hazov 14y ago
      This description defines abstract algebra and some topology well, but I am an applied mathematician and for me mathematics is about number crunching and stability of this number crunching. Without numbers or numerical structures like polynomials and matrices you'll only have set theory, some parts of algebra and some mathematical logic. Philosophers of mathematics spent the 20th century what mathematics is all about and they did not settled on any potential definition.
      - michaelochurch 14y ago
        Philosophers of mathematics spent the 20th century what mathematics is all about and they did not settled on any potential definition. Ok, I have to disagree with you here. What Godel established is that there's no complete axiom system. Every mathematical formalism will have statements P for which neither P nor ~P can be proven. This was not an unexpected result. What makes Godel's Incompleteness Theorem awesome is that it proved incompleteness, which few people thought possible. Same with Turing and the Halting Problem. Almost no one actually believed that such a program (that could determine, algorithmically, if a program halted) existed. If one did, it would blow open all of mathematics. Turing proved, in a very elegant way, that it didn't. What 20th-century mathematicians agree upon is that mathematical statements aren't "true" or "false" in an absolute, platonic sense, but that they are products of the axiom systems that generate them. Whether the Axiom of Choice or Continuum Hypothesis are "true" is meaningless. These aren't mathematical "controversies" that have people yelling at each other saying that the other is wrong. They're axioms about infinity (specifically, uncountable infinity) that, although they have no physical correlates (you can't actually Banach-Tarski an orange) are logically independent of the "obvious" axioms. What logically independent means is that neither L nor ~L will generate a contradiction, and therefore neither has any absolute high ground. Most mathematicians use AoC and CH for typical mathematics, but there are alternative mathematical worlds in which they don't hold, and those are interesting in their own right.

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.
      - spacemanaki 14y ago
        > If a compiler can't automatically eliminate tail calls, that's either a design flaw or a bug You may know this already, but my understanding is that Clojure opts to not automatically eliminate tail calls in order to use Java calling conventions, which I imagine simplifies or eases interop. I'm not defending this decision, as I don't have much of an opinion on it, but to call it a design flaw or a bug seems a bit disingenuous as there is definitely a tradeoff to be made.
        chimeracoder 14y ago
        Yes, and a "tradeoff" and a "design flaw" are just two sides of the same coin!
        lolcraft 14y ago
        I don't know why Clojure does not do TCO, but I would be surprised if the Java VM has something to do with it. I mean, why? TCO is just an AST transformation. Takes a function, returns a function and a for loop. Yeah, yeah, the easy implementation needs goto, but it's not necessary. AFAICT any tail-recursive function can be implemented as a for loop plus continue, break and return. Now, while Clojure just not implementing automatic TCO would not be a bug or a design flaw per se -- clisp does fairly well without it, because the developers just didn't bother -- if implementing such an AST transformation in the Clojure compiler is impossible, then the compiler's design is faulty. It's like programming FizzBuzz so that you can't later modify it to add a case for multiples of 7. OK, yeah, TCO without goto is not such a piece of cake, but you get the idea. And I don't think it's a trade-off in the least. If so, what are Clojure programmers winning now? The glorious overhead of thousands of function calls? Those tasty "stack overflow" back-traces, with thousands of calls to the same function?
- pekk 14y ago
  I imagine it is the problem endemic to the culture of some languages, where tons of clunky boilerplate is built around a task which can be done much simpler, so that most of the code is about some contentious, cargo-cult methodology or dogma rather than the problem that is being solved. If you were writing a virtual guestbook for a company which has many factories, you would have an excellent reason for having objects with names like FactoryVisitor.
sbi 14y ago
I respectfully beg to differ that "mathematics isn't about numbers or even proofs." Why are the math books on my shelves full of numbers and proofs? What was it I was wasting my time on in graduate school? This sort of definition (really a non-definition) is so vague that it robs mathematics of its character. Is mathematics important merely because many people believe that mathematicians are clever?
- jk4930 14y ago
  Mathematics itself is about structures and operations, properties of mathematical objects (like closedness and completeness) a.s.o. Numbers and proofs are just the tools of mathematics to work with those things.
  - hazov 14y ago
    This description defines abstract algebra and some topology well, but I am an applied mathematician and for me mathematics is about number crunching and stability of this number crunching. Without numbers or numerical structures like polynomials and matrices you'll only have set theory, some parts of algebra and some mathematical logic. Philosophers of mathematics spent the 20th century what mathematics is all about and they did not settled on any potential definition.
    - michaelochurch 14y ago
      Philosophers of mathematics spent the 20th century what mathematics is all about and they did not settled on any potential definition. Ok, I have to disagree with you here. What Godel established is that there's no complete axiom system. Every mathematical formalism will have statements P for which neither P nor ~P can be proven. This was not an unexpected result. What makes Godel's Incompleteness Theorem awesome is that it proved incompleteness, which few people thought possible. Same with Turing and the Halting Problem. Almost no one actually believed that such a program (that could determine, algorithmically, if a program halted) existed. If one did, it would blow open all of mathematics. Turing proved, in a very elegant way, that it didn't. What 20th-century mathematicians agree upon is that mathematical statements aren't "true" or "false" in an absolute, platonic sense, but that they are products of the axiom systems that generate them. Whether the Axiom of Choice or Continuum Hypothesis are "true" is meaningless. These aren't mathematical "controversies" that have people yelling at each other saying that the other is wrong. They're axioms about infinity (specifically, uncountable infinity) that, although they have no physical correlates (you can't actually Banach-Tarski an orange) are logically independent of the "obvious" axioms. What logically independent means is that neither L nor ~L will generate a contradiction, and therefore neither has any absolute high ground. Most mathematicians use AoC and CH for typical mathematics, but there are alternative mathematical worlds in which they don't hold, and those are interesting in their own right.