Fog Creek Software
Discussion Board




Learning new paradigms

I hate the word paradigm, but it works well here.

The recent thread on jobs by programming language made me think about this again. The question was on learning new languages quickly (i.e. 1 week's time).

Some languages, toolkits, etc. are designed to work in a certain manner. Predicate-logic languages clearly are not meant to work in a procedural manner.

For example, a little over a year ago I wrote a simple customer billing application in Java with swing. It was my first Java GUI app.

It was horrible. The entire code was a collection (well still is, hasn't needed to be changed enough to warrant refactoring) of ugly hacks to get around the API's.

The reason it turned out so bad was that I didn't understand the Composite design pattern it's designed around. Or the Factory pattern: "Wait, I can't instantiate this? I have to use a what? Wtf is a factory?".

I figured out, through the course of developing this app, how these patterns work and the point of using them, and I now respect almost all the API design done on Java's standard class libraries.

But this was a painful process. I could do it again better and faster (and in fact did for a class the following semester), but I shouldn't have to: It should have been write the first time.

Do you guys have any tricks you use to pick up things like this? Or do you just accumulate the experience to know what you're dealing with and just not make mistakes or go down wrong paths as often?

Mike Swieton
Monday, January 06, 2003

There are no shortcuts to learning - practice makes perfect.

Hang in there. Everybody's first applications seem like a mess later on, but you needed to write ugly code before you could understand why it was ugly.

Teach Yourself Programming in Ten Years
http://www.norvig.com/21-days.html

Matthew Lock
Monday, January 06, 2003

No idea if this is the Ultimate Strategy, but this is what I do:  I almost, almost never use my own code at the start.  I spend a lot of time looking at libs and obtain books where people explain their code.  Any area without a lot of prewritten code is probably a research project. 

The strength of Java is in its insane level of documentation.  I never really lost much time trying to grok someone else's code, because the code is already debugged, and I often take it apart when I want to look at items in isolation.  Writing from scratch is an exercise in buggy data-entry.

Another thing I did was be on the lookout for 'programming philosophy' type books.  For example, as you pointed out, Java is enormously influenced by the Gamma/Beck/etc books.  There's also the lisp influence, and unix.  Often it's better to search for an understanding one level lower than the target, since most good design starts there.

YMMV, of course...

Tj
Monday, January 06, 2003

I agree with Tj.  I almost always look at other people's example source code to learn from when starting in a new language before I start hacking any code -- especially if it's for a customer.  There's typically a "standard" or example to base most applications on.  For example, in Java there's the PetShop web application which demonstrates things such as MVC (model-view-controller) design patterns, using Enterprise Java Beans (EJBs) etc.  The same is also present in C# and ASP.NET.  There's the IBuySpy Portal and ASP.NET forums,  etc. 

Just download people's code and see if you can understand it.  You also have to sort of know when the code is crap and not to base your code off that either since there's plenty of wannabe programmers that post their code all over the net thinking they're almost as great as sliced bread. :)

HeyMacarana
Monday, January 06, 2003

For Java, here are two good places to start:

http://www.patterndepot.com/put/8/DesignJava.PDF
http://java.sun.com/blueprints/code/

Tom Davies
Monday, January 06, 2003

Extreme Programming recommends the "spike solution" for experimentation, and I like to use something like it when learning a new paradigm:

Go off and build an experiment, then throw the code away.

The idea is that experimentation is very good, but you shouldn't use important projects as laboratories for experiments.  Instead, explicitly experiment, then use what you learned when you're working on "production" projects.

Brent P. Newhall
Monday, January 06, 2003

*  Recent Topics

*  Fog Creek Home