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

Well, Mr. BuzzKillington(!), I’d disagree. I’d argue that fast thought to code ratio would give you wings! Surely you’ll type bugs in faster (valid point) but you’ll fix those also as fast! Overall development progress is incomparable.





I mean you do you man, but I've definitely spent an hour and a half on 1 line of code to make it fully vectorised instead of doing things the easy fast way iterating over the data and that code could run orders of magnitude faster than the fast way of coding.

I remember once in undergrad we had a particularly gnarly computation problem to tackle. Some people's code ran as long as 40 minutes. Most were around the 10-15 minute mark. A few were in the 4-5 minute range.

Mine ran in 50 seconds. No one else came even close.

Now, I get that that's not always required. For a one off calculation, it makes no sense to spend 3 hours of developer time to save 1 hour. But if you have to run it 10, 100, 1000 times it starts to make a lot of sense.

I can hack together a convoluted piece of shit pretty quick. No design doc, documentation, design elements that would give me flexibility or error checking. There are always compromises, but I just find it's extremely rare that my typing speed is the limiting factor. It always seems like spending a bit more time thinking about design saves me time in the end.

Maybe you're John Von Neumann or something but like I said, I'm just pretty skeptical.


I'm curious how you approach writing such performant code. Did you start with the crappy/easy way and then just refactor until it was in a state that you liked?

Maybe its easier to specifically describe the code/problem?


Hmmm... yeah so it does tend to depend a lot on what's going on. I'll try my best to answer though at a very high level.

For the best speedups, refactoring crappy code isn't going to cut it. It WILL still result in some nice performance boosts, and it's a good way to code in general. But when performance is absolutely essential, you're probably going to have to completely redesign from the ground up.

Mostly it seems like it just comes down to focusing on the parts that are going to take the vast majority of time and then just thinking very, very deeply about the problem you need to solve in that chunk. (Including asking if you're solving the right problem!) and what each and every function call or operation does, and trying to be as smart as you possibly can. Some fairly subtle things here working with intrinsic libraries can sometimes do some really stupid things behind the scenes that are hard to spot. Be careful to avoid any extra steps that are unnecessary, where data might get copied in memory unnecessarily or things like that.

Most of the time for the real speedups, I was writing my own libraries in Fortran that were custom tailored to the problem I was trying to solve. This is important because you might find some weird data validation being done or something that isn't relevant to your pipeline, but is included for generality.

There's certainly no magic bullet, but the most important is thinking hard about your problem, make sure you're solving the right one and the next most important thing is probably custom tailoring the libraries if you have time. ...assuming it's a problem that isn't so well solved. Sometimes that can be a waste of time of course, because your use case isn't so unusual.


Haha “you do you man” - hilarious! Read my “note:” in original comment. My whole point is a better human vs IDE I/O throughput. Can’t imagine this improvement can be any bad? Process stays the same, some aspects get significant improvement, that’s it

EDIT: also how many times in your career you had a problem where you had to make a significant and time consuming effort over that one line of code (other than hackathons, of course). With practically all high-level langs in modern collaborative environments readability is prioritized. “I should be able to read your code as a well written prose” - uncle Bob’s statement, is pretty much universal doctrine. Ability to type fast here is greatly underestimated


>With practically all high-level langs in modern collaborative environments readability is prioritized.

Readability and verbosity are two different things. I can see how someone using Java would think that typing faster is better. But that's a reflection of poor language design choices rather than anything intrinsic to programming.


Oddly enough, I find that I type fewer keystrokes when writing Java than, for example, Python. The boring predictability of the language allows the IDE to guess what you're thinking most of the time.



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

Search: