Slashdot Mirror
Ask Slashdot: What Should Every Programmer Read?
An anonymous reader writes "There's a blog post floating around right now listing articles every programmer should read. I'm curious what articles, books, etc., Slashdot readers would add to this list. Should The Art of Computer Programming, Design Patterns, or Structure and Interpretation
of Computer Programs be on the list? What about The Mythical Man-Month, or similar works that are about concepts relating to programming? Is there any code that every programmer should take a look at? Obviously, the nature of this question precludes articles about the nitty-gritty of particular languages, but I'm sure a lot of people would be interested in those, too. So if you can think of a few articles that every C++ programmer (or Perl, or Haskell, or whatever) should know, post those too."
It's rather out of date but "The Joy of C" was my first programming book and I attest its style to easing me in to the development mindset.
For example, here; http://www.catb.org/jargon/htm...
Clean Code by Robert C. Martin, Working Effectively with legacy code by Michael C. Feathers, Refactoring by Fowler, Design Patterns by the gang of four. If you are a C++ programmer, anything by Sutter or Meyers.
Je ne parle pas francais.
Everybody should RTFM.
Dear aunt, let's set so double the killer delete select all
No list is complete without Vernor Vinge's _True Names... and Other Dangers_. I don't care if it's a book, instead of an article, but still, it's required reading.
"Trust me - I know what I'm doing."
- Sledge Hammer
And "How to Write a KILLER LinkedIn Profile... And 18 Mistakes to Avoid", both by Brenda Bernstein.
An arbitrarily long strip of tape, divided into sections on which there appear symbols drawn from some finite alphabet. They should be able to work the rest out from that.
Code Complete is the #1 thing every programmer should read.
"Politics and the English Language", George Orwell.
Should be required reading for everyone not just programmers.
...you don't get to call yourself a "software engineer" or talk about others' software engineering practices.
"My life's work has been to prompt others... and be forgotten." --Cyrano de Bergerac
The little schemer series, (The Little Schemer, The Seasoned Schemer and The Reasoned Schemer) Daniel Friedman
Even if you never intent to use a lisp, it's worth reading.
http://www.amazon.com/The-Litt...
http://www.amazon.com/The-Seas...
http://www.amazon.com/The-Reas...
I have a copy of the first three volumes of TAoCP and have skimmed parts of it. I've occasionally opened it as a reference source (for example, on PRNGs), but I wouldn't claim to have "read" it. People who do are likely either hardcore computer scientists or bullshitters.
http://git-scm.com/documentati...
They're there for a reason.
The C Programming Language, so they learn how to properly document their work.
Paradigms, styles, approaches are different. There is no "central" body of things that can capture this. Even absolute classics like "Goto considered harmful" can be misleading and counter-productive to read unless the reader can supply the right context. That said, every programmer should always work to understand his or her craft better and broaden their view. That includes reading about insights other people have had into the process.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
http://www.joelonsoftware.com/articles/Unicode.html
Programmers maybe write reasonable code - but they often cannot express their ideas in ordinary language. Read the paper, George Orwell, 'Clean Code', Slashdot, whatever - and practice writing too. And talk to people. If they look puzzled, you're not communicating well, and need to get better. Use grammar. Write clean, accurate comments.
(Quick scan to make sure that this is clean... well, good enough...)
"The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
Dilbert.
I'm gazing across my bookshelf full of O Reilly books, Knuth's series, TCP/IP Illustrated, and others... but the most important books are more mundane:
Godel Escher Bach: an Eternal Golden Braid, and Alice in Wonderland
Both of these books encompass the thinking and mindset which will make you a better programmer by planting the seed of logic, states, and recursion, and nourishing the hell out of it. It will massage the pathways to make someone actually want to be a programmer.
Can't think of anything else that 'every' programmer should read. All programmers are different, what would benefit someone who writes C for embedded systems might bore a WPF developer to pieces and not benefit him or her one bit. So might as well read something funny.
I wish I'd read Roger Kaufman's book before I started programming. It would've helped a lot.
Here's a few pages to get a taste of the style: http://www.cs.utsa.edu/~wagner...
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
But how do they get "the right context" without knowing what to read?
Gack wrong title.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
code.
... the top 10 books/articles/whatever that every human being should read.
Now if only we could get some kind of agreement on what those "top 10" are.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Here's my two cents:
- Effective C++: 55 Specific Ways to Improve Your Programs
- Code Complete
- Design Patterns: Elements of Reusable Object-Oriented Software
"The best book on programming for the layman is Alice in Wonderland, but that's because it's the best book on anything for the layman."
- Alan Perlis, "Epigrams on Programming", ACM SIGPLAN Notices 17 (9), September 1982, pp. 7–13
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Code. Lots and lots of code. Code from diverse sources, understanding the problems, understanding the solutions. Programming books/articles offer nice ideas, philosophies, anecdotes, whatever, but nothing will improve programming skill more than experience. Reading code, IMO, and at least for me, increases that experience much more than writing it or reading the meta about programming.
while(1) attack(People.Sandy);
The Psychology of Computer Programming, by Weinberg. Its from 1971 but still relevant. It tackles the management aspect of working in a team, how to handle difficult people etc. Clean Code, a great book for those interested in adopting a better coding style. Are your routines longer than 5 lines? Wrestling With Bears , goes into details about how to mitigate risk, evaluate and prioritize requirements and keep your projects on track. Test Driven iOS Development. Cocoa Design Patterns (if your an iOS developer); it really helps to understand what is happening under the hood of the API. Software Engineering by Ian Sommerville, for those interested in design, architecture and large systems. Its a rather long and very traditional (not agile friendly), but its comprehensive and good. Someone already mentioned K&R, I'd add C++ by Bjarne Stroustrump. Agile and Iterative Development: A Manager's Guide. Its not really a "managers guide", but more of a "How can I be a good team player" with an introduction on XP/UP and Scrum kind of a guide. Highly recommented.
That's a good list of subject areas, and articles for technical areas, but if you're going to be an effective programmer, you need to venture out a bit. There are a couple of good books by Gerald Weinberg that will change the way you look at your profession. First is The Psychology of Computer Programming. It's a bit long in the tooth, but the lessons are still relevant. Same goes for Quality Software Management, Volume 1. Be warned, QSM, in particular, will make you dissatisfied with your managers.
Play it cool, play it cool, 50-50 fire and ice.
How about a book on Hindi so you can communicate with your boss and offshored co-workers at 2:00 AM in the morning, then train the H-1B who is going to be your replacement so you get a severance package?
Realistically, K&R's C book is a classic worth looking at. Defensive programming, and programming with security in mind are also important texts.
You gotta disconnect from the tech every once in a while.
I'm sure I'm not alone. This type of "article" seems to come up every other week.
What is a good read about programming?
If I want to get into programming, which language should I start with?
If I want to get my child into programming, where should I start?
Should schools push teaching programming?
Can I get a programming job with two semesters of classes done?
I've programmed for my whole life, can I learn a new language?
Isn't the rule of thumb for answers to headline questions to be "No"?
Seriously. Make a roulette wheel, spin it, then type the language it falls on followed by "tutorial" into google and start following directions.
This should be required reading for any programming putting software on the web. It details some 50 basic vulnerabilities that must be avoided. Its also a good starting point for the Q/A team and test planning.
"How to Win Friends and Influence People". Not for the advice; as a geek type you'll likely never be able to pull it off anyway. But in the spirit of knowing thy enemy; when the sales and marketing and pointy-haired businessmen try to manipulate you, you'll recognize the techniques and be able to put a source to them.
I see some good suggestions on how to code well but it's important to know how to produce human interfaces that are understandable, effective and even fun.
For that, my favorite book is "The Design of Everyday Things." It's not about software design, it let's you see effective (and bad!) design all around you and will make you think about your own designs. The affordances, or clues, you provide on how things work without having to spell it out in documentation.
Good programming is just the start. Good problem solving is the goal.
Then I suggest every programmer read every single one of the posts on this site: http://prog21.dadgum.com/ . The author has a remarkably clear head about things and a very mature outlook on programming.
A fool and his hard drive are soon parted.
"How to not fuck up"
It hasn't been written yet, but it needs to be written.
There are many that say 'how to do x'. But few/none that say 'How to not fuck up'.
I'll just leave this free and open source CS101 course here: NAND to Tetris.
No, in spite of what some jackasses say, it isn't just rewriting for its own sake. It is improving the structure in standardized ways so that you can add your new features much more safely. In interviews, I prefer people can name some standard refactorings before I ask them the typical questions about design patterns.
http://refactoring.com/
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
The best preparation for becoming a good programmer (or scientist or engineer) is to learn how to organize your thoughts and then address only what is necessary and sufficient to accomplish a given task.
I know no book that teaches clarity of thought better than Strunk & White's "The Elements of Style". Clear writing and great coding share a common wellspring.
The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully by Gerald M. Weinberg /. a long time ago, and I am glad I did.
It has a lot of little anecdotes that help you recall concepts of how to manage your own time. Things like Rudy's law of Rutabaga stick with me even though I haven't picked up the book in a while. I read this book based on someone's recommendation on
"Doctor's mistakes you bury, Engineer's mistakes you live with forever."
The UNIX Philosophy by Mike Gancarz is a great book. It is specifically applicable to understanding unix. But, it is broadly applicable for anyone developing software. Understanding how to build small reusable components that can be strung together well. It is also a short book, and thus a very easy read. So, it belongs on the list of books every program should read. You get a lot of bang for your buck.
My boss gave me this book when I started by my first job out of college. By far one of the best books on software development and construction out there. It is timeless and even though I no longer write code for a living, I refer back to it on many occasions still. You want a book to make a you a better programmer; you can't go wrong here.
Whereas other programming books are filled with conjecture and opinion ("I think this" or "I think that"), Steve McConnell went out and did the hard work of researching what actually works, then providing actual citations for everything he found. Following the guidelines and tactics in this book is like adding 10 years of experience to your programming skills. This book is a masterpiece in the field of programming.
http://www.amazon.ca/Code-Complete-Steve-McConnell/dp/0735619670
Spoiler, everybody dies
"How To Win Friends and Influence People" By Dale Carnegie.
A classic, every programmer (and person) should read it.
"What every programmer should know about floating point math"
After a year i go back and realize what a horrible programmer i am. It happens every year. But i'm getting better. I also spend a lot of time reading other people's code. I've found that if you are writing "new" code you haven't already seen in action, you just might wind up killing somone someday.
This has always been one of my favorites.
https://www.thc.org/root/phun/...
Their own code
Comment removed based on user account deletion
Won a Pulitzer in 1982, and git off my lawn.
That manual has been deprecated by the Book of Mormon. Much easier for a new user to absorb.
Don't read any books on programming, they're a waste of time and money. To become a good programmer, join an open source project and start developing in an open community. If you want to buy the books as a learning experience then I suggest grabbing an arduino ( or other uC ) and just writing a firmware, logging system and web interface for it.
http://www.joelonsoftware.com/...
Things you think are in the Constitution, but are not.
http://www.mit.edu/~xela/tao.h...
7 habits of highly effective people.
Never Eat alone
EMotional Intellegence 2.0
The Five Dysfunctions of a Team
What, were you thinking of programming books? bah, mostly worhtless for your career.
Understanding people? that is how you make it.
I used to be all about the programming books. I write solid, clean code. I use small methods, functions., etc. I wrote some really good code, did some amazing things with very limited memory.
None of that gets you dick in the long run.
Career and business wise, understanding how to deal with people, and how a good team works is the way to get ahead.
If I had read those books when I was twenty, I would have retired by 45. Instead I work endless hours to craft some high quality code when I could have written something mediocre and gone home on time.
Seriously no one would know or care.
The Kruger Dunning explains most post on
Even absolute classics like "Goto considered harmful" can be misleading
Only thing worse than GOTO statement is COMEFROM statement. Event driven programming is basically COMEFROM functions.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Mark Twain wrote a scathing essay titled "Fenimore Cooper's Literary Offenses" which discusses "nineteen rules governing literary art in the domain of romantic fiction–some say twenty-two", and mentions 18 in detail. Of course it's all an excuse to bash another author's writing, but there is a germ of truth behind it. Think of variables as "characters" in the "tale" being told (perhaps a user story?). http://www.pbs.org/marktwain/l...
There is a wikipedia entry about it, in case you have interest:
http://en.wikipedia.org/wiki/T...
Uh, Linux geek since 1999.
See my sig line below: Buckminster's the man to read, you geeks.
Development is programmable; Discovery is not programmable. (Fuller)
Nonsense. The Mythical Man-Month is mostly about team-building, project management and a bit about software architecture
In other words the mix of work for a programmer of every company I have been at.
You think you came to write code? Ha Ha! Let me acquaint you with Mr Process.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Everything Men Know About Women. They say Knott Mutch is the nom-de-plume for a Slashdot editor, but I'm not sure which one.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Was the Command Line by Neal Stephenson
I have plenty of common sense, I just choose to ignore it. -- Calvin
#ifndef BOOKS_EVERY_PROGRAMMER_SHOULD_READ_H /* (The Blue Book) */,
#define BOOKS_EVERY_PROGRAMMER_SHOULD_READ_H
"The TAO of Programming", "Back to Basics: A Complete Guide to Traditional Skills - Abigail R. Gehring", "Paper: Bitcoin: A Peer-to-Peer Electronic Cash System - Satoshi Nakamoto",
"Murach's Mainframe COBOL - Mike Murach, Anne Prince and Raul Menendez", "Cosmos - Carl Sagan", "The Persian Expedition - Xenophon",
"Democracy in America - Alexis de Tocqueville", "Crucial Confrontations: Tools for talking about broken promises, violated expectations, and bad behavior -- Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler",
"The Curriculum - Stanley Bing", "Python the hard way",
"Dan Ariely: Predictably Irrational", "Are your lights on?", "A Brief History of Time - Stephen Hawking ",
"D is for Digital: What a well-informed person should know about computers and communications - Brian W. Kernighan",
"History of the Peloponnesian War - Thucydides", "PostScript Language Tutorial and Cookbook - Adobe Systems"
"Elements of Positional Evaluation - Heisman", "The origin of the species - Charles Darwin", "The Fourth Turning - William Strauss, Neil Howe", "The Art of War - Sun Tzu",
"The Practice of Programming", "The Elements of Programming Style", "A Random Walk Down Wall Street - Malkiel", "One Up On Wall Street - Peter Lynch", "The TeX book",
"Silent Spring - Rachel Carson", "LaTeX Beginner's Guide - Stefan Kottwitz", "The Art of Choosing", "Liespotting",
"Basic Physics: A Self-Teaching Guide", "The Art of Assembly Language - Randall Hyde", "1491 - Charles C. Mann",
"The IDA Pro Book: The Unofficial Guide to the World's Most Popular Disassembler - Chris Eagle", "The Unix Programming Environment", "http://plan9.bell-labs.com/plan9/*", "http://www.vitanuova.com/inferno/*",
"Learning CFEngine 3: Automated system administration for sites of any size - Diego Zamboni", "UNIX and Linux System Administration Handbook - R. Hein", "DevOps Troubleshooting: Linux Server Best Practices - Kyle Rankin", "The Unix Philosophy - Mike Gancarz",
"What Every Web Developer Should Know About HTTP - K. Scott Allen", "A Mathematician's Apology - G H Hardy", "Linux Device Drivers - Jonathan Corbet, Alessandro Rubini", "http://www.slashdot.org/*",
"http://rubyonrails.org/*", "paper: Reflections on Trusting Trust - Ken Thompson", "Computers, Chess, and Cognition", "paper: Fundamental Concepts in Programming Languages - Christopher Strachey",
"paper: An Axiomatic Basis for Computer Programming - C. A. R. Hoare", "Cryptonomicon", " Dreaming in Code", "Beautiful Code:*", "The future of the internet and how to stop it - Zittrain",
"The Devil's Dictionary", "I, Robot - Isaac Asimov", "1984 - George Orwell", "Tufte. The Visual Display of Quantitative Information",
"The Non-Designer's Design Book - Robin Williams", "The Wealth of Networks - Yochai Benkler", "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency - Tom DeMarco", "Why Popcorn Costs So Much at the Movies: And Other Pricing Puzzles - Richard B. McKenzie",
"Where Wizards Stay Up Late: The Origins Of The Internet", "Engineering Long-Lasting Software: An Agile Approach Using SaaS and Cloud Computing -- David Patterson, Armando ", "Practical Electronics for Inventors - Paul Scherz and Simon Monk", "How to Diagnose and Fix Everything Electronic - Michael Geier ", "Hard Drive: Bill Gates and the Making of the Microsoft Empire - James Wallace",
"Learning Web Design: A Beginner's Guide to HTML, CSS, JavaScript, and Web Graphics ", "Brave New World - Aldous Huxley", "Understanding Digital Signal Processing - Richard G. Lyons", "HBase: The Definitive Guide",
"The Joy of jQuery: A Beginner's Guide to the World's Most Popular Javascript Library ", "TCP/IP Illustrated Volume 1", "DNS And Bind", "Cisco Internet Routing Architectures",
"HTTP The Definitive Guide", "Foundations of IT Service Management with ITIL 2011 - Brady Orand, Julie Villarreal", "In S
... my upcoming book, "Quit Fucking Up Perfectly Good Software with Overly-'Designed', Non-User-Tested Bullshit, I'm Looking at You, Apple Mozilla Google Microsoft Adobe Slashdot and Certain People at My Company Who Shall Remain Nameless", in stores this fall.
So far it's just the cover and then 168 pages of the title being repeated but I think I'll get it wrapped up pretty soon.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Word for word this short essay served to improve my coding more than any other document, and not just in C. Most of the essay is applicable to any language. Pike elegently and concisely explains the most important principles of good code style and software architecture. The sections "Programming with data" and "Function pointers" are particularly sailent. The section "Complexity", also known as "Rob's Rules", is outstanding and ought to be burned into the brain of every software developer. It's a free online classic and I'm surprised it hasn't been mentioned yet. http://www.lysator.liu.se/c/pi...
-73, de n1ywb
www.n1ywb.com
I'll second C2, and offer an additional recommendation: dig deep.
Required reading for internet skeptics
Anyone developing software needs a clue about names, and about unicode and text encodings.
http://www.kalzumeus.com/2010/...
http://www.joelonsoftware.com/...
(Then learn lots, lots more about text encodings).
Also, whether or not they use SQL directly, about metacharacter attacks and SQL injection:
http://bobby-tables.com/
http://watchguard.com/infocent...
Mostly so if you ever go into management you'll have a clue, unlike the vast majority of managers. (Unfortunately after reading it you see just how much stupid stuff management does.)
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
The correct answer to this question is "A programmer should read a lot".
I apologize for the lack of a signature.
> "Atlas Shrugged" by Ayn Rand.
Or, you could read some real philosophy, written by scholars who managed to mature beyond emotional adolescence.
And learn the fundamentals!
//it is okay if x overflows
x++;
or
x++;
Programmers should read / investigate about how things work, specially human behaviour, economics and politics and pay special attention to problems (and why they happened across the longest period of time you mind can handle). That will be far more better than whatever recommendation.
http://www.quasarcr.com/
Applied Cryptography by Bruce Schneier. Really any and all of his books.
+1 for, The C Programming Language, by K&R
(Brian W. Kernighan, Dennis M. Ritchie)
Because if you have never programmed in C (or assembler) then you really don't know how a computer works.
This is one of those questions that's going to keep being asked... Perhaps one day I'll be fast enough to get a first post on this that people actually read...
Link summary from last time:
General comments
I've noticed which book answers tend to fall a bunch of categories:
If you're going to ask someone "which book?" try limit the categories they should give you an answer for...
Zen and the Art of Motorcycle Maintenance
If you don't read it, you don't get it.
The Definitive C++ Book Guide and List
/ The Arrow
"How lovely you are. So lovely in my straightjacket..." - Nny
The pragmatic programmer and code complete
MouseClass extends ScrollClass, which extends TabClass, which extends SidebarClass, which extends PowerClass, w
by Tracy Kidder. A CS prof in school put it on the syllabus. Great account of a development project.
Karl Popper, "Objective Knowledge", in order to make you understand what the dangers of induction and inductive reasoning are.
John von Neumann & Oskar Morgenstern "Theory of Games and Economic Behavior", a brain-trainer that will leave you, after having read it, much more induced to first simulate, then code !
Peano, "Calcolo Geometrico", containing his famous axioms for Boolean algebra. There is a good translation from the year 2000 by Kannenberg, titled "Geometric Calculus"
Leslie Lamport, "Time, Clocks and the Ordering of Events in a Distributed System" -- you will never think the same again about synchronization and time-related problems....
And so on. All classics from the 20th century, giving the necessary background in computing and logics fundamentals that I so often miss in today's fresh graduates. The oldest text, by Peano is even from 1888, but still actual today !
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
If you are doing C++, you absolutely must read the Frequently Questioned Answers:
"C++ is a general-purpose programming language, not necessarily suitable for your special purpose."
It's a little (though not much) out of date, as it does not cover C++11. But the author has some comments on it, too.
Obviously I am going to be modded down, but hey. Truth is truth.
by Capers Jones.
Provides empirical evidence _why_ we need to write good code.
Here's an interview with the fella I just stumbled across yesterday:
http://www.informit.com/articles/article.aspx?p=1824791
-- Truth suffers from too much analysis.
ok, this is more about what programmers should "do" than what they should "read". But for anyone involved in working as part of a team or dealing with either managers or subordinates (holy crap, I have just described everyone not working completely alone), I strongly recommend going to a few Toastmasters meetings.
No matter what programming language you use, development style, methodology, or approach, programmers today spend more time communicating with other people than they ever have done before.
Toastmasters - both in terms of giving speeches and also performing leadership tasks based on running the meetings, helps to improve communication and leadership skills (dramatically, in most cases).
If you are ok with being the anti-social loner who sits in the corner churning out code, and who thinks of communication with others as "one grunt for no, two for yes", then you need not bother. But for everyone else, it is a great place to go.
If every university simply taught this book, software development would be called software engineering. Written in 1996, and still we have not learned the lessons. Flawed. Wordy. Partially out of date. And yet, if you understand and apply the concepts in this book, you will design applications and systems of the standard that everyone actually expects software to be at (rather than where it is).
Don't be put off by the "C++" in the title. Most of the concepts are applicable to any language. It's about the engineering behind large scale software development.
Yet the same people who complain about GOTO because they have to scroll around the source to see what'll happen have no problem with things like object-oriented programming, where it might be literally impossible to figure out what function (out of an unbound set) will actually be called until the code is run.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
which dull book did you invest time in reading, and you now want other people to read so you can feel validated?
sag
http://www.akkadia.org/drepper...
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Look around for things that deal with aspect that interest you, that expand on topics you do not know yet and that you can follow. I am _not_ against reading a lot. I am against elevating some texts to "high wisdom", as that can do more harm than good. This cannot be done without experimenting and looking around.
For example, for me, the algorithm books by Knuth are pretty worthless. I find them far too hard to read. On the other hand, the original papers referenced I usually understand much better.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Goto is not a problem in itself. In order to understand the issue, you have to know that at the time this article was written, most people used goto exclusively, and _that_ is a problem. Used competently, goto is just another tool in the box and it does have its uses.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Indeed. All paradigms known so far have their serious problems, and I do not expect that to change. The important thing is to know more than one tool and more than one style, so you always have choices to make the code better. And "better" always means KISS, clarity, simplicity. There is no silver bullet, and there may never be one. But people that just know one tool, tend to think it solves everything best. It does not.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
They use cooperative multitasking in this day and age? How stupid can you get? Cooperative multitasking has its applications, but only in small, extremely high quality code, where you have special needs besides that.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
This was the book that opened my eyes to defensive programming. It's pretty old now, but apparently there a newer version.
TFM?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Every programmer should read code. Bad code and good code. To learn how to do things and how to not do things.
Error-Free Software: Know-how and Know-why of Program Correctness by Robert L Baber, published by Wiley, ISBN 0 471 93016 4
http://www.amazon.com/Error-Fr...
This slim volume is by far the most readable and practical introduction to formal verification that I have seen.
Don't be put off by its somewhat overstated title.
I believe it is important for every professional programmer to have some understanding of how to construct a proof of correctness of code, even if they never use it professionally, as it will expand their understanding of programming. In my case, knowing what it would take to prove a program correct has changed the way I program, in ways that I hope improves the reliability of what I write.
I'll second the recommendation on Steve McConnell's Code Complete - I've used it as a college textbook in classes on SE I've taught. On a lighter note, I would recommend Tracy Kidder's The Soul of the New Machine. Somewhat dated, but gives a historical perspective on how/what it took to build a new machine and make it to market.
"Software is the difference between hardware and reality"
Programmers should sift through an old bug database.
“Common sense is not so common.” — Voltaire
Duh.
Need Mercedes parts ?
Not a book to read, but read about Unicode and learn that Characters are != Bytes.
Bytes are 8-bit machine values.
Characters are part of human languages. The old ASCII coding where a char is a byte is just one (primitive) method of encoding characters into bytes.
The important thing is that whenever you need to convert or store characters into bytes, you must use a function to convert chars to bytes. Conversely, when you need to convert bytes into characters, you need an inverse function to do so. Think of it like if you had to convert between bizarre languages like Klingon and Canadian, you would use a pair of translation functions between the two. You could not just access values from Klingon and assume they are valid values in Canadian.
The conversion from Chars to Bytes and vice versa takes an additional parameter that indicates which Character Encoding to use. There are several to pick from. US-ASCII, UTF8, UTF16, etc. But UTF8 is a very good default because it is very much like ASCII, but will properly convert characters in any human or alien language between Unicode and bytes. The functions that convert from Bytes to Characters on your system may very well offer a function that does not need a character encoding parameter (eg, UTF8) but will figure out which encoding the bytes represent and then decode them into characters for you.
It is difficult, I know. The notion that chars == bytes is deeply embedded. But it is easy to break. And once you do, it's really easy to understand that they are different and they must always be converted using a pair of functions. So for example, a function that compresses data would accept BYTES not characters and would return BYTES. A function that encodes data into Base64 would accept BYTES as input and would output CHARACTERS limited to the US-ASCII set of characters. But the characters could be embedded into anything that accepts character parameters, such as an email, output into a web page, etc. A function that parses JSON into a data structure accepts CHARACTERS as input, not bytes. An HTML output (or input) stream is characters, not bytes. A file on disk is bytes, not characters. But the byte stream can be passed through a reader that returns a character stream in order to read through the file as characters. Etc.
I'll see your senator, and I'll raise you two judges.
http://insecure.org/stf/smashs...
http://c2.com/cgi/wiki if you want the URL. One of the oldest URLs in my memory that still works.
It's not neatly organised, but I find I go to check one thing and two hours later I start closing the tabs I've opened that I know I'm not going to get around to reading.
It predates, predicted and helped evolve the whole Agile development movement, and all the conversations and insights that led to current best practices are still there.
Yet the same people who complain about GOTO because they have to scroll around the source to see what'll happen
That is of course a straw man. People don't complain about goto because they they to scroll around. Even in properly structured non-oo programming you have to scroll around to see subroutines. And that's fine.
The argument against goto is that it tends to produce buggy and unmaintainable code. Where maintenance isn't just scrolling around to understand what's going on, but making fixes and changes to the functionality.
Of course the oop approach is also complex, but it's complication derives from the actual complexity of the problem domain of writing event driven applications. Goto complexity (spaghetti programming) is accidental and unnecessary complexity.
As programmers need to have clear analytical thought, they'd be much better off reading The Blind Watchmaker or The God Delusion than The Bible.
There are rational and irrational persons on both sides of this issue.
We're not recommending people, we're recommending books. And the two I recommenced encourage analytical thinking, whilst the bible encourages the exact opposite. "Faith".
To be fair though, a lot of programmers do seem to like sci-fi and fantasy, so they might get something out of The Bible on that level.
i've done more harm to my own (and other people's) code by following advice taken from MSDN articles than by any another means.
microsoft have a way of breaking everything, and then writing about it is if they invented the solution.
except their solutions never work.
the number of times i have had to rewrite server code, socket code, locking code, threading code, all because the original was based on one of their samples.
there is no single "right" way to write code, but there are plenty of wrong ones, and microsoft have been the worst offenders, to date, in my experience.
at time of writing stackoverflow is my best reference, and otherwise plenty of RTFM.
I think you're mistaken about what the Bible means by "faith". It is not belief contrary to overwhelming or clear evidence. It's the willingness to take a risk that something is true, in cases where the evidence is ambiguous or mixed.
Garden of eden? Noah's Ark with at least 2 examples of every land species? Bringing a dead person back to life? There's no ambiguous or mixed evidence. If you believe this stuff, it's blind faith. And it's the opposite of analytical thinking.
I'm not aware of anywhere in the Bible where irrationality is endorsed.
I think it's telling that I'm talking about analytical thinking, and you keep responding as if I said rationality.
Anyhow, this off-topic thread is going nowhere.
The first thing I thought of when I saw this post was "import this" in Python, which prints out the Zen of Python:
"""
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
"""
Which is definitely relevant. Oh well.
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
Art of Assembly is a good book.
The Bible is a collection of 66 different books, some of which appear to have been intended as allegory (parts of Genesis; Job; etc.), poetry and wisdom literature (Psalms), history (1st and 2nd Kings), etc.
My understanding is that the allegorical and poetical books are not considered as such simply because a literal interpretation would be problematic. My understanding is that the Hebrew writing style flags them as such. I think you're making the mistake of interpreting non-literal books as having been intended as literal, and thus get a mistakenly tainted view of the Bible, and of the persons whose beliefs are rooted in it.
As far as bringing a dead person back to life: the Bible's authors certainly aren't claiming that's something that normally happens, nor that it's a natural even. The whole point of those resurrections was to confirm that Jesus wasn't merely a lying or deluded human.
Regarding analytical thinking vs. rationality: If you're depending on the differences in their meanings / connotations, I'm all ears, but you need to clarify your meanings. But in normal conversation, the two terms generally go hand-in-hand.
And I agree that the topic will probably go no where. Not because it's on the wrong /. thread, but because it generally takes more than an exchange over the internet to make someone change his position on this topic.
Kernighan and Ritchie's "The C Programming Language". I think it is the best to understand programming. Knuth's Art of Computer Programming is a great plus, but it is not the basics. Also having an understanding of compilers is very beneficial. Dragon book is really recommended.
The algorithms and architectures found in code help you manage workflow and data. You'll need those same skills in other areas of your life so you can be effective. IMHO - the best book for figuring out how to handle time and mental energy is "Getting Things Done" (GTD) by David Allen. Here is the best summary I've found for condensing the book's 288 pages down into less than 4000 words.
-- "In a time of drastic change it is the learners who survive; the 'learned' find themselves fully equipped to live in
The problem with GOTO is that it makes it difficult to reason about the code, or make statements you can count on. (This largely goes away when GOTO is used in a disciplined fashion, but most of its real uses have different and more limited keywords in modern languages.) In OO programming, you can examine the member functions to make sure that they do the same thing, if in different ways. If you find they don't, that's a real problem.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Thing about cooperative multitasking is that it's safer than preemptive. Errors are going to lead to thread starvation, which is fairly obvious and may not harm the program except by making it take longer. In preemptive, errors can occasionally cause race conditions, in which execution goes subtly awry and you get the wrong answer without realizing it.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
"The Timeless Way of Building" by Christopher Alexander.
"The wisdom of the Patriarchs was that they *knew* they were fools." --Master Foo
Read a book or paper about ethical engineering. The rest will fall in place.
The problem with cooperative is that basically any piece of code can kill the whole thing by deadlocking it. Testing is not adequate to find that. On the other hand, calculations that give wrong results because of race-conditions are exceedingly rare. Race-conditions are a crash-, deadlock- and security-risk, but almost never a risk that causes wrong computation results. In addition, with preemptive you can split processing power into parts that do not have dependencies. With cooperative, that is impossible, everything always depends on everything else working.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I think you're making the mistake of interpreting non-literal books as having been intended as literal, and thus get a mistakenly tainted view of the Bible, and of the persons whose beliefs are rooted in it.
You call it a mistake, yet the literal truth of the bible is exactly what most evangelical and born-again Christians profess as their belief. And before the 19th century codexes were unearthed in coptic monasteries, showing that the books of the bible had changed significantly over time, pretty much all protestant Christians believed in the literal truth of the bible, and indeed that the bible was the literal word of God.
For sure for those modern Christians that accept some of the bible is "allegorical and poetical" do so because they accept that there is too much evidence against them to be literally true. It has nothing to do with interpretations of Hebrew - the coincidence of the change with the discovery of the early bible codexes gives the lie to that story. The readings of Hebrew were available long before the end of the 19th century. They were always available.
As far as bringing a dead person back to life: the Bible's authors certainly aren't claiming that's something that normally happens, nor that it's a natural even. The whole point of those resurrections was to confirm that Jesus wasn't merely a lying or deluded human.
And it's simply faith for those that believe it. The analytical mind finds no support for it.
Regarding analytical thinking vs. rationality: If you're depending on the differences in their meanings / connotations, I'm all ears, but you need to clarify your meanings. But in normal conversation, the two terms generally go hand-in-hand.
They might go "generally hand-in-hand" for the non-analytical mind. But not for the analytical mind. That's my point. The fact that you didn't distinguish the two points to a fuzziness in your thinking.
The difference? An ant or a bee is extremely rational, arguably more rational than a human, but it's not at all analytical. Everything the ant or the bee does is to ensure survival of it's genes. That's rationality. However, it is not capable of analysing it's behaviour or anything around it.
I'm not particularly playing up the difference with regard to the content of these posts. Just the fact that you repeatedly made the mistake of switching one word for another, when their meaning is related but not the same. Going back to the original topic of the need to have an analytical mind to be a good programmer, it's like not distinguishing an int from a float.
Not because it's on the wrong /. thread, but because it generally takes more than an exchange over the internet to make someone change his position on this topic.
It's as rare as hen's teeth that an exchange face to face would do so either. Almost always a belief in religion is because of either indoctrination as a child, or because a person has come to crisis in their life, such as a prison sentence, or the loss of a loved one, and they have clung on to a fantasy that has brought them comfort.
In the other direction however, education can effect a change from religious belief to atheism or agnosticism. And I don't mean specifically atheist education. I mean general education that encourages analytical thinking.
I don't have the time to respond to all of those issues, but if you want to pick one, I'd be happy to keep chatting.
No, I'm happy to leave it there.
http://lxr.linux.no/linux-old+...
Casteism