7 ms·

Original blub code should look like that: frame.addKeyListener(new KeyListener() { public void keyTyped(KeyEvent event) { switch (event.getKeyCh

Original blub code should look like that: frame.addKeyListener(new KeyListener() { public void keyTyped(KeyEvent event) { switch (event.getKeyChar()) { case 'j': drop(); break; case 'h': move(-1); break; case 'k': move(1); break; case 'u': rotate(); break; } } public void keyPressed(KeyEvent event) { } public void keyReleased(KeyEvent event) { } }); About Arc code: (on-key-press frame 'u (rotate-shape) 'j (drop-shape) 'h (move-shape -1) 'k (move-shape 1)) Is this code ADDS NEW key event handler OR OVERRIDES old one? When it is invoked - when key is PRESSED or when key is TYPED?

illumen 17y ago
ah, events as function calls. How so terribly 50's. here's a way where events are objects... rather than an invocation. Much more flexible. a python + pygame example... cu, key_handlers= dict(u=rotate, j=drop, h=lambda : move(-1), k=lambda : move(-1)) buttons = {1:'u', 2:'j', 3:'h', 4:'k'} for e in pygame.event.get(): if e.type == KEYDOWN: key_handlers[e.key]() elif e.type == JOYBUTTONDOWN: key_handlers[buttons[e.button]]() elif e.type in [QUIT, MOUSEBUTTONDOWN, HTTPD]: quit()
- stcredzero 17y ago
  The grandparent code is much easier to understand.
  - illumen 17y ago
    The claim is Arc is agile and short... The Arc one has too many ()() all over the place. The arc one is also less powerful, because it uses different function invocations for different types of events. It's also likely more people will understand the python+pygame version. More people do currently understand the python version... hardly anyone uses Arc. You need to understand non-common concepts. You also need to understand how to create functions - rather than just call functions. Does that Arc one mean when the key down happens, or when a key up happens? Or maybe it means in between the key press and key down. Also, when will that code be called? It's magic. Will it be called from a separate thread, or some other Magic time... before or after the screen is to be updated? What else is going on at that time in the program? With the Arc version you have no idea... it's not explicit. Also Arc doesn't have first class events. It could have yes, but it doesn't. ps. the python code above was mangled by the buggy Arc program running this forum. Here is the code redone for simplicity without the extra shortness and power expressed in the other version. . for e in pygame.event.get(): if e.type == KEYDOWN: if e.unicode == 'u': shape.rotate() elif e.unicode == 'j': shape.drop() elif e.unicode == 'h': shape.move(-1) elif e.unicode == 'k': shape.move(1) Or the declarative python version: . dict( u=rotate , j=drop , h=lambda:move(-1) , k=lambda:move(-1))
    - stcredzero 17y ago
      The arc one is also less powerful, because it uses different function invocations for different types of events. Actually, that would make it more powerful. You can use polymorphism. It's also likely more people will understand the python+pygame version. More people do currently understand the python version... hardly anyone uses Arc. Missing the point. Conciseness is not best measured by eyes familiar with the language/library. It's best evaluated from the POV of the uninitiated. I have to parse and run a model to understand your first version. Your second version is as easily understandable as the Arc example in one way, but it's got a lot more pollution and an enforced higher line count. I am answering as someone not well versed in either Python or Arc. (Actually a little more familiar with Python.)
10ren 17y ago
Yes, most of the examples in the non-Arc language were written with artificial duplication, which obscures the actual advantages of Arc. There's the `printIfNotNull(foo.getBar().getName()); // pointless method`, also pointed out by axon, and the following code being duplicated instead of being a function: if (log.isDebugEnabled()) { log.debug("foo.valueOf(expression) = " + foo.valueOf(expression)); } BTW: heads up on your comment formatting: HN needs a blank line between text and code for 4-space indentation to be recognized.

illumen 17y ago

ah, events as function calls. How so terribly 50's. here's a way where events are objects... rather than an invocation. Much more flexible. a python + pygame example... cu, key_handlers= dict(u=rotate, j=drop, h=lambda : move(-1), k=lambda : move(-1)) buttons = {1:'u', 2:'j', 3:'h', 4:'k'} for e in pygame.event.get(): if e.type == KEYDOWN: key_handlers[e.key]() elif e.type == JOYBUTTONDOWN: key_handlers[buttons[e.button]]() elif e.type in [QUIT, MOUSEBUTTONDOWN, HTTPD]: quit()

stcredzero 17y ago
The grandparent code is much easier to understand.
- illumen 17y ago
  The claim is Arc is agile and short... The Arc one has too many ()() all over the place. The arc one is also less powerful, because it uses different function invocations for different types of events. It's also likely more people will understand the python+pygame version. More people do currently understand the python version... hardly anyone uses Arc. You need to understand non-common concepts. You also need to understand how to create functions - rather than just call functions. Does that Arc one mean when the key down happens, or when a key up happens? Or maybe it means in between the key press and key down. Also, when will that code be called? It's magic. Will it be called from a separate thread, or some other Magic time... before or after the screen is to be updated? What else is going on at that time in the program? With the Arc version you have no idea... it's not explicit. Also Arc doesn't have first class events. It could have yes, but it doesn't. ps. the python code above was mangled by the buggy Arc program running this forum. Here is the code redone for simplicity without the extra shortness and power expressed in the other version. . for e in pygame.event.get(): if e.type == KEYDOWN: if e.unicode == 'u': shape.rotate() elif e.unicode == 'j': shape.drop() elif e.unicode == 'h': shape.move(-1) elif e.unicode == 'k': shape.move(1) Or the declarative python version: . dict( u=rotate , j=drop , h=lambda:move(-1) , k=lambda:move(-1))
  - stcredzero 17y ago
    The arc one is also less powerful, because it uses different function invocations for different types of events. Actually, that would make it more powerful. You can use polymorphism. It's also likely more people will understand the python+pygame version. More people do currently understand the python version... hardly anyone uses Arc. Missing the point. Conciseness is not best measured by eyes familiar with the language/library. It's best evaluated from the POV of the uninitiated. I have to parse and run a model to understand your first version. Your second version is as easily understandable as the Arc example in one way, but it's got a lot more pollution and an enforced higher line count. I am answering as someone not well versed in either Python or Arc. (Actually a little more familiar with Python.)

10ren 17y ago

Yes, most of the examples in the non-Arc language were written with artificial duplication, which obscures the actual advantages of Arc. There's the `printIfNotNull(foo.getBar().getName()); // pointless method`, also pointed out by axon, and the following code being duplicated instead of being a function: if (log.isDebugEnabled()) { log.debug("foo.valueOf(expression) = " + foo.valueOf(expression)); } BTW: heads up on your comment formatting: HN needs a blank line between text and code for 4-space indentation to be recognized.