How difficult it is to get a perfect beam in practice? Can one manufacture a flat rotman lense like that to introduce sinc phase shifts - this should yield a well behaved very directed beam? What are the practical challenges in doing so?
If AI can find new proofs for well posed math problems, i see no reason why it shouldn't be able to implement a more performant fully featured version of an existing interpreter (eg with JIT and AOT) that emulates python api well and passes all python tests and tests of other projects. It is true that a lot of human effort and thought has been put into squeezing performance out of the existing implementation. It is true that many people have found that getting that last 1% of python test suite to pass turned out to be insurmountably hard. Same is true for math, and yet AI sometimes finds simple solutions that we somehow missed. Maybe there's a simple optimization that was used in an obscure interpreter of a domain specific language that we never heard of. Worth a shot in my mind. If that turns out to be successful, we should ideally find the code that served "as an inspiration" if any.
It might make more practical sense to start from CPython and try to optimize that further though. It even has a "not fully fleshed out" JIT already.
I have not looked into this specific issue, but are we sure that a regression here could have been avoided via a localized test? Maybe issues seem to arise from A implementing a feature with tests. B seeing that A lacks some functionality and adding it (potentially with tests), C seeing this (extra) functionality in A, and using in unintended ways not covered by tests (or in an unintended environment) + multiply by many layers of this A-B-C story up and down the stack.
I agree re Rust vs C - this is not (only) a language issue. What would (roughly) the invariant be here?
In another thread comment below i argue that maybe the system (OS) itself is so complex that it lacks clear contract / the contract evolves too quickly over time (as other parts of the code need to change the given piece of code to extend it to their use case) and that defies clear encoding?
Or we lack easy enough means to describe specs? I tried reading jepsen spec earlier today and despite it being an "integration test" of sorts, it is far from "simple".
Can an entire OS or a system of comparable complexity be decomposed into objects simple enough that their entire intended behavior (with all edge cases) can be explained in a paragraph of human text + half a screen of dense behavioral "spec" - if i do X and do Y, Z should come out / hold _no matter what happens in-between_. Or that's what asserts + fuzzing is effectively supposed to do? Is there a clear distinction between invalid input and failed invariant in typical C code? I guess error code vs seg fault?
On the other hand, it is (both halting and spec adherence) are checkable under compute and space constraints though? :) I'd say the biggest hurdle are means to describe the spec in way that is easy enough for a human to produce to make it feasible.
Not a DB person either, but things like TLA+ seem very hard to write even with LLMs. Behavioral tests with an enumerable number of random paths to take (aka model checking - eg jepsen) seem more feasible. Although you can't check internal properties of the system (string `pass` or any of it's copies or parts are not held anywhere in memory at any point between lines A and B) unless we can check that two memory dumps are indistinguishable with different pass strings (assuming we abstracted away storage devices in a test environment).. Also not sure if it's "easy enough" to write such tests either.
Maybe the reason is that OS domain objects / primitives are too complex and not "isolatable" enough / lack a clear contract at all? (Hence multi file refactorings that break invariants.)
I am far from a security expert, but from the number of "we missed a single line C check across files during refactoring" critical security bugs discovered on a regular basis these days, the whole premise of a "giant secure open source C codebase" seems questionable. It is not specific to C of course, but invariants are arguably even harder to enforce and track consistently (esp under changes to code) in C. Unsure if FP with invariants encoded in types is a practically feasible scalable solution either. Model checking? [LLM] fuzzing? Fewer primitives with clear boundaries? Is that how seLinux was "checked"?
Could you elaborate on what exactly does such syntax provide over kwargs? To me it looks like verbatim x=a, y=b replaced by x(a)+y(b) in the argument section.
Yes, that was my thought as well when i was visiting UK and reddit kept asking me to verify my age. It might be even more private and non-trackable than that - if "age.id.gov" central authority effectively "provides a new random user id" (implementation may vary and does not need to have a "literal username") every time you try to use it / log into a website that needs to verify your age - this way websites can not even track you across platforms.
It seems like all the tech stack is there to implement a very simple and privacy-persevering solution.
It does not even smell of state censorship because a website does not have to check your age if it decides to be "non compliant".
Why isn't it implemented like that? Based on the comments it seems more like a "free-for-all implement-your-own-PPI-handling-thon".
This will ofc make life harder for a some groups of people - like people without / limited access to IDs etc. And i do not even argue that the whole thing is necessary.
But there seem to be vastly superior technical means to implement that, aren't there?
One argument I heard from a college that the experimental llm written code (not production ofc) should be "write only" - you specify the requirements and constraints and let the machine figure it out - you specifically avoid "fixing it" or "cleaning it up" or reviewing the code because it disrupts the state of this discrete optimizer (over code). Not saying that it is right, or that it should be applied in prod, just noting that this is one potential way to go for non-critical code with clear "win conditions".
I asked the same question a few years ago, and the answer I arrived at is that the app has, by default, more permissions (not only technical but also conventional) to collect data, send push notifications, and otherwise harass the user.
To my surprise, even sophisticated means of traffic masking like amnezia and vxray get disrupted frequently, requiring hopping around self hosted solutions and updating ones setup periodically. That's waaay beyond what most people are capable of. I am fortunate to have some tech worker acquaintance who live next to my family members, otherwise there'd be no way for me to for example guide them through setup and re-configuration remotely. Still, this setup gets disrupted every month or so requiring manual intervention.
Eastern European pan-fried cottage cheese fritters (mix and fry 150g cottage cheese, 5 tbsp flour, 1 egg, 3 tbsp sugar, salt) are great. That's all I have to say.
I still consider jax.vmap to be a little miracle: fn2 = vmap(fn, (1,2)), if i remember correctly, traverces the computation graph of fn and correctly broacasts all operations in a way that ensures that fn2 acts like fn applied in a loop across the second dimension of the first argument (but accelerated, has auto-gradients, etc).
A long while ago i heard something (that might have been a urban myth) about Bose putting useless weight into their headphones to make them appear more "substantially professional". Is that a myth or they have pivoted towards actual quality since early days?
I'd be curious to know the breakdown of "wages and benefits" between academics, teachers and administrative staff. I've heard that admin takes up a huge fraction of the cost. How large can it be?
This is really cool, these patterns (run once now and then once triggered) surface all the time and usually turn into ugly code! How many interations did it take?
So most lines like A { B{ on D{ print() } } C{} } equivalently desugar into something like a = A; b = B(); a.mount(b); d = D(); d.on(f); b.mount(d); .. ?
I got confused by a couple of things. One of them is whether object parameters act like context parameters and there for depend on names in the caller variable scope? Ie if i define 'fn ship.Explode', i must have variable ship at call site? But i can still otherwise pass it explicitly as alien_ship.Explode(), right? How do i know if a particular call takes the current object into account? If i have two variables in my nested scope: ship and asteriod and both have ship.Explode and asteroid.Explode, which one is picked if i do just `Explode`? The innermost? Or I can't have two functions like that because the first thing is literally just a named variable and not a "method"?
Overall, if you could provide some examples of how things could have de-sugured into a different language, that'd be very interesting! Maybe with some examples of why this or that pattern is useful? I think it does a good job for things like on / once, but I'm not grokking how one would structure an app using this variable scoping use clause and object parameters.
Also not sure how to define functions that could be on'd or once'd. (Ah, i see, delve)
"""
Continuing with the previous example of “ß”, one has lowercase("ss") != lowercase("ß") but uppercase("ss") == uppercase("ß"). Conversely, for legacy reasons (compatibility with encodings predating Unicode), there exists a Kelvin sign “K”, which is distinct from the Latin uppercase letter “K”, but also lowercases to the normal Latin lowercase letter “k”, so that uppercase("K") != uppercase("K") but lowercase("K") == lowercase("K").
The correct way is to use Unicode case folding, a form of normalization designed specifically for case-insensitive comparisons. Both casefold("ß") == casefold("ss") and casefold("K") == casefold("K") are true. Case folding usually yields the same result as lowercasing, but not always (e.g., “ß” lowercases to itself but case-folds to “ss”).
"""
One question I have is why have Kelvin sign that is distinct from Latin K and other indistinguishable symbols? To make quantified machine readable (oh, this is not a 100K license plate or money amount, but a temperature)? Or to make it easier for specialized software to display it in correct placed/units?
It is very interesting though! I have been interested in this kind of language design for interactive UI for a while. If there was a quick article outlining how all the "with" and "on" and "own" work to more experienced developers using references to existing language features, I'd love to read it. Right now it reminds me of the declarative style of qt ui and online primitives introduced in godot, but i haven't looked at it in more details. Also love your take on async. Wish you all the best luck, this seems like a really thought through language design!