4 ms·

Everything comes at a cost of something in computation! That is what “trade offs” means. You can have any feature in any language once you undermine the defau

by ukj 5y ago

Everything comes at a cost of something in computation! That is what “trade offs” means. You can have any feature in any language once you undermine the default constraints of your language. You can implement Scala in Brainfuck. Turing completeness guarantees it! But this is not the sort of discourse we care about in practice. https://en.wikipedia.org/wiki/Brainfuck https://en.wikipedia.org/wiki/Brainfuck

dkersten 5y ago
Yes, and? How is that relevant here? You said "you can't", kortex said "you can" and then you moved the goal posts to "you can because of turing completeness, but its bad, Why do you even bother making the point?" to which I replied "because its a valid response to you're `you can't`" now you moved them again to "everything comes at a cost" (which... I also said?). Of course everything comes at a cost and yes, that's what "trade off" means. Dynamic languages come at a cost too (type checking is deferred to run time). So, this time, let me ask you: Why do you even bother making the point?
- ukj 5y ago
  Tractability vs possibility. You don't grok the difference. You can implement EVERYTHING in Brainfuck. Tractability is the reason you don't. The goalposts are exactly where I set them. With my first comment. "Every programming paradigm is a good idea if the respective trade-offs are acceptable to you."
  - dkersten 5y ago
    Its perfectly tractable though. Just because you don't understand it or don't think it is, doesn't make it true. > "Every programming paradigm is a good idea if the respective trade-offs are acceptable to you." That's not what we are responding to. Nobody here is arguing over this statement. We are responding to you assertion that static typed compile-time checked languages _prevent_ you from having dynamic dispatch and that you _can't have_ routers because of that. Neither of which are true. Dynamic languages prevent you from having compile time checks. Does that make them bad? Static languages give you compile time safety, but if you're willing to forego that [1], then you can get the EXACT SAME behavior as dynamic languages give you. You literally said: For example, one good reason why strong static types are a bad idea... they prevent you from implementing dynamic dispatch. Routers. You can't have routers. Nowhere did you say anything about trying to implement it at compile time. Also, if strong static types are a bad idea because you can't maintain them all the time, then dynamic typed languages are a bad idea because you don't get static types ever, its always at runtime. Just because a hammer can't screw in screws doesn't mean its a bad idea, it just means that you can't use it for all use cases. This is the same. You can use static types and for the few cases where you need runtime dynamism, then you use that. That doesn't make the static types in the rest of your code bad. It just gives you additional tools that dynamic types alone don't have. [1] to various degrees, its not all or nothing like you seem to be implying, there are levels of middle ground, like std::variant which maintains safety but you need to enumerate all possible types, or std::any which is fully dynamic but you give up compile time checks
    - ukj 5y ago
      Nothing PREVENTS you from doing anything with a computer except your own, mutually incompatible design goals! I am pointing out (and you seem to be agreeing) that you can't have static type safety AND dynamic dispatch _______AT THE SAME TIME__________ Which is why you get static type safety ____AT COMPILE TIME____. And dynamic dispatch ____AT RUNTIME___. You were the one moving the goal posts all along by flip-flopping between time-contexts.
      - dkersten 5y ago
        Ok, I think I understand what you are trying to say. Instead of telling us how we don’t understand various things, how about next time you define your terms, choose your words more carefully and be clearer with your explanations, so we can actually understand what you’re trying to say. So let me restate what I think you meant. Maybe I’m wrong. > a limitation of compile time static types is that they cannot do dynamic dispatch, which is relies on information that isn’t known at compile time. I think we can all agree on this? Note that I said it’s a limitation, not that it’s bad. Limitations don’t make something bad in themselves, they only constrain when it is an appropriate tool. You wouldn’t say that a submarine is bad because it can’t go on land? It’s a limitation but that doesn’t make it bad. Then you said that because of this limitation, “you can’t have routers”. But you can have routers in static languages like C++, Rust or even Haskell. You have a choice (trade off) to make: 1. either you give up on some dynamism to keep compile time checks by enumerating the types you can dispatch on (as std::variant does) 2. or you choose to give up static checking (for this part of your code only!) and move it to runtime first full dynamic logic (as std::any does). When giving up compile time safety for one part of your code, you do not give it up for all of your code, because you can runtime validate then on the boundaries going back into statically checked code paths, so the compiler cab assume that they are valid if they get back in (as the runtime checks would reject bad types) Neither case is “you can’t have routers”, but sure you can’t have fully dynamic routers purely at compile time. Also, both options are perfectly tractable and both cases are typically first class language features (at least in the static types languages I’ve used). In no case are the “bad” options, despite each option having different limitations. In a dynamic-types-only language, you don’t get to choose the trade offs at all, you only get “fully dynamic no compile time checking, runtime checks only”. Note also that in real life, few things are truly fully dynamic. You are always constrained by the operations that are expected to be carried out on the dynamic data and while you might not know at runtime what days you could get, you DO know what operations you expect to run on the data. And you can perform compile time checks around that. So for a router, so you really need it to be fully dynamic? Or can you live with it being generic (ie it’s a library that does routing and it can support any type, but you constrain it to known types when you actually use it). If so, you have options that maintain type safety: you can use OOP inheritance, you can use enumerated types like std::variant, you can use generics/templates. The library works for any types but the user chooses what types to implement based on the operations that will be performed on the data. Even dynamic types do this, they just defer it to runtime. Or you can have the router operate on purely dynamic types but the handlers that are routed to are statically typed (eg if in C++ the router uses std::any and the handler registers what types it can accept and the router checks validity before handing the data off).
  - bidirectional 5y ago
    You can't actually implement everything in Brainfuck. You can implement something which is performing an equivalent computation in an abstract, mathematical sense. But there's no way to write Firefox or Windows or Fortnite in Brainfuck. Turing completeness means you can evaluate any computable function of type N -> N (and the many things isomorphic to that), it doesn't give you anything else.
    - dkersten 5y ago
      Just as a Turing machine requires an infinitely sized tape to compute any computable function, so too would brainfuck require an indirect sized tape (or whatever it’s called in BF) to compute any computable function. Since memory is finite, neither of these properties are actually available on real hardware.
    - ukj 5y ago
      I am interested in computation. Period. Not any particular model of computation (programming language); and not merely computation with functions from N->N. Quoting from "http://math.andrej.com/2006/03/27/sometimes-all-functions-are-continuous/ http://math.andrej.com/2006/03/27/sometimes-all-functions-ar..." "The lesson is for those “experts” who “know” that all reasonable models of computation are equivalent to Turing machines. This is true if one looks just at functions from N to N. However, at higher types, questions of representation become important, and it does matter which model of computation is used."
- deleted 5y ago
  [deleted]

by ukj 5y ago

dkersten 5y ago

Yes, and? How is that relevant here? You said "you can't", kortex said "you can" and then you moved the goal posts to "you can because of turing completeness, but its bad, Why do you even bother making the point?" to which I replied "because its a valid response to you're `you can't`" now you moved them again to "everything comes at a cost" (which... I also said?). Of course everything comes at a cost and yes, that's what "trade off" means. Dynamic languages come at a cost too (type checking is deferred to run time). So, this time, let me ask you: Why do you even bother making the point?

ukj 5y ago
Tractability vs possibility. You don't grok the difference. You can implement EVERYTHING in Brainfuck. Tractability is the reason you don't. The goalposts are exactly where I set them. With my first comment. "Every programming paradigm is a good idea if the respective trade-offs are acceptable to you."
- dkersten 5y ago
  Its perfectly tractable though. Just because you don't understand it or don't think it is, doesn't make it true. > "Every programming paradigm is a good idea if the respective trade-offs are acceptable to you." That's not what we are responding to. Nobody here is arguing over this statement. We are responding to you assertion that static typed compile-time checked languages _prevent_ you from having dynamic dispatch and that you _can't have_ routers because of that. Neither of which are true. Dynamic languages prevent you from having compile time checks. Does that make them bad? Static languages give you compile time safety, but if you're willing to forego that [1], then you can get the EXACT SAME behavior as dynamic languages give you. You literally said: For example, one good reason why strong static types are a bad idea... they prevent you from implementing dynamic dispatch. Routers. You can't have routers. Nowhere did you say anything about trying to implement it at compile time. Also, if strong static types are a bad idea because you can't maintain them all the time, then dynamic typed languages are a bad idea because you don't get static types ever, its always at runtime. Just because a hammer can't screw in screws doesn't mean its a bad idea, it just means that you can't use it for all use cases. This is the same. You can use static types and for the few cases where you need runtime dynamism, then you use that. That doesn't make the static types in the rest of your code bad. It just gives you additional tools that dynamic types alone don't have. [1] to various degrees, its not all or nothing like you seem to be implying, there are levels of middle ground, like std::variant which maintains safety but you need to enumerate all possible types, or std::any which is fully dynamic but you give up compile time checks
  - ukj 5y ago
    Nothing PREVENTS you from doing anything with a computer except your own, mutually incompatible design goals! I am pointing out (and you seem to be agreeing) that you can't have static type safety AND dynamic dispatch _______AT THE SAME TIME__________ Which is why you get static type safety ____AT COMPILE TIME____. And dynamic dispatch ____AT RUNTIME___. You were the one moving the goal posts all along by flip-flopping between time-contexts.
    - dkersten 5y ago
      Ok, I think I understand what you are trying to say. Instead of telling us how we don’t understand various things, how about next time you define your terms, choose your words more carefully and be clearer with your explanations, so we can actually understand what you’re trying to say. So let me restate what I think you meant. Maybe I’m wrong. > a limitation of compile time static types is that they cannot do dynamic dispatch, which is relies on information that isn’t known at compile time. I think we can all agree on this? Note that I said it’s a limitation, not that it’s bad. Limitations don’t make something bad in themselves, they only constrain when it is an appropriate tool. You wouldn’t say that a submarine is bad because it can’t go on land? It’s a limitation but that doesn’t make it bad. Then you said that because of this limitation, “you can’t have routers”. But you can have routers in static languages like C++, Rust or even Haskell. You have a choice (trade off) to make: 1. either you give up on some dynamism to keep compile time checks by enumerating the types you can dispatch on (as std::variant does) 2. or you choose to give up static checking (for this part of your code only!) and move it to runtime first full dynamic logic (as std::any does). When giving up compile time safety for one part of your code, you do not give it up for all of your code, because you can runtime validate then on the boundaries going back into statically checked code paths, so the compiler cab assume that they are valid if they get back in (as the runtime checks would reject bad types) Neither case is “you can’t have routers”, but sure you can’t have fully dynamic routers purely at compile time. Also, both options are perfectly tractable and both cases are typically first class language features (at least in the static types languages I’ve used). In no case are the “bad” options, despite each option having different limitations. In a dynamic-types-only language, you don’t get to choose the trade offs at all, you only get “fully dynamic no compile time checking, runtime checks only”. Note also that in real life, few things are truly fully dynamic. You are always constrained by the operations that are expected to be carried out on the dynamic data and while you might not know at runtime what days you could get, you DO know what operations you expect to run on the data. And you can perform compile time checks around that. So for a router, so you really need it to be fully dynamic? Or can you live with it being generic (ie it’s a library that does routing and it can support any type, but you constrain it to known types when you actually use it). If so, you have options that maintain type safety: you can use OOP inheritance, you can use enumerated types like std::variant, you can use generics/templates. The library works for any types but the user chooses what types to implement based on the operations that will be performed on the data. Even dynamic types do this, they just defer it to runtime. Or you can have the router operate on purely dynamic types but the handlers that are routed to are statically typed (eg if in C++ the router uses std::any and the handler registers what types it can accept and the router checks validity before handing the data off).
- bidirectional 5y ago
  You can't actually implement everything in Brainfuck. You can implement something which is performing an equivalent computation in an abstract, mathematical sense. But there's no way to write Firefox or Windows or Fortnite in Brainfuck. Turing completeness means you can evaluate any computable function of type N -> N (and the many things isomorphic to that), it doesn't give you anything else.
  - dkersten 5y ago
    Just as a Turing machine requires an infinitely sized tape to compute any computable function, so too would brainfuck require an indirect sized tape (or whatever it’s called in BF) to compute any computable function. Since memory is finite, neither of these properties are actually available on real hardware.
  - ukj 5y ago
    I am interested in computation. Period. Not any particular model of computation (programming language); and not merely computation with functions from N->N. Quoting from "http://math.andrej.com/2006/03/27/sometimes-all-functions-are-continuous/ http://math.andrej.com/2006/03/27/sometimes-all-functions-ar..." "The lesson is for those “experts” who “know” that all reasonable models of computation are equivalent to Turing machines. This is true if one looks just at functions from N to N. However, at higher types, questions of representation become important, and it does matter which model of computation is used."
deleted 5y ago
[deleted]