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

51–60 of 72 posts

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

#51

Post by BugBrother »

mietek wrote: post #49
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?

JavaScript still only has floating point, I think... So no.

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

#52

Post by fsloth »

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…

"There is very little all programmers should be required to have in common"

Especially the closer one gets to domain specific things, yes. But I think it is beneficial to all who develop software to realize from time to time how deep the rabbit hole of implementation specific complexities goes, mainly so they understand how to design their systems without stepping in any "obvious" implementation specific landmines.

But in general I think your post validates the claim, since I really need to be aware of of all the traps in the floating point number representation to do my programming job properly :)

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

#53

Post by klibertp »

grobinson wrote: post #47
theoh wrote: post #35

Earlier quoted context omitted.

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…

> duck typing and automatic type conversion

It's weak typing (or equivalently "automatic type conversion" as you say) that is to blame. "Duck typing" - also "structural polymorphism", "subtyping polymorphism", know in OCaml as "polymorphic variants" and adopted as a default by Go's interfaces semantics - would only enable "'10' + 10" if String type would have a method "+(x:Number)", which most likely is not there, or if it is it's explicitly laid out.

It's weak typing - ie. language trying to coerce elements of expressions to the types which make the whole expressions make sense, with implicit rules that no one ever reads - that's dangerous.

Sorry for being this pedantic, but while I'd like to see less weak typing in languages (outside of some specific domains, like AWK) I'd also would like to see more "duck typing", because it's more convenient than nominative polymorphism and exactly as safe.

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

#54

Post by gaius »

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…

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!!

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

#55

Post by grobinson »

klibertp wrote: post #53
grobinson wrote: post #47

Earlier quoted context omitted.

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…

> duck typing and automatic type conversion It's weak typing (or equivalently "automatic type conversion" as you say) that is to blame. "Duck typing" - also "structural polymorphism", "subtyping polymorphism", know in OCaml as "polymorphic variants" and adopted as a default by Go's interfaces semantics - would only enable "'10' + 10" if String type would have a method "+(x:Number)", which most likely is not there, or…

Sorry, you're absolutely right! I had confused the two when writing my post.

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

#56

Post by jnbiche »

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

Earlier quoted context omitted.

"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 a…

Fair enough. We're are on the same page, after all.

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

#57

Post by tim333 »

gaius wrote: post #54
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…

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.

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

#58

Post by gaius »

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.

Umm, no, not really, it has to be baked into everything you do, even the most junior programmer working on a website has to know e.g. about SQL injection.

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

#59

Post by pron »

tikhonj wrote: post #17
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…

The beauty behind fundamental programming language concepts—which make up the majority of this list—is that they apply to programming in general . They are all widely used abstractions, underpinnings for common technologies or powerful mental tools. Most importantly, they promote a sort of higher-order reasoning and mathematical thinking that's extremely powerful but rarely taught well. Are these strictly required fo…

> The beauty behind fundamental programming language concepts—which make up the majority of this list—is that they apply to programming in general.

I would disagree (with the extent of their applicability and general usefulness). Not that this isn't somewhat useful to many or most programmers -- you may certainly be right about that -- but there are other subjects (like data structures, for example) that are probably a lot more useful, and serve as much more fundamental underpinning for common technologies[1]. So, yes, we'd all benefits if more programmers learned this stuff, but we'd benefit even more if they spend their time on even more important/general CS topics.

Because programmers spend much of their time in code they sometimes tend to place too much emphasis on code over working, well-behaving, performant running programs. Producing such programs requires a lot more than "the right" programming style: it requires a good understanding of hardware, of requirement analysis, of common failure modes, of algorithms and data structures. Programming style (or language) is just a part of what's required, and probably among the least important parts.

The widespread belief among PL people is that "good" programming languages (for your own definition/preference of "good") promote good working software, but not only has that never been proven, there isn't much evidence to suggest this is even true at all (now, I'm not saying it's not true, but just playing devil's advocate and pointing out it isn't evidently true).

[1] Proof: binary (and other types of trees) trees are used in every programming language, while classes, object, higher order function or monads are most certainly not; ergo: you can certainly program -- and produce good, working software -- without classes/object/high-order-functions/monads, but you can't produce good software (in general, that is), without knowledge of trees (and/or other data structures).

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

#60

Post by vegedor »

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

Earlier quoted context omitted.

"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 a…

The title doesn't represen the problem properly. It would better be 10 Things every Programmer should _learn_. Now, if you are in the beginning of developing, obviously there is more, but from a universal point of view, you should really want to advance to these points, but not everyone has to agree with that, since before learning that, the question is what you wanted to build using information technology. So are you arguing about a True Scotsman? The term Computer Science is very specific, as you might be thinking of, in contrast to Engineering or Design. Programmer isn't.

Many technical schools do teach a combination of design/engineering and computer science however to bridge the gaps from either side, where the focus is less on science than it's application. Therefore the Master Classes are more focused as well and it might just so happen you never get in touch with distributed computing more than once. Although, that might become an outdated assumption.

Post reply on HN