By the way, the only reason why I brought up cross platform as a key feature. Is that many languages out there have a strong framework to back them up. .NET( pick your language ), Nodejs ( which by its self technically isn't a language ), Python, etc.
On Thu, Jul 31, 2014 at 12:53 PM, William Hermans <[email protected]> wrote: > Well, it should be very obvious by now that I have a strong dislike for > Java, and I was being too literal. This sort of situation really upsets me, > and I've seen it happen on more than Java too. Most recently was with > Nodejs, and an older package manager pulling in x86 / i386 specific code > for my own BBB. This does not happen at all with NPM, at least not that > I've seen yet. > > Also since I do not use Java at all, I was under the impression that the > JVM was supposed to handle all the hardware abstraction, but from what > you're saying here I was probably wrong. At least in the context of > hardware architecture. This is how I feel it should be done however. > > I still wont touch Java, and there is at least one more language I try to > avoid at all costs too. But if it works for you, I say more power to you. > It was not my intention to start a "holy crusade" in the name of > development.. Despite the fact that seems where I've taken us. > > > On Thu, Jul 31, 2014 at 10:01 AM, Datenheld <[email protected]> wrote: > >> You're being too harsh on the topic. Most people didn't really use java >> because of platform independence. In the beginnings of Java, applets were >> the killer feature. You could easily deliver fat client software with the >> webbrowser. It wasn't that much about platform independence. Java is a lot >> more than platform independence. >> >> Platform independence hast its limits by design. When you want to be >> independent of something, you need abstractions. Abstractions are leaky, >> though. When you then want to do something, which is not common to all(!) >> platforms you support, then you cannot generalize it. Or you make it >> possible but then you depend upon the details of the platform. Those >> details are for example the native library that PureJavaComm delivers. >> >> >also it is not very proficient especially considering you've spent how >> many days here trying to troubleshoot an issue that should never have >> existed >> >> Well, I'm arguing against that by saying, that you will potentially have >> the same problem in every language that uses a runtime and does not compile >> to native code. >> >> >I could go on all day, but THIS is one reason why Java is a horrible >> language. People are taught to write sloppy / crappy code like this, and >> told that it's fine / good. It's not fine, when you break a key feature in >> a language. >> >> Why is it a key feature to communicate with low level peripherals? Once >> you go beneath a leaky abstraction (and every abstraction is leaky), you >> will have tight dependencies. You cannot say the code is crappy. The things >> you want to do are simply not possible without writing native code. When >> you choose to write such code in Java, it is by design and not necessarily >> crappy. It's all about the API for Java. >> >> I could take a native i386 lib with a python API, pull it over to arm and >> then complain that it does not work as well. This is basically what you are >> doing currently, no offense meant. >> >> >Anyway, do not take the above personally. but please do try to expand >> your horizons some. >> >> Well, personally, I am proficient in quite a lot languages. So I feel >> like I can judge languages quite well. Java has its flaws, but as a >> language, it is quite decent. You can write bad code in any language and >> Java code is not necessarily bad code, just because it breaks platform >> independence (reasoning: see above). I like Java because it's object >> oriented and does not need extensive resource managing like C++. I can >> handle complexity with it much better, than in C. And since I use it at >> work, I am getting results very fast. >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
