51–59 of 59 posts
Earlier quoted context omitted.
This. We finally have a tool that can learn from all the libraries and abstractions that have to fit everybody's needs (and do so badly because there is no free lunch), and extract just the parts that are actually relevant to our problem and domain. This allows you to not only produce a much smaller attack surface, but also allows for domain specific optimisations and shortcuts. It's kinda like project specific seman…
>This allows you to not only produce a much smaller attack surface Why does this reduce your attack surface? Can the functions in the library, unrelated to the ones you're using, be triggered by user input somehow?
Let's say you got a library to do arbitrary unicode string verification, but your code only ever works with strings of a short bounded length (e.g. 32 byte), an LLM could write you vectored verification instructions for that.
”Dunning-Kruger effect leads us to understimate the complexity of the problem solved by the library we're considering.” Invoking the smarter-than-thou effect is not a great starting point. See e.g. https://www.sciencedirect.com/science/article/abs/pii/S01602... If we’re considering a library, it would be prudent of us to take a look at the source code to see what exactly we’re pulling in. In the process, we would lea…
The Dunning-Kruger effect absolutely also leads to people releasing libraries they should not have and which nobody should use.
Earlier quoted context omitted.
I didn't get this either so let me try to explain as ChatGPT did to me: Monomorphization means taking a generic function and generating a version specific to the type being used, eg a Rust function fn identity (x: T) -> T { x } can be compiled into one version for i32 and one for String, which is more efficient since the compiler knows the types: fn identity_i32(x: i32) -> i32 { x } fn identity_string(x: String) -> S…
Nah, I found it hilarious that any LLM would have any clue what would constitute ‘well baked’ in the context, or that any of this was going to end well.
Earlier quoted context omitted.
3 million weekly downloads for a package that is “deprecated” and the source repo no longer exists. Truly insane.
Even if it wasn't deprecated this is literally ['yes', 'y', '1'].indexOf(input.toLowerCase()) !== -1 People adding a dependency to avoid writing one line of code...
I had a similar situation at a former job once, where as a subtask of some task we basically needed to implement a "partial deep copy" for a few specific classes (deep-copy some selected properties, shallow-copy the rest), which could either be implemented in ~50 lines of Java code, or by adding an extra library that provided this functionality using a domain-specific language, plus many other things, some of them potential vulnerabilities... and it took a lot of time to convince my team leader that "reinventing the wheel" is the right thing to do in this case.
"Why do you want to program something that already exists? Don't you realize that every line of code you write is a line of code someone else will have to maintain in the future?" Yeah, good points, but it's not like using a library is without costs either: you need to scan for vulnerabilities, increase versions, sometimes the API changes; in long term that is a lot of work to do just to avoid writing 50 lines of code.
Earlier quoted context omitted.
The Dunning-Kruger effect absolutely also leads to people releasing libraries they should not have and which nobody should use.
You could replace ”The Dunning—Kruger effect” with ”ignorance” and the message would stay the same without sounding like you’re trying to prove your own intellect.
>Vibe coding is more fun than reading documentation. Shit, vibe-coding can be more fun than ordinary coding. In my experience the big problem is that the documentation is always terrible, you can't ask open-ended questions on stack overflow, the library's reddit (if any) has zero users, and anything asked on their discord is not searchable. It's incredible that we still don't have a stack overflow that is just a foru…
There are some bad/missing documentations out there, but more often than not, people rush to use the library without first understanding the domain and learning the library's design. Once that's done, the generated api reference and the source code is more than enough to get going.
> learning the library's design
without solid documentation. And if I am reading the library implementation thoroughly, I might as well implement what I need myself.