> For christ's sake, you suggested Java and Objective-C for the task. How do you expect to have any credibility after that?
Because while they might not be considered "hip" languages, they have large developer communities and are comparatively straightforward to pick up for any web developer that isn't familiar with them, yet they still have good support for the task at hand: talking to hardware.
> For a novice language, why are you expecting a typical task would be decoding a binary protocol?
Because they're talking to hardware, and because working with binary is actually much simpler (if your language doesn't have some bizarre aversion to it).
If you've ever taught novices to program, it's actually easier to start with binary as you avoid all the complexity of text encodings and parsing. You want an integer? Read an integer. No length prefixed fields. No reserved characters. No escape sequences. No terminating characters. No character set encodings. No case sensitivity or symbolic equivalents to worry about. The worst you might have to deal with is endianess and usually you can dodge that issue by starting with native endianess. C makes it harder with it's "not sure what width that is" fixed point integers, but that's part of why you don't pick C for that job either.
Working with binary only really becomes a pain once you have to start talking to humans.
> comparatively straightforward to pick up for any web developer that isn't familiar with them
compared to javascript.
really?
you think java is "easy to pick up" ?
I'm going to have to just say I disagree with you there. I don't like my chances of convincing you how silly that sounds. You seem to be operating on some very peculiar assumptions.
> compared to javascript. really? you think java is "easy to pick up" ?
Yes, compared to JavaScript, it absolutely is.
Really, the only PITA with learning Java is all the framework-itis (which is starting to become an issue with JavaScript as well, but that's another story...). For things like embedded systems, Java doesn't have any of that stuff and it magically returns to the comparatively simple language for programming network aware hardware it was originally intended to be.
> You seem to be operating on some very peculiar assumptions.
My assumptions are from teaching and watching other teach both children and adults how to program (usually with adults it has been people who are already professional programmers). I'd absolutely agree that Java isn't the best teaching language, but particularly if you've got someone who already knows how to program (which is kind of what I think of when I hear "web developer") at least at some basic level, it tends to be pretty easy to pick up.
JavaScript on the other hand, is quite the opposite.
I've worked with "copy-and-paste" developers who couldn't really write their own program from scratch to save their lives. When you asked them to explain what the code they'd pasted in was doing, JavaScript was invariably the language where they had the hardest time deciphering what was going on, and more often than not, you ended up sympathizing with their difficulty. (C++ and Perl can also be quite difficult to decipher, but they tend to have the advantage that anything much more complex than a one liner generally won't work at all if just blindly copied and pasted, so copy-and-paste coders tend to be rarer breeds there).
> Anybody can open up a browser and immediately start playing around with Javascript.
Tell me, if you were looking to teach people to write Java code for web applications (I know, perish the thought!), would you start them off writing applets?
> You simply can't say the same for Java, C, C++, or assembly--frameworks and the other nonsense notwithstanding.
Your statement about the ubiquity of JavaScript runtimes is really JavaScript's strongest feature IMHO, but I don't think it is terribly compelling in terms of developer accessibility. You could make something like that argument could say something pretty similar in support of DOS shell, PowerShell, AppleScript, VBScript, VSMacros, XSL, but no one would ever think that a defensible argument for them. Sure you want accessibility, but I think it's okay to suggest that a one click install not be outside the grasp or patience of a developer on their way to writing for distributed device systems... ;-) The difference between "open your browser and now start to learn this language" and "open your browser to download and install this app so you can start learning this language" shouldn't separate anyone who was going to make it in the first place.
Because while they might not be considered "hip" languages, they have large developer communities and are comparatively straightforward to pick up for any web developer that isn't familiar with them, yet they still have good support for the task at hand: talking to hardware.
> For a novice language, why are you expecting a typical task would be decoding a binary protocol?
Because they're talking to hardware, and because working with binary is actually much simpler (if your language doesn't have some bizarre aversion to it).
If you've ever taught novices to program, it's actually easier to start with binary as you avoid all the complexity of text encodings and parsing. You want an integer? Read an integer. No length prefixed fields. No reserved characters. No escape sequences. No terminating characters. No character set encodings. No case sensitivity or symbolic equivalents to worry about. The worst you might have to deal with is endianess and usually you can dodge that issue by starting with native endianess. C makes it harder with it's "not sure what width that is" fixed point integers, but that's part of why you don't pick C for that job either.
Working with binary only really becomes a pain once you have to start talking to humans.