4 ms·

Just because Erlang is very good at solving a certain class of problems, doesn't mean it's inferior at solving general computing problems. The Erlang challenge

• lg 19y ago
  You said it. I checked out the Erlang tutorial just now, and apparently you can't use user-defined functions in the test-expression of a conditional, to prevent people from putting side-effecty functions in there? Now maybe there's some good reason for that, that has to do with the mysteries of handling concurrency or something, but it gives me the prima-facie feeling of java for the fp crowd.
  • tb 19y ago
    Mostly the reason for that is to allow the compiler to optimise the order of evaluation of the conditions. If you could put functions with side-effects in there then it would be impossible to do that since the compiler would have to guarantee some kind of consistent evaluation order. There have been proposals for some way to mark user-defined functions as side-effect free and thus allow them to be used in guards. None has had acceptance from the core Erlang developers yet. In any case this is not usually too much of a problem. The Erlang idiom is to use 'case' instead of 'if' in most cases (no pun intended) and where a calculated value is needed then just assign it to a variable beforehand - not quite as pretty I agree but no big deal.
    • lg 19y ago
      So my small problem sounds like a bigger problem. Why won't Erlang let me specify the order of evaluation? You know, like, left to right?
      • bayareaguy 19y ago
        Dumb question: Erlang computations are supposed to be side-effect free right? If they are, why does order of evaluation matter?
        • lg 19y ago
          Seems you're right. That was a nice foray. Back to Scheme I go...
      • tb 19y ago
        If you had a piece of code like this: case my_function(Foo) of some_result -> do_something(A); some_other_result -> do_something(B); _ -> do_default_case() end Why do you care if the output of my_function(Foo) is compared to some_result first or some_other_result first?
• mechanical_fish 19y ago
  Well, okay, it sounds like I have therefore interpreted the Erlang Challenge correctly: it highlights what Erlang is good at. And that's fine. There's nothing wrong with ass-kicking special-purpose programming languages, and I look forward to the day when I will actually spend ten minutes learning Erlang and be able to start discussing it instead of just marveling at it from afar. The thing is, the Arc Challenges (I presume there will be others...) are explicitly intended to convince us that Arc is an awesome language for solving general computing problems. (Of course, they're also tools for designing Arc: If Arc proves unconvincingly awesome at any point, the plan is to twiddle its design knobs until the awesomeness returns. We will see how it goes.) When you adopted the Arc Challenge's title and style, it left me wondering if you were aiming at the same goal. If you were, I wanted to invite you to shoot again, because you kinda missed. However, it seems that "convincing me that Erlang is good at everything" was never your goal at all, so I'm sorry to have interpreted it that way. (My interpretation may have been unduly influenced by the original title of the submission...)
  • yariv 19y ago
    I guess that you and I had different interpretations of the Arc challenge. I thought it was intended to demonstrate how easy it is to implement multi-page flows in Arc by binding closures to links and forms. I didn't think it was intended to convince people that Arc is a good general purpose language because its scope was so narrow (if the challenge were to build a search engine or an image editing tool, it would have been a different story). By the way, although I didn't expect people to extrapolate from the Erlang challenge that Erlang is a good general purpose too, I do think that it is, at least for building backends for a wide range of applications. I wrote a followup on my blog to the Erlang challenge where I listed some of them.