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

Even some of the things that people think are just broken in LLMs are common in children, e.g. repeating things (getting stuck in a loop) or their inability to understand humour.

The good old "kilogram of steel" test is something that the children, the mentally infirm and the less capable LLMs all fail in the same way.

Some failures like that are simply human failures reproduced faithfully. Some are rooted deeper than that.

And yes, it's true that children don't get bored in the same way adults do, which often leads to repetitive behavior. Boredom is an important heuristic for behavior, it seems.


> repetitive behavior

I mean literally saying the same thing again and again. Like "And then I played and then I played and then I played and then I played..."


Yes, including that. It's just the small version of the thing LLMs are prone to.

A lot of LLM behaviors are self-reinforcing across context, and this includes small stupid loops and the more elaborate variants. Like an LLM making a reasoning mistake, catching it while checking itself, and then making it again, 5 times in a row.


Python is actually kind of awkward for this use case since you can't import from other files easily unless you are in a proper Python package, which isn't usually the case for everyday scripting.

Lol what.

Python lets you dynamically import from anywhere. The syntax is a bit funky, but thats what llms are for.


No it doesn't. You can't do something like `import ../../foo/bar`. You can mess around with PYTHONPATH and importlib to work around that but that's a horrible hack that also breaks all tooling. Not a good idea.

With Deno you can just import by relative file path and it just works like you'd expect and the tools support it. I wish more languages worked like that.


> You can't do something like `import ../../foo/bar`.

https://docs.python.org/3/reference/import.html#relativeimpo...

You'd use:

  import ...foo.bar

It also has poor support for Windows.

The best option I've found for this use case (ad-hoc scripting with third party dependencies) is Deno.

I'm hoping Rust will get there in the end too.


Well, the reason is you can stop using Bash. If you never write Bash scripts already then you probably don't need it (and also congratulations on doing things right), but most people at least have lazy colleagues that write shell scripts. One day I'd like them to be not awful.

Nonsense, unless you think the entire field of PL research is doing nothing. The industry learns things and gradually improves, on average.

Do you still write FORTRAN and Perl?


Nobody is marketing it. It doesn't have a marketing budget. What you're seeing are lots of people that really like it because it's really good. Not flawless obviously but a significant improvement on C and C++.

I see a lot of activity of very specific parts of the industry promoting it. But also enthusiasts doing aggressive marketing are doing aggressive marketing - even if they do not have a budget. Whether it is an improvement is debatable. From my perspective, it is an improvement in some aspects and a significant step back in others. What is unacceptable though is the significant hate and pressure towards people who have other priorities and preferences, which is created by the "we must stamp out memory safety issues at all cost and Rust is the solution" narrative.

> Whether it is an improvement is debatable.

Not really.

> it is an improvement in some aspects and a significant step back in others

Of course. Very few improvements are better in every way. There's always something you can find to like about the old solution. Horses are friendlier than cars. Records allow bigger artwork than CDs. Unlike DVDs (at first anyway) you can write to VHS. Unlike Typescript, Javascript doesn't need a compile step. FORTRAN77 fits nicely on punch cards.

That doesn't mean there's really any serious debate about them being improvements.

I will freely admit that Rust has only average compile time (though it's better than C++ at this point), high complexity, and async Rust is full of footguns. But I could come up with a much longer list of complaints for C.

> we must stamp out memory safety issues at all cost and Rust is the solution

Yeah I think memory safety is actually probably not the most important thing about Rust. Having a modern strong type system is arguably more significant. Memory safety is important too of course - even if you don't care about security memory safety issues are often plain hard to debug bugs.


It's pretty settled now.

> Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken. That means that the machine code cannot be 100% branch tested, which is an important component of SQLite's quality strategy.

I don't think they thought about this too much. In the C code are they testing the "branch" into Undefined Behaviour?


At least for the foreseeable future (next 50 years say).

I looked into quantum inertial navigation a while ago because I wanted to understand - is it some weird quantum thing where they eliminate all accumulated error or not. As far as I could tell the answer is "not" - it's just a very very precise way of measuring acceleration.

Seems kind of hard to imagine that any accelerometer can be so precise you can use dead reckoning to the centimeter over a long time scale. Especially given how strong acceleration due to gravity is.


It's pretty clear from other articles the answer is not. Although from what I can see it claims to be about 50 times better than conventional methods. One claim is they tracked a plane to within a few hundreds meters for a 300 mile flight. Which is technically impressive but entirely useless for the stated purpose in this article.

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

Search: