Comment by sofuture | Hacker News Reader

Comment by sofuture | Hacker News Reader

I've recently jumped into Erlang, and have come to some of the same conclusions. I read Armstrong's Erlang book, and thought 'that seems cool' and didn't at all grok what was going on beyond the superficial. Then a few months later, just sat down and started solving Project Euler problems. At first it was strange and foreign and I was mad variables were immutable. A day later and it just clicked, I'd never had that much fun writing code.

The FP paradigm is (to me, even after 15 years of imperative programming) so much more natural for development, since you're able to sanely start attacking the problem directly -- instead of architecting a big-picture solution up front that's probably wrong anyway because you've ignored some detail you haven't yet discovered.

Building things with actions instead of objects just makes much more sense. Reuse comes much more naturally, and doesn't seem as contrived as a lot of OOP reuse seems. I've noticed that working my FP muscles out has made me a much better imperative programmer -- I write a lot more clever and effective code (not clever like 'tee-hee-no-one-will-ever-figure-this-out'!).

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?

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

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.

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

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.

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.

That's what I had in mind, thanks.

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.

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.

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.

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.

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.

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

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.

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.

For me one of the real eye openers was that I'd gotten to the end of a fairly long book on FP without seeing a single assignment of a value to a variable.

I have just finished the first iteration of a web app written in clojure and in the several hundred lines of code, I have a single variable which changes state.

Neat! Did you use a templating system? And if so which one?

The usual solution for that would be hiccup, with a few custom functions.

Depends, Enlive is seeing at least some use as well (the web app I built for personal use has enlive handling the HTML as well).

I am using hiccup for generating the html, compojure and ring for routing and request/response handling, jetty as the webserver and postgresql as the database

Did you cook up your own authentication or is that provided by one of those?

As of now I am just using my own. The user can create an account with username/password. When they login, it will associate the user with the session object. Session management is handled by ring, although the session data resides in memory only. I have a function which wraps around the routes which require the user to be logged in and checks the session to make sure the user is not nil.

Which book?

The Little Schemer.

Thank you for the reference to Project Euler. I'm learning Scala right now and it gave me just the right sized challenges for testing my knowledge. They're big enough to take time and thought, but small enough that you can solve them within the CLI interpreter.

I've used Erlang for a while, although sporadically. Honestly, I think I can do more with less code in Ruby, though. Erlang's great for the things it's good at, but brevity and clarity are really things I think are critical.

Here's a small example I bumped into the other day, providing a default value if a hash value isn't present:

    foo[:bar] || "beebop"

vs

    case (catch dict:fetch(bar, Foo)) of {'EXIT', _} ->
                        "beebop";
                Val -> Val
          end

(or something close, there might be a typo)

So wrap it in a function

  default(Dict, Key, Default) ->
      case dict:is_key(Key, Dict) of
          true -> dict:fetch(Key, Dict);
          _ -> Default
      end.

Dunno about Erlang, but in Haskell, you can actually call this function ||:

    import Prelude hiding ((||))
    import qualified Data.Map as M
    import Data.Maybe

    (||) = flip fromMaybe

    main = print $ result || "OH NOES!"
      where result = M.lookup "baz" map
            map    = M.fromList [("foo", "bar"), ("bar", "baz")]

    ghci> main
    "OH NOES!"

With some typeclass magic, you can even make this work for arbitrary types. But don't waste your time with this, since it's already built in as `mplus`:

    ghci> Nothing `mplus` Just 42
    Just 42
    ghci> Left "OH NOES" `mplus` Right "it worked"
    Right "it worked"

Believe it or not, I actually had figured that out.

The point was about the language in general, its verbosity, and the ability to string things together.

This is built into the Scala API - foo.getOrElse(bar, "beebop")

Stuff like this should be built into the standard language.

Python has it too:

* foo.get(bar) will return None if the element is not there * foo.get(bar, "beebop") does what your Scala example does * foo.setdefault works just like foo.get. However, if foo did not have key bar when it was called, it will fill the key in with the default value before returning. * collections.defaultdict is also worth a look.

Reply on news.ycombinator.com