IMPLICT MAGIC

I learned to program with BASIC followed by C. These languages require syntax to tell the computer to do something.

Java, like many contemporary languages, has many implicit features that add convenience, but my impartive language roots make these features difficult to accept.

This diffculty results in a trouble with fluency.

For example, in Part 2, I mention implicit casting and the fact that it will not loose precision.

This is generally a safe thing to do, and makes life easier by having to type fewer characters. But it does cause a schism in the language. There are some cases where casts are not necessary and some where they are, and in both these cases the predicate of the statement has the same subject (type conversion). At this point Java starts to take on the characteristics of a colloquial language. I’m streaching things, but from the point of view of being able to site read code, this starts to make a difference.

If I open up some code, written in the C-family syntax, in general, I should be able to tell what it is doing (ignoring complex domain specific knowledge). However, once implicit language features are added, a specific knowledge of the language becomes necessary to understand the code.

Of course, this is what programmers get paid for–to know the languages they use. I’ve written code in many languages with implicit magic, and I get used to it eventually. But, these sorts of differences require effort to maintain fluency. I hit a wall in this case with Ruby. Ruby does a considerable amount at the interpreter level. I could not justify reading the amount of documentation that would have been required to fully grasp the language. I’ve edited some Ruby code, but I could not tell you much about it now.

All of this is not to rail against implicit language choices. They are obviously favoured by many. But, I need to develop a method of noticing the differences between the languages, so I do not have to continually relearn the specifics when I switch code bases.

ABSTRACT METHODS

A part of my course last week had to do with inheritance and abstract methods.

After experimenting with abstract method declartion, I found that I could not declare two abstract methods that only differed by return type.

protected abstract void test(int i);
protected abstract String test(int i);

In this case, the second version of the abstract class is not found and attempting to override it in a subclass causes a compile time error.

This provides some ability to control what subclasses can do with abstract methods, which gives programmers of abstract classes some guarantees about return types. This level of hierarchical control creates options for writing code that is secure.