6 ms·

Agreed, but if Python is your main weapon of choice, one will usually want to invest next in something really fast to bridge the gap. I wasn't aware Racket is t

Agreed, but if Python is your main weapon of choice, one will usually want to invest next in something really fast to bridge the gap. I wasn't aware Racket is that much faster....I'd like to see some benchmarks.

catnaroek 10y ago
I tend to think of Racket as an alternative to Python, rather than a complement to it. C and Rust fit better the latter description. Racket is faster than CPython, but that isn't anywhere near the top of my list of reasons to use Racket instead of Python. When speed is a priority, Rust and MLton (Standard ML) are both much faster than Racket. But: (0) Racket is much more malleable than either Rust or SML. Rather than bash your head trying to model your problem domain in the existing language, you can redefine the language until it's the ideal tool for your problem domain. (1) Unlike other languages that also advertise malleability (Common Lisp, Smalltalk, etc.), Racket is malleable in principled ways, so you can define abstractions without figuratively stomping on abstractions defined by other people (which you might also be interested in using).
- throwaway7645 10y ago
  How often are you doing something that needs to be turned into a DSL, or is this something that you do all the time once you grok it?
  - catnaroek 10y ago
    More often than I'd like to. In an ideal world, language designs would be perfect out of the box, and the right abstraction for expressing what I want to express would always be available without me having to do anything. Alas, in the real world, languages have limitations, and you can either metaprogram them away or put up with them. For example, a while back I was investigating a general framework for expressing various types of self-balancing search trees without tediously reimplementing the same ideas over and over: (0) A search tree is either a leaf or node. A node is a alternating sequence of subtrees and individual elements, beginning and ending with a subtree. (1) Rebalancing a tree preserves the sequence obtained from traversing it in-order. (2) In the specific case of binary search trees, there exist two kinds of rotations: 3-rotations (rebalancing the sequence “a,x,b,y,c”, where “a,b,c” range over subtrees and “x,y” range over individual elements) and 4-rotations (rebalancing the sequence “a,x,b,y,c,z,d”, where “a,b,c,d” range over subtrees and “x,y,z” range over individual elements). (3) It is very convenient to manipulate purely functional search trees using zippers, for more or less the same reasons it is very convenient to manipulate imperative search trees using iterators. Zipper types can be obtained from tree types using a generic procedure (given the recursive type “T = μR.F(R)”, find the derivative of “F(R)” with respect to “R”, then instantiate it at “T = R”)... if only you could express this procedure in the first place.
    - throwaway7645 10y ago
      Thanks for the reply!
- mkesper 10y ago
  If you redefine your whole language, how is your experience with understanding your code after say 6 months?
  - kd0amg 10y ago
    I've generally found, both with my own code and others' code, that `some-undocumented-special-form' is about as understandable as `some-undocumented-function' (and a similar equivalence for things that are documented).
  - catnaroek 10y ago
    That greatly depends on how principled (hence convenient) the mechanisms for redefining and/or extending the language are. Metaprogramming in Python has the annoying tendency to create a mess where the implementation details of different parts are tightly coupled to each other. But metaprogramming Racket, especially using syntax/parse, is very clean.
    - throwaway7645 10y ago
      Interesting. I wish there as a Manning "Racket in Action" book. The problem with a lot of Lisp materials is that they show you the basic constructs and not how to best use them (like you talk about above).
      - soegaard 10y ago
        Maybe "Beautiful Racket" ? http://beautifulracket.com/ http://beautifulracket.com/
      - lispm 10y ago
        On Lisp. PAIP, Common Lisp Recipes, Practical Common Lisp, Lisp Style and Design, AMOP, Object-Oriented Programming in Common Lisp: A Programmer's Guide to CLOS, ... There are various Lisp books which go beyond the basic constructs.
- lispm 10y ago
  > Unlike other languages that also advertise malleability (Common Lisp, Smalltalk, etc.), Racket is malleable in principled ways, so you can define abstractions without figuratively stomping on abstractions defined by other people (which you might also be interested in using). Just like the Common Lisp Object System Meta-object protocol, readtables, symbol packages, ...
  - catnaroek 10y ago
    I prefer defining things to tweaking them, so I don't find dynamic metaprogramming (CLOS) to be a good enough substitute for static metaprogramming (macros), and Racket's macro system is light years ahead of Common Lisp's. YMMV, of course.
    - lispm 10y ago
      I don't think macros are a good way to implement or even extend object-oriented languages. So I don't think static macroprogramming is a good substitute for a meta-object system.
      - catnaroek 10y ago
        Give me a compelling reason to design programs in an object-oriented way. Just to be clear, I don't find the ability to subvert existing definitions particularly attractive, because it undermines my ultimate goal to actually prove things about my programs. --- @lispm, I have reply here because I'm temporarily unable to make new posts. > A large share of contemporary software is written in an object-oriented way. Sure, but how does that contradict my original assertion that Racket's mechanisms for extending and redefining the language are more principled than either Common Lisp's or Smalltalk's? --- > Could it be that you just don't like/use/need/want the object-oriented ways to extend those languages and thus these mechanisms are not 'principled'? You're right that there's an aesthetic component: I don't have much taste for object-orientation. But this isn't just me being close-minded: I would take object-orientation far more seriously if someone could provide an interpretation of object-oriented programs as mathematical objects with nice properties. > How are Racket's mechanisms for extending and redefining the language more principled Racket's macro system is based on a theory of how to macro-expand in a capture-avoiding way, ruling out by construction errors that are very difficult to debug when doing similar things in Common Lisp. And macro systems are more principled than MOPs in that macros are purely static devices: you (re)define the language first, and you use it later. > Especially since Racket provides some of that, too -> Swindle. Object-orientation in Racket is completely opt-in. You don't have to use it if you don't want to, and, in fact, I just don't use it... > Is the CLOS MOP not principled? Why? ... OTOH, in Common Lisp it's far more pervasive. Everything is an object and has a class, and classes can be tampered with in arbitrary ways, precisely using the MOP. How can then you prove anything interesting about how instances of a class will behave under all circumstances? The essence of abstraction is to ignore implementation details, and concentrate on, well, abstract properties. A MOP achieves the opposite thing: it makes all implementation details available everywhere, complicating the problem of abstraction enforcement.

catnaroek 10y ago

I tend to think of Racket as an alternative to Python, rather than a complement to it. C and Rust fit better the latter description. Racket is faster than CPython, but that isn't anywhere near the top of my list of reasons to use Racket instead of Python. When speed is a priority, Rust and MLton (Standard ML) are both much faster than Racket. But: (0) Racket is much more malleable than either Rust or SML. Rather than bash your head trying to model your problem domain in the existing language, you can redefine the language until it's the ideal tool for your problem domain. (1) Unlike other languages that also advertise malleability (Common Lisp, Smalltalk, etc.), Racket is malleable in principled ways, so you can define abstractions without figuratively stomping on abstractions defined by other people (which you might also be interested in using).

throwaway7645 10y ago
How often are you doing something that needs to be turned into a DSL, or is this something that you do all the time once you grok it?
- catnaroek 10y ago
  More often than I'd like to. In an ideal world, language designs would be perfect out of the box, and the right abstraction for expressing what I want to express would always be available without me having to do anything. Alas, in the real world, languages have limitations, and you can either metaprogram them away or put up with them. For example, a while back I was investigating a general framework for expressing various types of self-balancing search trees without tediously reimplementing the same ideas over and over: (0) A search tree is either a leaf or node. A node is a alternating sequence of subtrees and individual elements, beginning and ending with a subtree. (1) Rebalancing a tree preserves the sequence obtained from traversing it in-order. (2) In the specific case of binary search trees, there exist two kinds of rotations: 3-rotations (rebalancing the sequence “a,x,b,y,c”, where “a,b,c” range over subtrees and “x,y” range over individual elements) and 4-rotations (rebalancing the sequence “a,x,b,y,c,z,d”, where “a,b,c,d” range over subtrees and “x,y,z” range over individual elements). (3) It is very convenient to manipulate purely functional search trees using zippers, for more or less the same reasons it is very convenient to manipulate imperative search trees using iterators. Zipper types can be obtained from tree types using a generic procedure (given the recursive type “T = μR.F(R)”, find the derivative of “F(R)” with respect to “R”, then instantiate it at “T = R”)... if only you could express this procedure in the first place.
  - throwaway7645 10y ago
    Thanks for the reply!
mkesper 10y ago
If you redefine your whole language, how is your experience with understanding your code after say 6 months?
- kd0amg 10y ago
  I've generally found, both with my own code and others' code, that `some-undocumented-special-form' is about as understandable as `some-undocumented-function' (and a similar equivalence for things that are documented).
- catnaroek 10y ago
  That greatly depends on how principled (hence convenient) the mechanisms for redefining and/or extending the language are. Metaprogramming in Python has the annoying tendency to create a mess where the implementation details of different parts are tightly coupled to each other. But metaprogramming Racket, especially using syntax/parse, is very clean.
  - throwaway7645 10y ago
    Interesting. I wish there as a Manning "Racket in Action" book. The problem with a lot of Lisp materials is that they show you the basic constructs and not how to best use them (like you talk about above).
    - soegaard 10y ago
      Maybe "Beautiful Racket" ? http://beautifulracket.com/ http://beautifulracket.com/
    - lispm 10y ago
      On Lisp. PAIP, Common Lisp Recipes, Practical Common Lisp, Lisp Style and Design, AMOP, Object-Oriented Programming in Common Lisp: A Programmer's Guide to CLOS, ... There are various Lisp books which go beyond the basic constructs.
lispm 10y ago
> Unlike other languages that also advertise malleability (Common Lisp, Smalltalk, etc.), Racket is malleable in principled ways, so you can define abstractions without figuratively stomping on abstractions defined by other people (which you might also be interested in using). Just like the Common Lisp Object System Meta-object protocol, readtables, symbol packages, ...
- catnaroek 10y ago
  I prefer defining things to tweaking them, so I don't find dynamic metaprogramming (CLOS) to be a good enough substitute for static metaprogramming (macros), and Racket's macro system is light years ahead of Common Lisp's. YMMV, of course.
  - lispm 10y ago
    I don't think macros are a good way to implement or even extend object-oriented languages. So I don't think static macroprogramming is a good substitute for a meta-object system.
    - catnaroek 10y ago
      Give me a compelling reason to design programs in an object-oriented way. Just to be clear, I don't find the ability to subvert existing definitions particularly attractive, because it undermines my ultimate goal to actually prove things about my programs. --- @lispm, I have reply here because I'm temporarily unable to make new posts. > A large share of contemporary software is written in an object-oriented way. Sure, but how does that contradict my original assertion that Racket's mechanisms for extending and redefining the language are more principled than either Common Lisp's or Smalltalk's? --- > Could it be that you just don't like/use/need/want the object-oriented ways to extend those languages and thus these mechanisms are not 'principled'? You're right that there's an aesthetic component: I don't have much taste for object-orientation. But this isn't just me being close-minded: I would take object-orientation far more seriously if someone could provide an interpretation of object-oriented programs as mathematical objects with nice properties. > How are Racket's mechanisms for extending and redefining the language more principled Racket's macro system is based on a theory of how to macro-expand in a capture-avoiding way, ruling out by construction errors that are very difficult to debug when doing similar things in Common Lisp. And macro systems are more principled than MOPs in that macros are purely static devices: you (re)define the language first, and you use it later. > Especially since Racket provides some of that, too -> Swindle. Object-orientation in Racket is completely opt-in. You don't have to use it if you don't want to, and, in fact, I just don't use it... > Is the CLOS MOP not principled? Why? ... OTOH, in Common Lisp it's far more pervasive. Everything is an object and has a class, and classes can be tampered with in arbitrary ways, precisely using the MOP. How can then you prove anything interesting about how instances of a class will behave under all circumstances? The essence of abstraction is to ignore implementation details, and concentrate on, well, abstract properties. A MOP achieves the opposite thing: it makes all implementation details available everywhere, complicating the problem of abstraction enforcement.