Background: I want to develop a component therefore building a class library.
This component should be usable with many higher-order languages such as C, C#, C++, VB, Java, Haskell, Ruby, Erlang, ...
I do not want to exclude any users which are not using my development language.
Are there principles or tools which supports my project?
I searched a little bit and found Haxle for compiling into different languages, but it supports very few of them.
I would even develop parallel in all n languages to be supported, but if I want to change or fix something I have to maintain all other n-1 and the code is possibly distributed...
This is not what I know about clean code design and maintainability. So how to manage edits on code for the different languages?
What is the proper way to solve this? I am surely not the first one which want to build a library for multiple languages.
I want to develop this library (in this case for complexity reduction) in one target language but this time for multiple platforms (Unix, Win, Mac ...).
How to manage this? In fact there will be appreciated about 90% of code which is platform independent and 10% which differs for every OS.
What is the best way to control the changes in the platform dependent code? (The independent is easy ...)
What if I change so things in the part which uses Unix dependent code, then I have to trail all other platform and the code is possibly distributed.
I think #IFDEF is no option ...
Are there any experiences or hints?
I would be delighted if there are existing solutions to these problems, which are quite similar.
What you want is only possible if you provide interfaces for every language you want to support. Some kind of wrapper which transforms between the client language and ypu library.
This is possible but not practical in most cases for standalone libraries.
Take a look at webservices or or message orientad middleware. In this case your application will be provided within a special container which itself provides interface mechanism e.g.
SOAP, XML-RPC to call your application.
For 1), I would use an interface that all these languages can use. A common approach is something based on networking/TCP, like protobuffer, REST, SOAP. Many languages support these in their standard libraries, and interfaces designed with that are normally language agnostic.
There are basically two options - you could develop a network server or you could develop a JVM-based library which could be shared between some of the JVM languages like JRuby or Jython.
Update from #millimoose: you could also develop your library in C and create bindings for all other languages.
For multi-language:
I thought about TCP/middleware/webservices/REST/ which seems to be the recommended proceeding.
But I think it's all to much at runtime for only using a library.
Also the functionality is a little bit time-critical and so direct procedure calls are more fitting (instead of networking even on localhost). And the library user hasn't to construct an access component only to use the library functions.
So I think the way to go seems to be developing the library in a core language which is widely supported (C/C++, ...) and provide wrapper interfaces for the different target languages.
For multi-platform (mono-language):
No real answer has been provided also not in my mind.
Of course I could simply use Java (what I am familiar with) but what about other languages?
I am surely not the first one having this/these problem(s) ...
Having recently read up a on Objective-C it strikes me as a fairly neat language with plenty of cool features.
I have no intention of doing any iPhone development, however I understand that GCC is able to compile Objective-C code and so I wanted to know - Is Objective-C a viable alternative language to C99 for Windows development?
In particular:
Is anyone currently doing Windows development using Objective-C?
Are there any runtime components that would need to be distributed with my applications?
I understand that Objective-C is a superset of C, does this mean that it is possible to use any C-compatible library? (for example the Windows API)
Would I get garbage collection in my applications?
I've found Cocotron and GNUstep which are often mentioned when talking about using Objective-C on other platforms, however as GCC can already be used to compile Objective-C I don't really understand why I would need these.
Are there any other pitfalls or traps I might run in attempting Windows development using Objective-C?
With respect to your first question, I don't know if anyone is seriously doing development on windows with Objective-C, but there may be, though those numbers would probably be less than those doing serious work with a language like whitespace.
Secondly, you would need, at a minimum the objective-c runtime. There are two runtimes, NeXT's (now Apple's) runtime, and the GNU Objective-C runtime. They are not compatible. If you are on a non-NeXT and non-Apple platform, such as windows, you have no choice, GNU runtime only.
Objective-C is a superset of C, and yes you can use the Win32 API if you so desire directly in your objective-c code. As well, you would only get garbage collection if you use a conservative collector, and it ties in with the libraries you're using. In short: No.
What GCC has is support for the objective-c language, and runtime, no standard library. What the GNU objc runtime provides you with in terms of a standard library, is two objects: Object, and NXConstantString class, which is needed to support the #"" syntax. Object is merely a base class. Not very useful, eh? This is why frameworks like Cocotron and GNUstep exist — to give you access to an implementation of OPENSTEP/Cocoa.
Regarding pitfalls or traps, yeah: Your application, even using Cocotron or GNUstep may never be portable to the Mac for instance, or you may get bit by things like typed selectors in the GNU objc runtime, or a plethora of other problems. Let me finish answering this by posing another question: What pitfalls or traps might you run into targeting .NET? I'm sure some if not most of those apply in this case too. Standard pitfalls and traps apply.
I hope this helps.
There is no mature solution yet. If you develop the solution itself, you can do it anyway. But if you're not, it's not the time.
For compiler tools, there is LLVM/Clang which are open-source under BSD license.
The compiler is sponsored by Apple, so it compiles Objective-C completely, and is becoming primary compiler for Apple. So compiler is no problem anymore.
Problem is runtime environment library. Objective-C language is depends it's runtime to execute. The runtime defines all behavior of object system and some more. Runtime environment library is core system and different with framework library like Cocoa or Quartz. in .NET, it's CRE, not .NET framework class library.
Without runtime, program cannot be executed like .NET program executed on Windows without .NET runtime.
For more details, check this conversation:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-January/007593.html
Is there any other scripting language that can be used to embed scripts inside applications, which can access Mac OS X, or application classes with the same features, or most of the features seen in F-script?
The scripting language with the best support on the Mac is still AppleScript. But unlike F-Script, it cannot directly access the Objective-C level, it can only use what the target application chooses to expose for scripting.
There are Objective-C bridges for Perl, Python, and Ruby. I suppose those can embedded to provide scripting to your application.
Nu is an interesting option, although it isn't very popular yet.
A lot of people seem to like JSTalk.
But probably Applescript is your best bet: integrated into the system and all that.
I would say F-Script for many reasons. It has many unique features and is extremely tightly integrated with Cocoa and the Objective-C runtime. You can for example inspect various Finder classes (windows, icons, coverflow view...) and it's very easy (one or two lines of code) to start or control other processes. I don't think there is any good reason to prefer AppleScript. It's good for very short scripts, but will probably drive you crazy if you want to do something more complex.
Also, MacRuby is going to rock when it's a bit more stable, and some serious stuff has been accomplished using PyObjC as well, although I don't think it's very actively maintained anymore.
If you don't need F-Script graphical introspection tools, which are quite unique, there are some decent scripting languages that you can embed in applications. See in Particular RubyCocoa (for Ruby), PyObjC (for Python), JSTalk (for JavaScript) and CamelBones (for Perl). They are based on bridges between Cocoa and a foreign object model, which leads to some complexities. This is different from F-Script, which is directly built for the Cocoa object model. When ready, MacRuby might be an option too, but the syntax for manipulating Objective-C objects is not very nice (it improves on RubyCocoa, though). Nu is also an option: directly built for Cocoa like F-Script, but with a strong Lisp flavor.
MacRuby is an implementation of Ruby 1.9 that uses the Objective-C runtime and garbage collector. It can be embedded in a Objective-C application.
Even if the last available version is only 0.6, it is reported to be stable enough to be used in applications.
I see here that there are a load of languages aside from Java that run on the JVM. I'm a bit confused about the whole concept of other languages running in the JVM. So:
What is the advantage in having other languages for the JVM?
What is required (in high level terms) to write a language/compiler for the JVM?
How do you write/compile/run code in a language (other than Java) in the JVM?
EDIT: There were 3 follow up questions (originally comments) that were answered in the accepted answer. They are reprinted here for legibility:
How would an app written in, say, JPython, interact with a Java app?
Also, Can that JPython application use any of the JDK functions/objects??
What if it was Jaskell code, would the fact that it is a functional language not make it incompatible with the JDK?
To address your three questions separately:
What is the advantage in having other languages for the JVM?
There are two factors here. (1) Why have a language other than Java for the JVM, and (2) why have another language run on the JVM, instead of a different runtime?
Other languages can satisfy other needs. For example, Java has no built-in support for closures, a feature that is often very useful.
A language that runs on the JVM is bytecode compatible with any other language that runs on the JVM, meaning that code written in one language can interact with a library written in another language.
What is required (in high level terms) to write a language/compiler for the JVM?
The JVM reads bytecode (.class) files to obtain the instructions it needs to perform. Thus any language that is to be run on the JVM needs to be compiled to bytecode adhering to the Sun specification. This process is similar to compiling to native code, except that instead of compiling to instructions understood by the CPU, the code is compiled to instructions that are interpreted by the JVM.
How do you write/compile/run code in a language (other than Java) in the JVM?
Very much in the same way you write/compile/run code in Java. To get your feet wet, I'd recommend looking at Scala, which runs flawlessly on the JVM.
Answering your follow up questions:
How would an app written in, say, JPython, interact with a Java app?
This depends on the implementation's choice of bridging the language gap. In your example, Jython project has a straightforward means of doing this (see here):
from java.net import URL
u = URL('http://jython.org')
Also, can that JPython application use any of the JDK functions/objects?
Yes, see above.
What if it was Jaskell code, would the fact that it is a functional language not make it incompatible with the JDK?
No. Scala (link above) for example implements functional features while maintaining compatibility with Java. For example:
object Timer {
def oncePerSecond(callback: () => unit) {
while (true) { callback(); Thread sleep 1000 }
}
def timeFlies() {
println("time flies like an arrow...")
}
def main(args: Array[String]) {
oncePerSecond(timeFlies)
}
}
You need other languages on the JVM for the same reason you need multiple programming languages in general: Different languages are better as solving different problems ... static typing vs. dynamic typing, strict vs. lazy ... Declarative, Imperative, Object Oriented ... etc.
In general, writing a "compiler" for another language to run on the JVM (or on the .Net CLR) is essentially a matter of compiling that language into java bytecode (or in the case of .Net, IL) instead of to assembly/machine language.
That said, a lot of the extra languages that are being written for JVM aren't compiled, but rather interpreted scripting languages...
Turning this on its head, consider you want to design a new language and you want it to run in a managed runtime with a JIT and GC. Then consider that you could:
(a) write you own managed runtime (VM) and tackle all sorts of technically difficult issues that will doubtless lead to many bugs, bad performance, improper threading and a great deal of portability effort
or
(b) compile your language into bytecode that can run on the Java VM which is already quite mature, fast and supported on a number of platforms (sometimes with more than one choice of vendor impementation).
Given that the JavaVM bytecode is not tied so closely to the Java language as to unduly restrict the type of language you can implement, it has been a popular target environment for languages that want to run in a VM.
Java is a fairly verbose programming language that is getting outdated very quickly with all of the new fancy languages/frameworks coming out in the past 5 years. To support all the fancy syntax that people want in a language AND preserve backwards compatibility it makes more sense to add more languages to the runtime.
Another benefit is it lets you run some web frameworks written in Ruby ala JRuby (aka Rails), or Grails(Groovy on Railys essentially), etc. on a proven hosting platform that likely already is in production at many companies, rather than having to using that not nearly as tried and tested Ruby hosting environments.
To compile the other languages you are just converting to Java byte code.
I would answer, “because Java sucks” but then again, perhaps that's too obvious … ;-)
The advantage to having other languages for the JVM is quite the same as the advantage to having other languages for computer in general: while all turing-complete languages can technically accomplish the same tasks, some languages make some tasks easier than others while other languages make other tasks easier. Since the JVM is something we already have the ability to run on all (well, nearly all) computers, and a lot of computers, in fact already have it, we can get the "write once, run anywhere" benefit, but without requiring that one uses Java.
Writing a language/compiler for the JVM isn't really different from writing one for a real machine. The real difference is that you have to compile to the JVM's bytecode instead of to the machine's executable code, but that's really a minor difference in the grand scheme of things.
Writing code for a language other than Java in the JVM really isn't different from writing Java except, of course, that you'll be using a different language. You'll compile using the compiler that somebody writes for it (again, not much different from a C compiler, fundamentally, and pretty much not different at all from a Java compiler), and you'll end up being able to run it just like you would compiled Java code since once it's in bytecode, the JVM can't tell what language it came from.
Different languages are tailored to different tasks. While certain problem domains fit the Java language perfectly, some are much easier to express in alternative languages. Also, for a user accustomed to Ruby, Python, etc, the ability to generate Java bytecode and take advantage of the JDK classes and JIT compiler has obvious benefits.
Answering just your second question:
The JVM is just an abstract machine and execution model. So targetting it with a compiler is just the same as any other machine and execution model that a compiler might target, be it implemented in hardware (x86, CELL, etc) or software (parrot, .NET). The JVM is fairly simple, so its actually a fairly easy target for compilers. Also, implementations tend to have pretty good JIT compilers (to deal with the lousy code that javac produces), so you can get good performance without having to worry about a lot of optimizations.
A couple of caveats apply. First, the JVM directly embodies java's module and inheritance system, so trying to do anything else (multiple inheritance, multiple dispatch) is likely to be tricky and require convoluted code. Second, JVMs are optimized to deal with the kind of bytecode that javac produces. Producing bytecode that is very different from this is likely to get into odd corners of the JIT compiler/JVM which will likely be inefficient at best (at worst, they can crash the JVM or at least give spurious VirtualMachineError exceptions).
What the JVM can do is defined by the JVM's bytecode (what you find in .class files) rather than the source language. So changing the high level source code language isn't going to have a substantial impact on the available functionality.
As for what is required to write a compiler for the JVM, all you really need to do is generate correct bytecode / .class files. How you write/compile code with an alternate compiler sort of depends on the compiler in question, but once the compiler outputs .class files, running them is no different than running the .class files generated by javac.
The advantage for these other languages is that they get relatively easy access to lots of java libraries.
The advantage for Java people varies depending on language -- each has a story tell Java coders about what they do better. Some will stress how they can be used to add dynamic scripting to JVM-based apps, others will just talk about how their language is easier to use, has a better syntax, or so forth.
What's required are the same things to write any other language compiler: parsing to an AST, then transforming that to instructions for the target architecture (byte code) and storing it in the right format (.class files).
From the users' perspective, you just write code and run the compiler binaries, and out comes .class files you can mix in with those your java compiler produces.
The .NET languages are more for show than actual usefulness. Each language has been so butchered, that they're all C# with a new face.
There are a variety of reasons to provide alternative languages for the Java VM:
The JVM is multiplatform. Any language ported to the JVM gets that as a free bonus.
There is quite a bit of legacy code out there. Antiquated engines like ColdFusion perform better while offering customers the ability to slowly phase their applications from the legacy solution to the modern solution.
Certain forms of scripting are better suited to rapid development. JavaFX, for example, is designed with rapid Graphical development in mind. In this way it competes with engines like DarkBasic. (Processing is another player in this space.)
Scripting environments can offer control. For example, an application may wish to expose a VBA-like environment to the user without exposing the underlying Java APIs. Using an engine like Rhino can provide an environment that supports quick and dirty coding in a carefully controlled sandbox.
Interpreted scripts mean that there's no need to recompile anything. No need to recompile translates into a more dynamic environment. e.g. Despite OpenOffice's use of Java as a "scripting language", Java sucks for that use. The user has to go through all kinds of recompile/reload gyrations that are unnecessary in a dynamic scripting environment like Javascript.
Which brings me to another point. Scripting engines can be more easily stopped and reloaded without stopping and reloading the entire JVM. This increases the utility of the scripting language as the environment can be reset at any time.
It's much easier for a compiler writer to generate JVM or CLR byte-codes. They are a much cleaner and higher level abstraction than any machine language. Because of this, it is much more feasible to experiment with creating new languages than ever before, because all you have to do is target one of these VM architectures and you will have a set of tools and libraries already available for your language. They let language designers focus more on the language than all the necessary support infrastructure.
Because the JSR process is rendering Java more and more dead: http://www.infoq.com/news/2009/01/java7-updated
It's a shame that even essential and long known additions like Closures are not added just because the members cannot agree on an implementation.
Java has accumulated a massive user base over seven major versions (from 1.0 to 1.6). Its capability to evolve is limited by the need to preserve backwards compatibility for the uncountable millions of lines of Java code running in production.
This is a problem because Java needs to evolve to:
compete with newer programming languages that have learned from Java's successes and failures.
incorporate new advances in programming language design.
allow users to take full advantage of advances in hardware - e.g. multi-core processors.
fix some cutting edge ideas that introduced unexpected problems (e.g. checked exceptions, generics).
The requirement for backwards compatibility is a barrier to staying competitive.
If you compare Java to C#, Java has the advantage in mature, production ready libraries and frameworks, and a disadvantage in terms of language features and rate of increase in market share. This is what you would expect from comparing two successful languages that are one generation apart.
Any new language has the same advantage and disadvantage that C# has compared to Java to an extreme degree. One way of maximizing the advantage in terms of language features, and minimizing the disadvantage in terms of mature libraries and frameworks is to build the language for an existing virtual machine and make it interoperable with code written for that virtual machine. This is the reason behind the modest success of Groovy and Clojure; and the excitement around Scala. Without the JVM these languages could only ever have occupied a tiny niche in a very specialized market segment, whereas with the JVM they occupy a significant niche in the mainstream.
They do it to keep up with .Net. .Net allows C#, VB, J# (formerly), F#, Python, Ruby (coming soon), and c++. I'm probably missing some. Probably the big one in there is Python, for the scripting people.
To an extent it is probably an 'Arms Race' against the .NET CLR.
But I think there are also genuine reasons for introducing new languages to the JVM, particularly when they will be run 'in parallel', you can use the right language for the right job, a scripting language like Groovy may be exactly what you need for your page presentation, whereas regular old Java is better for your business logic.
I'm going to leave someone more qualified to talk about what is required to write a new language/compiler.
As for how to writing code, you do it in notepad/vi as usual! (or use a development tool that supports the language if you want to do it the easy way.) Compiling will require a special compiler for the language that will interpret and compile it into bytecode.
Since java also produces bytecode technically you don't need to do anything special to run it.
The reason is that the JVM platform offers a lot of advantages.
Giant number of libraries
Broader degree of platform
implementations
Mature frameworks
Legacy code that's
already part of your infrastructure
The languages Sun is trying to support with their Scripting spec (e.g. Python, Ruby) are up and comers largely due to their perceived productivity enhancements. Running Jython allows you to, in theory, be more productive, and leverage the capabilities of Python to solve a problem more suited to Python, but still be able to integrate, on a runtime level, with your existing codebase. The classic implementations of Python and Ruby effect the same ability for C libraries.
Additionally, it's often easier to express some things in a dynamic language than in Java. If this is the case, you can go the other way; consume Python/Ruby libraries from Java.
There's a performance hit, but many are willing to accept that in exchange for a less verbose, clearer codebase.