3 ms·
>There is support in other editors, but it is nowhere near as complete and convenient as it is in Emacs. Why not, rather giving up the language, just disable t
by forgotpwd16 4y ago
>There is support in other editors, but it is nowhere near as complete and convenient as it is in Emacs.
Why not, rather giving up the language, just disable the debugger? Found from SO[1]
(defun debug-ignore (c h) (declare (ignore h)) (print c) (abort))
(setf *debugger-hook* #'debug-ignore)
Of course you lose a significantly strong functionality but so you do moving elsewhere.
>are multiple implementations of this ANSI standard, each with their own set of features.
Can just target a single implementation. Though, similar to previous, this kinda kills the point of having a standard and multiple implementations.
Some code examples on the CLOS section and how it compares to Julia's approach will be nice and will make the points made easier to understand. The rest seem to be indeed cultural issues rather technical which for a language to be considered is also important.
[1]: https://stackoverflow.com/a/3074698 https://stackoverflow.com/a/3074698
- proffeatur8 4y agoAnd then there’s the little issue of over a magnitude improvement in performance in Julia compared to the already-optimized Common Lisp code…
- forgotpwd16 4y agoTrue. Julia makes it easier to write performant code. Plus there're nice facilities enabling further optimization.
- deleted 4y ago[deleted]
- reikonomusha 4y agoOn average, you will not get anything close to order of magnitude speed-ups on optimized Lisp code.
- eigenspace 4y agoThis really depends. If someone is trying to operate with small user defined generic functions on a large array of user defined defined classes in Common Lisp in a tight loop (i.e. what Michael was doing) then performance is very very hard to recover. Of course, performance claims about Common Lisp are very slippery because one can always say "well, __ implementation using ___ library can avoid ____ specific performance problem", but I think it's fair to say that in general, generic code and CLOS features can land you in very serious performance trouble quite quickly, especially if you're trying to make reasonably portable code.
- medo-bear 4y agoin general if you are concerned with performance you will want the ability to "touch metal", which means digging into implementation-specific compiler details. this is something that sbcl is very good at providing portable code is appropriate when the whole language can benefit from your library