libera/#commonlisp - IRC Chatlog
Search
17:32:02
dsx
<dbotton> smart people in time will always use Lisp | Don't know if I'm smart, but so far prototyping with CL is a lot of pain. N 50% solutions, half of which don't work anymore because remote APIs changed 5 years ago.
17:33:05
dsx
With a-bit-more-than-basic building blocks missing, doing anything with any service means diy all the way.
17:36:18
jackdaniel
imo this is overly harsh, cl has plenty of useful libraries; not all imaginable libraries, but still more than "too little to build anything serious"
17:36:32
louis77
CL is not used that much to make sure there are up 2 date libraries for every remote system
17:37:00
jackdaniel
implementing "aws anything" is just a matter of plugging existing api - it would be bad had cl not have way to access the internet or speak http and such
17:37:41
jackdaniel
but if your idea of building "production systems" is stitching existing libraries and not writing code along the way then sure
17:37:44
dsx
CL has plenty of wonderful things, which make DIY easier. The problem though is that I don't want to make another 50% solution to work with s3.
17:38:25
NotThatRPG
I found myself wishing that CL had good support for OpenAPI as a way to get CL applications to better interoperate (and for callers not to have to know they were talking to CL)
17:38:53
dsx
jackdaniel: on the surface, yes, it is just another rest. But the devil is in details. There is a lot more, that just talking to REST that needs to happen before and after the request.
17:40:42
dsx
My idea of — quoting dbotton — prototyping, startups, etc is exactly gluing existing libraries together to get something working in a couple days, and then see which parts have to be optimized
17:42:48
jackdaniel
ACTION shrugs; I'd still not equalte a missing library for a particular api to "diy all the way"
17:47:53
dsx
beach: it's a first programming language that makes sense to me. BTW, language is fine. It really is. It's ecosystem's problem.
18:00:01
dsx
NotThatRPG: I've been looking at that, CFFI and Co, but I don't know enough CL yet to be effective. How well does this approach work in your experience?
18:03:49
louis77
well you could ask in the discord channel if someone has written a library you need and maybe just didn't publish it
18:04:20
NotThatRPG
dsx: It works well for cases where the integration with python is pretty "chunky" -- the computation mostly stays on one side or another. Most recently I used cl4py to make an OpenAPI server for a CL program. Generated the OpenAPI code using openapi-generator for Python, then had cl4py invoke the CL program that actually did the computations.
18:04:44
louis77
but yes, CL has many very good library for general use cases but not for special use cases, like one of these new graph databases popping up every month
18:04:47
NotThatRPG
I would not use ABCL except for scripting a java application. As a CL implementation it is incredibly slow.
18:05:41
louis77
btw. found a startup claiming to build a product, add the buzzword "graph" to it and collect VC money
18:05:53
NotThatRPG
No experience with Clojure -- tried a long time ago, but the amount of Java infrastructure I needed to wade through fended me off. If you know Java already, though, something like Clojure or Scala might hit your sweet spot
18:15:35
NotThatRPG
If you *don't* know the java ecosystem intimately, I don't think Clojure is a win -- the learning overhead is huge, and you really need to know the ecosystem to get any payoff. IMO Python is a much more welcoming environment. You can ease into it in a way that's simply impossible for Java
18:18:07
dsx
I don't share this experience. I don't know Java, but it took me about an hour to write a basic web todo app in clojure.
18:19:01
dsx
That's one of the reasons I got to CL in a first place. I was and still am curious about the place it came from.
19:06:31
pjb
dsx: well using clojure would let you use some java library for s3. You can do the same with abcl. You're not forced to use cl libraries. You can use foreign libraries.
19:18:12
louis77
with the free personal edition unfortunately you run out of heap space fast as soon as you load some dependencies via quicklisp
20:06:48
NotThatRPG
dsx: I'm interested to hear that. The last time I tried (which was a while ago, it's true) there was all this guff about installing and configuring Maven and after fighting with that for a while, I gave up, since I didn't know what it was, nor did I want to learn.
22:35:30
NotThatRPG
Here's an obscure question: inside an :around method, can I wrap a thunk around (call-next-method) and return that thunk? I'm not sure if it's not allowed (because it's lexically-scoped) or is allowed (because it's infinite extent)?
22:41:52
pjb
But I may be wrong, since clhs call-next-method says: "The function call-next-method has lexical scope and indefinite extent and can only be used within the body of a method defined by a method-defining form."
0:34:28
phoe
pjb: would https://gist.github.com/phoe/a049bbab5ac14fb5b5e70715b19b2942 be nonconforming then?
2:49:22
NotThatRPG
phoe: I think that's conforming -- call-next-method is only invoked inside around methods. I was asking if I could "smuggle it out" by return a closure that invoked it. I don't *think* that's legit, but I would have to chase a whole lot of pointers around inside the CLHS to figure out....
3:02:04
Bike
i think that is legit. it has indefinite extent, after all. that last clause confuses things though.
4:13:16
taichi
I am probably doing this wrong, but is there an easy way to locally declare `sb-cover:store-coverage-data' over an asdf:load-system. It seems the information gets dropped somewhere along the way
4:21:57
mariari
nevermind it seems declaim dynamically scopes it correctly, I let the warning by SBCL mislead me