We Keep Coding

How much more difficult is it to write cross-platform software in Haskell than in Java?

I am fairly new to Haskell and to programming in general, and I'd like to use Haskell for a project that I have in mind. My major concern is how difficult it will be to write a cross-platform program with Haskell. Ideally, I'd like my final product to work and be easy to install on most Windows, Mac, and Linux machines.
I haven't written any Java, but as I understand it, one of the major strengths of Java is that you can "write once, run anywhere." Since I haven't heard that claim made about Haskell, I assume that a bit more work goes into writing a cross platform Haskell program than in writing a cross platform Java program.
My question is, how much more work are we talking about? If I want my program to work on most Windows, Mac, and Linux machines, how much more of a headache will I be causing myself if I opt to use Haskell instead of a JIT compiled language like Java?
And as a follow-up question:
To what extent can the answer to my first question be applied to all non-JIT compiled languages generally? Are the challenges of creating cross platform software in Haskell more or less equivalent to the challenge of doing so with any other compiled language? How unique is Haskell in this regard?
Thanks!

You can roughly divide languages into two types- Those that require some type of helper program, and those that are compiled. Examples of languages that need helper software include- Java, which needs the jre, HTML needs a browser, interpreted languages like perl or python need the perl/python interpreter. C/C++ and GHC/Haskell are compiled languages, and can run on their own (Haskell has an interpreter also, but you probably can't assume that your users will have it installed).
There are different challenges associates with each approach. To run Java/HTML/Perl/Python, the user has to install the correct version of the associated helper program, but other than this, you can easily supply one version of your program and assume it will work anywhere. To distribute a compiled program, you generally have to compile it on each target OS and supply a separate version for each one. GHC has been ported to Linux, Mac, and Windows, so you can do this. Compiled programs can run on a target machine without installing anything else.... except perhaps a required library....
Library compatibility can be a problem in both types of languages.... Your user may need to install required libs (package managers like apt can do this automatically). This affects all languages (with or without helper software), and I don't consider it an advantage in one type of language vs another (although some languages like Python, and even Java to some extent advertise "batteries included", meaning that pretty much anything you will want is included in the base install).
So, if you stick to normal libs, and don't mind recompiling for each target platform, Haskell programs can work on all the common systems (much better than C/C++, which use slightly different variants on each OS).
See also Do ghc-compiled binaries require GHC or are they self-contained?

Technically, Java is compile once; run everywhere, as it compiles to an intermediate machine-like language. Haskell, like C/C++, compiles to native machine binaries, which means you need to compile everywhere (for every architecture/OS).

Does compiling Java to native code protect the source code?

Now, I know that...
Anything can be reverse engineered, given enough time and resources.
However, would compiling your Java code to native code with a tool like GCJ make it more difficult to decompile? I mean, given a few minutes, I can decompile a .jar using JD-GUI, and it is relatively accurate. Most of the "Java to EXE" converters are just .exe launchers for the JVM, and while there are many benefits to the JVM, I have been led to believe that security of the source code is not one of them.
Bottom line: Can you use something like GCJ to compile your Java source (or .class) files to native machine code, and if so, will that protect it from decompiling?
EDIT: Ideally, it would be something more than just obfuscation. The specific project is a commercial game, so what we are looking for is a way to make it more difficult to get to the source code to begin with, not just understand it. Also, I'm not sure that Steam accepts .jars, and we are planning on submitting it to the new Green Light project.

I wouldn't choose that approach just for source-security.
Check out some Obfuscator tools out there like ProGuard
If you want to see what those tools do to your source code, just try read the decompiled Minecraft jar if you have one on hand.
A downside to using this is, that if your code depends on using reflection, you'll have to configure the tools to ignore those functions/classes/whatever, as those will not be found at runtime otherwise.

Technically, yes. Using something like GCJ will make it harder to decompile, however keep in mind that you are losing some major benefits of using Java if you do this. Namely, you lose the ability to write cross-platform applications.
You could use an obfuscator to make the code harder to decompile AND still keep the benefits of using Java.

a Source code obfuscator like
this , this and this
makes your variables, functions, etc... unreadable by other(has no logical meaning). You should read here too!

What languages would be a good replacement for Java?

I may be posting a premature question, and maybe I'm just freaking out for no reason, but the way Oracle is handling Java is not very promising. I am a nerd who fell in love with Java from the first sight, and use it all the time in my personal/freelance projects but now I am thinking of a replacement.
I am fluent in C#/VB.NET too but I am looking for something more like:
Open Source
Compiled
Cross-Platform
Object Oriented
Large standard library
Extensive documentation
Web development is a major plus
I was thinking about a compromise: Python/Django for web development (or PHP), and Qt for thick client development. Anyone with better thoughts?

Not so long ago, I decided to explore away from the JVM. I set foot on python, and even though i'm nowhere near the expert/ guru level, I dont regret it. Didn't choose C# (considered it) because I consider it to be more of the same. I alredy know (and like a lot) C++, so python seemed like something new, which is what I was looking for.
It fullfils many of your requirements. Particularly, i'm decided not to learn PHP, so the web frameworks in python came in great.
Not to mention, Python has a large community (also see here), always eager to help and teach, which I consider to be very important.
Just my two cents.

Might be worth loking at the other JVM languages - Clojure and Scala are the two I personally think are most promising.
Yes you are on the JVM, but you're pretty independent from Java the langauage and don't have to use any Sun/Oracle implementations if you don't want to.
Having said that - I think that you are worrying a little too much about Java, too many players (including Oracle!) have too much invested to let it go too far off course.

Try Scala. It looks extremely elegant and promising. Being object oriented and sharing a lot with java in a very concise manner.

Everything you said points to C#, except for the Open Source point.
To fix that, there's Mono.

You could try D. My one-sentence description of why it's an awesome language is that its generic programming/compile-time introspection/template metaprogramming facilities are good enough to give you almost flexibility of a duck-typed language, while its execution speed and static type checking rival or exceed C++ and C#.
I think it meets your requirements quite well.
Open source: The frontend to the reference DMD implementation is open source (the back end isn't due to restrictions beyond the author's control). Work is underway to glue the reference frontend to open source backends such as LLVM (LDC) and GCC (GDC). In the case of D1 (the older version of the language) the LLVM port is fairly mature.
Compiled: D is meant to be compiled to native machine code, i.e. raw, inscrutable hexadecimal numbers.
Cross-platform: The reference DMD compiler supports x86 Windows, Linux, Mac OS X and FreeBSD. GDC and LDC will likely support a lot more CPU architectures.
Object oriented: D isn't a "pure" OO language in the Ruby sense of everything being an object, or in the Java sense of not supporting any other paradigm. It does, however, fully support Java-style OO as a subset of the language, along with procedural and functional style programming.
Large standard library: D1 has Tango, which qualifies. D2 has Phobos, which is not "large" yet by modern standards but is larger than C or C++'s standard lib. However, recently there has been a large interest in contributing and Andrei Alexandrescu (its main designer) has accepted several new contributors, including myself.
Extensive documentation: The standard library and language are reasonably well documented at the Digital Mars website. There's also Andrei Alexandrescu's book "The D Programming Language".
Web development: This is an admitted weakness. D doesn't (yet) have a good web framework, though its native unicode support and excellent generic programming support should make writing one relatively easy.

I too would like another Java-like technology to come along. Lately I've been doing Flex/Actionscript. While I really enjoy it, Actionscript technology seriously lacks the elegance that Java has. Adobe can write some good cross platform APIs, but they just don't have the head capital to build elegant languages and compilers. I've also tried Ruby, but the VM for Ruby is really bad. I've gone back to Java after my flirtation with other technologies and I think it's because the language is good enough, but the JVM is by far the best out there.
So do you want to stay with the JVM or do you really want to the leave the JVM altogether? Staying on the JVM there are lots of options: JRuby, Scala, Groovy, Javascript, Clojure are the big players. However, there are tons of great languages that can take advantage of the JVM's features.
Leaving the JVM there are still good options like python, ruby, and erlang. But you give up some of the nice features of the JVM like performance (big one), and the ability to drop down to a nice language like Java if you need speed. Those others mean using C or nothing at all.
I finally stopped worrying about Java's future. Sun did all it could to screw it up and it still turned out pretty darn good. I think Opensource has a lot more influence over Java's success than Oracle or Sun could ever have had.

I can't post comments yet, so I'm posting an answer related to the Python discussion. Though Python isn't compiled to machine code, there is a Python-to-C compiler called Cython, which can compile nearly all valid Python -- closures are finally (!) in the latest development release. It's have a big impact on some parts of the Python commmunity, e.g., I was at Euroscipy recently, and over half the talks mentioned Cython.

I personally don't like PHP, but it does meet all of your requirements. It doesn't officially support compilation but there is the Hip Hop project which compiles PHP to C code. Facebook is currently heading up this project.
That said, I highly discourage you from using it :)

C# is the only thing that will meet your needs and not feel hopelessly archaic, or frustrate with limited library. For open source/non-windows, use mono. It's a good, mature implementation of most of what's important in the CLR.
Some things (WPF, WCF, etc) are "missing" from mono, but these aren't so much part of the platform as they are windows-specific proprietary toolkits. Some of them are being implemented slowly in mono, some aren't. Coming from java you won't miss them because you're looking for a platform and good standard libraries to build upon, not a gui toolkit or whiz-bang communication framework.
As far as a platform to build stuff with that's "like" java and offers similar levels of functionality, C# + CLR is the clearest option.

Using also Cython you get the best of the two worlds , the ability to code in python , the ability to code in C and C++ and of course compile your code and the ability to use both python a c/c++ libraries out of the box. And if you dont like C++ syntax , cython syntax is python syntax and more.
link text

Problems porting Java to J#

I've got a medium sized (25k lines code, 25k lines tests) codebase in java, and would like to port it to run on a CLR as well as the JVM.
Only the main class, and a few testing utilities deal with the file system or OS in any way. The rest of the code uses the generic collections APIs extensively, java.util.regex, java.net (but not URL or URLConnection), java.io for charset encoding/decoding, java.text for unicode normalization, and org.w3c.dom for XML manipulation.
Is it possible to get most of the codebase compiling under both J# and Java, and then port the rest?
If so, what kind of pitfalls am I likely to run into?
thanks in advance,
mike

Check out IKVM: http://www.ikvm.net/
It allows you to run (specially compiled) Java code inside the .Net CLR.
Some of my colleages have used it successfully with a Java codebase of 1 million+ lines of code.

Pitfalls:
Anything like this scares the heck out of me. The number of really subtle bugs waiting to happen is huge.
J# only supports Java 1.1.4 AFAIK - goodbye generics etc.
Visual Studio 2008 doesn't support J# - basically it's a dead project.
I suspect that you'd actually find it simpler to rewrite it in C# (including learning C# if you don't already know it - it's a joy). You'll end up with a more idiomatically .NET-like library that way as well, if that's relevant: if you ever want another .NET developer to consume your code, they're likely to be far happier with a "pure" .NET project than one using J#.
The downside is that going forward, any changes would also need to be made in two places. There's certainly pain there, but I really think you'll have a better experience using "normal" .NET.

As Jon pointed out: J# is pretty dead.
Running your (normal) Java code on .NET using IKVM might be an alternative, 'though.

When learning Java, how important is it to know Unix well?

Other than the Java language itself, you have to learn the java framework. Similiar to how you have to learn the .net framework in addition to the language (C#/VB).
How important is it to know unix? Or rather, what unix areas should one focus on?
Seeing as many people run java based applications (desktop/web) on unix boxes, what sort of unix skills do you need? Are we just talking basic directory traversing, creating files, etc or is there much more to it?

The answer as read from Sun marketing material is that Java is cross platform, so you don't.
The practical answer is that you need to know enough to get your own application up and running on the platform where you plan to use it. Getting to know Apache or Tomcat configuration helps if you're working with web development, and so does knowing how to use the basic network analysis tools - the ifconfig, netstat and traceroute commands are all useful. File permission tools are also a must for getting a system working - look into chmod and chown and how those commands work.
Desktop systems have it easier, since most windowing systems are very good at working cross platform, but you still need to know a little bit about how the file system and permissions are structured.

Really, you don't need unix skills directly for writing java-based applications. However, if you want to develop java-based applications on unix boxes and deploy there, you want a good working understanding of how to operate and administer a unix box.
But for the areas you mention (directory traversing, creating files), you'll be using Java APIs that only occasionally touch on Unix-specific ("\n" vs "\r\n", directories rooted at "/", etc.) information. When they do touch, it's not something you need to know in a programming sort of way, it's something you need to know in a user/administrator sort of way.

Not important for the language it self.
You can learn java very well and never have touched a unix box at all.
If you want to deploy on a unix server however you should know just the basics.
File paths, new lines, permissions, etc. but the knowledge needed can be acquired after a few hours in the typing in the terminal.
Most of the os specifics are abstracted into the language from the beginning. Those that cannot be abstracted ( such as cron for instance ) are left behind.

You don't really need Unix skills to use Java, but if you do you'll have a good toolbox relevant for any kind of development. I certainly appreciate the ability to grep my entire source tree for files, use Perl for code generation and so forth. Even a simple matter of counting all lines of source code can be hard to do in a GUI only world. Knowing the basic Unix command line tools will make you a better developer imo.

I think your metaphor means you should learn Java library in addition to the language itself.
Certainly knowing UNIX will help a bit as it increases your general knowledge, but I don't think it's really directly related to Java at all.

As well as knowing how to traverse directories, you need to be able to edit and grep files. You need to know how do do some basic process management also. But the level of detail you need depends on what you want to do on a unix system. Eg. web development requires that you run a web container such as tomcat. You will probably want to learn the package manager of your system of choice.

It depends on your OS. You can do Java development on Windows in which case no Unix/Linux knowledge is required. That said, even on Windows GNU/Cygwin utilities can be helpful.

I assume that you are talking about learning and not developing a full scale project.
Because of the JVM, which by vision should provide a uniform API towards the programmers, regardless of the underlaying system, Java programs are meant to be written in a way that is not specific to the underlaying system (up to the point of using JNI etc').
That means that as a writer of small programs for learning,
your knowledge of the underlaying system should be minimal.
If you are not using IDE, you should at least know how to run 'javac', 'java' from the command line, and to test your program.
If you are Using an IDE like Eclipse, from the point that the IDE is running, you should expect an experience that is almost isolated from the system underneath.
However keep in mind that this is the vision, and it is always advised to know at least a bit about what's going on on your own system.

You don't need to know *NIX to develop a Java application, maybe if you're going to run it on a *NIX machine or if it uses something very attached to *NIX it'll be good if you know the basis about file names and permissions, for example.
The need of knowing *NIX comes with the need of deploying the app on a *NIX server. If this is the case it'll be good if you know something about system variables (set the JAVA_HOME, for example), the tipicall directory structure of a *NIX machine, and basic use (creating files, directories, deleting, symlinks...).
I think it's very good to know some scripting (bash, csh, sh). Depending of the complexity of the deployment this can give you extra points at the look of your boss for example.