normally more parameters leads to overfitting (like fitting a polynomial to points), but neural nets are for some reason not as susceptible to that and can scale well with more parameters.
Thats been my understanding of the crux of mystery.
Would love to be corrected by someone more knowledgable though
This absolutely was the crux of the (first) mystery, and I would argue that "deep learning theory" really only took off once it recognized this. There are other mysteries too, like the feasibility of transfer learning, neural scaling laws, and now more recently, in-context learning.
I've never quite wrapped my head around the full JVM Threading story (esp with the new VThreads). Does the Thread Pool system work well when you over-parallelize your workload? If it's thread-and-forget? Can you thread stuff in a library you write, even if the caller is threading stuff at a higher level?
Do you have any idea/guess why Injest hasn't been folded in to core? It seems a natural extension, so I worry if it has some hidden footgun
Awesome modern flexible framework for making GUIs.
It's important to highlight that the it doesn't enforce any single model of how to hook up your GUI and state management. The built-in subscription model is fantastic, but you can do whatever suits you.
A big change was added in v1.9.0 that's not really documented in the README
With the new extension lifecycles you can pretty much design and hook up any GUI system you'd like. You can even have different GUI sub-trees have separate systems entirely.
The problem is that you have to recalculate the world at each update. In Clojure you have immutable datastructures that help. On the webstack you have React and reconciliation. All solutions come with a performance overhead. There are some interesting hybrid systems where you can try to isolate derived states and cache intermediate states (ex: Pathom for declarative state management and caching, and extension lifecycles in CLJFX for isolating UI subtrees)
I'm curious what you found inadequate with the existing solutions?
I remember when I started writing Clojure I'd use stuff like Records to encode the data-shape. Paired with Protocols they're quite powerful when the interface is more important than the shape. But in most situations the flexible data shapes are what make programs very easy to extend/evolve.
It's interesting that the flights are not timed for when the moon is in the magnetosphere shadow. As far as I could gather it seems they're intentionally exposing astronauts to more radiation to test equipment (maybe with an eye to future Mars missions?). Hard to get hard details from all the press release fluffy
It's got to be one of the most unusual biographies of a living person that I've ever come across. Nearly every sentence is a head-turner. If you made it up no one would believe you
You generally do present your passport when leaving. Most places you get an exit stamp (which matches your entry stamp). They usually confirm things such as not overstaying a visa.
ex:
overstaying in Thailand results in a on-the-spot fine
China lately has exit checks when traveling to SEA (they try to intercept people traveling to scam centers)
Babashka,
which is Clojure for scripting,
is the Small Clojure Interpreter compiled to a native executable
That said,
it does limit you a little b/c with Graal native you need to tell the compiler if you will dynamically use a type/class
(so it can't be inferred during compilation).
The compiler is doing what JS people call "tree shaking" to strip unused code.
(dead code elimination in C++ terms)
As I understand it you have some annotation file so you don't eliminate too much,
similar to using Proguard.
So it's mostly plug-n-play but with some caveats
New GraalVM project Crema now supports runtime class-loading. Here's a full Clojure runtime built with GraalVM native-image + Crema: https://github.com/borkdude/cream
Though to my mind the correct solution would be to launch a program + VM, then freeze/store the program state. Then you could just memcopy+execve the program and immediately skip all the initialization
(after a bit of Googling it seems this isn't a new idea haha, and it's in the JVM roadmap with Project Leyden. Should come out in maybe JDK 27 and make a lot of this stuff obsolete)
DSLs typically involves constructing macros that are domain specific (to cobble together a domain specific programming language on top of the host). Most of the linked examples are not macro based and are the exact opposite. They specifying domain specific data layouts built directly using the Clojure-native immutable datatypes. They don't create Domain specific datatypes or function-generating wrappers. It's just rarely necessary
A good example is making GUIs in Clojure. At first there was a cool macro based system called `fn-fx` that maked a JavaFX GUI. Then vlaaad wrote `cljfx` which just used plain Clojure maps and removed the macros entirely. This increased the boilerplate a tiny amount but made the system much more flexible and extensible
> DSLs typically involves constructing macros that are domain specific
a DSL is a constrained language for expressing domain concepts.
in traditional Lisps they are often syntax-oriented, because code is lists and macros are a natural tool.
in Clojure, pervasive use of keywords, vectors and maps allows you to shift DSL design towards data interpretation rather than syntax transformation.
so in Clojure doesn't discourage DSLs - clojure practicioners simply prefer data-oriented DSLs to macro-oriented ones, mostly because they are easier to reason about and process with existing tools, while macros are used more selectively.
The original comment you took issue with "The point being made is that the Clojure style discourages building DSLs and the like and prefers to remain close to Clojure types and constructs". You seemingly read half the sentence and in the most unfavorable way possible. (in context it's clearly not talking about "data-oriented DSLs)
> DSL is a constrained language for expressing domain concepts
What you're calling "data-oriented DSLs" is not constrained.
I guess this is all semantic, but in my book just specifying a data-structure doesn't make a language. You're not extending the host language in any way
> What you're calling "data-oriented DSLs" is not constrained
constraints come from the interpreter, not from the syntax
> in my book just specifying a data-structure doesn't make a language
correct, it does not
what makes it a language is defining constraints on that structure and rules for how it's interpreted
that works both for clojure (where the data structure can involve lists, vectors, maps and primitives) and traditional lisps (where data structure is lists, or to be precise cons cells and primitives)
in both cases macros can be used and are used (but don't have to be used) to prevent immediate evaluation of those data structures according to host language rules and instead change how they are evaluated according to DSL author's rules
for example, datomic queries are just data structures, but they clearly form a constrained language with well defined semantics and the fact that they're not implemented via macros doesn't make them less of a DSL
Thats been my understanding of the crux of mystery.
Would love to be corrected by someone more knowledgable though
reply