8th Annual ICFP Contest 72
mauricec writes "Think your favorite programming language is the best one out there? Put it to the test in this year's International Conference on Functional Programming's annual Programming Contest. The contest is coming up in a little under 4 weeks! This year's competition rewards programmers who can plan ahead. As before, we'll announce a problem and give you three days to solve it. Two weeks later, we'll announce a change to the problem specification and give you one day to adapt your program to the new spec. More info on the contest and prizes is on the contest's web page."
Is rewriting cheating? (Score:3, Insightful)
Re:Is rewriting cheating? (Score:2, Funny)
Re:Is rewriting cheating? (Score:2, Informative)
Re:Plan ahead? (Score:4, Informative)
Prediction: more people in this thread will make that mistake.
Re:Plan ahead? (Score:3, Insightful)
No, but (from your link) it does "change its structure and design, and remove dead code, to make it easier for human maintenance in the future."
Refactoring might be a sensible thing to do during the two weeks between the first and second phases of the competition.
Having said that, from my (limited) experience, you tend to need less refactoring in functional programming languages than in imperative (or object-oriented) languages.
Matt
Re:Plan ahead? (Score:2, Insightful)
Object Oriented design requires one to think in a way more human, and less mathematic/computerish. We classify things as "objects", we give objects "methods" and "properties". Functional languages only have properties (coeffecients and inputs, etc).
Refactoring OO programs tends to be a hobby, more than a necessity, as I find it. Every now and again you'll hit something that g
Re:Plan ahead? (Score:2)
Abstraction (Score:2, Informative)
Mod parent down. If you read his other posts, you will see that he is confusing functional languages (ML, Haskell, Scheme) with procedural languages (C and Pascal). Unlike procedural languages, functional languages, with roots in the lambda calculus, are very abstract to the degree that people often complain they are too abstract to be useful.
The parent poster makes the same mistake in nearly all of his posts under this article. Watch out.
Re:Plan ahead? (Score:2)
That is right, but often when you get changed requirements, or when you have to add functionality while keeping the old behaviour, first thing you do is refactor. With the new requirements in mind you can see where your design should be more generic. By refactoring to accomplish this, you make it easier to build the new functionality on top of the existing code.
Re:Plan ahead? (Score:1)
Re:Plan ahead? (Score:2)
Not a bad exercise! (Score:5, Interesting)
The last part of the assignment was to make our life-forms compatible with that of at least one other group. This last part proved quite interesting as, even though the critters were technically compatible with the other groups environment, many of the assumptions our two groups had made about the world (such as sight radius of each creature, how much food a creature needs, how fine grained the world was...) made the creatyres behave rather weird.
Still, it is a good way to be forced to write code that is easy to refactor from start!
Sounds like my clients (Score:5, Funny)
sounds like some of my clients.
Re:Sounds like my clients (Score:4, Insightful)
Frustrating? Yes! But we have to live with it. We just need to make them understand that the project will be delayed and it will cost more and why this is so if they change the specs late in the project.
Our job as developers is to make the system easy to change bacause we all know this will happen.
Wow (Score:5, Interesting)
Re:Wow (Score:4, Interesting)
You answered your own question in your first sentence: "This is just like real life."
Humans (and spec writers, too!) make mistakes and sometimes overlook aspects of a desired requirement that are important. Recognising this and being ready to deal with it is part of the job for any professional in any industry.
Re:Wow (Score:4, Interesting)
I was just kind of pointing out that this contest brings to light one of the most frustrating parts of designing software in the first place. This is one of the things that makes it so hard to get right. If you told a civil engineer to build a bridge, and then half way through building it, told him you wanted it to hold twice as many cars, and be a draw-bridge, instead of a suspension bridge, well, I think that he would basically have to start over from scratch, and the project would of course be over budget, and take longer then originally expected. With software, there is less of an impact, but people still have to realize the real impacts of trying to change things at the last minute. People who don't really know much about software will look at competitions like this, and think that they don't really have to worry about changing requirements, because programs can be changed easily, without any ill effects.
Re:Wow (Score:1)
To use your analogy, rebuilding the bridge might be worth it if large ships (read: lots of money) now need to get through.
Re:Wow (Score:2)
Yes, it does happen. Generally from a "on-high" business process change where I.T. is not consulted. Many managers do not understand how these decisions affect I.T. systems. Also, government policy changes will have huge affects when dealing with a highly regulated industry.
Re:Wow (Score:2)
This is a lot of what ends up happening to software. A simple project gets completely finished, but ends up being too rigid and when someone wants to add functionality to it, they end up having to rewrite the whole damned thing.
This is why we moved from more functional languages, to more Object Oriented languages. If someone writes a program abstract enough, then adding fu
Re:Wow (Score:3, Informative)
Note that C and Pascal are decidedly not examples of programming languages designed for functional programming. Wikipedia's page is a decent starting point for learning about this.
http://en.wikipe [wikipedia.org]
Re:Wow (Score:2)
Re:Wow (Score:2)
Whether you should be allowed to do it with software is a good question, too. Obviously there's more scope for reusing a line of code than a 10 tonne block of concrete, but code reuse is one of those semi-mythical creatures that you rarely see in real life. It would be fascinating to know how many "programmer error" bugs that cause loss of data, security breaches, etc. oc
Re:Wow (Score:2)
Re:Wow (Score:1)
> Oriented languages.
Huh? No. Most people who moved to more OO languages were coming from procedural/imperative languages, not from functional languages.
> If someone writes a program abstract enough, then adding functionality
> is as simple as throwing in a new object, inhieriting, and you're done.
Object-orientation isn't the only kind of abstraction. The FP equivalent to re-writing a base class is to pass a different clos
Re:Wow (Score:4, Insightful)
Don't you just hate it when competitions are similar to real life, instead of promoting some "pure" academic ideal?
Re:Wow (Score:1)
Ahh, but that would require the contest directors (aka, stakeholders) to put forth the effort to create coherent and complete requirements (and when does THAT happen?!)
The implication to 'whoever best' is that the task is non-trivial enough to end in enough of a gradation to separate out even the top tier percent into a clear winner. Non-triviality of this level would be an effort ten-fold larger than the actual programming. Bullet-proof specifactio
Re:Wow (Score:2)
Re:Wow (Score:3, Insightful)
Part of the reason that
FP (Score:5, Insightful)
There are some comments already saying "if the program could be written in three days, couldn't they write a new one from scratch in one day?" The answer is that a very fast programmer probably could. But what would the point be? The object of this exercise is to show off just how generic a program written in a functional language can be. It really is possible to abstract everything, leading perhaps to the famous paradox "Everything can be solved by adding another layer of abstraction, except having too many layers of abstraction."
Putting that aside, I think this is a great idea for a competition. I hadn't heard of it before this one, and have only recently got into functional programming myself. I'm a new-found convert to ML, and find it interesting to be forced to think about a problem in a completely new, and usually recursive, way. ML also has some imperative elements but I prefer to avoid them as far as possible. I'll attempt to make an entry to this contest, although I doubt I'm at the relevant level of expertise yet.
I'd be interested to hear what languages other Slashdotters think would be most appropriate to a contest like this. Lisp gurus, start your engines!
Re:FP (Score:2)
First of all, we know we have to use a functional language to design the program. This throws out C++, C#, Java, Visual Basic, Objective C, Perl, Python, Parrot, etc. etc. Next, we know that we're
Re:FP (Score:1)
No you don't. You can use any language you want.
So what we're left with are languages like C and Pascal, PHP
So how is it you throw out C++, Perl and Python in your "have to use a functional language" cut, but C and Pascal survived? C++ at least has libraries like Boost.Lambda, and Higher Order Perl [plover.com] shows off it's functional side a bit. And of course in your final list of languages, the closest thing you have to a funct
COBOL (Score:1, Funny)
MS
Re:COBOL (Score:2)
Ummm... WTF? (Score:1)
Re:Ummm... WTF? (Score:1)
Relax, with your WTFs...
Re:FP (Score:2)
And if you really want to have some fun, write it in assembly, though this option will make you very machine-conscious.
Re:FP (Score:1)
The most appropriate one is probably the language you know best (coupled with the one most suited to the problem -- if speed is a big plus, you're not going to want to deal with, say, PHP, and if concurrency is a big issue, you might want to lean on Erlang or Oz). Despite the name of the contest, you don't need to use a functional language: the winners of last
Many solutions, but... (Score:2)
I think Forth.
Small core, fast, functional, modular, & universal.
What they don't tell you (Score:2, Funny)
Re:What they don't tell you (Score:1)
Re:second row (Score:5, Insightful)
"Hey, significant other, I'm not into it for the money"
Worked for me. YMMV.
Re:second row (Score:2)
Nah, thats too harsh. After all, if you worked for EA a chance at $7.29 an hour would be an EXCELLENT reason to jump ship.
Re:If Functional Languages are academic... (Score:1)
Re:If Functional Languages are academic... (Score:2)
Often not a good idea (Score:3, Funny)
It takes time. It makes the code more complex than it could be, and thus less readable and maintainable. And when the spec finally changes, it changes in a way that makes this additional layer of complexity useless, and another layer is added on top of it.
Re:Often not a good idea (Score:2)
For simple, algorithm-scale problems, planning isn't really required, it's done implicitly by the problem itself. Things like solving questions are often algorithmically scaled. "You have N sailors with numbers pinned on their shirts from 1 to N. Starting with sailor 1, you go around in a circle, telling every Mth sailor to leave the circle. If you continue forcing sailors out of the circle, what is the number of the last remaining sailor?".
The problem i
Re:Often not a good idea (Score:2)
I know that planning is important. What I consider doubtful is planning *ahead*, i.e. designing for more than what the application must do, just because the requirements might change in the future.
Lisp (Score:1)
Re:Lisp (Score:2)
CLers then mutter things like your "the most active and talented lispers tend not to bother in the first place", implying that they could of course win if they wanted to, but that they are above all of that. Really? Okay, prove it by winning three times in a row. If CL gives its users the kind
Re:Lisp (Score:1)
Lisp fell out of favor because it was ahead of its time. On the hardware avaialable in 1975, a language such as C was able, by not providing any useful highlevel abstractions, to wring useful performance out of the hardware. So naturally such languages almost completely took over.
The up-and-coming languages that are gaining favor now actually have more in common with lisp than they do with C, in a lot of ways. Not everything, obviously, and s
FP only? (Score:2)
Re:FP only? (Score:1)
Re:FP only? (Score:1)
> adapt it just as quickly?
You're going to write a non-trivial program in three days, in C? Is that even possible? Bear in mind, this competition is being held by functional-programming nerds, so the problem is likely to be the sort of thing that's most easily solved by using continuations for backtracking or some such technique.