New Apps

Articles

Tips

Events

Improve Soft Skills

Improve Skills



  • If you are developing applications for Windows desktops, or for Windows servers (e.g. ASPdotNET), or for Windows phone, then C#.
  • If you are developing a PC game or writing an OS, then C or C++.
  • If you are writing server applications (e.g. web or mobile), or targeting Android phones, then Java.
  • If you are targeting iPhones/iPads, then ObjectiveC or Swift.
  • If you are building the browser side of an application, or if using node.js, then Javascript.
  • Since the comments I keep getting are pointing out how non-universal my original answer to this silly question was, I should point out that there are many other computer languages that are great for various uses. Python, PHP, Perl, Ruby, assembly, whatever.

Simply using the "best" language related to the domain still doesn't mean it's going to give you the "best" results in the "quickest" / "easiest" manner. Just that it's more possible than with others. It's still very much up to what the programmer knows and implements. None of them (any language ever invented - not just those you've listed) are anything close to a "magic-bullet".

Therefore "best" is not just an irrelevant term (especially if no specialization in domain is stated), it's also subjective and individual- / group dependent. I.e. before stating the "best", first state "what" you want to do as well as what you know and how well you can use it (unless you're willing / able to spend a lot of time trying to become an expert in something you don't know). Only then could you even attempt at rating a language's suitability.


Frankly speaking, every programming language is Best, if you can master it. For example, A person with sound knowledge over only C is a valuable key resource compared with a person having 'basic knowledge' on many languages.

The interesting thing is that, once you master a single language, conquering others will not be that tough!

So, suggestion for the beginners: Be the master of a modern language(whatever suits you) & after that try to gather basic knowledge of others, eventually if you have time, master those as well.



If you’re new to Java, or just looking to brush up on the details, then this is the article is for you!
As far as prerequisites go, we’re going to assume you understand how to program (perhaps in PHP, or Visual Basic or C++), but that you are unfamiliar with the specifics of programming in the Java language. We aren’t going to teach you to program; we’re going to provide you with clear examples of commonly used Java language constructs and principles, while pointing out some Android-specific tips and tricks.
Technically, you don’t need any tools to complete this article you will certainly need them to develop Android applications.
To develop Android applications (or any Java applications, for that matter), you need a development environment to write and build applications. Eclipse is a very popular development environment (IDE) for Java and the preferred IDE for Android development. It’s freely available for Windows, Mac, and Linux operating systems.
For complete instructions on how to install Eclipse (including which versions are supported) and the Android SDK, see the Android developer website.
Android applications are developed using the Java language. As of now, that’s really your only option for native applications. Java is a very popular programming language developed by Sun Microsystems (now owned by Oracle). Developed long after C and C++, Java incorporates many of the powerful features of those powerful languages while addressing some of their drawbacks. Still, programming languages are only as powerful as their libraries. These libraries exist to help developers build applications.
Some of the Java’s important core features are:
  • It’s easy to learn and understand
  • It’s designed to be platform-independent and secure, using
    virtual machines
  • It’s object-oriented
Android relies heavily on these Java fundamentals. The Android SDK includes many standard Java libraries (data structure libraries, math libraries, graphics libraries, networking libraries and everything else you could want) as well as special Android libraries that will help you develop awesome Android applications.
Java is easy to learn for a variety of reasons. There’s certainly no shortage of Java resources out there to help you learn the language, including websites, tutorials, books, and classes. Java is one of the most widely discussed, taught, and used programming languages on the planet. It’s used for many different types of programming projects, no matter their scale, from web applications to desktop applications to mobile applications.
If you’re coming from a traditional programming background like C or C++, you’ll find Java syntax quite similar. If you’re not, then take comfort in knowing that you’ve chosen one of the easiest languages to learn. You’ll be up and running in no time at all.
Finally, Java is one of the most human-readable languages out there, by which we mean that a person who knows nothing about programming can often look at some Java code and have at least an inkling what it’s doing. Consider the following example:
If you simply read the code aloud, you can pretty much tell that this snippet of code is doing. There’s a single letter variable called character. If the character variable equals the letter a, then we do something (call the doSomething() method), otherwise we do something else (by calling the doSomethingElse() method).
With many programming languages, you need to use a compiler to reduce your code down into machine language that the device can understand. While this is well and good, different devices use different machine languages. This means that you might need to compile your applications for each different device or machine language—in other words, your code isn’t very portable. This is not the case with Java. The Java compilers convert your code from human readable Java source files to something called “bytecode” in the Java world. These are interpreted by a Java Virtual Machine, which operates much like a physical CPU might operate on machine code, to actually execute the compiled code. Although it might seem like this is inefficient, much effort has been put into making this process very fast and efficient. These efforts have paid off in that Java performance in generally second only to C/C++ in common language performance comparisons.
Android applications run in a special virtual machine called the Dalvik VM. While the details of this VM are unimportant to the average developer, it can be helpful to think of the Dalvik VM as a bubble in which your Android application runs, allowing you to not have to worry about whether the device is a Motorola Droid, an HTC Evo, or the latest toaster running Android. You don’t care so long as the device is Dalvik VM friendly—and that’s the device manufacturer’s job to implement, not yours.
Let’s take this bubble idea a bit further. Because Java applications run within the bubble that is a virtual machine, they are isolated from the underlying device hardware. Therefore, a virtual machine can encapsulate, contain, and manage code execution in a safe manner compared to languages that operate in machine code directly. The Android platform takes things a step further. Each Android application runs on the (Linux-based) operating system using a different user account and in its own instance of the Dalvik VM. Android applications are closely monitored by the operating system and shut down if they don’t play nice (e.g. use too much processing power, become unresponsive, waste resources, etc.). Therefore, it’s important to develop applications that are stable and responsive. Applications can communicate with one another using well-defined protocols.
Like many languages, Java is still a compiled language even though it doesn’t compile all the way down to machine code. This means you, the developer, need to compile your Android projects and package them up to deploy onto devices. The Eclipse development environment (used with the Android Development plug-in) makes this pretty painless. In Eclipse, automatic compilation is often turned on by default. This means that every time you save a project file, Eclipse recompiles the changes for your application package. You immediately see compile errors. Eclipse also interprets Java as you type, providing handy code coloring and formatting as well as showing many types of errors as you go. Often, you can click on the error and have Eclipse automatically fix a typo, or add an import statement, or provide a method stub for you, saving lots of typing.
You can still manually compile your code if you so desire. Within Eclipse, you’ll find the Build settings under the project menu. If you have “Build Automatically” turned on, you can still choose the “Clean…” option that will allow you to do full rebuild of all files. If “Build Automatically” is turned off, “Build All” and “Build Project” menu options are enabled. "Build All" means to build all of the projects in the workspace. You can have many projects in an Eclipse workspace.
The build process, for regular Java projects, results in a file with the extension of JAR – Java ARchive. Android applications take JAR files and package them for deployment on devices as Android PacKage files with an extension .apk. These formats not only include your compiled Java code, but also any other resources, such as strings, images, or sound files, that your application requires to run as well as the Application Manifest file, AndroidManifest.xml. The Android Manifest file is a file required by all Android applications, which you use to define configuration details about your app.
Okay. Time for a very brief and 20,000 foot view of object oriented programming (OOP). OOP is a programming style or technique that relies upon the definition of data structures called objects. For those new to OOP, an object can be thought of much like a custom data type. For example, you might have a Dog object, which represents the blueprint for a generic dog, with a name, breed, and gender. You could then create different instances of the Dog object to represent specific dogs. Each Dog object must be created by calling its constructor (a method that has the same name as the object itself, and may or may not have parameters for setting initial values). For example, the following Dog objects use a constructor with three parameters (name, breed, gender):
So where is this Dog object defined? Well, here we need to begin defining some of the fundamental building blocks of the Java programming language. A class provides a definition for an object. Therefore, there is a Dog class somewhere—either defined by you or in some library somewhere. Generally speaking, a class will be defined in its own file, with the filename matching the class name (e.g. Dog.java). There are exceptions to this rule, such as classes defined within other classes (when a class is declared within a class, it is generally defined for use within the parent class only as a helper class, and referred to as aninner class).
When you want to reference an object from within another class, you need to include an import statementin the top of your class file, much like you would use a #include statement in a compiled language like C.
A class typically describes the data and behavior of an object. The behavior is defined using classmethods. Method is the common term for a subroutine in an OOP language. Many common object classes are defined in shared class libraries like software development kits (SDKs), whereas others are defined by you, the developer, for your own purposes. Software is then built up by using and manipulating object instances in different ways.
Please realize this is a very generalized definition of OOP. There are entire books written on this subject. If you’d like to know more about OOP, here are a few resources you might want to check out:
Note: We use a lot of different terminology in this tutorial. There are multiple ways to refer to a given concept (e.g. superclass vs. parent class), which is confusing to those new to object oriented programming. Different developers use different terms, and so we have tried to mention synonyms where appropriate. Deciding which terms you will use is a personal choice.
Here is another important Java concept you’ll run into a lot: inheritance. Simply put, inheritance means that Java classes (and therefore objects) can be organized into hierarchies with lower, more specific, classes in the hierarchy inheriting behavior and traits from higher, more generic, classes.
This concept is best illustrated by example. Let’s pretend we are developing a Java application to simulate an aquarium. This aquarium has some fish in it. Therefore, we might define a class to represent a fish. This class, called Fish, could include some data fields (also called attributes, or class member variables) to describe a fish object: species, color and size; as well as some of its behavior in the form of methods (also called subroutines, or functions in procedural languages), like eat(), sleep(), and makeBabyFish().
A special type of method, called a constructor, is used to create and initialize an object; constructors are named the same as their class and may include parameters. The following Fish class has two constructors: one for creating a generic Fish object and another for constructing a specific Fish object with some initial data. You’ll also see that the Fish class has two eat() methods: one for eating something random, and another for eating another fish, which would be represented by another instance of the Fish class:
Classes can be organized into hierarchies, where a derived class (or subclass) includes all the features of its parent class (or superclass), but refines and adds to them to define a more specific object using the extends keyword. This is called inheritance.
For example, the Fish class might have two subclasses: FreshwaterFish and SaltwaterFish. These subclasses would have all the features of the Fish class, but could further customize the objects through new attributes and behaviors or modified behaviors from the parent class Fish. For example, the FreshwaterFish class might include information about the type of freshwater environment lived in (e.g. river, lake, pond, or puddle). Similarly, the SaltwaterFish class might customize the makeBabyFish() method such that the fish eats its mate after breeding (as defined in the super class) by using the override mechanism, like this:
In Java, you can organize object behaviors in what are called interfaces. While a class defines an object, an interface defines some behavior that can be applied to an object. For example, we could define a Swimmer interface that provides a set of methods that are common across all objects that can swim, whether they are fish, otters, or submergible androids. The Swimmer interface might specify four methods: startSwimming(), stopSwimming(), dive(), and surface().
A class like Fish could then implement the Swimmer interface (using the implements keyword) and provide implementations of the swimming behavior:
Class hierarchies, such as our fish classes, can then be organized into packages. A package is simply a set of classes and interfaces, bundled together. Developers use namespaces to uniquely name packages. For example, we could use com.mamlambo.aquarium or com.ourclient.project.subproject as our package name to keep track of our fish-related classes.
Wow! You’ve just embarked on a crash-course in Java for Android development. We’ve covered a pretty intense amount of material here

References :


Our universe exhibits many examples of entities that can change form: A butterfly morphs from larva to pupa to imago, its adult form. On Earth, the normal state of water is liquid, but water changes to a solid when frozen, and to a gas when heated to its boiling point. This ability to change form is known as polymorphism. Modeling polymorphism in a programming language lets you create a uniform interface to different kinds of operands, arguments, and objects. The result is code that is more concise and easier to maintain.

Java supports four kinds of polymorphism:


1. Coercion is an operation that serves multiple types through implicit-type conversion. For example, you divide an integer by another integer or a floating-point value by another floating-point value. If one operand is an integer and the other operand is a floating-point value, the compiler coerces (implicitly converts) the integer to a floating-point value to prevent a type error. (There is no division operation that supports an integer operand and a floating-point operand.) Another example is passing a subclass object reference to a method's superclass parameter. The compiler coerces the subclass type to the superclass type to restrict operations to those of the superclass.

2. Overloading refers to using the same operator symbol or method name in different contexts. For example, you might use + to perform integer addition, floating-point addition, or string concatenation, depending on the types of its operands. Also, multiple methods having the same name can appear in a class (through declaration and/or inheritance).

3. Parametric polymorphism stipulates that within a class declaration, a field name can associate with different types and a method name can associate with different parameter and return types. The field and method can then take on different types in each class instance (object). For example, a field might be of type Double (a member of Java's standard class library that wraps a double value) and a method might return a Double in one object, and the same field might be of type String and the same method might return a String in another object. Java supports parametric polymorphism via generics, which I'll discuss in a future article.

4. Subtype means that a type can serve as another type's subtype. When a subtype instance appears in a supertype context, executing a supertype operation on the subtype instance results in the subtype's version of that operation executing. For example, consider a fragment of code that draws arbitrary shapes. You can express this drawing code more concisely by introducing a Shape class with a draw() method; by introducing Circle, Rectangle, and other subclasses that override draw(); by introducing an array of type Shape whose elements store references to Shape subclass instances; and by calling Shape's draw() method on each instance. When you call draw(), it's the Circle's, Rectangle's or other Shape instance's draw() method that gets called. We say that there are many forms of Shape's draw() method.


Like many developers, I classify coercion and overloading as ad-hoc polymorphism, and parametric and subtype as universal polymorphism. While valuable techniques, I don't believe coercion and overloading are true polymorphism; they're more like type conversions and syntactic sugar.

In this article I'll focus on subtype polymorphism. You'll learn about upcasting and late binding, abstract classes (which cannot be instantiated), and abstract methods (which cannot be called). You'll also learn how to do downcasting and runtime-type identification in your Java programs, and you'll get a first look at covariant return types. I'll introduce parametric polymorphism in a future tutorial.


Upcasting and late binding


Subtype polymorphism relies on upcasting and late binding. Upcasting is a form of casting where you cast up the inheritance hierarchy from a subtype to a supertype. No cast operator is involved because the subtype is a specialization of the supertype. For example, Shape s = new Circle(); upcasts from Circle to Shape. This makes sense because a circle is a kind of shape.

After upcasting Circle to Shape, you cannot call Circle-specific methods, such as a getRadius() method that returns the circle's radius, because Circle-specific methods are not part of Shape's interface. Losing access to subtype features after narrowing a subclass to its superclass seems pointless, but is necessary for achieving subtype polymorphism.

Suppose that Shape declares a draw() method, its Circle subclass overrides this method, Shape s = new Circle(); has just executed, and the next line specifies s.draw();. Which draw() method is called: Shape's draw() method or Circle's draw() method? The compiler doesn't know which draw() method to call. All it can do is verify that a method exists in the superclass, and verify that the method call's arguments list and return type match the superclass's method declaration. However, the compiler also inserts an instruction into the compiled code that, at runtime, fetches and uses whatever reference is in s to call the correct draw() method. This task is known as late binding.

Late binding vs early binding

Late binding is used for calls to non-final instance methods. For all other method calls, the compiler knows which method to call. It inserts an instruction into the compiled code that calls the method associated with the variable's type and not its value. This technique is known as early binding.

Upcasting and late binding


I've created an application that demonstrates subtype polymorphism in terms of upcasting and late binding. This application consists of Shape, Circle, Rectangle, and Shapes classes, where each class is stored in its own source file. Listing 1 presents the first three classes.

Listing 1. Declaring a hierarchy of shapes


class Shape
{
   void draw()
   {
   }
}

class Circle extends Shape
{
   private int x, y, r;

   Circle(int x, int y, int r)
   {
      this.x = x;
      this.y = y;
      this.r = r;
   }

   // For brevity, I've omitted getX(), getY(), and getRadius() methods.

   @Override
   void draw()
   {
      System.out.println("Drawing circle (" + x + ", "+ y + ", " + r + ")");
   }
}

class Rectangle extends Shape
{
   private int x, y, w, h;

   Rectangle(int x, int y, int w, int h)
   {
      this.x = x;
      this.y = y;
      this.w = w;
      this.h = h;
   }

   // For brevity, I've omitted getX(), getY(), getWidth(), and getHeight()
   // methods.

   @Override
   void draw()
   {
      System.out.println("Drawing rectangle (" + x + ", "+ y + ", " + w + "," +
                         h + ")");
   }
}

Listing 2 presents the Shapes application class whose main() method drives the application.


Listing 2. Upcasting and late binding in subtype polymorphism


class Shapes
{
   public static void main(String[] args)
   {
      Shape[] shapes = { new Circle(10, 20, 30),
                         new Rectangle(20, 30, 40, 50) };
      for (int i = 0; i < shapes.length; i++)
         shapes[i].draw();
   }
}

The declaration of the shapes array demonstrates upcasting. The Circle and Rectangle references are stored in shapes[0] and shapes[1] and are upcast to type Shape. Each of shapes[0] and shapes[1] is regarded as a Shape instance: shapes[0] isn't regarded as a Circle; shapes[1] isn't regarded as a Rectangle.

Late binding is demonstrated by the shapes[i].draw(); expression. When i equals 0, the compiler-generated instruction causes Circle's draw() method to be called. When i equals 1, however, this instruction causes Rectangle's draw() method to be called. This is the essence of subtype polymorphism.

Assuming that all four source files (Shapes.java, Shape.java, Rectangle.java, and Circle.java) are located in the current directory, compile them via either of the following command lines:


javac *.java
javac Shapes.java
Run the resulting application:


java Shapes

You should observe the following output:


Drawing circle (10, 20, 30)

Drawing rectangle (20, 30, 40, 50)


Abstract classes and methods


When designing class hierarchies, you'll find that classes nearer the top of these hierarchies are more generic than classes that are lower down. For example, a Vehicle superclass is more generic than a Truck subclass. Similarly, a Shape superclass is more generic than a Circle or a Rectangle subclass.

It doesn't make sense to instantiate a generic class. After all, what would a Vehicle object describe? Similarly, what kind of shape is represented by a Shape object? Rather than code an empty draw() method in Shape, we can prevent this method from being called and this class from being instantiated by declaring both entities to be abstract.

Java provides the abstract reserved word to declare a class that cannot be instantiated. The compiler reports an error when you try to instantiate this class. abstract is also used to declare a method without a body. The draw() method doesn't need a body because it is unable to draw an abstract shape. Listing 3 demonstrates.


Listing 3. Abstracting the Shape class and its draw() method



abstract class Shape
{
   abstract void draw(); // semicolon is required
}

Abstract cautions

The compiler reports an error when you attempt to declare a class abstract and final. For example, the compiler complains about abstract final class Shape because an abstract class cannot be instantiated and a final class cannot be extended. The compiler also reports an error when you declare a method abstract but don't declare its class abstract. Removing abstract from the Shape class's header in Listing 3 would result in an error, for instance. This would be an error because a non-abstract (concrete) class cannot be instantiated when it contains an abstract method. Finally, when you extend an abstract class, the extending class must override all of the abstract methods, or else the extending class must itself be declared to be abstract; otherwise, the compiler will report an error.

Declaring fields, constructors, and non-abstract methods


An abstract class can declare fields, constructors, and non-abstract methods in addition to or instead of abstract methods. For example, an abstract Vehicle class might declare fields describing its make, model, and year. Also, it might declare a constructor to initialize these fields and concrete methods to return their values. Check out Listing 4.

Listing 4. Abstracting a vehicle


abstract class Vehicle
{
   private String make, model;
   private int year;

   Vehicle(String make, String model, int year)
   {
      this.make = make;
      this.model = model;
      this.year = year;
   }

   String getMake()
   {
      return make;
   }

   String getModel()
   {
      return model;
   }

   int getYear()
   {
      return year;
   }

   abstract void move();
}

You'll note that Vehicle declares an abstract move() method to describe the movement of a vehicle. For example, a car rolls down the road, a boat sails across the water, and a plane flies through the air. Vehicle's subclasses would override move() and provide an appropriate description. They would also inherit the methods and their constructors would call Vehicle's constructor.

Downcasting and RTTI


Moving up the class hierarchy, via upcasting, entails losing access to subtype features. For example, assigning a Circle object to Shape variable s means that you cannot use s to call Circle's getRadius() method. However, it's possible to once again access Circle's getRadius() method by performing an explicit cast operation like this one: Circle c = (Circle) s;.

This assignment is known as downcasting because you are casting down the inheritance hierarchy from a supertype to a subtype (from the Shape superclass to the Circle subclass). Although an upcast is always safe (the superclass's interface is a subset of the subclass's interface), a downcast isn't always safe. Listing 5 shows what kind of trouble could ensue if you use downcasting incorrectly.

Listing 5. The problem with downcasting


class Superclass
{
}

class Subclass extends Superclass
{
   void method()
   {
   }
}

public class BadDowncast
{
   public static void main(String[] args)
   {
      Superclass superclass = new Superclass();
      Subclass subclass = (Subclass) superclass;
      subclass.method();
   }
}

Listing 5 presents a class hierarchy consisting of Superclass and Subclass, which extends Superclass. 

Furthermore, Subclass declares method(). A third class named BadDowncast provides a main() method that instantiates Superclass. BadDowncast then tries to downcast this object to Subclass and assign the result to variable subclass.

In this case the compiler will not complain because downcasting from a superclass to a subclass in the same type hierarchy is legal. That said, if the assignment was allowed the application would crash when it tried to execute subclass.method();. 

In this case the JVM would be attempting to call a nonexistent method, because Superclass doesn't declare method(). Fortunately, the JVM verifies that a cast is legal before performing a cast operation. Detecting that Superclass doesn't declare method(), it would throw a ClassCastException object.

Compile Listing 5 as follows :


javac BadDowncast.java


References :


Remembering what the programming world was like in 1995 is no easy task. Object-oriented programming, for one, was an accepted but seldom practiced paradigm, with much of what passed as so-called object-oriented programs being little more than rebranded C code that used >> instead of printf and class instead of struct. The programs we wrote those days routinely dumped core due to pointer arithmetic errors or ran out of memory due to leaks. Source code could barely be ported between different versions of Unix. Running the same binary on different processors and operating systems was crazy talk.

Java changed all that. While platform-dependent, manually allocated, procedural C code will continue to be with us for the next 20 years at least, Java proved this was a choice, not a requirement. For the first time, we began writing real production code in a cross-platform, garbage-collected, object-oriented language; and we liked it ... millions of us. Languages that have come after Java, most notably C#, have had to clear the new higher bar for developer productivity that Java established.

1. A base Object class from which all classes descend? Smalltalk

2. Strong static type-checking at compile time? Ada

3. Multiple interface, single implementation inheritance? Objective-C

4. Inline documentation? CWeb

5. Cross-platform virtual machine and byte code with just-in-time compilation? Smalltalk again, especially Sun’s Self dialect.

6. Garbage collection? Lisp

7. Primitive types and control structures? C

8. Dual type system with non-object primitive types for performance? C++


Java did, however, pioneer new territory. Nothing like checked exceptions is present in any other language before or since. Java was also the first language to use Unicode in the native string type and the source code itself.

But Java’s core strength was that it was built to be a practical tool for getting work done. It popularized good ideas from earlier languages by repackaging them in a format that was familiar to the average C coder, though (unlike C++ and Objective-C) Java was not a strict superset of C. Indeed it was precisely this willingness to not only add but also remove features that made Java so much simpler and easier to learn than other object-oriented C descendants.

Java did not (and still does not) have structs, unions, typedefs, and header files. An object-oriented language not shackled by a requirement to run legacy code didn’t need them. Similarly Java wisely omitted ideas that had been tried and found wanting in other languages: multiple implementation inheritance, pointer arithmetic, and operator overloading most noticeably. This good taste at the beginning means that even 20 years later, Java is still relatively free of the “here be dragons” warnings that litter the style guides for its predecessors.

But the rest of the programming world has not stood still. Thousands of programming languages have risen since we first started programming Java, but most never achieved more than a minuscule fraction of collective attention before eventually disappearing. What sold us on Java were applets, small programs running inside of Web pages that could interact with the user and do more than display static text, pictures, and forms. Today, this doesn’t sound like much, but remember -- in 1995, JavaScript and the DOM didn’t exist, and an HTML form that talked to a server-side CGI script written in Perl was state of the art.


The irony is that applets never worked very well. They were completely isolated from the content on the page, unable to read or write HTML as JavaScript eventually could. Security constraints prevented applets from interacting with the local file system and third-party network servers. These restrictions made applets suitable for little more than simple games and animations. Even these trivial proofs of concept were hampered by the poor performance of early browser virtual machines. And by the time applets’ deficiencies were corrected, browsers and front-end developers had long since passed Java by. Flash, JavaScript, and most recently HTML5 caught our eyes as far more effective platforms for delivering the dynamic Web content Java had promised us but failed to deliver.

Still, applets were what inspired us to work with Java, and what we discovered was a clean language that smoothed out many of the rough edges and pain points we’d been struggling with in alternatives such as C++. Automatic garbage collection alone was worth the price of admission. Applets may have been overhyped and underdelivered, but that didn’t mean Java wasn’t a damn good language for other problems.

Originally intended as a cross-platform client library, Java found real success in the server space. Servlets, Java Server Pages, and an array of enterprise-focused libraries that were periodically bundled together and rebranded in one confusing acronym or another solved real problems for us and for business. Marketing failures aside, Java achieved near-standard status in IT departments around the world. (Quick: What’s the difference between Java 2 Enterprise Edition and Java Platform Enterprise Edition? If you guessed that J2EE is the successor of JEE, you got it exactly backward.) Some of these enterprise-focused products were on the heavyweight side and inspired open source alternatives and supplements such as Spring, Hibernate, and Tomcat, but these all built on top of the foundation Sun set.

Arguably the single most important contribution of open source to Java and the wider craft of programming is JUnit. Test-driven development (TDD) had been tried earlier with Smalltalk. However, like many other innovations of that language, TDD did not achieve widespread notice and adoption until it became available in Java. When Kent Beck and Erich Gamma released JUnit in 2000, TDD rapidly ascended from an experimental practice of a few programmers to the standard way to develop software in the 21st century. As Martin Fowler has said, "Never in the field of software development was so much owed by so many to so few lines of code," and those few lines of code were written in Java.

Twenty years since its inception, Java is no longer the scrappy upstart. It has become the entrenched incumbent other languages rebel against. Lighter-weight languages like Ruby and Python have made significant inroads into Java’s territory, especially in the startup community where speed of development counts for more than robustness and scale -- a trade-off that Java itself took advantage of in the early days when performance of virtual machines severely lagged compiled code.

Java, of course, is not standing still. Oracle continues to incorporate well-proven technologies from other languages such as generics, autoboxing, enumerations, and, most recently, lambda expressions. Many programmers first encountered these ideas in Java. Not every programmer knows Java, but whether they know it or not, every programmer today has been influenced by it.



References :



If hitting a target is hard and hitting a moving target is even harder, then creating a new hit technology is next to impossible because the shape and nature of the target morphs as it moves. Think of building a swish new laptop just as laptops are heading out of favor, or a must-have mobile app just as smartphones plateau, or a dynamite tablet experience just as the wearable future takes hold.

It's no secret that technology trends move fast -- and the tools and means for building those technologies constantly evolve. But if you don't lift your head up every once in a while to look past the next year's projects, you could end up coding yourself down an inescapable rabbit hole.

To help you prepare for -- or at least start contemplating -- a future that's screaming across the sky faster than we can see, we've compiled a dozen predictions about how the next five years of programming will shake out. Our crystal ball is very subjective, and some of the following conjectures might not prove universal. Some won't be fully realized in five years. Others are already true, but the extent of their truth is not as well-established or widely known as it will be fairly soon. Some may surface as half-truths because some faction of coders may take a different path. Some might even be flat-out wrong.

Despite all of those caveats, there's truth here in the main. Read them quickly because the future is changing faster than we know.



Future of programming prediction No. 1: GPUs will be the next CPUs


Remember the days when people bragged about the CPU in their box? Now even the best CPUs rarely cost more than $200, while fancy graphics cards routinely cost $500, $600, or much more. Gamers love to brag about the power of their graphics cards, not their CPUs, and that's driving the market.

The rest of the world is slowly catching on. More and more software uses the GPUs. True, some of these early forays are inherently graphical processes, like the work of Web browsers, but increasingly we're seeing applications that have nothing to do with drawing fancy pictures being rewritten to use the parallel architecture of GPUs. Physicists use them to study matter; chemists use them to study reactions; astronomers simulate the galaxy with graphics cards; biologists crunch statistics via GPUs for population studies. And for a while this year, I heated my office by using my GPU to mine bitcoins.

Practices like these will only become more widespread. Soon better compilers will make it possible to write code and let the compiler detect when it can run effectively on the GPU. The academic tools can already do this at a limited level, but it will become more popular when it is easier for everyone to do so with any project.

Bank your bitcoins on this one coming true.



Future of programming prediction No. 2: Databases will perform increasingly sophisticated analysis


Once programmers ceded control of data to something called a "database," they stopped being "programmers" and started being "database users." This isn't a bad thing. After all, databases are engineered to be more efficient at handling data than anything a normal human programmer can create, especially under tight deadline. They're also (usually) very efficient at using RAM and juggling the memory hierarchy. Dumping numbers into a database and letting the database do its thing is more often than not the most intelligent solution to dealing with data, and it's going to get even more intelligent as the databases themselves get more intelligent with time.

That's because databases of the future are certain to do more than just store numbers. Many database systems already have sophisticated report engines (aka "business intelligence"), and these extras will only become more powerful, enabling databases to run more sophisticated algorithms on tables, search more efficiently for patterns in the data, and do much of the work currently touted by the buzzword "big data."

This power and sophistication will be driven by the cost of moving data around. Simply extracting the information from the database and handing it to a separate "big data" package will become increasingly time consuming and require much more programming. Leaving the data in the database and letting its engine perform the analysis will be much faster because it will limit the overhead of communication, as well as decrease the amount of programming necessary to extract value from the data store.



Future of programming prediction No. 3: JavaScript for everything


No, JavaScript won't be the only language in the programming world, especially given the surprising number of ads for Cobol programmers still being filed, but it will certainly begin to seem that way. JavaScript is inescapable on the browser, which now dominates almost everything a client computer does. Now the server side is embracing it with tools like Node.js.

JavaScript will assuredly become more dominant in other areas as well. Once the only way into a smartphone was to write code in the native language demanded by the manufacturer: Objective-C for the iPhone; Java for Android; C# for Microsoft. Now most mobile developers can get the performance they want out of HTML5 applications running in browser like views. The result may not be as zippy as native code, but the JavaScript is good enough and portable to the Web, too.

The browser isn't just colonizing phones; it's eating entire platforms. Chrome OS and Chromebooks are making regular operating systems obsolete. Why worry about that layer when JavaScript and the browser can do everything?

The mainframe will have Cobol. Biologists will probably stick with Python. Linux will be written in C. But almost everything else is fair game as JavaScript gobbles the world.




Future of programming prediction No. 4: Android on every device


When the browser doesn't win, Android is close behind. Camera designers, threatened by cellphones with good lenses, started putting Android on cameras, so now you can run Instagram on a Nikon. Does that make Nikon a computer company now? Does it even matter?

There are Android refrigerators, car stereos, watches, televisions, even headphones. Some complain that the UI is too complicated because it can do too much, but that's missing the point. The UI layer can always be simplified. If Android is running underneath, the platform will dominate.

It's going to get even more complicated. PC manufacturers are looking at the burgeoning tablet world and feeling left out. Their solution is to run Android on Windows and let people use their Android apps on their desktops, too. Some just run the stock Android emulators used by programmers, but others are looking beyond that to create brands like "PC Plus." Once Android takes over the PC, it may combine with the browser to push Windows native apps into a distant third place for mind share on the box.



Future of programming prediction No. 6: Open source will find new ways to squeeze us


For all of the success of open source stacks like Android, Ubuntu, or MySQL, there remains a sticky problem with finding the revenue to support development. There are plenty of good stories about how open source code has helped hackers, but there aren't very many examples of how companies built a relatively stable ecology that let the programmers buy health care or food.


The vast majority of open source companies distribute what might better be called a demonstration version under an open source license. Then some kind of secret sauce is kept locked away to give the programmers something to bargain with. It's the way of the world. Why buy the cow if you can get the milk for free? The best open source projects will find a way to tighten the screws in a comfortable way without scaring away customers.


References :




If you’ve decided to become a full stack web developer you’ve made a wise choice! Knowing both back-end and front-end technologies can give you a leg up in the tech industry and perhaps even land you land you a six-figure salary.

We often get questions from prospective students about what technologies to focus on. Now, before you make the jump into full stack web development, it’s valuable to have some understanding of the common programming languages and technology stacks, so that you can make an informed decision about how to build your base.

If you’re just beginning your path to a career in web development, here are recommendations for the best programming languages and technologies to learn right out of the gate.


Web Fundamentals: HTML, CSS, JavaScript


HTML and CSS (along with JavaScript) are the universal languages of front-end browsers, so it goes without saying that you should nail web development basics like HTML and CSS before diving into more difficult back-end technologies. A basic understanding of JavaScript should prove very useful as well.

Luckily, there are plenty of free web development resources and intro to code courses out there to help you get your feet wet in web development and general programming techniques.

As they begin writing code in JavaScript, novice programmers should also spend time getting familiar with algorithms and data structures at a basic level, since becoming familiar with these helps you break problems down into pieces that are more easily solved, across all technologies and languages. This is a real passion of mine, so be on the lookout for another blog post soon, dedicated to this topic.



Python


Python is an excellent introductory programming language for full-stack developers.

Although it is most popular as a back-end language, it is generally useful in other scenarios. As a general purpose programming language, you can use it to create almost any type of program or software.

Python code is inherently readable, because of an easy-to-learn syntax and an emphasis on good programming style and naming. As an instructor, I appreciate that it even enforces good indentation, which requires programmers to stay very clear on how they organize their loops, conditions and other program logic.

While it’s design is simple, Python is nonetheless incredibly flexible and powerful, which is why a whopping 80 percent of top computer science programs teach Python as an introductory language.



MEAN


MEAN is emerging as one of the industry’s most popular web technology stacks due to its powerful combination of JavaScript-based technologies:


  • MongoDB for the database
  • Express.js for the web framework
  • AngularJS for the frontend framework
  • Node.js for the server platform
  • A few years ago MEAN was just beginning to gain popularity. Now it’s in full swing usage by major tech companies such as Uber, Google, PayPal and Netflix.

So what makes MEAN so great?


MEAN has the promise of a single language, JavaScript, that all engineers can use, whether front-end or back-end. Node.js uses JavaScript as the server-side languages, rather than other scripting languages, which means  you can use MEAN to write the web application code, the database code and the client code.

Specifically, developers appreciate Node.js —and its mindboggling speed, which when paired with Socket.IO unlocks the possibility of some pretty cool interactive applications.

MongoDB is just one of many NoSQL databases available today that remove the restrictions of more structured databases. This allows you to save more data, and change the types of things that you save, much more flexibly.

Angular is a significant front-end framework that emphasizes real-time UI updates, in an single-page application model.

All told, MEAN has unrivaled support from industry leaders like Amazon, Microsoft and Google. Because it is open source, the savvy developer can tweak it to their preference.  



Ruby on Rails


Ruby on Rails is another full-stack framework, and is the technology stack of choice for Twitter, Basecamp and other notable sites.

Mastering Rails will greatly solidify your understanding of core web concepts, and is an extremely desirable skillset within the web development industry.

Rails is similar to – but more refined than – frameworks such as PHP’s CodeIgniter and MEAN’s Express. Rails has excellent built-in support for MVC and REST — with ActiveRecord — a superb relational database ORM.

Ruby (language) and Rails (framework) are stable and mature, with lots of online support. Plus, more so than with MEAN, the Rails subsystems work together seamlessly.

Ruby has a thriving third-party ecosystem of add-ins (gems). If Rails doesn’t do what you need, a gem likely fills the gap.

Additionally, Rails is well-known for enabling one to rapidly build web apps. If you are an entrepreneur or want to prototype your ideas quickly, Rails is the choice for you.



BONUS: Swift iOS


Knowing how to extend your product to the mobile interface is a handy and potentially lucrative tool to have as a full-stack developer.

But, as you might imagine, writing mobile applications is different than building web systems. Mobile devices are powerful rich clients, always with you and always connected. Services like audio/video, location, motion and power-management, and the requirement that it seamlessly pair with the same back-end system created for browsers, can make a mobile app more complex than a full-featured web system.

The compiled language, object-oriented OS and mobile device paradigm of Swift and iOS will make it easier for you to subsequently pick up Java/Android or C#/.NET.

The iOS developer ecosystem is controlled end-to-end by Apple, so documentation is generally accurate and mostly complete (although pieces are sometimes in the previous language, Objective-C).

It’s important to note that the Swift language is new and constantly changing. Apple continues to rapidly evolve both Swift and XCode (the accompanying development environment). As a result, the online support you may have experienced learning other technology stacks is largely absent – or worse, incorrect. Unless you are willing to spend time sorting through things on your own, you may find this frustrating.

However, undoubtedly iOS is very cutting-edge, challenging, and for those reasons, quite in-demand. With the Apple App Store and direct distribution, you can sell apps and extend your product to millions of people!



Learn Full-Stack Development


Rest assured, there’s not one single path to becoming a full stack web developer.


By learning one or more of these technologies you’ll have familiarity with each development layer, be up-to-speed on the most in-demand programming languages, and will be on your way to mastering full-stack development.







References :

Showing posts with label Improve Skills. Show all posts
Showing posts with label Improve Skills. Show all posts

Thursday, September 8, 2016

Currently, which one is best: C#, Java or C++?



  • If you are developing applications for Windows desktops, or for Windows servers (e.g. ASPdotNET), or for Windows phone, then C#.
  • If you are developing a PC game or writing an OS, then C or C++.
  • If you are writing server applications (e.g. web or mobile), or targeting Android phones, then Java.
  • If you are targeting iPhones/iPads, then ObjectiveC or Swift.
  • If you are building the browser side of an application, or if using node.js, then Javascript.
  • Since the comments I keep getting are pointing out how non-universal my original answer to this silly question was, I should point out that there are many other computer languages that are great for various uses. Python, PHP, Perl, Ruby, assembly, whatever.

Simply using the "best" language related to the domain still doesn't mean it's going to give you the "best" results in the "quickest" / "easiest" manner. Just that it's more possible than with others. It's still very much up to what the programmer knows and implements. None of them (any language ever invented - not just those you've listed) are anything close to a "magic-bullet".

Therefore "best" is not just an irrelevant term (especially if no specialization in domain is stated), it's also subjective and individual- / group dependent. I.e. before stating the "best", first state "what" you want to do as well as what you know and how well you can use it (unless you're willing / able to spend a lot of time trying to become an expert in something you don't know). Only then could you even attempt at rating a language's suitability.


Frankly speaking, every programming language is Best, if you can master it. For example, A person with sound knowledge over only C is a valuable key resource compared with a person having 'basic knowledge' on many languages.

The interesting thing is that, once you master a single language, conquering others will not be that tough!

So, suggestion for the beginners: Be the master of a modern language(whatever suits you) & after that try to gather basic knowledge of others, eventually if you have time, master those as well.

Friday, May 20, 2016

Learn Java for Android Development: Introduction to Java



If you’re new to Java, or just looking to brush up on the details, then this is the article is for you!
As far as prerequisites go, we’re going to assume you understand how to program (perhaps in PHP, or Visual Basic or C++), but that you are unfamiliar with the specifics of programming in the Java language. We aren’t going to teach you to program; we’re going to provide you with clear examples of commonly used Java language constructs and principles, while pointing out some Android-specific tips and tricks.
Technically, you don’t need any tools to complete this article you will certainly need them to develop Android applications.
To develop Android applications (or any Java applications, for that matter), you need a development environment to write and build applications. Eclipse is a very popular development environment (IDE) for Java and the preferred IDE for Android development. It’s freely available for Windows, Mac, and Linux operating systems.
For complete instructions on how to install Eclipse (including which versions are supported) and the Android SDK, see the Android developer website.
Android applications are developed using the Java language. As of now, that’s really your only option for native applications. Java is a very popular programming language developed by Sun Microsystems (now owned by Oracle). Developed long after C and C++, Java incorporates many of the powerful features of those powerful languages while addressing some of their drawbacks. Still, programming languages are only as powerful as their libraries. These libraries exist to help developers build applications.
Some of the Java’s important core features are:
  • It’s easy to learn and understand
  • It’s designed to be platform-independent and secure, using
    virtual machines
  • It’s object-oriented
Android relies heavily on these Java fundamentals. The Android SDK includes many standard Java libraries (data structure libraries, math libraries, graphics libraries, networking libraries and everything else you could want) as well as special Android libraries that will help you develop awesome Android applications.
Java is easy to learn for a variety of reasons. There’s certainly no shortage of Java resources out there to help you learn the language, including websites, tutorials, books, and classes. Java is one of the most widely discussed, taught, and used programming languages on the planet. It’s used for many different types of programming projects, no matter their scale, from web applications to desktop applications to mobile applications.
If you’re coming from a traditional programming background like C or C++, you’ll find Java syntax quite similar. If you’re not, then take comfort in knowing that you’ve chosen one of the easiest languages to learn. You’ll be up and running in no time at all.
Finally, Java is one of the most human-readable languages out there, by which we mean that a person who knows nothing about programming can often look at some Java code and have at least an inkling what it’s doing. Consider the following example:
If you simply read the code aloud, you can pretty much tell that this snippet of code is doing. There’s a single letter variable called character. If the character variable equals the letter a, then we do something (call the doSomething() method), otherwise we do something else (by calling the doSomethingElse() method).
With many programming languages, you need to use a compiler to reduce your code down into machine language that the device can understand. While this is well and good, different devices use different machine languages. This means that you might need to compile your applications for each different device or machine language—in other words, your code isn’t very portable. This is not the case with Java. The Java compilers convert your code from human readable Java source files to something called “bytecode” in the Java world. These are interpreted by a Java Virtual Machine, which operates much like a physical CPU might operate on machine code, to actually execute the compiled code. Although it might seem like this is inefficient, much effort has been put into making this process very fast and efficient. These efforts have paid off in that Java performance in generally second only to C/C++ in common language performance comparisons.
Android applications run in a special virtual machine called the Dalvik VM. While the details of this VM are unimportant to the average developer, it can be helpful to think of the Dalvik VM as a bubble in which your Android application runs, allowing you to not have to worry about whether the device is a Motorola Droid, an HTC Evo, or the latest toaster running Android. You don’t care so long as the device is Dalvik VM friendly—and that’s the device manufacturer’s job to implement, not yours.
Let’s take this bubble idea a bit further. Because Java applications run within the bubble that is a virtual machine, they are isolated from the underlying device hardware. Therefore, a virtual machine can encapsulate, contain, and manage code execution in a safe manner compared to languages that operate in machine code directly. The Android platform takes things a step further. Each Android application runs on the (Linux-based) operating system using a different user account and in its own instance of the Dalvik VM. Android applications are closely monitored by the operating system and shut down if they don’t play nice (e.g. use too much processing power, become unresponsive, waste resources, etc.). Therefore, it’s important to develop applications that are stable and responsive. Applications can communicate with one another using well-defined protocols.
Like many languages, Java is still a compiled language even though it doesn’t compile all the way down to machine code. This means you, the developer, need to compile your Android projects and package them up to deploy onto devices. The Eclipse development environment (used with the Android Development plug-in) makes this pretty painless. In Eclipse, automatic compilation is often turned on by default. This means that every time you save a project file, Eclipse recompiles the changes for your application package. You immediately see compile errors. Eclipse also interprets Java as you type, providing handy code coloring and formatting as well as showing many types of errors as you go. Often, you can click on the error and have Eclipse automatically fix a typo, or add an import statement, or provide a method stub for you, saving lots of typing.
You can still manually compile your code if you so desire. Within Eclipse, you’ll find the Build settings under the project menu. If you have “Build Automatically” turned on, you can still choose the “Clean…” option that will allow you to do full rebuild of all files. If “Build Automatically” is turned off, “Build All” and “Build Project” menu options are enabled. "Build All" means to build all of the projects in the workspace. You can have many projects in an Eclipse workspace.
The build process, for regular Java projects, results in a file with the extension of JAR – Java ARchive. Android applications take JAR files and package them for deployment on devices as Android PacKage files with an extension .apk. These formats not only include your compiled Java code, but also any other resources, such as strings, images, or sound files, that your application requires to run as well as the Application Manifest file, AndroidManifest.xml. The Android Manifest file is a file required by all Android applications, which you use to define configuration details about your app.
Okay. Time for a very brief and 20,000 foot view of object oriented programming (OOP). OOP is a programming style or technique that relies upon the definition of data structures called objects. For those new to OOP, an object can be thought of much like a custom data type. For example, you might have a Dog object, which represents the blueprint for a generic dog, with a name, breed, and gender. You could then create different instances of the Dog object to represent specific dogs. Each Dog object must be created by calling its constructor (a method that has the same name as the object itself, and may or may not have parameters for setting initial values). For example, the following Dog objects use a constructor with three parameters (name, breed, gender):
So where is this Dog object defined? Well, here we need to begin defining some of the fundamental building blocks of the Java programming language. A class provides a definition for an object. Therefore, there is a Dog class somewhere—either defined by you or in some library somewhere. Generally speaking, a class will be defined in its own file, with the filename matching the class name (e.g. Dog.java). There are exceptions to this rule, such as classes defined within other classes (when a class is declared within a class, it is generally defined for use within the parent class only as a helper class, and referred to as aninner class).
When you want to reference an object from within another class, you need to include an import statementin the top of your class file, much like you would use a #include statement in a compiled language like C.
A class typically describes the data and behavior of an object. The behavior is defined using classmethods. Method is the common term for a subroutine in an OOP language. Many common object classes are defined in shared class libraries like software development kits (SDKs), whereas others are defined by you, the developer, for your own purposes. Software is then built up by using and manipulating object instances in different ways.
Please realize this is a very generalized definition of OOP. There are entire books written on this subject. If you’d like to know more about OOP, here are a few resources you might want to check out:
Note: We use a lot of different terminology in this tutorial. There are multiple ways to refer to a given concept (e.g. superclass vs. parent class), which is confusing to those new to object oriented programming. Different developers use different terms, and so we have tried to mention synonyms where appropriate. Deciding which terms you will use is a personal choice.
Here is another important Java concept you’ll run into a lot: inheritance. Simply put, inheritance means that Java classes (and therefore objects) can be organized into hierarchies with lower, more specific, classes in the hierarchy inheriting behavior and traits from higher, more generic, classes.
This concept is best illustrated by example. Let’s pretend we are developing a Java application to simulate an aquarium. This aquarium has some fish in it. Therefore, we might define a class to represent a fish. This class, called Fish, could include some data fields (also called attributes, or class member variables) to describe a fish object: species, color and size; as well as some of its behavior in the form of methods (also called subroutines, or functions in procedural languages), like eat(), sleep(), and makeBabyFish().
A special type of method, called a constructor, is used to create and initialize an object; constructors are named the same as their class and may include parameters. The following Fish class has two constructors: one for creating a generic Fish object and another for constructing a specific Fish object with some initial data. You’ll also see that the Fish class has two eat() methods: one for eating something random, and another for eating another fish, which would be represented by another instance of the Fish class:
Classes can be organized into hierarchies, where a derived class (or subclass) includes all the features of its parent class (or superclass), but refines and adds to them to define a more specific object using the extends keyword. This is called inheritance.
For example, the Fish class might have two subclasses: FreshwaterFish and SaltwaterFish. These subclasses would have all the features of the Fish class, but could further customize the objects through new attributes and behaviors or modified behaviors from the parent class Fish. For example, the FreshwaterFish class might include information about the type of freshwater environment lived in (e.g. river, lake, pond, or puddle). Similarly, the SaltwaterFish class might customize the makeBabyFish() method such that the fish eats its mate after breeding (as defined in the super class) by using the override mechanism, like this:
In Java, you can organize object behaviors in what are called interfaces. While a class defines an object, an interface defines some behavior that can be applied to an object. For example, we could define a Swimmer interface that provides a set of methods that are common across all objects that can swim, whether they are fish, otters, or submergible androids. The Swimmer interface might specify four methods: startSwimming(), stopSwimming(), dive(), and surface().
A class like Fish could then implement the Swimmer interface (using the implements keyword) and provide implementations of the swimming behavior:
Class hierarchies, such as our fish classes, can then be organized into packages. A package is simply a set of classes and interfaces, bundled together. Developers use namespaces to uniquely name packages. For example, we could use com.mamlambo.aquarium or com.ourclient.project.subproject as our package name to keep track of our fish-related classes.
Wow! You’ve just embarked on a crash-course in Java for Android development. We’ve covered a pretty intense amount of material here

References :

Saturday, May 14, 2016

Java 101: Polymorphism in Java


Our universe exhibits many examples of entities that can change form: A butterfly morphs from larva to pupa to imago, its adult form. On Earth, the normal state of water is liquid, but water changes to a solid when frozen, and to a gas when heated to its boiling point. This ability to change form is known as polymorphism. Modeling polymorphism in a programming language lets you create a uniform interface to different kinds of operands, arguments, and objects. The result is code that is more concise and easier to maintain.

Java supports four kinds of polymorphism:


1. Coercion is an operation that serves multiple types through implicit-type conversion. For example, you divide an integer by another integer or a floating-point value by another floating-point value. If one operand is an integer and the other operand is a floating-point value, the compiler coerces (implicitly converts) the integer to a floating-point value to prevent a type error. (There is no division operation that supports an integer operand and a floating-point operand.) Another example is passing a subclass object reference to a method's superclass parameter. The compiler coerces the subclass type to the superclass type to restrict operations to those of the superclass.

2. Overloading refers to using the same operator symbol or method name in different contexts. For example, you might use + to perform integer addition, floating-point addition, or string concatenation, depending on the types of its operands. Also, multiple methods having the same name can appear in a class (through declaration and/or inheritance).

3. Parametric polymorphism stipulates that within a class declaration, a field name can associate with different types and a method name can associate with different parameter and return types. The field and method can then take on different types in each class instance (object). For example, a field might be of type Double (a member of Java's standard class library that wraps a double value) and a method might return a Double in one object, and the same field might be of type String and the same method might return a String in another object. Java supports parametric polymorphism via generics, which I'll discuss in a future article.

4. Subtype means that a type can serve as another type's subtype. When a subtype instance appears in a supertype context, executing a supertype operation on the subtype instance results in the subtype's version of that operation executing. For example, consider a fragment of code that draws arbitrary shapes. You can express this drawing code more concisely by introducing a Shape class with a draw() method; by introducing Circle, Rectangle, and other subclasses that override draw(); by introducing an array of type Shape whose elements store references to Shape subclass instances; and by calling Shape's draw() method on each instance. When you call draw(), it's the Circle's, Rectangle's or other Shape instance's draw() method that gets called. We say that there are many forms of Shape's draw() method.


Like many developers, I classify coercion and overloading as ad-hoc polymorphism, and parametric and subtype as universal polymorphism. While valuable techniques, I don't believe coercion and overloading are true polymorphism; they're more like type conversions and syntactic sugar.

In this article I'll focus on subtype polymorphism. You'll learn about upcasting and late binding, abstract classes (which cannot be instantiated), and abstract methods (which cannot be called). You'll also learn how to do downcasting and runtime-type identification in your Java programs, and you'll get a first look at covariant return types. I'll introduce parametric polymorphism in a future tutorial.


Upcasting and late binding


Subtype polymorphism relies on upcasting and late binding. Upcasting is a form of casting where you cast up the inheritance hierarchy from a subtype to a supertype. No cast operator is involved because the subtype is a specialization of the supertype. For example, Shape s = new Circle(); upcasts from Circle to Shape. This makes sense because a circle is a kind of shape.

After upcasting Circle to Shape, you cannot call Circle-specific methods, such as a getRadius() method that returns the circle's radius, because Circle-specific methods are not part of Shape's interface. Losing access to subtype features after narrowing a subclass to its superclass seems pointless, but is necessary for achieving subtype polymorphism.

Suppose that Shape declares a draw() method, its Circle subclass overrides this method, Shape s = new Circle(); has just executed, and the next line specifies s.draw();. Which draw() method is called: Shape's draw() method or Circle's draw() method? The compiler doesn't know which draw() method to call. All it can do is verify that a method exists in the superclass, and verify that the method call's arguments list and return type match the superclass's method declaration. However, the compiler also inserts an instruction into the compiled code that, at runtime, fetches and uses whatever reference is in s to call the correct draw() method. This task is known as late binding.

Late binding vs early binding

Late binding is used for calls to non-final instance methods. For all other method calls, the compiler knows which method to call. It inserts an instruction into the compiled code that calls the method associated with the variable's type and not its value. This technique is known as early binding.

Upcasting and late binding


I've created an application that demonstrates subtype polymorphism in terms of upcasting and late binding. This application consists of Shape, Circle, Rectangle, and Shapes classes, where each class is stored in its own source file. Listing 1 presents the first three classes.

Listing 1. Declaring a hierarchy of shapes


class Shape
{
   void draw()
   {
   }
}

class Circle extends Shape
{
   private int x, y, r;

   Circle(int x, int y, int r)
   {
      this.x = x;
      this.y = y;
      this.r = r;
   }

   // For brevity, I've omitted getX(), getY(), and getRadius() methods.

   @Override
   void draw()
   {
      System.out.println("Drawing circle (" + x + ", "+ y + ", " + r + ")");
   }
}

class Rectangle extends Shape
{
   private int x, y, w, h;

   Rectangle(int x, int y, int w, int h)
   {
      this.x = x;
      this.y = y;
      this.w = w;
      this.h = h;
   }

   // For brevity, I've omitted getX(), getY(), getWidth(), and getHeight()
   // methods.

   @Override
   void draw()
   {
      System.out.println("Drawing rectangle (" + x + ", "+ y + ", " + w + "," +
                         h + ")");
   }
}

Listing 2 presents the Shapes application class whose main() method drives the application.


Listing 2. Upcasting and late binding in subtype polymorphism


class Shapes
{
   public static void main(String[] args)
   {
      Shape[] shapes = { new Circle(10, 20, 30),
                         new Rectangle(20, 30, 40, 50) };
      for (int i = 0; i < shapes.length; i++)
         shapes[i].draw();
   }
}

The declaration of the shapes array demonstrates upcasting. The Circle and Rectangle references are stored in shapes[0] and shapes[1] and are upcast to type Shape. Each of shapes[0] and shapes[1] is regarded as a Shape instance: shapes[0] isn't regarded as a Circle; shapes[1] isn't regarded as a Rectangle.

Late binding is demonstrated by the shapes[i].draw(); expression. When i equals 0, the compiler-generated instruction causes Circle's draw() method to be called. When i equals 1, however, this instruction causes Rectangle's draw() method to be called. This is the essence of subtype polymorphism.

Assuming that all four source files (Shapes.java, Shape.java, Rectangle.java, and Circle.java) are located in the current directory, compile them via either of the following command lines:


javac *.java
javac Shapes.java
Run the resulting application:


java Shapes

You should observe the following output:


Drawing circle (10, 20, 30)

Drawing rectangle (20, 30, 40, 50)


Abstract classes and methods


When designing class hierarchies, you'll find that classes nearer the top of these hierarchies are more generic than classes that are lower down. For example, a Vehicle superclass is more generic than a Truck subclass. Similarly, a Shape superclass is more generic than a Circle or a Rectangle subclass.

It doesn't make sense to instantiate a generic class. After all, what would a Vehicle object describe? Similarly, what kind of shape is represented by a Shape object? Rather than code an empty draw() method in Shape, we can prevent this method from being called and this class from being instantiated by declaring both entities to be abstract.

Java provides the abstract reserved word to declare a class that cannot be instantiated. The compiler reports an error when you try to instantiate this class. abstract is also used to declare a method without a body. The draw() method doesn't need a body because it is unable to draw an abstract shape. Listing 3 demonstrates.


Listing 3. Abstracting the Shape class and its draw() method



abstract class Shape
{
   abstract void draw(); // semicolon is required
}

Abstract cautions

The compiler reports an error when you attempt to declare a class abstract and final. For example, the compiler complains about abstract final class Shape because an abstract class cannot be instantiated and a final class cannot be extended. The compiler also reports an error when you declare a method abstract but don't declare its class abstract. Removing abstract from the Shape class's header in Listing 3 would result in an error, for instance. This would be an error because a non-abstract (concrete) class cannot be instantiated when it contains an abstract method. Finally, when you extend an abstract class, the extending class must override all of the abstract methods, or else the extending class must itself be declared to be abstract; otherwise, the compiler will report an error.

Declaring fields, constructors, and non-abstract methods


An abstract class can declare fields, constructors, and non-abstract methods in addition to or instead of abstract methods. For example, an abstract Vehicle class might declare fields describing its make, model, and year. Also, it might declare a constructor to initialize these fields and concrete methods to return their values. Check out Listing 4.

Listing 4. Abstracting a vehicle


abstract class Vehicle
{
   private String make, model;
   private int year;

   Vehicle(String make, String model, int year)
   {
      this.make = make;
      this.model = model;
      this.year = year;
   }

   String getMake()
   {
      return make;
   }

   String getModel()
   {
      return model;
   }

   int getYear()
   {
      return year;
   }

   abstract void move();
}

You'll note that Vehicle declares an abstract move() method to describe the movement of a vehicle. For example, a car rolls down the road, a boat sails across the water, and a plane flies through the air. Vehicle's subclasses would override move() and provide an appropriate description. They would also inherit the methods and their constructors would call Vehicle's constructor.

Downcasting and RTTI


Moving up the class hierarchy, via upcasting, entails losing access to subtype features. For example, assigning a Circle object to Shape variable s means that you cannot use s to call Circle's getRadius() method. However, it's possible to once again access Circle's getRadius() method by performing an explicit cast operation like this one: Circle c = (Circle) s;.

This assignment is known as downcasting because you are casting down the inheritance hierarchy from a supertype to a subtype (from the Shape superclass to the Circle subclass). Although an upcast is always safe (the superclass's interface is a subset of the subclass's interface), a downcast isn't always safe. Listing 5 shows what kind of trouble could ensue if you use downcasting incorrectly.

Listing 5. The problem with downcasting


class Superclass
{
}

class Subclass extends Superclass
{
   void method()
   {
   }
}

public class BadDowncast
{
   public static void main(String[] args)
   {
      Superclass superclass = new Superclass();
      Subclass subclass = (Subclass) superclass;
      subclass.method();
   }
}

Listing 5 presents a class hierarchy consisting of Superclass and Subclass, which extends Superclass. 

Furthermore, Subclass declares method(). A third class named BadDowncast provides a main() method that instantiates Superclass. BadDowncast then tries to downcast this object to Subclass and assign the result to variable subclass.

In this case the compiler will not complain because downcasting from a superclass to a subclass in the same type hierarchy is legal. That said, if the assignment was allowed the application would crash when it tried to execute subclass.method();. 

In this case the JVM would be attempting to call a nonexistent method, because Superclass doesn't declare method(). Fortunately, the JVM verifies that a cast is legal before performing a cast operation. Detecting that Superclass doesn't declare method(), it would throw a ClassCastException object.

Compile Listing 5 as follows :


javac BadDowncast.java


References :

Java at 20: How it changed programming forever


Remembering what the programming world was like in 1995 is no easy task. Object-oriented programming, for one, was an accepted but seldom practiced paradigm, with much of what passed as so-called object-oriented programs being little more than rebranded C code that used >> instead of printf and class instead of struct. The programs we wrote those days routinely dumped core due to pointer arithmetic errors or ran out of memory due to leaks. Source code could barely be ported between different versions of Unix. Running the same binary on different processors and operating systems was crazy talk.

Java changed all that. While platform-dependent, manually allocated, procedural C code will continue to be with us for the next 20 years at least, Java proved this was a choice, not a requirement. For the first time, we began writing real production code in a cross-platform, garbage-collected, object-oriented language; and we liked it ... millions of us. Languages that have come after Java, most notably C#, have had to clear the new higher bar for developer productivity that Java established.

1. A base Object class from which all classes descend? Smalltalk

2. Strong static type-checking at compile time? Ada

3. Multiple interface, single implementation inheritance? Objective-C

4. Inline documentation? CWeb

5. Cross-platform virtual machine and byte code with just-in-time compilation? Smalltalk again, especially Sun’s Self dialect.

6. Garbage collection? Lisp

7. Primitive types and control structures? C

8. Dual type system with non-object primitive types for performance? C++


Java did, however, pioneer new territory. Nothing like checked exceptions is present in any other language before or since. Java was also the first language to use Unicode in the native string type and the source code itself.

But Java’s core strength was that it was built to be a practical tool for getting work done. It popularized good ideas from earlier languages by repackaging them in a format that was familiar to the average C coder, though (unlike C++ and Objective-C) Java was not a strict superset of C. Indeed it was precisely this willingness to not only add but also remove features that made Java so much simpler and easier to learn than other object-oriented C descendants.

Java did not (and still does not) have structs, unions, typedefs, and header files. An object-oriented language not shackled by a requirement to run legacy code didn’t need them. Similarly Java wisely omitted ideas that had been tried and found wanting in other languages: multiple implementation inheritance, pointer arithmetic, and operator overloading most noticeably. This good taste at the beginning means that even 20 years later, Java is still relatively free of the “here be dragons” warnings that litter the style guides for its predecessors.

But the rest of the programming world has not stood still. Thousands of programming languages have risen since we first started programming Java, but most never achieved more than a minuscule fraction of collective attention before eventually disappearing. What sold us on Java were applets, small programs running inside of Web pages that could interact with the user and do more than display static text, pictures, and forms. Today, this doesn’t sound like much, but remember -- in 1995, JavaScript and the DOM didn’t exist, and an HTML form that talked to a server-side CGI script written in Perl was state of the art.


The irony is that applets never worked very well. They were completely isolated from the content on the page, unable to read or write HTML as JavaScript eventually could. Security constraints prevented applets from interacting with the local file system and third-party network servers. These restrictions made applets suitable for little more than simple games and animations. Even these trivial proofs of concept were hampered by the poor performance of early browser virtual machines. And by the time applets’ deficiencies were corrected, browsers and front-end developers had long since passed Java by. Flash, JavaScript, and most recently HTML5 caught our eyes as far more effective platforms for delivering the dynamic Web content Java had promised us but failed to deliver.

Still, applets were what inspired us to work with Java, and what we discovered was a clean language that smoothed out many of the rough edges and pain points we’d been struggling with in alternatives such as C++. Automatic garbage collection alone was worth the price of admission. Applets may have been overhyped and underdelivered, but that didn’t mean Java wasn’t a damn good language for other problems.

Originally intended as a cross-platform client library, Java found real success in the server space. Servlets, Java Server Pages, and an array of enterprise-focused libraries that were periodically bundled together and rebranded in one confusing acronym or another solved real problems for us and for business. Marketing failures aside, Java achieved near-standard status in IT departments around the world. (Quick: What’s the difference between Java 2 Enterprise Edition and Java Platform Enterprise Edition? If you guessed that J2EE is the successor of JEE, you got it exactly backward.) Some of these enterprise-focused products were on the heavyweight side and inspired open source alternatives and supplements such as Spring, Hibernate, and Tomcat, but these all built on top of the foundation Sun set.

Arguably the single most important contribution of open source to Java and the wider craft of programming is JUnit. Test-driven development (TDD) had been tried earlier with Smalltalk. However, like many other innovations of that language, TDD did not achieve widespread notice and adoption until it became available in Java. When Kent Beck and Erich Gamma released JUnit in 2000, TDD rapidly ascended from an experimental practice of a few programmers to the standard way to develop software in the 21st century. As Martin Fowler has said, "Never in the field of software development was so much owed by so many to so few lines of code," and those few lines of code were written in Java.

Twenty years since its inception, Java is no longer the scrappy upstart. It has become the entrenched incumbent other languages rebel against. Lighter-weight languages like Ruby and Python have made significant inroads into Java’s territory, especially in the startup community where speed of development counts for more than robustness and scale -- a trade-off that Java itself took advantage of in the early days when performance of virtual machines severely lagged compiled code.

Java, of course, is not standing still. Oracle continues to incorporate well-proven technologies from other languages such as generics, autoboxing, enumerations, and, most recently, lambda expressions. Many programmers first encountered these ideas in Java. Not every programmer knows Java, but whether they know it or not, every programmer today has been influenced by it.



References :


6 predictions for the future of programming


If hitting a target is hard and hitting a moving target is even harder, then creating a new hit technology is next to impossible because the shape and nature of the target morphs as it moves. Think of building a swish new laptop just as laptops are heading out of favor, or a must-have mobile app just as smartphones plateau, or a dynamite tablet experience just as the wearable future takes hold.

It's no secret that technology trends move fast -- and the tools and means for building those technologies constantly evolve. But if you don't lift your head up every once in a while to look past the next year's projects, you could end up coding yourself down an inescapable rabbit hole.

To help you prepare for -- or at least start contemplating -- a future that's screaming across the sky faster than we can see, we've compiled a dozen predictions about how the next five years of programming will shake out. Our crystal ball is very subjective, and some of the following conjectures might not prove universal. Some won't be fully realized in five years. Others are already true, but the extent of their truth is not as well-established or widely known as it will be fairly soon. Some may surface as half-truths because some faction of coders may take a different path. Some might even be flat-out wrong.

Despite all of those caveats, there's truth here in the main. Read them quickly because the future is changing faster than we know.



Future of programming prediction No. 1: GPUs will be the next CPUs


Remember the days when people bragged about the CPU in their box? Now even the best CPUs rarely cost more than $200, while fancy graphics cards routinely cost $500, $600, or much more. Gamers love to brag about the power of their graphics cards, not their CPUs, and that's driving the market.

The rest of the world is slowly catching on. More and more software uses the GPUs. True, some of these early forays are inherently graphical processes, like the work of Web browsers, but increasingly we're seeing applications that have nothing to do with drawing fancy pictures being rewritten to use the parallel architecture of GPUs. Physicists use them to study matter; chemists use them to study reactions; astronomers simulate the galaxy with graphics cards; biologists crunch statistics via GPUs for population studies. And for a while this year, I heated my office by using my GPU to mine bitcoins.

Practices like these will only become more widespread. Soon better compilers will make it possible to write code and let the compiler detect when it can run effectively on the GPU. The academic tools can already do this at a limited level, but it will become more popular when it is easier for everyone to do so with any project.

Bank your bitcoins on this one coming true.



Future of programming prediction No. 2: Databases will perform increasingly sophisticated analysis


Once programmers ceded control of data to something called a "database," they stopped being "programmers" and started being "database users." This isn't a bad thing. After all, databases are engineered to be more efficient at handling data than anything a normal human programmer can create, especially under tight deadline. They're also (usually) very efficient at using RAM and juggling the memory hierarchy. Dumping numbers into a database and letting the database do its thing is more often than not the most intelligent solution to dealing with data, and it's going to get even more intelligent as the databases themselves get more intelligent with time.

That's because databases of the future are certain to do more than just store numbers. Many database systems already have sophisticated report engines (aka "business intelligence"), and these extras will only become more powerful, enabling databases to run more sophisticated algorithms on tables, search more efficiently for patterns in the data, and do much of the work currently touted by the buzzword "big data."

This power and sophistication will be driven by the cost of moving data around. Simply extracting the information from the database and handing it to a separate "big data" package will become increasingly time consuming and require much more programming. Leaving the data in the database and letting its engine perform the analysis will be much faster because it will limit the overhead of communication, as well as decrease the amount of programming necessary to extract value from the data store.



Future of programming prediction No. 3: JavaScript for everything


No, JavaScript won't be the only language in the programming world, especially given the surprising number of ads for Cobol programmers still being filed, but it will certainly begin to seem that way. JavaScript is inescapable on the browser, which now dominates almost everything a client computer does. Now the server side is embracing it with tools like Node.js.

JavaScript will assuredly become more dominant in other areas as well. Once the only way into a smartphone was to write code in the native language demanded by the manufacturer: Objective-C for the iPhone; Java for Android; C# for Microsoft. Now most mobile developers can get the performance they want out of HTML5 applications running in browser like views. The result may not be as zippy as native code, but the JavaScript is good enough and portable to the Web, too.

The browser isn't just colonizing phones; it's eating entire platforms. Chrome OS and Chromebooks are making regular operating systems obsolete. Why worry about that layer when JavaScript and the browser can do everything?

The mainframe will have Cobol. Biologists will probably stick with Python. Linux will be written in C. But almost everything else is fair game as JavaScript gobbles the world.




Future of programming prediction No. 4: Android on every device


When the browser doesn't win, Android is close behind. Camera designers, threatened by cellphones with good lenses, started putting Android on cameras, so now you can run Instagram on a Nikon. Does that make Nikon a computer company now? Does it even matter?

There are Android refrigerators, car stereos, watches, televisions, even headphones. Some complain that the UI is too complicated because it can do too much, but that's missing the point. The UI layer can always be simplified. If Android is running underneath, the platform will dominate.

It's going to get even more complicated. PC manufacturers are looking at the burgeoning tablet world and feeling left out. Their solution is to run Android on Windows and let people use their Android apps on their desktops, too. Some just run the stock Android emulators used by programmers, but others are looking beyond that to create brands like "PC Plus." Once Android takes over the PC, it may combine with the browser to push Windows native apps into a distant third place for mind share on the box.



Future of programming prediction No. 6: Open source will find new ways to squeeze us


For all of the success of open source stacks like Android, Ubuntu, or MySQL, there remains a sticky problem with finding the revenue to support development. There are plenty of good stories about how open source code has helped hackers, but there aren't very many examples of how companies built a relatively stable ecology that let the programmers buy health care or food.


The vast majority of open source companies distribute what might better be called a demonstration version under an open source license. Then some kind of secret sauce is kept locked away to give the programmers something to bargain with. It's the way of the world. Why buy the cow if you can get the milk for free? The best open source projects will find a way to tighten the screws in a comfortable way without scaring away customers.


References :

Sunday, May 1, 2016

Top Programming Languages for the Full Stack Web Developer




If you’ve decided to become a full stack web developer you’ve made a wise choice! Knowing both back-end and front-end technologies can give you a leg up in the tech industry and perhaps even land you land you a six-figure salary.

We often get questions from prospective students about what technologies to focus on. Now, before you make the jump into full stack web development, it’s valuable to have some understanding of the common programming languages and technology stacks, so that you can make an informed decision about how to build your base.

If you’re just beginning your path to a career in web development, here are recommendations for the best programming languages and technologies to learn right out of the gate.


Web Fundamentals: HTML, CSS, JavaScript


HTML and CSS (along with JavaScript) are the universal languages of front-end browsers, so it goes without saying that you should nail web development basics like HTML and CSS before diving into more difficult back-end technologies. A basic understanding of JavaScript should prove very useful as well.

Luckily, there are plenty of free web development resources and intro to code courses out there to help you get your feet wet in web development and general programming techniques.

As they begin writing code in JavaScript, novice programmers should also spend time getting familiar with algorithms and data structures at a basic level, since becoming familiar with these helps you break problems down into pieces that are more easily solved, across all technologies and languages. This is a real passion of mine, so be on the lookout for another blog post soon, dedicated to this topic.



Python


Python is an excellent introductory programming language for full-stack developers.

Although it is most popular as a back-end language, it is generally useful in other scenarios. As a general purpose programming language, you can use it to create almost any type of program or software.

Python code is inherently readable, because of an easy-to-learn syntax and an emphasis on good programming style and naming. As an instructor, I appreciate that it even enforces good indentation, which requires programmers to stay very clear on how they organize their loops, conditions and other program logic.

While it’s design is simple, Python is nonetheless incredibly flexible and powerful, which is why a whopping 80 percent of top computer science programs teach Python as an introductory language.



MEAN


MEAN is emerging as one of the industry’s most popular web technology stacks due to its powerful combination of JavaScript-based technologies:


  • MongoDB for the database
  • Express.js for the web framework
  • AngularJS for the frontend framework
  • Node.js for the server platform
  • A few years ago MEAN was just beginning to gain popularity. Now it’s in full swing usage by major tech companies such as Uber, Google, PayPal and Netflix.

So what makes MEAN so great?


MEAN has the promise of a single language, JavaScript, that all engineers can use, whether front-end or back-end. Node.js uses JavaScript as the server-side languages, rather than other scripting languages, which means  you can use MEAN to write the web application code, the database code and the client code.

Specifically, developers appreciate Node.js —and its mindboggling speed, which when paired with Socket.IO unlocks the possibility of some pretty cool interactive applications.

MongoDB is just one of many NoSQL databases available today that remove the restrictions of more structured databases. This allows you to save more data, and change the types of things that you save, much more flexibly.

Angular is a significant front-end framework that emphasizes real-time UI updates, in an single-page application model.

All told, MEAN has unrivaled support from industry leaders like Amazon, Microsoft and Google. Because it is open source, the savvy developer can tweak it to their preference.  



Ruby on Rails


Ruby on Rails is another full-stack framework, and is the technology stack of choice for Twitter, Basecamp and other notable sites.

Mastering Rails will greatly solidify your understanding of core web concepts, and is an extremely desirable skillset within the web development industry.

Rails is similar to – but more refined than – frameworks such as PHP’s CodeIgniter and MEAN’s Express. Rails has excellent built-in support for MVC and REST — with ActiveRecord — a superb relational database ORM.

Ruby (language) and Rails (framework) are stable and mature, with lots of online support. Plus, more so than with MEAN, the Rails subsystems work together seamlessly.

Ruby has a thriving third-party ecosystem of add-ins (gems). If Rails doesn’t do what you need, a gem likely fills the gap.

Additionally, Rails is well-known for enabling one to rapidly build web apps. If you are an entrepreneur or want to prototype your ideas quickly, Rails is the choice for you.



BONUS: Swift iOS


Knowing how to extend your product to the mobile interface is a handy and potentially lucrative tool to have as a full-stack developer.

But, as you might imagine, writing mobile applications is different than building web systems. Mobile devices are powerful rich clients, always with you and always connected. Services like audio/video, location, motion and power-management, and the requirement that it seamlessly pair with the same back-end system created for browsers, can make a mobile app more complex than a full-featured web system.

The compiled language, object-oriented OS and mobile device paradigm of Swift and iOS will make it easier for you to subsequently pick up Java/Android or C#/.NET.

The iOS developer ecosystem is controlled end-to-end by Apple, so documentation is generally accurate and mostly complete (although pieces are sometimes in the previous language, Objective-C).

It’s important to note that the Swift language is new and constantly changing. Apple continues to rapidly evolve both Swift and XCode (the accompanying development environment). As a result, the online support you may have experienced learning other technology stacks is largely absent – or worse, incorrect. Unless you are willing to spend time sorting through things on your own, you may find this frustrating.

However, undoubtedly iOS is very cutting-edge, challenging, and for those reasons, quite in-demand. With the Apple App Store and direct distribution, you can sell apps and extend your product to millions of people!



Learn Full-Stack Development


Rest assured, there’s not one single path to becoming a full stack web developer.


By learning one or more of these technologies you’ll have familiarity with each development layer, be up-to-speed on the most in-demand programming languages, and will be on your way to mastering full-stack development.







References :

Social Impact