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

>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



And then there’s the little issue of over a magnitude improvement in performance in Julia compared to the already-optimized Common Lisp code…


True. Julia makes it easier to write performant code. Plus there're nice facilities enabling further optimization.


On average, you will not get anything close to order of magnitude speed-ups on optimized Lisp code.


This 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.


in 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




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

Search: