Hacker News new | past | comments | ask | show | jobs | submit login

I feel it misses a reliable take-down of the systems people. Recipe: (1) ask the person if they have evaluated some framework which would take months to evaluate; (2) suggest that their hard work reinvents the wheel; (3) step back and enjoy a smug victory.

On the odd occasion that they have evaluated the framework you named, you can simply try again a few minutes later with a different framework. If you are challenged, use condescension to imply that the victim did not try hard enough.

This tactic works even for situations where the victim has used a first-principles approach to completely demolish a problem to the satisfaction of all stakeholders. 'Reinventing the wheel' is a type of sin. The mere suggestion of it will stick like shit to a blanket.




You can attack them even if you have no idea what they are doing. Just look at the plots in the report and mumble something about "missing confidence intervals", "unrealistic workload", and "it's not even heavy tailed".


"Missing confidence intervals" is my (IMO) legit pet peeve.

People fit frighteningly complicated models with millions-to-billions of parameters. They throw in hairy regularization schemes justified by fancy math.

When it comes time to evaluate the output, however: "Our model is better because this one number is bigger than their number [once, on this one test set]."


As an undergrad, my circle had this drinking game called "Big Number." It came about because two of the biggest wastoids were the last people awake in the wee hours of Sunday, and one of them said to the other, "I'm too drunk to deal. Let's just roll dice, and the one with the biggest number drinks."

Of course, over the years, the game developed dozens of other rules.


Cool Story. Any details on more of the rules?


Confidence intervals aren't even that informative. Like using boxplots when you could inform the viewer so much more with sina plots [1]. Why not show me the whole posterior probability distribution (perhaps helpfully marking the 95% highest density region [2])? Or if you don't have a distribution, show me the 95%, 97.5% and 99.5% intervals.

[1] https://clauswilke.com/dataviz/boxplots-violins.html

[2] https://www.sciencedirect.com/topics/mathematics/highest-den...


Sure, there are better ways to actually do it; I was just riffing off the bit in the article.

It is super weird that an field devoted to doing inference somehow just...doesn't when it comes to evaluating their/our own work.


Nice comment, but you should rewrite it in Rust.


Nah man, Rust has overplayed its hand and has been turned into a meme. We need a new Rust that's exactly like the old Rust before it was cool.


Yeah, come on, write it in Nim or don't write it at all.


Nim is too simple and lacks complex mathematics.


Lisp has joined the channel


I tried Rust a while ago (I do mainly Python) but not for long enough to get my head around it (the borrow checker).

Is it now past the peak hype cycle, or do people still love it?


I learned it a while back during some huge hype and put it down for a while after slow, minor, painful success. I recently came back and it feels much improved, and my troubles with the borrow checker seem to finally be something I have overcome. I think it will continue to be loved.


There was a real improvement to the borrow checker to make it use non-lexical-lifetimes. The practical implications were the borrow checker being much better at reasoning about mutually exclusive borrows between branches.


That beginner-level Rust code made Coq barf. Rewrite your POC in Haskell before reverting back.


I always liked this quote from Alan Kay - "Reinventing the flat tire"


I have a system full of reinvented wheels to keep running (going to try and replace them with more standard solutions).

The dev has now left but he would always insist that the existing solutions didn't meet every need. There was always one feature that required him to build some over engineered version of something. "Good enough" was never an option for him.


This takes on a sinister tone in connection with interminable "which X is the best for this project" discussions. Evaluating all Xes would take infinite time because new Xes (JavaScript offshoots, Python package managers, CMSes, IDEs, build systems, you name it) are coming out faster than you can fairly evaluate them, and every person on the project has used at least one X. So the question basically boils down to

1) try Foo because of all the Xes all of us have tried it was the only one which didn't cause manic depression,

2) continue the discussion until the most ruthless/charismatic/stubborn person "wins", or

3) try new shiny Bar, because all the cool kids are using it.

I wonder if this is part of the reason so many projects go for the new shiny thing: in a group of reasonable people a lot of the time all of them will agree that all existing solutions suck.


"Not reactive enough"


"Have you tried to quantify the QoE?"




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

Search: