jamii (u/jamii) - Readit News

jamii commented on SQL needed structure scattered-thoughts.net/wr... · Posted by u/todsacerdoti

ivanb · 6 days ago

One limitation of JSON is its limited set of types. For example, for decimal numbers one has to resort to stringly typing representation because DB connection libraries assume that JSON numbers are floating point. Note that JSON numbers are just sequences of digits, nothing more. There is no attached precision semantic.

Another example is UUIDs. Instead of transferring 16 bytes, the libraries deal with wasteful string representation. I'm sure you can bring another examples.

Nonetheless, for majority of data JSON as DB output format is alright.

jamii · 5 days ago

Yeah, json is annoying because of the limited types, but postgres arrays/rows are annoying because of the lack of sum/union types (if your UI has a heterogenous list of elements).

The OLAP world has much nicer type systems eg https://duckdb.org/docs/stable/sql/data_types/union.html.

jamii commented on Evidence that AI is destroying jobs for young people derekthompson.org/p/the-e... · Posted by u/duck

juxtaposicion · 7 days ago

I'm not sure I understand. Your model shows that different group buckets (eg 20-24yo vs 25-29yo) peak at different years (in your figure, 2022 vs 2024) despite being driven by the same dynamics. Is that expected? I (naively?) expected the same groups to rise, fall and have peaks at the same times.

jamii · 7 days ago

One of the dynamics is that people get older so they move into different buckets.

We can make the model way simpler to make it clearer. Say in 2020 we hired 1000 20-24yo, 1000 25-29yo etc and then we didn't hire anyone since then. That was five years ago, so now we have 0 20-24yo, 1000 25-29yo, 1000 30-34yo etc and 1000 retirees who don't show up in the graph.

Each individual year we hired the exact same number of people in each age bracket, and yet we still end up with fewer young people total whenever hiring goes down, because all the people that got hired during the big hiring spike are now older.

jamii commented on Evidence that AI is destroying jobs for young people derekthompson.org/p/the-e... · Posted by u/duck

jamii · 7 days ago

I made a stupid simple model where hiring in all age brackets rose slowly until 2021 and then fell slowly. That produces very similar looking graphs, because the many engineers that were hired at the peak move up the demographic curve over time. Normalizing the graph to 2022 levels, as the paper seems to do, hides the fact that the actual hiring ratios didn't change at all.

https://docs.google.com/spreadsheets/d/1z0l0rNebCTVWLk77_7HA...

jamii commented on Go allocation probe scattered-thoughts.net/wr... · Posted by u/blenderob

osigurdson · 2 months ago

>> func (thing Thing) String() string { if thing == nil { return nil } str = ... return &str }

It seems like the "..." of str = ... is the interesting part.

jamii · 2 months ago

The ... is the useful part. We actually want that string, so we can't avoid allocating it.

But the &str at the end is an additional heap allocation and causes an additional pointer hop when using the string. The only reason the function returns a pointer to a string in the first place is so that the nil check at the beginning can return nil. The calling code always checks if the result is nil and then immediately dereferences the string pointer. A better interface would be to panic if the argument is nil, or if that's too scary then:

    func (thing *Thing) String() (string, bool) {
        if thing == nil {
            return "", false
        }
        str := ...
        return str, true
    }

jamii commented on Store Tags After Payloads scattered-thoughts.net/wr... · Posted by u/todsacerdoti

jamii · 2 months ago

I'm curious if any languages other than swift do this.

jamii commented on Austral: A Systems Language with Linear Types and Capabilities (2022) borretti.me/article/intro... · Posted by u/yamrzou

conaclos · 6 months ago

An interesting design choice of Austral is the use of second-class references [0] in place of first-class references like Rust does. This makes the implementation of a borrow checker simpler at the cost of reduced expressiveness. Hylo (previously Val) [1] tries also to find a way of avoiding first-class references using value semantic and subscripts.

[0] https://borretti.me/article/second-class-references; [1] https://www.hylo-lang.org/

jamii · 6 months ago

I don't think Austral uses second-class references. Even the page you linked says:

> But is it worth it? Again, the tradeoff is expressivity vs. simplicity... Austral’s linear types and borrowing is already so simple. Austral’s equivalent of a borrow checker is ~700 lines of OCaml. The only downside of Austral is right now you have to write the lifetimes of the references you pass to functions, but I will probably implement lifetime (region) elision.

jamii commented on The program is the database is the interface scattered-thoughts.net/wr... · Posted by u/tosh

hilti · 6 months ago

What the author demonstrates here is a powerful principle that dates back to LISP's origins but remains revolutionary today: the collapse of artificial boundaries between program, data, and interface creates a more direct connection to the problem domain.

This example elegantly shows how a few dozen lines of Clojure can replace an entire accounting application. The transactions live directly in the code, the categorization rules are simple pattern matchers, and the "interface" is just printed output of the transformed data. No SQL, no UI framework, no MVC architecture - yet it solves the actual problem perfectly.

The power comes from removing indirection. In a conventional app, you have: - Data model (to represent the domain) - Storage layer (to persist the model) - Business logic (to manipulate the model) - UI (to visualize and interact)

Each boundary introduces translation costs, impedance mismatches, and maintenance burden.

In the LISP approach shown here, those boundaries disappear. The representation is the storage is the computation is the interface. And that direct connection to your problem is surprisingly empowering - it's why REPLs and notebooks have become so important for data work.

Of course, there are tradeoffs. This works beautifully for personal tools and small-team scenarios. It doesn't scale to massive collaborative systems where you need rigid interfaces between components. But I suspect many of us are solving problems that don't actually need that complexity.

I'm reminded of Greenspun's Tenth Rule: "Any sufficiently complicated program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." The irony is that by embracing LISP principles directly, you can often avoid building those complicated programs in the first place.

Rich Hickey's "Simple Made Easy" talk explores this distinction perfectly - what the industry calls "easy" (familiar tools and patterns) often creates accidental complexity. The approach shown here prioritizes simplicity over easiness, and the result speaks for itself.

jamii · 6 months ago

> it solves the actual problem perfectly

The whole post was about how that doesn't solve the problem perfectly - there is no way to interactively edit the output.

> by embracing LISP principles directly

This could just as easily have been javascript+json or erlang+bert. There's no lisp magic. The core idea in the post was just finding a way for code to edit it's own constants so that I don't need a separate datastore.

Eventually I couldn't get this working the way I wanted with clojure and I had to write a simple language from scratch to embed provenance in values - https://news.ycombinator.com/item?id=43303314.

jamii commented on The program is the database is the interface scattered-thoughts.net/wr... · Posted by u/tosh

jamii · 6 months ago

This is an old prototype. I ended up making a language for it from scratch so that I could attach provenance metadata to values, making them directly editable even when far removed from their original source.

https://www.scattered-thoughts.net/log/0027#preimp

https://x.com/sc13ts/status/1564759255198351360/video/1

I never wrote up most of that work. I still like the ideas though.

Also if I had ever finished editing this I wouldn't have buried the lede quite so much.

jamii commented on HYTRADBOI 2025 post-mortem scattered-thoughts.net/wr... · Posted by u/jamii

jamii · 6 months ago

Worth mentioning that all the talks are published at https://www.hytradboi.com/2025/#program.