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

41–50 of 72 posts

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

#41

Post by nightski »

sneak wrote: post #40
momo-reina wrote: post #36

Earlier quoted context omitted.

Actually I'd argue that there are quite a few things that programmers should have in common, if by programmers we're talking about serious engineers/computer scientis[1] and not "amateur-hour web designers"[2]. Knowledge of the fundamental concepts talked about on that list of papers, and the history therewith, is what allows us to go past the current level of engineering and actually reach greater heights. Most of t…

I started programming seventeen years ago as an "amateur-hour web designer". This sort of attitude is not productive or helpful to our rapidly-growing industry.

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

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

#42

Post by jnbiche »

momo-reina wrote: post #36
platz wrote: post #4

There is very little all programmers should be required to have in common. The field is just that big now. 9 times out of 10 a list like this includes a treatise on floating point number representation, which while useful, probably isn't of utmost importance in the 21st century, but hey, at one time folks thought that was required for 'all programmers' to read. At least this list does seem more up to date and relevan…

Actually I'd argue that there are quite a few things that programmers should have in common, if by programmers we're talking about serious engineers/computer scientis[1] and not "amateur-hour web designers"[2]. Knowledge of the fundamental concepts talked about on that list of papers, and the history therewith, is what allows us to go past the current level of engineering and actually reach greater heights. Most of t…

"not "amateur-hour web designers"

Perhaps you're confused. Most people who refer to themselves as "web designers" aren't meant to be or and aren't trying to be computer scientists or engineers. Many of them have a graphics design education, or taken inspiration from that tradition. Some of the more technically-minded of them can do basic coding, but most of them stop at HTML and CSS. But they're better than I am at UI/UX, and visual design, because that's what they do. They're not meant to be computer scientists.

If you mean web-application developers, however, I'd urge you to take a look at some of the stuff that is being done on the front-end these days. (not to mention the fact that this blog post was written by a Javascript expert)

Yes, there are some people who have drifted into their jobs and are little more than cargo cultists, although some of the more talented and curious of them do make the upgrade to serious professionals. But by far, most of the people I've worked with recently on front-end jobs have had a rigorous computer science education, with an excellent knowledge of data structures, algorithms, software engineering, and computer architecture. The fact that they're working on the front-end, in Javascript, is incidental. In their spare time, and if they're lucky, on some in-house stuff, they might prefer working in Haskell, or maybe Clojure. But much like C in past decades, the web is ubiquitous, and any serious developer of this era must know how to work in it. We don't all have the privilege of getting paid to write Scheme.

But I do share your opinion that there are certain foundational concepts and knowledge that all professional programmers should have in common, including some of the papers referenced.

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

#43

Post by lmm »

nightski wrote: post #41
sneak wrote: post #40

Earlier quoted context omitted.

I started programming seventeen years ago as an "amateur-hour web designer". This sort of attitude is not productive or helpful to our rapidly-growing industry.

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.

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

#45

Post by momo-reina »

jnbiche wrote: post #42
momo-reina wrote: post #36

Earlier quoted context omitted.

Actually I'd argue that there are quite a few things that programmers should have in common, if by programmers we're talking about serious engineers/computer scientis[1] and not "amateur-hour web designers"[2]. Knowledge of the fundamental concepts talked about on that list of papers, and the history therewith, is what allows us to go past the current level of engineering and actually reach greater heights. Most of t…

"not "amateur-hour web designers" Perhaps you're confused. Most people who refer to themselves as "web designers" aren't meant to be or and aren't trying to be computer scientists or engineers. Many of them have a graphics design education, or taken inspiration from that tradition. Some of the more technically-minded of them can do basic coding, but most of them stop at HTML and CSS. But they're better than I am at U…

Perhaps the comment came out wrong, let me try to be a little clearer.

I'm not trying to create separate categories between front-end, back-end, desktop, CLI, and systems engineers. The distinction I am trying to make though is that yes, while Computing has become a vast field, there simply are some basic fundamental skills that are absolutely required if we want to go beyond our current level of achievement.

These are things that you have mentioned: deep knowledge of algorithms, data structures, software engineering, computer architecture, etc. This is absolutely the MINIMUM requirement Without understanding these things, we will stay at this present level of software engineering forever. Sure we will have mastered the tools, and the current programming-paradigms that these tools teach us, but we will not be able to advance.

Whether one programs in JavaScript, Forth, Common Lisp, or even BASIC isn't the issue. The point that Fogus's post is trying to get across, or at least what I have taken away from it, is that most "serious" programmers are incredibly lacking in what is considered basic foundational knowledge. What field one specializes in is irrelevant, there is just some stuff that everyone has to understand, not necessarily in the way that a specialist in the field does, but at least have more than passing, cursory knowledge of it.

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

#46

Post by grobinson »

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.

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 lack thereof, in that project.

By the time I finished 2nd year of Comp Sci I had a pretty good understanding of algorithms, design patterns, some theory (Petri-nets, state machines, etc..), databases, etc. Going into my MSc, there is quite a lot that you can't learn without reading papers. For example, chances are you are going to have no idea how to solve the consensus problem in a distributed system without reading Paxos.

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

#47

Post by grobinson »

theoh wrote: post #35
recursive wrote: post #6

Earlier quoted context omitted.

Floating point behavior still represents a significant portion of new questions asked on stack overflow. I'd say it's still very relevant.

Considering JavaScript makes it difficult to avoid, that's not surprising... And since js is probably one of the common denominators of much activity on the fringes of programming it seems like floating point should be widely discussed. Unrelated to numeric computing, my favourite thing would be Butler Lampson's Hints for Computer System Design.

I've worked with code in the past where the previous developers didn't understand that there was a difference between an integer in a string (i.e. var x = '10';) and an integer (i.e. var x = 10; ). In some ways weak typing and automatic type conversion is quite dangerous because it can encourage beginners to adopt bad practice and be non the wiser.

Edit: Changed 'In some ways duck typing' to 'In some ways weak typing' as rightly pointed out below.

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

#48

Post by grobinson »

jaryd wrote: post #23

I would recommend this one for historical purposes: http://insecure.org/stf/smashstack.html

This is an excellent paper but it does require a prior understanding of the stack, addressing, buffers, pointers, etc. It would be really nice if there was an article or blog post designed for people who want to read this paper but don't have the prior knowledge that's required to understand it. Unfortuntely I don't know of any. HN?

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

#49

Post by mietek »

platz wrote: post #4

There is very little all programmers should be required to have in common. The field is just that big now. 9 times out of 10 a list like this includes a treatise on floating point number representation, which while useful, probably isn't of utmost importance in the 21st century, but hey, at one time folks thought that was required for 'all programmers' to read. At least this list does seem more up to date and relevan…

Have programmers stopped representing monetary values using floating point yet?

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

#50

Post by anjbe »

bdamm wrote: post #32

Any list without Shannon's 1948 "A Mathematical Theory of Communication" is just not a good list. Sorry. http://cm.bell-labs.com/cm/ms/what/shannonday/shannon1948.pd... The foundation of information theory. It is, by far, the most astonishing paper I have ever read. Far more astonishing than Lamport's famous conclusion about clocks. It is the kind of paper that causes a soul rift when read thoroughly.

I’m partial to his Master’s thesis, “A Symbolic Analysis of Relay and Switching Circuits.” It literally invented digital computing. As an electrical engineering student it blows me away that one guy’s thesis (he was 21!) can be fundamental to so much.
Post reply on HN