libera/commonlisp - IRC Chatlog
Search
20:36:07
Michal
Does anybody have any recommendations for machine learning libraries in Common Lisp?
20:44:03
Qwnavery
It's a hard one because I'm unaware of any ML projects that have GPU accellerated support
20:46:28
Michal
I thought it was much faster than Python, but I heard Python had an optimised library via numphy
20:46:55
Michal
What's CUDA? I'm very new to all of this. I just finished Andrew Ngs course and wanted to try stuff out
20:53:00
Qwnavery
Michal: cool, to get started with CUDA you'll need the Proprietary Nvidia CUDA drivers https://developer.nvidia.com/cuda-downloads
2:34:43
sukaeto
late to the conversations, but I (think I) understand what beach is saying re: binding
2:36:03
sukaeto
they sometimes use it the way a compiler writer would - as in "this variable is bound to this value"
2:36:28
sukaeto
they also use it in the logical sense - as in "this variable is not free in this form. It is bound."
2:39:20
sukaeto
in the second sense, you're saying the variable is bound by the *context*. (progv '(*x*) () (boundp '*x*)) <- *x* is bound in the sense that it won't be susceptible to variable capture, no matter where that progv is put
5:05:52
beach
lisp123: You can figure out the answer by checking for those in existing code. So if I take SICL for instance, we seem to have 25 :before, 31 :after, and 53 :around.
5:10:11
lisp123
I was wondering how useful they were since you could also bundle some of that code into the primary methods. In Sonja Keene's book, they note it as useful for code reuse (this was for :before and :after at least), where more specific classes can do some additional side effects on top of the primary method, either before or after
5:12:14
beach
lisp123: When I taught a small class at the university of Auckland, I showed the students how, if you don't have auxiliary methods, then you might sometimes have to change the interface to obtain certain optimizations, so that's a no-no for stable APIs. They were totally convinced.
5:12:36
beach
lisp123: So you can obtain the same effect with only primary methods, but you can't then also have your software modular.
5:13:11
beach
You probably haven't seen that issue, since I bet your code is fairly small, and you write mainly for yourself.
5:13:47
lisp123
Yes, I don't use much state at all or have large code at all, hence wanted to ask what was used in bigger projects.
5:14:29
lisp123
So basically, the primary method gives the primary interface which clients use, and then you add some stuff before/after/around it?
5:14:35
beach
Then you just have to take my word for it, that auxiliary methods are a must for larger projects, and especially for stable libraries.
5:15:25
beach
Yes, one common thing to do is to have the library define an :around method that can intercept the client call, and do special things then.
5:17:43
beach
Common Lisp has a lot of that kind of stuff, i.e., features that are almost never used, but when you need them, you really can't do without them. Since other languages often don't have these features, they have to sacrifice modularity, maintainability, performance, etc.
5:18:49
beach
For instance: custom metaclasses, custom method combinations, custom function types, reader macros, macros, etc., etc.
5:19:07
lisp123
Yes, its very well thought through. I basically assume anything in CL is there for a very good reason
5:19:40
beach
So the incorrect conclusion made by people who don't like Common Lisp is that, since these features are rarely used, they aren't really useful. Very wrong!
5:30:14
jeosol
beach: I do agree that for large projects, those auxilliary methods are a must. I application have non-trivial hierarchy and those :before, :after methods do help to implements things clearly.
5:31:44
jeosol
I am you mention maintainability and modularity of the codebase, these are important for nontrival programs, otherwise, you get a mess that no one wants to deal with or maintain
5:37:09
hayley
I once used a lot of :after methods for a "reactive" programming style, but then hurt my head on concurrency. But I suppose that's orthogonal to the utility of auxiliary methods (though having behaviour in one place makes modelling marginally easier).
6:02:32
beach
Also, Common Lisp is designed to make these features easy to implement. There is no need to have a committee that votes on new syntax. It can all be done in the form of library code.
6:03:55
jeosol
beach: yes. I have coded in C++, not a huge program, but it was a pain. The CL project I have been working for a while, is way larger, but the logical and physical design is much easier to manager.
6:04:27
jeosol
it's hard to make other see, the fact you don't have to fight the language and it does help you all the way
6:05:01
jeosol
not worrying about excessive compile/link-time issues with C++ header files otherwise, your build takes forever
6:05:29
jeosol
beach: you are so right - this is something I have tried to explain to others why I use CL
6:06:08
jeosol
I am like the language is a joy to work in. I am only concerned about the concepts I am trying to implement, i have uniform syntax and don't have to worry about a specific, different language to use a given point
6:06:40
jeosol
beach: very true, unfortunately, I still have to do that in the next few months while I discuss with others
6:07:12
beach
I wish you good luck. Perhaps you will find a better way than I have been able to come up with.
6:07:35
jeosol
reading large-scale C++ software design, the author mention a project that was taking the order of weeks to build - large software indeed, but with our incremental development, we get our changes integrated right there
6:08:11
jeosol
beach: I don't think so beach, I have tried the last few weeks and evening compiling some tidbits here and there to show how things are easier in CL
6:08:33
lisp123
jeosol: Although "uniform syntax" sometimes can be a misnomer. Its true the basic syntax of lisp languages are relatively simple, But then, with special forms or certain macros, complexity creeps in
6:09:05
beach
lisp123: But it is nothing like the complexity of the surface syntax of most languages.
6:09:13
jeosol
I haven't even talked about macros with them because I use that to generate a lot of functions at compile-time so I don't have to code them by hand - a lot of my functions are generated this way (still have to estimate the amout, not sure how to do that)
6:10:35
jeosol
lisp123: good point, I was simplifying things by "uniform syntax". What I mean is that there are way fewer language syntax things I have to worry about - but it kind of goes to the fighting with the language do what you want, or just focus on the concepts you want to implement
6:11:07
lisp123
Honestly, one of the issues for me initially was 'how can lisp be so simple and yet do what I want it to' -> especially with english-named variables and functions, it feels like reading pseudocode at times, but it actually works and works well
6:12:17
lisp123
jeosol: Yep agree. Just wanted to point it out since its worth mentioning to non-lispers that there is some syntax down the track that requires memorisation (but its more to do with having forms in certain places vs. punctuation etc)
6:12:55
jeosol
I work with optimization, and at the time (grad school) working with matlab (memory and speed issues) and C++ (moved because of speed), I saw a CL implementat of genetic algorithm - wow, it was so succint, the guy had my whole C++ header files and CPP files in a few pages of his theses
6:13:18
jeosol
I was sold, because of time, I used C++ to finish, but started looking into to CL then.
6:13:58
lisp123
jeosol: I still feel a bit uncomfortable reading what appears to be very simple code and it works. It feels like its _meant_ to be more complicated. Hopefully that misperception finally goes to rest as I use Lisp more and more.
6:15:17
jeosol
beach: the finding better way is what I am trying to do - I don't have same background/expertise with CL but gotten more CL related books to read over the years.
6:15:37
jeosol
hayley: The problem is people don't like to use it or complain, it's an old language etc
6:15:44
beach
lisp123: Paul Wilson describes Lisp as having a 2-level syntax. One is the syntax defined by sequences of characters, and the other is the syntax at the S-expression level.
6:16:12
jeosol
In a previous shop mostly using python, I got complaints for using CL ( for personal tasks) and for even using emacs editor when most people used vscode
6:16:32
lisp123
hayley: Work wise it can be off putting to others who don't use Lisp, so I need to bite my lip sometimes. Also I'm demotivated on some of their projects, if they are using python or something else, I don't feel the desire to improve their code (why not just do it in Lisp)
6:17:57
jeosol
well it was an ML/AI shop, so the use of python is sort of needed. But some of the older symbolic logic AI code, were CL (using SBCL and lispworks) but no one except a programmer from the 80s and myself knew lisp.
6:20:00
jeosol
some good points on the thread regarding CL vs other languages. I know PG has this whole CL superiority thing, and once told me (when I was starting) to use clojure instead, that it's a modern lisp, but after I mentioned I need/was using CLOS, he then conceded that I should stick with CL
6:20:17
lisp123
jeosol: Yeah, my biggest gripe is when people say why are using Emacs over VSCode. Of all editors, VSCode might be the worst. I rather use notepad at this point (at least I assume there is no telemetry there)
6:21:02
jeosol
like beach, having language fights is not something I am interested in, but I have often needed to explain why CL was chosen for a project ...
6:22:11
jeosol
my OS and tools are: Linux (OS), Emacs + Slime + Paredit. I know there is sly and other emacs variant that my improve my workflow, but I just stuck with these
6:26:02
jeosol
beach: is the Paul Winston comment from his and Horn's book or paper . It is ok, if you don't remember
6:27:48
jeosol
beach: is this the Hudak and Jones paper you referred to above: https://www.cs.yale.edu/publications/techreports/tr1049.pdf
6:29:37
hayley
"For those who object to this use of functional languages, we suggest reading the rest of this paper as if it were about a video game."
6:32:21
beach
I spent a year with Paul Wilson and his research group at the University of Texas at Austin. I am not sure whether he published anything about the 2-level syntax. He may just have told me.
6:32:40
jeosol
beach: Apologies, I mixed up the names and went to pick up the Winston book from the shell
6:34:20
jeosol
beach: I will be interested in a collection of relevant references like the Hudak ones, references that talk about building programs, nontrivial ones in CL. I know this task is not specific, but I am just trying to study these more
6:39:40
jeosol
beach: skimmed the Hudak and Jones paper - very interesting. Thanks for suggesting this
7:42:25
beach
UT Austin is also where J Moore (ACL2) and Gordon Novak (AKCL) work. And it was where Dijkstra had a chair position while I was there.