Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python vs Common Lisp, workflow and ecosystem (2019)

lisp-journey.gitlab.io

Post reply on HN
Print view View original

81–83 of 83 posts

Re: Python vs Common Lisp, workflow and ecosystem (2019)

#81

Post by 7thaccount »

enriquto wrote: post #59
odonnellryan wrote: post #35

Earlier quoted context omitted.

This is really splitting hairs isn't it? Plenty of languages are not bootstrapped. Isn't that essentially the same thing?

No, nothing to do with bootstraping, this is completely different. My point is that you cannot develop the very algorithms that you are using. Numerical math is not only about using ready-made algorithms, it is mostly about implementing new algorithms. For example, if you invent a new matrix factorization algorithm, it is very likely that you cannot implement it in Python (or if you can, it will be either very slow o…

Nobody is arguing that, but they're saying it doesn't matter to the majority of scientists who just want to invert a matrix for some study and don't need to implement a new matrix inversion algorithm. I would use C or C++ for that most likely. That is a valid use case for some scientists, but I would expect it to be a very small number compared to those that just need to use the existing tools in the ecosystem.

I think we may be speaking past each other a bit.

Re: Python vs Common Lisp, workflow and ecosystem (2019)

#83

Post by dasyatidprime »

dasyatidprime wrote: post #74
pjmlp wrote: post #73

Earlier quoted context omitted.

> The latter allows for things like overriding __getattr__ to intercept ‘all’ method calls and property accesses, for which I don't think there's any equivalent in CLOS. CLOS already offered AOP, which you can use to control such calls. https://lispcookbook.github.io/cl-cookbook/clos.html#dispatc...

I'm not sure what you're pointing at there. I'm aware of method combinations and method qualifiers—are you referring to being able to add a general :before/:after/:around on a single generic? If so, that's not what I mean; what I mean is vaguely similar but on the first-arg dispatch axis. Here's a toy Python example. Given: class KnowItAll(object): def __getattr__(self, attr): return lambda: "yes, I know how to " + a…

Aha! I was half-wrong, but it's also horrible…

  (defclass tracer () ((actual :initarg :actual)))
  (defun make-tracer (object)
    (make-instance 'tracer :actual object))

  ;; But please don't.
  (defmethod no-applicable-method :around (gf &rest args)
    (if (typep (car args) 'tracer)
        (let* ((tracer (car args))
               (args* (cdr args))
               (actual (slot-value tracer 'actual)))
          (format t "Calling ~S on ~S" gf (cons actual args*))
          (apply gf actual args*))
        (apply #'call-next-method gf args)))
You can't do this with a real specialization on no-applicable-method, incidentally, because the first arg isn't special enough, it's just folded into the &rest. And that, I'm pretty sure, means this doesn't coexist with other uses of no-applicable-method properly… and you still can't do on-the-fly method names that aren't attached to a generic, and so on, but this does sort of account for the object forwarder case (and in fact you could extend it to allow tracers on more of the arguments!). It does, I expect, remain extremely unidiomatic by comparison.
Post reply on HN