Re:Ask HN: Production Lisp in 2020?
by justinmeiners on Tuesday May 19, 2020 @09:30AM
(#23234663)
I would like to consider Python a common lisp alternative. But it's one or two orders of magnitude slower and is not really standardized. I think there is a lot more that's attractive than just macros.
[ Parent
| on HN ]
Re:Ask HN: Production Lisp in 2020?
by oalae5niMiel7qu on Thursday May 21, 2020 @05:04AM
(#23256288)
...and Python doesn't have it. Image-based programming is the other thing besides macros that gives Lisp an edge. Python might as well be batch-compiled.
> and is not really standardized
What do you mean by this ?
Re:Ask HN: Production Lisp in 2020?
by justinmeiners on Tuesday May 19, 2020 @11:04AM
(#23235612)
My understanding is the Python standard is essentially whatever C Python chooses to do. They do write the changes to a specification separately, but essentially its one moving implementation, with alternatives that have compatibility limitations.
Indeed. I'm curious what Python 4 will do to Python 3.
"standard" is "whatever CPython managed to miss a segfault for today".
And PyEvalFrameEx is the stuff of nightmares that can't be really fixed because it hardcoded spaghetti that, if rewritten, could subtly break python in myriad ways that would make 2->3 migration a cakewalk.
Oh, and there's no real test suite to verify if you didn't break something subtle in implementation.
While parsing Ruby code is well known to be problematic, there is a very good reason why Ruby can have interchangeable implementation while Python pretty much can't.