3 ms·

Right, we think that contracts and OO programming are both important things that programmers want and need, and so they deserve high quality support from the la

by samth 10y ago

Right, we think that contracts and OO programming are both important things that programmers want and need, and so they deserve high quality support from the language. The traditional Scheme approach of not making choices and not integrating things hasn't served anyone well, and isn't the approach that other languages like Python or Ruby take.

qwertyuiop924 10y ago
But Racket isn't making choices either. Python and Ruby say that procedural programming is the choice for small projects, and OO is what you should be using for larger projects. You can do other things, but that's the default. Racket's approach is to toss 50-odd paradigms at you, and say: "screw it, you figure it out." At least with the traditional scheme there was a default: a sort of procedural paradigm, with some functionalism mixed in. With Racket, there isn't even that. Give us contracts and OO, and all the other paradigms, but give us a reasonable default paradigm as well.
- samth 10y ago
  Racket provides contracts for all paradigms you might want to use -- DBC is not a separate paradigm. The reasonable default is writing programs with structures and functions. Most people use OO primarily for the GUI (where OO works quite nicely). This is the same paradigm that you'd find in ML or Rust or Go in many cases.
  - qwertyuiop924 10y ago
    shrugs The docs could have fooled me. You try to learn anything about Racket, and pretty soon, you're 10 levels deep into nonsense about contracts and other junk that you shouldn't need to see just to find the semantics of cons, or define. Which is to say, the docs are bad. But that's excusable. What I do NOT find exusable, and what started this conversation, is that syntax-case is overcomplicated compared to, say, er and ir macros, or syntactic closures, all of which were already available. So use a more complex system, when it's been shown a simpler one will do?
    - samth 10y ago
      For posterity, here are the docs for `cons`: http://docs.racket-lang.org/reference/pairs.html?q=cons#%28def._%28%28quote._~23~25kernel%29._cons%29%29 http://docs.racket-lang.org/reference/pairs.html?q=cons#%28d... I don't see 10 levels of nonsense there. But clearly you're not happy about larger aspects of the system that it's probably not worth debating here. But let's just say that (a) syntax-case is a pattern matching library, not a macro system, and (b) Racket's macro system has demonstrated its usefulness by building those libraries that you claimed were built in, such as OO systems and contracts.
      - qwertyuiop924 10y ago
        Racket's macro system has proved it is as capable as any other macro system. No more, no less. I merely argue that it is overly complicated.
      - qwertyuiop924 10y ago
        in response to b, I knew full well how those libraries were built. When I said built in, I meant part of core. And before you claim they aren't in core, I mean what the rest of the scheme world means when they say core: stdlib.

by samth 10y ago

qwertyuiop924 10y ago

But Racket isn't making choices either. Python and Ruby say that procedural programming is the choice for small projects, and OO is what you should be using for larger projects. You can do other things, but that's the default. Racket's approach is to toss 50-odd paradigms at you, and say: "screw it, you figure it out." At least with the traditional scheme there was a default: a sort of procedural paradigm, with some functionalism mixed in. With Racket, there isn't even that. Give us contracts and OO, and all the other paradigms, but give us a reasonable default paradigm as well.

samth 10y ago
Racket provides contracts for all paradigms you might want to use -- DBC is not a separate paradigm. The reasonable default is writing programs with structures and functions. Most people use OO primarily for the GUI (where OO works quite nicely). This is the same paradigm that you'd find in ML or Rust or Go in many cases.
- qwertyuiop924 10y ago
  shrugs The docs could have fooled me. You try to learn anything about Racket, and pretty soon, you're 10 levels deep into nonsense about contracts and other junk that you shouldn't need to see just to find the semantics of cons, or define. Which is to say, the docs are bad. But that's excusable. What I do NOT find exusable, and what started this conversation, is that syntax-case is overcomplicated compared to, say, er and ir macros, or syntactic closures, all of which were already available. So use a more complex system, when it's been shown a simpler one will do?
  - samth 10y ago
    For posterity, here are the docs for `cons`: http://docs.racket-lang.org/reference/pairs.html?q=cons#%28def._%28%28quote._~23~25kernel%29._cons%29%29 http://docs.racket-lang.org/reference/pairs.html?q=cons#%28d... I don't see 10 levels of nonsense there. But clearly you're not happy about larger aspects of the system that it's probably not worth debating here. But let's just say that (a) syntax-case is a pattern matching library, not a macro system, and (b) Racket's macro system has demonstrated its usefulness by building those libraries that you claimed were built in, such as OO systems and contracts.
    - qwertyuiop924 10y ago
      Racket's macro system has proved it is as capable as any other macro system. No more, no less. I merely argue that it is overly complicated.
    - qwertyuiop924 10y ago
      in response to b, I knew full well how those libraries were built. When I said built in, I meant part of core. And before you claim they aren't in core, I mean what the rest of the scheme world means when they say core: stdlib.