Ask HN: What language-agnostic programming books should I read? | Hacker News

Ask HN: What language-agnostic programming books should I read? | Hacker News: " What language-agnostic programming books should I read?"



'via Blog this'

technologyreview: Programming Languages: Toolkits for the Mind

Toolkits for the Mind: "When the Japanese computer scientist Yukihiro Matsumoto decided to create Ruby, a programming language that has helped build Twitter, Hulu, and much of the modern Web, he was chasing an idea from a 1966 science fiction novel called Babel-17 by Samuel R. Delany. At the book’s heart is an invented language of the same name that upgrades the minds of all those who speak it. “Babel-17 is such an exact analytical language, it almost assures you technical mastery of any situation you look at,” the protagonist says at one point.



With Ruby, Matsumoto wanted the same thing: to reprogram and improve the way programmers think.

It sounds grandiose, but Matsumoto’s isn’t a fringe view. Software developers as a species tend to be convinced that programming languages have a grip on the mind strong enough to change the way you approach problems—even to change which problems you think to solve. It’s how they size up companies, products, their peers: “What language do you use?”



 That can help outsiders understand the software companies that have become so powerful and valuable, and the products and services that infuse our lives. A decision that seems like the most inside kind of inside baseball—whether someone builds a new thing using, say, Ruby or PHP or C—can suddenly affect us all. If you want to know why Facebook looks and works the way it does and what kinds of things it can do for and to us next, you need to know something about PHP, the programming language Mark Zuckerberg built it with."



'via Blog this'

Why I Switch From [Language_1] to [Language_2]

Why I Switch From [Language_1] to [Language_2]: "I am a big fan of [Language_1] and one of its early adopters, having been disappointed with the utter failures of [Language_0]. I have been an avid contributor to many open source projects such as [Obscure_Project_1], [Obscure_Project_2], and [Obscure_Project_3]. However, after using [Language_1] for over 5 years, I have been dealing with [Minor_Technical_Flaws]. At first, I ignored and even tolerated these flaws, but I was forced to confront reality. I could not live with these flaws, and since [Language_1] is a mature language, it will be difficult, if not impossible, to actually fix [Minor_Technical_Flaws]."



'via Blog this'

“My Code is Self-Documenting” — Eric Holscher - Surfing in Kansas

“My Code is Self-Documenting” — Eric Holscher - Surfing in Kansas: "Self-documenting code is one of the biggest documentation myths in the software industry. This view generally conflates documentation with code comments. I’d like to make two arguments in this post:

Code comments have value
Documentation has more value than just explaining how software works"



'via Blog this'

xkcd: Functional Programming

xkcd: Sad: "

'via Blog this'

braydie/HowToBeAProgrammer: A guide on how to be a Programmer - originally published by Robert L Read

braydie/HowToBeAProgrammer: A guide on how to be a Programmer - originally published by Robert L Read:



To be a good programmer is difficult and noble. The hardest part of making real a collective vision of a software project is dealing with one's coworkers and customers. Writing computer programs is important and takes great intelligence and skill. But it is really child's play compared to everything else that a good programmer must do to make a software system that succeeds for both the customer and myriad colleagues for whom she is partially responsible. In this essay I attempt to summarize as concisely as possible those things that I wish someone had explained to me when I was twenty-one.


This is very subjective and, therefore, this essay is doomed to be personal and somewhat opinionated. I confine myself to problems that a programmer is very likely to have to face in her work. Many of these problems and their solutions are so general to the human condition that I will probably seem preachy. I hope in spite of this that this essay will be useful.

'Knowing and Doing' blog

Excellent Computer Science blog: http://www.cs.uni.edu/~wallingf/blog

Interesting articles include:

Thinking in Types, and Good Design

Students who become accustomed to programming in languages like Python and Ruby often become accustomed to using untyped lists, arrays, hashes, and tuples as their go-to collections. They are oh, so, handy, often the quickest route to a program that works on the small examples at hand. But those very handy data structures promote sloppy design, or at least enable it; they make it easy not to see very basic objects living in the code.
Who needs a Game class when a Python list or Ruby array works out of the box? I'll tell you: you do, as soon as you try to almost anything else in your program. Otherwise, you begin working around the generality of the list or array, writing code to handle special cases really aren't special cases at all. They are simply unbundled objects running wild in the program.
Good design is good design. Most of the features of a good design transcend any particular programming style or language.

Code Duplication as a Hint to Think Differently

When defining a program to process an inductively-defined data type, the structure of the program should follow the structure of the data.

This guideline helps many programmers begin to write recursive programs in a functional style, rather than an imperative style.

Take Small Steps

If a CS major learns only one habit of professional practice in four years, it should be:

Take small steps.

A corollary:

If things aren't working, take smaller steps.

I once heard Kent Beck say something similar, in the context of TDD and XP. When my colleague Mark Jacobson works with students who are struggling, he uses a similar mantra: Solve a simpler problem. As Dr. Nick notes, students and professionals alike should scale the step size according to their level of knowledge or their confidence about the problem.

Software Design is a Bet on a Particular Future

This truth is expressed nicely by Reginald Braithwaite:

Software design is the act of making bets about the future. A well-designed program is a bet on what will change in the future, and what will not change. And a well-designed program communicates the nature of that bet by being relatively flexible about things that the designers think are most likely to change, and being relatively inflexible about the things the designers think are least likely to change.

That's what refactoring is all about, of course. Sometimes, a particular guess turns out to be wrong. We have the wrong factors, the wrong components, for adding a new feature. So we change the shape of the code -- we factor it into different components -- to reflect our new best understanding of the future. Then we move on.
Sometimes, though, there are forces that make more desirable a relatively monolithic piece of code (or, as Braithwaite points out, a system decomposed into relatively less flexible components). In these cases, we need to defactor, to use Braithwaite's term: we recombine some or all of the parts to create a new design.
Predicting the future is hard, even for experienced programmers. One of the goals of agile design is to not think too far ahead, because that means committing to a future too far removed from what we already know to be true about our program.