If Philosophers were Programmers

“Wikipedia has a special section called, ‘Language Philosophy,’ in every article for a programming language. This section looks at the motivation and the basic principles of the language design. What if we investigate further than that? What deeper connections between philosophies and programming languages exist? By considering the most influential thinkers of all time (e.g. Plato, Descartes, Kant) we can figure out which programming language fits best with aspects of their philosophy (Did you know that Kant was the first Python programmer)? The list is not exhaustive, but this is a funny and educative start.”

Top Ten Errors Java Programmers Make

 

In the article, Top Ten Errors Java Programmers Make, David Reilly gives a list of his top 10 mistakes people do while programming in Java.

An excerpt:

Whether you program regularly in Java, and know it like the back of your hand, or whether you’re new to the language or a casual programmer, you’ll make mistakes. It’s natural, it’s human, and guess what? You’ll more than likely make the same mistakes that others do, over and over again. Here’s my top ten list of errors that we all seem to make at one time or another, how to spot them, and how to fix them.

Read more

Concept-Oriented Programming

 

In Informal Introduction into the Concept-Oriented Programming, Alexandr Savinov describes a new approach to programming based on using concepts instead of conventional classes and inclusion relation instead of inheritance. It generalizes OOP and allows the programmer to modularize cross-cutting concerns. In CoP, a great deal of functions is executed implicitly during object access via custom references with custom behaviour. There are several important points about this new approach briefly outlined below.

Concepts instead of classesUse concepts instead of classes in OOP where a concept is defined as a pair of two classes: one reference class and one object class. If a concept does not define its reference class then it is equivalent to a conventional class. Both objects and references possess some structure and behavioral methods. One simple consequence of having concepts is that objects are represented and accessed indirectly using custom references with arbitrary domain-specific structure and functions.

Inclusion instead of inheritanceInclusion relation is used in CoP where inheritance is used in OOP. Inclusion generalizes inheritance and, if a concept does not define its reference class (and hence is equivalent to a class), then inclusion is equivalent to inheritance. In the general case inclusion relation is interpreted as IS-IN relation while inheritance is interpreted as IS-A. As a consequence, a parent object may have many children. Another consequence is that object references have a hierarchical structure, i.e., they consist of several segments similar to postal addresses. Thus objects exist in a hierarchical address space which is modeled by the programmer.

Dual methodsEach concept has two definitions for each method provided in its reference class and object class. However, when methods are used they are applied to variables without any indication what definition to call, i.e., methods are used precisely as it is done in OOP. In order to resolve this ambiguity CoP introduces the mechanism of dual methods which specifies the necessary sequence of access. One property of this mechanism is that it is still possible to override parent methods by children but in addition it is also possible to override child methods from the existing parent. In the latter case the parent object will be able to actively intervene into the sequence of access by intercepting incoming method calls.

Cross-cutting concerns<The ability of parents to intercept all access requests independent of the type of the target child object makes it possible to modularize cross-cutting concerns existing in the program. This means that parent concepts play a role of aspects in AOP but do it completely differently. They are able to transparently inject the necessary intermediate functions when target object are about to be accessed. In this sense CoP can be viewed as an alternative to AOP.

Data modellingCoP is part of a new approach to data modelling, which is called concept-oriented data model (CoM). This data model consists of two parts: identity modeling and entity modeling (just because concept is defined as consisting of two parts). CoP is deals with identity modeling (while entity modeling is based on other principles). Therefore it looks quite promising from the point of view of integrating programming and data modeling (so called impedance mismatch in its different forms).

10 Commandments for Java Developers

 

There are many standards and best practices for Java Developers out there. The article 10 Commandments for java Developers outlines ten most basic rules that every developer must adhere to and the disastrous outcomes that can follow if these rules are not followed. Briefly summarizing the 10 commandments:

1. Add comments to your code. – It is true comments do not literally contribute to the functionality of a program. But time and time again you return to the code that you wrote two weeks ago and, for the life of you, you cannot remember what it does!
2. Do not complicate things. – Developers tend to come up with complicated solutions for the simplest problems. We introduce EJBs into applications that have five users. We implement frameworks that an application just does not need. We add property files, object-oriented solutions, and threads to application that do not require such things. For those who do not know any better, I recommend reaching out to the more experienced programmers for advice.
3. Keep in Mind – “Less is more” is not always better. – Code efficiency is a great thing, but in many situations writing less lines of code does not improve the efficiency of that code.
4. No hard coding please. – Developers often forget or omit this rule on purpose because we are, as usual, crunched for time. But maybe if we had followed this rule, we would not have ended up in the situation that we are in. How long does it take to write one extra line of code that defines a static final variable?
5. Do not invent your own frameworks. – There are literally thousands of frameworks out there and most of them are open-source. Many of these frameworks are superb solutions that have been used in thousands of applications. We need to keep up to date with the new frameworks, at least superficially. One of the best and most obvious examples of a superb widely used framework is Struts. This open source web framework is a perfect candidate to be used in web-based applications.
6. Say no to Print lines and String Concatenations. – I know that for debugging purposes, developers like to add System.out.println everywhere we see fit. And we say to ourselves that we will delete these later. But we often forget to delete these lines of code or we do not want to delete them.
7. Pay attention to the GUI. – No matter how absurd it sounds; I repeatedly observe that GUI is as important to the business clients as functionality and performance. The GUI is an essential part of a successful application. Very often IT management tends to overlook the importance of GUI. Many organizations save money by not hiring web designers who have experience in design of “user-friendly” applications. Java developers have to rely on their own HTML skills and their limited knowledge in this area.
8. Always Prepare Document Requirements. – Every business requirement must be documented. This could be true in some fairy tale, but it is far from that in the real world. No matter how time-pressed your development is, no matter how tight the deadlines, you must always make sure that every business requirement is documented.
9. Unit-test. Unit-test. Unit-test. – I am not going to go into any details as to what is the best way to unit-test your code. I am just going to say that that it must be done. This is the most basic rule of programming. This is one rule that, above all, cannot be omitted. It would be great if your fellow developer could create and execute a test plan for your code, but if that is not possible, you must do it yourself. When creating a unit test plan, follow these basic rules:
   1. Write the unit test before writing code for class it tests.
   2. Capture code comments in unit tests.
   3. Test all the public methods that perform an “interesting” function (that is, not getters and setters, unless they do their getting and setting in some unique way).
10. Remember – quality, not quantity. – Do not stay late (when you do not have to). I understand that sometimes production problems, urgent deadlines, and unexpected events might prevent us from leaving work on time. But, managers do not appreciate and reward their employees because they stay late on regular basis, they appreciate them because they do quality work. If you follow the rules that I outline above, you will find yourself producing less buggy and more maintainable code. That is the most important part of your job.