Slashdot Mirror

← Back to Stories (view on slashdot.org)

8th Annual ICFP Contest

Posted by Zonk on from the push-the-button,-frank dept.

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."

54 of 72 comments (clear)

  1. Is rewriting cheating? by nhnfreespirit · · Score: 3, Insightful

    If the original program can be written in 3 days, chances are a good programmer can write a new one that matches the changed specifications from scratch in one day. Is this cheating? :-P

    1. Re:Is rewriting cheating? by Cmdr+Whackjob · · Score: 2, Funny

      If a good programmer writes a new program in one day and no one sees it - does it really exist?

    2. Re:Is rewriting cheating? by JonyEpsilon · · Score: 2, Informative
      From the prizes page:
      The judges' prize will be awarded to a team that produces reasonably competitive entries and, in the judges' opinion, has the most effective re-use of their first submission.
  2. Re:Plan ahead? by Markus+Persson · · Score: 4, Informative
    Refactoring does not change behavior.

    Prediction: more people in this thread will make that mistake.

    --
    If the cat can't experience its own death, nothing will ever kill you. (No, really!)
  3. Not a bad exercise! by nhnfreespirit · · Score: 5, Interesting

    We actually did just this as an assignmet in a software engineering class a while back. We had to write a simple life simulator, and then a new assignmet was handed out that changed the original specifications.

    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!

  4. Sounds like my clients by SlightOverdose · · Score: 5, Funny

    Hmm. Two weeks to complete a project, followed by a changed spec the day before going live.

    sounds like some of my clients.

    1. Re:Sounds like my clients by ^DA · · Score: 4, Insightful
      Change of spec sounds like real life to me. Customers rarely know excactly what they want before they have a working system up and running. THEN they start to see the possibilities.

      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.

  5. Wow by CastrTroy · · Score: 4, Interesting

    This is just like in real life. Design a program to spec, and then 1 day before launch, change the requirements. Is this the kind of activity we should really be promoting? Maybe we should give well laid out requirements, and whoever follows them the best, wins. Not only would following the requirements be important, but also not exceeding the requirements, and adding a bunch of stuff that wasn't asked for, would cause you to lose points.

    --

    Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    1. Re:Wow by NoseBag · · Score: 3, Interesting

      Is this the kind of activity we should really be promoting?

      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.

      --
      Cloned foods give the statement "We had that last week!" a whole new meaning.
    2. Re:Wow by jorleif · · Score: 3, Insightful

      Is this the kind of activity we should really be promoting?

      Don't you just hate it when competitions are similar to real life, instead of promoting some "pure" academic ideal?

    3. Re:Wow by rhendershot · · Score: 1

      >>Maybe we should give well laid out requirements

      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 specifactions like that don't just grow on trees ya know... ;)

    4. Re:Wow by CastrTroy · · Score: 3, Interesting

      I do realise thats its kind of important to make a program that can easily be changed to meet changing requirements. Even if it follows spec, and does what the customer wants today, within 3 months, the customer will want it to do a bunch other things, or do some things differently.

      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.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    5. Re:Wow by honcho · · Score: 1

      Do you really think that people just change requirements on a whim without any thought to the impact on time and budget? Maybe the cost of not changing the requirements would be more costly because you're no longer solving the business problem the way it needs to be solved.

      To use your analogy, rebuilding the bridge might be worth it if large ships (read: lots of money) now need to get through.

    6. Re:Wow by ciroknight · · Score: 1

      The thing is, in the scenario you described, you wouldn't have the option to change the kind of bridge after it was in construction.

      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 functionality is as simple as throwing in a new object, inhieriting, and you're done.

      For a civil engineer, it would be like modular construction; if you built a bridge out of modular sections and realized that you needed two more lanes, you could double up the number of sections and run two parallel to each other.

      This competition is here to demonstrate that this kind of abstraction can be brought to functional programming as well. Things like function pointers, generic structures, generic pointers, and type casting (most of these being very Cish/Pascalish things because that's all of the functional programming I do) can make a functional language more abstract. But the cost is that these things tend to be a little bit more tricky.

      I still say the best example anyone can give of the success of Functional programming is the Linux Kernel itself. It's abstract enough to have a plugin interface for file systems and general use objects, device drivers, etc, but it's functional enough to be very fast and very memory effecient.

      --
      "Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
    7. Re:Wow by jjc2222 · · Score: 3, Informative
      You are getting "procedural" programming confused with "functional" programming. Functional languages generally refer to languages that concentrate on the evaluation of expressions with no side-effects rather than statements that modify data. Examples of functional languages are:

      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.wikipedia.org/wiki/Functional_programmin g/
    8. Re:Wow by Anonymous+Brave+Guy · · Score: 1
      The thing is, in the scenario you described, you wouldn't have the option to change the kind of bridge after it was in construction.

      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. occur in code that was changed late and in a hurry, though I'm not aware of any formal studies into this.

      This is why we moved from more functional languages, to more Object Oriented 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.

      I'm assuming you mean "more procedural languages"; in common terminology, "procedural" means C, Pascal, FORTRAN, etc., while "functional" means ML, Haskell, etc. In any case, the benefits of OO aren't as clear-cut as the evangelists make out. Making your program "abstract enough" to do what you describe typically results in a vastly over-engineered design where the complexity does more harm to productivity than good, IME. OO provides some useful design tools, but again IME, they're far more useful when handled pragmatically and not put on some sort of pedestal.

      Things like function pointers, generic structures, generic pointers, and type casting (most of these being very Cish/Pascalish things because that's all of the functional programming I do) can make a functional language more abstract. But the cost is that these things tend to be a little bit more tricky.

      With no offence intended, I'm pretty sure now that you're misunderstanding what "functional programming" means. In functional programming, functions are first-order concepts -- you can build them, pass them around, combine them and evaluate them more-or-less arbitrarily. That's almost the definition of functional programming! Concepts like function pointers or delegates are the poor man's knock-offs, and only exist because the languages that offer them aren't up to the real thing.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    9. Re:Wow by KingPrad · · Score: 1

      Yeah man. We wouldn't want to have a competition which tests skills useful in the real world, too.

      --
      Stop the Slashdot Effect! Don't read the articles!
    10. Re:Wow by ciroknight · · Score: 1

      Ah you caught me, I must have misread the blurb (didn't bother reading the articles). My mistake.

      --
      "Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
    11. Re:Wow by ciroknight · · Score: 1

      My apologies, I misread and misinformed the whole thing; I was thinking the whole time proceedural and not functional.. No posting on /. in the AM hours for me :).

      --
      "Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
    12. Re:Wow by mccoma · · Score: 1
      Do you really think that people just change requirements on a whim without any thought to the impact on time and budget?

      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.

    13. Re:Wow by be-fan · · Score: 2, Insightful

      This is like real life. And I disagree that this is something we shouldn't be promoting anyway. There are a lot of areas where its impossible to define a detailed specification before hand. Take your average DARPA project. In many cases, nobody knows what the final solution should look like, or even what is possible given current technology. In such situations, the specifications are vague and often changing, because the process of doing the research makes the end result more clear.

      Part of the reason that these ICFP contests are held are to demonstrate the strengths of functional languages. Traditionally, exploratory programming and rapid refactoring has been considered one of these strengths. Thus it makes sense to have a contest to demonstrate these strengths, especially when the conditions of the contest are applicable to so many real world scenarios.

      --
      A deep unwavering belief is a sure sign you're missing something...
    14. Re:Wow by jonadab · · Score: 1

      > This is why we moved from more functional languages, to more Object
      > 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 closure/callback. (No, it's not really equivalent. Well, it is in the Turing-equivalence sense, but it's wrapping things in a different abstraction. OO and FP are quite different in that sense. That's why they're both useful.)

      > Things like function pointers, generic structures, generic pointers,
      > and type casting

      I have never heard of a functional programming language that has pointers in the traditional C-ish sense, nor one that has the kind of type system that makes casts necessary. I'm sure there probably is one, but I'm not familiar with it, and it's certainly not the norm in the FP world.

      > (most of these being very Cish/Pascalish things because that's all of
      > the functional programming I do)

      This is the first time I have ever heard C or Pascal called a functional
      language. C is normally considered a low-level or procedural language, much
      like assembly language, and Pascal is generally classified as a Structured
      Programming or B&D language. Both of those paradigms are at least as
      different from functional programming as they are from object-oriented.

      A good example of a functional programming language would be Scheme. (A very bad example of a functional language would be unlambda. HTH.HAND.)

      Personally, I prefer multiparadigmatic languages.

      --
      Cut that out, or I will ship you to Norilsk in a box.
  6. FP by mistersooreams · · 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!

    --
    apterous.org
    1. Re:FP by ciroknight · · Score: 1

      PHP comes quickly to mind. Many, many people call it a Object Oriented language, but when it comes down to it, it's really just scriptable C. Perl, Parrot and Python are all OO throwing them out of consideration. BASIC (the non-visual flavors), Pascal, C, and Haskell are all really good choices as well.

      And if you really want to have some fun, write it in assembly, though this option will make you very machine-conscious.

      --
      "Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
    2. Re:FP by ciroknight · · Score: 1

      I disagree. The problem has been defined, but not specified. The problem is designing a program to do a task, and then within a fixed amount of time, redesigning the program to do a similar task. Though language considerations normally wouldn't be considered so early, we can start making some decisions already.

      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 going to have to redesign, which means we probably want to throw out programs that tend to be a bit more tedious to design in. Languages like Assembly (general), Fortran, etc. leave in this cut. So what we're left with are languages like C and Pascal, PHP (in my world; some people call it OO, but I call it retardedly functional), Shell scripting, Maple (hey, it works), BASIC, Lisp. From there, we can begin to choose a specific language for a specific problem.

      --
      "Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
    3. Re:FP by Fahrenheit+450 · · Score: 1

      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!

      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 year's lightning division used Java, C++, Perl, and m4; and the second place team in the main division used C++ (thought the Judge's Prize winners used OCaml, and the main division winners used Haskell). In fact C++ was the most popular language in last year's competition, and C was the leader the year before.

      Of course, OCaml is always popular due to its speed and flexibility, and it's what I would choose, as it is my primary language anyway.

      --
      -30-
    4. Re:FP by Fahrenheit+450 · · Score: 1

      First of all, we know we have to use a functional language to design the program.

      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 shows off it's functional side a bit. And of course in your final list of languages, the closest thing you have to a functional language is Lisp (which is commonly thought of as functional, but it's really multi-paradigm, and is more often than not coded in an imperative manner). Me = confused...

      Anyway, the bottom line is: choose whatever language you want to use.

      --
      -30-
  7. Re:Plan ahead? by Maffy · · 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

  8. What they don't tell you by datadriven · · Score: 2, Funny

    ...is that you have to write a program to kill Microsoft

    --
    GETPKG - Package Management for Slackware
    1. Re:What they don't tell you by agacat · · Score: 1

      The program that will kill Microsoft is already written - it's called Windows. MS is just taking a long time to die.

  9. Re:Plan ahead? by De+Lemming · · Score: 1

    Refactoring does not change behavior.

    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.

  10. Often not a good idea by jb_nizet · · Score: 2, Funny

    In my (short) experience, I've found that planning ahead is, most of the time, a bad idea.
    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.

    1. Re:Often not a good idea by ciroknight · · Score: 1

      Good luck when you get into more complex problems.

      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 is when you get to problems like "Make a client that plays this game and gets the maximum score possible" tend to get more complex, but are on a scale of multi-algorithm; it often requires more than one proceedure running side by side to find the best outcome.

      These higher level questions require a bit more thinking, and eventually breaking down and saying "this is how I'm going to solve this problem, this is how this one's taken care of, and this is the code that glues the two together." And believe it or not, that's planning.

      --
      "Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
    2. Re:Often not a good idea by jb_nizet · · Score: 1

      You're describing what planning means (or designing, or whatever).
      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.

  11. Re:Plan ahead? by roach2002 · · Score: 1

    Correction: Refactoring should not change behavior

  12. Lisp by elgee · · Score: 1

    I enjoyed programming in Lisp, but it fell out of favor. Now I have to use Javasp.

    1. Re:Lisp by jonadab · · Score: 1

      > I enjoyed programming in Lisp, but it fell out of favor.

      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 specifically not the paren-based syntax, but most of the VHLLs now provide such things as anonymous subroutines with lexical closures, garbage collection, and so forth, which are really the important features of lisp. These so-called "scripting" languages (Perl, Ruby, Python, ...) are beginning to (gradually) displace traditional compiled languages (C, C++, ...) and be used more and more for application development. (No, Perl5 doesn't have real gc (it refcounts); Perl6 will, though.)

      --
      Cut that out, or I will ship you to Norilsk in a box.
    2. Re:Lisp by GCP · · Score: 1

      If Common Lisp were really the "secret weapon" its proponents make it out to be, one would expect it to occasionally win contests like this. There are usually CL entrants in this contest, but they rarely do very well.

      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 of advantage claimed, it shouldn't even require the "most active and talented" to do win.

      This sort of nonsense, combined with the arrogant hostility of the CL community toward honest questions about the emperor's current wardrobe, are MAJOR reasons for CL's lack of popularity.

      --
      "Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
  13. Re:Plan ahead? by /ASCII · · Score: 1

    Yes, because if refactoring does change behaviour, you must have introduced a bug. And code should not contain bugs.

    --
    Try out fish, the friendly interactive shell.
  14. Ummm... WTF? by ccharles · · Score: 1
    FP
    There are some comments already saying...
    If there are already some comments, how is this a FP?
    1. Re:Ummm... WTF? by Anonymous Coward · · Score: 1

      FP stands for Functional Programming.

      Relax, with your WTFs...

  15. Re:Plan ahead? by ciroknight · · Score: 1, Insightful

    This is often true because functional languages are not very abstract. They tend to be very mathematic and algorithmically driven.

    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 greatly speeds up the code, but more likely it just makes the code either look better, or more usable if you were to plug it into something else, neither of which I end up doing very much.

    --
    "Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
  16. Re:Plan ahead? by ciroknight · · Score: 1

    grr, should use the preview button;

    ..code WORK better or more usable.. neither of which ends up very useful to me...sigh.

    --
    "Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
  17. FP only? by Tom · · Score: 1

    Can I write my program in C and look whether or not I'll be able to adapt it just as quickly?

    --
    Assorted stuff I do sometimes: Lemuria.org
    1. Re:FP only? by khslinky · · Score: 1

      It's not restricted to functional languages. In fact, teams using C have done quite well in past years.

    2. Re:FP only? by jonadab · · Score: 1

      > Can I write my program in C and look whether or not I'll be able to
      > 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.

      --
      Cut that out, or I will ship you to Norilsk in a box.
  18. Re:second row by archeopterix · · Score: 4, Insightful
    Also the top prize is $700.00. If you spend every waking moment on it for 4 days (700 / 96) it amounts to a CHANCE at $7.29 an hour. Explain THAT to your significant other.
    Challenge accepted.

    "Hey, significant other, I'm not into it for the money"

    Worked for me. YMMV.

  19. Abstraction by Anonymous Coward · · Score: 2, Informative
    because functional languages are not very abstract.

    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.

  20. Re:If Functional Languages are academic... by Fahrenheit+450 · · Score: 1

    Don't know who's from Toyota, but Microsoft has some very research oriented people on their payroll: Simon Peyton Jones (big time Haskell guy), Cedric Fournet (the creator of JoCaml), Don Syme (working on f# -- a variant of OCaml for .NET), and so on), and I'm guessing the US Military Academy representative is Chris Okasaki, author of Purely Functional Data Structures. BTW, you do know that the Military Academies are universities, don't you?

    --
    -30-
  21. COBOL by Anonymous Coward · · Score: 1, Funny

    I'm halfway tempted to enter this contest - using COBOL. Just to show that it can be done.

    MS

    1. Re:COBOL by m50d · · Score: 1

      You wimp. Do it in befunge. That's a challenging language.

      --
      I am trolling
  22. Many solutions, but... by quarkscat · · Score: 1

    "Lisp gurus, start your engines!" -- NOT!

    I think Forth.
    Small core, fast, functional, modular, & universal.

  23. Re:If Functional Languages are academic... by be-fan · · Score: 1

    It's not surprising that you've got big entities who also have academic divisions. The schism between academia and the commercial world isn't nearly as big as its made out to be, though it is bigger in computer science than in other engineering fields. This is especially true of very large or very small companies, both of which see a particular benefit in utilizing the advancements of academia. The former, because they are so big that they can only grow through innovation, and the latter because they are so small they can only survive through innovation.

    --
    A deep unwavering belief is a sure sign you're missing something...
  24. Re:second row by patio11 · · Score: 1
    Your "waking moments" seem to be 24 hours a day -- how is EA doing these days, anyhow?

    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.

    --
    Help poke pirates in the eyepatch, arr.