Live data from Hacker News

Fable Converted Pylint to Rust

pypi.org

121–122 of 122 posts

Re: Fable Converted Pylint to Rust

#121

Earlier quoted context omitted.

While I agree with your point in general, rewriting a big widely used project in a stricter language is always a good thing. It improves the dev-ex of people contributing to these projects and more importantly helps people seperate logic into silos. Python is inherently limited in which kinds of abstraction it can express.

In an open source tool, there is no value without community of contributors. The value of the discussed project is exactly zero right now in the best-case scenario . It's more likely to be negative: because there has been no contact with reality (no users have used it in production), the risk is higher than using the existing one. IOW, 1. Only after some brave souls use this in production, will the value of this proj…

I didn't suggest that this was useful.

Re: Fable Converted Pylint to Rust

#122

Earlier quoted context omitted.

A lot of programmers naively believe that tests prove that the program works... Even though this has been repeated over and over again: tests can only prove that the program isn't broken in some specific way. When there's a person in the loop, you know that the program was written intentionally. It can still be wrong, but if you were to ask the author why they wrote this or another part of the program, they'd have an…

I personally think at some complexity level almost nobody who wrote the code can tell you what's going on. E.g. TypeScript's `checker.ts`

I think you are putting the cart before the horse: the code was written intentionally, i.e. someone first had a thought, and then fleshed it out in the code (and maybe had forgotten all about it the minute later).

When LLM generates code, it also has a "thought process" of sorts. But it's very different from the one humans use. An LLM generating code may pretend to have a thought process similar to humans (when asked to elaborate on the reasons the code is this way or the other), but, fundamentally, it's going to be a lie, because the real reasons this LLM created the code in a particular way is very different, and is very hard to grasp for a human, even if they are familiar with the problem (there were some attempts at explaining LLMs "thinking" that would end up looking like heatmaps and other weird things that are useful for debugging them).

Imagine that instead of a stack trace, the program you are debugging spits out only the memory dump with values in registers etc. (the gibberish-looking part of the coredump file). You'd be in a similar situation receiving the "true" explanation from an LLM generating your code.

Post reply on HN