Posts Tagged ‘Programming’

Picking the first language to learn for novice programmers can be a daunting task. For many, they simply have no clear where to start, and don’t know any of the merits and drawbacks of the various choices they have. Even among experienced programmers, the debate on what new programmers should start with is long and has many different sides. In this article I will give my side.

My Perspective

Before I talk about which language people should start trying to learn first, I will discuss where I am coming from when I make that choice. The first language someone learns in my opinion should be fairly easy to develop with, and be able to give the programmer results fairly quickly. The main problem I generally see with fledgling programmers just starting out is that they get very frustrated with error messages, and in general struggle to connect the concepts they are working with to an actual useful program. I keep these things in mind when making my choice.

 

My Opinion

For new programmers, I highly recommend starting with a web development related language, namely Javascript or PHP, PHP being the first recommendation. The reason I say this is simple. PHP is a very easy language to program in. As a scripting language,  development goes much faster (no having to recompile upon changing a single line of code), and the language itself is much more forgiving. A new user doesn’t have to memorize many different syntactical rules, so all they have to focus on is understanding the concepts, and getting practice with solving problems. Also, PHP (and to an extent, Javascript) comes right out of the box with many various helper functions and algorithms that in other languages you need to either import a library, or write the function yourself. This allows novice programmers to solve problems much faster and easier. However, this comes with a drawback. A programmer who gets used to PHP having a lot of functionality built in that other languages don’t have by default may make it difficult for the programmer to migrate to different languages/platforms. On the other hand, while the programmer may become too reliant on these built in functions, they do know to some extent how to solve a similar problem with another language. The new problem becomes finding out how the other language implements the functionality used in the built in PHP function, or how to write it themselves.

The second reason I suggest PHP (or Javascript), and web development in general is because it makes using the various concepts they’ve learned in practice more rewarding. It is much easier to make an interactive GUI with PHP combined with HTML/CSS than with a programming language like C++, Java, or even Python. Because of this, its much easier to make a “cool” application even with only basic skills. Making a website where you can log in and see a welcome screen is extremely easy with PHP and HTML, but would be much more difficult for a novice in, say, C++ or Java.

 

Drawbacks

While learning PHP (or web development in general) first is not a bad idea, there are some drawbacks. One thing, which I mentioned earlier in this post, was that many novice users who use PHP may become dependent on the built in functions that aren’t available in other languages without either importing a library, or writing the code yourself. This can make transitioning to a more difficult language even harder. This type of problem isn’t unique to PHP either, but common to people who start with most scripting languages, and than transition to a more difficult, stricter language. For example, in my school, the introductory programming class used Python, while the next class (Object Oriented Programming) is taught using C++. Many of the students who go from the first class to the second struggle early in the class with the unavailability of certain functionality that they got so used to using in Python.

Another issue is bad habits that are easy to form with scripting languages. Since most scripting languages have no explicit typing, the concept of a variable with a type can be difficult to understand, especially if you have been programming for a good amount of time.

In general, since scripting languages or usually much easier than stricter programming languages, novice programmers are able to progress faster and without much frustration, but they can pick up bad habits, like the expectation of the language to provide certain functionality, or the expectation of the program to handle many things in the background that you have to set up yourself in stricter languages. The example that one may come to think of first is garbage collection, which is available in most scripting languages, and even some strict programming languages (most notable being Java), but not in, say, C++. Scripting languages also hide many of the core functionality that is inherent in the language from the user. This can create programmers who know how to do something a certain way, but have no idea of the concept behind what allows them to accomplish whatever goal they have. This makes it much harder for these programmers to solve more complex problems that require knowledge of how programs and the underlying code actually works. For example, a novice may figure out how to stop a certain PHP notice from occurring by using the notice suppression operator (the @ operator), but may have no clue why that operator actually fixes (well it doesn’t actually fix the error, but rather stops it from being reported) the error.

However, these problems can be resolved by going from learning an easy scripting language to learning a more difficult, stricter programming language like C++ (in fact, I highly recommend starting with PHP/Javascript and even MySQL if you are adventurous, and then learning C++ in depth). This way, the programmer gets the benefits of learning a very strict language like C++, where you essentially have full control over your program and therefore have to know not only how to solve problems, but why certain code and concepts solve the problem. Also, the programmer won’t be nearly as frustrated since they already have a language under their belt. The learning curve of C++ is high enough, but some of that difficulty can be mitigated if you already have practice with most or all of the basic programming concepts.

 

In short, for anyone who wishes to learn how to program and make applications, I suggest starting with web design, namely PHP (but Javascript, ASP, or any other web based language would work) because development is faster and easier for a novice programmer, and seeing the results of your knowledge and making cool, useful applications is much easier, especially if you want to incorporate some sort of GUI elements.

As a side note, since not everyone is interested in web design, or has the means to purchase a server (although you can always download software like LAMP, or WAMP to turn your computer into a local web server), other scripting languages will work as well. If you are going to go this route, I suggest Python personally.

 

If you have any questions or comments, or disagree with what I say, leave a comment below! I would love to have a discussion with someone who has a differing opinion from mine.

As a tutor and coding help forum poster, I notice many instances of people using OOP, but using it incorrectly. Now, i don’t necessarily mean that they have errors in their code, or that it isn’t logically correct, but rather that the programmer in question has problems with their concepts of OOP. In this post I’ll be discussing the very basic and common problems I see, and ways to think about OOP such that these mistakes can be avoided. I’ll only be going over two of the simplest OOP concepts, encapsulation and inheritance.

Object Oriented Programming: The Why?

Many people simply use Object Oriented Programming because its the “latest and greatest” paradigm in the computer science field. The problem is that they learn the syntax and semantics of OOP, but never truely learn what OOP is. Let me start by giving a basic explanation of what OOP brings to the table as far as programming is concerned.

First, the basic concept of OOP is instead of programming procedurally, or functionally, you program in such a way that your entire program consists of discrete, separate objects that interact with each other in certain ways. This concept is fairly easy to understand, but doesn’t quite explain how to implement such a program that takes advantage of all OOP has to offer. However, lets take a simple example to further illustrate this concept. Lets say we are writing a program to model driving a car. Each car is a separate object of course, but these objects are instances of the same class (in the case, a car), but have different properties. Some are fast, some are strong, and some have great gas mileage. Each car, consequently, is composed of many other discrete objects. Like the rear view mirror, or the engine (which in turn could be composed of other objects) and the tires (and of course these each have their own attributes). Then there is the driver of the car which is another object that interacts directly with the car. The Driver tells the car to drive, and the car in turn tells the engine to turn on, and tells the wheels to spin. The Driver doesn’t ever interact with the individual components of a car, but rather the car itself. The car interacts with each individual components. In (very PHP-like) pseudo code, this interaction might look something like

$Honda_Accord =  new Car();
$Honda_Accord->addEngine(new Engine());
//add rest of components
$bob = new Driver();
$bob->Drive($Honda_Accord);

//inside the drive method,
$Honda_Accord->start_engine();
$Honda_Accord->spin_wheels();
//etc..

Encapsulation

This is probably the most widely known but often misunderstood concepts that OOP brings to the table. The basic concept is that of data hiding. Each discrete object in your program has data inside of it, that it hides from the rest of the program. If we consider the example above, each car would have certain properties (like speed, gas mileage, etc.). These properties would only be changed or acted with by the car. The rest of the program cannot (and should not) have access to any of these properties. For example, the driver tells the car to start, but the car is the one that sends the signals to the tires to move. The driver doesn’t (and can’t) interact with each individual wheel.

Encapsulation is often widely misused though. I see misuse in many forms, but the most common are as follows. The programmer may completely forgo encapsulation (For example, he makes all data members public). The programmer also may take it too far (he makes every single data member private, even those that conceptual shouldn’t be). I also see many people doing a very curious thing. They make all (or most) of the classes data members private, but create mutators and accessors for all of them, essentially making them public, but writing a lot more code to do so. For example

class A {
private $some_int;
private $some_string;

public function get_some_int(){ return $this->some_int; }

public function set_some_int($i){ $this->some_int = $i; }

public function get_some_string(){ return $this->some_string; }

public function set_some_string($s){ $this-> some_string = $s; }

}

Now, trying to explain how to correctly use encapsulation is almost impossible, since it can be applied in so many ways. However, I often try to tell my students the following, which has mixed, but predominantly positives results: When deciding what data members to make public, which to make private, and which to make accessors or mutators for, consider the following. If we consider a data member, say int x, how is it going to be used? Is it only ever going to be accessed and modified inside the class. If so make it private. If it will be accessed outside of the class, but you only want to be able to change it inside, then make it a private variable with an accessor (like GetX()). If you are going to be accessing and changing it outside of the class without any restrictions (IE a programmer using this class can set the value of x to any reasonable value) Then make it public. If you want to make it so that the data member can be set and retrieved outside the class, but setting the variable has restrictions (Like x cannot be over 10 or below 0) then make the variable private, and use an accessor and mutator.

Lets take an example. Lets say we are creating a Person class. The name of the person would obviously be private (since no one can change someone’s name but the person) but with an accessor (people can still ask for their name). The amount of cash someone has would again be private, but would have an accessor (someone can ask how much money they have) and a restricted mutator (someone can’t just set the amount of money they have, but a store keeper can ask for a certain amount, or give a certain amount back as change.) The class could look something like:

class Person {
private $name;
private $cash;

public function getName(){ return $this->name; }

public function getCash(){ return $this->cash; }

public function giveChange($c){ $this->cash += $c; }//function to return change back to user

public function pay($price) { $this->cash -= $price; }//function to pay for something

}
<h3>Inheritance</h3>
Inheritance is one of the most commonly misused concepts I see. Sometimes even more than encapsulation (since its a bit easier to understand the implications of it in a conceptual sense, so its much easier to correct past mistakes). However, inheritance is slightly more complex than encapsulation. The basic concept is rather easy to understand. Inheritance in OOP models inheritance in real life fairly closely. You have a Base or Parent object, and you have a Derived or Child object that inherits from it. The child has all the properties that a parent has, and more.

The main problem I see many students and novice programmers trip up on is having children inherit from parents for no apparent reason. For example (and this is a real example) one of my students had a lab recitation to model a car (much like the example above, but much simpler). Cars were composed of Engines, and Wheels and had some basic attributes (like model name and number). This student decided to have the engines and wheels inherit from the car because they were part of the class, and he took this to mean that they had to inherit from cars. This shows two things. One, laziness, and two, a complete misunderstanding of the concept of inheritance.

When deciding on using inheritance, take the following into consideration:

Say we have a system where we have a few different classes. Lets say that these classes all have some sort of similarities. If they do, then I would take these similarities (generally in the form of the same attributes, or the same methods) , move them into a base class, and have my other classes derive from them. Inheritance can be used to avoid having to repeat code. However, inheritance is unnecessary or irrelevant if we have two classes that are quite different from each other, even if they seem to have some similarities. For example, if we are creating a GUI system, we may have a bunch of different shapes. Each shape would have some similar methods and attributes (Like the name of the shape, and a method for drawing the shape). Each shape should derive from some Base shape class. Another example would be a system where we have musicians and a music store. Each musician and each store would have a store of instruments (for example, a musician may have a guitar and drums, and a store may have a whole selection of guitars, basses, drums, etc.) Musicians and stores would also each have names, and other things. However, it really wouldn't make sense for either musicians to inherit from stores, or stores from musicians since each has unique data members that the other doesn't have.

Taking the shapes example, the code may look something like



class Shape { //base shape class
protected $name= "abstract shape";//protected so derived class can access of course

public function draw(){ ... }

}

class Triangle extends Shape {//triangle class that inherits from shape class

private $height;
private $base;

function _construct(){ $this->name = "triangle"; } //constructor to set name of this class to triangle

}

 

If you have any questions, comments or feedback, please let me know in the comments!

public function draw() { ... draw the triangle ... }

Everyone has heard of Facebook and used Facebook. It has become sort of a household name, and with the release of their API some time ago, other sites have been able to cash in on Facebook success by integrating parts of it into their site. Overall, the Facebook API is an incredible piece of software, offering developers ways to integrate the users social life with their website seamlessly, and it allows users to share account information and social information across multiple servers without having to remember a bunch of different login information. By the way, when I refer to the Facebook API, I am mostly talking about the PHP API and Javascript SDK.

However, where Facebook does many things right, it also does many things wrong. Now, I’m not saying that the Facebook API is bad or badly written or anything like that. In fact I haven’t really had a chance to examine to code for the API’s I use, so I’m not really in a place to make a claim either way. However, I do have some experience using it, and that experience has gone from awesome high’s where things finally worked and worked well, to horrible lows where the API would do everything but what I wanted it to do, seemingly of its own volition.

 

The problem, in my opinion, about the Facebook API as a whole is the lack of good documentation. Now when I say good, I don’t simply mean “Hey this function call exists. Its syntax is as so:…” but rather some documentation with more than 1 or 2 code examples, and some notes on certain caveats that come with the functionality. For example, take a look at this entry in the PHP.net manual. The parameter list is explained in great detail, notes are given about certain parts of its functionality that might not be apparent, and overall someone reading this would know most of the information on how to use the function. Compare this to almost any entry in the Facebook API documentation and you may see what i’m saying. If you browse through their documentation, on many pages you will find loads of comments with “Hey! I’m having this problem”, “hey me too”, “Hey me three”, etc. with absolutely no comment from the Facebook developers at all. Problems that should be rather simple become a huge headache because, in the end, you simply don’t know what the problem is, and the documentation provides no help.

For example, I was working on implementing a request dialog for a website, and used a simple one line piece of code from the documentation itself. I got absolutely no response when I tried to run this line. Upon viewing the documentation, it makes no mention of whether or not certain permissions are required (This is stated on another page as I came to find out) or if some kind of prerequisite function call was needed before trying to use this API call. This kind of back and forth is common to debugging Facebook API problems simply because there aren’t many places to ask about. Of course there are the developer forums, but half the time you see a topic relevant to your problem discussed, its the same “Hey! I’m having this problem”, “hey me too”, “Hey me three”, etc.

Now the documentation isn’t the only problem with the Facebook API. I’ve had instances where the API seemingly decides to work and not work depending on its mood, and random nondescript error messages happening sometimes, but not other times (and if you read the comments in the documentation, and in the forums, this isn’t an uncommon problem) Hell, I tried using the latest version of the PHP API once (this was a few weeks ago, I am not sure what the status of the latest version is now) and it straight up refused to work, and I had to re-download and re-upload an earlier version. It’s this kind of lack of communication and documentation from Facebook that can make working with the Facebook APIs a huge headache.

 

Now don’t get me wrong, the Facebook API is quite powerful, and an awesome addition to any site that has some sort of social functionality to it. However,  a word of advice for developers getting ready to implement some sort of Facebook connection with their site. If you plan on using the Facebook API, whether its immediately or down the line, plan for using it from the first step. Doing this can save the developer a lot of headache.