Re:Squashed Bugs, with Failure Rate Heatmaps
by pfdietz on Saturday December 21, 2019 @08:58AM
(#21851199)
Lisps are compiled, generally. It's just that you can add new compiled functions to a running image, and replace existing compiled functions. The running time of compiled Common Lisp can approach that of compiled C code, and sometimes be better.
The dividing line between compiled and interpreted languages has become permeable these days anyway. Perhaps the better dividing line is between languages that are designed to compile to efficient code, vs. languages whose design precludes that. In some cases this may just mean we need smarter compilers. And this is where I really like this kind of language fuzzing: it's a great way to test compilers, and can be extremely helpful at firming up implementations of complicated optimizations.
Re:Squashed Bugs, with Failure Rate Heatmaps
by perl4ever on Saturday December 21, 2019 @01:04PM
(#21852461)
"Lisps are compiled, generally"
The environment I was working in is compiled also, but like you say, you can modify it while running.
Then I run it interactively with source debugging and when anything goes wrong, I do some editing and more than half the time I don't even have to restart the program from the beginning.
And the more subtle the things I "assert" the more direction I get when they are violated. It eliminates a lot of effort in sorting out incorrect ideas when I can just encode my incorrect ideas and let the computer find the problem.
I've always shied away from Lisp and similar, but I'm definitely reminded of how advocates describe the benefits of developing in an interpreted environment. When I was a kid, I always had the sense that only compiled languages were prestigious, industrial strength, professional, whatever.