Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical Papers Every Programmer Should Read at Least Twice (2011)

blog.fogus.me

Post reply on HN
Print view View original

61–70 of 72 posts

Re: Technical Papers Every Programmer Should Read at Least Twice (2011)

#61

Post by imanaccount247 »

tim333 wrote: post #57
gaius wrote: post #54

Earlier quoted context omitted.

The guys at Sony might disagree with you. How to secure a network or a mainframe was known in the 1970s, but who needs to know all that legacy systems crap, right? OO look new JS framework!!

I think the Sony issues illustrate platz's point "There is very little all programmers should be required to have in common. The field is just that big now." In a company like Sony you need some guys that specialise in security and prevention of hacking, and some that specialise in other stuff.

No, you can't just have "some guys that specialize in security". That's exactly what 99%+ of software is full of obvious security holes. 99%+ of developers don't know anything about or care anything about security. Security is a process not a product remember? Everyone has to be actively part of it all the time. You don't churn out buggy exploitable software and then expect some "security experts" to somehow magically make it secure.

Re: Technical Papers Every Programmer Should Read at Least Twice (2011)

#62

Post by stillsut »

ashish01 wrote: post #3

Can some please do a similar list for machine learning and also for maths relevant to ML?

Probably the most famous papers is Breimen's "The Two Cultures". The rejoinder's from Cox and Hoadley add two additional perspectives from long careers.

Re: Technical Papers Every Programmer Should Read at Least Twice (2011)

#63

Post by 3rd3 »

Semiapies wrote: post #34
waterlesscloud wrote: post #33

Earlier quoted context omitted.

Wow. That really is a quite revealing comparison.

Part of it might be that this was dropped on a Friday night, US time.

There is also the fact that the first condensation seeds of discussions on HN are largely determined by chance.

Re: Technical Papers Every Programmer Should Read at Least Twice (2011)

#64

Post by EdwardCoffin »

Matumio wrote: post #39
jvreeland wrote: post #11

It's weird that "What every programmer should know about memory" Isn't on here. Even for languages that manage memory for you understanding the hard limitations and basic operations used to access and manipulate memory is certainly useful.

This is an excellent read, but I disagree with the title. It's a must-read for people interested in CPU architecture and for programmers who, after profiling, still consider doing micro-optimizations. E.g. if you seriously think about reordering your struct members for faster access. If you're building a web service, skip it.

I think it is a useful read for people doing any kind of programming at all, in that it might discourage them from attempting optimizations that seem obviously good, and might have _been_ good, if they were running on 20 year-old architectures, but these days just make the code more convoluted to no gain.

I know that this is the kind of effect the paper had on me (I spent a lot of time carefully reading it shortly after it was published), and now I almost never use what knowledge I gained from it to make performance optimizations, but it does frequently discourage me from attempting optimizations that I now know would probably not have the desired effect.

Re: Technical Papers Every Programmer Should Read at Least Twice (2011)

#65

Post by tim333 »

imanaccount247 wrote: post #61
tim333 wrote: post #57

Earlier quoted context omitted.

I think the Sony issues illustrate platz's point "There is very little all programmers should be required to have in common. The field is just that big now." In a company like Sony you need some guys that specialise in security and prevention of hacking, and some that specialise in other stuff.

No, you can't just have "some guys that specialize in security". That's exactly what 99%+ of software is full of obvious security holes. 99%+ of developers don't know anything about or care anything about security. Security is a process not a product remember? Everyone has to be actively part of it all the time. You don't churn out buggy exploitable software and then expect some "security experts" to somehow magicall…

I see your point but if 99%+ of developers are rubbish at security what are you going to do about it?

a) Hope they suddenly improve, which is probably not going to happen

b) Accept they have limits and encourage them to use systems and frameworks that are hard to screw up on, written people who are good at security?

I note in the Sony hack the only computers that survived basically intact were Macs, not I guess because their owners understood security but because they were well designed and idiot friendly.

Re: Technical Papers Every Programmer Should Read at Least Twice (2011)

#67

Post by kuni-toko-tachi »

lmm wrote: post #43
nightski wrote: post #41

Earlier quoted context omitted.

Would you still consider yourself an "amateur-hour web designer"? If not, why did you improve? Should we not aspire to be better?

I've learnt from various sources, but none of them were papers. There is no one-size-fits-all teaching or learning method. And rudeness and insults are going to make people less likely to learn, not more.

I've been writing software for 20/years, and had I learned the concepts brought forth in these papers years ago, I would have been much better. Hacking is not writing software.

Re: Technical Papers Every Programmer Should Read at Least Twice (2011)

#68

Post by imanaccount247 »

tim333 wrote: post #65
imanaccount247 wrote: post #61

Earlier quoted context omitted.

No, you can't just have "some guys that specialize in security". That's exactly what 99%+ of software is full of obvious security holes. 99%+ of developers don't know anything about or care anything about security. Security is a process not a product remember? Everyone has to be actively part of it all the time. You don't churn out buggy exploitable software and then expect some "security experts" to somehow magicall…

I see your point but if 99%+ of developers are rubbish at security what are you going to do about it? a) Hope they suddenly improve, which is probably not going to happen b) Accept they have limits and encourage them to use systems and frameworks that are hard to screw up on, written people who are good at security? I note in the Sony hack the only computers that survived basically intact were Macs, not I guess becau…

They don't have to suddenly improve, they can learn and improve at a normal pace. Yes, of course they should not use PHP. But simply having them use languages, libraries and frameworks that are written by people who get security won't stop them from writing insecure applications to put into production. They still need to learn to write secure code too.

Re: Technical Papers Every Programmer Should Read at Least Twice (2011)

#69

Post by lmm »

grobinson wrote: post #46
lmm wrote: post #43

Earlier quoted context omitted.

I've learnt from various sources, but none of them were papers. There is no one-size-fits-all teaching or learning method. And rudeness and insults are going to make people less likely to learn, not more.

Is that not because, at the time, you were much more of a beginner than you are now? I've been studying Computer Science for the last four years (BSc and now MSc) but was coding for maybe three years before that. Back then I was learning JavaScript and PHP from w3schools, PHP.net and some blogs. I built a framework from reading the source code for CodeIgniter. I learn't a lot about object orientated design, or the la…

I tried to read the Paxos paper and gave up. The Raft paper I probably could've understood, but I found it easier to understand by looking at an implementation and a less formal description of it. I don't think it's about what you know (plenty of papers have few prerequisites and are conceptually quite simple).

Re: Technical Papers Every Programmer Should Read at Least Twice (2011)

#70

Post by hueving »

imanaccount247 wrote: post #68
tim333 wrote: post #65

Earlier quoted context omitted.

I see your point but if 99%+ of developers are rubbish at security what are you going to do about it? a) Hope they suddenly improve, which is probably not going to happen b) Accept they have limits and encourage them to use systems and frameworks that are hard to screw up on, written people who are good at security? I note in the Sony hack the only computers that survived basically intact were Macs, not I guess becau…

They don't have to suddenly improve, they can learn and improve at a normal pace. Yes, of course they should not use PHP. But simply having them use languages, libraries and frameworks that are written by people who get security won't stop them from writing insecure applications to put into production. They still need to learn to write secure code too.

>Yes, of course they should not use PHP.

Wow, this is utterly worthless, if not harmful, advice. There is no correlation between choosing PHP for an application with the security of said application. PHP apps are so widely deployed that securing them is a pretty well-known process at this point.

Post reply on HN