Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Nope, can't be done. You'd basically need to build up an entirely different language for manipulating symbols to even make any sense of it. That new language would look very much like ML, Coq, Agda, Haskell, etc.

I think people forget that it's ok to not know any of this stuff. You can spend an entire lifetime writing nothing but Java and you won't miss out on anything.

There is no reason to understand this beyond the technical challenge of understanding it. It will never be useful in any actual day-to-day software engineering endeavor because whatever you can do with the Yoneda lemma you can do without it and the Yoneda lemma does not make the solution any better, it does not make reasoning about large scale dynamic systems any easier, and it will not make your software less prone to bugs.



Well... it might help, sometimes.

I think about something like Stokes' theorem: The integral of a function over the boundary of a manifold is equal to the integral of the derivative of the function over the interior of the manifold. But in practice, one integral or the other is often easier to do; that means that the theorem has the practical effect of letting you transform some hard problems into equivalent but easier problems.

But note well that I said "some problems". There are many problems that this won't help with. There are others where the problem you're trying to solve is the easier one, and applying the theorem turns it into a harder problem.

I suspect (but do not know) that the Yoneda Lemma is similar. It can sometimes give you a simpler way of looking at a problem. But just sometimes. Sometimes the Haskell/ML view is the easiest way to solve the problem you have. And sometimes it's not.


> You'd basically need to build up an entirely different language for manipulating symbols to even make any sense of it.

No problem:

  struct symbol {
    obj_base_fields; // macro
    obj name_string;
    obj package;
    // ...
  };

  struct cons {
    obj_base_fields; // macro
    obj car, cdr;
  };


Tbh, I find lisp to be a pretty annoying language for talking about this stuff. It seems to aim just slightly below the right level of abstraction by talking about symbols where you really want to have abstract binding trees.

I'd like to see a lisp where ABTs were given a more prominent frontline treatment. That'd complete the "locality" story that often gives people pause when implementing macros.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: