Wednesday, 26 October 2016

Unit 14 - A1

Task 1
What is an Event Driven Language?
An even driven language is very self-explanatory. This is because as certain events occur within the language which causes different events to occur for example, when you click on different icons within the operating system that event causes the program to load within the operating system. The same can happen within different apps or games, as the user performs different inputs, those events cause responses from the game.
Typical events in your chosen language – Python
The language that I have chosen is Python, this is an Event Driven programming language because you are able to code into the program and then that allows a user to provide their own input into the system and then the appropriate output occurs (hence why it is an event driven language).


Key Features:
Service Oriented – This is something in event driven programming and it means that it takes very little of a computers processing power meaning is does not slow down the computer. “Services” themselves are programs that run in the background of an OS (Windows, Mac, Linux), these have services so your computer system is much more user friendly. An example of this could be, when you first plug a USB memory stick or input device (keyboard) the operating system begins to install the necessary drivers in the background.

Time Driven – A time driven feature in event driven programming runs a specific code based on a timely basis every hour, on a specific day, once a week etc. An example of this could be scheduled Virus Scans, this is where you go into your respective Anti-Virus software and you choose the days that a scan is run and what time the scans are to run.

Event Handlers – These are in event driven programming and are designed to run a specific action when a specific event is triggered. The best example that can be used to help understand this is the key combination of “Ctrl + Shift + Esc”, when these buttons are pressed together they trigger the event to bring up the Task Manager application.

Trigger Functions – They are mechanisms that decide what code to run when a specific event occurs, trigger functions are used to select which event handler to use for the specific event that has occurred. Many devices have trigger functions with a specific event that runs for it. For example, automated doors have a sensor that when someone is in proximity of the sensor, it sends a signal to open the door.

Now I am going to describe some of the benefits of Python:
·         Simple – Python is a simple and minimalistic language. Reading a program that is well written in Python, can be compared to standard English. This is because coding in Python follows a relatively logical process and doesn’t really require strange coding words or number-word combinations. If you want to change something just think about what it’s called and you can change it! Also; with Python having this element of pseudo-code integration, it can be one of its greatest assets. It helps because you can simply figure out a solution to any programming issues that may arise rather than work out a very convoluted solution, because the language is so intuitive.
·
  
Easy to Learn – This feature co-insides with the previous point, because Python has such a simple syntax that the language has.
·
  
Free and Open Source – Python is an example of Open Source software. This is basically where you can freely distribute copies of the software, you can read its source, you can even make changes to it! This is another reason why Python is good, because it is open source it means that it is constantly being improved because of the Python community.
·
  
High-Level Language – This is something that is quite counter-intuitive about Python. When something is a “High-Level” language it doesn’t mean that it is difficult, it just means that the programmer doesn’t have to concern themselves with “Low-Level” details such as managing memory usage used by the program.
·
  
Portable – Thanks to Python’s open-source nature, Python has been ported to many different platforms (this means that is has been changed in order to make it work on other systems). All Python programs can work on any of these platforms (and there are a lot); Linux, Windows, FreeBSD, Macintosh, Solaris, OS/2, Amiga, AROS, AS/400, BeOS, OS/390, z/OS, Palm OS, QNX, VMS, Psion, Acorn RISC OS, VxWorks, PlayStation, Sharp Zaurus, Windows CE and even PocketPC.
·
  
Interpreted – A program that is written in a “Compiled Language” such as C or C++, it is converted from the source language e.g. C or C++, into a language that is spoken by your computer (binary code is the most common, it is 0s and 1s). This is done through the use of flags and options. When you run the program written in those languages, the linker/loader software copies the program from hard disk to memory and starts running it.
Python on the other hand, doesn’t need to be compiled into binary. You can just run the program directly from the source code. Internally, Python converts the source code into an intermediate form called bytecodes and then translates this into the native language of your computer and then runs it. When all of this is considered, it actually means that Python is easier to use simply because you don’t have to worry about compiling the program, making sure that the proper libraries are linked and loaded. This also makes your Python programs more portable, since you can just load the program onto another computer and 99% of the time it will just work.
·
  
Object Oriented – Python supports procedure-oriented programming as well as object-oriented programming. In procedure-oriented languages, the program is built around procedures or functions that are nothing but reusable pieces of the program. In object-oriented languages, the program is built around objects which combine data and functionality. Python has an incredibly powerful yet comically simple way of performing OOP, especially when compared to “big languages” such as C++ and Java.
·
  
Extensible – If you were to need a critical piece of code to run very fast or if you were to want to have some piece of algorithm not to be open, you can code that part of your program in C or C++ and then use them from your Python program.
·
  
Embeddable – You can embed Python within your C/C++ programs to give “scripting” capabilities for your program’s users.
·
  
Extensive Libraries – The Python Standard Library (PSL) is massive. It can help you perform various things involving regular expressions, documentation generation, unit testing, threading, databases… The list goes on and on, what’s more is that this is available wherever Python is installed. This is called the “Batteries Included” philosophy of Python. Even though Python already has this mind blowing library built in, there are other quality libraries such as wxPython, Twisted and the Python Imaging Library to name a few!


Now then, even though all of this is fantastic. As with anything there has to be some disadvantages that comes with Python. These are some of the disadvantages that I have found from my research:
·
  
Python isn’t the best for memory intensive tasks – This is because it is a High-Level language as mentioned before. Because you can’t specify the memory allocation within Python you can’t optimise Python for memory intensive tasks.
·
  
Python is an interpreted language and is slow when compared to C, C++ or Java – Even though you can use C and C++ within Python, the language itself is still very slow and is the reason why you shouldn’t use Python for something that needs to perform at high speeds.
·
  
Python is not a great choice for a high-graphic 3D game that takes up a lot of CPU.
·
  
Python is evolving continuously, with constant evolution there is little substantial documentation available for the language.

Task 2

Operating Systems Are Event Driven Applications
Based on the information that I have previously stated about what an Event Driven language is, I can draw direct comparisons to Operating Systems such as Windows and Mac OS.
The first thing that helps to support that claim that operating systems are event driven is installing the Operating System itself. This is because the installation can only progress when certain events occur. For example, the installation of an Operating System cannot begin until the user has selected the language that they want the Operating System to run in. This is an example of a Click Event and only when this event has been triggered may the installation of the Operating System begin. Also, each of the stages of the installation cannot occur until the previous stage has been completed. This is also considered event driven because, only in the event of the previous stage being completed may the installation continue.
Next, once the Operating System has been installed successfully installed you are greeted with the respective GUI desktop. The desktop found within an operating system is populated by many potential event driven programs; the most obvious example would be the Start Menu. This is because you can trigger the start menu to appear by either clicking the windows icon in the bottom left corner or you can press the windows key on your keyboard. This is the event that causes the start menu to appear.


















Another way I can demonstrate that there is event driven properties within operating systems is through the drag and drop characteristics that are very commonly found within OS such as Windows. This is useful when a user wants to take their desktop and manoeuvre them to their liking.























This is an example of using the drag and drop functionality in order to move the different icons to where I want them to be. This is considered to be event driven because it is based around the click event. Because you need to use the left click and hold it, that triggers the selection within Windows and then by moving the mouse that event causes the icon to move on the screen.

The next example that I am going to discuss is when an external storage device is connected to a computer. Typically, people connect either USB sticks or SD cards to computers because they want to take the data off the storage device. This can be anything from assignments, work that they need to complete for their job or even videos and photos from their most recent holiday. Once the preferred storage device has been connected to the computer this is what causes the series of events to occur. In the case of my computer, as soon as my USB stick is placed into a USB port on my computer the USB instantly opens, this means that I am greeted with this screen:











However, if I were to use a USB stick that my computer doesn’t recognise a small window would appear towards the right of my screen saying “choose how ‘USB’ opens” and it will give you options such as; Open (this is what I usually choose because I just want to connect a USB and then use it), there is the option to have the computer automatically copy all of the files off the USB stick to your chosen hard drive and even an option that says “Do Nothing” so literally nothing happens when you connect a USB stick to your computer (not an option I would personally recommend).
There are even events within a computer that requires an input once but, then you have changed the event and it will occur on its own. An example of this would be setting your anti-virus software to run a scan every other day at 5pm. By using the traditional click event you are causing another event to occur, once the 5pm time has been set this means that the event will wait. Then when the clock on the computer says that it is 5pm, this event triggers the anti-virus software to begin scanning the computer for any potential viruses, malware and unwanted programmes. This is a different type of event but it is still an event that needs to occur before the scan can be initialised. This is simply another example of the near infinite ways event programming is present within an operating system.
Taking all the previous examples that I have already mentioned into account we can safely assume that Operating Systems are Event Driven. Everything that can potentially happen within an Operating System is event driven. Computers are meant to respond to the different inputs that can be formed by the user of the respective Operating System (Windows, Mac, Linux, Android etc.) even if we go all the way back to the beginning of using a computer, when you press the power button on a computer that is what causes the Operating System to boot. Even this blog that I am writing is entirely event driven. I needed to boot up my computer, log in to my account by using a keyboard to provide the correct input to then cause the computer to allow me to access my local user account within Windows 10. I then needed to open the Word file, this being done with the mouse and the click events. Then there is the input that is being created using my keyboards which is causing all the letters to appear within the word document, at consistent intervals throughout writing this blog I am pressing ctrl + s to trigger the save file event; and so forth and so forth. Everything that is found within an Operating System is event driven and I would hope that I have provided enough thorough evidence to prove my original statement.

Task 3

Everything is Event Driven

In this final task, I have been asked to discuss the suitability of event-driven languages for creating a non-graphical program.

To summarise everything I am about to say into a sentence; most of the things that you can think of are based on event driven programming and even some of the things you wouldn't think of are event driven.

To begin I will talk about the more obvious things that you may not have considered to be event driven within your home. 
The first thing that I will talk about is things like your kettle and your washing machine. This is because they are still event driven programs. While it doesn't seem like they are, when we think about how they work it becomes obvious as to why they are. A kettle beings to heat up the water when the button is pressed, the water is then continually heated up until the internal thermostat detects that the water has reached the proper temperature of 100 degrees Celsius. This event triggers the kettle to stop boiling and this is why kettles are event driven. Event driven programming is suitable for a kettle because it means that the water doesn't boil for too long and it means that the water won't burst out of kettle injuring the user.

Washing machines also follow a similar event driven programming. When you think about it, washing machines have all of the different settings that they can use for all of the different washing cycles and such; but then wishing each of the washing cycles there are different events that occur. For example, if you wanted to perform a simple 40 degree wash, then you would first need to set the dial for the desired wash cycle. From there, the user will need to press the begin cycle button so the washing machine initiates. From there the washing machine will have a set of events that will occur to wash the laundry, this will go from the water coming into the drum of the washing machine, to the different rotations that happen throughout the cycle. There will be different directions for the rotations and the different speeds during the cycle. Event driven programming is suitable in a washing machine because it allows the washing machine to properly clean the clothes.

Thermostats can be another thing that is event driven but this is much simpler to explain and understand, this is because as the ambient temperature around the thermostat changes so does the display as it updates to accommodate the changes in temperature. Event driven programming is suitable for a thermostat because it is connected to the central heating. In this there is a temperature target then the cannot be exceeded nor can the temperature be less than. What this means is that the room will always be a constant temperature and the user will not be too cold or too hot.

Alarm systems also work on a similar system. Very simple, but powerful. This is because when you arm the alarm you have to put in a specific code that arms the alarm. Then when the circuit is whole (as shown here)
This is the complete circuit that will be armed as the door is closed and the alarm turned on. When someone (either an intruder or the home owner) enters the house this breaks the circuit and this is what causes the alarm to trigger and begin alerting people. The alarm will only cease if the correct code is then entered again. If an incorrect code is entered multiple times or the code is not entered within a certain amount of time then the loud alarm will trigger. This is why an alarm system is event triggered. Event driven programming is suitable for an alarm, because the alarm will only trigger when the circuit is broken. This means that the alarm wont constantly go off and make a loud annoying noise.

DVD players are another example of one of the many devices that are event driven, this is because when the DVD is put into the player this event causes the player to begin reading the disk in order to produce the image onto the output device that it is connected to (screen, monitor, projector etc.) Even driven programming is suitable for a DVD player because it allows the user to change some of the settings when the DVD first starts, watch bonus content that is on the disk and even something as simple as pause the DVD and play again.

Microwaves (just like everything previously mentioned) work on the basis of event driven programming. The microwave works similarly to the washing machine, this is because when the user decides to use the microwave they can either set the microwave to a preset option or they can use a combination of power settings and timing settings to cook the food. Even driven programming is suitable for a Microwave because it means that the food/drink that has been placed into the Microwave doesn't over cook or burn and potentially damage the Microwave.

The final event driven application that I am going to discuss is a mobile phone. This can be explained quite simply as a small computer, that is basically how a mobile phone now works. Depending on the mobile phone that is being use there are different events that can be triggered. This is because there are some phones that are entirely touchscreen, touchscreen but has some buttons, and there are even some mobile phones that are entirely button based. But, they all do the same basic few things. In terms of why they are event driven, I could be here all day explaining why so, I will only comment on a few things.
First, you will need to power on the phone regardless and by pressing the power button you have triggered the phone to turn on. Once the phone has turned on, most mobile phones have a lock screen that the user is then presented with. Once presented with, the screen can then be unlocked in a variety of ways; on “old school” phones, there is typically a key on the face of the phone that corresponds with the “unlock” button. On typical touchscreen phones, when the user tries to unlock the phone they are required to either input a number code, a password or a pattern/symbol. The last example, is that there are some phones that have biometric scanners (fingerprint scanners) that a user can use to unlock their phone. These events need to be met to trigger the phone to unlock and allow the user to use it. We can even be more pedantic and say that when a person calls another person that is a series of events that trigger to allow the phone call to occur. Event driven programming is suitable for mobile phones because they are entirely interactive. They need the different events that are provided by the user in order to function. Just something like a making a phone number you need to input the phone number of the person that you want to call, therefore event driven programming is required for a mobile phone to work.


So as you can tell. Everything that in the world of technology is event driven!

No comments:

Post a Comment