| ▲ | danielvaughn a day ago |
| In addition, I think token efficiency will continue to be a problem. So you could imagine very terse programming languages that are roughly readable for a human, but optimized to be read by LLMs. |
|
| ▲ | Insanity a day ago | parent | next [-] |
| That's an interesting idea. But IMO the real 'token saver' isn't in the language keywords but it's in the naming of things like variables, classes, etc. There are languages that are already pretty sparse with keywords. e.g in Go you can write 'func main() string', no need to define that it's public, or static etc. So combining a less verbose language with 'codegolfing' the variables might be enough. |
| |
| ▲ | danielvaughn 21 hours ago | parent | next [-] | | I'm not an expert in LLMs, but I don't think character length matters. Text is deterministically tokenized into byte sequences before being fed as context to the LLM, so in theory `mySuperLongVariableName` uses the same number of tokens as `a`. Happy to be corrected here. | | | |
| ▲ | coderenegade 18 hours ago | parent | prev | next [-] | | You're more likely to save tokens in the architecture than the language. A clean, extensible architecture will communicate intent more clearly, require fewer searches through the codebase, and take up less of the context window. | |
| ▲ | gf000 a day ago | parent | prev [-] | | Go is one of the most verbose mainstream programming languages, so that's a pretty terrible example. | | |
| ▲ | Insanity 21 hours ago | parent | next [-] | | Maybe not a perfect example but it’s more lightweight than Java at least haha | | |
| ▲ | gf000 21 hours ago | parent [-] | | If by lightweight you mean verbosity, then absolutely no. In go every third line is a noisy if err check. |
| |
| ▲ | giancarlostoro 21 hours ago | parent | prev | next [-] | | To you maybe, but Go is running a large amount of internet infrastructure today. | | |
| ▲ | gf000 21 hours ago | parent [-] | | How does that relate to Go being a verbose language? | | |
| ▲ | giancarlostoro 21 hours ago | parent [-] | | Its not verbose to some of us. It is explicit in what it does, meaning I don't have to wonder if there's syntatic sugar hiding intent. Drastically more minimal than equivalent code in other languages. | | |
| ▲ | gf000 20 hours ago | parent [-] | | Verbosity is an objective metric. Code readability is another, correlating one, but this is more subjective. To me go scores pretty low here - code flow would be readable were it not for the huge amount of noise you get from error "handling" (it is mostly just syntactic ceremony, often failing to properly handle the error case, and people are desensitized to these blocks so code review are more likely to miss these). For function signatures, they made it terser - in my subjective opinion - at the expense of readability. There were two very mainstream schools of thought with relation to type signature syntax, `type ident` and `ident : type`. Go opted for a third one that is unfamiliar to both bases, while not even having the benefits of the second syntax (e.g. easy type syntax, subjective but that : helps the eye "pattern match" these expressions). | | |
| ▲ | giancarlostoro 20 hours ago | parent [-] | | Every time I hear complaints about error handling, I wonder if people have next to no try catch blocks or if they just do magic to hide that detail away in other languages? Because I still have to do error handling in other languages roughly the same? Am I missing something? | | |
| ▲ | gf000 11 hours ago | parent | next [-] | | Exceptions travel up the stack on their own. Given that most error cases can't be handled immediately locally (otherwise it would be handled already and not return an error), but higher up (e.g. a web server deciding to return an error code) exceptions will save you a lot of boilerplate, you only have the throw at the source and the catch at the handler. Meanwhile Go will have some boilerplate at every single level Errors as values can be made ergonomic, there is the FP-heavy monadic solution with `do`, or just some macro like Rust. Go has none of these. | |
| ▲ | thunky 18 hours ago | parent | prev | next [-] | | Lots of non-go code out there on the Internet if you ever decide you want to take a look. | |
| ▲ | politician 18 hours ago | parent | prev [-] | | You’re not missing anything. I’ve worked with many developers that are clueless about error handling; who treat it as a mostly optional side quest. It’s not surprising that folks sees the explicit error handling in Go as a grotesque interruption of the happy path. | | |
| ▲ | jurgenburgen 9 hours ago | parent [-] | | That’s a pretty defensive take. You don’t have to hate Go to agree that Rust’s `?` operator is much nicer when all you want to do is propagate the error. |
|
|
|
|
|
| |
| ▲ | LtWorf a day ago | parent | prev [-] | | Well LLMs are made to be extremely verbose so it's a good match! | | |
| ▲ | nineteen999 21 hours ago | parent [-] | | I think there's a huge range here - ChatGPT to me seems extra verbose on the web version, but when running with Codex it seems extra terse. Claude seems more consistently _concise_ to me, both in web and cli versions.
But who knows, after 12 months of stuff it could be me who is hallucinating... |
|
|
|
|
| ▲ | idiotsecant a day ago | parent | prev [-] |
| I think I remember seeing research right here on HN that terse languages don't actually help all that much |
| |
| ▲ | thomasmg a day ago | parent [-] | | I would be very interested in this research... I'm trying to write a language that is simple and concise like Python, but fast and statically typed. My gutfeeling is that more concise than Python (J, K, or some code golfing language) is bad for readability, but so is the verbosity of Rust, Zig, Java. | | |
|
