mden
Joined 13 years ago
Joined 13 years ago
From https://openai.com/index/navier-stokes-solution/:
> we cannot rule out that de-identified data derived from their usage of our products helped improve our models
Not to say it was perfect, e.g. sometimes it would get temporarily stuck in a testing loop or it would test scenarios that didn't necessarily seem reasonable. But overall rather effective and capable. This was for a city building game so pre-scripted builds, even if by AI, are likely much easier to create and execute than say playing an ARPG.
It's fine to be cynical but it's also good to remember that there are real people that do care and try to improve the world as well.
That's rather amusing. "Am I wrong? No it's the rest of the world!"
How are these other frameworks so far ahead? I've used a couple of frameworks and React has been the easiest from the big ones to wrap my head around.
Maybe I'm too idealistic but why does following incentives with no regard for secondary consequences not evil?
That seems unnecessarily brutal (and untrue).
> 2,000 line long modules and 200-line methods with 3-4 if-levels are considered harmful
Sometimes, not always. Limiting file size arbitrarily is not "best practice". There are times where keeping the context in one place lowers the cognitive complexity in understanding the logic. If these functions are logically tightly related splitting them out into multiple files will likely make things worse. 2000 lines (a lot of white space and comments) isn't crazy at all for a complicated piece of business logic.
> Comments that say what the code does instead of specifying why are similarly not useful and likely to go out of date with the actual code.
I don't think this is a clear cut best practice either. A comment that explains that you set var a to parameter b is useless, but it can have utility if the "what" adds more context, which seems to be the case in this file from skimming it. There's code and there's business logic and comments can act as translation between the two without necessarily being the why.
> Gratuitous use of `nil`
Welcome to golang. `nil` for error values is standard.