How Programming Language Shapes Thought: Overview of Series

In my last blog I went down the memory lane to see some of my own hand written notes from 1996-1998. Actually reams and reams of papers filled with many interesting ideas ranging from chip design to programming languages from Natural language processing to object oriented operating system design. (I also found bunch of science fictions I wrote that I am going to cleanup and publish.

I am planning a series of blogs on the subject. Here is an overview.  

I am opinionated because I'm Literate.
Donald Knuth coined the term "Literate Programming 
He says:  Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.
Planned Blog : Don't be illiterate!!

Syntax sugar is good.
 In my opinion the number one job of any programming language is to make programmers productive. I hate people who say "it's just syntax sugar". Yes, you are right- you idiot! Assembler is a syntax sugar, C is a syntax sugar, C++ is syntax sugar ..so on and so forth. I want 10th generation language right now. As long as it makes me productive and makes my intent clear sugar is good!! 

Planned Blog : Sugar is good!!
If someone is insisting on writing the 'raw' code then they are wasting their time and money.

Code is Design  
Software is different, the code we write is itself design.

Planned Blog : Be Extreme! Refactor your thinking: How to neutralize the guys who ask for design specs... 

Quality vs. Correctness: Be Assertive. 
Now, as software engineers we spend a huge amount of time finding fixing and debugging the bugs. So being productive means language features that force me to think about quality and make it easy to write the code. One of the books that has influenced me the most is Writing Solid Code. Two things that have stuck with me for lifetime are (A) I use asserts like crazy (B) I use debugger a lot. 

I like to be super paranoid so lots of asserts. And I write a lots of tests which tend to be exhaustive.
Here is a catch though : Absence of bugs is not quality and presence of asserts is not correctness.  When I misunderstand something or simply did not think about something. I write wrong code , wrong asserts and wrong tests ! All unit tests pass and I have a bug filed against me !!!  
planned blog: Be Assertive
planned blog: Quality Strategy
planned blog: Being Probably Correct .. 
planned blog: Automate my way to disaster. 

planned blog: Fragile Development

Ineffective Design!
One of my favorite books was  The Design and Evolution of C++ . The three takeaways ..

1. Language must be must be a natural progression of what programmers are comfortable with right now.
2. It must be statically compiled. With no runtime overhead.It must be able to link with existing code.
3. Pay the price for only for the features that you use. Also,

With multi paradigm language like C++ one problem is that with increased flexibility comes increased complexity and increased risk that you'll shoot in your foot. You are always free to write the ineffective, sloppy or very clever "(!?#@)" code.  With increased flexibility comes increased responsibility. Thankfully there are books like these
Effective C++: 55 Specific Ways to Improve Your Programs and Designs (3rd Edition)
More Effective C++: 35 New Ways to Improve Your Programs and Designs

But problem is that all that good stuff is option.

Be Effective ! Analyze that! 
Use static analysis tools
Other blogs

• Design by contract
• Unit Testing
• Pex an interesting Idea

and many more ...