Comments URL: https://news.ycombinator.com/item?id=47256533

Points: 2

# Comments: 1

I will say, that I'm trying to steelman the code-as-assembly POV, and I dont think the exact historical analogy is critical to it being right or wrong. The main thing is that "we've seen the level of abstraction go up before, and people complained, but this is no different" is the crux. In that sense, a folk history is fine as long as the pattern is real

Comments URL: https://news.ycombinator.com/item?id=46955747

Points: 32

# Comments: 7

First, hardware engineers are dealing with the same laws of physics every time. Materials have known properties etc.

Software: there are few laws of physics (mostly performance and asymptotic complexity). Most software isnt anywhere near those boundaries so you get to pretend they dont exist. If you get to invent your own physics each time, yeah the process is going to look very different.

Think about it, if all reasoning is post-hoc rationalization, reasons are useless. Imagine a mentally ill person on the street yelling at you as you pass by: you're going to ignore those noises, not try to interpret their meaning and let them influence your beliefs.

This theory is too cynical. The real answer has got to have some element of "reasoning is useful because it somehow improves our predictions about the world"

That's why it's common advice to turn off MCPs for tools you dont think are relevant to the task at hand.

The idea behind skills us that they're progressively unlocked: they only take up a short description in the context, relying on the agent to expand things if it feels it's relevant.

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 $13 trillion US mortgage industry into a set of APIs.

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

If you like:

- Programming languages

- Functional or Logic programming

- Operations research & optimization

- Working on an amazing team on a really hard problem

Come join us!

You do it when you have a bunch of automated integrations with you and you have to break them. The lights arent on at the client: their dev teams are focused on other things, so you have to wake them up to a change that's happening (either by causing their alerting to go off, or their customers to complain because their site is broken)

I am imagining all these overpaid founders etc just sitting in a room like reality show contestants. Trying to make smalltalk, brainstorm jamming for months, not really producing much because... who cares, they have unbelievable money and this is the weirdest scenario ever.

I meant support in terms of there's an active community of people using the language and building things with it. It's not going to die as a language like Algol 68 or Pascal.

But even that's too far really. Like it or not, "shiny fad" languages like Python & Javascript have been around forever, support for them isn't going away, this should be a non-concern at the architectural level. (Bigger language concerns: is it performant enough for my expected use? Does it have strong types to help with correctness? Can I hire programmers who know it? etc)

This is missing the lesson of the Yoneda Lemma: symbols are uniquely identified by their relationships with other symbols. If those relationships are represented in text, then in principle they can be inferred and navigated by an LLM.

Some relationships are not represented well in text: tacit knowledge like how hard to twist a bottle cap to get it to come off, etc. We aren't capturing those relationships between all your individual muscles and your brain well in language, so an LLM will miss them or have very approximate versions of them, but... that's always been the problem with tacit knowledge: it's the exact kind of knowledge that's hard to communicate!

Yes, this is 100% correct. Type systems are just another language

> The same propensity for human error exists there as well.

This is where I disagree. Sure you can make errors in types, but it's not the same because strong type systems are more like proof systems. They tell you when you've encoded something that doesnt make logical sense. And they help you figure out if your code can be made to adhere to them. It's a checker that you don't normally have.

> But I don't see much difference in putting that logic in the base language or the higher order type system language, except the base language is more expressive and flexible.

The type language encodes your assumptions, and the base language has to adhere to those assumptions. If your type language is expressive enough, you can encode pretty complex assumptions. There's value in having the two playing against each other.

Similar to tests: you could say tests are just re-stating what you've already written in your code. In reality, it's another check for consistency with your original intention.

Just get good!

Your job as a programmer is to think through the domain logic, find the right abstractions to represent that logic, and then tell the computer to enforce those abstractions for you. Punting business logic to "it's all messy, type systems can't be used to model it" is just saying "I cant take the time to find the right abstractions, sorry"