# Does the Julia community suffer from the “Lisp curse” (whatever it means)?

**URL:** <https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852>\
**Category:** Community\
**Created:** [August 16, 2023, 5:10am UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852 "2023-08-16T05:10:52Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Tarny\_GG\_Channie](https://avatars.discourse-cdn.com/v4/letter/t/3bc359/32.png) [@Tarny\_GG\_Channie](https://discourse.julialang.org/u/Tarny_GG_Channie)\
**Post date:** [August 16, 2023, 5:10am UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/1 "2023-08-16T05:10:52Z")

</div>

The Lisp curse is that the more expressive, powerful Lisp language doesn’t really get popular like the less expressive ones, maybe because of the lack of standardization, maybe because it’s easier to mess up? Maybe because it’s harder to document? We don’t know the validity of the Lisp curse nor the true cause, so it’s just a guess. Does it apply to Julia?

For:

- Julia is really expressive.
- Some complain about the correctness and documentation issues, maybe because Julia multiple dispatch, a more powerful paradigm, is also harder to document/test.
- Julia ecosystem is composed of smaller independent libraries rather than a few big libraries. This means some libraries may be maintained by a few or even a single dev and can no longer be maintained once the dev is gone. The documentation may also be less complete because the developer team see things from fewer perspectives. Each library also imposes its own standard which can be different from each other.

Against:

- Julia culture often induce challenge which means things don’t get “too easy”. The Greedy Julians don’t want to do something for less, they want to do more for the same. For example, they want to do source-to-source AD, inducing lots of difficulties. Maybe they want to optimize something to a ridiculous level. These can add difficulty, sometimes artificially, but it does make the library feel like something worth sharing.
- Julia makes good generics which make library easier to make and use.

What do you think? The way I see is that I want expressive languages like Julia to truly succeed. So, if there is a problem, we need to know.

---

<div class="post-metadata">

**Author:** ![algunion](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/algunion/32/51630_2.png) [@algunion](https://discourse.julialang.org/u/algunion)\
**Post date:** [August 16, 2023, 8:57am UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/2 "2023-08-16T08:57:29Z")

</div>

I usually find myself _cursing_ (well, I do not curse - but it sounds good in the context of _List curse_) at either myself or the language when failing to write enough tests.

I think that aggressively imposing a test writing discipline would do a lot of good to the future of the ecosystem (and also avoid the _Lisp curse_ - whatever it means).

---

<div class="post-metadata">

**Author:** ![frylock](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/frylock/32/50213_2.png) [@frylock](https://discourse.julialang.org/u/frylock)\
**Post date:** [August 16, 2023, 12:53pm UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/3 "2023-08-16T12:53:37Z")

</div>

For the uninitiate, [the essay](http://www.winestockwebdesign.com/Essays/Lisp_Curse.html). It would be more funny if it were less true. Usually summarized as:

> Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp.

Good programmers in a language find most concepts elsewhere easy to re-implement in their language of choice. When it is easy enough, nobody bothers to package or document it. It could be that the task was that easy, or because it is a pain to package and document it. Then you get a profusion of mediocre blobs of code that sort of fit the bill, but are buggy and undocumented - because the author doesn’t really care about it, or doesn’t have time anymore.

All languages suffer from this to some extent - it is not a “yes, cursed” or “no, not cursed” answer. Sure, Julia is very powerful, and it may be true that there are many disposable implementations of things floating around, but it seems like the curators of the language have really gone out of their way to make code easy to package and document.

I’d say, the curse taking root largely depends on the groups of people involved, and the vagaries of fate more so than the expressiveness of a language.

---

<div class="post-metadata">

**Author:** ![Zarko](https://avatars.discourse-cdn.com/v4/letter/z/258eb7/32.png) [@Zarko](https://discourse.julialang.org/u/Zarko)\
**Post date:** [October 12, 2023, 3:56pm UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/4 "2023-10-12T15:56:53Z")

</div>

This post was temporarily hidden by the community for possibly being off-topic, unfocused, inappropriate, or spammy.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [October 27, 2023, 10:17am UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/5 "2023-10-27T10:17:31Z")

</div>

When people talk about Lisp being powerful, they usually mean _expressive power_: using macros, one can write really compact code, and build up friendly surface syntax for whatever extension they desire.

Given this outstanding expressive power, it is puzzling why Lisp is not so widespread. The “Lisp curse” mentioned above is a theory based on social factors. But seasoned programmers (including Lispers) know that having great expressive power in a language does not mean that solutions are _composable_ and/or _performant_. Yes, it is easy to write an OOP extension to scheme, but it will not compete with optimized C++, and not necessarily compose with some orthogonal extension someone else wrote.

The innovation of Julia is that it allows one to write composable, performant, expressive code, based on its type system and compilation model (new ingredient), multimethods, and macros.

Incidentally, there are three additional lesser known Lisp curses.

1. Arguing about obscure points of the [CLHS](https://www.cliki.net/CLHS): there are necessarily corner cases that were not covered in detail, so is something a bug, or not? This resulted in a lot of acerbic 200-response mega-threads on Usenet.

2. Having a standard, instead of a single reference implementation. It has some advantages, but at this point it is very unlikely that incremental improvements ever end up in a new standard, so Common Lisp proper is frozen 1994 forever.

3. Attracting people who think it is some form of super-powerful ancient magic that will solve otherwise intractable problems, make P = NP, model the brain, etc. Nope, it is just a programming language.

Julia seems to be immune to all of these at the moment.

---

<div class="post-metadata">

**Author:** ![johnh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnh/32/3615_2.png) [@johnh](https://discourse.julialang.org/u/johnh)\
**Post date:** [October 27, 2023, 10:48am UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/6 "2023-10-27T10:48:57Z")

</div>

> [@Tarny\_GG\_Channie](#):
>
> Maybe they want to optimize something to a ridiculous level.

In the past I have said “Good enough for Jazz” here. Which means that you get something good enough for the analysis/simulation you need to run.  
However I will now make a more apt reply to your point. There is a lot of discussion on this forum regarding optimization becasue there are many use cases being presented and discussed for Julia.  
For instance yesterday I think there was a request about web applications, with a detailed discussion of cores and threads being used.  
Then look at the long running discussion on small executables.

My point being that the replies to a wide range of requests for use cases will inevitably involve dives into optimization.

Maybe you are right though - the reply could be “use this library or package - it is good enough for jazz”

---

<div class="post-metadata">

**Author:** ![tbeason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tbeason/32/15898_2.png) [@tbeason](https://discourse.julialang.org/u/tbeason)\
**Post date:** [October 27, 2023, 12:59pm UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/7 "2023-10-27T12:59:37Z")

</div>

> [@Tamas\_Papp](#):
>
> …there are necessarily corner cases that were not covered in detail, so is something a bug, or not? This resulted in a lot of acerbic 200-response mega-threads on Usenet…
> 
> Julia seems to be immune to all of these at the moment.

Well, not all of them, it would seem. 😉

---

<div class="post-metadata">

**Author:** ![ParadaCarleton](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/paradacarleton/32/20005_2.png) [@ParadaCarleton](https://discourse.julialang.org/u/ParadaCarleton)\
**Post date:** [October 27, 2023, 9:43pm UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/8 "2023-10-27T21:43:28Z")

</div>

> [@Tamas\_Papp](#):
>
> But seasoned programmers (including Lispers) know that having great expressive power in a language does not mean that solutions are _composable_ and/or _performant_. Yes, it is easy to write an OOP extension to scheme, but it will not compete with optimized C++, and not necessarily compose with some orthogonal extension someone else wrote.

I don’t think the essay mentions performance, although you could include that. The problem with Lisp libraries for new language features was that they tended to be hacked-together, poorly-documented, bug-ridden, and incomplete, so most Lisp implementations of critical features just never caught on. There were just never polished, professional, packages for OOP in Scheme, the way there were in Java or C++.

One good overview of the situation explained:

> I predict that while there will arise packages that try to address some of these issues, they will be in disagreement about what to do, they will be niche, without good core language support, and therefore not really solve the problem.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [October 28, 2023, 3:33am UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/9 "2023-10-28T03:33:00Z")

</div>

Yes, I think we do. We really love multiple dispatch, but invalidations are making Julia difficult to use due to compilation and recompilation. My sense is that we should be more judicious about how we use multiple dispatch and perhaps separate the multiple dispatch out into dedicated packages.

For example, currently we have mostly types declared in `StaticArraysCore.jl` and we have overloaded methods in `StaticArrays.jl`.

StaticArraysCore.jl is not very useful by itself. All the useful methods are in StaticArrays.jl. What if we implemented package scoped versions of methods such as `StaticArraysCore.length`.

```julia
module StaticArraysCore
    # ...
    length(a::StaticArrayLike) = prod(Size(a))::Int
    # ...
end
module StaticArrays
    # ...
    @inline Base.length(a::StaticArrayLike) = StaticArraysCore.length(a)
    # ...
end

```

With this, I could use methods in StaticArraysCore.jl specifically for StaticArrays without worrying about invalidating methods and causing recompilation elsewhere. I can still access the `StaticArraysCore.length` implementation without overloading `Base.length`.

The main reason I can think of for why we don’t do this, is because `StaticArraysCore.length` is not very useful since all the rest of our APIs are heavily dependent on multiple dispatch. However, it would allow someone to implement methods for StaticArrays without relying on multiple dispatch.

The overall problem is that features such multiple dispatch introduce complexity. Some simplicity in Julia would go a long way.

---

<div class="post-metadata">

**Author:** ![jishnub](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jishnub/32/33620_2.png) [@jishnub](https://discourse.julialang.org/u/jishnub)\
**Post date:** [October 28, 2023, 12:56pm UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/10 "2023-10-28T12:56:48Z")

</div>

This may be a naive question, but isn’t this an example of single dispatch? My impression was that multiple dispatch necessarily involves two or more objects: self, and others. Is the point more about dynamic dispatch in general?

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 28, 2023, 2:59pm UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/11 "2023-10-28T14:59:57Z")

</div>

> [@mkitti](#):
>
> I think we do. We really love multiple dispatch, but invalidations are making Julia difficult to use due to compilation and recompilation.

I’m not sure, are you answering yes we do to the question do we “suffer from Lisp curse”? Which I think is about code correctness (or too many implementations).

The “and recompilation part” I don’t understand. If you precompile your code, then it should be enough (assuming it’s all compiled, or you’re not calling with alternative types, since code is generic by default). I don’t clearly see a need for even recomiling, just more compiling, if for a type not already precompiled. I know of the concept of “invalidations”, which is maybe what you had in mind, but it’s also confusing for me. It seems you could compile and reuse already precompiled code. Does this only happen because of inlining (that could be turned off, across packages)? I mean it might be an opt-in option to ask for aggressive inling, we currently do. We don’t have that third possibility yet, only inlining on or off, but not a middle ground; [Python C code packages are just compiled and never recompiled, based on how used…?! So it seems we could also do without.]

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [October 28, 2023, 3:11pm UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/12 "2023-10-28T15:11:47Z")

</div>

> [@jishnub](#):
>
> This may be a naive question, but isn’t this an example of single dispatch? My impression was that multiple dispatch necessarily involves two or more objects: self, and others. Is the point more about dynamic dispatch in general?

Sorry, perhaps that was bad example.

Yes. The point is that we have dynamic dispatch and that we have a tendency to overload `Base` methods directly. Rather I think we should consider trying to program as if we did not have any dispatch, and then integrate the dispatch via method forwarding only.

> [@Palli](#):
>
> I’m not sure, are you answering yes we do to the question do we “suffer from Lisp curse”? Which I think is about code correctness (or too many implementations).

I believe this is the general statement of the Lisp curse:

> **Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp.**

If we use methods where concrete types cannot be fully inferred and that are commonly overloaded, we risk our compiled code cache being invalidated forcing recompilation. Julia has the superpower of multiple dispatch, but perhaps we are abusing it.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 28, 2023, 3:46pm UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/13 "2023-10-28T15:46:48Z")

</div>

Not “fully inferred” (you mean not type stable?); then invalidated “forcing recompilation”. I meant it’s forcing _now_, but is it in principle forcing, or could recompilation be avoided? So it’s a technical issue, just not yet implemented to avoid recompilation. Also besides, I’m not sure it’s a “social issue”, recompilation just works? Maybe people complain a bit, so social in that sense.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [October 28, 2023, 3:50pm UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/14 "2023-10-28T15:50:09Z")

</div>

It really should not take 30 seconds to load package with precompilation, and yet we see instances such as this:

> [@How to help reduce package load latency?](https://discourse.julialang.org/t/how-to-help-reduce-package-load-latency/105294):
>
> In an effort to reduce package load latency for a slow loading package,I successfully added some precompilation (via @compile\_workload) and it had the desired effect. However, some dependencies are very slow as well, and I would like to learn how to help with that. The output of @time\_imports using ParameterEstimation includes the following 12852.5 ms Polymake 24.84% compilation time (89% recompilation) 5354.2 ms GAP 17.17% compilation time (83% recompilation) 5574.2 ms Hecke 41.18…

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 28, 2023, 4:15pm UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/15 "2023-10-28T16:15:32Z")

</div>

It’s an avoidable problem (currently, i.e. then a social problem, yes, in some sense, but I did not have latency in mind for it, but you have to do something, rather than “just wait”).

Is it fully precompiled? It seems to me it’s not and worked on (why not is another story, that Julia doesn’t fully precompile by default). If you use that package in an app and you compile it with PackageCompiler.jl, will it work faster? I think not, but not sure, i.e. will it eliminate recompilation?

I was curious to look into it, if anything can be done, but after the very long download, and very long precompile, it failed, and now always fails quickly with:

```julia
julia> @time using ParameterEstimation
[Info: Precompiling ParameterEstimation [b4cd1eb8-1e24-11e8-3319-93036a3eb9f3]
WARNING: Method definition isapprox(IntervalSets.AbstractInterval{T} where T, IntervalSets.AbstractInterval{T} where T) in module IntervalSets at /home/pharaldsson/.julia/packages/IntervalSets/viB6k/src/IntervalSets.jl:144 overwritten in module DomainSets at /home/pharaldsson/.julia/packages/DomainSets/aafhp/src/domains/interval.jl:52.
  **incremental compilation may be fatally broken for this module**

WARNING: Method definition isapprox(IntervalSets.AbstractInterval{T} where T, IntervalSets.AbstractInterval{T} where T) in module IntervalSets at /home/pharaldsson/.julia/packages/IntervalSets/viB6k/src/IntervalSets.jl:144 overwritten in module DomainSets at /home/pharaldsson/.julia/packages/DomainSets/aafhp/src/domains/interval.jl:52.
  **incremental compilation may be fatally broken for this module**

ERROR: LoadError: UndefVarError: `preprocess_ode` not defined

```

Then in Julia 2.0, nobody can claim Julia is unsafe or its standard libraries, and all Julia 2.0 code will work also in 1.x.

---

<div class="post-metadata">

**Author:** ![jishnub](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jishnub/32/33620_2.png) [@jishnub](https://discourse.julialang.org/u/jishnub)\
**Post date:** [October 28, 2023, 5:08pm UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/16 "2023-10-28T17:08:18Z")

</div>

Could you file an issue with DomainSets? This should be resolved

---

<div class="post-metadata">

**Author:** ![ParadaCarleton](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/paradacarleton/32/20005_2.png) [@ParadaCarleton](https://discourse.julialang.org/u/ParadaCarleton)\
**Post date:** [October 28, 2023, 6:34pm UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/17 "2023-10-28T18:34:20Z")

</div>

> [@mkitti](#):
>
> It really should not take 30 seconds to load package with precompilation, and yet we see instances such as this:

This seems like a real problem, but also unrelated to the original Lisp curse, which is about how Lisp’s expressiveness creates social problems by attracting the kinds of people who can’t work well with others.

Lisp doesn’t suffer from particularly long compile times because it’s typically not JIT compiled; Julia’s decision to JIT compile into LLVM (an infamously slow compiler) is unrelated to how dynamic it is.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 28, 2023, 7:05pm UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/18 "2023-10-28T19:05:05Z")

</div>

> [@ParadaCarleton](#):
>
> unrelated to the original Lisp curse

Right, but also not about JIT. Lisp is fast because interpreted, or if compiled, not as aggressively as Julia. LLVM is slow, but needs not be. You can choose optimization level, and inlining is the problem. If you never would then it’s not bad to compile each function separately. Julia allows that, and someone else could try with that package, running with -O0, -O1, and/or --inline=off, what I was going to do:

I filed an issue, and I can’t performance tune this or try, until I figure out getting it to install/run at all:

> <https://github.com/JuliaApproximation/DomainSets.jl/issues/144>
>
> Likely because of:
> ⌅ \[5b8099bc\] DomainSets v0.5.14
> 
> A.
> It was suggested I re…port this here (not at ParameterEstimation; misinformed, report there \[too\]?):
> 
> \`\`\`
> julia\> @time using ParameterEstimation
> \[Info: Precompiling ParameterEstimation \[b4cd1eb8-1e24-11e8-3319-93036a3eb9f3\]
> WARNING: Method definition isapprox(IntervalSets.AbstractInterval{T} where T, IntervalSets.AbstractInterval{T} where T) in module IntervalSets at /home/pharaldsson/.julia/packages/IntervalSets/viB6k/src/IntervalSets.jl:144 overwritten in module DomainSets at /home/pharaldsson/.julia/packages/DomainSets/aafhp/src/domains/interval.jl:52.
> \*\* incremental compilation may be fatally broken for this module \*\*
> 
> WARNING: Method definition isapprox(IntervalSets.AbstractInterval{T} where T, IntervalSets.AbstractInterval{T} where T) in module IntervalSets at /home/pharaldsson/.julia/packages/IntervalSets/viB6k/src/IntervalSets.jl:144 overwritten in module DomainSets at /home/pharaldsson/.julia/packages/DomainSets/aafhp/src/domains/interval.jl:52.
> \*\* incremental compilation may be fatally broken for this module \*\*
> 
> ERROR: LoadError: UndefVarError: \`preprocess\_ode\` not defined
> Stacktrace:
> \[1\] include
> @ ./Base.jl:457 \[inlined\]
> \[2\] include\_package\_for\_output(pkg::Base.PkgId, input::String, depot\_path::Vector{String}, dl\_load\_path::Vector{String}, load\_path::Vector{String}, concrete\_deps::Vector{Pair{Base.PkgId, UInt128}}, source::String)
> @ Base ./loading.jl:2049
> \[3\] top-level scope
> @ stdin:3
> in expression starting at /home/pharaldsson/.julia/packages/SIAN/2YI9H/src/SIAN.jl:1
> in expression starting at stdin:3
> ERROR: LoadError: Failed to precompile SIAN \[cf7bdac0-b945-4905-b5ad-bc3f1a757483\] to "/home/pharaldsson/.julia/compiled/v1.9/SIAN/jl\_2dtjI3".
> Stacktrace:
> \[1\] error(s::String)
> @ Base ./error.jl:35
> \[2\] compilecache(pkg::Base.PkgId, path::String, internal\_stderr::IO, internal\_stdout::IO, keep\_loaded\_modules::Bool)
> @ Base ./loading.jl:2300
> \[3\] compilecache
> @ ./loading.jl:2167 \[inlined\]
> \[4\] \_require(pkg::Base.PkgId, env::String)
> @ Base ./loading.jl:1805
> \[5\] \_require\_prelocked(uuidkey::Base.PkgId, env::String)
> @ Base ./loading.jl:1660
> \[6\] macro expansion
> @ ./loading.jl:1648 \[inlined\]
> \[7\] macro expansion
> @ ./lock.jl:267 \[inlined\]
> \[8\] require(into::Module, mod::Symbol)
> @ Base ./loading.jl:1611
> \[9\] include
> @ ./Base.jl:457 \[inlined\]
> \[10\] include\_package\_for\_output(pkg::Base.PkgId, input::String, depot\_path::Vector{String}, dl\_load\_path::Vector{String}, load\_path::Vector{String}, concrete\_deps::Vector{Pair{Base.PkgId, UInt128}}, source::Nothing)
> @ Base ./loading.jl:2049
> \[11\] top-level scope
> @ stdin:3
> in expression starting at /home/pharaldsson/.julia/packages/ParameterEstimation/W1ASN/src/ParameterEstimation.jl:1
> in expression starting at stdin:3
> ERROR: Failed to precompile ParameterEstimation \[b4cd1eb8-1e24-11e8-3319-93036a3eb9f3\] to "/home/pharaldsson/.julia/compiled/v1.9/ParameterEstimation/jl\_L9eI6O".
> Stacktrace:
> \[1\] error(s::String)
> @ Base ./error.jl:35
> \[2\] compilecache(pkg::Base.PkgId, path::String, internal\_stderr::IO, internal\_stdout::IO, keep\_loaded\_modules::Bool)
> @ Base ./loading.jl:2300
> \[3\] compilecache
> @ ./loading.jl:2167 \[inlined\]
> \[4\] \_require(pkg::Base.PkgId, env::String)
> @ Base ./loading.jl:1805
> \[5\] \_require\_prelocked(uuidkey::Base.PkgId, env::String)
> @ Base ./loading.jl:1660
> \[6\] macro expansion
> @ ./loading.jl:1648 \[inlined\]
> \[7\] macro expansion
> @ ./lock.jl:267 \[inlined\]
> \[8\] require(into::Module, mod::Symbol)
> @ Base ./loading.jl:1611
> \[9\] top-level scope
> @ ./timing.jl:273 \[inlined\]
> \[10\] top-level scope
> @ ./REPL\[19\]:0
> 
> 
> 
> (@v1.9) pkg\> st -m
> Status \`~/.julia/environments/v1.9/Manifest.toml\`
> ⌅ \[c3fe647b\] AbstractAlgebra v0.26.2
> \[621f4979\] AbstractFFTs v1.5.0
> \[398f06c4\] AbstractLattices v0.2.1
> \[1520ce14\] AbstractTrees v0.4.4
> \[79e6a3ab\] Adapt v3.7.1
> \[27a7e980\] Animations v0.4.1
> ⌅ \[fb37089c\] Arblib v0.6.4
> \[dce04be8\] ArgCheck v2.3.0
> \[c7e460c6\] ArgParse v1.1.4
> \[ec485272\] ArnoldiMethod v0.2.0
> ⌅ \[4fba245c\] ArrayInterface v6.0.25
> \[30b0a656\] ArrayInterfaceCore v0.1.29
> \[6ba088a2\] ArrayInterfaceGPUArrays v0.2.2
> \[015c0d05\] ArrayInterfaceOffsetArrays v0.1.7
> \[b0d46f97\] ArrayInterfaceStaticArrays v0.1.5
> \[dd5226c6\] ArrayInterfaceStaticArraysCore v0.1.4
> ⌃ \[4c555306\] ArrayLayouts v0.8.18
> \[bf4720bc\] AssetRegistry v0.1.0
> ⌅ \[15f4f7f2\] AutoHashEquals v0.2.0
> \[4eb35182\] AutoSysimages v0.2.6
> ⌅ \[67c07d97\] Automa v0.8.4
> \[13072b0f\] AxisAlgorithms v1.0.1
> \[39de3d68\] AxisArrays v0.4.7
> ⌅ \[aae01518\] BandedMatrices v0.17.18
> \[198e06fe\] BangBang v0.3.39
> \[9718e550\] Baselet v0.1.1
> \[6e4b80f9\] BenchmarkTools v1.3.2
> \[e2ed5e7c\] Bijections v0.1.6
> \[f01c122e\] BinaryWrappers v0.1.2
> \[d1d4a3ce\] BitFlags v0.1.7
> \[62783981\] BitTwiddlingConvenienceFunctions v0.1.5
> \[ad839575\] Blink v0.12.8
> ⌅ \[764a87c0\] BoundaryValueDiffEq v2.11.0
> ⌅ \[fa961155\] CEnum v0.4.2
> ⌅ \[2a0fbf3d\] CPUSummary v0.1.30
> \[96374032\] CRlibm v1.0.1
> \[00ebfdb7\] CSTParser v3.3.6
> \[159f3aea\] Cairo v1.0.5
> \[13f3f980\] CairoMakie v0.10.11
> \[49dc2e85\] Calculus v0.5.1
> \[d360d2e6\] ChainRulesCore v1.18.0
> ⌃ \[fb6a15b2\] CloseOpenIntervals v0.1.11
> \[da1fd8a2\] CodeTracking v1.3.5
> \[523fee87\] CodecBzip2 v0.8.1
> \[944b1d66\] CodecZlib v0.7.3
> \[a2cac450\] ColorBrewer v0.4.0
> \[35d6a980\] ColorSchemes v3.24.0
> \[3da002f7\] ColorTypes v0.11.4
> ⌅ \[c3611d14\] ColorVectorSpace v0.9.10
> \[5ae59095\] Colors v0.12.10
> \[861a8166\] Combinatorics v1.0.2
> \[a80b9123\] CommonMark v0.8.12
> \[38540f10\] CommonSolve v0.2.4
> \[bbf7d656\] CommonSubexpressions v0.3.0
> ⌅ \[34da2185\] Compat v3.46.2
> \[b152e2b5\] CompositeTypes v0.1.3
> \[a33af91c\] CompositionsBase v0.1.2
> \[f0e56b4a\] ConcurrentUtilities v2.2.1
> \[8f4d0f93\] Conda v1.9.1
> \[992eb4ea\] CondaPkg v0.2.22
> \[5218b696\] Configurations v0.17.6
> \[187b0558\] ConstructionBase v1.5.4
> \[d38c429a\] Contour v0.6.2
> \[adafc99b\] CpuId v0.3.1
> \[a8cc5b0e\] Crayons v4.1.1
> ⌅ \[1f15a43c\] CxxWrap v0.12.1
> \[a10d1c49\] DBInterface v2.5.0
> \[9a962f9c\] DataAPI v1.15.0
> ⌃ \[a93c6f00\] DataFrames v1.3.6
> \[864edb3b\] DataStructures v0.18.15
> \[e2d170a0\] DataValueInterfaces v1.0.0
> \[abce61dc\] Decimals v0.4.1
> \[ab62b9b5\] DeepDiffs v1.2.0
> \[244e2a9f\] DefineSingletons v0.1.2
> \[927a84f5\] DelaunayTriangulation v0.8.8
> ⌃ \[bcd4f6db\] DelayDiffEq v5.41.1
> \[8bb1440f\] DelimitedFiles v1.9.1
> \[39dd38d3\] Dierckx v0.5.3
> ⌅ \[2b5f629d\] DiffEqBase v6.108.0
> ⌃ \[459566f4\] DiffEqCallbacks v2.26.1
> \[77a26b50\] DiffEqNoiseProcess v5.19.0
> \[1130ab10\] DiffEqParamEstim v2.1.0
> \[163ba53b\] DiffResults v1.1.0
> \[b552c78f\] DiffRules v1.15.1
> ⌃ \[0c46a032\] DifferentialEquations v7.6.0
> \[b4f34e82\] Distances v0.10.10
> \[31c24e10\] Distributions v0.25.102
> ⌅ \[ffbed154\] DocStringExtensions v0.8.6
> ⌅ \[5b8099bc\] DomainSets v0.5.14
> \[4dc1fcf4\] DotEnv v0.3.1
> \[fa6b7ba4\] DualNumbers v0.6.8
> ⌅ \[7c1d4256\] DynamicPolynomials v0.4.6
> \[fdbdab4c\] ElasticArrays v1.2.11
> \[4e289a0a\] EnumX v1.0.4
> \[90fa49ef\] ErrorfreeArithmetic v0.5.2
> \[429591f6\] ExactPredicates v2.2.6
> \[460bff9d\] ExceptionUnwrapping v0.1.9
> ⌃ \[d4d017d3\] ExponentialUtilities v1.23.0
> \[e2ba6199\] ExprTools v0.1.10
> \[55351af7\] ExproniconLite v0.10.4
> \[411431e0\] Extents v0.1.2
> \[8f5d6c58\] EzXML v1.1.0
> \[c87230d0\] FFMPEG v0.4.1
> \[7a1cc6ca\] FFTW v1.7.1
> ⌃ \[7034ab61\] FastBroadcast v0.2.4
> \[9aa1b823\] FastClosures v0.3.2
> \[fa42c844\] FastRounding v0.3.1
> \[5789e2e9\] FileIO v1.16.1
> \[48062228\] FilePathsBase v0.9.21
> ⌅ \[1a297f60\] FillArrays v0.13.11
> ⌃ \[6a86dc24\] FiniteDiff v2.17.0
> \[53c48c17\] FixedPointNumbers v0.8.4
> \[59287772\] Formatting v0.4.2
> \[f6369f11\] ForwardDiff v0.10.36
> \[b38be410\] FreeType v4.1.0
> \[663a7486\] FreeTypeAbstraction v0.10.0
> \[069b7b12\] FunctionWrappers v1.1.3
> \[77dc65aa\] FunctionWrappersWrappers v0.1.3
> \[de31a74c\] FunctionalCollections v0.5.0
> \[fb4132e2\] FuzzyCompletions v0.5.3
> ⌅ \[c863536a\] GAP v0.8.5
> \[f7f18e0c\] GLFW v3.4.1
> \[e9467ef8\] GLMakie v0.8.11
> \[46192b85\] GPUArraysCore v0.1.5
> ⌃ \[28b8d3ca\] GR v0.72.8
> \[c145ed77\] GenericSchur v0.5.3
> \[c43c736e\] Genie v5.19.1
> \[cf35fbd7\] GeoInterface v1.3.2
> \[5c1252a2\] GeometryBasics v0.4.9
> \[c27321d9\] Glob v1.3.1
> \[a2bd30eb\] Graphics v1.1.2
> \[86223c79\] Graphs v1.9.0
> \[3955a311\] GridLayoutBase v0.9.2
> \[42e2da0e\] Grisu v1.0.2
> ⌅ \[0b43b601\] Groebner v0.2.11
> \[d5909c97\] GroupsCore v0.4.0
> \[cd3eb016\] HTTP v1.10.0
> ⌅ \[3e1990a7\] Hecke v0.14.10
> \[9fb69e20\] Hiccup v0.2.2
> ⌃ \[f213a82b\] HomotopyContinuation v2.6.4
> \[3e5b6fbb\] HostCPUFeatures v0.1.16
> \[77172c1b\] HttpCommon v0.5.0
> \[34004b35\] HypergeometricFunctions v0.3.23
> \[ac1192a8\] HypertextLiteral v0.9.4
> \[18364772\] IPython v0.5.1
> \[615f187c\] IfElse v0.1.1
> \[2803e5a7\] ImageAxes v0.6.11
> ⌃ \[c817782e\] ImageBase v0.1.5
> ⌅ \[a09fc81d\] ImageCore v0.9.4
> \[82e4d734\] ImageIO v0.6.7
> \[bc367c6b\] ImageMetadata v0.9.9
> \[9b13fd28\] IndirectArrays v1.0.0
> \[a303e19e\] Infinity v0.2.4
> \[d25df0c9\] Inflate v0.1.4
> \[6d011eab\] Inflector v1.1.0
> \[22cec73e\] InitialValues v0.3.1
> \[842dd82b\] InlineStrings v1.4.0
> \[18e54dd8\] IntegerMathUtils v0.1.2
> \[a98d9a8b\] Interpolations v0.14.7
> \[d1acc4aa\] IntervalArithmetic v0.21.2
> \[8197267c\] IntervalSets v0.7.8
> \[d8418881\] Intervals v1.10.0
> \[41ab1584\] InvertedIndices v1.3.0
> \[92d709cd\] IrrationalConstants v0.2.2
> \[f1662d9f\] Isoband v0.1.1
> \[c8e1da08\] IterTools v1.8.0
> \[42fd0dbc\] IterativeSolvers v0.9.3
> \[82899510\] IteratorInterfaceExtensions v1.0.0
> \[1019f520\] JLFzf v0.1.6
> \[692b3bcd\] JLLWrappers v1.5.0
> \[97c1335a\] JSExpr v0.5.4
> \[682c06a0\] JSON v0.21.4
> \[0f8b85d8\] JSON3 v1.13.2
> \[b835a17e\] JpegTurbo v0.1.4
> \[98e50ef6\] JuliaFormatter v1.0.40
> \[aa1ae85d\] JuliaInterpreter v0.9.26
> \[70703baa\] JuliaSyntax v0.4.6
> ⌃ \[ccbc3e58\] JumpProcesses v9.5.1
> ⌅ \[ef3ab10e\] KLU v0.3.0
> \[5ab0869b\] KernelDensity v0.6.7
> ⌅ \[ba0b0d4f\] Krylov v0.8.4
> ⌅ \[0b1a1467\] KrylovKit v0.5.4
> \[8ac3fa9e\] LRUCache v1.5.0
> \[b964fa9f\] LaTeXStrings v1.3.0
> ⌃ \[2ee39098\] LabelledArrays v1.13.0
> \[984bce1d\] LambertW v0.4.6
> ⌅ \[23fbe1c1\] Latexify v0.15.21
> \[6f188dcb\] LayerDicts v1.0.0
> ⌃ \[10f19ff3\] LayoutPointers v0.1.13
> \[0e77f7df\] LazilyInitializedFields v1.2.1
> \[50d2b5c4\] Lazy v0.15.1
> \[8cdb02fc\] LazyModules v0.3.1
> \[2d8b4e74\] LevyArea v1.0.0
> \[194296ae\] LibPQ v1.17.1
> \[9c8b4983\] LightXML v0.9.0
> \[d3d80556\] LineSearches v7.2.0
> \[9b3f67b0\] LinearAlgebraX v0.1.12
> ⌅ \[7ed4a6bd\] LinearSolve v1.20.0
> \[2ab3a3ac\] LogExpFunctions v0.3.26
> \[e6f89c97\] LoggingExtras v1.0.3
> ⌃ \[bdcacae8\] LoopVectorization v0.12.150
> \[6f1432cf\] LoweredCodeUtils v2.3.0
> \[6c6e2e6c\] MIMEs v0.1.4
> \[1914dd2f\] MacroTools v0.5.11
> \[ee78f7c6\] Makie v0.19.11
> \[20f20a25\] MakieCore v0.6.8
> \[36869731\] Malt v1.1.0
> \[d125e4d3\] ManualMemory v0.1.8
> \[dbb5928d\] MappedArrays v0.4.2
> ⌅ \[7eb4fadd\] Match v1.2.0
> \[b8f27783\] MathOptInterface v1.21.0
> \[0a4f8689\] MathTeXEngine v0.5.6
> \[739be429\] MbedTLS v1.1.7
> \[442fdcdd\] Measures v0.3.2
> \[f28f55f0\] Memento v1.4.1
> \[7269a6da\] MeshIO v0.4.10
> ⌅ \[e9d8d322\] Metatheory v1.3.5
> \[128add7d\] MicroCollections v0.1.4
> \[0b3b1443\] MicroMamba v0.1.14
> \[39ec1447\] Millboard v0.2.5
> \[e1d29d7a\] Missings v1.1.0
> ⌃ \[291d046c\] MixedSubdivisions v1.1.2
> \[78c3b35d\] Mocking v0.7.7
> ⌃ \[961ee093\] ModelingToolkit v8.36.0
> \[66fc600b\] ModernGL v1.1.7
> \[7475f97c\] Mods v1.3.3
> ⌅ \[4fe8b98c\] Mongoc v0.6.2
> \[e94cdb99\] MosaicViews v0.3.4
> \[99f44e22\] MsgPack v1.2.0
> \[46d2c3a1\] MuladdMacro v0.2.4
> \[3b2b4ff1\] Multisets v0.4.4
> ⌅ \[102ac46a\] MultivariatePolynomials v0.4.7
> \[ffc61752\] Mustache v1.0.17
> \[d8a4904e\] MutableArithmetics v1.3.3
> \[a975b10e\] Mux v1.0.1
> \[d41bc354\] NLSolversBase v7.8.3
> \[2774e3e8\] NLsolve v4.5.1
> \[77ba4419\] NaNMath v1.0.2
> \[e1fe445b\] NativeFileDialog v0.2.1
> ⌅ \[2edaba10\] Nemo v0.31.1
> \[f09324ee\] Netpbm v1.1.1
> \[49dea1ee\] Nettle v1.0.0
> \[4d1e1d77\] Nullables v1.0.0
> \[beb21ac1\] ObjectSystem v1.0.0
> \[510215fc\] Observables v0.5.4
> \[6fe1bfb0\] OffsetArrays v1.12.10
> \[5fb14364\] OhMyREPL v0.5.23
> \[52e1d378\] OpenEXR v0.3.2
> \[4d8831e6\] OpenSSL v1.4.1
> \[429524aa\] Optim v1.7.8
> \[bac558e1\] OrderedCollections v1.6.2
> ⌃ \[1dea7af3\] OrdinaryDiffEq v6.33.3
> ⌅ \[f1435218\] Oscar v0.10.0
> \[90014a1f\] PDMats v0.11.28
> \[f57f5aa1\] PNGFiles v0.4.1
> \[9b87118b\] PackageCompiler v2.1.11
> \[19eb6ba3\] Packing v0.5.0
> \[5432bcbf\] PaddedViews v0.5.12
> \[b4cd1eb8\] ParameterEstimation v0.2.1
> \[d96e819e\] Parameters v0.12.3
> \[69de0a69\] Parsers v2.7.2
> \[06bb1623\] PenaltyFunctions v0.3.0
> \[2ae35dd2\] Permutations v0.4.17
> \[fa939f87\] Pidfile v1.3.0
> \[b98c9c47\] Pipe v1.3.0
> \[eebad327\] PkgVersion v0.3.3
> \[ccf2f8ad\] PlotThemes v3.1.0
> \[995b91a9\] PlotUtils v1.3.5
> \[a03496cd\] PlotlyBase v0.8.19
> \[f0f68f2c\] PlotlyJS v0.18.11
> \[91a5bcdd\] Plots v1.39.0
> \[c3e4b0f8\] Pluto v0.19.30
> \[e409e4f3\] PoissonRandom v0.4.4
> ⌅ \[f517fe37\] Polyester v0.6.20
> ⌅ \[1d0040c9\] PolyesterWeave v0.1.13
> \[647866c9\] PolygonOps v0.1.2
> ⌅ \[d720cf60\] Polymake v0.8.0
> \[f27b6e38\] Polynomials v4.0.4
> \[2dfb63ee\] PooledArrays v1.4.3
> \[85a6dd25\] PositiveFactorizations v0.2.4
> ⌃ \[d236fae5\] PreallocationTools v0.4.11
> \[91cefc8d\] PrecompileSignatures v3.0.3
> \[aea7be01\] PrecompileTools v1.2.0
> \[21216c6a\] Preferences v1.4.1
> ⌅ \[08abe8d2\] PrettyTables v1.3.1
> \[27ebfcd6\] Primes v0.5.4
> \[92933f4c\] ProgressMeter v1.9.0
> \[01f381cc\] ProjectiveVectors v1.1.4
> \[438e738f\] PyCall v1.96.1
> \[d330b81b\] PyPlot v2.11.2
> \[b65fc819\] Python v0.0.0 \`https://github.com/LilithHafner/Jokes:Python#main\`
> \[6099a3de\] PythonCall v0.9.15
> \[274fc56d\] PythonPlot v1.0.3
> \[4b34888f\] QOI v1.0.0
> \[1fd47b50\] QuadGK v2.9.1
> \[3fc713dc\] REPLCompletions v0.0.3
> \[74087812\] Random123 v1.6.1
> \[fb686558\] RandomExtensions v0.4.4
> \[e6cf234a\] RandomNumbers v1.5.3
> \[b3c3ace0\] RangeArrays v0.3.2
> \[c84ed2f1\] Ratios v0.4.5
> \[3cdcf5f2\] RecipesBase v1.3.4
> \[01d81517\] RecipesPipeline v0.6.12
> ⌃ \[731186ca\] RecursiveArrayTools v2.32.3
> \[f2c3362d\] RecursiveFactorization v0.2.20
> \[189a3867\] Reexport v1.2.2
> \[42d2dcc6\] Referenceables v0.1.2
> \[2792f1a3\] RegistryInstances v0.1.0
> \[05181044\] RelocatableFolders v1.0.1
> \[ae029012\] Requires v1.3.0
> \[ae5879a3\] ResettableStacks v1.1.1
> \[295af30f\] Revise v3.5.7
> \[286e9d63\] RingLists v0.2.8
> \[79098fc4\] Rmath v0.7.1
> \[5eaf0fd0\] RoundingEmulator v0.2.1
> \[7e49a35a\] RuntimeGeneratedFunctions v0.5.12
> \[cf7bdac0\] SIAN v1.4.1
> \[94e857df\] SIMDTypes v0.1.0
> \[476501e8\] SLEEFPirates v0.6.39
> \[af517c2e\] SQLStrings v0.1.0
> ⌅ \[0bca4576\] SciMLBase v1.81.0
> \[6c6a2e73\] Scratch v1.2.0
> ⌅ \[8e049039\] SemialgebraicSets v0.2.5
> \[3cc68bcd\] SetRounding v0.2.1
> \[efcf1570\] Setfield v1.1.1
> \[65257c39\] ShaderAbstractions v0.4.0
> \[992d4aef\] Showoff v1.0.3
> \[73760f76\] SignedDistanceFields v0.4.0
> \[777ac1f9\] SimpleBufferStream v1.1.0
> \[55797a34\] SimpleGraphs v0.8.4
> ⌃ \[727e6d20\] SimpleNonlinearSolve v0.1.5
> \[ec83eff0\] SimplePartitions v0.3.0
> \[cc47b68c\] SimplePolynomials v0.2.14
> \[a6525b86\] SimpleRandom v0.3.1
> \[699a6c99\] SimpleTraits v0.9.4
> \[ce78b400\] SimpleUnPack v1.1.0
> ⌅ \[bcd08a7b\] Singular v0.10.2
> \[45858cf5\] Sixel v0.1.3
> \[66db9d55\] SnoopPrecompile v1.0.3
> \[a2af1166\] SortingAlgorithms v1.2.0
> ⌅ \[47a9eef4\] SparseDiffTools v1.30.0
> \[276daf66\] SpecialFunctions v2.3.1
> \[171d559e\] SplittablesBase v0.1.15
> \[c5dd0088\] StableHashTraits v1.1.0
> \[cae243ae\] StackViews v0.1.1
> \[aedffcd0\] Static v0.8.8
> \[90137ffa\] StaticArrays v1.6.5
> \[1e83bf80\] StaticArraysCore v1.4.2
> \[82ae8749\] StatsAPI v1.7.0
> \[2913bbd2\] StatsBase v0.34.2
> \[4c63d2b9\] StatsFuns v1.3.0
> ⌃ \[9672c7b4\] SteadyStateDiffEq v1.12.0
> ⌃ \[789caeaf\] StochasticDiffEq v6.58.0
> ⌅ \[7792a7ef\] StrideArraysCore v0.4.7
> \[69024149\] StringEncodings v0.3.7
> \[09ab397b\] StructArrays v0.6.16
> \[856f2bd8\] StructTypes v1.10.0
> ⌃ \[220ca800\] StructuralIdentifiability v0.4.5
> ⌃ \[c3572dad\] Sundials v4.15.1
> ⌅ \[d1185830\] SymbolicUtils v0.19.11
> ⌅ \[0c5d862f\] Symbolics v4.14.0
> \[dc5dba14\] TZJData v1.0.0+2023c
> \[3783bdb8\] TableTraits v1.0.1
> \[bd369af6\] Tables v1.11.1
> \[f6209947\] TailRec v0.2.0 \`https://github.com/TakekazuKATO/TailRec.jl#master\`
> ⌅ \[6aa5eb33\] TaylorSeries v0.13.2
> \[62fd8b95\] TensorCore v0.1.1
> ⌅ \[8ea1fca8\] TermInterface v0.2.3
> \[98d24dd4\] TestSetExtensions v2.0.0
> \[b718987f\] TextWrap v1.0.1
> \[8290d209\] ThreadingUtilities v0.5.2
> \[ac1d9e8a\] ThreadsX v0.1.11
> ⌅ \[731e570b\] TiffImages v0.6.8
> \[f269a46b\] TimeZones v1.13.0
> \[a759f4b9\] TimerOutputs v0.5.23
> \[0796e94c\] Tokenize v0.5.25
> ⌅ \[3bb67fe8\] TranscodingStreams v0.9.13
> \[28d57a85\] Transducers v0.4.78
> \[a2a6695c\] TreeViews v0.3.0
> \[d5829a12\] TriangularSolve v0.1.19
> \[410a4b4d\] Tricks v0.1.8
> \[981d1d27\] TriplotBase v0.1.0
> \[9d95972d\] TupleTools v1.4.3
> \[30578b45\] URIParser v0.4.1
> \[5c2747f8\] URIs v1.5.1
> \[0f7cfa37\] UTCDateTimes v1.6.1
> \[3a884ed6\] UnPack v1.0.2
> \[1cfade01\] UnicodeFun v0.4.1
> \[1986cc42\] Unitful v1.17.0
> \[45397f5d\] UnitfulLatexify v1.6.3
> \[e17b2a0c\] UnsafePointers v1.0.0
> \[41fe7b60\] Unzip v0.2.0
> ⌃ \[3d5dd08c\] VectorizationBase v0.21.58
> \[81def892\] VersionParsing v1.3.0
> \[19fa3120\] VertexSafeGraphs v0.2.0
> \[0f1e0344\] WebIO v0.8.21
> \[104b5d7c\] WebSockets v1.6.0
> \[cc8bc4a8\] Widgets v0.6.6
> \[efce3f68\] WoodburyMatrices v0.5.5
> \[ddb6d928\] YAML v0.4.9
> \[700de1a5\] ZygoteRules v0.2.4
> \[7b86fcea\] ATK\_jll v2.38.0+0
> ⌅ \[e21ec000\] Antic\_jll v0.200.501+0
> ⌅ \[d9960996\] Arb\_jll v200.2200.0+0
> \[6e34b625\] Bzip2\_jll v1.0.8+0
> \[4e9b3aee\] CRlibm\_jll v1.0.1+0
> \[83423d85\] Cairo\_jll v1.16.1+1
> ⌅ \[fcfa6d1b\] Calcium\_jll v0.400.102+0
> \[ee1fde0b\] Dbus\_jll v1.12.16+3
> \[cd4c43a9\] Dierckx\_jll v0.1.0+0
> \[5ae413db\] EarCut\_jll v2.2.4+0
> \[2702e6a9\] EpollShim\_jll v0.0.20230411+0
> \[2e619515\] Expat\_jll v2.5.0+0
> ⌃ \[b22a6f82\] FFMPEG\_jll v4.4.2+2
> \[f5851436\] FFTW\_jll v3.3.10+0
> ⌅ \[e134572f\] FLINT\_jll v200.800.500+0
> \[a3f928ae\] Fontconfig\_jll v2.13.93+0
> \[d7e528f0\] FreeType2\_jll v2.13.1+0
> \[559328eb\] FriBidi\_jll v1.0.10+0
> ⌅ \[5cd7a574\] GAP\_jll v400.1192.2+1
> ⌅ \[de1ad85e\] GAP\_lib\_jll v400.1192.2+0
> ⌅ \[ba154793\] GAP\_pkg\_juliainterface\_jll v0.800.0+0
> \[0656b61e\] GLFW\_jll v3.3.8+0
> \[e8aa6df9\] GLPK\_jll v5.0.1+0
> ⌅ \[d2c73de3\] GR\_jll v0.72.8+0
> \[77ec8976\] GTK3\_jll v3.24.31+0
> \[78b55507\] Gettext\_jll v0.21.0+0
> \[7746bdde\] Glib\_jll v2.76.5+0
> \[3b182d85\] Graphite2\_jll v1.3.14+0
> \[2e76f6c2\] HarfBuzz\_jll v2.8.1+1
> \[905a6f67\] Imath\_jll v3.1.7+0
> \[1d5cc7b8\] IntelOpenMP\_jll v2023.2.0+0
> \[aacddb02\] JpegTurbo\_jll v2.1.91+0
> \[f7e6163d\] Kaleido\_jll v0.2.1+0
> \[b39eb1a6\] Kerberos\_krb5\_jll v1.19.3+0
> \[c1c5ebd0\] LAME\_jll v3.100.1+0
> \[88015f11\] LERC\_jll v3.0.0+1
> \[1d63c593\] LLVMOpenMP\_jll v15.0.4+0
> ⌅ \[a3ccf953\] LLVM\_full\_jll v14.0.6+4
> \[dd4b983a\] LZO\_jll v2.10.1+0
> ⌅ \[08be9ffa\] LibPQ\_jll v14.3.0+1
> \[42c93a91\] Libepoxy\_jll v1.5.10+0
> ⌅ \[e9f186c6\] Libffi\_jll v3.2.2+1
> \[d4300ac3\] Libgcrypt\_jll v1.8.7+0
> \[7e76a0d4\] Libglvnd\_jll v1.6.0+0
> \[7add5ba3\] Libgpg\_error\_jll v1.42.0+0
> \[94ce4f54\] Libiconv\_jll v1.17.0+0
> \[4b2f31a3\] Libmount\_jll v2.35.0+0
> ⌅ \[89763e89\] Libtiff\_jll v4.4.0+0
> \[38a345b3\] Libuuid\_jll v2.36.0+0
> \[856f044c\] MKL\_jll v2023.2.0+0
> \[2ce0c516\] MPC\_jll v1.2.1+0
> \[90100e71\] MongoC\_jll v1.19.1+0
> \[94d9ae2c\] NativeFileDialog\_jll v1.1.6+3
> \[68e3532b\] Ncurses\_jll v6.4.1+0
> \[4c82536e\] Nettle\_jll v3.7.2+0
> \[76642167\] Ninja\_jll v1.11.1+0
> \[e7412a2a\] Ogg\_jll v1.3.5+1
> ⌅ \[656ef2d0\] OpenBLAS32\_jll v0.3.21+0
> \[18a262bb\] OpenEXR\_jll v3.1.4+0
> ⌅ \[458c3c95\] OpenSSL\_jll v1.1.23+0
> \[efe28fd5\] OpenSpecFun\_jll v0.5.5+0
> \[91d4177d\] Opus\_jll v1.3.2+0
> \[80dd9cbb\] PPL\_jll v1.2.1+0
> \[36c8627f\] Pango\_jll v1.50.14+0
> ⌅ \[83958c19\] Perl\_jll v5.34.0+2
> \[30392449\] Pixman\_jll v0.42.2+0
> \[ea2cea3b\] Qt5Base\_jll v5.15.3+2
> \[05236dd9\] Readline\_jll v8.2.1+0
> \[f50d1b31\] Rmath\_jll v0.4.0+0
> ⌅ \[43d676ae\] Singular\_jll v403.1.300+0
> ⌅ \[fb77eaff\] Sundials\_jll v5.2.1+0
> ⌅ \[3428059b\] SymEngine\_jll v0.8.1+0
> \[36f60fef\] TOPCOM\_jll v0.17.8+0
> \[a2964d1f\] Wayland\_jll v1.21.0+1
> \[2381bf8a\] Wayland\_protocols\_jll v1.25.0+0
> \[02c8fc9c\] XML2\_jll v2.11.5+0
> \[aed1982a\] XSLT\_jll v1.1.34+0
> \[4f6342f7\] Xorg\_libX11\_jll v1.8.6+0
> \[0c0b7dd1\] Xorg\_libXau\_jll v1.0.11+0
> \[3c9796d7\] Xorg\_libXcomposite\_jll v0.4.5+4
> \[935fb764\] Xorg\_libXcursor\_jll v1.2.0+4
> \[0aeada51\] Xorg\_libXdamage\_jll v1.1.5+4
> \[a3789734\] Xorg\_libXdmcp\_jll v1.1.4+0
> \[1082639a\] Xorg\_libXext\_jll v1.3.4+4
> \[d091e8ba\] Xorg\_libXfixes\_jll v5.0.3+4
> \[a51aa0fd\] Xorg\_libXi\_jll v1.7.10+4
> \[d1454406\] Xorg\_libXinerama\_jll v1.1.4+4
> \[ec84b674\] Xorg\_libXrandr\_jll v1.5.2+4
> \[ea2f1a96\] Xorg\_libXrender\_jll v0.9.10+4
> \[b6f176f1\] Xorg\_libXtst\_jll v1.2.3+4
> \[14d82f49\] Xorg\_libpthread\_stubs\_jll v0.1.1+0
> \[c7cfdc94\] Xorg\_libxcb\_jll v1.15.0+0
> \[cc61e674\] Xorg\_libxkbfile\_jll v1.1.2+0
> \[12413925\] Xorg\_xcb\_util\_image\_jll v0.4.0+1
> \[2def613f\] Xorg\_xcb\_util\_jll v0.4.0+1
> \[975044d2\] Xorg\_xcb\_util\_keysyms\_jll v0.4.0+1
> \[0d47668e\] Xorg\_xcb\_util\_renderutil\_jll v0.3.9+1
> \[c22f9ab0\] Xorg\_xcb\_util\_wm\_jll v0.4.1+1
> \[35661453\] Xorg\_xkbcomp\_jll v1.4.6+0
> \[33bec58e\] Xorg\_xkeyboard\_config\_jll v2.39.0+0
> \[c5fb5394\] Xorg\_xtrans\_jll v1.5.0+0
> \[3161d3a3\] Zstd\_jll v1.5.5+0
> \[de012916\] at\_spi2\_atk\_jll v2.34.1+4
> \[0fc3237b\] at\_spi2\_core\_jll v2.34.0+4
> \[508c9074\] bliss\_jll v0.77.0+1
> ⌅ \[28df3c45\] boost\_jll v1.76.0+1
> \[f07e07eb\] cddlib\_jll v0.94.13+0
> \[5558cf25\] cohomCalg\_jll v0.32.0+0
> \[214eeab7\] fzf\_jll v0.35.1+0
> \[da03df04\] gdk\_pixbuf\_jll v2.42.8+0
> \[bf975903\] iso\_codes\_jll v4.11.0+0
> \[9a68df92\] isoband\_jll v0.2.3+0
> \[1493ae25\] lib4ti2\_jll v1.6.10+0
> \[a4ae2306\] libaom\_jll v3.4.0+0
> \[0ac62f75\] libass\_jll v0.15.1+0
> ⌅ \[3eaa8342\] libcxxwrap\_julia\_jll v0.9.7+3
> \[f638f0a6\] libfdk\_aac\_jll v2.0.2+0
> \[b53b4c65\] libpng\_jll v1.6.38+0
> ⌅ \[4d8266f6\] libpolymake\_julia\_jll v0.8.0+2
> ⌅ \[ae4fbd8f\] libsingular\_julia\_jll v0.23.1+0
> \[075b6546\] libsixel\_jll v1.10.3+0
> \[f27f6e37\] libvorbis\_jll v1.3.7+1
> \[3873f7d0\] lrslib\_jll v0.3.3+0
> \[f8abcde7\] micromamba\_jll v1.4.9+0
> ⌅ \[6d01cc9a\] msolve\_jll v0.2.3+1
> \[55c6dc9b\] nauty\_jll v2.6.13+1
> ⌃ \[6690c6e9\] normaliz\_jll v300.900.100+0
> ⌅ \[7c209550\] polymake\_jll v400.600.0+0
> \[fe1e1685\] snappy\_jll v1.1.9+1
> \[1270edf5\] x264\_jll v2021.5.5+0
> \[dfaa095f\] x265\_jll v3.5.0+0
> \[d8fb68d0\] xkbcommon\_jll v1.4.1+1
> \[0dad84c5\] ArgTools v1.1.1
> \[56f22d72\] Artifacts
> \[2a0f44e3\] Base64
> \[8bf52ea8\] CRC32c
> \[ade2ca70\] Dates
> \[8ba89e20\] Distributed
> \[f43a241f\] Downloads v1.6.0
> \[7b1f6079\] FileWatching
> \[9fa8497b\] Future
> \[b77e0a4c\] InteractiveUtils
> \[4af54fe1\] LazyArtifacts
> \[b27032c2\] LibCURL v0.6.3
> \[76f85450\] LibGit2
> \[8f399da3\] Libdl
> \[37e2e46d\] LinearAlgebra
> \[56ddb016\] Logging
> \[d6f4376e\] Markdown
> \[a63ad114\] Mmap
> \[ca575930\] NetworkOptions v1.2.0
> \[44cfe95a\] Pkg v1.9.2
> \[de0858da\] Printf
> \[9abbd945\] Profile
> \[3fa0cd96\] REPL
> \[9a3f8284\] Random
> \[ea8e919c\] SHA v0.7.0
> \[9e88b42a\] Serialization
> \[1a1011a3\] SharedArrays
> \[6462fe0b\] Sockets
> \[2f01184e\] SparseArrays
> \[10745b16\] Statistics v1.9.0
> \[4607b0f0\] SuiteSparse
> \[fa267f1f\] TOML v1.0.3
> \[a4e569a6\] Tar v1.10.0
> \[8dfed614\] Test
> \[cf7118a7\] UUIDs
> \[4ec0a83e\] Unicode
> \[e66e0078\] CompilerSupportLibraries\_jll v1.0.5+0
> \[781609d7\] GMP\_jll v6.2.1+2
> \[deac9b47\] LibCURL\_jll v7.84.0+0
> \[29816b5a\] LibSSH2\_jll v1.10.2+0
> \[3a97d323\] MPFR\_jll v4.1.1+4
> \[c8ffd9c3\] MbedTLS\_jll v2.28.2+0
> \[14a3606d\] MozillaCACerts\_jll v2022.10.11
> \[4536629a\] OpenBLAS\_jll v0.3.21+4
> \[05823500\] OpenLibm\_jll v0.8.1+0
> \[efcefdf7\] PCRE2\_jll v10.42.0+0
> \[bea87d4a\] SuiteSparse\_jll v5.10.1+6
> \[83775a58\] Zlib\_jll v1.2.13+0
> \[8e850b90\] libblastrampoline\_jll v5.8.0+0
> \[8e850ede\] nghttp2\_jll v1.48.0+0
> \[3f19e933\] p7zip\_jll v17.4.0+0
> Info Packages marked with ⌃ and ⌅ have new versions available, but those with ⌅ are restricted by compatibility constraints from upgrading. To see why use \`status --outdated -m\`
> \`\`\`
> 
> B.
> FYI: After removing and updateing to latest, I'm not sure why this works (i.e. I know no workaround):
> \`\`\`
> (@v1.9) pkg\> add --preserve=all ParameterEstimation
> Resolving package versions...
> ERROR: Unsatisfiable requirements detected for package Symbolics \[0c5d862f\]:
> Symbolics \[0c5d862f\] log:
> ├─possible versions are: 0.1.0-5.10.0 or uninstalled
> ├─restricted by compatibility requirements with ArrayInterface \[4fba245c\] to versions: \[0.1.0-4.2.2, 4.6.0-5.10.0\] or uninstalled
> │ └─ArrayInterface \[4fba245c\] log:
> │ ├─possible versions are: 0.0.1-7.4.11 or uninstalled
> │ └─restricted to versions 6.0.25 by an explicit requirement, leaving only versions: 6.0.25
> ├─restricted by compatibility requirements with Latexify \[23fbe1c1\] to versions: 5.3.0-5.10.0 or uninstalled
> │ └─Latexify \[23fbe1c1\] log:
> │ ├─possible versions are: 0.5.0-0.16.1 or uninstalled
> │ └─restricted to versions 0.16.1 by an explicit requirement, leaving only versions: 0.16.1
> ├─restricted by compatibility requirements with RuntimeGeneratedFunctions \[7e49a35a\] to versions: \[0.1.0-5.4.0, 5.5.1-5.10.0\] or uninstalled, leaving only versions: \[5.3.0-5.4.0, 5.5.1-5.10.0\] or uninstalled
> │ └─RuntimeGeneratedFunctions \[7e49a35a\] log:
> │ ├─possible versions are: 0.1.0-0.5.12 or uninstalled
> │ └─restricted to versions 0.5.12 by an explicit requirement, leaving only versions: 0.5.12
> ├─restricted by compatibility requirements with ParameterEstimation \[b4cd1eb8\] to versions: 4.0.0-5.10.0, leaving only versions: \[5.3.0-5.4.0, 5.5.1-5.10.0\]
> │ └─ParameterEstimation \[b4cd1eb8\] log:
> │ ├─possible versions are: 0.1.0-0.2.1 or uninstalled
> │ └─restricted to versions \* by an explicit requirement, leaving only versions: 0.1.0-0.2.1
> └─restricted by compatibility requirements with DomainSets \[5b8099bc\] to versions: 0.1.0-0.1.26 or uninstalled — no versions left
> └─DomainSets \[5b8099bc\] log:
> ├─possible versions are: 0.0.1-0.7.0 or uninstalled
> └─restricted to versions 0.7.0 by an explicit requirement, leaving only versions: 0.7.0
> \`\`\`

---

<div class="post-metadata">

**Author:** ![orebas](https://avatars.discourse-cdn.com/v4/letter/o/bbe5ce/32.png) [@orebas](https://discourse.julialang.org/u/orebas)\
**Post date:** [October 29, 2023, 6:00am UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/19 "2023-10-29T06:00:51Z")

</div>

This post was temporarily hidden by the community for possibly being off-topic, unfocused, inappropriate, or spammy.

---

<div class="post-metadata">

**Author:** ![vindarel](https://avatars.discourse-cdn.com/v4/letter/v/ce73a5/32.png) [@vindarel](https://discourse.julialang.org/u/vindarel)\
**Post date:** [April 27, 2024, 12:03am UTC](https://discourse.julialang.org/t/does-the-julia-community-suffer-from-the-lisp-curse-whatever-it-means/102852/20 "2024-04-27T00:03:27Z")

</div>

> Lisp is fast because interpreted, or if compiled […]

Hi, my 2c: yes, implementations like SBCL or CCL (known for its fast compilation speed) compile to native code. CLISP compiles to bytecode, but it isn’t the most used one nowadays.