awesome-lisp-companies
ModelingToolkit.jl
Our great sponsors
awesome-lisp-companies | ModelingToolkit.jl | |
---|---|---|
50 | 15 | |
571 | 1,321 | |
- | 2.3% | |
7.4 | 9.8 | |
4 months ago | 5 days ago | |
Julia | ||
- | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
awesome-lisp-companies
-
Why Is Common Lisp Not the Most Popular Programming Language?
Everyone, if you don't have a clue on how's Common Lisp going these days, I suggest:
https://lisp-journey.gitlab.io/blog/these-years-in-common-li... (https://www.reddit.com/r/lisp/comments/107oejk/these_years_i...)
A curated list of libraries: https://github.com/CodyReichert/awesome-cl
Some companies, the ones we hear about: https://github.com/azzamsa/awesome-lisp-companies/
and oh, some more editors besides Emacs or Vim: https://lispcookbook.github.io/cl-cookbook/editor-support.ht... (Atom/Pulsar support is good, VSCode support less so, Jetbrains one getting good, Lem is a modern Emacsy built in CL, Jupyter notebooks, cl-repl for a terminal REPL, etc)
yet no other language gives so many tools to the developer… quantum companies would disagree. https://github.com/azzamsa/awesome-lisp-companies/
(BTW: CL isn't Smalltalk which isn't uniquely that anymore, we do use source files and we can compile single-file binaries. My web app weights 35MB, starts up in 0.4s (or 0.01s without core compression))
-
We need to talk about parentheses
Examples (for Common Lisp, so not citing Emacs): reddit v1, Google's ITA Software that powers airfare search engines (Kayak, Orbitz…), Postgres' pgloader (http://pgloader.io/), which was re-written from Python to Common Lisp, Opus Modus for music composition, the Maxima CAS, PTC 3D designer CAD software (used by big brands worldwide), Grammarly, Mirai, the 3D editor that designed Gollum's face, the ScoreCloud app that lets you whistle or play an instrument and get the music score,
but also the ACL2 theorem prover, used in the industry since the 90s, NASA's PVS provers and SPIKE scheduler used for Hubble and JWT, many companies in Quantum Computing, companies like SISCOG, who plans the transportation systems of european metropolis' underground since the 80s, Ravenpack who's into big-data analysis for financial services (they might be hiring), Keepit (https://www.keepit.com/), Pocket Change (Japan, https://www.pocket-change.jp/en/), the new Feetr in trading (https://feetr.io/, you can search HN), Airbus, Alstom, Planisware (https://planisware.com),
or also the open-source screenshotbot (https://screenshotbot.io), the Kandria game (https://kandria.com/),
and the companies in https://github.com/azzamsa/awesome-lisp-companies and on LispWorks and Allegro's Success Stories.
https://github.com/tamurashingo/reddit1.0/
https://www.ptc.com/en/products/cad/3d-design
https://apps.apple.com/us/app/scorecloud-express/id566535238
-
A Tour of Lisps
Haven't had a lisp job, so maybe I shouldn't comment, but... I did use CL and Clojure on the job for a few things at my last two places. It's easier to find Clojure companies (and them to find you) than Common Lisp ones. You might want to peruse https://github.com/azzamsa/awesome-lisp-companies from time to time and see if any have openings. There's other resources linked too and of course there's the reddit and discord community (such as there is) hubs. You can also see if there are any meetups in your area, that's how I almost ended up at a Clojure startup some years back.
I should have taken strategy notes after talking to a guy at my last job who got management buy-in to rewrite a lot of Java code (for android) to Kotlin and have all new code for android be in Kotlin (before that was considered the sensible default). I think that's in general a better approach for a lot of would-be paid lispers: don't wait for or look for the lisp job, make the lisp job. Whether that's doing work where the customer doesn't care what language the thing is made in, or introducing it (some have even snuck it in -- the original clojure.jar got a lot of early success that way) to an existing work place. What I somewhat remember from my conversation was that if you can make a good technical case and have at least one other person supporting you (ideally your entire dev team as was his case), it's a lot easier to sell. No one raised bogus concerns about increasing the hiring difficulty or effort learning the new system. (I say bogus because engineers are learning all the time, and huge swathes of the industry have already had to do things like migrate from ObjC to Swift, or the various versions of JavaScript and later TypeScript + all the framework churn, switching IDEs; learning and change are quite common and a non-issue.) From other Lisp company reports, getting a new hire up to speed to be productive with the team using Common Lisp is a matter of a week or two, a small portion of the overall onboarding time a lot of new jobs have. Mastery takes longer, of course, but that's different.
If I had stayed longer at my last job I would have continued to flesh out a better demo for interactive selenium webdriver tests for our main Java application after injecting ABCL into it, it seemed like the easiest vector to get more interest from my team and other teams. It kind of sucks when you're debugging a broken test and finally hit an exception but now you have to start over again (especially if you stepped too far in the debugger), especially with heavy webdriver tests that can take a long time. The Lisp debugging experience is so much better... And when writing the test from scratch, it's very interactive, you type code and execute it and verify the browser did what you intended. When you're done you run it again from scratch to verify.
-
All of Mark Watson's Lisp Books
> but there doesn't seem to be one that really stands out as pragmatic, industrial
disagree ;) This industrial language is Common Lisp.
Some industrial uses:
- http://www.lispworks.com/success-stories/index.html
- https://github.com/azzamsa/awesome-lisp-companies/
- https://lisp-lang.org/success/
Example companies: Intel's programmable chips, the ACL2 theorem prover (https://royalsocietypublishing.org/doi/10.1098/rsta.2015.039...), urban transportation planning systems (SISCOG), Quantum Computing (HRL Labs, Rigetti…), big data financial analysis (Ravenpack, they might be hiring), Google, Boeing, the NASA, etc.
ps: Python competing? strong disagree^^
-
Steel Bank Common Lisp
Hey there, newer member of the first group here. Please see https://github.com/azzamsa/awesome-lisp-companies/ to update your meta-comment. So, is CL used in the industry today, yes or no?
Personal note: I much prefer to maintain a long-living software in Common Lisp rather than in Python, thank you very much. May all the new programmers learn easily and all the teams have lots of ~~burden~~ work with Python, good for them.
-
Racket: The Lisp for the Modern Day
Common Lisp has many industrial uses though.
(https://github.com/azzamsa/awesome-lisp-companies/
https://lisp-lang.org/success/
http://www.lispworks.com/success-stories/index.html
such as
https://www.cs.utexas.edu/users/moore/acl2/ (theorem prover used by big corp©)
https://allegrograph.com/press_room/barefoot-networks-uses-f... (Intel programmable chip)
quantum compilers https://news.ycombinator.com/item?id=32741928
etc, etc, etc)
-
Why Lisp Syntax Works
A few more that we know of, using CL today: https://github.com/azzamsa/awesome-lisp-companies/
Others: https://lisp-lang.org/success/
-
How to Understand and Use Common Lisp
yes
https://github.com/azzamsa/awesome-lisp-companies
industrial theorem prover, design of Intel chips, quantum compilers...
and little me, being more productive and having more fun than with python to deploy boring tools (read a DB, format the data, send to FTP servers, show a web interface...).
ModelingToolkit.jl
- Simulating a simple circuit with the ModelingToolkit
-
“Why I still recommend Julia”
No, you do get type errors during runtime. The most common one is a MethodNotFound error, which corresponds to a dispatch not being found. This is the one that people then complain about for long stacktraces and as being hard to read (and that's a valid criticism). The reason for it is because if you do xy with a type combination that does not have a corresponding dispatch, i.e. (x::T1,y::T2) not defined anywhere, then it looks through the method table of the function, does not find one, and throws this MethodNotFound error. You will only get no error if a method is found. Now what can happen is that you can have a method to an abstract type, *(x::T1,y::AbstractArray), but `y` does not "actually" act like an AbstractArray in some way. If the way that it's "not an AbstractArray" is that it's missing some method overloads of the AbstractArray interface (https://docs.julialang.org/en/v1/manual/interfaces/#man-inte...), you will get a MethodNotFound error thrown on that interface function. Thus you will only not get an error if someone has declared `typeof(y) <: AbstractArray` and implemented the AbstractArray interface.
However, what Yuri pointed out is that there are some packages (specifically in the statistics area) which implemented functions like `f(A::AbstractArray)` but used `for i in 1:length(A)` to iterate through x's values. Notice that the AbstractArray interface has interface functions for "non-traditional indices", including `axes(A)` which is a function to call to get "the a tuple of AbstractUnitRange{<:Integer} of valid indices". Thus these codes are incorrect, because by the definition of the interface you should be doing `for i in axes(A)` if you want to support an AbstractArray because there is no guarantee that its indices go from `1:length(A)`. Note that this was added to the `AbstractArray` interface in the v1.0 change, which is notably after the codes he referenced were written, and thus it's more that they were not updated to handle this expanded interface when the v1.0 transition occurred.
This is important to understand because the criticisms and proposed "solutions" don't actually match the case... at all. This is not a case of Julia just letting anything through: someone had to purposefully define these functions for them to exist. And interfaces are not a solution here because there is an interface here, its rules were just not followed. I don't know of an interface system which would actually throw an error if someone does a loop `for i in 1:length(A)` in a code where `A` is then indexed by the element. That analysis is rather difficult at the compiler level because it's non-local: `length(A)` is valid since querying for the length is part of the AbstractArray interface (for good reasons), so then `1:length(A)` is valid since that's just range construction on integers, so the for loop construction itself is valid, and it's only invalid because of some other knowledge about how `A[i]` should work (this look structure could be correct if it's not used to `A[i]` but rather do something like `sum(i)` without indexing). If you want this to throw an error, the only real thing you could do is remove indexing from the AbstractArray interface and solely rely on iteration, which I'm not opposed to (given the relationship to GPUs of course), but etc. you can see the question to solving this is "what is the right interface?" not "are there even interfaces?" (of which the answer is, yes but the errors are thrown at runtime MethodNotFound instead of compile time MethodNotImplemented for undefined things, the latter would be cool for better debugging and stacktraces but isn't a solution).
This is why the real discussions are not about interfaces as a solution, they don't solve this issue, and even further languages with interfaces also have this issue. It's about tools for helping code style. You probably should just never do `for i in 1:length(A)`, probably you should always do `for i in eachindex(A)` or `for i in axes(A)` because those iteration styles work for `Array` but also work for any `AbstractArray` and thus it's just a safer way to code. That is why there are specific mentions to not do this in style guides (for example, https://github.com/SciML/SciMLStyle#generic-code-is-preferre...), and things like JuliaFormatter automatically flag it as a style break (which would cause CI failures in organizations like SciML which enforce SciML Style formatting as a CI run with Github Actions https://github.com/SciML/ModelingToolkit.jl/blob/v8.14.1/.gi...). There's a call to add linting support for this as well, flagging it any time someone writes this code. If everyone is told to not assume 1-based indexing, formatting CI fails if it is assumed, and the linter underlines every piece of code that does it as red, (along with many other measures, which includes extensive downstream testing, fuzzing against other array types, etc.) then we're at least pretty well guarded against it. And many Julia organizations, like SciML, have these practices in place to guard against it. Yuri's specific discussion is more that JuliaStats does not.
-
‘Machine Scientists’ Distill the Laws of Physics from Raw Data
The thing to watch in the space of Simulink/Modelica is https://github.com/SciML/ModelingToolkit.jl . It's an acausal modeling system similar to Modelica (though extended to things like SDEs, PDEs, and nonlinear optimization), and has a standard library (https://github.com/SciML/ModelingToolkitStandardLibrary.jl) similar to the MSL. There's still a lot to do, but it's pretty functional at this point. The two other projects to watch are FunctionalModels.jl (https://github.com/tshort/FunctionalModels.jl, which is the renamed Sims.jl), which is built using ModelingToolkit.jl and puts a more functional interface on it. Then there's Modia.jl (https://github.com/ModiaSim/Modia.jl) which had a complete rewrite not too long ago, and in its new form it's fairly similar to ModelingToolkit.jl and the differences are more in the details. For causal modeling similar to Simulink, there's Causal.jl (https://github.com/zekeriyasari/Causal.jl) which is fairly feature-complete, though I think a lot of people these days are going towards acausal modeling instead so flipping Simulink -> acausal, and in that transition picking up Julia, is what I think is the most likely direction (and given MTK has gotten 40,000 downloads in the last year, I think there's good data backing it up).
And quick mention to bring it back to the main thread here, the DataDrivenDiffEq symbolic regression API gives back Symbolics.jl/ModelingToolkit.jl objects, meaning that the learned equations can be put directly into the simulation tools or composed with other physical models. We're really trying to marry this process modeling and engineering world with these "newer" AI tools.
-
Julia 1.7 has been released
https://homes.cs.washington.edu/~thickstn/ctpg-project-page/...
That's all showing the raw iteration count to show that it algorithmically is faster, but the time per iteration is also fast for many reasons showcased in the SciMLBenchmarks routinely outperforming C and Fortran solvers (https://github.com/SciML/SciMLBenchmarks.jl). So it's excelling pretty well, and things like the automated discovery of black hole dynamics are all done using the universal differential equation framework enabled by the SciML tools (see https://arxiv.org/abs/2102.12695 for that application).
What we are missing however is that, right now these simulations are all writing raw differential equations so we do need a better set of modeling tools. That said, MuJoCo and DiffTaichi are not great physical modeling environments for building real systems, instead we would point to Simulink and Modelica as what are really useful for building real-world systems. So it would be cool if there was a modeling language in Julia which extends that universe and directly does optimal code generation for the Julia solvers... and that's what ModelingToolkit.jl is (https://github.com/SciML/ModelingToolkit.jl). That project is still pretty new, but there's already enough to show some large-scale models outperforming Dymola on examples that require symbolic tearing and index reduction, which is far more than what physical simulation environments used for non-scientific purposes (MuJoCo and DiffTaichi) are able to do. See the workshop for details (https://www.youtube.com/watch?v=HEVOgSLBzWA). And that's just the top level details, there's a whole Julia Computing product called JuliaSim (https://juliacomputing.com/products/juliasim/) which is then being built on these pieces to do things like automatically generate ML-accelerated components and add model building GUIs.
That said, MuJoCo and DiffTaichi have much better visualizations and animations than MTK. Our focus so far has been on the core routines, making them fast, scalable, stable, and extensive. You'll need to wait for the near future (or build something with Makie) if you want the pretty pictures of the robot to happen automatically. That said, Julia's Makie visualization system has already been shown to be sufficiently powerful for this kind of application (https://nextjournal.com/sdanisch/taking-your-robot-for-a-wal...), so we're excited to see where that will go in the future.
-
[Research] Input Arbitrary PDE -> Output Approximate Solution
PDEs are difficult because you don't have a simple numerical definition over all PDEs because they can be defined by arbitrarily many functions. u' = Laplace u + f? Define f. u' = g(u) * Laplace u + f? Define f and g. Etc. To cover the space of PDEs you have to go symbolic at some point, and make the discretization methods dependent on the symbolic form. This is precisely what the ModelingToolkit.jl ecosystem is doing. One instantiation of a discretizer on this symbolic form is NeuralPDE.jl which takes a symbolic PDESystem and generates an OptimizationProblem for a neural network which represents the solution via a Physics-Informed Neural Network (PINN).
-
Should I switch over completely to Julia from Python for numerical analysis/computing?
There's a very clear momentum for Julia here in this domain of modeling and simulation. With JuliaSim funding an entire modeling and simulation department within Julia Computing dedicated to building out an ecosystem that accelerates this domain and the centralization around the SciML tooling, this is an area where we absolutely have both a manpower and momentum advantage. We're getting many universities (PhD students and professors) involved on the open source side, while building out different commercial tools and GUIs on top of the open numerical core. The modeling and simulation domain itself is soon going to have its own SciMLCon since our developer community has gotten too large to just be a few JuliaCon talks: it needs its own days to fit everyone! Not only that, in many aspects we're not just moving faster but have already passed. Not in every way, there's still some important discussion in controls that needs to happen, but that's what the momentum is for.
- What should a graduate engineer know about MATLAB?
-
I'm considering Rust, Go, or Julia for my next language and I'd like to hear your thoughts on these
Julia has great support for modeling, have a look at ModelingToolkit.jl. From the README:
-
Rust vs Fortran
Bonus 1: And for example with packages like ModelingToolkit.jl you write an abstract model that is in a first step symbolically reduced and optimized for numerical stability, then automatically parallelized for the specific system architecture (cpu, gpu, distributed) and compiled. And the cool thing is that everything happens as julia code transformations, and no other low level language (besides LLVM very far down) is used.
-
JuliaSymbolics Roadmap: A Modern Computer Algebra System for a Modern Language
I didn't find examples on JuliaSymbolics. I however followed the link to https://github.com/SciML/ModelingToolkit.jl
What are some alternatives?
casadi - CasADi is a symbolic framework for numeric optimization implementing automatic differentiation in forward and reverse modes on sparse matrix-valued computational graphs. It supports self-contained C-code generation and interfaces state-of-the-art codes such as SUNDIALS, IPOPT etc. It can be used from C++, Python or Matlab/Octave.
Carp - A statically typed lisp, without a GC, for real-time applications.
DifferentialEquations.jl - Multi-language suite for high-performance solvers of differential equations and scientific machine learning (SciML) components. Ordinary differential equations (ODEs), stochastic differential equations (SDEs), delay differential equations (DDEs), differential-algebraic equations (DAEs), and more in Julia.
portacle - A portable common lisp development environment
julia - The Julia Programming Language
coalton - Coalton is an efficient, statically typed functional programming language that supercharges Common Lisp.
Fennel - Lua Lisp Language
NeuralPDE.jl - Physics-Informed Neural Networks (PINN) Solvers of (Partial) Differential Equations for Scientific Machine Learning (SciML) accelerated simulation
dolfinx - Next generation FEniCS problem solving environment
Gridap.jl - Grid-based approximation of partial differential equations in Julia
Symbolics.jl - Symbolic programming for the next generation of numerical software
kandria - A post-apocalyptic actionRPG. Now on Steam!