Forgot your password?
typodupeerror
Australia Education Programming

Good Language Choice For School Programming Test? 407

Posted by timothy
from the 'strailian's-too-difficult dept.
An anonymous reader writes "The Australian Informatics Olympiad programming test is being run in a couple of months. I'm an experienced programmer and I'm thinking of volunteering to tutor interested kids at my children's school to get them ready. There will be children of all levels in the group, from those that can't write 'hello world' in any language, to somewhat experienced programmers. For those starting from scratch, I'm wondering what language to teach them to code in. Accepted languages are C, C++, Pascal, Java, PHP, Python and Visual Basic. I'm leaning towards Python, because it is a powerful language with a simple syntax. However, the test has a run-time CPU seconds limit, so using an interpreted language like Python could put the students at a disadvantage compared to using C. Is it better to teach them something in 2 months that they're likely to be able to code in but possibly run foul of the CPU time limit, or struggle to teach them to code in a more complicated syntax like C/C++ which would however give them the best chance of having a fast solution?"
This discussion has been archived. No new comments can be posted.

Good Language Choice For School Programming Test?

Comments Filter:
  • Strange limitation (Score:1, Insightful)

    by Anonymous Coward on Sunday March 14, 2010 @09:08PM (#31476692)

    What a ridiculous limitation! CPU time is only interesting for hardcore programming these days. If you're writing a cutting edge game or analyzing data from an radio telescope, sure, but if you're teaching kids to program: keep it simple. Teach them how to write their name 1000 times, and if they want to do that faster they'll discover C for themselves.

  • by Jason Pollock (45537) on Sunday March 14, 2010 @09:08PM (#31476694) Homepage

    I'm guessing that the CPU limits are generous and are more about filtering out bad algorithms than bad languages.

    For example, someone using stooge sort instead of quicksort...

    While the language used would increase the budget, the algorithms used will very quickly swamp any language gains.

    When I did programming contests, they were more bound on thought (how quickly you can come up with an algorithm) and then implementation time. Rarely did compute time come into it.

  • by Anonymous Coward on Sunday March 14, 2010 @09:13PM (#31476744)

    I agree. Some problems in programming competitions could be solved with a simple exhaustive algorithm. The main point of the CPU time limit is to make people use better and more creative algorithms, i.e. if you solve it correctly CPU time shouldn't be an issue in any language.

  • Go With Your Gut (Score:5, Insightful)

    by Bob(TM) (104510) on Sunday March 14, 2010 @09:19PM (#31476806)

    Unless these kids already have a programming proficiency, go with your gut.

    The exercise is as much about allowing them to test the programming waters as it is about them winning. If you are starting with a blank slate, that means you need to create an environment that is intriguing. If YOU think Python is the thing, you'll be passionate ... and that is a lot of what makes a good coach/tutor in an olympiad.

    Further, I think you could do a lot worse than Python. It is really a great language and is popping up in a lot of disciplines as the scripting tool of choice. It will perform well and has great characteristics that make it well suited for someone learning the ropes. Plus, the language is modern enough to be relevant should they desire to pursue IT further.

    I would stay away from C/C++. In the hands of novices in a timed activity, I would wager it would be more trouble than it's worth.

  • by Frequency Domain (601421) on Sunday March 14, 2010 @09:22PM (#31476830)
    Any CPU limits should be generous enough to accommodate correct solutions in any of the permissible languages.
  • by gweihir (88907) on Sunday March 14, 2010 @09:24PM (#31476854)

    C, C++ and Java are not an option. They all need years to master and have numerous non-obvious pitfalls. Pascal is pretty limitad and definitly a historic design. PHP is obscure in palaces. Visual Basic still is a bad joke, confined to just one platform and wioth numerous design problems.

    On the other hand Python is fine, with the only thing to master the indention. Not on the list, but Ruby would also be nice. And for a minimalistic, yet powerful language, loot at (again not on the list) Lua.

  • No Perl ? (Score:2, Insightful)

    by Anonymous Coward on Sunday March 14, 2010 @09:46PM (#31477062)

    Probably because there would already by a module that solves the problem.

  • by godrik (1287354) on Sunday March 14, 2010 @09:46PM (#31477064)

    The contest has a cpu time limit which seems to be reasonnable for a programming contest.

  • by gd2shoe (747932) on Sunday March 14, 2010 @09:49PM (#31477080) Journal

    You can't really worry about the runtime limit since it should be rather liberal for a student's competition...

    As the summary says "Accepted languages" (presumably the competition rules), I would tend to agree. They're not going to ask your students to complete something that those languages cannot reasonably accomplish. Bad C++ code will be slower than halfway-decent Python code. Teach a good foundation, and let the chips fall where they may.

    (And I too vote Python, by the way.)

  • Perl !! (Score:4, Insightful)

    by QX-Mat (460729) on Sunday March 14, 2010 @09:53PM (#31477114)

    Perl is very simple to learn (check out "Robert's Perl Tutorial"). Perl allows the programmer to do what he wants - regardless of the style. There's even English.pm. Perl has many upsides ie: it's a powerful parser and indispensable toolkit... and highly embeddable. If there was ever a seed language to learn, it's Perl.

    There's also the fact that Perl programmers are real unix men - and let's face it, you'd rather have real unix graduates than Ruby fannies?

  • Python or Java (Score:4, Insightful)

    by M. Baranczak (726671) on Sunday March 14, 2010 @10:00PM (#31477170)

    I assume you want something that'll give the kids an advantage in the competition, and be useful if they want to start programming seriously.

    Pascal - it was nice back when Reagan was in the White House and Michael Jackson still had his nose, but it's obsolete.

    PHP is for writing dynamic web pages. It's good at what it does, but it isn't really a general-purpose language.

    C and C++ are faster than interpreted languages. That is, sometimes they're slightly faster. And they're almost always harder to write in.

    VB? Go fuck yourself.

    So that leaves Java and Python.

  • by Charan (563851) on Sunday March 14, 2010 @10:07PM (#31477230)

    I'm sure the CPU time limit would be generous enough that it won't matter if your programming language is interpreted 10x slower than hand-tuned assembly. They want to make sure you aren't using a brute-force O(n^3) algorithm when a linear one would work well enough.

    Plus, the judges need a rule to allow them to terminate programs that may be stuck in infinite loops. Otherwise, a contestant could delay the results of a competition indefinitely.

    (Imagine: "This competition was rigged! The judges killed my program before it had a chance to finish. It was working fine, and I was the first one to submit answers to all the problems. What? So it has a long start up time. You don't have a rule against 100-hour programs.")

  • by Samah (729132) on Sunday March 14, 2010 @10:34PM (#31477432)

    And for a minimalistic, yet powerful language, loot at (again not on the list) Lua.

    You beat me to it. Lua is ridiculously easy to pick up and will give the students a chance to worry about actual algorithms and lateral thinking rather than jumping straight into OOP. For the uninitiated: Lua does not natively support a polymorphic OO environment but it is very easily implemented with metatables.

    Disclaimer: I'm a Lua fanboy. :)

  • by r00t (33219) on Sunday March 14, 2010 @10:43PM (#31477480) Journal

    We can sort of classify the languages into "slow" and "not slow" in various ways.

    • Learning: Pascal is fast. C++ is horribly slow. The rest are moderate.
    • Compiling: While it can't beat "no compile", Pascal is shockingly fast for people used to something like C or Java. C++ is horribly slow.
    • Start-up: Pascal again does fine. Here it's joined by C and C++. The interpreted stuff is typicallly an embarassment.
    • Run-time: Pascal again does fine. Here it's joined by C. C++ can be fast if you treat it like C or if you're a God-like expert in compiler/library details that normal mortals don't understand. The interpreted stuff is typically an embarassment.

    This should come as no surprise. Pascal was intended as a teaching language. None of the other languages was designed for teaching, unless you somehow equate Visual Basic with BASIC.

    The second choice is probably C, but you'll have some issues teaching about declarations/definitions (inside out) and string-related stuff. The meaning of '=' is also not compatible with normal math notation.

    The third choice is probably Java. You get most of the trouble of C, less speed, and greater need for boilerplate sourcecode bloat.

  • by Zillidot (2794) on Sunday March 14, 2010 @11:00PM (#31477560)

    I have competed in both the informatics olympiads and the ACM collegiate programming contests, and in my experience there was a much greater emphasis on algorithms in the informatics olympiad. Whether your algorithm was O(n^3) or O(n^4) did make a difference to the results.

    That said, the choice of programming language only adds a constant factor to the runtime, so your point still stands.

  • Re:Perl !! (Score:4, Insightful)

    by LodCrappo (705968) on Sunday March 14, 2010 @11:26PM (#31477752) Homepage

    I'm a big fan of Perl myself but I wouldn't recommend it for new programmers. The phrase "enough rope to hang yourself" doesn't begin to describe it. It's also probably a bad choice in this scenario because it isn't on the list of accepted languages, although if you were decently skilled I'm sure you could write one liner to translate your perl source into any one of the accepted list.

  • Re:My $0.02 (Score:3, Insightful)

    by Joce640k (829181) on Sunday March 14, 2010 @11:35PM (#31477800) Homepage

    C shouldn't even be on the list, neither should Pascal.

    C++ is my favorite language but there's no way you can learn it in that time scale.

    VB is almost obsolete and too much tied into to MS APIs.

    That really only leaves Python or PHP.

    Python is cute but it's not really very good for writing software that has to be published/deployed.

    I'd go with PHP because it's much more useful for getting jobs, etc., after the competition.

  • by sydneyfong (410107) on Sunday March 14, 2010 @11:45PM (#31477878) Homepage Journal

    I've participated in local and regional Informatics Olympiads, and went to the IOI once. I was involved in training local students a few years ago, so I know quite a bit of the ins and outs of these competitions.

    All the languages have pros and cons, but PHP and VB obviously aren't suitable (if only for their encouragement of crappy coding practices). Java offers little advantage over C/C++, and it forces OOP onto you so it adds an unnecessary layer of complexity for the students.

    The "industry standard" of competitive programming is C++, since it offers near-C speed with the power of various algorithms (eg. sort) and data structures ( maps, sets, priority queues ). Those who intend to take the competition seriously should be using C++ as their primary language. But then judging from your requirements the vast majority of your students won't fall into this category, so I wouldn't recommend C++, at least not at this stage.

    Python generally is a good first language for its simplicity and power. There are a few problems with using python for competitive programming though. First, speed can become a problem for *some* contests, which have rather tight runtime constraints. The contests that cater for a wide range of languages are usually better in this respect, but a lot out there are primarily C/C++/Pascal/Java. Secondly, the fact that python supports a range of built in advanced data structures and algorithms means that you may lose the chance to teach them how to implement the basic stuff, eg. using a binary search tree to implement a map (typing `` mymap = {}; mymap[foo] = bar; '' is surely easier than implementing a BST yourself). You might ask why learn to reinvent the wheel when most modern languages provide these features, but these data structures and algorithms is the core of informatics olympiads, and one needs to learn from the basics. That being said, if the timeframe is just 2 months, I think teaching python might be most rewarding for the students.

    C and Pascal are basically on the same league. C is a bit more "archaic" than Pascal in terms of the way it does things, but feature-wise they are roughly equivalent. The languages are simple, fast, and bare bones enough to force the user to implement the basic stuff. In the long term they are good languages for teaching data structures and algorithms, but require a bit of patience on the part of the student since you need to know quite a bit before you can do anything "flashy" with them.

    My experience with most average students is that they usually struggle to form precise ideas on what to tell the program to do, and then when they do have rough ideas they then fail to write a syntactically correct program, and if they really do write a syntactically correct program the program usually fails on correctness for most inputs, or simply do the wrong thing. Running time shouldn't be a concern before the students actually get a correct program, and my experience is, unless you have really really bright students, most of them probably won't be able to come close to writing a correct program within competition constraints, so don't worry too much about running time.

    In short, I recommend python, but in the long term you might want to think about using C/Pascal. And if you restrain yourself to a subset of C++, it might work too.

  • by O('_')O_Bush (1162487) on Sunday March 14, 2010 @11:55PM (#31477954)
    Even though I do 99% of my work in Java, C/C++, VB, or shell scripts, the few times that I have written in Python, it was an absolute pleasure.

    The libraries that I used kicked Java/C++ library asses, to the extend that what was going to be a "short" 500 line program in Java dealing with parsing images, turned into an 80 line program in Python.

    The best part is, it was extremely easy to debug as I wrote, since just about any line I dropped into the source file, I could check with the interpreter.

    It also only took half an hour to pick up from other OOP languages.

    I <3 Python
  • by u.hertlein (111825) on Monday March 15, 2010 @12:10AM (#31478064)

    * Learning: Pascal is fast. C++ is horribly slow. The rest are moderate.
            * Compiling: While it can't beat "no compile", Pascal is shockingly fast for people used to something like C or Java. C++ is horribly slow.
            * Start-up: Pascal again does fine. Here it's joined by C and C++. The interpreted stuff is typicallly an embarassment.
            * Run-time: Pascal again does fine. Here it's joined by C. C++ can be fast if you treat it like C or if you're a God-like expert in compiler/library details that normal mortals don't understand. The interpreted stuff is typically an embarassment.

    What I find interesting is that no one has mentioned that what's actually more important than the language itself is the available libraries/toolkit/frameworks that it comes with.

    Let's face it, after you've learned a few languages it pretty much comes down to "what is printf called this week?" when you pick up a new language (functional languages aside). Getting familiar with frameworks is actually what takes the most time.

    C++ and C are pretty bad in this department. STL is nice but only gets you so far. Threads? Nope (not yet). Sockets? No. XML/encryption/whatnot? Sorry. You have to write an awful lot of code to come up with this or find (and learn!) a support lib that does this. (I do C++ for a living.)

    So I'd say: Python. Or C#/Mono (but that's not on the list, why?)

  • Re:My $0.02 (Score:3, Insightful)

    by pem (1013437) on Monday March 15, 2010 @12:36AM (#31478186)

    Python is cute but it's not really very good for writing software that has to be published/deployed.

    I can only respond to this statement by quoting Wolfgang Paul: "Not only is it not right, it's not even wrong!"

  • Re:Psyco (Score:3, Insightful)

    by dougmc (70836) <dougmc+slashdot@frenzied.us> on Monday March 15, 2010 @12:51AM (#31478262) Homepage
    Of course, that's for perl 6 -- which hasn't been released, and it's hard to tell when or if it'll ever be released.

    Personally, I think a lot of the perl hate comes from the perl users getting stuff solved fast and (often) ugly, when the perl haters spend far more time creating their (often) far prettier solutions. If the programs need to be written quickly, I'd say perl would be the language to use (except that it's not permitted, of course.) If the programs need to execute quickly, C -- but it'll take longer to write them. In most cases (real world and contests!), time to write the program is more important than execution time -- though I'm not familiar with this contest.

  • by r00t (33219) on Monday March 15, 2010 @02:05AM (#31478552) Journal

    This is a student's programming contest, right? Why are you even concerned about compile time or "startup" time?

    Normally there is a time limit during which the competition runs. The faster your tools are, the more time you have to write code.

    A kid might need 50 tries to get his program right.

  • Re:My $0.02 (Score:3, Insightful)

    by smash (1351) on Monday March 15, 2010 @02:37AM (#31478670) Homepage Journal
    Eve online has stacks of code written in python. If that isn't "published" enough for you, then Civ4 runs a stack of python code as well.

    PHP is not really what I'd suggest as a good choice. Unless you're doing web development it is fairly unused. And even if you ARE doing web development, its had plenty of bugs and major language changes from release to release.

    PERL would be a better choice from a pure "usefulness in getting a job" standpoint. It can be used for web development, and a whole heap of other tasks.

    But having seen the range of things python has been used to implement, and what I've heard about how easy it is to learn (i'm not a python coder at the moment), I'd agree with the GP that it is a fine choice.

  • Java != slow (Score:3, Insightful)

    by Vapula (14703) on Monday March 15, 2010 @03:55AM (#31478986)

    Well, it's true that the JVM may take some time to start... but once it's running, JIT and other make it run quite fast... You see game servers hosting hundred of players on a "normal" machine (not 8-CPU 4-core or similar), web sites using JSP, ...

    And if you don't start to use the latest API (reflexion and similar) and stick to "standard" java, it'll make you create clean code...

    But I agree that starting the JVM is rather slow... Even slower if you start it in "server" mode (but then, you'll get a speed increase while running the code)

  • by dunkelfalke (91624) on Monday March 15, 2010 @04:09AM (#31479056)

    Pray tell me how a modern Pascal dialect (as used by Free Pascal Compiler for example) is "limitad".

  • by verdante (1661279) on Monday March 15, 2010 @05:09AM (#31479380)

    Having competed in a handful of collegiate programming contests about 10 years ago, the CPU time limit was never even a passing concern. Granted, we were coding in C++, but even in Python, any solution that hits the CPU limit on these contests is quite likely an unnecessarily complex algorithm.

    Python makes for much faster coding and debugging and works on many problems. But there's a whole range of contest problems bomb out in Python:

    1) Large inputs or outputs and short time limits. Python's "print" statement is simply not fast enough for large-output problems.

    2) Billions of booleans. In C++ you would use bitboards and bitarrays, maybe a 100MB worth. Using native Python data structures the memory can run into gigabytes. Using numpy, the bit-twiddling will still be many times slower.

    3) Some problems with tight loops and a time limit is set at a couple times the speed of the author's C or Java solution. Python being 10x slower on such loops takes it over the time limit.

  • Python, Java, and VB (one must assume it's VB.NET, and thus has the same libraries as C#) are definitely what I would suggest on the basis of libraries. OK, you can do C++ with the CLR and CLR libraries, but C++ is *not* a good choice for a first language.

    There's a lot of hate on /. for VB, perhaps because not many Slashdotters have tried any version of the language from the last 8 years, but it *is* a good first language - static and strong typing (by default now, I believe), either procedural or OOP (full support for inheritance, unlike legacy VB), BASIC-style syntax (intuitive and quick to pick up), fully memory managed (real GC, not just ref-counting), structured exception handling (no, it's not On Error Goto anymore), and all the .NET/Mono libraries available (before you ask, yes Mono has a VB compiler/runtime, and once you compile it all down to CIL the libraries are usable by any language).

    Java has about half those advantages plus a lot of silly restrictions (although at least Scanner makes getting keyboard input a lot less retarded than it used to be), but it's still a popular choice for learning a first language, and a practical choice for those who want to make a career of programming (though they should learn multiple languages anyhow). Python is a better choice, and possibly quicker to learn, although I'm not a fan of dynamically typed languages with significant whitespace.

  • by gweihir (88907) on Monday March 15, 2010 @04:34PM (#31487264)

    Well, scripting is not about execution speed, but development speed. You are of course right on the developer angle. Language, process, design method, etc. cannot cause incompetent developers to create good software. That is just the vision by incompetent management (of which there is a lot), because they would like to treat developers as exchangeable components, not individuals that are, on to bottom line, possible worth a lot more than they are.

    However, language can stand in your way, making development more complicated. For compentent, experienced developers, this will just increse development time and increase the number of bugs. For inexperienced developers, it can be catastrophic.

  • by obarel (670863) on Monday March 15, 2010 @05:00PM (#31487666)
    I'm also a Lua fanboy, but for motivation and inspiration I'd use Python and not Lua.

    Just think about this problem: how do you get a directory listing in Lua?

    Lua doesn't have an immense standard libraries. Even though it's extremely powerful, the power is in the flexibility, not in the environment. Of course, there are many many libraries that you can pretty much download and use (depending on OS, of course), but it still doesn't come "batteries included" like Python.

    Also, Lua is very simple to learn, but even then you have to know a bit before you can have some fun. Compare:
    Lua: for _,v in ipairs(list)
    Python: for x in list

    Even for basic loops you have to call a function.

    Compare:
    Lua: print(string.format("Your age is %d", age))
    Python: print("Your age is %d" % age)

    Even for basic output you have to call a function.

    Lua is fantastic, I've used it in many projects - at work and at home. But in my opinion Python is better for "get something working quickly" (i.e. the modern, much much better, equivalent of BASIC as a first language). As my "scratchpad" / calculator / quick eval-print-loop I always use Python.

Every nonzero finite dimensional inner product space has an orthonormal basis. It makes sense, when you don't think about it.

Working...