Just a quick update.
As part of a current project I'm not at liberty to discuss in such a public forum (when it's released, getting me to shut up about it will be the challenge) I was forced to poke into the guts of the Arduino app, specifically version 1.6.5 and figure out how to add a tool to the tools menu.
Surprise. The existing sample code doesn't work. Not surprising. It hasn't been updated since 2008.
So began my crash course in Java, Processing (the framework in which the Arduino app is actually written), and Arduino itself, which is based on a very old version of the aforementioned Processing.
As a result, I've come up with a basic skeleton for building tools for the Arduino app, along with simple documentation for how to build and install those tools. I've also created my very first git repository. Woohoo! Go me. :) So here it is, ready for the perusal of the entire universe. https://github.com/jrstrick/arduino_tool_skeleton.git
By the way, if my newfound loathing for Java hasn't come through in this post, let me make it clear. Java is an abomination of a language. The only one I've ever found that I liked less was Python. Java, at least, isn't whitespace-sensitive and broken between versions.
-JRS
4 comments:
I'd be interested to see a post on what exactly you find objectionable about Java, which would give me an opportunity to refute those objections (or to admit that I have no way to refute them).
My greatest complaints with Java are housekeeping matters, and some may be gross misunderstandings on my part.
First, the package declaration not only declares where the finished jar file will be, it declares what its paths MUST be in order to function. Why? What earthly point is there in this? I want to put my "executables" where I want them, damn it, and I'd like to do it without having to rewrite code.
Second, the idea that you can have only one class per file leads to piles and piles of files. This kind of pedantic insistence on a "right way" to do things and building it into the language irritates me disproportionately.
My third problem is related to the second, but is really a matter of other people's Java. Something about Java, probably my second objection above, encourages some programmers to abstract /everything/, spewing files and classes like monkeys throwing poop, until, to understand a class as it's instantiated, you have to unstack a dozen matryoshka-like declarations, each consisting of two or three lines of code and no comments.
And then there are the frameworks. I was working with the guts of the Arduino app, which was written in the Processing framework, which depends on the Swing framework, and probably others I'm not even aware of. My own (limited) experience with professional programming is that even when you use third party code you incur huge maintenance problems - frameworks and libraries go unsupported, get revised and the new version won't work, and so on. I realize only academics insist on doing everything themselves, but good night. How do pros make software work, revision after revision, when there are monkeys changing the frameworks it depends on? It would seem that the Arduino LLC's experience has been similar. They are generations behind in Processing, to the point where they had to fork it and go their own way. What is doubly annoying about this is that the Arduino LLC is one of the worst offenders for breaking backward compatibility. As I understand it, you can't build an addon that will work in 1.0 and 1.6.5. They changed pathnames, so your files will be in the wrong place. I read that they did it again between 1.6.5 and 1.6.6. Again, this is an "other people's Java" problem more than a fundamental problem with the language itself.
I'm showing my age, and the fact that I don't do this every day, I'm sure.
-JRS
Packaging all your compiled classes into a JAR file largely eliminates the need for specific paths they have to be in. The classes are in specific paths within the JAR file, but the JAR file itself can be anywhere, as long as your CLASSPATH points to it.
The restriction is not "one class per source file," it's one public class per source file. You can have any number of nonpublic classes in the same file with the "main" public class. In practice, we commonly use inner class declarations for additional classes needed to support a public class.
You can engage in excess levels of abstraction in many other languages; I don't think Java is necessarily any better or worse in that respect. One big reason why you abstract classes behind interfaces in Java is to make unit testing easier, since the functionality behind those interfaces can be easily mocked at testing time.
Arduino should have kept up with the latest revisions of the frameworks it uses. This tells me that they didn't do the work up front that allows them to easily refactor the code to adapt to new framework versions; specifically, I doubt they have proper unit tests on the code. You can't do aggressive refactoring unless you have tests in place beforehand to make sure that the refactored code doesn't break the behavior of the original code.
But yeah, some of this is attributable to the practices of the developers using the language, rather than the language itself. Remember Erbo's First Law: "Any programming language is suitable for writing CRAP."
Remember Erbo's First Law: "Any programming language is suitable for writing CRAP."
Amen. See also: obfuscated C. Or an abomination I saw back in college where a professor's sample Pascal code not only didn't compile, it was obvious he wrote it in his head as Fortran.
-JRS
Post a Comment