freenode/#lisp - IRC Chatlog
Search
3:21:30
beach
I started watching a talk by Robert Virding entitled "On Language Design", and I think the next time someone suggests a revision of the Common Lisp standard, I'll point them to that presentation.
3:23:15
beach
"Be very careful when making changes suggested by users" * They often don't see the whole picture of the changes they suggest. * They often don't know what they really need. * They often want help with a solution; not [with] solving a problem.
4:03:26
contrapunctus
Ironic, in the context of a language which is famous for trusting that the user knows best.
4:04:26
contrapunctus
(And that it should be possible for the user, if they wish, to get involved the design of the language.)
4:06:09
no-defun-allowed
Arguably a user is expected to involve themselves by "extending" a language via macros.
4:06:57
beach
Not really ironic. The users get involved by experimenting, using the existing features of the language, and only after extensive experimentation and user experience is the new proposal considered for standardization.
4:07:53
borei
im not sure if im on right direction or not, so i need some advise. Im working on the client for rados/ceph, and im hitting the following problem. To dump lisp object (instance of class) i need to pack object into flat array. I didn't find better solution then to use CFFI. I don't know lisp so deep and if there is "pure lisp" solution for that problem.
4:08:43
no-defun-allowed
That is a very strange solution, and it sounds like it would get very unportable very quickly, should it depend on the memory layout of standard instances.
4:10:07
bhartrihari
I think it's a fine barbell strategy. Instead of finding a balance in the middle, it balances two extremes—a safe side (conforming code), and the unsafe (and volatile) side (non conforming code but with useful features, eg. OS threads).
4:10:08
bhartrihari
The conforming code will always work, and the very useful non-conforming code can be made to work when it arises. Hence gaining from both the sides.