I've moved to @sigue , mostly because it has a bigger character limit per post.
| My Where | A bit north of Boston, USA |
| My GitHub | https://github.com/cgay |
| My Languages | EN / ES / Dylan / Common Lisp |
| My Hobby | #dylanlang https://opendylan.org |
Carl Gay
@sigue
- 112 Followers
- 90 Following
- 713 Posts
#GoLang / #CommonLisp / #C++ hacker by day, #DylanLang hacker and #weiqi / #baduk / #go player by night.
@[email protected] I agree with you.
Maybe a good way to phrase this is, "only use _internal_ punctuation and leave punctuation at the periphery to the handler higher on the stack."
But I feel like we shouldn't be chaining text together anyway. There should be an automatic display of the "caused by" chain. Doesn't Java do something like this now?
"RPC error" caused by "file operation failed" caused by "permission denied"
Some guy in Texas with the same name as me just signed up for a cheesy dating site. Good luck, buddy. I'm rooting for ya.
(Though if he can't even type his email address correctly I have my doubts.)
in/on is a mighty fine distinction, especially if you're not a native English speaker. With this in mind, I propose the following....
(loop for c being the conses of ...)
Yes, it's a joke.
Slightly different, but related topic: this would be a lot nicer than the current mess of hash-value and hash-key loop constructs:
(loop for k => v in table ...)
Whoa...switching fedi instances is SUCH. A. PAIN.
lispm@sigue yes, one could see experiments in making generic functions faster since a few years. I find that very interesting, That's also good to see that the European Lisp Symposium attracts such talks & papers. #lisp and #commonlisp users should be aware that the ELS is taking place once a year. Next time it is in Vienna/Austria May/2024. https://european-lisp-symposium.org
@weekend_editor Pass. 😜
https://www.youtube.com/watch?v=7IpnmXnO1RU is really impressive. I need to look into the code more and figure out exactly what it's doing. Limitations etc. That kind of thing is a powerful argument for CL. On the other hand, it's also a powerful argument for IMPROVING CL with some changes like that.
Lightning Talk: Julia Functions, Now in Lisp
@lispm This is, of course, highly personal, but I also find that for some reason in Common Lisp the code often ends up being much harder to follow than more straight-forward code that perhaps uses a few more lines. A huge contributor to this is macros plus "let's help out the compiler and do all this at compile time".
Yep, it's extremely powerful, but can be pretty complex.
I hope to write up a comparison of the CL vs Dylan protocol buffers implementations when I'm done with the Dylan one.
@weekend_editor @lispm @[email protected]
RE: "[T]here's also tight vs loose binding, which is Dylan's version of the fragile base class problem."
I think that may be one reason why the names were officially changed to "development" and "production" modes. One should compile code in "production" mode when running in production.