Why is the host software written in java?

I've been considering porting the host software to pyqt4 because i dislike java immensely (i find java to be a pain to install with all its libs, and i have never been able to use it comfortably.) As pyqt4 is effectively as portable (py2exe can build a windows version in seconds with no user input or dependencies), and arguably freer, would there be any interest from the community? I'm not in any way critisising anyone's work, the software works great as-is, just wondering if there are any reasons it is written in java or if the devs happen to like it.

I think the primary consideration is that is has to run anywhere?

PC, Mac and Linux.

Python runs everywhere, and imho it is simpler to install than java. Standalone executables are easy to create if installing programs is undesirable, and the advantages of no dependencies must outweigh the costs of generating 3 different executables.

Python runs on Windows, Linux/Unix, Mac OS X, OS/2, Amiga, Palm Handhelds, and Nokia mobile phones. Python has also been ported to the Java and .NET virtual machines.

Java can be run on every machine that can run Firefox And if I wanna want to use Python on things like Solaris then I need to download a 3rd-party software...

And if I consider the fact that everyone has Java... and a few have python.

Edited 2 time(s). Last edit at 01/23/2009 05:44PM by Mr. Seeker.

While you may dislike Java, and I dislike Java, there's two points to recommend it over python:

1) Python's class handling sucks. I mean it's downright terrible. I say this despite the fact that I love working with python and I think it's marvelous. But oo code in python is really annoying. self.anything_in_your_class is really annoying to write. You'd think they'd have left that distinction only for cases where an identifier is overridden locally.

2) Java is far faster than python. Java actually parallels C++ for speed. C++ is somewhat faster depending on compiler optimizations, but with the more recent revisions in JIT, most of the slack between the two has been taken up. The same cannot be said for python. python is an interpreted language, and it's not what you could call fast.

If it's ok slow, use python. If it needs to be sorta fast, use C++ or Java. If it needs to be really fast, use assembly.

I think compiled vs. interpreted is the biggest argument against python but Java isn't necessarily 'the best' language either.

Having said that, speed isn't really a factor in the long run as any differences will be minuscule compared to Moores Law (eg. 20% difference in speed is approx. equivalent of a difference of 4 months in terms of purchasing a computer).

What I think we want in a language is:
- Garbage collection (so we don't have to worry about the most common bugs: various types of memory leaks and buffer overflow issues).
- Portable - run anywhere as mentioned above.
- Popular - so we can get as many devs involved as possible.
- Efficient to write and maintain.
- Large open source extensible SDK toolkit to allow the most flexibility for programmers and enhance the efficiency.

Edit: This list is approximately in my order of importance, yours may vary significantly :-)

Speed is a much lower priority than these but I think having a language that is interpreted rather than compiled would lessen initial uptake and effect the popularity/mindshare that the language has as well.

Java is a 'good enough' fit but not the perfect fit for these criteria - most problems can probably be traced back to the limitations Sun had on it in it's infancy.

In the future I do think we will transition away from Java, probably to a language that hasn't been invented yet that deals with all the perceived problems with Java :-)

If anyone is interested there is a good book called 'After the Software Wars' by Keith Curtis you can buy and download ($5) or have printed on demand from [www.lulu.com] which has a section about programming languages, and what is wrong with Java, C, C++, C# etc. and what this new Java++ language would have in it.

It is written by a former 'Softie who got interested in Open Source and Linux after 11 years at MS.

Edited 1 time(s). Last edit at 01/25/2009 10:50PM by reece.arnott.

> - Garbage collection (so we don't have to worry
> about the most common bugs: various types of
> memory leaks and buffer overflow issues).

Interestingly enough, garbage collection is directly at odds with real-time control for all but extremely specialized garbage collectors, and even then it is hard to get it to perform right. It leaves your system suceptible to extremely chaotic delays when the system needs more memory. I'd much prefer if critical portions of the code were written separate and without a garbage collector; it's not hard to not mess up for pieces that big.

As much as I know it's hard for a lot of people, this might be best done in C. C compiles for everything, doesn't have that issue, and it's not that hard to make it build on both platforms.

I mean, we can certainly ignore the problem and have it work most of the time, and have it be good enough. But I'm not sure I'd want garbage collection as a requirement for anything that's part of the control path

>> Interestingly enough, garbage collection is directly at odds with real-time control

One keeps the amount of code having real time control requirements as small as possible, and uses a language that gets closer to the hardware.

99% of the software needed by reprap does not need actual realtime performance, it just needs to work and yield results in a reasonable amount of time (I.E, the modeling software, the slicing software, the path generation engine, the fill engine... none of these subsystems need to be real time.)

The only real time component is tool path execution and hardware control, and this is very small in terms of lines of code -- this is the part that needs to be written in a low level language -- C++, C or assembly would probably be best choices here.

BeagleFury Wrote:
-------------------------------------------------------
>
> The only real time component is tool path
> execution and hardware control, and this is very
> small in terms of lines of code -- this is the
> part that needs to be written in a low level
> language -- C++, C or assembly would probably be
> best choices here.
>
Hell, mine real time stuff is written in Basic. Works fine.

The trick is to get your PC out of the real time loop. I did that by building a nice big EEPROM buffer for very low level print instructions. I've never looked back.

---

-------------------------------------------------------

Hell, there are no rules here - we're trying to accomplish something.

Opportunity is missed by most people because it is dressed in overalls and looks like work.

Thomas A. Edison

One HUGE advantage to Java is its' "mindshare". My mother-in-law has Java on her PC and knows it and is comfortable with it. If she didn't have it I could tell her how to get it with minimal bother. If I told her she needed Python on her PC she would probably drop the whole idea as too snake related. Just a thought.