We Keep Coding

Alternative to Java

I need an alternative to Java, because I am working on a genetics-calculation project.
It takes a lot of memory and the most of the cpu time. And therefore it won´t work when I deploy it on a server, because many people use the program at the same time.
Does anybody know another language that is not running in a virtual machine and is similar to Java (object-oriented, using exceptions and type-safety)?
Best regards,
Jonathan

To answer the direct question: there are dozens of languages that fit your explicit requirements. AmmoQ listed a few; Wikipedia has many more.
And I think that you'll be disappointed with every one of them.
Despite what Java haters want you to think, Java's performance is not much different than any other compiled language. Just changing languages won't improve performance much.
You'll probably do better by getting a profiler, and looking at the algorithms that you used.
Good luck!

If your apps is consuming most of the CPU and memory on a single-user workstation, I'm skeptical that translating it into some non-VM language is going to help much. With Java, you're depending on the VM for things like memory management; you're going to have to re-implement their equivalents in your non-VM language. Also, Java's memory management is pretty good. Your application probably isn't real-time sensitive, so having it pause once in a while isn't a problem. Besides, you're going to be running this on a multi-user system anyway, right?
Memory usage will have more to do with your underlying data structures and algorithms rather than something magical about the language. Unless you've got a really great memory allocator library for your chosen language, you may find you uses just as much memory (if not more) due to bugs in your program.
Since your app is compute-intensive, some other language is unlikely to make it less so, unless you insert some strategic sleep() calls throughout the code to deliberately make it yield the CPU more often. This will slow it down, but will be nicer to the other users.
Try running your app with Java's -server option. That will engage a VM designed for long-running programs and includes a JIT that will compile your Java into native code. It may make your program run a bit faster, but it will still be CPU and memory bound.

If you don't like C++, you might consider D, ObjectiveC or the new Go language from google.

You may try C++, it satisfies all your requirements.

Use Python along with numpy, scipy and matplotlib packages. numpy is a Python package which has all the number crunching code implemented in C. Hence runtime performance (bcoz of Python Virtual Machine) won't be an issue.
If you want compiled, statically typed language only, have a look at Haskell.

Can your algorithms be parallelised?
No matter what language you use you may come up against limitations at some point if you use a single process. Using something like Hadoop will mean you can retain Java and ease of use but you can run in parallel across many machines.

On the same theme as #Barry Brown's answer:
If your application is compute / memory intensive in Java, it will probably be compute / memory intensive in C++ or any other "more efficient" language. You might get some extra leeway ... but you'll soon run into the same performance wall.
IMO, you need to do the following things:
You need profile your application, and look for any major performance bottlenecks. You might find some real surprises.
In the light of the previous step, review the design and algorithms, paying attention to space and time complexity issues. Do some research to see if someone has discovered better algorithms for doing the computations that are problematic from a performance perspective.
If the previous steps don't get you ahead of the curve, see if you can upgrade your platform; get a bigger machine with more processors, more memory, etc.
If you are still stuck, your only other option is a scale-out design. Assuming that individual user requests are processed in a single-threaded, re-architect your system so that you can run "workers" across multiple servers, with a load balancer on the front. If you have a persistent back-end, look into how you can replicate that. And so on.
Figure out if the key algorithms can be parallelized / distributed so that the resource intensive parts of a user request execute in parallel on multiple processors / multiple servers; e.g. using a "map-reduce" framework.
OK, so there is no easy answer. But simply changing programming languages is NOT a good answer.

Regardless of language your program will need to share with others when running in multiple instances on a single machine. That is simply the way computers work.
The best way to allow your current program to scale to use the available hardware resources is to chop your amount of work into small, independent pieces, and make them implement the Callable interface. These can then be executed by a suitable Executor which can then be chosen according to the available hardware. See the Executors class for many preconfigured versions. THis is what I would recommend you to do here.
If you want to switch language then Mac OS X 10.6 allows for programming in the way described above with C and ObjectiveC and if you do it properly OS X can distribute the code over all available computing resources (both CPU and GPU and what have we).
If none of the above is interesting to you, then consider one of the Grid frameworks. Terracotta may be a good place to start.

F# or ruby, or python, they are very good for calculations, and many other things
NASA uses python

Well.. I think you are looking for C#.
C# is Object Oriented and has excellent support for Generics. You can use it do write both WinForm and server-side applications.
You can read more about C# generics here: http://msdn.microsoft.com/en-us/library/ms379564(VS.80).aspx
Edit:
My mistake, geneTIcs, not geneRIcs. It does not change the fact C# will do the job, and using generics will reduce load significantly.

You might find the computer language shootout here interesting.
For example, here's Java vs C++.
You might find Ocaml (from which F# is derived) worth a look; it meets your requirements for OO, exceptions, static types and it has a native compiler, however according to the shootout you may be trading less memory for lower speed.

Performance of Java 1.6 vs C++?

With Java 1.6 out can we say that performance of Java 1.6 is almost equivalent to C++ code or still there is lot to improve on performance front in Java compared to C++ ?
Thanks.

Debian likes to conduct benchmarks on this sort of thing. In their case, it appears that Java is about half as fast and consumes 2-18 times as much memory as C++.

A well-written Java program is never going to be as fast as a well-written C or C++ program. The virtual machine is an irreducible overhead. However, most code is not well written.
Java is a simpler language than C++, and offers a more forgiving environment for inexperienced programmers - so if your programmers are inexperienced (and cheap), then Java will probably perform 'better' than C++.
shared_ptrs offer a similarly forgiving environment in C++, so they are very tempting for inexperienced programmers, or those migrating from Java, But their performance overhead is as bad or worse than Java's garbage collection. I've seen large C++ programs where every variable is a shared_ptr, and they perform terribly.
My opinion
Personally, I think that large projects need to choose an 'easy' programming language for the bulk of their code, and a 'fast' one for sections that need optimising. Java may be a good choice for the 'easy' language, especially since there is currently a plentiful supply of Java programmers - in the future, I think even easier languages such as Python will begin to take over.
C++ is a reasonable choice for a 'fast' language if you already know it, but I think it's over-complexity will eventually see it fall by the wayside, while C will continue to fulfill this role.

I would expect that most of the time for most applications C++ will be faster than Java.
In some cases there will be some C++ which is slower than Java for a given task. This is pretty rare and always a result for poor implemntation or more commenly poor refactoring of an application.
In the majority of cases the performance difference more than offset by the fexibility, ease of use, availability of libraries, and, portability that Java provides.
In a very few cases performance is so critical that developing in Java would be a poor choice <opinion><flame off>in these cases plain C is usually a better choice than C++ </flame></opinion>.
Currently the sweetspot in performance/ease of use/ease of development tradeoffs is C#. Portability is a big issues here though.

I find that Java performs very well.
However, why has no one ever fixed my biggest complaint?
Java uses FIVE TIMES as much memory as a C++ program doing the same job. At least!
And once it's used, Java keeps it!
Please, please, why won't anyone write a garbage collector for Java that uses minimum amounts of RAM? It could compact the heap and returns the memory to the OS. Instead of ridiculous piles of -Xm* options, use the memory needed and then give it back!
Actually I am sure some of the embedded system JVMs do this, but none of the desktop or server systems do.
This memory piggishness makes Java applications all want to act as if they own the entire computer system, that no one ever wants to run more than one application and that RAM is free and infinitely upgradable.
Therefore, no matter how great the performance, I would never write anything like a utility program in Java. Only gigantic server apps need apply.

What program are you developing?
Comparing C++ to Java speed is like comparing a screwdriver and a hammer, pointless. In the world we live in, where both supercomputers and toasters need to be programmed, you need to focus on your particular requirements.
I use C++ for hard realtime software running on embedded systems. I wouldn't dream of using the awfully broken Java for realtime spec for at least another 5 years, when it will hopefully be mature. I would be equally loath to use C++ for a database, cloud accessing middleware app (actually I have no Idea what I just said, but I know Java is good for 'that sort of stuff')
Would you use a ferrari with no trunk space to move your belongings? Would you bring a minivan to a drag race?
People have to understand that just because they are programming languages, does not mean they are comparable in a meaningful way.

No. Unless you measure it, you may not say it.

Performance is usually "good enough" for most purposes. The question is what you want to compare exactly, and if you have applied a profiler to find and fix the hotspots in your code.
JVM's based on Sun's code still pay a hefty startup-tax (I still wonder why they cannot snapshot that and restart from there) but Suns approach has been correctness first, speed second, and it's taken them 10 years to get up to par.
So the answer is "It depends" :)

For most applications it is almost certainly possible to write a C++ program which performs considerably better than a program to achieve the same thing in java.
However if the program isn't optimised for speed then java will likely be just as fast or faster because the compiler / JIT is able to make optimisations that a C++ environment can't.
Basically if you are willing to spend considerable time understanding and coding for performance you can probably do a considerably better job in c++ eventually than you could in java but for the same amount of time and effort it is quite likely that java will "win".
As usual though, algorithmic improvements tend to make as much if not more difference than the language.

Moving heavily templatized C++ code to Java

I have an application written in C++ (makes heavy use of templates) that I need to take to the Java ME platform.
I have two questions:
Are there any good tools to convert C++ code to Java - do some basic stuff so I have a platform to start with. I found this - http://tangiblesoftwaresolutions.com/Product_Details/CPlusPlus_to_Java_Converter_Details.html. It would at least eliminate the need for simple but time-consuming stuff like moving classes to different files, namespaces to packages, etc. Has anyone tried it? Or knows of any better ones?
The bigger problem is how to deal with templates - the code makes very heavy use of them. Any suggestions on how to go about this? Are there any tools to expand templates for instance so I have a rudimentary base and then I could work on writing the modules in Java?
Any help would be appreciated.

For all of Sun's marketing, Java is not simply a better C++, and in fact does not support many of the idioms and paradigms C++ supports. This makes automated translation difficult. How should you automatically turn a multi-inheritance hierarchy into Java's single inheritance hierarchy? (Note, I am not saying that a multi-inheritance hierarchy is a good thing, only that it is explicitly allowed in C++). More fundamentally, how would you represent a pointer-to-member function in Java? Or handle the differences between Java and C++ overload resolution?
Java added generics a few years ago, but purposely made them less powerful than C++ templates. Regardless of whether that was a good idea, it limits what automated translation can do with heavily templatized code.
Aside from using some research compiler that can turn C++ into Java bytecode, I'm afraid you may be stuck doing the translation by hand.

Can you use JNI and call the old C++ code from the new Java code?

I think for your case a very simple tool would be possible and perhaps worthwhile. Might be a fun weekend-job, though! A friend of mine once did a port from C++ to Java and he just made a list of regular expression substitutions. Like, he had all occurrences of -> replaced by a dot. And so forth. This was some years ago, however, so I don't really feel like asking him.
So, you could do the same, collect some easy substitutions and perhaps publish them somewhere on github?

Generics is the Java feature that corresponds to C++ templates and they are not supported in J2ME. You can use them with the aid of a framework, which probably uses pre-processing to do the trick. (Actually Generics in Java is a compiler feature - the JVM knows nothing about them.)
Anyway, it will be difficult if not impossible to automatically port even a small portion of your code form C++ to Java Standard Edition - things are much worse with J2ME. There are many and important differences between Java Generics and C++ templates.

I don't think it's going to be possible, esp. if your original code is heavily templatized - J2ME doesn't support generics, AFAIK.
Unfortunately, it seems like this will require a lot of manual work to go through the original code and rewrite it (I'm assuming your target platform doesn't support JNI)

Which is more similar to AS3, Java or C++?

I am ActionScript 3/Flex programmer, it is the first language I learned.
I want to learn either Java or C++.
Would one of these be easier to learn based on my current knowledge?

It really depends what you want to do. C++ is more powerful and fast. But Java has a smaller learning curve.
I'd say learn C++, only because it will require you to gain a better understanding of how computers work under the hood. It will also help position you to learn Java, C#, or any other language down the road.

Java seems more likely to be directly relatable to your work in AS3; C++ is better for giving you a grounding in a different technology (pointer-style OO rather than object-style. C++ may feel eerily similar yet different).
If you are doing C-ish C++, the pointer language learning process can be very informative as to how OS-level calls are written...
The places where you will reach for one tool or the other are very different, and the use you have for the tool may be more important in deciding than their relative merits as languages - employability IS a use for a tool, after all.

Well, AS3 more closely resembles JavaScript - they both follow the ECMAScript specification.
But to answer your question, I would say learning Java will be more beneficial and easier for you. Java supports Interfaces, and single inheritance, like Flex, whereas C++ supports multiple inheritance and lacks a formal notion of Interfaces. Java and Flex both manage memory for you, whereas C++ forces you to manage your own memory. Both Java and Flex have large helper libraries out of the box, and both have native String types, whereas C++ forces you to find a library to use and doesn't support native String types.
This may be my own bias, but it also seems more likely that you'll find a job that is looking for a Flex/Java developer, rather than a Flex/C++ developer. Java and Flex seem to work well together, with Flex as a front end and Java as a middle and back end.

I would say Java is more similar to AS3 than C++. You will find lots of familiar metaphors and mechanisms.
C++ on the other hand, will require more effort to learn. It is closer to the machine and demands an undertanding of lower level mechanisms. For instance, there is no garbage collection so you have to manage your memory resources yourself.
Which is better to know depends on what you plan to do with the language. C++ is good at performance critical applications (games, all kinds of real time simulations etc.). Java makes it easier and safer to build things, but at the cost of performance.
hope this helps
regards

C++ is, generally, harder to learn than Java. You will find this true pretty much no matter what your previous experience. Therefore, if you want to learn the easier, learn Java.
(This is partly a matter of design philosophy. C++ was designed to be mostly upward compatible from C, at least the C at the time C++ was being designed. It was also designed
to be useful and permissive, with ease of learning being secondary. Java was designed partly as a reaction to C++, as a generally safer and easier language. C++ is more expressive than Java, but this comes at a price: it's harder to learn C++, and easier to screw up with it.)
That being said, you never said why you wanted to learn another language. You might well be better off learning C++, even though it is more difficult.

Whatever you'll finally decide to learn, do yourself a favor and read either Thinking in Java or Thinking in C++.
Both books are available - for free! - at Bruce Eckels website. They are very, very good.
C++ is more complex than Java so I'd suggest to take a look at Java, first.
However, this isn't meant as C++ bashing. Both are great language, it just depends on what you'd like to do in the end.

I would go with Java. It will be easier to learn and, given your background, I'm guessing you do more web/internet work in which case you'll probably find more ways to apply the Java knowledge then you would C++.

I think you would find Java more similar.
Learning C++ will likely require you to learn concepts that you could avoid with other high level languages (such Java and AS3) e.g. manual memory management, pointers, non forward looking compiler, multiple inheritance, etc.

C, C++, Java, what is next and what will it look like? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
What do you think the next evolution of languages will look like?

You might assume C and C++ are being "phased out" and that Java/.Net/Python/whatever is an "advance" or the "next stop".
They are all used heavily (see the number C or C++ of tags on this site). The difference is that neither one is the lingua-franca of the programming world anymore. It used to be that the majority of apps were desktop or DOS apps on systems with very limited resources, furthermore all the major desktop APIs were written in C or C++. So everyone learned these.
Now its more complex. Languages are becomming more application specific. C/C++ for when performance is important. Scripting languages for when your main performance hit is db reads/writes. Java and .Net for generic, non-performance-critical desktop apps.
Its the same thing with computer or electrical engineering. In the past these were huge fields at the highest level of abstraction available. Now we have all sorts of higher levels of abstraction. Still, we need people to do this lower-level kind of engineering. They are still in demand. In the same manner, C will continue to be used in many environments, as will C++. You'd be crazy, for instance, to think that you could write a device driver in Java, you'd also be mildly crazy (but perhaps less so) to write a full fledged GUI app in C if you had the choice and ability to do it in Java or .Net.
Each tool has its purpose. I expect C, C++, and Java to evolve and continue to be used for new and legacy development.

I can't speak for C++ and Java, but C definitely ain't goin' nowhere...
It's pretty much unthinkable to write any kind of operating system kernel without most of it in C (well, you can use assembly language entirely if you are really stubborn :-P).
C is basically a thin wrapper of niceness around assembly language. It's so tightly coupled to a standard Von Neumann CPU architecture that no standard library or runtime is required to implement most of its features: pointers, character strings, automatic variables on the stack, integer arithmetic, etc.
For the same reasons, C is great for user-level applications that absolutely demand high performance, things like multiplying huge matrices or parsing complex languages. It may be a pain to write a parser in C, but the speed and efficiency advantages of manual memory management are hard to pass up...

Alan Kay once said "Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind."
He is working on changing the future of programming
"The real romance is out ahead and yet to come. The computer revolution hasn't started yet. Don't be misled by the enormous flow of money into bad defacto standards for unsophisticated buyers using poor adaptations of incomplete ideas." source
Well, I might add that Bjarne once said "There are only two kinds of languages: the ones people complain about and the ones nobody uses."

Languages evolve to fill a niche problem that is not covered by other languages.
Weather that language gets a foot hold and establishes itself is another question entirely and has a lot to do with popularity.
What comes next?
The problem I see that needs filling is multi-processors (or multi-cores). Currently all the popular languages have very limited ability to exploit the additional cores. Basically all current popular languages give the developer the very basic objects (threads/locks etc) to use the cores and then leave it up to the developer to try and exploit the parallelism available from multi-cores.
It would be a nice to have a language that abstracted away the concept of cores (even threads) and could automatically exploit the enherant parallelism available from multi-cores/multi-processor architecture. Unfortunately all these languages (that I know about) are still research projects at universities and are unlikely to see real adoption any time soon.
You imply that there was a progression C -> C++ -> Java.
That's a bit artificial, each language represents a method of solving problems and each language has inherent problem domains where it is efficient at solve a problem and other problem domains where that language would be a bad choice.
Personally:
I would never write a device driver with Java.
I would probably not write back-end web module with C (you probably can but not me)
etc.

C# ? -- oh, but that is Java :) (sorry, couldn't resist)
The next generation of languages is already here, Scripting ones. Its no mistake that Microsoft is working on the DLR (dynamic language runtime). I think the future will be interpreted (but JITted), dynamic languages that have few constraints and lots of flexibility.
Performance constraints for the majority of languages are not so important nowadays, or no-one would be writing Java or C# apps at all, but considering CPUs are super-fast, and RAM is cheap, we don't notice the inefficiencies of these higher-level designs (eg if you have a 1mhz cpu, you write your code in C, not C#. If you have a CPU running at 3Ghz, you write it whatever you like)
So.. Ruby, Python, "Dynamic-C#"... these are the future. When MS releases the DLR, expect a lot of interest in it, expect a lot of companies to start talking about programmer productivity as the most important part of most application development.
After that.... probably a GUI-driven system where you connect blocks together in a UML-a-like system and add properties to them that produces generated code.

I believe the answer is twofold.
First, client side applications are more and more implemented as browser based applications. To give a browser based application a look and feel comparable to rich desktop application you need something like Javascript. And if you followed the news a bit you see a tremendous effort towards speeding up the javascript implementation in browsers, and a flourishing ecosystem of libraries which help you create a responsive, intuitive GUI with javascript in a browser.
So, for GUIs I believe the future is Javascript.
For the backend, the server, I very much doubt that the near future has a scripted language in store. Server-side software tends to live for years and years, features added, bugs fixed and all. The language in which that is written needs to be not so much fast to write, but easy to read (maintain).
And scripted languages tend to be a bit more difficult to understand if you revisit your code after a year or two to fix that bug. That has (in my opinion) two primary reasons which will not go away in the short term:
IDEs have trouble giving hints with dynamic languages
In the context your working there is by definition less context information available; in Java you know you can only get type X. In a scripted language you should check all referencing code, not easy in a large project
These problems can be mitigated by using very experienced developers, but if, in the future, the only kind of usefull developer is a experienced one we won't need to hire inexperienced ones, which will give trouble in the future.
For those reasons I believe the next-gen server-side language is statically typed. And from the statically typed languages I think C# and Java have the best chances due to the enormous amount of usefull libraries available and the very readable nature of those languages.

As other have mentioned, languages tend to adapt around new technologies and trends. So in order to answer that question, you first have to look at the overall future of computers and see what languages are most suitable for these purposes.
For example, to use your language progression as an example, in the beginning (:-)) there was a need for a language that would make maximum use of the limited resources available, C fit the bill in that regard. As time went on, and the spectrum of software applications incresed there was a greater demand for OO based languages in order to facilitate software reuse, easier design etc. and C++ / Java became popular.
Currently, there is an increased drift in the industry towards server side components that do all the work with thin client UIs (i.e. browsers). So languages that cater for this demand are becomming more popular (Ruby, ASP/Java EE languages).
New languages will become popular when the technology that they are closest to become popular.
Personally (and this is guesswork), I think there is huge scope for a language that truly takes advantage of multi-core systems. This will mean having multi-threading built from the very start and will probably require a change in approach and thinking (like going from procedural to OO).

It's going on a couple years old now, but Tim Sweeney's The Next Mainstream Programming Language: A Game Developer's Perspective is an interesting cogitation on the subject.

What is the future of programming? Away from languages as we know them.
It's 2009 and we're still using text editors? With the project I'm a part of you can build entire applications simply by setting attributes. Outside of (mainly mathematical) expressions and string values, there's not a line of text anywhere.
One of the developers complained that "you can't print out the code," and I replied, "Would a company print out its entire accounting structure? Or would it print out the aspects it wants to see, such as Cashflow Statements and Balance Sheets?" It's only when we move out into new abstraction mechanisms that we can really move ahead.
The future of programming remains to be seen, but I think there are some exciting developments happening that will finally release us from the C/C++/Java harness we've had on for so long.

At some point programs will start writing their own programs making humans redundant as far as programming is concerned. The major disagreement is when this will happen.

If you follow only this branch of programming language history, I think one can write both JavaScript and C#, since they came after the three you mention, share a similar syntax, and took from the predecessors.
Others might mention D or Objective-C (they are already here, of course).
By next language, I suppose you mean "next successful", because there is almost a new language each month...
I think it will be a language with garbage collection, running on bytecode with Jit, highly portable.
I can't tell if it will be object-oriented or functional, with static or dynamic typing, but I would bet on a mix, like does the interesting Fan Programming Language.
Or maybe we are all wrong, it might just a natural language, with spoken or graphical interface: "Take the weather box of this page, change its color and this logo to that, and integrate in my page".

What would be great, in my opinion, is a language like C++ with a more compact definition, better standard library, native garbage collection, and native synchronization constructs. It should be usable by relative novices, but still provide facilities for experts to program in an efficient, low-level way when needed. I believe D meets most of these criteria, but it seems unlikely to me that it will take hold.

On the short term, I expect high level languages to become more powerful and more used. Perl 6 and Javascript 2.0 are good examples of what awaits us.
On the long term, functional languages might make it into the mainstream, but I expect that will not happen any time soon.

D language, especially the 2.0 version has learnt from Ruby, Python and lots of modern languages without keeping source compatibility with C, still allowing for raw access to the metal. The design decisions of this language are a perfect solution for next-generation system and general programming languages, with even functional programming and metaprogramming built-in.

The language question is in my opinion no either or. It allways depends on your application. And since languages have mostly a standard set of libraries that are well suited for this or that application. Languages are tied somewhat to a particular application field.
For Example:
C -> Device drivers
C++ -> Highperformance Computing
Java -> Server side programs (J2EE)
C# -> Server, Client(Silverlight, WinForm, WPF)
Ruby, Python, ... -> WebScripting (Serverside) and helper scripts
ECMAScript (Javascript) -> WebScripting (Clientside)
I think any of these languages are capable to solve any computing program (also performance wise since we have Jits) but they are not used in any field since it is not feasible to recreate every library for every language.
On thing that makes C and C++ special is, that there is a standard library but compared to the others it is a rather minimalistic standard library. To use those languages efficiently 3rd party (non-standard) libraries are needed.
So when choosing a language for a project you look for these things:
Are there the right libraries you can use in your project
Do you know the language
Is it efficient to programm in this language (look at brainfuck)
Does your team know and master the language?
The last thing is also do you like the language? At the end that is the biggest motivation to use this or that language.
So the next step in language evolution will be higher level libraries and concepts to be faster and more expressive. Examples are
Lambda expressions
Linq (C# feature to do sort of sql in the language)
functional programming
variable typing
dynamic typing
not particular language: better IDEs that assists the programmer
Important: Support for easy! parallelism (Axum, Nesl, orca, Chapel, ... ) Here list