habitue

[flagged]

I'm no Musk fanboy but I think this kind of maximally cynical take is tiresome. They thought it would work, they expended significant engineering effort and money making it real and producing it and selling it to customers.

The simplest explanation is that they did all that and the market didn't want it. The economics of traditional panels outweighed the aesthetic advantages of tiles and they're pivoting. No conspiracy or fraud need be invoked.

I am confused about why Gary Marcus thinks it's so obvious that Claude isn't conscious. As he points out, Dawkins is just taking a bog-standard behaviorist position: that he can't distinguish Claude from a conscious being just by the behavior here.

Marcus is saying "Well, if you knew they were trained to mimic, then you'd understand it's just mimicry and not real consciousness" The problem with this argument is that we just don't have a good idea what "real consciousness" is. What if, in order to simulate human text prediction with sufficient accuracy, the model has to assemble sub-networks internally into something equivalent to a conscious mind? We could disprove that kind of thing really quickly if we knew how to define consciousness really well, but we kinda don't!

Philosophers are genuinely split on this question, it's totally reasonable to be on either side of this based on your personal intuition. Marcus's position seems to be actually based on his own personal incredulity, despite his claims that understanding LLM training methodology gives him some special insight into the internal experience (or lack thereof) of an LLM.

(The Claude Delusion is a banger title though)

The first edition is expensive. The current edition is ~$90 for a full color hardcover (expensive but not ruinius if you really want it)

Sometimes, in the interest of having something rather than nothing, I have to press publish. This entails getting things wrong, which is regrettable.

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

This is an interesting distinction, but it ignores the reasons software engineers do that.

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.

This just doesn't explain things by itself. It doesn't explain why humans would care about reasoning in the first place. It's like explaining all life as parasitic while ignoring where the hosts get their energy from.

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"

...and will also have a deeper understanding of the problem that will help solving other problems down the line?

Skills wont use less context once invoked, the point is that MCP in particular frontloads a bunch of stuff into your context on the entire api surface area. So even if it doesn't invoke the mcp, it's costing you.

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.

These kinds of tools should be standard in understanding code

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 $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!

I mean, bcachefs is basically the equivalent of rewriting all that code, without explicitly trying to be a clone. Same for btrfs

I think Co-* is probably better, though more obscure I guess

We did this at stripe when deprecating TLS 1.0, and called it a brown out (I don't know the origin of the term in software).

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)

There has to be adverse selection here from the amount of money being offered right? Like ok, very few people could turn it down, but it's not going to result in a motivated team.

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.

Maybe chess was wrong, it's adversarial. But there's definitely a qualitative leap between "adversary withing defined rules in a particular context" and "anything is on the table, they could kill you etc." kind of adversary

I mean C89 has no support, it's not getting an update or a bugfix, the standard is what it is. So if vendor support is your overriding concern, you should be constantly updating your software to LTS versions.

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.

Started watching, but "C89 is the safe option for long lived software" kind of turned me off. There are plenty of safe long lived stable languages out there where you dont have to manually manipulate memory. At the very least, this guy should be advocating for Java.

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)

Symbols, by definition, only represent a thing.

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!

by encoding more and more responsibility in the type system, you're just pushing your business logic to a different language

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.

Basically, this article is saying "modelling your domain logic in a type system is hard" and suggests wimping out.

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"

Pylon (https://pylonlending.com) | ONSITE Menlo Park / San Francisco, 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 or SF 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!

Pylon (https://pylonlending.com) | ONSITE Menlo Park, San Francisco, 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 or SF 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!

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!

Continue to be happy to have deleted windows from all my computers, including for gaming. There are issues with closed source OSs in general, but microsoft has continually shown that they make bad decisions and just aren't trustworthy.

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.