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