2 ms·
Should I mention now that I think syntax-case is an awkward hacky mess, that syntactic closures solved the problem better, as did er and ir transformers from ch
by qwertyuiop924 10y ago
Should I mention now that I think syntax-case is an awkward hacky mess, that syntactic closures solved the problem better, as did er and ir transformers from chicken? (Although ir-macro-transformer is O(n), because it crawls your macro so that sucks)
Should I also mention that I feel that this is endemic of Racket itself, which tries to be the be-all-end-all by taking everything from everyone, but winds up being an awkward mess, as it tries to integrate DBC with FP and a (fairly weak, iirc) OO system, not to mention custodians, and a ton of other stuff that should have been spun off into modules and libraries, but is cluttering up core and makes me long for chicken, and want to hurl whenever I look at it?
Don't get me wrong, a big stdlib is always handy, but for god's sake, pick a SMALL set of core concepts and stick with them.
Now if you'll excuse me, I'll go get some kevlar. Knowing you lot, I may need it after this.
- samth 10y agoNote that the contract system and the OO system are built entirely with libraries, rather than being in the core. Also, syntax-case is implemented with a library on top of a much simpler core. We Racketeers spend a lot of time working on how to simplify and shrink the core -- Matthew Flatt's recent work on hygiene via sets of scopes is an example of exactly that simplification. Custodians are in the core, but it's not possible to move them to a library -- they necessarily have to integrate with things like the garbage collector. You couldn't have the things they provide, like the ability to limit part of your program to a specified amount of memory, without that.
- qwertyuiop924 10y agoWhat I meant was that the contracts and OO are integrated strongly into racket's stdlib: instead of providing a basic paradigm, and then providing alternatives, like most schemes do, Racket's default paradigm is, "all of them." That creates an overcomplicated mess.
- samth 10y agoRight, 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 agoBut 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 agoRacket 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 agoshrugs 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?