Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

TopCoder: Programming is Fun Again

By jmzero in Technology
Mon Dec 12, 2005 at 10:11:44 AM EST
Tags: Software (all tags)

When you bought your current computer, it probably didn't come with a manual on programming. Many of you will likely remember a computer from your youth that did - a TRS-80, Commodore 64, or PCjr perhaps. If you're a bit younger, you may remember puzzling over the source to "gorillas.bas" on a school computer or popping up "Hello World" in Visual Basic without being quite sure how that worked. Do you remember enjoying programming? Over the last few months competing on TopCoder, I've rediscovered some of that confusion and frustration - and glee.

What is TopCoder?

TopCoder, as a company, does a few things - but the central attraction is the algorithm competions. These are events in which programmers are presented with a set of problems - ranging from trivial to very difficult - and are tasked with writing functions (in any supported programming language) that solve those problems. The winner is the one who, after about an hour, has finished the most solutions in the fastest time.

I won't be going into specifics of how the competition works - to get that you can visit the TopCoder website. Rather, this will be a quick overview of what TopCoder is and why you might want to give it a try.

What's the point?

TopCoders compete for a variety of reasons. While there is money for winning in competition (especially for big events like the annual Google Code Jam), that money is as out of reach for the majority of competitors as the World Cup is to the majority of footballers. More modest success, though, may still impress potential employers, who sponsor TopCoder competitions with the hope of recruiting talented participants. This is of special value to competitors in out-of-the-way places, for whom TopCoder provides a unique way to demonstrate one facet of programming aptitude to employers in larger centers. As a fairly experienced, employed programmer, to me TopCoder is just a hobby - and I expect no more out of it than pleasant diversion and the joy of mental exercise.

What are the problems like?

There's really quite a range - and the best way to get an idea of this is to either compete or to look at the problem archive on their site. Either way is free, but requires registration so I can't link to problem descriptions directly. Instead, I'll give some general idea of what kinds of things you might expect.

A beginner problem might be to pick words out of a list that have certain characteristics - maybe ones with more vowels than consonants. In solving this, one would write a function that accepted an array of words, inspected each one to see whether it met criteria, and then passes back the ones that do. A medium problem might be to inspect a certain position in a game of tic-tac-toe, and predict who will win given optimal play. A difficult problem might ask a programmer to design the best schedule for airline flights given a certain set of cities, populations, costs, and other constraints.

In practice, the problems deal with a stupefying variety of situations - and are designed and constrained to force programmers to think of innovative solutions. The problem subject matter is sometimes realistic, sometimes fanciful, sometimes abstract or math-based. At times, the problem is simple to state but horrifyingly complicated to answer. Other times, the problem description is pages long and challenging just to comprehend - and yet yields to a solution just a few lines of code long. The most successful coders leverage knowledge from geometry, set and graph theory, calculus, physics, and computing in finding efficient ways to tackle problems. Often, a single problem can be approached successfully as an analog of a physics problem with a known formula, as a calculus problem, as a dynamic programming puzzle (ie. a problem that can be broken down into more manageable subpuzzles or "stages"), or as a system to be solved via a more arcane technique like gradient analysis. You don't need to know every relevant subject - but helpful insight can be gathered from a surprising breadth of fields (that aren't always centered on computing).

And this is fun?

If you like mental challenges, then yes it is. It's a mental game unlike any other, and in some ways sours you for other mental challenges. In TopCoder, you become accustomed to solving whole classes of problems at once, relying on the computer to do the grunt work while you cut right to the substance. For example, my wife enjoys Sudoku, while to me it was only fun once. With a TopCoding perspective, you don't want to solve one Sudoku layout. Rather, you construct a human-usable algorithm to solve any layout - and end up resenting the work of carrying that algorithm out in solving a specific puzzle

Designing an algorithm to rigorously solve all 9x9 Sudoku problems would likely constitute a "Division I Medium" challenge in TopCoder - a task that the best competitors would complete in minutes. Naturally there are many mental challenges (eg. Chess or Go or recognizing a human face) for which formulating even a basic algorithm is much more complex - but after trying TopCoding for a while, you too may start imagining algorithms for daily tasks. Putting the groceries in your fridge is at one moment Tetris, the next a classic knapsack problem (when you run out of space), and the next a complex optimization problem to make sure high-use items are quickly accessible without blocking visibility of shorter ones.

May the best programmer win?

That's not really the best way to think of TopCoder. The challenges of everyday programming very rarely center on writing complicated algorithms to solve the kind of difficult problems TopCoder presents. For most programmers, most daily tasks are simple and repetitive. A good programmer, in everyday work, is one who can communicate well with users, managers, and other developers, who can write clean, maintainable code, and who can choose the best tools, architecture, and techniques in putting together a solution. For the majority of programmers - in my experience - it's rare that a job arises for which constructing workable algorithms is the difficult part; and even when it is, you normally have a lot more time to think up and implement a solution. In this lies some of TopCoder's allure - it's a place where talented programmers can exercise skills that are generally underused and often atrophied. Many programmers seem to misunderstand this, and bear some resentment towards TopCoder for not recognizing the parts of programming they take pride in. To restate, TopCoder isn't a test of general programming aptitude or intelligence - and there's no reason to feel threatened by it. Even if you suck like I do.

May the fastest typist win?

No. While fast typing is certainly helpful - especially on the easier problems - the time to mentally fabricate a solution will almost always outweigh the time required to enter it. Winners are those who are best at finding ways to attack difficult problems. The tools of speed - fast typing, libraries of code snippets (you can bring in any code, as long as you wrote it), and optimized toolchains (you can use any tool, so long as it doesn't interfere with the TopCoder application) - function more like tie-breakers between top competitors. Going too fast and making an error means not only zero points for that problem but allows other competitors to pick up points by finding your mistake (during the "challenge phase"). If you're mentally agile enough to see to the heart of a problem, you'll normally have enough time to type your solution (though it's worthwhile to get used to the interface before entering a competition).

I could do that...

You're right, you can - though you will need to come in with solid programming skills already developed, as the educational content offered is geared towards the intermediate rather than beginning programmer. It's always free, and it doesn't require anything particular besides a computer and an Internet connection. However, even if you're an experienced, well-educated programmer you may be taken aback by the difficulty of some of the problems and the level of competition (especially from Eastern Europe - see this Business Week article).

Are you a top TopCoder? Statistics suggest probably not. But it's fun to try, and you're guaranteed to learn something along the way. Prepare now, and maybe next time Google Code Jam comes around you can win yourself a T-shirt (which is my goal). You may even find programming fun again. Happy coding.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


What's your TopCoder rating?
o Never tried it. 70%
o Done it, but don't know. 8%
o Gray (0-899) 5%
o Green (900-1199) 0%
o Blue (1200-1499) 5%
o Yellow (1500-2199) 5%
o Red (2200+) 5%

Votes: 37
Results | Other Polls

Related Links
o Google
o TopCoder website
o Business Week
o Also by jmzero

Display: Sort:
TopCoder: Programming is Fun Again | 66 comments (47 topical, 19 editorial, 0 hidden)
Programming as a Child (3.00 / 5) (#2)
by mberteig on Sat Dec 10, 2005 at 07:33:45 PM EST

My fist exposure to programming was on an Apple II+. I had a friend named Ted Cook who told me about "peek" and "poke" and for some reason those words completely hooked me. I was at his house for a sleep-over birthday party. He showed me his computer and showed me a BASIC listing of some sort. I don't remember any details, but I spent the whole night wishing that I could spend more time working on the computer. I was around six or seven years old at the time. My own son, the same age now, plays games with high-quality 3D rendering on one of our several home computers. He spends way more time with computers but has no interest in how they work. Time to change that! Thanks for the reminder.

Agile Advice - How and Why to Work Agile
The C64... (none / 1) (#10)
by BJH on Sun Dec 11, 2005 at 12:08:41 AM EST

...also had PEEK and POKE (indeed, some people would say that's all it had). The first thing I did when I learned of PEEK was, of course, write a program that PEEKed all available memory locations. I imagine most people did the same.

Roses are red, violets are blue.
I'm schizophrenic, and so am I.
-- Oscar Levant

[ Parent ]
I remember ... (3.00 / 2) (#11)
by rpresser on Sun Dec 11, 2005 at 12:39:51 AM EST

my sense of self-pride when i managed, in about 1983 or 1984, to write an almost functional "self-replicating" program in TRS-80 Level II Basic.  It was a one-liner (line 10) whose function was to copy itself, using peek and poke, to the next line (i.e., line 10 would copy to line 20), which would then execute and copy itself to the next line ... Unfortunately, although i figured out most of the required format, I never did find the "end-of-program" pointer location, so my program could finish the copy, but the next line wouldn't run.

I also still remember that on the TRS-80, PEEK(14400) was one of the locations that told you if certain keys were pressed down .. so PEEK(14400) AND 128, for instance, meant that the left arrow was held down. Invaluable for letting the user hold down an arrow key to continue turning or whatever in the game.
"In terms of both hyperbolic overreaching and eventual wrongness, the Permanent [Republican] Majority has set a new, and truly difficult to beat, standard." --rusty
[ Parent ]

The beauty of peek and poke (3.00 / 3) (#12)
by The Diary Section on Sun Dec 11, 2005 at 06:52:28 AM EST

is explained very well here by Jeff Minter. Much nostaligia ensues; I don't think people remember pre-internet just how hard it was to come by information. I certainly recall borrowing knackered all 3rd generation photocopies of odds and ends with promises I'd return them the next day. Great series by the way, well worth reading all the way through.
Spend 10 minutes in the company of an American and you end up feeling like a Keats or a Shelley: Thin, brilliant, suave, and desperate for industrial-scale quantities of opium.
[ Parent ]
A while back... (none / 0) (#30)
by jmzero on Sun Dec 11, 2005 at 07:29:26 PM EST

I found some old C64 code of mine a while back (on a printout).  I apparently hadn't figured out that variable names could be more than one letter.  I knew about GoSub, but never used it (sometimes setting variables so a routine would know where to go back to).  I never did figure out disk access - instead I used big "READ/DATA" blocks to store sprite pixels and game maps and such.  

But if my programming hadn't been so heinous, I guess I wouldn't have had to print it out...
"Let's not stir that bag of worms." - my lovely wife
[ Parent ]

In early MS BASICs (3.00 / 2) (#31)
by rpresser on Mon Dec 12, 2005 at 01:45:13 AM EST

variables COULDN'T be more than one letter. Well, you could type them long, but it didn't distinguish between long and short. LONGVARIABLENAME$ would refer to exactly the same variable as L$.  Not positive if that was true of C64, but it definitely was of TRS-80 and Applesoft and probably BASICA/GWBASIC too.

"In terms of both hyperbolic overreaching and eventual wrongness, the Permanent [Republican] Majority has set a new, and truly difficult to beat, standard." --rusty
[ Parent ]
First *two* letters on C64 - woohoo (none / 0) (#47)
by smithmc on Tue Dec 13, 2005 at 12:43:48 PM EST

variables COULDN'T be more than one letter. Well, you could type them long, but it didn't distinguish between long and short. LONGVARIABLENAME$ would refer to exactly the same variable as L$. Not positive if that was true of C64, but it definitely was of TRS-80 and Applesoft and probably BASICA/GWBASIC too.

On the C64 (and other Commodore machines), the first *two* letters were significant. Talk about sophisticated, huh?

[ Parent ]

Argh. (none / 0) (#51)
by rpresser on Tue Dec 13, 2005 at 05:48:37 PM EST

You have jogged my faulty memory.  TRS-80s used the first two letters also.  And letter/number combinations like A9 or W7 were okay, too. But no underscores.
"In terms of both hyperbolic overreaching and eventual wrongness, the Permanent [Republican] Majority has set a new, and truly difficult to beat, standard." --rusty
[ Parent ]
easy to fix this (3.00 / 3) (#20)
by tkatchevzombie on Sun Dec 11, 2005 at 02:43:44 PM EST

don't buy him any games, so that he's forced to write his own.

[ Parent ]
I had to think about this... (none / 1) (#35)
by Resonant on Mon Dec 12, 2005 at 03:12:48 PM EST

but I just came to the realization that is exactly what my parents did for me, without the intentional bit.

When I was younger we didn't really have money to burn on video games, but I was really into RPG's. So I made my own text based ones in QBASIC and had a hell of a time.

Ahh, nostalgia.

"I answer, 'This is _quantitative_ religious studies.'" - glor
[ Parent ]
well, times change (3.00 / 3) (#33)
by The Diary Section on Mon Dec 12, 2005 at 10:06:31 AM EST

when I was a kid my old man was peturbed that I spent all my time messing about on computers (yay, ZX-81) but had no real interest in electronics (ie. how they work).
Spend 10 minutes in the company of an American and you end up feeling like a Keats or a Shelley: Thin, brilliant, suave, and desperate for industrial-scale quantities of opium.
[ Parent ]
0, abstain. (2.33 / 3) (#6)
by self anonymized on Sat Dec 10, 2005 at 10:10:09 PM EST

Programming was never fun, at least not for me.

Windows API (2.60 / 5) (#15)
by cronian on Sun Dec 11, 2005 at 11:30:09 AM EST

Programming is fun until you meet the Windows API or MFC. Then, it is blah, blah, blah, so this program can d just about nothing.

We perfect it; Congress kills it; They make it; We Import it; It must be anti-Americanism
-1 boring. (1.00 / 3) (#23)
by The Amazing Idiot on Sun Dec 11, 2005 at 04:19:21 PM EST

Tried two practice competitions (none / 0) (#25)
by caine on Sun Dec 11, 2005 at 06:00:48 PM EST

And, well, it's fun and nice but the lack of support for C (and other languages one might want to write in) makes it not for me.

They also seemed to want to have an awful lot of personal information when signing up.


Well, they do have C++.. (none / 1) (#27)
by jmzero on Sun Dec 11, 2005 at 07:15:05 PM EST

You can write in C++ - does the C code you want to write include a lot of stuff like "int class;"?

It is true they don't support many languages - but unless you were hoping for a functional language (which is certainly an omission), I'd imagine most programmers should be reasonably satisfied with one of C++, Java, VB or C#.

I'd categorize their registration form as "moderately annoying" - but understandable in that they are giving away cash prizes, and want to make it somewhat difficult to sandbag in division II.  But that's certainly a legitimate complaint if you're just looking to practice.
"Let's not stir that bag of worms." - my lovely wife
[ Parent ]

If it were tailored toward real hackers... (none / 1) (#32)
by skyknight on Mon Dec 12, 2005 at 07:44:04 AM EST

then they would have Perl, Python and Lisp. I mean, come on, their UI is just a pass-through agent to a back-end compiler. They are being too lazy and dismissive to write a simple test harness in each of those languages to pipe in the problem and parse the solution. No serious hacker, when banging out a prototype solution to a novel problem, would go to C++ or Java. These are heavy weight languages best suited to large scale software engineering projects, not quick 100-liners that you're blasting out at rocket speed. It doesn't speak well of Top Coder that they don't understand this.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
I'd like to see some more languages... (none / 1) (#34)
by jmzero on Mon Dec 12, 2005 at 10:41:41 AM EST

...especially a functional one or two - if only to see how they compare (they wouldn't do me much good at this point).  To some extent, I think they pick languages based on sponsor demands - and the sponsors either have a horse in the race (ie. Sun and Microsoft) or they are looking for people who will be developing in one of these languages.  

That said, the best guys on TopCoder (Petr, SnapDragon, Eryx, Tomek, etc..) are ridiculously good at what they do - and it's hard for me not to consider C++ to be a well-suited language after watching Petr bang out 3 solutions in 20 minutes (with the code all so elegant it depresses me).  I don't think you can really appreciate the level of the talent there until you try a few problems.

Any "real" Lisp hackers are also certainly welcome to cross-compile into C and submit that - though there is a restriction on total program length (not sure what exactly) so that might be a tall order.  
"Let's not stir that bag of worms." - my lovely wife
[ Parent ]

Just because a ninja... (none / 0) (#40)
by skyknight on Mon Dec 12, 2005 at 08:00:13 PM EST

can wield a battle ax better that most other people does not mean that a battle ax would be his weapon of choice. It may very well be the case that these uber-l337 guys, when using their least favorite language, can kick the asses of anyone regardless of the tool that they use, but they might still be happier using another language. Myself, I can write C++ and Java plenty competently, but that doesn't mean that I want to use them for everything.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
I agree, to an extent... (none / 0) (#52)
by jmzero on Tue Dec 13, 2005 at 06:04:42 PM EST

I agree many coders would pick some other language, and some would be significantly faster in their "native tongue".  And to some extent, the best guys' C++ code ends up looking like a new language anyway - it's usually full of macros, templates, odd operators (<?=, etc..), and oddly-named-but-standard functions (eg "ntoia", which generates an integer array which corresponds to a numbered permutation, using some arcane math - and appears regularly in solutions).

That said, I really don't think it ends up being that important.  On the hard problems, you either come up with a good strategy or you don't.  The actual implementation of "dp on current+next/x/y/val" is going to look much the same in any language.  In any language, you're either going to realize how to work around that corner case and write up a good test for it - or you aren't.  And the implementation of those things is going to be about the same in any language - (functional ones excluded to some extent).
"Let's not stir that bag of worms." - my lovely wife
[ Parent ]

Functional ones excluded (none / 0) (#55)
by Thought Assassin on Tue Dec 13, 2005 at 08:12:19 PM EST

Seriously, who wouldn't use a functional language for these kind of problems? That final glib exception negates your whole post...

Anyway, if typing speed helps as claimed, surely being able to express your algorithm in a more succinct manner is going to be some advantage? (Presumably any real contenders will find the right algorithm quickly enough)

[ Parent ]

Indeed (none / 0) (#57)
by jmzero on Tue Dec 13, 2005 at 11:38:35 PM EST

I would like to see how someone skilled with a functional language would do - and I didn't mean to be glib there.  It'd be interesting to see, and I wouldn't try to predict how things would go.  

Finding a correct algorithm, though, is certainly not a foregone conclusion for anyone on the more difficult problems.  Sometimes, without the correct background knowledge, even the best coders will be left with too much wheel to re-invent in too little time.
"Let's not stir that bag of worms." - my lovely wife
[ Parent ]

Plugin (none / 0) (#38)
by wildclaw on Mon Dec 12, 2005 at 07:29:00 PM EST

Their framework consists of a fairly extensive plugin model. I personally use a plugin that will automatically save any problem I open to disk, including the complete test suite for that problem. I will then use VS.NET to write/test the solution before finally loading the solution back into their framework and submitting it.

Supporting more languages would be nice, but you can't have everything.

As for your comment about what language "serious hackers" use, I can only shake my head and laugh. A real hacker will use the environment that is availible to him to the best of its ability.

Also, the implication that C++ and Java are heavy weight and not fit for writing small code snippets is not true. While static typing usually means having to write a little more, it is easily outweighed by the fact that static typing catches certain types of bugs at compile time. Also, as the article submittor mentioned, typing speed isn't that important. The real skill lies in quickly coming up with an algorithm, and that has nothing to do with writing in the solution.

[ Parent ]

You would do well... (none / 0) (#39)
by skyknight on Mon Dec 12, 2005 at 07:56:26 PM EST

to read this. In short, strong typing is a crutch. Compilation is a rather low bar when it comes to testing the correctness of code. If you're actually going to test something properly, then you need to run it through unit tests, and having such tests pass provides you with assurances that are a super set of the assurances you get from having your code simply compile. To me, this issue is akin to file locking with version control systems. It's the kind of misfeature after which people lust when they don't really understand their craft all that well.

Regardless of whether you think typing speed is an issue, the run/debug/modify cycle is certainly longer for compiled languages when you're testing on really small inputs. This is indisputable, unless of course you like to dispute things for the sake of disputation.

Also, I'm inclined to argue that a hacker is as much defined by the kinds of things that he refuses to do as he is by the kinds of things that he does. C++ and Java just aren't good languages for banging out projects that are on the scale of miniature prototypes. Anyone who has spent significant time working in Perl/Python and Java/C++ can tell you as much.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Blind leading the blind (none / 0) (#42)
by Thought Assassin on Tue Dec 13, 2005 at 02:07:30 AM EST

Yes, the article points out a lot of flaws in C++ and Java (which also apply to other languages with weak static typing and no type inference). It doesn't point out any flaws in static typing.

It points out that static typing doesn't remove the need for testing. It doesn't negate the fact that static typing removes the need to test _some_ things, and the more expressive your type system, the more things you can prove instead of testing.

It seems to also neglect the benefits of static typing to _reading_ and maintaining code.

[ Parent ]

Oh, be serious... (none / 0) (#45)
by skyknight on Tue Dec 13, 2005 at 08:12:42 AM EST

You're not actually going to argue that C++'s or Java's iteration over collections is cleaner than doing it in Perl or Python are you? I would say that readability is more a function of the architect of the language and the person writing in it rather than whether or not you have strong typing. A type on a variable is a crutch explaining its purpose. It's way more important that a variable have a descriptive name than to have its type specified.

Bad programmers will write illegible, awkward and unmaintainable code in any language. This is an invariant. All static typing does is give you a few hints when reading code written by a talentless hack. Far better is to avoid working with such people. A good programmer will make his code readable by breaking it into well organized and descriptively named modules, classes, and functions, and provide variable names that are well tailored to both their purpose and scope.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
stfu pls (none / 0) (#49)
by tkatchevzombie on Tue Dec 13, 2005 at 01:53:35 PM EST

you missed the point of the parent comment completely.

also, you misunderstand the meaning of 'static typing'.

[ Parent ]

What he said. (nt) (none / 0) (#53)
by Thought Assassin on Tue Dec 13, 2005 at 07:42:58 PM EST

[ Parent ]
The remainder (none / 0) (#54)
by Thought Assassin on Tue Dec 13, 2005 at 08:00:53 PM EST

Addressing what little tkatchevzombie didn't:

A type on a variable is a crutch explaining its purpose.

Crutches come in handy when your leg is injured.

All static typing does is give you a few hints when reading code written by a talentless hack.

Guess what? Noone writes perfect code all of the time.

The benefits of static typing don't apply all of the time, but since they come for free, who cares? Also, type systems are becoming more and more expressive, so you can replace more and more of your testing with proofs. I'd like to think that before you hang up your keyboard, automated testing will be all but obsolete.

[ Parent ]

Be serious. There is no free lunch. $ (none / 0) (#56)
by skyknight on Tue Dec 13, 2005 at 08:30:08 PM EST

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
right, (none / 0) (#59)
by New Me on Wed Dec 14, 2005 at 08:21:05 AM EST

since when is it free? You have to write more code, and that code will have to more crippled because of ST.

"He hallucinated, freaked out, his aneurysm popped, and he died. Happened to me once." --Lode Runner
[ Parent ]

What's the cost? (none / 0) (#60)
by Thought Assassin on Wed Dec 14, 2005 at 09:45:23 PM EST

So why did neither you nor the article explain exactly what this hidden cost is?

[ Parent ]
The cost is your time and effort in writing more (none / 0) (#61)
by New Me on Thu Dec 15, 2005 at 02:18:25 PM EST

"He hallucinated, freaked out, his aneurysm popped, and he died. Happened to me once." --Lode Runner
[ Parent ]

Cut off in your prime (none / 0) (#62)
by Thought Assassin on Sun Dec 18, 2005 at 10:51:28 PM EST

Looks like your subject got truncated. :(

Writing more what? I typically need to write about the same amount of code (though significantly _less_ when managing particularly complicated ad-hoc-polymorphic type structures), but less testing and documentation.

[ Parent ]

Already read it (3.00 / 2) (#43)
by wildclaw on Tue Dec 13, 2005 at 05:04:41 AM EST

I have already seen that article a couple of times and it really isn't that insightful. I have programmed in lots of languages, including Python so I am already familiar with the main concept discussed in the article.

The most annoying thing with that article is that it consistently tries to find things to complain about in Java and c++ while glorifying Python. It even goes so far as to complain that the new keyword isn't needed in Java. While it is true, it is a petty complaint.  The most valid complaint is probably against checked exceptions, but that is Java specific and there is lots of people that agree that checked exceptions are better on paper than they are in reality.

Back to the subject at hand. Of course compilation doesn't catch all bugs. It does however catch more bugs in a strongly typed language than it does in a dynamically typed one. I can agree that it isn't that big of an advantage though.

One funny thing about the article is that actually contains a very good example of why static typing is good. Look at the pets collection in his Python specific example: Cat, Dog, Bob. Bob is obviously not a pet species but the program will run anyway. A strongly typed language wouldn't allow a non pet to exist in a pets collection.

I find it interesting that you think it is obvious that the run/debug/modify cycle is longer for compiled languages without giving any reasons at all. The compile time is negiable for small projects (atleast in c#), and debugging/modifying is much more dependant on the programming environment than the language. Visual Studio 2005 for example allows me to edit code while debugging and have it take effect immediatly.

The biggest advantage of strongly typed languages have yet to be mentioned. Strongly typed languages can take much more advantage of a good programming environment than dynamically typed languages. Both intellisense and refactoring are seriously hampered when dealing with dynamicly typed languages.

Finally I would just like to say that pretty much everything debated up until now plays a very little part in a top coder contest. A top coder problem will rarely need to use dynamic methods calling and static variable declaration doesn't really do much when programming a single method.

[ Parent ]

I'm not convinced... (none / 0) (#44)
by skyknight on Tue Dec 13, 2005 at 08:01:56 AM EST

Yes, the Pet interface prevents you from invoking a function that expects a Pet on a non-Pet object. So what? Again, that strikes me as being a rather low bar for correctness. There are much worse blunders that you can still make, blunders for which you'll need good test code to discover, and that code will (should) provide a super-set of assurances. Then again, this argument is slightly silly anyway, because if you really want interfaces, they you can still have them in languages like Perl and Python. You just create a class with the methods you want and have their bodies be exception throwing that alerts you to their not having been fully specified.

As for intellisense, I'm not all that hot for it. I used it eons ago when I used MSVC++ regularly, and got its benefit again when I used JBuilder for a while. Maybe it's just me, but the times where I actually need help with an API, it's because I don't know the API at all and need to go look up a description of what various methods do. Once I've looked it up once, I generally don't have to look it up again unless I go without using it for a very long time. One might even reasonably argue that intellisense is dangerous, as a method signature doesn't necessarily really tell you what a method does, and so if you can't remember you should probably be looking at detailed docs.

As for speed, the way I see it, with a compiled language you're making a trade-off between up-front costs and long term benefits on execution time. When you're developing code, you're constantly changing it, and thus the investment of waiting around for code to compile into optimized binary or byte code is lost. Surely you note that running javac isn't very quick, and having to run javac followed by java is significantly slower than running perl.

I really don't understand why you think that refactoring should be easier in a strongly typed language. To me, the most important thing in refactoring is having a really good set of automated tests that you can run to make sure that you haven't regressed. Everything else pales in relative importance. I don't know what you think strong typing buys you for refactoring, but even if you can think of something that I haven't considered, I seriously doubt it's nearly as important as having good tests.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
More than correctness (none / 1) (#46)
by wurp on Tue Dec 13, 2005 at 08:57:50 AM EST

Strong typing shows intention and supported functionality.  Of course, here I'm deviating from the discussion of hacking, and into maintenance of bigger systems...  When you try to read and modify a function that has no indicators of what calls the parameters support other than the name of the object, you're just asking for trouble.  Support for 'real' (i.e. strongly typed) interfaces, which I understand is under development for Python, is essential to create code that isn't mostly read-only.

Also, when you start arguing about people having to run javac, you show that you're way out of date on Java development.  I was a pure command line guy for a long time - I used either vi or Emacs + JDEE, I did manual compilation cycles, etc.  None of the IDEs had enough to offer to make up for losing the editing bliss of vi or a well configured Emacs, and they introduced problems by hiding classpath and configuration details.  Eclipse changed all of that for me.  The intellisense, refactoring support (much of which would be impossible without strong typing, e.g. method renaming), and automatic invisible compilation just fundamentally change Java development, imnsho.

I have done only a little Python.  I was really excited by it, until I heard reports from a friend of his difficulties understanding and contributing to Zope, and I understood the validity of his arguments.  Now I still use perl and/or bash for all my 1 to 200 line scripts (because perl has better integrated regular expression support), java or C++ for my bigger projects, and python for essentially nothing.

That said, TurboGears has my interest up for Python again.
Buy my stuff
[ Parent ]

All my variables are named after C++ keywords (3.00 / 2) (#36)
by caine on Mon Dec 12, 2005 at 05:03:55 PM EST

Nah. But it's a bother taking in and returning vectors and other crap when I don't want to. Also I don't want to waste valuable minutes or seconds because I don't remember the syntax for a STL map or whatever.


[ Parent ]

True (none / 0) (#37)
by jmzero on Mon Dec 12, 2005 at 06:02:51 PM EST

I had forgotten about their tendency to pass in vectors - I'd have to brush up on how they worked as well.  

In whatever language, it does take some time to get used to their interface and how they expect things passed back and such (and what libraries are available and all that).
"Let's not stir that bag of worms." - my lovely wife
[ Parent ]

Who says you have to? (n/t) (none / 0) (#48)
by smithmc on Tue Dec 13, 2005 at 12:45:03 PM EST

[ Parent ]
Full C++ (none / 0) (#63)
by yamla on Mon Dec 19, 2005 at 03:48:44 PM EST

Does it support all of C++?  For example, std::vectors, std::multimaps, std::strings?  What about boost.org extensions to C++, some of which will be part of C++0x?

[ Parent ]
I'm not sure what they have available. (none / 0) (#64)
by jmzero on Tue Dec 20, 2005 at 11:54:07 AM EST

I know they use vectors a fair bit, and I assume they'd have most standard stuff (though likely not the boost stuff) - but I don't really know.  I'm not actually even sure what compiler they use.

Your best bet is to try a practice problem or two in their applet, and see what you can get away with.
"Let's not stir that bag of worms." - my lovely wife
[ Parent ]

Combinatorics are important... (none / 0) (#41)
by gmol on Tue Dec 13, 2005 at 01:02:55 AM EST

I don't know about anyone else, but I would do fine within my school for math contest but get thrashed when going up to only slightly higher level comps..

The real problem was that I at the end of high school, I relazed that I never really learned combinatorics.  I am better at it than many people I know, but I still have this insecurity when talking to comp sci guys and stuff...

They should really teach that stuff at a more basic level, a lot of mathematicians advocate teaching real algebra at a much younger age instead of just arithmetic.

I was never a fan of this in college (none / 0) (#50)
by mrcsparker on Tue Dec 13, 2005 at 02:40:49 PM EST

It just seems to breed bad coding practices.  I would enter these contests every year for the extra credit and spend a few days after unlearning all of the bad habits that come out in a timed coding competition.

Sounds like the ACM Programming Competition (none / 0) (#58)
by polyglot on Wed Dec 14, 2005 at 01:04:56 AM EST

this one at which, I would point out, us Adelaideans are currently kicking arse.
"There is no God and Dirac is his prophet"
     -- Wolfgang Pauli
Major (none / 0) (#65)
by MissMatch on Sat May 13, 2006 at 03:18:32 PM EST

When i entered HS i was into programming and after taking it for four years at school, I realized that it wasnt for me, not because I wasn't getting good marks (88%+) but because I just couldn't stand doing things exactly the way school told us, I wanted to write code my way, figure out problems my way, schools basically tell you this is the problem, and you MUST use this method to solve it, example (use these function names, bla bla) I never thought id switch from Comp sci to anyhting else but I did to Business and my exuse to my parents "Oh, the demand for programmers has fallen, it would only make sense to go into biz" bla...i still program, on my own terms, i teach myself from other code and hell yea i worked with gorillas.bas when i was 11 to make AOL proggies LOL!

Bad CS Program (none / 0) (#66)
by NovemberDelta on Fri Aug 04, 2006 at 05:39:27 PM EST

Sounds like you just ended up in a pretty bad CS program, possibly with an incompetent teacher (I find usually incompetent CS teachers will require you do things exactly by the book, because if you don't they wont be able to tell whether it's right or wrong...).

I know in my CS classes, I've ended up with a good teacher. He simply tells us "This is what I'm trying to get you to learn. Now write me a program that accomplishes $X."

"I'm trying to get you to make use of a function that takes and argument and a return value, now write me a program that takes the dimensions of a room and returns the surface area in square feet."

This way, there was no inane, unrelated requirements. As long as we used the things he needed us to use, beyond that we could basically do whatever we wanted. For example, I think in that "surface area" one, I ended up with a "Room" class inhereting from a "Cube" class and a whole bunch of other really pointless stuff just to kill time.


[ Parent ]

TopCoder: Programming is Fun Again | 66 comments (47 topical, 19 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!