Tax-Free Guice
I'm speechless. Thanks, Eric.
Wednesday, September 26, 2007
Hi. My name is Bob.
I'm a stay-at-home dad. I used to be the CTO of Square. I also created the Jolt award-winning Guice framework and led the core library development for Android.
Previous Posts
- Silicon Valley JUG @ Google Tonight
- Gavin King on ActiveRecord
- Treader Supports del.icio.us
- Why reinvent the wheel?
- Roof of The Royal Orleans
- Treader: Twitter directly from Google Reader
- Temporary Twitters
- Restore My Faith In Humanity
- The Mechanics of Photo Attribution
- Got Guice on your resume?
7 Comments:
So so so so so so true.
Peace
-stephan
--
Stephan Schmidt :: stephan@reposita.org
Reposita Open Source - Monitor your software development
http://www.reposita.org
Blog at http://stephan.reposita.org - No signal. No noise.
LOL...LMAO... this really makes my day. I declare this the joke of the day
Genius
CONTINUOUS NUISANCE DOUBLE TYPE COGNITIVE DISSONANCE TAX
by Peter William Lount, peter@smalltalk.org.
A "DOUBLE TYPE TAX" is a perfect way to describe any language that forces the user or programmer to "type" as in typing characters the "type" specification of every variable. How tedious typing type information is, and it's only of limited use. Anytime type information is really needed in a program it can be checked at runtime with minimal or insignificant cost. In fact many programs ultimately run faster with type-less languages, aka dynamic languages, such as Smalltalk. This is because many programs tend to be disk bound or thrash the cache anyhow, and significantly because of the poor implementations of class libraries in languages that force type specifications upon poor unsuspecting programmers who don't know any better or who don't want to change and adapt to a world of programming free of type specifications on variables, parameters, etc...
By virtue of their success dynamic typeless languages are valid programming models which drives type-focused programming types crazy.
All type checking is simply redundant at compile time. It's effectively useless except for detecting a few categories of errors and for a few optimizations. Languages with types are effectively not any higher level than C or Assembly language.
What especially drives "type fiends" nuts is that there are those of us who recognize that dynamic languages are far superior to typed language programming paradigms. We rain on their parade.
Types have their purpose but it's very limited and should be banned from programming languages for the most part. The main difference between a type and an untyped language is that in untyped language, say Smalltalk for example, the so called "type" information is attached to the object itself and not to the variable/parameter slot. This allows tremendous flexibility and most importantly FREEDOM from the DOUBLE TYPE TAX.
The DOUBLE TYPE TAX creates rigidity in a program and leads to a proliferation of code to deal with specific variants of the code to implement each variant. This unnecessary code growth is a source of bugs and takes time; time that costs the programmer and their boss, client, customer additional money and resources. Most of all it takes time, the most precious resource that any living being with a shelf life (i.e. that means you) has.
The Smalltalk IDE is essential in working to reduce and eliminate "type" bugs from the code. Often they are caught in the development cycle, which by the way is just a few seconds compared with many minutes for other languages like Java. Code coloring solves many problems with messages that might otherwise result in an error.
The TYPED Variables and Parameters in typed languages won't save you from the need for automated test cases which are essential to ensure program correctness. This is true for Java and all typed languages. Wise programmers (and wise development team leads) use automated "unit testing" on their objects and automated "use case tests" on their human interface and systems interface components. These automated tests will catch the vast majority of errors that the proponents of "typed languages" want caught. For the other errors, Smalltalk has a fully realized run time error-exception catching and handling system that puts Java's try-catch to shame.
Not even Java's vaunted type system catches all "type" errors at compile time. Witness the proliferation of "null pointer" errors and their ilk in any serious project.
Runtime "type/class analysis" during testing and during production usage can find out all the "classes" that pass through variables and parameters in Smalltalk methods. The untyped dynamic language, "Self" (a descendant of Smalltalk), implemented a level of this that was used to custom compile special versions of methods for each "class" of objects being passed into a method invocation, often generating many different versions. This proved highly effective and Self set speed records in the process. Self is a perfect example of making a language simpler but not simplistic; a perfect example of providing a clean programming language without unnecessary concepts like "types" on all the variables while finding ways to optimize for performance.
The feed back of variable and parameter "types or class" information can be added to Smalltalk and other dynamic untyped languages easily. This would provide a number of advantages and capabilities in the Integrated Development Environments (IDE) of languages such as Smalltalk. For example the runtime class info of what's flowing through variables and parameters could be shown in a method browser much like syntax and valid known message names are highlighted. This provides programmers with information that could help them improve their designs. One could imagine seeing that the way the method is written could be adjusted to make it more generic and allow an even wider range of object "types" or object instances of various class to flow through the method - thus greatly expanding the capability of the program and likely reducing it's code foot print in the process.
Mandatory type information added by the programmer takes programming into a land of details usually irrelevant to the task at hand. The programmers end up focusing way too much on computer science (what ever that is) and not enough time focusing on the problem they are being paid to work on. It's really an economic issue that costs companies that used typed languages huge amounts of resources in terms of extra people, larger time budgets, larger monetary budgets and larger and more difficult debugging and maintenance cycles.
The bottom line is that dynamic languages have proven themselves as viable and highly reliable systems. Static typed languages or any language that forces variable and parameter types upon you are going to force you to pay the DOUBLE TYPE TAX - one payment for all the extra language goo they make you type with your fingers, and another larger payment in brain power that you have to use to specify all the variable and parameter type information all the time, every time you want to use a variable.
Message passing unary, binary and keyword languages, such as Smalltalk, have the added advantage that they are "literate programming" as well; in essence a Smalltalk method is often self documenting and usually lacks a need for comments as the language flows naturally into ones mind. Some projects even eschew comments due to this aspect of Smalltalk, although I recommend any comments that clarify the programmers intentions or the specifications or details that just aren't apparent from reading the code. Due to the nature of Smalltalk often methods are short, in fact many teams prefer methods to be less than ten lines or even three lines or less if at all possible. This makes methods highly reusable and reconfigurable. This makes their objects more flexible.
You'll often see typed languages have methods that run into many pages as common practice. This means that there will be many more "duplicated" chunks of code. Even if a team uses the best practices from Smalltalk and writes short Java methods it's simply not possible for Java methods to be as short overall in a large project as a result of the extra syntax type goo that must be typed by programmers fingers and minds.
Basically types steal too much brain power for their worth. They can be caught using a good IDE, a well thought out set of objects and classes, a good testing methodology, and at runtime.
Typed languages gain very little from their typed capabilities and they pay a huge price too. Too huge a price to stay competitive in this busy business world.
May you be type free. Freedom from the DOUBLE TYPE TAX is not only possible but will alter your programming for the better.
The CONTINUOUS TAX definition that Crazy Bob and Cederic use is just nonsense. As James Robertson pointed out you've got it backwards, the CONTINUOUS TAX really refers to the CONTINUOUS NUISANCE THAT TYPING VARIABLE AND PARAMETERS brings you. Besides you must pay the DOUBLE TYPE TAX plus the WHAT ARE THE PARAMETERS TAX all the time with typed languages that use the round parenthesis unnamed parameter lists. That's a lot of TYPE TAX to pay for TYPES. Oh, yeah, there is even more, the COGNITIVE DISSONANCE AND COMPUTER SCIENCE TAXES that take you away from the actual problems at hand in the solution space down into the unless and irrelevant computer science details.
I taught a programmer Smalltalk who had used types for over 30 years in his day to day professional career as a civil engineer. After one month of using Smalltalk, he came into my office and told me "Smalltalk is amazing, I can do 90% civil engineering and only 10% computer science!". He was very excited. He used Smalltalk for sixteen years after very successfully in his career and business until he passed away recently. The programs that he (and I) wrote still provide a huge competitive advantage for that his old firm and will do so for many years to come.
Type are simply unnecessary and are a hindrance for leading edge software systems. Eliminate types whenever you can. Use a powerful dynamic literate language with unary, binary and keyword message passing syntax (UBKMPS) such as Smalltalk. Get it on today.
You can download and use one or more of the many versions of Smalltalk. See http://www.Smalltalk.org/versions for information on them.
I really cannot see how the above very long statement about SmallTalk relates the the, by the way very cool, joke in this blog-entry.
Thank you bob, i am also a maintenance programmer for the moment, and i cannot re-write the entire application in SmallTalk.
Guice has really helped me out of a lot of problems, and it tastes good too :-)
Hi jesper t,
It relates via what James Robertson had to say about Continuous Tax, Continuous Confusion.
When working on a team or as a maintenance programmer one is by definition of the hierarchy and circumstances often limited in which languages and tools one can choose. Often this choice is a single language with very specific tools, although which tools can be used is usually more flexible than which language. I empathize.
Smalltalk tastes good too. You might like it. Cheers.
hahaha
Post a Comment
<< Home