Hacker Newsnew | past | comments | ask | show | jobs | submit | t14n's commentslogin

fwiw there's a project doing just that: https://github.com/tursodatabase/turso

they have a blog hinting at some answers as to "why": https://turso.tech/blog/introducing-limbo-a-complete-rewrite...


fwiw this problem already exists with my more junior co-workers. and also my own code that I write when exhausted!

if you have trusted processes for review and aren't always rushing out changes without triple checking your work (plus a review from another set of eyes), then I think you catch a lot of the subtler bugs that are emitted from an LLM.


Yes, code review can catch these things. But code review for more complex issues works better when the submitter can walk the reviewers through the design and explain the details (sometimes the reviewers will catch a flaw in the submitter's reasoning before they spot the issue in the code: it can become clearer that the developer didn't adequately understand the spec or the problem to be solved). If an LLM produced it, a rigorous process will take longer, which reduces the value of using the LLM in the first place.


+1

there are a million million subcultures with pretty stark differences in taste/aesthetics that you can dig up on the internet. looking at what's grossing in mega-dense populations of millions of people then yeah, perhaps in aggregate at large N, things their individuality -- surprise?

there are parts of every major city that feel the same, but if you're willing to take a train out 45 minutes in any direction without google maps, i'm willing to bet you get into spaces that are incredibly local!


There are some OS specific files (unix.rx, windows.rs, etc) that you can discount (imo).

If you really wanted to codegolf the repo, I'm sure you can make it literally <1024 lines.


A new-ish field of "mechanistic interpretability" is trying to poke at weights and activations and find human-interpretable ideas w/in them. Making lots of progress lately, and there are some folks trying to apply ideas from the field to Alphafold 2. There are hopes of learning the ideas about biology/molecular interactions that the model has "discovered".

Perhaps we're in an early stage of Ted Chiang's story "The Evolution of Human Science", where AIs have largely taken over scientific research and a field of "meta-science" developed where humans translate AI research into more human-interpretable artifacts.


I'd upvote this twice if I could. Young male here and dating is rough; most of my friends are male and single...

But I find it a little ungenerous to interpret that young women are dating men who are cheating. I think it's more likely the case that single women who are in their 20s are willing to date men in their 30s, and so if you have to choose between a 23 year old who just graduated or a 33 year old well established in their career...

Just my guess. And copium.


I don't mean to say they are cheating. I'm saying, in my experience, a lot of 'dating' nowadays in Gen Z is ambiguous. Zoomers call them 'situationships'.

Basically they're dating for a while and having sex, but never have a conversation about exclusivity or 'making it official'.

So in such a situation, one side might be under the impression they are 'boyfriend/girlfriend' because they are seeing each other frequently for months, having sex and so on, but the other side might think they're still just 'casually dating' and assume they're both free to play the field/'date around' still.

So it's not necessarily cheating. There's ambiguity/poor communication skills and one side thinks they're in a serious relationship, while the other thinks it's casual and therefore is seeing other people.


I like the sentiment of the title, even if it gets people riled up. I'm fondly reminded of the introduction from Bob Nystrom's _Crafting Interpreter_ [1]

> This last reason is hard for me to admit, because it’s so close to my heart. Ever since I learned to program as a kid, I felt there was something magical about languages. When I first tapped out BASIC programs one key at a time I couldn’t conceive how BASIC itself was made.

> Later, the mixture of awe and terror on my college friends’ faces when talking about their compilers class was enough to convince me language hackers were a different breed of human—some sort of wizards granted privileged access to arcane arts.

> It’s a charming image, but it has a darker side. I didn’t feel like a wizard, so I was left thinking I lacked some inborn quality necessary to join the cabal. Though I’ve been fascinated by languages ever since I doodled made-up keywords in my school notebook, it took me decades to muster the courage to try to really learn them. That “magical” quality, that sense of exclusivity, excluded me.

> And its practitioners don’t hesitate to play up this image. Two of the seminal texts on programming languages feature a dragon and a wizard on their covers.

> When I did finally start cobbling together my own little interpreters, I quickly learned that, of course, there is no magic at all. It’s just code, and the people who hack on languages are just people.

> There are a few techniques you don’t often encounter outside of languages, and some parts are a little difficult. But not more difficult than other obstacles you’ve overcome. My hope is that if you’ve felt intimidated by languages and this book helps you overcome that fear, maybe I’ll leave you just a tiny bit braver than you were before.

1: https://craftinginterpreters.com/


Hrm. It seems like the authors are caught up in things like "vividness" score and the "sentiment analysis" of the text; I guess because it's loosely related to AI?

But it seems like a bulk of the stats collected are things that I would find really useful. I've probably asked myself, "how many words are in this book" on 10+ separate occasions, both as a reader and as a writer.

It also seems like there were also counts of things like adjectives, verbs, adverbs, passive verbs, etc -- stats that I might want to know about a novel.

The bulk of the service seems rather "boring" and non-AI. Unfortunate that the whole thing was taken down because of a few features. Hopefully it'll come back.


Yes, human labor is critical for subsistence. But let's look at how many people are employed by industry in the US: https://www.bls.gov/emp/tables/employment-by-major-industry-...

About 2% of people in the US work in agriculture/forestry/animal handling/etc. If you include transportation workers, that's still about 5% of US workers. And if you include wholesale workers and utilities workers -- that's still < 10% of the US population.

All of this work is critical and necessary (to your point). But I think the BLS data is evidence toward OP's point that we've automated and optimized a lot of the work necessary for subsistence.


Using the USA as an example of labor distribution in this regard is disingenuous. Like most leading countries, we are supported by an external labor class operating extremely cheaply and exporting critical goods into our system. Agriculture work in the USA would be much more prevalent if 13% of the Mexican population wasn't directly involved in agriculture. In fact ~78% of Mexico's exports go to the USA. Its a vassal state, supplying the USA with cheap and largely unregulated human labor critical for our subsistence. You say we optimized our work, I say we imported $40 Billion in food from China last year.


I think you have to include a lot of "Retail Trade" and/or "Leisure and Hospitality" in those numbers, though I'm not sure where grocery and food service workers fall exactly. Meat packing, prepared foods, etc are a lot more manual than agriculture itself. Most people do not want to eat raw field corn/wheat/soybeans.


It's not some magical automation though. The farmers, in order to be that efficient, need constant input of fuel and fertilizers and pesticides and machines (as they break down and wear out). Digging deeper, they also need financial and physical infrastructure and basically very many components of our advanced civilization, or they wouldn't achieve anywhere near the efficiency they have now.


https://tommynguyen.dev/

Not too many interesting technical or SWE related posts though. I mostly use it as a scratchpad for ideas and non-tech things I'm thinking about (probably write enough about technical topics at work!)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: