programming

Type-System Criteria · ongoing by Tim Bray Cri­te­ria Let’s call them the Bánffy-Bray cri­te­ria for se­lect­ing be­tween sta­tic and dy­namic type sys­tems. Sta­tic typ­ing’s at­trac­tive­ness is a di­rect func­tion (and dy­namic typ­ing’s an in­verse func­tion) of API sur­face size. Dy­namic typ­ing’s at­trac­tive­ness is a di­rect func­tion (and sta­tic typ­ing’s an in­verse func­tion) of unit test­ing work­a­bil­ity.

Online interactive resources to learn programming: Learn | Code.org — Beginners (concepts), HTML/CSS, JavaScript, Python, Codecademy — HTML/CSS, JavaScript, jQuery, PHP, Python, Ruby Learn Code The Hard Way — Python, Ruby, C, SQL, Regex, CLI Try Ruby: learn the basics of the Ruby language in your browser

This brings us to the magical three step process for becoming an expert at anything: Watch someone Try it yourself and experiment Teach someone else (via Programming Your Brain: The Art of Learning in Three Steps | BitNative ) See also another image representation:

When I left Sun to go to NeXT, I thought Objective-C was the coolest thing since sliced bread, and I hated C++. So, naturally when I stayed to start the (eventually) Java project, Obj-C had a big influence. James Gosling, being much older than I was, he had lots of experience with SmallTalk and Simula68, which we also borrowed from liberally. Patrick Naughton (in Java Was Strongly Influenced by Objective-C ) Sigh… we sure knew how to have fun in those days… ...

A programmer takes between 10-15 minutes to start editing code after resuming work from an interruption. When interrupted during an edit of a method, only 10% of times did a programmer resume work in less than a minute. A programmer is likely to get just one uninterrupted 2-hour session in a day (via Programmer Interrupted )

::: {style=“margin-bottom:5px”} If programming languages were religion{target="_blank"} from katherine goodier{target="_blank"} ::: (via If programming languages were religion ) I originally wrote this article in December 15, 2008, and posted it on the Aegisub blog. I’m re-posting it here for archival purposes. — Rodrigo Monteiro ( Source: http://www.slideshare.net/ )

97 Things Every Programmer Should Know – Contributions Appearing in the Book Act with Prudence by Seb Rose Apply Functional Programming Principles by Edward Garson Ask “What Would the User Do?” (You Are not the User) by Giles Colborne Automate Your Coding Standard by Filip van Laenen Beauty Is in Simplicity by Jørn Ølmheim Before You Refactor by Rajith Attapattu Beware the Share by Udi Dahan The Boy Scout Rule by Uncle Bob Check Your Code First before Looking to Blame Others by Allan Kelly Choose Your Tools with Care by Giovanni Asproni Code in the Language of the Domain by Dan North Code Is Design by Ryan Brush Code Layout Matters by Steve Freeman Code Reviews by Mattias Karlsson Coding with Reason by Yechiel Kimchi A Comment on Comments by Cal Evans Comment Only What the Code Cannot Say by Kevlin Henney Continuous Learning by Clint Shank Convenience Is not an -ility by Gregor Hohpe Deploy Early and Often by Steve Berczuk Distinguish Business Exceptions from Technical by Dan Bergh Johnsson Do Lots of Deliberate Practice by Jon Jagger Domain-Specific Languages by Michael Hunger Don’t Be Afraid to Break Things by Mike Lewis Don’t Be Cute with Your Test Data by Rod Begbie Don’t Ignore that Error! by Pete Goodliffe Don’t Just Learn the Language, Understand its Culture by Anders Norås Don’t Nail Your Program into the Upright Position by Verity Stob Don’t Rely on “Magic Happens Here” by AlanGriffiths Don’t Repeat Yourself by Steve Smith Don’t Touch that Code! by Cal Evans Encapsulate Behavior, not Just State by Einar Landre Floating-point Numbers Aren’t Real by Chuck Allison Fulfill Your Ambitions with Open Source by Richard Monson-Haefel The Golden Rule of API Design by Michael Feathers The Guru Myth by Ryan Brush Hard Work Does not Pay Off by Olve Maudal How to Use a Bug Tracker by Matt Doar Improve Code by Removing It by Pete Goodliffe Install Me by Marcus Baker Inter-Process Communication Affects Application Response Time by Randy Stafford Keep the Build Clean by Johannes Brodwall Know How to Use Command-line Tools by Carroll Robinson Know Well More than Two Programming Languages by Russel Winder Know Your IDE by Heinz Kabutz Know Your Limits by Greg Colvin Know Your Next Commit by Dan Bergh Johnsson Large Interconnected Data Belongs to a Database by Diomidis Spinellis Learn Foreign Languages by Klaus Marquardt Learn to Estimate by Giovanni Asproni Learn to Say “Hello, World” by Thomas Guest Let Your Project Speak for Itself by Daniel Lindner The Linker Is not a Magical Program by Walter Bright The Longevity of Interim Solutions by Klaus Marquardt Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly by Scott Meyers Make the Invisible More Visible by Jon Jagger Message Passing Leads to Better Scalability in Parallel Systems by Russel Winder A Message to the Future by Linda Rising Missing Opportunities for Polymorphism by Kirk Pepperdine News of the Weird: Testers Are Your Friends by Burk Hufnagel One Binary by Steve Freeman Only the Code Tells the Truth by Peter Sommerlad Own (and Refactor) the Build by Steve Berczuk Pair Program and Feel the Flow by Gudny Hauknes , Ann Katrin Gagnat , and Kari Røssland Prefer Domain-Specific Types to Primitive Types by Einar Landre Prevent Errors by Giles Colborne The Professional Programmer by Uncle Bob Put Everything Under Version Control by Diomidis Spinellis Put the Mouse Down and Step Away from the Keyboard by Burk Hufnagel Read Code by Karianne Berg Read the Humanities by Keith Braithwaite Reinvent the Wheel Often by Jason P Sage Resist the Temptation of the Singleton Pattern by Sam Saariste The Road to Performance Is Littered with Dirty Code Bombs by Kirk Pepperdine Simplicity Comes from Reduction by Paul W. Homer The Single Responsibility Principle by Uncle Bob Start from Yes by Alex Miller Step Back and Automate, Automate, Automate by Cay Horstmann Take Advantage of Code Analysis Tools by Sarah Mount Test for Required Behavior, not Incidental Behavior by Kevlin Henney Test Precisely and Concretely by Kevlin Henney Test While You Sleep (and over Weekends) by Rajith Attapattu Testing Is the Engineering Rigor of Software Development by Neal Ford Thinking in States by Niclas Nilsson Two Heads Are Often Better than One by Adrian Wible Two Wrongs Can Make a Right (and Are Difficult to Fix) by Allan Kelly Ubuntu Coding for Your Friends by Aslam Khan The Unix Tools Are Your Friends by Diomidis Spinellis Use the Right Algorithm and Data Structure by JC van Winkel Verbose Logging Will Disturb Your Sleep by Johannes Brodwall WET Dilutes Performance Bottlenecks by Kirk Pepperdine When Programmers and Testers Collaborate by Janet Gregory Write Code as If You Had to Support It for the Rest of Your Life by Yuriy Zubarev Write Small Functions Using Examples by Keith Braithwaite Write Tests for People by Gerard Meszaros You Gotta Care about the Code by Pete Goodliffe Your Customers Do not Mean What They Say by Nate Jackson \

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time. Tom Cargill, Bell Labs (the Ninety-ninety rule )

Learnable Programming Programming is a way of thinking, not a rote skill. Learning about “for” loops is not learning to program, any more than learning about pencils is learning to draw. People understand what they can see. If a programmer cannot see what a program is doing, she can’t understand it. Excellent essay about programming “without blindfolds”.

TIOBE Programming Community Index The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month.