Talk:Event-driven programming

Does anyone have a subscription to ArchiveNews.com? If so, would you let me know. I have a favor to ask.

WHAT IS AN "EVENT BOOB JOB" ?

-pressing a key of keyboard ,--- Example

In the example part there is the folowing text "fi" shouldn't this be "endif" of "end if" ? --Killerog 09:29, 14 June 2006 (UTC)

This is just an indicator that the pseudocode style of the original author has some ALGOL 68 heritage ;) --62.206.21.253 10:13, 11 December 2006 (UTC)

Merged all content from Event driven programming language

It was on the same subject, but improperly titled. The EDPL page was (IMO) much more informative, so its content is now dominant. This page could be improved by

1. Better real-world examples of ways to use EDP (I suspect the socket example may be one, but I am not at all versed in the subject.
2. Linking the description of EDP to the references.

Nate 16:24, 6 December 2006 (UTC)

Events vs. Threading

I think a paragraph in event-driven programming vs. threading would be good, since they are often confused. Anyone? 72.140.200.178 17:56, 16 December 2006 (UTC)

Keep an eye out for this spammer

Edit protection has been added to Visual Basic due to an AIV. The spammer has also tried putting those links on this page once, so they may retry here. If you notice, could you report back to either the VB talk page or my talk page. Thanks, John Vandenberg 14:44, 16 June 2007 (UTC)

Event-driven or Event-based?

Many people use the term 'event-based', there are also three books which use 'event-based'. Any idea? —Preceding unsigned comment added by 64.62.138.33 (talk) 08:43, August 25, 2007 (UTC)

merger proposal

---

Event in Computing should not be merged with Event Notification (or Event Driven Architecture) as the latter is used only in the enterprise application integration(EAI). A keyboard or mouse event (as given in the Wikipedia example) should not be compared with event that criss cross enterprise systems. (L.Sukumaran - 27-Aug-08).

--- —Preceding unsigned comment added by 203.158.94.82 (talk) 06:45, 27 August 2008 (UTC)

I don't think that Event Driven Architecture should be the same as event-driven programming.

---

Absolutely Event Driven Architacture is *not* the same as Event Driven Programming. Event Driven Architacture is a term coined by Gartner to describe enterprise systems where asynchronous business events are a key element of the IT infrastructure. Business events initiate business processes or change the state of currently running processes. EDA is seen as loosely-coupled fine-grained asynchronous events which is complementary to the largely synchronous, request-reply semantics that are common in SOA.

---

I don't think Event Driven Programming is necessarily the same as Event Driven Architecture - unless you believe that IT architecture is not a valid discipline. Architecture defines the framework and concepts, while programming realises and implements them, but this article does need a rewrite. It needs to be much clearer about what EDA is and cite references Peter Campbell Talk! 00:03, 3 August 2006 (UTC)

---

There are various disconnected merger proposals relating to articles in the Category:Event (computing). I think it would be better to focus on tidying up the whole category. --RichardVeryard 08:27, 27 August 2007 (UTC)

batch programming vs. event-driven

Hmm, I wouldn't say event-driven is opposite to batch (although they are mutually exclusive). The not batch is interactive, and not every interactive program is event-driven. For example,

 #include <stdio.h>
 int main() {
    char buf[512];
    printf("What's your name? ");
    if(!fgets(buf, sizeof(buf), stdin)) return 1;
    printf("I'm pleased to meet you, dear %s!\n", buf);
    return 0;
 }

is obviously interactive, but in no way event-driven. DrCroco (talk) 17:28, 29 January 2008 (UTC)

I concur. This section confuses batch programming with other interactive programming techniques that aren't event driven. I've adjusted the batch sample to no longer be interactive (It no longer reads the keyboard.), but I'm uncertain of the value of the entire section. Perhaps explaining the process order of event driven programming would be better? Mrfelis (talk) 21:31, 19 July 2010 (UTC)

Actually, I think your example is an excellent illustration of the murkiness of the concept. For instance, user input is collected and the program blocks until an enter keystroke is registered. At the hardware level, what is going on? It's unlikely that the program is polling repeatedly for keystrokes. I'm guessing the hardware is raising an interrupt. This would make the concept of a user pressing the enter key very close to what we mean by "event driven". The key is pressed and an interrupt, which is clearly an event, notifies the process that input is waiting in some sort of buffer. The process receives this message and continues execution. You seem to think of it in terms of a programming paradigm, but I think any program that blocks for user input and doesn't have a polling loop will be event driven at some level. --Morticae (talk) 04:20, 3 November 2009 (UTC)

Regardless of what the hardware and/or OS is doing, the programmer writing a batch program is still writing a batch program even if the OS is capable of multitasking. When a batch program asks to read data from a device, that program blocks. In an early 90's era PC some devices would notify the Programmable Interrupt Controller (PIC) that data is available. The PIC then generated an interrupt that forced the CPU to jump to an address (probably some place in BIOS unless the device was more exotic - like a sound card or mouse) for handling that would read the data from the device. At this point the OS would unblock the batch program and provide the data from the device.

Some devices were not considered important enough to justify using a hardware interrupt (there were only 15 available) and had to be polled. The joystick that plugged into back of the sound blaster card is an example.

Event driven programs don't block, and the program is free to do other useful work while waiting for some event. Batch programs stop running. This difference is significant. This article needs a lot of clarification before attempting to explain how the multiple levels of a computer system's architecture blur the lines. At this point, explaining this would do more than just further confuse the subject of an already weak article. Mrfelis (talk) 21:31, 19 July 2010 (UTC)

What do hardware languages have to do?

I find this assertion highly dubious:

Hardware description language (like Verilog and VHDL) are essentially multi-threaded programming languages based on an event-driven paradigm

HDLs are not anywhere near to "threaded" programming languages (threads run on a processor connected to a memory stack, while HDLs are directly translated to hardware), and their paradigm is more "continuous" than "event-driven". I think this should be explained with much more clarity for it to stay in the article, otherwise I can't see how event-driven relates to this kind of languages. Diego (talk) 20:51, 16 June 2008 (UTC)

I have just finished a blog entry, that explains how HDLs outperform the conventional, serial, programming in reaction to state change and would like to defend the assertion. At first, though the programming threads are much "heavier" than the HDL processes, they are known as lightweight process. Secondly, the HDLs, VHDL for sure, do heavily rely on the notion of "event" to drive the processes: one signal change causes change of other signals that depend on it and so on. The simulation goes on as long as there are any events scheduled to simulate. --Javalenok (talk) 10:46, 5 June 2010 (UTC)

I would agree that hardware description languages resemble dataflow programming or signal programming (especially in the synchronous sense), but the concept of event-driven programming is less close. Even-driven programming is based on an event queue, which is served asyncronously in a first-come first-severed fasion rather than by parallel processes.Mange01 (talk) 19:45, 5 June 2010 (UTC)

Take a major HDL, the VHDL. Its semantics is defined for (delta-cycle) simulation. Literally, "The simulation philosophy of VHDL is based on the ordering of events in time: new events are generated as result of actions taken in response to other events scheduled for previous simulation times." The simulation runs until there is at least one event in the queue. This is literal meaning of 'event-driven'. So, the HDL is true (asynchronous) event-driven by nature. Any synchronization is implemented 'on top'. So, despite most of HW might be synchronous, it does not mean that HDLs are. Neither organizing the boolean operators and larger processors into a dataflow network (VHDL "programming" is description of HW circuit indeed rather than explicit event specification) implies the circuit model is evaluated in fashion different from event driven. The article definition requires only program behaviour to be determined by events rather than the programming style. In Java or Delphi, you register the event handlers explicitly. As I mentioned above, this is 'syntactic salt'. Got rid of it, you'll get the sugar, the event-driven friendly HDL dataflow style. --Javalenok (talk) 14:36, 12 October 2010 (UTC)

"Fertile Ground For Bugs" edit

Edits from December 2010 have replaced criticism of Event-driver programming with something that appears rather dubious, or at least extremely unclear.

I'm most bothered by the line "doesn't try to have shared memory problems that can be solved with fancy algorithms," which sounds like pure snark. But I don't know a thing about this subject, so maybe I'm just misunderstanding what it tries to do (or what's being snarked at).

Can somebody please examine the edit, and clarify or revert as necessary? Standback (talk) 07:53, 21 February 2011 (UTC)

Looking at the edit, I also agree it looks snark. I would suggest moving it back to its original form. Anonymous