So, part 1 was all about our current circumstance in the world, with Java being a bit “dusty” (to use the term I used in the part 1 post) when held in comparison to the ideas backing new languages.
To recap the most important idea from part 1: Java was a great step forward for its time, but there is of course the possibility of a better idea than Java.
Was the original brick cell phone the end-all solution for cell phones? Heck no. Was Compaq’s first laptop the best design, just because it was the first of its kind? Absolutely not.
Just so, C and Java are not necessarily the best end-all solution, no matter how good you feel either of those languages is.
As I pointed out in part 1, there is a good legitimate use for (almost) every language, regardless of anything I say against any language. Thus, Java will never *actually* disappear, just like C will never actually disappear. I’m okay with that, but I wish to bring a better understanding to those of you who code in Java who would like to crucify people like me for suggesting that Java isn’t the best solution.
Part 2: Something of a Design Flaw
We all hate that diabolical moment when the sudden realization hits us: there’s a design flaw, and a project redesign is needed in order to accomplish the necessary task. And it’s either a redesign, or you’ll be forced into more countless hours of trying to code your way around the design flaw, thus the code becomes convoluted, and making it impossible for the next guy to easily grasp what’s going on.
Part 1 was clean of any significant reference to other languages. Part 2 is not. You’ve been warned. I’ve established the foundation of my case in Part 1, and so from this point of view, read the rest of Part 2 in conceptual terms.
If I get any replies on how to better code a Java example, then those persons have entirely and utterly missed the point of what is being presented (again). If you are one of those persons, then I cry for you and your blindness to outside ideas.
Java’s core development effectively stopped the day the JVM was completed; ”That’s it, that’s all” (as the french Québecois say.. in english). Once the JVM was made, the Java platform allowed for pretty much any package to be developed. The JVM has all of its nasty internals tucked out of sight, and coders are free to make whatever code they want, and it’ll run on top of the JVM. Yes, the JVM is probably tweaked frequently, but huge additions aren’t really in Java’s script (’script’ as in playwrite). Therefore, you have to “code around” the design in order to accomplish modern operations on Java’s data types.
This is generally the pattern of most languages: initial core development exits stage right, package development takes the spotlight. So this being the case, we can’t really expect any overhaul to the JVM and how it works. Therefore, I present to you concepts.
Programming is becoming more and more “object-oriented”, and rightfully so. The goal therefore, is to make the code modular. The goal of modular code is easy deployment/use all over the project’s code. You change something in one main source file, and the changes are reflected everywhere.
Java (like a few other languages) has saturated (super-saturated?) itself with packages which define hundreds of specialized data structures for certain tasks. This is great if you understand the fine nuances between their uses. But frankly, naming two Classes “HashMap” and “HashTable” doesn’t clear anything up for me. What’s the difference? (Readers, don’t answer; it’s rhetorical.)
Python’s idea is a bit different: of course it provides certain data structures for you to use, but it decided to circumvent some of this madness.
So here’s the bottom line: Java says “Pick your card”. Python says “Write you own card”.
That’s probably a terrifying thought for you Java peoples. “What? No Hash generalization to plug into a [Concurrent]Map/Table/AttributeSet/Set ???!!?” And the same applies to Tree stuctures and the whole gang.
No, Python’s job is not to baffle you with finely-tuned data structures that you’ll never master. Instead, Python’s “Write your own card” approach is used, and it’s surprisingly simple: You’re going to write what you need to use, but we’re going to make it easy to do that.
Let’s start with something *extremely* simple. My argument has more weight than this, but you’ll begin to understand soon. Java did away with simple integer values casting into booleans for use in IF constructs. Reasoning probably had to do with ambiguity between a ‘1′ and a ‘true’. To avoid this, Java doesn’t cast ints into booleans. Fair enough. But then we explore the rest of how Java compares values. To test the “value” of an variable, we’re used to using the ‘==’ sign. The problem with dynamic object is that everything is pointers. This means that if you ask if Object1 == Object2, you’re comparing their memory addresses which each pointers points toward. That’s not what you want. So by necessity, Java provides dozens of methods on each object’s base class called ‘equals’. And so Java typically tests value by the ‘.equals()’ method. This sort of removes the ‘==’ from its most common use! ’==’ is left only for FOR constructs and simple primitive tests.
Python, and a few other more forward-thinking languages, have added a reserved word called ‘is’. This solves the issue noted above. When you want to compare the ‘value’ of two objects, you use ‘==’, but when you want to test the ‘identity’ of two objects, you use the word ‘is’.
The point here is that if you say Object1==Object2, you’re comparing values (the most common case, you might argue), but when you want to ask if Object1 literally IS Object2 (ie, their pointers are the same), Python just makes you compare as Object1 is Object2.
Example follows. Note that in Python, examples are provided with “>>>” prefixing lines that you would type in an interactive console session. Lines without the “>>>” are things returned to you by the Python Interpreter.
# Python
>>> myInt = 1
>>> myBoolean = True
>>> print myInt == myBoolean
True
>>> print myInt is True
False
Very simply, the ‘==’ operator is used to ask the integer and boolean values if they “boil down” to the same thing. This is True. But if you ask the integer if it IS the boolean value True, then it returns False, because an integer simple ‘is’ not a boolean.
This is the kind of new stuff that Python (and other languages) are offering to the world. Java is sort of half stuck in this world of mixing the meaning of the ‘==’. If used with primitives, you test by value. If you test with any object at all, you test by memory address, and are thus forced to use Object1.equals(Object2) to test value.
Integrating custom objects in Python into standard Python syntax is amazingly easy. By contrast, Java rather frequently forces you into writing goofy class methods to perform your tests.
Consider this example of array indexing. The following seems natural:
// Java
String[] myArray = new String[]{"1", "2", "3"};
String myVar = myArray[0]
But if you write your own object, you can’t ever use indexing notation, to get or set items as the indexed position. You have to use custom class methods instead. But in Python, you can integrate with the language by defining methods on your object. Thus, I can actually tell Python what myCustomObject[0] or even myCustomObject["sectionName"] means:
# Python
>>> myCustomObject["mainSection"] = "hello world"
>>> print myCustomObject["mainSection"]
'hello world'
In effect, you can have your custom object manage the values however you want; that is up to you. It abstracts the implementation so that if it ever changes, code other people have written won’t deprecate so easily, because they access the data via standard Python syntax.
Further, you can actually iterate over a custom object in your own custom way. You can pick what “iterating over” the object means. You have complete power. Assuming you had several “positions” in your custom object, example code might look like the following:
# Python
>>> for i in myCustomObject:
... print i, ":", myCustomObject[i]
'mainSection' : 'hello world'
'another' : 'foobars are healthy'
Can you see the power in this? You have the amazing ability to tell the language how to integrate very simply with the standard language syntax.
Lots of “advanced” object functionality is available to Python’s objects by default. There’s no need to dig out obscure utility functions to get efficient functionality. A popular thing about arrays these days are “array slices”. Simply, this means that you can access several indexes of an array at a time. In Python, your typical idea of an ‘array’ is implemented as a data type called a “list”. This is built into Python automatically. There’s no need to import any goofy package first.
# Python
>>> myList = ["a", "b", "c", "d"]
>>> myList[0]
'a'
>>> myList[0:3]
['a', 'b', 'c']
# You can also imply the beginning or end of the list:
>>> myList[:3]
['a', 'b', 'c']
>>> myList[1:]
['b', 'c', 'd']
# Or, you can go backwards:
>>> myList[-1]
'd'
See how easy this is? Say goodbye to excessive myArray[myArray.length - 1] calls. Lists support pushing, popping, removing specific items, and queries to find out if an element exists in the list:
# Python
>>> myList = ["a", "b", "c", "d"]
>>> myList.append('e')
>>> myList
['a', 'b', 'c', 'd', 'e']
>>> poppedValue = myList.pop()
>>> poppedValue
'e'
# Pop from an index:
>>> poppedValue = myList.pop(0)
>>> poppedValue
'a'
# Append lists together:
>>> myList.extend(['1', '2', '3'])
>>> myList
['b', 'c', 'd', '1', '2', '3']
>>> "b" in myList
True
>>> "z" not in myList
True
# As a side note, you can do the same to any iterable object, including strings or custom objects!
>>> myString = "12345"
>>> myString[2:4]
'34'
>>> myCustomObject[1:]
['foobars are healthy']
Much more is possible, but this is good enough to start with. Just understand how amazing simply Python has made this. Java is a nightmare compared to this. It might all seem trivial to you, but Python has decided what the most effective way to perform these operations is simply built in. Anybody caught using any loops in Python to do these things should be arrested. Anybody caught using loops in Java to do these things is doing it because they have no choice.
These examples only touch the surface of the differences. These differences are exactly what makes modern programming languages so powerful. Yes, there’s a speed trade off, but the productivity to be gained is incredible. The “scaffolding” of Java and C is overdone. It is not as needed as it once was. Python’s clean appearance is easy to read, easy to maintain, and easy to extend. Python is fully object oriented, and supports multiple class inheritance. Complex tasks are easier, and you’ll find that you don’t need to code with your browser open to the current JavaDocs. Python’s just easier. I’d love to expound on more features of Python which further enhance productivity, so I’ll probably write a Part 3, for those curious to have it explained.
The point is not comparing speeds. The charts often prove that Java can outrun Python in many tasks. But as you look at the code to power the Java part of the test, and then compare it to the Python equivalent, you’ll be shocked at how little effort is required to achieve the same behavior. And with those clock cycles lost in the Python code are more than made up in productivity, allowing you to simply accomplish MORE. Certain tasks will still require C, regardless of how good Java is. Nobody seems to complain between the slowness of Java compared to C. Thus, it’s not a big step to move on to Python. Modernize. Get more done.
Until part 3.
I’ve got one of those 12-in-1 memory card drives, so it was pretty useless in Vista or XP when I clickedon that icon, because it would only tell you random drive letters and the like. Now, it tries to split it up by the physical hardware. I intentionally put in my camera and iPod, so that you can see what kind of effect they were shooting for this time around. That main “F:\” section on the bottom is my 12-in-1 card reader, which has 5 slots in it. Only one currently has a card in it, so it naturally shows the card’s name.
In fact, just a few seconds after I took the screenshot, it corrected itself to a non-negative integer, haha…
