[WilliamLP]

One thing that raises my eyebrows is how much functional programmers talk about Project Euler problems. The actual programming for solving these problems is in fact extremely trivial. They require some mathematical insight, especially after the first one hundred or so, and you need to do some external research on Pell's Equation to avoid getting stuck, and you need a fraction library if your language doesn't have it built in. But am I wrong in thinking that these kind of problems are almost no test or strain for your actual programming at all?

[sofuture]

They're an absolutely fantastic way to start 'getting' any language. They're small, discrete, and varied tasks that require you to build different types of operations and structures. Sure, they're not at all reflective of 'real programming' nor are they necessarily particularly challenging, programming wise.

I'd rather cut my teeth in a new language on the first 50 or so PE problems, than take on a bigger, less defined, or more domain limited task.

I'm conversant in Python and Erlang because of PE problems entirely. They've enabled me to start actual projects in both languages.

[WilliamLP]

> varied tasks

That's where I'd argue. It would be like saying you're an all around gamer when you play only chess but with different openings every time.

Varied simple tasks would be doing some Euler problems, doing some basic algorithms (Dijkstra's with Heap, A* pathfinder on a 2d map, etc... TopCoder problems are great for this), write a Mandelbrot zoomer, Conway's Life app with position setup and step-through and save/load, write a Tetris clone, write a basic HTML form builder, write a blogging engine, write a multi-user chat room server, write a simple side-scrolling shooter game, write a basic Roguelike game, write a simple text adventure. Things like this can all be afternoon projects.

Every time I read someone claiming that Project Euler is for developing general-purpose programming, I roll my eyes more than a little.

[scott_s]

When learning, it's easiest to learn one thing at at a time. If you're learning a new programming language or programming paradigm, it's helpful to solve a task you fully understand. That way, the unknown is not the solution, but what the solution looks like in this new language or paradigm.

Most of the examples you gave are applications. They require considering things external to the a core problem, such as user interaction and network communication. Those are like projects in a course. Project Euler problems are like a homework set.

[Poiesis]

> Most of the examples you gave are applications. They require considering things external to the a core problem, such as user interaction and network communication.

"Core problem" to me means solving a problem a user has. Things like user interaction are indeed part of the core problem.

Unless there's another sense of the term I'm missing?

[nudge]

Did anyone actually make this claim here? You quoted two words out of a comment that said quite a bit beside, including:

"Sure, they're not at all reflective of 'real programming' nor are they necessarily particularly challenging, programming wise."

Nobody claimed Project Euler is the way to become a great programmer. I would roll my eyes at your mistake, but I don't roll my eyes at people's mistakes. I try to help them correct them.

[WilliamLP]

Don't get me wrong, I love Project Euler and had a blast doing a couple of hundred problems in Java a couple years ago. I make these claims:

1. The problem solving there has almost no connection to what it is like for the vast majority of uses of writing a computer problem.

2. It is in no sense a varied set of tasks. It's similar to a math contest problem set, with some basic string manipulation masquerading as numerical problems (pandigital numbers, etc.)

3. The programming and program design required to solve tasks in this narrow space is trivial, and not particularly instructive of how you'd write programs in another space.

4. Functional programming articles tend to mention and place stock in Project Euler problems to a degree which, in my opinion, is unusually much larger compared general programming articles.

[lolipop1]

I think you're simply talking about different complementary things.

One speaks about the fact that you can learn the basic keywords and flow (as in how the language is parsed) using simple mathematic problems.

While the other speaks about solving real-world problems require more diversity.

[silentbicycle]

Any similar sites you'd suggest, besides Project Euler and TopCoder? I've worked through much of PythonChallenge, but I'm more interested in sites that aren't as closely tied to a specific language.

[pbewig]

Programming Praxis (http://programmingpraxis.com) provides a collection of etudes, updated weekly, for the education and enjoyment of the savvy programer. Although there is some math content (the current exercise uses the chinese remainder theorem), Programming Praxis is much less math-oriented than Project Euler.

[WilliamLP]

Do you know about Sphere Online Judge? (http://www.spoj.pl/) It supports a lot of languages. It still contains mostly algorithmic problems though, making it a superset of the kinds of problems at Project Euler but still a tiny subset of general programming.

[silentbicycle]

That's what I had in mind, thanks.

[nudge]

No mystery. Project Euler is a useful set of problems to tackle when learning a new language. It's not 'Wahoo with functional programming I can finally get past Euler 15'; it's 'Wow after a bunch of these Euler problems I think I am finally starting to get functional programming'.

[ionfish]

I wonder whether it's just that programmers who enjoy functional programming are also the sort of people who enjoy Project Euler problems. Since most of the problems are fairly mathematical, they also tend to have clear and concise expressions in functional languages.

[DanielBMarkham]

New to FP here as well (couple of years playing, more serious work in last few months)

It used to bug me too, but then I realized that common mathematical problems are the only "easy" way to explain how some things work.

Put another way, the problem domain in most applications is laid bare in FP. So your structures are intricately tied to whatever you're doing. You can either put up with a 30-minute "backstory" on why you're writing function foo, or we can just go with some kind of math deal. Usually authors pick the math option.

I found that once I could plow through writing short snippets, then I could start reading example code from the web. That helped a lot.