Optimization.jl VS clasp

Interesting response. I develop the Julia SciML organization https://sciml.ai/ and we'd be more than happy to work with you to get wrappers for PRIMA into Optimization.jl's general interface (https://docs.sciml.ai/Optimization/stable/). Please get in touch and we can figure out how to set this all up. I personally would be curious to try this out and do some benchmarks against nlopt methods.

There are also Optimization and Nonconvex , which seem like umbrella packages and I am not sure what methods to use inside these packages. Any help on these?

> but would you say most packages follow or enforce SemVer?

The package ecosystem pretty much requires SemVer. If you just say `PackageX = "1"` inside of a Project.toml [compat], then it will assume SemVer, i.e. any version 1.x is non-breaking an thus allowed, but not version 2. Some (but very few) packages do `PackageX = ">=1"`, so you could say Julia doesn't force SemVar (because a package can say that it explicitly believes it's compatible with all future versions), but of course that's nonsense and there will always be some bad actors around. So then:

> Would enforcing a stricter dependency graph fix some of the foot guns of using packages or would that limit composability of packages too much?

That's not the issue. As above, the dependency graphs are very strict. The issue is always at the periphery (for any package ecosystem really). In Julia, one thing that can amplify it is the fact that Requires.jl, the hacky conditional dependency system that is very not recommended for many reasons, cannot specify version requirements on conditional dependencies. I find this to be the root cause of most issues in the "flow" of the package development ecosystem. Most packages are okay, but then oh, I don't want to depend on CUDA for this feature, so a little bit of Requires.jl here, and oh let me do a small hack for OffSetArrays. And now these little hacky features on the edge are both less tested and not well versioned.

Thankfully there's a better way to do it by using multi-package repositories with subpackages. For example, https://github.com/SciML/GalacticOptim.jl is a global interface for lots of different optimization libraries, and you can see all of the different subpackages here https://github.com/SciML/GalacticOptim.jl/tree/master/lib. This lets there be a GalacticOptim and then a GalacticBBO package, each with versioning, but with tests being different while allowing easy co-development of the parts. Very few packages in the Julia ecosystem actually use this (I only know of one other package in Julia making use of this) because the tooling only recently was able to support it, but this is how a lot of packages should be going.

The upside too is that Requires.jl optional dependency handling is by far and away the main source of loading time issues in Julia (because it blocks precompilation in many ways). So it's really killing two birds with one stone: decreasing package load times by about 99% (that's not even a joke, it's the huge majority of the time for most packages which are not StaticArrays.jl) while making version dependencies stricter. And now you know what I'm doing this week and what the next blog post will be on haha.

I accidentally a Common Lisp that interoperates with C++ (https://github.com/clasp-developers/clasp.git). We would also like to move beyond BDWGC and Whiffle looks interesting. I will reach out to you and maybe we can chat about it.

Clasp might be such a language, it seems.

https://github.com/clasp-developers/clasp

/u/jeaye are you aware of CLASP? https://github.com/clasp-developers/clasp https://www.youtube.com/watch?v=mbdXeRBbgDM

Sounds to me like CLASP; it automatically exports C++ objects to be used from Common Lisp also via llvm.

Now, the difference of compiling speed of SBCL and CCL is not so big. Look at cl-benchmark, LispWorks is really fast, CCL is on par with Allegro, SBCL is close to CCL. Or https://github.com/clasp-developers/clasp/wiki/Relative-Compile-Performance-of-clasp, it depends on specific project (SBCL sometimes faster, slower, alike), overall difference is not big.

So..

"Why do you want to make Lisp more popular? If you were sucessful, what would be different in the world, and why is that desirable to you?"

Normally at this point I'd listen to the response, and ask more questions based on that. That would wind up with a very, very deep thread, so I'll break a cardinal rule and pre-guess at some answers.

This kind of question comes up pretty frequently. In many cases, I suspect the motivation behind the question is "Wow! Here's this cool tool I've discovered. I want to make something really useful with it. I want to do it as part of a community effort; share my excitement with others, share in their excitement, and know that what I'm making is useful because others find it desirable and are excited by it." The field could be cooking, sports, old machine tools, tiny homes, or demo scene. Its the fundemental driver for most content on HN, YouTube, Instructables, and such. It is a Good Thing.

If that is your motivator, then my suggestion is to find something that bugs you and fix it. You've already decided you're only interested in code, not other aspects. You said you preferred vim, but the emacs ecosystem has a very rich set of sharp edges that need filing off, and a rich set of tools with which to attack them.

One example: even after 50 years there's no open IDE which allows you to easily globally rename a Lisp identifier. I don't know about LispWorks or other proprietary environments, but you can't in emacs or vim do a right-click on "foo" in "(defun foo ()...)" and select a command which automatically renames it in all invocations. [Queue lots of "but you can..." replies here.] I don't think vim is up to the task of doing this internally. It would be possible in emacs; but would require a huge effort with lots of help from other people. If you emerged alive from that rabbit warren you'd join the company of Certified "How Hard Could it Be?" Mad Scientists such as Dr. "I just want to draw molecules" Meister [1] and "Wouldn't an OS in Lisp be Cool" Froggey [2].

[1] https://github.com/clasp-developers/clasp

[2] Mezzano https://github.com/froggey/Mezzano

But also, there's a reason why most implementations readily make an effort to provide interoperability tools with a variety of runtimes. Clasp much like ABCL gives access to a whole library of other libraries trivially wrapped to interoperate with at little to no performance to cost (depending on how thin you make the wrappers, mainly).