4 ms·

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 fro

by 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)
tptacek 17y ago
You don't really know a priori the order everything is executing in, unless you control the remote ends of all the connections and you have no timers. I've lost days of my life to timer cancellation bugs.
- axod 17y ago
  Sure, you don't know the exact order your code executes if it has external inputs :) but you know that your code will execute 'linearly' and then adhere to any program flow constructs you put in, and nothing else. You can be 100% sure that it won't suddenly stop executing here, and jump over to some totally disconnected bit of code for a while, then jump back. You don't have to worry about a whole class of bugs which take up weeks/months of peoples time. Not sure what you mean @ timers, I was really talking about async/event driven in general. Timers seem like an implementation specific detail on top of that. I haven't really seen any issues myself there :/
  - jerf 17y ago
    "You don't have to worry about a whole class of bugs which take up weeks/months of peoples time." I reiterate, you need to spend some quality time with Erlang. This time I recommend http://erlang.org/download/erlang-book-part1.pdf http://erlang.org/download/erlang-book-part1.pdf ; Erlang has some powerful answers to those "whole class of bugs". (Actually, not being aware of that does rather make sense of the rest of your views. I have first-hand experience that Erlang really does make those problems go away; I like to say that Erlang takes concurrent programming from an exponential problem to a polynomial one. It still isn't "trivial" and I don't know that it ever can be, but it makes it so a human can do it.)
jerf 17y ago
That's flat out ridiculous, to the point I have a hard time not just calling it stupid. Nothing stops you from using thread pools in Erlang, if that's what you want to do. It's just that you aren't required to do it, either. You compare "an idiot writing Erlang" with "a smart person writing in an event-based system", but who cares about that comparison? Event-based async programming is a hack around language weaknesses and is a strict subset of Erlang's capabilities, in that anything you could write in those frameworks you can write in Erlang. Yes, including "knowing when things execute". In fact I'd say you get more control because you have more choices; you don't have to lock things up if you want to actually run a computation of some sort. I suggest you spend some quality time with http://www.erlang.org/doc/design_principles/users_guide.html http://www.erlang.org/doc/design_principles/users_guide.html . You can stop at the "included applications" chapter. Erlang is a friend to event-based stuff, after all, it just handles it naturally, without you having to do the scheduling unless you want to.

by axod 17y ago

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)

tptacek 17y ago

You don't really know a priori the order everything is executing in, unless you control the remote ends of all the connections and you have no timers. I've lost days of my life to timer cancellation bugs.

axod 17y ago
Sure, you don't know the exact order your code executes if it has external inputs :) but you know that your code will execute 'linearly' and then adhere to any program flow constructs you put in, and nothing else. You can be 100% sure that it won't suddenly stop executing here, and jump over to some totally disconnected bit of code for a while, then jump back. You don't have to worry about a whole class of bugs which take up weeks/months of peoples time. Not sure what you mean @ timers, I was really talking about async/event driven in general. Timers seem like an implementation specific detail on top of that. I haven't really seen any issues myself there :/
- jerf 17y ago
  "You don't have to worry about a whole class of bugs which take up weeks/months of peoples time." I reiterate, you need to spend some quality time with Erlang. This time I recommend http://erlang.org/download/erlang-book-part1.pdf http://erlang.org/download/erlang-book-part1.pdf ; Erlang has some powerful answers to those "whole class of bugs". (Actually, not being aware of that does rather make sense of the rest of your views. I have first-hand experience that Erlang really does make those problems go away; I like to say that Erlang takes concurrent programming from an exponential problem to a polynomial one. It still isn't "trivial" and I don't know that it ever can be, but it makes it so a human can do it.)

jerf 17y ago

That's flat out ridiculous, to the point I have a hard time not just calling it stupid. Nothing stops you from using thread pools in Erlang, if that's what you want to do. It's just that you aren't required to do it, either. You compare "an idiot writing Erlang" with "a smart person writing in an event-based system", but who cares about that comparison? Event-based async programming is a hack around language weaknesses and is a strict subset of Erlang's capabilities, in that anything you could write in those frameworks you can write in Erlang. Yes, including "knowing when things execute". In fact I'd say you get more control because you have more choices; you don't have to lock things up if you want to actually run a computation of some sort. I suggest you spend some quality time with http://www.erlang.org/doc/design_principles/users_guide.html http://www.erlang.org/doc/design_principles/users_guide.html . You can stop at the "included applications" chapter. Erlang is a friend to event-based stuff, after all, it just handles it naturally, without you having to do the scheduling unless you want to.