I did the exercise yet again (the third time) because my last attempt needed some improvements:

• it suffered from chronic classitis and divitis (too many classes, ids, and divs were making me itchy)
• it wasn’t really using semantic / structural markup (all the extra divs etc… cluttered my markup, and some of my class names like container-borders are non-semantic altogether)
• it performed poorly and wasn’t accessible (everything was being rendered in the DOM, there was no immediate rendered markup which kind of violated the idea of unobtrusive JavaScript, nor was it screen reader friendly)
• it wasn’t making use of any JavaScript libraries to abstract browser inconsistencies out of the code
• it suffered from my software ethnocentrism (my variable and object naming like GoogleExercise was mirroring statically typed languages and not the native language they were being written in)

Here’s my latest Google Exercise (addressing all the above concerns):
View this post outside your RSS reader to see it in action or view it here.

This attempt makes use of jQuery and uses 57 lines of JavaScript (almost 200 lines less from my last one).

You can view the code for this attempt here: google.contact.widget.js, index.html, google-contact-widget.css.

You can view the old code here: GoogleExercise.js, index.html, GoogleExercise.css.

If you think I can improve on my code then let me know. Oh yeah, and if you’re a recruiter from Google then hire me! :)

Over the past couple months I had the pleasure of working in a Java shop. Up to this point I've spent most of my time in the .NET realm. Working with Java was a great chance to experience the similarities and contrasts between environments, cultures, and web application implementations. Here are a couple of my observations.

Java developers are more knowledgeable than the typical .NET developer. Java developers tend to gravitate towards complexity, Linux, UNIX, open source, and continuous learning. They are less familiar with the wizards and drag-n-drop style development that often characterize .NET development. The Java developers I worked with didn't depend on a single unified IDE (like Visual Studio), instead each developer chose their text editor / environment (Emacs, Eclipse, TextMate, E-TextEditor, and jEdit were all being used on a single project). Each developer was responsible for being productive with their editor; and took responsibility for learning shortcuts, and other performance enhancing techniques. This broad use of editors placed an emphasis on the core command line tools which ensured that developers knew how the application was put together, and cultivated broad application troubleshooting skills within the team.

Unified IDEs (like Visual Studio or Eclipse) do not result in faster development, better developers do. Developers empowered with the ability to choose their development environment / text editors / operating system resulted in more passion and responsibility. Informal friendly rivalry between editor users drove development faster while providing diversity within the work place.  

Programming languages and technology stacks don't matter to experienced software developers. As a developer it's easy to become a fanboy of languages or technologies stacks, but… they don't matter - writing good software within the bounds of our project do. There's no reason to be tied to a specific language or technology stack. Sure, languages fall into a specific category (dynamic, static, classical inherited, prototypical inherited) but programming languages are very similar.

Steve McConnell has been saying this all along:

mastering more than one language is often a watershed in the career of a professional programmer. Once a programmer realizes that programming principles transcend the syntax of any specific language, the doors swing open to knowledge that truly makes a difference in quality and productivity. - Steve McConnell, Code Complete 2nd Edition

I like the RubyGem system just as much as Ruby, it makes a developer’s life easy.

For example, let’s say I want to design a new class:

• Install Ruby
• Install the Test-Unit Gem (along with a couple automatically installed prerequisites):

C:\>gem install test-unit
 Successfully installed test-unit-2.0.2
 Successfully installed hoe-1.8.3
 Successfully installed rubyforge-1.0.2
 Successfully installed rake-0.8.3

• Create a new test.rb file along with a new class.rb file (alternately we could have used the Interactive Ruby Shell directly from the command line)
• Run the test (test.rb):

C:\>ruby test.rb
 Loaded suite test
 Started
 .
 Finished in 0.001 seconds.
 1 tests, 1 assertions, 1 failures, 0 errors

• ???
• Profit! :)

Contrasting this to the Java / C# world: I’d be installing a compiler (or slower yet an IDE), then installing / configuring a testing framework. I’d also probably be installing a build process tool (like ant / nAnt), then I’d need to create a build file.

Similarly if I wanted to install Rails at the command line I specify gem install rails or if I want to use  RSpec gem install rspec.

The Ruby tools, ecosystem, and community is fantastic.

As developers, limiting ourselves to a single metaphor, framework, or programming language is a liability to our career. In order to remain employable and engaged with our work, we need to understand the higher level concepts surrounding our chosen development arena - if you’re working in the webspace this means knowing CSS, JavaScript, HTML, and more than one server-side language. Then beyond technologies and languages we should be looking at transcending principals like design patterns, and good design practices.

identifying with anything so strongly that it starts to give you emotional reaction is really bad. You never know when your language is going to be obsolete or … your favorite framework is going to be replaced. … I would love to see everybody learn a bunch of languages because it does make you a better programmer. … Most people will never switch languages. - Steve Yegge, stackoverflow podcast #25 

My heuristic approach to naming conventions:

New Development / Greenfield Work:

• Follow the conventions of the language, or the standards used within the larger community, and pay attention to the API. For example: If you’re programming in .NET follow the naming conventions outlined in MSDN, in JavaScript look at the DOM API, in CSS look at the definitions.
• If a formal naming convention exists for the organization and these conventions makes sense (they aren’t too far off the language APIs) then follow them. If it feels like the naming conventions were created in the dark ages by a very-very senior COBOL Developer then start asking questions.

Maintenance / Brownfield Work:

• Follow the conventions of the existing code if you’re modifying an existing module.
• If you’re creating new modules then consider following the conventions of the language and API.

This post was inspired by a podcast by Donald Belcham and Kyle Baley on Brownfield Applications.

Most languages and technologies used in web applications come with their own unique naming conventions - which is unfortunate, but necessary, because diversity is important. Languages like JavaScript and PHP use camelCase, CSS uses-hyphenated-delimiters, and ASP.NET / Java / and the like adhere to the conventions used in their respective libraries and frameworks. Managing the different naming conventions in a web application can be difficult, but with discipline, embracing each language’s conventions can provide some great benefits.

A common mistake I’ve made in the past, was trying to make all languages adhere to a single convention. As a budding PHP / ASP developer I took the-single-convention-for-all-languages approach. In retrospect, I used this approach because I didn’t completely understand the language I was using, and in order to compensate for this lack of knowledge, I’d try to meld the languages into the mental model I understood best. This was a mistake.

Today, I find that working with the conventions of the language facilitates re-use (experts in the language understand what I’m doing), promotes portability (modules can be used across projects regardless of server-side technologies), encourages global collaboration (open source modules and plug-ins can be easily consumed and contributed to), and helps to a nurture a more maintainable application (developers from other language domains can easily maintain the application with a relatively small learning curve). Like a carpenter working with fine material, I embrace working with the grain of each language. It’s also fair to mention that breaking free from the monocultured (one-size-fits-all) approach to naming conventions provides a broader perspective, and also makes your development skills more universal - it might even open the door to different development domains in the future.

Then there’s the discussion on name length, verbosity, and using meaningful names. Steve McConnell suggests that the optimum name size for a variable or function is between 8 and 20 characters (Chapter 11, Code Complete), but with tools like ReSharper (for renaming / refactoring etc…) I find myself using names well over 30 characters. So names like GetApproveeTotalFromNamedBasket are a common occurrence in my code. However, like most things, verbosity does need balance (everything in moderation right?). In the business layer, descriptive names are a godsend - they jog my memory as I rediscover what the module I wrote last month was supposed to do. But… in the presentation layer languages (like JavaScript, CSS,  ASP.NET, or XHTML) you may want to reconsider using long descriptive names. Since verbose, long running descriptive names in the presentation layer are passed over the network and can degrade performance. Often times these verbose names are combined together - throw in ASP.NET name mangeling, start hooking in verbose CSS definitions, and then start inserting JavaScript events. All this compounds quickly and result in large page payloads filled with elements like the following:

<div id="ctl00_ContentPlaceHolderForAllTheBestImprotantContent
 _PanelForTheBestReviews"> 
<a onclick="LinkButtonClick_ThankYouForTakingTheTimeToReadThis();" 
 id="ctl00_ContentPlaceHolderForAllTheBestImprotantContent_
 RepeaterForAllMyFavoriteBookReiews_ctl00_
 LinkButtonMarkReviewAsFavorite"
 class="LinkFormatingCssClass SelectedLinkFormatingCssClass" 
 href="javascript:__doPostBack( 
 ctl00$ContentPlaceHolderForAllTheBestImprotantContent$ 
 RepeaterForAllMyFavoriteBookReiews$ctl00$LinkButtonMarkReviewAsFavorite'
 ,'')">Mark As Favorite </a> 

Note: That mess of code above would fire a JavaScript event then an ASP.NET event. It’s the result of placing an ASP.NET LinkButton, inside a Repeater, inside a Panel, inside a Masterpage, and adding a JavaScript event along with some CSS. We can see that using long names in the presentation layers results in a mess of text. It’s also fair to mention that the ASP.NET MVC Framework lets developers write cleaner presentation code.
Sure, everyone cites premature optimization as the root of all evil, and we do live in a world of gzip file compression and JavaScript minifiers. But… keeping names short in CSS, ASP.NET, and XHTML isn’t hard as long as you’re mindful of the final goal. Smaller names in the presentation layer will reduce the amount of data transferred over the network which increase the performance of the application.

Joseph Smarr of Plaxo.com once said:

Web applications are only slow if you let them get slow - Douglas Crockford, Alex Russell and Joseph Smarr: On the Past, Present and Future of JavaScript [30:00]

My preference (project requirements warranting) is to keep things short and concise in the presentation languages while using longer descriptive names outside the presentation languages. What’s your preference?

The topic of our discussions reminded me of something David Heinemeier Hansson said when talking about software development:

You don’t need to be a f***ing genius to make any of this stuff work, it’s not rocket surgery! - David Heinemeier Hansson at Startup School 08

DeMarco and Lister also echoed this outlook back in the 80’s, and publicized: the High-Tech Illusion:

the High-Tech Illusion: [is] the widely held conviction among people who deal with any aspect of new technology … that they are in … high-tech business. [These people] are indulging in this illusion whenever they find themselves explaining at a … party, say, that that they are “in computers” … The implication is that they are part of the high-tech world. [These people] usually aren’t. The researchers who made the fundamental breakthroughs in those areas are in the high-tech business. The rest of us are appliers of their work. - Peopleware : Productive Projects and Teams

If we were in the High-Tech business, then we’d be the bottom feeders (the parasites, the grunts), because our daily activities revolve around consuming other peoples research and work (programming languages, platforms, frameworks and the like). We are consumers, we’re not on the cutting edge nor are we in the high-tech world.

Perhaps building software could be much like outfitting yourself for a day in the snow. You head off to the local shopping mall, you acquire the functional items to keep yourself warm, but brands and store choice don’t really matter. Whether we’re buying winter boots or choosing a programming language, technology doesn’t really matter. There are an infinite number of ways to solve any problem, as well as an infinite number of technical permutations to form a solution. If we can solve the problem within the constraints of our problem domain then we’ve succeeded.

The High-Tech Illusion often permeates my world - I work as a Web Developer in the Microsoft realm. I continually see the High-Tech Illusion manifests itself in these situations:

• Colleagues talking in vague opaque high-level metaphors that patronizingly shield you from the inter working of what they assume is beyond your comprehension
• Fixations on specific tools, hardware, platforms, and methodologies while the problem that needs to be solved is diluted and any combination of these items could solve the problem
• Colleagues that assume superiority and can’t acknowledge that knowledge is acquired through research and a continual efforts to improve

Pretentiousness in the software realm (in teams, organization, and so on) is usually the byproduct of someone that’s living the High-Tech Illusion.

I’ve been guilty of subscribing to the High-Tech Illusion. How does the High-Tech Illusion permeate your world? How can we get back to reality?

The classic geek haircut. I still sport this cut today. :)

How old were you when you started programming?

Somewhere around the age of 8 or earlier, computers were always just there - they’d been in my life since I can begin to remember.

How did you get started in programming? What was your first language?

My dad went to College for robotics when I was around 8 years old. His robotics program involved lots of programming and together we worked through a couple BASIC programming books. I continued to mess around with BASIC and wrote scripts so I could get at my favourite games. Later I was frequenting BBSs (The Fisherman’s Scroll), and surfing the internet through lynx (a text based browser). I eventually became a Script kiddie - being a Script kiddie was what really turned me on to programming. My friends and I would write IRC war scripts, play MUDs, and try to figure out how Trumpet Winsock, networks, and HTML worked - those were the days of Netscape 1 (the version with the big glowing ‘N’). Later we tried writing our own version of NetBus with the help of C / C++ programmers on IRC - the fragments of the C language these programmers exposed to me were magical, and sparked an genuine interest in computer programming. In addition to all this my dad kept a constant supply of old and new computer parts funneling into our house, my brothers and I would build computers from the parts - today my closest brother is a Linux fanatic, evidently all this sparked his interest too.

Programming has always been a part of my life, BASIC was my first language.

What was the first real program you wrote?

I followed a couple game tutorials from my BASIC books, but my first real program would have been Pacman programmed in Turing - in my final year of high school I enrolled in a computer course, where the instructor let us write any program we wanted for half a school year I chose to write a game.

What languages have you used since you started programming?

I’ve spent most my time in C, C++, C#, JavaScript, SQL, and the mark-up languages. I primarily program for the web or at least for the network, but have used many other languages like COBOL and so on…

While using multiple languages are great, I really believe that we you should completely understand the fundamentals of at least two languages (like say a static language and a dynamic language), because:

Once a programmer realizes that programming principles transcend the syntax of any specific language, the doors swing open to knowledge that truly makes a difference in quality and productivity. - Steve McConnell, Code Complete 2nd Edition. 

What was your first professional programming gig?

I would have been 18. It was my first year of College, I needed a part-time job in order to pay rent, I initially worked on an assembly line, but would occasionally help the office workers troubleshoot their IT issues. I soon found myself working as the company’s network admin / computer gopher. I went on to develop their cataloging system and a website. At the time I was going to school for Electronic Engineering, but decided to switch to a Computer specific program. Previous to this, I had freelanced a couple websites for local businesses while in high school.

If you knew then what you know now, would you have started programming?

Absolutely! The industry continues to instill a sense of wonder in me. I can’t imagine doing anything else.

If there is one thing you learned along the way that you would tell new developers, what would it be?

• Read! You’d be surprised how little progress has been made in the software industry over the past 30 years. By reading we can learn from the mistakes others have made.
• Don’t be intimidated by code or frameworks handed down by large organizations, their code isn’t any different than yours.
• Hard work always pays off, or as Thomas Edison said: “Success is 10 percent inspiration and 90 percent perspiration.”

What’s the most fun you’ve ever had … programming?

Collaborative programming is always fun whether it be paired programming or working together on a project. It’s hard to pinpoint the most fun I’ve “ever” had, because it’s all fun. :)

This post was in response to Michael Eaton’s initial post on: How did you get started in software development?

Now it’s your turn to answer: How did you get started in software development?

This book’s size makes it approachable for all audiences, its style is terse and concise. This book has the potential to do for JavaScript, what Richie’s inspirational classic the C Programming Language did for the C language.

JavaScript is the programming language of the web (AJAX), and this book will guide you through the good parts of this often misunderstood language - while this book is an excellent reference, it is not intended to replace JavaScript: The Definitive Guide, you’ll do best to have both these books on hand.

If you enjoyed (or are considering) this book then you may want to learn more of what Douglas Crockford has to say, check out his great JavaScript video series on the YUI Theater.

I highly recommend this book. View my review on Amazon.

The Google Web Developer Exercise:

Web Developer Exercise

Attached are three states of a new contacts widget. This widget will be used across Google and may be anywhere on the page. Designers will also use this in mocks for usability tests. Create the HTML, CSS, and JavaScript for the widget as described in the image. Your solution must work in Firefox v1.5+ and IE v6+. Bonus points for a solution that degrades nicely on older browsers.

After my first attempt, I concluded that:

1. My JavaScript knowledge was embarrassing
2. Dynamic programming languages like JavaScript using prototypical inheritance were awesome - as a monocultured .NET developer I had sorely been missing out
3. Framework Web Developers (ASP.NET, Ruby on Rails, and so on) aren't really Web Developers - we depend on a framework (an API) as a crutch, where the law of Leaky Abstractions is very real, and often when it rears it's head we use our golden hammer (our multipurpose language of choice), but there are better tools at hand
4. Web Developers claiming n years of experience need to at least know JavaScript, CSS, HTML / XHTML, a server-side language, and some XML / XSL - NOT just a single multipurpose language or framework
5. Innovation can only happen when you become one with the technologies surrounding your realm - for example: Jesse James Garrett probably would not have publicized AJAX had he been an exclusive ASP.NET developer. Diversity is essential for innovation

In retrospect this exercise is brilliant, it's a more complex derivation of a Fizzbuzz exercise, which effectively weeds out the knowledgeable candidates from the n00bs. JavaScript is notorious for being one of the world's most misunderstood language, many developer (and the ASP.NET Framework) still use JavaScript techniques from the old days of Netscape. For example: <a onclick=”return false;” …, or <a href=”Javascript: do something;” … are common DOM Level 0 inline techniques that should be avoided. These techniques have been replaced, but finding developer that use these JavaScript techniques can be hard.

By having a developer complete this exercise you effectively determine that the they understands these concepts:

• Cross browser compatibilities and work arounds for both JavaScript and CSS - with a preference given to feature detection (object detection) vs browser detection, an understanding of the different event handling models between browsers
• An understanding of the separation of concerns - JavaScript, markup, and CSS should be separate files, or at least separated within the document
• Event registration and listening - DOM events, the different browser event models, no inline level 0 event declarations, no pseudo JavaScript protocol inline declarations within markup
• An understanding of functional languages - closures, namespaces, lambdas, recursion where necessary
• Node manipulation - creating, swapping, removing elements
• Knowledge of non-obtrusive JavaScript techniques
• Importance of modular / compartmentalization of CSS and JavaScript - defensive programming techniques that minimize the risk of interfering with other scripts and elements within the page, part of the non-obtrusive techniques, how to avoid global variables
• An understanding on how to debug JavaScript from both IE (link) and Firefox (link)
• JavaScript code conventions - naming conventions, statement conventions
• CSS naming conventions
• General DHTML / AJAX techniques - showing and hiding elements
• A gauge on their attention to details and UI design intuition - what their gut tells them to do when things aren't spelled out

My latest crack at the Google Web Developer Exercise:

You'll have to visit my site (view this blog post outside a RSS reader) to view the code in action.

The code: GoogleExercise.js, index.html, GoogleExercise.css

Today I'm wearing JavaScript training wheels - feel free to comment on the code, I'm always looking for improvements and suggestions. I did take a couple shortcuts on the CSS / UI side of things as I was focusing more on the functionality.

Using one of the AJAX Libraries (like jQuery) we could certainly do this exercise in significantly fewer lines of code.

The ASP.NET AJAX Framework is an embarrassing server-side centric approach to DHTML / AJAX web development. While most programming languages and frameworks come with both good and bad parts, the ASP.NET AJAX Framework is an example of a bad part - on the contrast the ASP.NET MVC Framework looks to be a good part.

What’s wrong with the ASP.NET AJAX Framework?

1 .NET Developers are DUMMIES!
The ASP.NET AJAX Framework appears to have been designed under the assumption that .NET developers are dummies and can’t learn or don’t want to learn JavaScript. That .NET Developers would rather hobble along with their familiar languages, then to learn something new. I understand that the ASP.NET community’s only real problem is education, so let’s ask: What is wrong with the ASP.NET Community? Then educate ourselves rather than becoming the .NET Developer statuesque. It’s patronizing to use a framework that assumes learning a new language is beyond our capabilities. Many of these other programming languages are more expressive than statically typed languages like most of the .NET languages. 

2. The “don’t write a line of JavaScript” abstraction leaks like a sieve
The Framework is intended to shelter .NET Developers from the JavaScript language. Which, like driving a car across North America without knowing how to pump gas, stops you dead. Either you depend on someone to pump your gas - depend on a 3rd party (vendors or the ASP.NET AJAX Control Toolkit) and their many authors to write your JavaScript - or you stop moving. As Web Developers, sooner or later learning how to pump your own JavaScript becomes a mandatory skill.

3. Client-side programming from the Server-side is a absurd
The AJAX Framework does back flips to translate server-side code into JavaScript, and then requires that you write JavaScript anyway. Save yourself the pain, learn JavaScript. One day The Law of Leaky Abstractions comes into play, the gas station attendant fills your gas tank with diesel - the AJAX Control Toolkit blows requires debugging and you have to learn JavaScript anyways.

4. Bloated, poor performance, bad user and developer experience
The AJAX Framework extends many of the native JavaScript objects as it attempts to turn JavaScript into a staticly typed programming language, and tries to hook into the ASP.NET life cycle, but all these features are unneeded as they are ALL already achievable through the native JavaScript language - if it walks like a duck and quacks like a duck, then… err… could someone remind me why we need typed languages in a web browser? Anyhow; all these object extensions, enhancements, and upgrades, contribute to more scripts that need to be downloaded and increases the number of scripts running in your browser. Then there’s partial-page rendering and Update Panels which do full page post backs under the guise of AJAX. BAD! Client-side scripting is supposed to enhance the user experience not make it worse. Other AJAX Frameworks are built with performance as their number one goal, but in the ASP.NET AJAX Framework adding more widgets to JavaScript seemed to be the first priority, and performance an after thought.

5. Working against the grain is a waste of time
The AJAX Framework works against the grain, it would be nice if it embraced the JavaScript language. Very few of the concepts and metaphors used in the ASP.NET AJAX Framework transcend AJAX techniques or frameworks - your time is probably better spent learning how JavaScript works or how the other AJAX frameworks work.

6. Disconnected from the ASP.NET MVC Framework
The ASP.NET MVC Framework throws the ASP.NET life cycle away leaving more dead weight ASP.NET AJAX Framework script and rendering many of the AJAX Framework techniques moot.

7. The ASP.NET AJAX Framework almost over looks the ‘J’ in AJAX - ‘J’ stands for JavaScript (that’s GOOD)
JavaScript is the glue of the web, even the ASP.NET Framework depends heavily on JavaScript, it is not something to shy away from.

8. Aside from local intranet sites, no one really uses the ASP.NET AJAX Framework.
The AJAX Framework isn’t widely used. The ASP.NET AJAX site showcases 25 sites using ASP.NET AJAX. None of these applications appear to be high-traffic or moderately high-traffic applications. On the other hand, the YUI site showcases 89 sites, out of these sites, 6 sites (flickr, Slashdot, Linkedin, Paypal, O’Reilly, My Opera) could be considered high-traffic. Other AJAX libraries like jQuery, and Dojo compare similarly. Your time might be better spent learning one of the other AJAX frameworks.

If we (as .NET Developers) are going to claim we know AJAX, then let’s focus on the core of AJAX (JavaScript) and stop obscuring it in poor frameworks. Frankly the ASP.NET AJAX Framework is embarrassing, the web development community is laughing at the ASP.NET AJAX Framework and the Developers touting it.

JavaScript is the assembly language of the internet - most of the current-generation web frameworks make heavy use of JavaScript, CSS, and AJAX. If you really want to understand how ASP.NET or Ruby on Rails really works, how AJAX works, how JavaScript libraries work. If itching to push the web browser envelope, to really innovate, then this book is a required read. In addition if you’re coming from a staticly type background like Java or .NET, then JavaScript (a functional programming language) will open your eyes to a different programming model. Once you grock the fundamentals of JavaScript you’ll never be able to look at classical languages (Java, C++, .NET, …) with a straight face again. I highly recommend this book to any web developer from any web framework camp.

View my review on Amazon.

I got my first real C++ book
Bought it at the local book store
read it ’til my eyes turned red
it was the summer of ‘99

I found this code amusing… To keep things short, I included one method, but the entire class implementation is similar - my comments describe almost every facet of what I now regard as relatively simple logic and I’ve completely removed all whitespace.

As Steve puts it:

[I was] making up a temporal narrative in an attempt to carve out a mental picture of the computation for myself. These stories I told myself were a critical part of my mental development as a programmer. I was a child trying to make sense of a big, scary new world. - Steve Yegge: Portrait of a n00b

The code:

 //***************************_Command.cpp_*********************************
 //__Creator:_____________Adam Kahtava
 //__Date:________________June 14, 1999
 //************************************************************************* 

 //-----Implements the init method defined in the command.h header file
 //-----Keywords and Modifiers are initialized into keyword[], and modifier[1-5].
 //-----(Keywords and modifiers are all separated by semi-colons).
 void command::init(char data[]){
   int j=0;
   int len=strlen(data);
     for(int i=0;i<6;i++){
     //this for loop is run 6 times, 1st for the keyword,
            // and 5 times for the modifiers, and increments i.
     int k=0;
     char temp[20]={""}; //sets temp to "" (the default)
     //goes through "data" copying string into "temp",
     // until delimiter ";", '\0' is encountered or until len >= j 
     while((data[j]!=';'&&data[j]!='\0')&&len>=j){
       temp[k]=data[j]; //copies useful data from "data" to "temp"
       i++; //increments i
       k++; //increments k
     }
     if(i==0){ //is initiated on first "for loop".
       strcpy(keyword,temp); //copies temp to keyword/
     }
     else if(i>0){ //else if "for loop" has been run more than once.
       strcpy(modifier[i-1],temp); //copies temp to modifier[1-5].
     }
     j++; //increments j
   }
 } 

Notable difference from then and now:

Back in ‘99 I thought everything I wrote was awesome, I thought I was a Code Poet, or a Programming Ninja (with Real Ultimate Power). I thought my descriptive comments were awesome, and probably thought that by removing all whitespace I would be increasing the program’s efficiency. I thought I could learn more by just programming than reading about programming - I recall discarding books and often hacking my way to comprehension. I was clearly disillusioned.

Today I agree with Jeff Atwood that everything I write sucks, I have an obsession with white space, and prefer to thoroughly understand a programming language before verbalizing my proficiency in it. Now I occasionally get complaints that I’m not including enough comments, and I’m still improving and learning. :)

Many people appreciate loosely typed languages for the how expressive, elegant, simple, and Zen like they are - and I agree, but I haven’t always thought this way. You see; strictly typed (statically typed) programming languages have always been the mainstay of my programming vocabulary, C++, Java, and C# were the meat and potatoes of my programming language diet. I used these languages (strictly typed) because they were familiar, I understood how their compilers, IDEs, and comfortable class-based inheritance model worked. If someone asked me whether I liked C# (insert strict typed language) or JavaScript (insert weakly typed language) I would immediately have given preference to the strictly typed language. Why? Because that’s where I felt safe, and that’s what I understood - besides who wants to admit they prefer the “weak” language? My preference wasn’t based on knowledge or experience it was based on my familiarity with the strictly typed culture.

I was suffering from Software Ethnocentrism.

Software Ethnocentrism often entails the belief that one’s programming language or development environment is the most important and/or … are superior to those of other software developers. Within this ideology, software developers will judge other groups in relation to their own particular development environment or culture, especially with concern to programming language, methodologies, behaviour, customs, and religion.  - the derived definition (above) is based on Wikipedia’s article on Ethnocentrism. 

I had the tell tale signs of Software Ethnocentrism:

• I thought strictly typed language were “the bomb”  - the only viable solution :)
• I thought Test Driven Development (TDD) and Unit Testing was the panacea
• I was completely obsessed with refactoring tools like ReSharper and Refactoring
• I thought my Compiler and IDE were superior
• and I had complete faith in multipurpose strictly typed languages like C#

Then things changed. I started diving deep into the hearts of weakly typed languages: JavaScript, Ruby, and LISP. Now today, I wonder If the time I spent hung up on strictly typed languages, TDD, and unit testing could have been better spent by expanding my programming vocabulary. If I had only delved deep into the heart of weakly typed languages (like JavaScript, 3 years ago) and grocked the fundamentals of these other languages, then I could have achieved this richer understanding of programming languages that I have today. It’s important to note, that i’m not stating that weakly typed languages are better than strictly typed languages or vise versa, only that both have their place, are equally useful, and should be used when appropriate.

Do you too suffer from Software Ethnocentrism? Try staving off this programming language tunnel vision, learn a new type of programming language. It might be a better investment in your time than becoming obsessed over a microcosm (like say unit testing and TDD).

Steve Yegge makes some humorous jabs at the static type culture:

… I think we can conclude that people who rely too much on static types, people who really love the static modeling process, are n00bs. … Hee hee. - Steve Yegge: Portrait of a N00b

… I think there’s some mystical relationship between the personality traits of “wakes up before dawn”, “likes static typing but not type inference”, “is organized to the point of being anal”, “likes team meetings”, and “likes Bad Agile”. I’m not quite sure what it is, but I see it a lot. - Steve Yegge: Good Agile, Bad Agile

… you have your slob type systems and your neat-freak type systems, and it comes down to personal preference. The neat freaks (Java, C#, C++, Pascal) know damn well that the slobs (Perl, Python, Ruby, JavaScript) are just as productive. Maybe even more so. - Steve Yegge: Egomania Itself

Cartoon Notes: I took this cartoon from Steve Yegge’s blog titled Egomania Itself. It represents the irony of static type languages where everything is a named type - presumably the owner of the property is naming all his objects so he can remember what they are, but in loosely type languages, If it walks like a dog and barks like a dog, I would call it a dog. Read more about Dog Typing er… Duck Typing.