habitue

I was really hoping this was going to explain some big issue with Larry's seemingly reasonable meeting policies. Turns out a few people kinda messed with it a few times?

This is about the speed with which the compiler can advise an LLM that a particular thing checks or doesn't check. Typescript is much slower than Go

Pylon (https://pylonlending.com) | ONSITE Menlo Park, CA

What Stripe did for payments, Pylon is doing for the mortgage industry: We're taking a sleepy industry with backward technology and re-building the stack from the ground up. We're first-principles thinkers, and our team is small, talented and ambitious.

I'm hiring generalists who love coding and want to build something beautiful in an industry where technology written in the 90s is the norm. We're Series A, well funded, and we have traction with customers. Come to Menlo Park and help us turn the $2 trillion US mortgage industry into a set of APIs.

I've been commenting on HN since 2009, if you apply through this link, I'll personally reply to your app:

https://jobs.ashbyhq.com/pylon?utm_source=hn-whos-hiring

If you like:

- Programming languages

- Operations research & optimization

- Building things the right way

Come join us!

People are on here arguing that terraform is code, actually. Sure it is, but it's not a good general purpose programming language. It is a config language that grew some features from general purpose languages. It's clearly more pleasant to write that config in a real language

Uh, like managing people who are difficult out is part of managing a team. A company has no obligation to keep people on who are difficult.

Yeah, like come on. Amazon kills things when they're truly truly unpopular, and does everything they can to grandfather paying customers on legacy offerings.

Google kills off things that are a maintenance burden for them, they dont care who is using it.

Amazon has their pathologies, but killing off beloved services isn't really one of them

Apparently, this article was written almost exactly a year and a half ago so... I guess the author is forgiven!

I think I'd say "it's hard, and would require making some opinionated decisions as to what to convert something to" vs "not possible". The bar is pretty high for "not possible"

This kind of "LLMs don't really do anything, it's all a trick" / "they're stochastic parrots" argument was kind of maybe defensible a year and a half ago. At this point, if you're making these arguments you're willfuly ignorant of what is happening.

LLMs write code, today, that works. They solve hard PhD level questions, today.

There is no trick. If anything, it's clear they haven't found a trick and are mostly brute forcing the intelligence they have. They're using unbelievable amounts of compute and are getting close to human level. Clearly humans still have some tricks that LLMs dont have yet, but that doesn't diminish what they can objectively do.

This immediately suggests what you want is a gradual migration process from one language through several intermediate languages to your target language.

i.e. instead of a big bang C++ -> Carbon migration, instead you want something like:

C++ -> C+++ -> Carbon-- -> Carbon -> Carbon++ -> Rust

(Basically fake names for more gradual transitional intermediate languages, assuming Google would like to have everything in Rust eventually.)

The key idea of "targeting automated migrations" makes this kind of thing feasible

The "good engineers are right a lot" is true, but it feels bad to say.

Why does it feel bad? Everyone wants to be right more often. All else equal, we'd like the people we work with to be right more often than wrong.

Here are some statements that don't feel as bad to say for some reason (not endorsing these per se, just they dont feel bad to say):

- good engineers are pleasant to work with

- good engineers are practical

- good engineers know a lot about engineering

Here are some statements that start to feel weirder to me:

- good engineers have high IQs

- good engineers are uncompromising

- good engineers know that lisp is the best language

- good engineers are right a lot

Maybe it has something to do with the ratio of how easy it is to verify the property, with how hard it is to embody the property once you hear about it.

Having a high IQ is kinda hard to verify directly. If that was a widely known phrase, everyone would just claim they had the high IQ. Same with being right: you can just claim you're right a lot. Being uncompromising is easy, just don't compromise.

Being practical is hard to do, but maybe is easy to claim? Maybe it's easier to verify if someone is practical than if someone is smart. Not sure. Being pleasant tonwork woth is hard work maybe? Maybe there's just a social confluence bias.

It's one study, on mice. This is the beginning of a long chain where more studies are done -> a consensus is formed -> doctors start to hear about the consensus and take it into account prescribing it

It could plausibly be 20 years before that plays out

This was actually pioneered by Bruce Willis. He would get paid a lot to show up in a couple of introductory scenes for really low budget films. They'd put his face on the movie poster, they'd pay him like half the budget of the film, then he'd move on to the next one.

(Unfortunately, it turns out he was struggling with dementia and it seems he was trying to cash out before he couldn't act at all)

This seems obvious, but you're forgetting the inputs may actually have low entropy to begin with. Lossy compression is non-reversible, but usually the expectation is that we don't care about the parts we lost.

How might this cash out with recursive LLMs? Generalizing is very similar to compression: imagine recovering the Schrodinger equation from lots of noisy physical experiments. You might imagine that an LLM could output a set of somewhat general models from real data, and training it on data generated from those models generalizes further in future passes until maybe it caps out at the lowest entropy model (a theory of everything?)

It doesn't seem like it actually works that way with current models, but it isn't a foregone conclusion at the mathematical level at least.

I see your point for one part, which is that `select([id]).from(Users)` is maybe in the best case as readable as `select id from users`, and in many common cases it'll be less readable than sql. Plus, it's not quite sql, you'll have to look up how to do things a lot of times.

But we aren't just talking about SQL the high level language that you might execute when you are poking the data live. In a web app dynamically constructing sql, we have multiple issues:

1. Deserialization: we need to know what the query returns and plug it into data structures we want to use in our program

2. SQL is dynamically typed, and if you construct queries dynamically you're even more dynamically up a creek. Maybe even "sql injection vulnerability" up a creek.

1 and 2 are solved by strongly typed query builders like this: the type system has a proof that the ways you will construct queries in your program actually result in valid sql queries and that they return the right data shape.

It's actually solving a real problem

Preordered https://forgekeyboard.com/

We'll see if I can actually use it!

The issue you're running into is that to run docker on mac, you have to run it in a vm. Docker is fundamentally a linux technology, so first emulate x86_64 linux, then run the container. That's going to be slow.

There are native macos containers, but they arent very popular

So, we should build more compilers. The only limiting factor, I think, is that it's damn hard to design a good DSL that wraps your domain well and is neither too flexible (increasing boilerplate) nor too rigid (increasing workarounds and escape hatch usage).

But generically, a compiler is the exact kind of thing you want when you're doing "Take this data structure and transform it into this other data structure". In a traditional compiler, we usually deserialize the first data structure from a string (parsing), call that data structure a CST, validate the data structure (syntax & type checking), do the transform, then serialize the output.

This kind of validate and transform pattern is all over programming though. And it's pretty easy to test with things like property tests. So yeah, we should build little compilers more as abstraction boundaries in our code.

I took the article as being aimed at domain specific languages. Kmett's lens library is just such a DSL

The ironic thing about the chimp story is that probably chimps are immune to the problem and humans are the only species that would fall for it. It takes chimps a long time to learn to copy others. I doubt they could sustain a superstition like this for long even if you managed to induce it through great effort.

It's humans that copy each other without a second thought. It's a great heuristic on average. These kinds of fables are correctives against our first instinct to replicate other's behaviors, but if we actually tried to reason through everything from first principles we'd never get anything done.

Copying is the plain pieces in the lucky charms, thinking things through is the marshmallows.

Dude, this is an amazing comment. Really points out how it looks when someone us ahead of their time:

  - awkward groping for how to explain things
  - none of the words match how we talk about things now

Algol-68 was clearly so ahead of its time, it's hard to understand anything they're saying. They're in outer space

> If we think of mitochondria as non-living organelles, how will we ever harness their full potential?

"Alive" is a fuzzy boundary in concept space that helps humans navigate a fractally complex world. It's not a fact about mitochondria that either hides or reveals structure. We can harness the potential of viruses, and reasonable people can disagree on whether they are alive.

> You can't really have it both ways.

Oh you totally can, you just have to give up consistency

I mean, I'm aware of the downsides, the OP asked why someone might use it. Ease of use seems like a reasonable upside

I imagine for streaming tools like these it's pretty convenient. You don't have to manage buffers etc, just write code against a massive string and haskell takes care of streaming it for you and pulling in more data when needed.

There are libraries that handle it, but they probably have weird types, you can just use functions in the prelude to write a lot of these basic utilities.

Seems like this is just pointing out exploration/exploitation tradeoffs. I don't see how 80/20 has much to do with this.

Yeah, I think it would. I think if we coudl seamlessly transmit thought from one person to another in full fidelity, we would be less smart. Abstraction results from boiling out unnecessary parts and retaining the essence of something. If you have a very high bandwidth connection (unlike language) you dont need to abstract as much and I would guess humans wouldnt be as advanced as they are.

> Many times the very act of trying to communicate a thought colors/corrupts the main point and gives only one perspective or a snapshot of the overall thought. There's a reason why they say a picture is worth a thousand words.

Yeah! Sometimes the thought isnt compressible and language doesnt help. But a lot of times it is, and it does

Language may not be essential for thought, (most of us have the experience of an idea occurring to us that we struggle to put into words), but language acts as a regularization mechanism on thoughts.

Serializing much higher dimensional freeform thoughts into language is a very lossy process, and this kinda ensures that mostly only the core bits get translated. Think of times when someone gets an idea you're trying to convey, but you realize they're missing some critical context you forgot to share. It takes some activation energy to add that bit of context, so if it seems like they mostly get what you're saying, you skip it. Over time, transferring ideas from one person to the next, they tend towards a very compressed form because language is expensive.

This process also works on your own thoughts. Thinking out loud performs a similar role, it compresses the hell out of the thought or else it remains inexpressible. Now imagine repeated stages of compressing through language, allowing ideas to form from that compressed form, and then compressing those ideas in turn. It's a bit of a recursive process and language is in the middle of it.

I want more physical devices like this with knobs and switches. Too many things are smooth glass rectangles