4 ms·
It's not math, though. It's abstract reasoning, as is math. And that's about as deep as the similarities go. Math can't deal with imperfect input and/or side
by codr7 7y ago
It's not math, though.
It's abstract reasoning, as is math. And that's about as deep as the similarities go.
Math can't deal with imperfect input and/or side effects without turning into something else. And code without real world side effects is useless, as is real world perfection.
- JustFinishedBSG 7y ago> Math can't deal with imperfect input and/or side effects without turning into something else. It very much can though.
- codr7 7y agoNot in any sense that matters here, no. There's no math equation for reading from a socket. Code is not math and math is not code. It's possible to sort of hide the fact by stacking enough abstractions on top, but in the end it's going to be the same old code that makes it happen.
- UK-AL 7y agoLinear types and session types can enforce protocols for reading from a socket.
- ulucs 7y agoWell, you have Maybe for imperfect inputs and monads for side effects.
- codr7 7y agoBut Haskell isn't math, it's code dressed up in a math costume.
- uryga 7y agowould you consider Lambda Calculus to be math?
- FridgeSeal 7y agoHaskell is code (attempting to) implement category theory. It’s about as close to a programming language representing maths as we have (probably along with APL type languages)
- Syzygies 7y agoMy first language (not counting Basic or Fortran on punched cards) was APL, and my current language is Haskell. I'm a PhD mathematician. Luckily, I was trained far enough down the street from MIT to escape their Lisp world view, so we coded our computer algebra system in C, and it was fast enough to succeed and bring us tenure. Today, we'd choose Haskell. Thinking in Haskell is the same feeling as thinking about math research. I know mathematicians who can only code in Haskell. The trouble with discussing languages online is it's harder to assess if each party has actually used each language. The dogma in such discussions is completely "welcome to my world" familiar to me as a mathematician. We all have different opinions, and we're all sure we're right.
- codr7 7y agoHaskell is definitely one of the languages that looks most like math. Being used to math, and solving math problems, I can certainly see how that's helpful. Making the jump to stating that everyone would be better off coding math style, which is what some are desperately trying to pull off; doesn't make any sort of sense. It's remarkable how far you can get within such a rigid and formal framework. But for most messy real world problems, there are better solutions. Lisp being the most powerful invented so far.
- smallnamespace 7y ago> Math can't deal with imperfect input See stats, probability, information theory, and signal analysis
- mjburgess 7y agoThat's a different sense of "imperfect", meaning, "inexact". Here: Malformed
- mannykannot 7y agoThere's some non-trivial math behind the methods for defining and selecting well-formed data.
- nomel 7y agoAnd they tend to always accept data that is malformed to look like regular data.
- mannykannot 7y agoPutting aside the question of whether this is a tendentious exaggeration, it is more of a problem in ad-hoc code.
- pron 7y ago> Math can't deal with imperfect input and/or side effects without turning into something else. This is just not true. Differential equations certainly deal with change over time (except it's not called "side effects" there) and imperfections. The analog for discrete systems in temporal logic.
- sixbrx 7y agoIt's not called side effects there because there are none, in the modern mathematical formulation at least. The goal is to identify solution functions, and those are just sets of ordered pairs or something similarly inert.
- pron 7y agoExcept that even in programming, the name "side-effect" is not too clear. It stems from the fact that subroutines sometimes behave a bit like functions, and when they don't, we call the added behavior a "side effect". If you want to be mathematically precise, subroutines are predicate transformers, and, again, there are no "side effects" (This is a mistake functional programmers make when they speak of referential transparency; most languages are referentially transparent, and that was the whole point of the paper that first introduced the term to programming. They are only not referentially transparent with respect to an incorrect semantic model). The philosophical difference between a subroutine with side effects and a derivative is small.
- mannykannot 7y agoIn general, the point is better made with analytical thinking, rather than math specifically, but if you end up in a place where you need the math, it is important to recognize that. Cryptography is perhaps the starkest example, but math also comes into play in reasoning about concurrency, and in determining if your proposed architecture will perform adequately.
- xhgdvjky 7y agoside effects are an implementation detail