2 ms·

Why is that a good thing? Essentially what you're saying is that Erlang allows you to make idiotic mistakes?

by axod 17y ago

davidw 17y ago
If the logic of your program is: On event, do some big, long calculation. Why should you need to write the code differently from that? It's nice that the language/environment handles things for you, rather than manually dividing things up into little chunks.
- axod 17y ago
  If your program is: Show a calculator. Why should you need to write the code to do each individual part of the calculator? I disagree, dividing up the work yourself into chunks means you retain complete control of when your code executes. That actually decreases the complexity of your code, since you know when everything will execute.
jerf 17y ago
No. Things that are not Erlang turn you into a human compiler, forced to manually chop your code into pieces for the pleasure of the computer. Erlang allows you to actually write things without doing the chopping up the scheduler should do. Event-based libraries are great hacks on top of weak languages/runtimes that allow those weak languages to hobble forward into the present, but they shouldn't be confused for the right approach in the future. I do hope they don't become trendy. Of course, look for them to become trendy, then for one or more of them to rediscover the pleasure of actually writing code in a straightforward manner, so they will provide you with a preprocessor that tries to do the chopping up for you, but still won't solve the problem of doing too much work in one timeslice. Then they'll rediscover that cooperative multitasking was abandoned years ago for good reason. You know, there's nothing new under the sun, but sometimes you just wonder... this much hype around cooperative multitasking? Seriously?
- axod 17y ago
  I can't disagree with you enough. I don't want anything else to decide what order my code runs. I want it to run in the order I decide. Once you move away from the stupid "I want these 100 things to run at the same time", and realize that's impossible unless you have 100 CPUs, then you can start to move forwards and learn a better way. Event based / async programming is simple once you get used to it, it's hugely liberating, and _extremely_ efficient. It reduces code complexity, and means you _know_ what order your code will execute in. Something that I kinda like knowing.
  - eru 17y ago
    > I don't want anything else to decide what order my code runs. I want it to run in the order I decide. And I guess you also want to manage all your memory yourself?
    - axod 17y ago
      No, because that's a completely different thing. Throwing your code at a compiler/CPU and saying "Here! you decide what order to execute this in", means I have to write MORE code to deal with that. eg asyc/event programming => less code, less complexity, more efficient Managing memory yourself would mean writing more code and more complexity. So it's comparing apples to inverse apples.
      - eru 17y ago
        That's strange. I always get a headache when I have to think about order of execution (e.g. in C or Ocaml). Haskell (which is not parallel by default, so it's slightly off-topic here), manages the order for me, and I feel I have an easier time writing code, less code.
      - viraptor 17y ago
        I don't get what you're saying to be honest... When you have 2 actors that are executing "independently", you're just doing (very-pseudo-code) this: (assume recv == wait_for_N_bytes_or_timeout_after_M_seconds) case recv(10, 5) in timeout -> handle_this_and_throw data -> do_something(data) in do_something you've already made a progress to another state (unless you want to handle the FSM explicitly, then nothing is preventing it) and can throw to cleanup. In an event based scenario: def got_some(data): buffer += data switch(current_processing_state): case state1: buffer = try_to_handle(buffer) case state2: .... Now you might have enough data in the buffer to handle it, or you might not. You cannot check it before, because each state might need different amount of data. Try to insert timeouts into this code in a way that also closes the in-state resources now... yeah... forget about throwing exceptions really. Any internal exception thrown by bad code is very likely to hit your code in a bad way unless you handle all possible exceptions in every state separately. I see more code and more complexity in event style. Care to provide some counter-example? (and I'm not saying it's not possible - just haven't really seen one yet)

Why is that a good thing? Essentially what you're saying is that Erlang allows you to make idiotic mistakes?

by axod 17y ago

Why is that a good thing? Essentially what you're saying is that Erlang allows you to make idiotic mistakes?

If the logic of your program is: On event, do some big, long calculation. Why should you need to write the code differently from that? It's nice that the language/environment handles things for you, rather than manually dividing things up into little chunks.

axod 17y ago
If your program is: Show a calculator. Why should you need to write the code to do each individual part of the calculator? I disagree, dividing up the work yourself into chunks means you retain complete control of when your code executes. That actually decreases the complexity of your code, since you know when everything will execute.

jerf 17y ago

No. Things that are not Erlang turn you into a human compiler, forced to manually chop your code into pieces for the pleasure of the computer. Erlang allows you to actually write things without doing the chopping up the scheduler should do. Event-based libraries are great hacks on top of weak languages/runtimes that allow those weak languages to hobble forward into the present, but they shouldn't be confused for the right approach in the future. I do hope they don't become trendy. Of course, look for them to become trendy, then for one or more of them to rediscover the pleasure of actually writing code in a straightforward manner, so they will provide you with a preprocessor that tries to do the chopping up for you, but still won't solve the problem of doing too much work in one timeslice. Then they'll rediscover that cooperative multitasking was abandoned years ago for good reason. You know, there's nothing new under the sun, but sometimes you just wonder... this much hype around cooperative multitasking? Seriously?

axod 17y ago
I can't disagree with you enough. I don't want anything else to decide what order my code runs. I want it to run in the order I decide. Once you move away from the stupid "I want these 100 things to run at the same time", and realize that's impossible unless you have 100 CPUs, then you can start to move forwards and learn a better way. Event based / async programming is simple once you get used to it, it's hugely liberating, and _extremely_ efficient. It reduces code complexity, and means you _know_ what order your code will execute in. Something that I kinda like knowing.
- eru 17y ago
  > I don't want anything else to decide what order my code runs. I want it to run in the order I decide. And I guess you also want to manage all your memory yourself?
  - axod 17y ago
    No, because that's a completely different thing. Throwing your code at a compiler/CPU and saying "Here! you decide what order to execute this in", means I have to write MORE code to deal with that. eg asyc/event programming => less code, less complexity, more efficient Managing memory yourself would mean writing more code and more complexity. So it's comparing apples to inverse apples.
    - eru 17y ago
      That's strange. I always get a headache when I have to think about order of execution (e.g. in C or Ocaml). Haskell (which is not parallel by default, so it's slightly off-topic here), manages the order for me, and I feel I have an easier time writing code, less code.
    - viraptor 17y ago
      I don't get what you're saying to be honest... When you have 2 actors that are executing "independently", you're just doing (very-pseudo-code) this: (assume recv == wait_for_N_bytes_or_timeout_after_M_seconds) case recv(10, 5) in timeout -> handle_this_and_throw data -> do_something(data) in do_something you've already made a progress to another state (unless you want to handle the FSM explicitly, then nothing is preventing it) and can throw to cleanup. In an event based scenario: def got_some(data): buffer += data switch(current_processing_state): case state1: buffer = try_to_handle(buffer) case state2: .... Now you might have enough data in the buffer to handle it, or you might not. You cannot check it before, because each state might need different amount of data. Try to insert timeouts into this code in a way that also closes the in-state resources now... yeah... forget about throwing exceptions really. Any internal exception thrown by bad code is very likely to hit your code in a bad way unless you handle all possible exceptions in every state separately. I see more code and more complexity in event style. Care to provide some counter-example? (and I'm not saying it's not possible - just haven't really seen one yet)