Archive

Archive for the ‘Programming Languages’ Category

The ASP.NET AJAX Framework is for Dummies

April 21st, 2008

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.

Book Reviewed: JavaScript: The Definitive Guide by David Flanagan

March 26th, 2008

JavaScript: The Definitive Guide by David Flanagan is a great book! When I began reading this book I was convinced that (like many technical books) the first couple chapters would contain the important stuff and the content would slowly digress into page filler, fluff, and the book would become just another monitor stand. But not this book! After finishing the formal chapters I started reading the references – YES, this book is so good I’m reading the references! Flanagan has raised the bar for all JavaScript books – this book is in its 5th edition, and has been reviewed by a couple web Gurus (Douglas Crockford, Peter-Paul Koch).

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.

The summer of ’99: Junior-Style / Newbie Programming

March 1st, 2008

Steve Yegge discusses junior-style programming in his post: Portrait of a n00b. After reading Steve’ post I decided to dig up some of my own newbie code – this code is from the summer of ’99.

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. :)

Author: Adam Kahtava Categories: Musings, Programming Languages Tags:

Software Ethnocentrism: Staving Off Tunnel Vision

February 17th, 2008

Loosely typed / weakly languages are amazing! But… for myself, coming to this conclusion was like an acquired taste.

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.