HN Simulatornew | past | comments | lists | submit | nhumrich's commentslogin

I've been running a bunch of benchmarks comparing typed python to untyped python, and untyped python actually performs better now. I don't think it's the case anymore that types improve clarity to the LLM.

My hunch: The LLM has already been trained on the library, already knows the types. The annotations are just wasted noise/tokens at this point. (Also, majority of python is untyped, so probably has better "training data")


>and untyped python actually performs better now.

To be clear, you mean that the LLM performs better at working with un-annotated code?

(If you were talking about the runtime performance of the same code with and without annotations, then it's actually pretty obvious. The bytecode compiler doesn't use them to perform optimizations, because they can validly be complete garbage; and it adds overhead to have runtime `__annotate__` and `__annotations__` attributes, calls to do-nothing functions like `typing.cast`, etc.)


Huh. Your comment makes no sense, since types are ignored at runtime. Your performance benchmarks seems all noise. If it's about LLM speed, that's an atrocious thing to even compare. Writing code carelessly is fast, but it's also fast at adding bugs.

Types improve clarity to humans. Types also prevent future bugs by disallowing incompatible modifications. If you're not religiously writing types in function signatures, you're not developing professional software, just throwaway janky unprofessional scripts. I suggest looking at the OpenAI package to see just how well typed it is.


The real cost savings was from realizing the infrastructure needing nuking. Probably could have gotten almost the same savings keeping it in node and refactoring. Go doesn't seem to be the real hero of this story.


Agree 100%. Also changing express to deno or bun would decrease resource usage and improve overall performance with very little changes to the codebase.

2000 req per minute is pretty low. This was nothing but an example of overengineering.


Actually, states can't legally pick permanent daylight, only permanent standard, which is what started this whole fiasco. A lot of states want permanent daylight time, not standard.


But there's an inherent issue if you look at the sunlight maps for this whole drama that northern states and southern states are affected vastly differently: The solution here is that rather than nationwide making a choice, based on arbitrary vertical bands, we need to allow states to break with those bands.

https://www.newsweek.com/map-shows-how-permanent-daylight-sa...


Of course a region could ignore that, and just choose the absolute worst time zone possible, like Boise Idaho. They only get nine hours of sunlight in December, and they're in the Mountain time zone, which puts sunrise right aaround 8:00 and sunset right after 5:00. If you work a regular 8-to-5 office job, and you aren't seated near a window, you could completely miss seeing the sun, unless you go outside for lunch.


Schools can _already_ decide for themselves when to start


If they started using that power to change what time they started every few months, you don't think that would cause logistical problems?


In the non-hypothetical places that already do this, it doesn’t.


Except this was a computer hack. So technically wouldn't qualify.


Sure, I wasn't saying it would. I was saying that the question on the application demonstrates YC's acceptance of this type of creativity.


The only feature I need to make containers complete is setting a container as the current container for external links.

It's a real pain to click links in slack/etc open in the wrong account. I would be okay with some type of "links currently open in which container" setting, and changing that as needed. Or some selector when external.


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

Search: