Related
I am making a proposal for a Python adapter to the Oracle NoSQL Database. The Oracle NoSQL Database runs as a stand alone java application, and at least in a Java program, you interface with it by telling your program the hostname and port to connect to, and some configuration settings. Then you make java calls off of the "kvstore" object that contains that configuration.
I'd like to make a Python library that essentially exposes Python versions of the java methods Oracle NoSQL has, and converts those to Java to speak with the running Oracle NoSQL application, but I'm not sure what technologies would be best to be able to do that.
Does anyone know what technology I would want to use? I'd rather not use Jython (so the application could run in a standard Python environment) or JNI (as it seems to have some nasty caveats.)
EDIT: The only potentially technology I've found so far is: Jpype
Would it work for me?
Also, here are the ideal requirements the library would have. I would consider using Jython or JNI if one of them really did best match these requirements.
Performance. The main benefits of Oracle NoSQL are performance and scalability, so that would be the most important component for the adapter.
Easy to implement for the Python users. In order for the library to actually be used by Python programmers, it would have to relatively easy for them to use in a natural sort of way.
Reliability. It would need to be possible for it to be trustworthy and bug free, while working on the platforms you naturally expect Python to work on. (This is what made me concerned about JNI. It sounds like it is platform dependent for its implementation, and can be error-prone.)
Development speed. The last point of importance is that it be relatively fast to develop. The team of developers would enjoy learning Python or C, but we know Java better than any other programming langauge right now.
I've tried to answer each point in order, with it's own related notes.
Performance: My opinion is that JNI would be the winner here, but I could be wrong, because Jython could be JITed as well.
Easy to Implement: I am taking this as you mean easy to consume the library? That would depend entirely on how you build the API, 1 to 1 method calls, object handles, etc.
Reliability: Jython is the clear winner here, because there is no room for error when you merely instantiate POJOs/ directly access the API right in the client code.
Development Speed: JNI can be very tedious. You are essentially learning CPython modules, C, Python extensions, JNI and then referencing an existing API built in Java.
All in all, if you can make the jump, I think you'd get more benefit in the short term embedding Jython, mostly because there you can directly manipulate the API. I have personally embedded IronPython in a .NET codebase with good success. Yes you lose native speed, but the tradeoffs are hard to justify with the amount of C coding needed for a working JNI bridge. That said, you may well find projects like the one you listed (Jpype) that can do much of the legwork for you.
I would be asking what features of a native CPython runtime I need that you lose when going to Jython. Is your existing codebase in CPython heavily reliant on CPython native features?
Anyway, there's my attempt at an answer.
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 2 years ago.
Improve this question
Our company is starting the development of a client-server application and a discussion is going on about which technologies should be used.
For the client (GUI) side we tend to QT and C++. For the server side, we have been advised to use Java and indeed it looks like it is one of the languages being used most for server development.
Can anyone elaborate on the advantages offered by Java for server side development and why adopting it should make our life as developers easier and/or allow us to reach better results than if we used, let´s say, .NET or even C++?
Thanks in advance.
Some advantages:
Run compiled code across platforms.
Managed memory (garbage collection).
Hude wealth of excellent open-source libaries.
Large developer market.
Easy migration for C++ developers.
Some disadvantages:
Aging language — has not kept up with language advances IMO (e.g. adding functional facilities).
Future uncertain after Oracle aquistion (will become clearer with time).
Low level programming difficult.
You may want to look also at other languages which run on the JVM, such as Scala and Groovy, at .NET (it can run on Linux et al using Mono) and even the D language, which provides a C++ like, compiled to native, language with modern features such as garbage collection (optional), code contracts, lambdas etc. These languages provide many of the benefits of Java over C/C++ but have also taken the progression a bit further or in different directions.
Apart from platform independence, the main advantage of server-side Java development is the wide selection of mature libraries and standardized frameworks. However, the main focus here is on web development.
For a C++ client, Java could still be beneficial if you use REST as protocol between client and server (JAX-RS is pretty nice). Otherwise, it depends very much on your application domain and whether there are Java libraries that could help you in that regard.
Let's put it this way... it's not which server-side language is better and what not, it is what's available in your company that you can leverage of and make good use of it. When you work in a big corporation, sometimes you cannot just introduce "yet another language"... it doesn't work that way. :)
Further, every language has its pros and cons. You can almost argue the pros/cons in both way depending on how biased or open-minded you are. You can choose RoR and all that bleeding age technologies, but if your team members are not comfortable in dealing a brand new language, how exactly are you going to maintain the project in long run? I mean, if your team is familiar with PHP, I don't see anything wrong using that compared to Java, .NET, etc.
Your customers don't care the underlying implementation as long as it works.
Java advantages:
- mature
- good to excellent backward compatibility
- wide range of available frameworks for almost any problem
- robust - garbage collection, APIs as java.util.concurrent
- great tools to manage code quality, good IDEs etc.
- very good performance
- support for scripting
disadvantages:
- sometimes too many frameworks for the same thing
- not all the frameworks have as good quality of code as you need
- looks easier than really it is
You have many options in server side. Since you have the control over server side you can basically use anything. Using .NET forces you to use Windows Server so i will prefer a framework that can run on any operating system and is portable.
Java was the right answer 5-10 years ago. Because it had portability, and can work on any system. But these days developers look for languages/frameworks that are easier to use, maintain and code. I will vote on Python these days for server side development because of this, its fast it easier to read and maintain code wise, and it has many open source projects/libraries that you can use, even Google is favoring python over Java(GAE had python support first, then support for Java came). You can use django on python for web development and twisted for writing a server that uses TCP to communicate.
There are several issues you need taken in accout to select the language:
which are the languages which know your team best / good enougth
which are the languages which know the team thet must maintain the server
are there the right frameworks with an quality that makes you want to use them
will the code be maintainable as long as the server is in production
how fast will be the development -- the importent thing here is not the time you spend to type the code - more important is the time that you need until the product works stable enougth to use it for production without reasonable bugs
communication with other systems - if every system you need to communicate with is an .net - that it would be wise to build the new system in .net too
are there any constraints (must use this server, open source policy of your company, ...)
cost of licences, ...
...
At least the descicion to use a specific language for an project with a reasonable size, is always the question of cost. But not only the cost to build the system, also the cost to maintain it. - The points mentioned above are all cost related: for example: if you do not knwo the language you are slower (-> $), if the system can not be maintained, it must be rebuiled (-> $), if there are not the right libs, you need to implemnt it by your own (-> $), if the language you picked make it easy for bugs to hide, you need a long time until the system can go in production (-> $)
In MHO, the advantages of Java are: the wide spread knowlege (this is for .net too), a huge amount of realy mature open source framworks (this is the point for Java against .net), and the usage of a strong typed system and a compiler wich result in less bugs is a long term advantage of Java and .net over every not strong typed scripting language)
One must have for all languages you use on a Server is an Garbage collection!
Currently Google App Engine supports both Python & Java. Java support is less mature. However, Java seems to have a longer list of libraries and especially support for Java bytecode regardless of the languages used to write that code. Which language will give better performance and more power? Please advise. Thank you!
Edit:
http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1
Edit:
By "power" I mean better expandability and inclusion of available libraries outside the framework. Python allows only pure Python libraries, though.
I'm biased (being a Python expert but pretty rusty in Java) but I think the Python runtime of GAE is currently more advanced and better developed than the Java runtime -- the former has had one extra year to develop and mature, after all.
How things will proceed going forward is of course hard to predict -- demand is probably stronger on the Java side (especially since it's not just about Java, but other languages perched on top of the JVM too, so it's THE way to run e.g. PHP or Ruby code on App Engine); the Python App Engine team however does have the advantage of having on board Guido van Rossum, the inventor of Python and an amazingly strong engineer.
In terms of flexibility, the Java engine, as already mentioned, does offer the possibility of running JVM bytecode made by different languages, not just Java -- if you're in a multi-language shop that's a pretty large positive. Vice versa, if you loathe Javascript but must execute some code in the user's browser, Java's GWT (generating the Javascript for you from your Java-level coding) is far richer and more advanced than Python-side alternatives (in practice, if you choose Python, you'll be writing some JS yourself for this purpose, while if you choose Java GWT is a usable alternative if you loathe writing JS).
In terms of libraries it's pretty much a wash -- the JVM is restricted enough (no threads, no custom class loaders, no JNI, no relational DB) to hamper the simple reuse of existing Java libraries as much, or more, than existing Python libraries are similarly hampered by the similar restrictions on the Python runtime.
In terms of performance, I think it's a wash, though you should benchmark on tasks of your own -- don't rely on the performance of highly optimized JIT-based JVM implementations discounting their large startup times and memory footprints, because the app engine environment is very different (startup costs will be paid often, as instances of your app are started, stopped, moved to different hosts, etc, all trasparently to you -- such events are typically much cheaper with Python runtime environments than with JVMs).
The XPath/XSLT situation (to be euphemistic...) is not exactly perfect on either side, sigh, though I think it may be a tad less bad in the JVM (where, apparently, substantial subsets of Saxon can be made to run, with some care). I think it's worth opening issues on the Appengine Issues page with XPath and XSLT in their titles -- right now there are only issues asking for specific libraries, and that's myopic: I don't really care HOW a good XPath/XSLT is implemented, for Python and/or for Java, as long as I get to use it. (Specific libraries may ease migration of existing code, but that's less important than being able to perform such tasks as "rapidly apply XSLT transformation" in SOME way!-). I know I'd star such an issue if well phrased (especially in a language-independent way).
Last but not least: remember that you can have different version of your app (using the same datastore) some of which are implemented with the Python runtime, some with the Java runtime, and you can access versions that differ from the "default/active" one with explicit URLs. So you could have both Python and Java code (in different versions of your app) use and modify the same data store, granting you even more flexibility (though only one will have the "nice" URL such as foobar.appspot.com -- which is probably important only for access by interactive users on browsers, I imagine;-).
Watch this app for changes in Python and Java performance:
http://gaejava.appspot.com/
(edit: apologies, link is broken now. But following para still applied when I saw it running last)
Currently, Python and using the low-level API in Java are faster than JDO on Java, for this simple test. At least if the underlying engine changes, that app should reflect performance changes.
Based on experience with running these VMs on other platforms, I'd say that you'll probably get more raw performance out of Java than Python. Don't underestimate Python's selling points, however: The Python language is much more productive in terms of lines of code - the general agreement is that Python requires a third of the code of an equivalent Java program, while remaining as or more readable. This benefit is multiplied by the ability to run code immediately without an explicit compile step.
With regards to available libraries, you'll find that much of the extensive Python runtime library works out of the box (as does Java's). The popular Django Web framework (http://www.djangoproject.com/) is also supported on AppEngine.
With regards to 'power', it's difficult to know what you mean, but Python is used in many different domains, especially the Web: YouTube is written in Python, as is Sourceforge (as of last week).
June 2013: This video is a very good answer by a google engineer:
http://www.youtube.com/watch?v=tLriM2krw2E
TLDR; is:
Pick the language that you and your team is most productive with
If you want to build something for production: Java or Python (not Go)
If you have a big team and a complex code base: Java (because of static code analysis and refactoring)
Small teams that iterate quickly: Python (although Java is also okay)
An important question to consider in deciding between Python and Java is how you will use the datastore in each language (and most other angles to the original question have already been covered quite well in this topic).
For Java, the standard method is to use JDO or JPA. These are great for portability but are not very well suited to the datastore.
A low-level API is available but this is too low level for day-to-day use - it is more suitable for building 3rd party libraries.
For Python there is an API designed specifically to provide applications with easy but powerful access to the datastore. It is great except that it is not portable so it locks you into GAE.
Fortunately, there are solutions being developed for the weaknesses listed for both languages.
For Java, the low-level API is being used to develop persistence libraries that are much better suited to the datastore then JDO/JPA (IMO). Examples include the Siena project, and Objectify.
I've recently started using Objectify and am finding it to be very easy to use and well suited to the datastore, and its growing popularity has translated into good support. For example, Objectify is officially supported by Google's new Cloud Endpoints service. On the other hand, Objectify only works with the datastore, while Siena is 'inspired' by the datastore but is designed to work with a variety of both SQL databases and NoSQL datastores.
For Python, there are efforts being made to allow the use of the Python GAE datastore API off of the GAE. One example is the SQLite backend that Google released for use with the SDK, but I doubt they intend this to grow into something production ready. The TyphoonAE project probably has more potential, but I don't think it is production ready yet either (correct me if I am wrong).
If anyone has experience with any of these alternatives or knows of others, please add them in a comment. Personally, I really like the GAE datastore - I find it to be a considerable improvement over the AWS SimpleDB - so I wish for the success of these efforts to alleviate some of the issues in using it.
I'm strongly recommending Java for GAE and here's why:
Performance: Java is potentially faster then Python.
Python development is under pressure of a lack of third-party libraries. For example, there is no XSLT for Python/GAE at all. Almost all Python libraries are C bindings (and those are unsupported by GAE).
Memcache API: Java SDK have more interesting abilities than Python SDK.
Datastore API: JDO is very slow, but native Java datastore API is very fast and easy.
I'm using Java/GAE in development right now.
As you've identified, using a JVM doesn't restrict you to using the Java language. A list of JVM languages and links can be found here. However, the Google App Engine does restrict the set of classes you can use from the normal Java SE set, and you will want to investigate if any of these implementations can be used on the app engine.
EDIT: I see you've found such a list
I can't comment on the performance of Python. However, the JVM is a very powerful platform performance-wise, given its ability to dynamically compile and optimise code during the run time.
Ultimately performance will depend on what your application does, and how you code it. In the absence of further info, I think it's not possible to give any more pointers in this area.
I've been amazed at how clean, straightforward, and problem free the Python/Django SDK is. However I started running into situations where I needed to start doing more JavaScript and thought I might want to take advantage of the GWT and other Java utilities. I've gotten just half way through the GAE Java tutorial, and have had one problem after another: Eclipse configuration issues, JRE versionitis, the mind-numbing complexity of Java, and a confusing and possibly broken tutorial. Checking out this site and others linked from here clinched it for me. I'm going back to Python, and I'll look into Pyjamas to help with my JavaScript challenges.
I'm a little late to the conversation, but here are my two cents. I really had a hard time choosing between Python and Java, since I am well versed in both languages. As we all know, there are advantages and disadvantages for both, and you have to take in account your requirements and the frameworks that work best for your project.
As I usually do in this type of dilemmas, I look for numbers to support my decision. I decided to go with Python for many reasons, but in my case, there was one plot that was the tipping point. If you search "Google App Engine" in GitHub as of September 2014, you will find the following figure:
There could be many biases in these numbers, but overall, there are three times more GAE Python repositories than GAE Java repositories. Not only that, but if you list the projects by the "number of stars" you will see that a majority of the Python projects appear at the top (you have to take in account that Python has been around longer). To me, this makes a strong case for Python because I take in account community adoption & support, documentation, and availability of open-source projects.
It's a good question, and I think many of the responses have given good view points of pros and cons on both sides of the fence. I've tried both Python and JVM-based AppEngine (in my case I was using Gaelyk which is a Groovy application framework built for AppEngine). When it comes to performance on the platform, one thing I hadn't considered until it was staring me in the face is the implication of "Loading Requests" that occur on the Java side of the fence. When using Groovy these loading requests are a killer.
I put a post together on the topic (http://distractable.net/coding/google-appengine-java-vs-python-performance-comparison/) and I'm hoping to find a way of working around the problem, but if not I think I'll be going back to a Python + Django combination until cold starting java requests has less of an impact.
Based on how much I hear Java people complain about AppEngine compared to Python users, I would say Python is much less stressful to use.
There's also project Unladen Swallow, which is apparently Google-funded if not Google-owned. They're trying to implement a LLVM-based backend for Python 2.6.1 bytecode, so they can use a JIT and various nice native code/GC/multi-core optimisations. (Nice quote: "We aspire to do no original work, instead using as much of the last 30 years of research as possible.") They're looking for a 5x speed-up to CPython.
Of course this doesn't answer your immediate question, but points towards a "closing of the gap" (if any) in the future (hopefully).
The beauty of python nowdays is how well it communicates with other languages. For instance you can have both python and java on the same table with Jython. Of course jython even though it fully supports java libraries it does not support fully python libraries. But its an ideal solution if you want to mess with Java Libraries. It even allows you to mix it with Java code with no extra coding.
But even python itself has made some steps forwared. See ctypes for example, near C speed , direct accees to C libraries all of this without leaving the comfort of python coding. Cython goes one step further , allowing to mix c code with python code with ease, or even if you dont want to mess with c or c++ , you can still code in python but use statically type variables making your python programms as fast as C apps. Cython is both used and supported by google by the way.
Yesterday I even found tools for python to inline C or even Assembly (see CorePy) , you cant get any more powerful than that.
Python is surely a very mature language, not only standing on itself , but able to coooperate with any other language with easy. I think that is what makes python an ideal solution even in a very advanced and demanding scenarios.
With python you can have acess to C/C++ ,Java , .NET and many other libraries with almost zero additional coding giving you also a language that minimises, simplifies and beautifies coding. Its a very tempting language.
Gone with Python even though GWT seems a perfect match for the kind of an app I'm developing. JPA is pretty messed up on GAE (e.g. no #Embeddable and other obscure non-documented limitations). Having spent a week, I can tell that Java just doesn't feel right on GAE at the moment.
One think to take into account are the frameworks you intend yo use. Not all frameworks on Java side are well suited for applications running on App Engine, which is somewhat different than traditional Java app servers.
One thing to consider is the application startup time. With traditional Java web apps you don't really need to think about this. The application starts and then it just runs. Doesn't really matter if the startup takes 5 seconds or couple of minutes. With App Engine you might end up in a situation where the application is only started when a request comes in. This means the user is waiting while your application boots up. New GAE features like reserved instances help here, but check first.
Another thing are the different limitations GAE psoes on Java. Not all frameworks are happy with the limitations on what classes you can use or the fact that threads are not allowed or that you can't access local filesystem. These issues are probably easy to find out by just googling about GAE compatibility.
I've also seen some people complaining about issues with session size on modern UI frameworks (Wicket, namely). In general these frameworks tend to do certain trade-offs in order to make development fun, fast and easy. Sometimes this may lead to conflicts with the App Engine limitations.
I initially started developing working on GAE with Java, but then switched to Python because of these reasons. My personal feeling is that Python is a better choice for App Engine development. I think Java is more "at home" for example on Amazon's Elastic Beanstalk.
BUT with App Engine things are changing very rapidly. GAE is changing itself and as it becomes more popular, the frameworks are also changing to work around its limitations.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Why would you choose java over others? Why did you choose java to program your application?
Please include what you are using java for (desktop application/ web application/ mobile).
Excellent tooling: IDE, CI, etc.
Vast array of 3rd party libraries.
Huge amount of documentation available.
Large pool of developers available.
Platform ubiquitous.
Excellent performance.
Excellent specification.
Sturdy garbage collection.
Managed memory.
Native threads.
Choice - implemented by multiple vendors.
I have used Java to build various middle-ware products: Inventory mgmt; CMS; chemical registration; etc.
One of the nice things about Java is that everyone knows it. Of course, now that I've said that, I'll get 80 comments from people claiming to have never learned the language. Be that as it may...
Like it or not, Java is the closest thing to a lingua franca (the idiom means "common language") we have in the industry today. Just about every has either used Java at some point, or (more commonly) is actively using it now. That sort of ubiquity can be extremely attractive to some companies, particularly those reliant on consultants. If you start a project in Java, you're pretty much guaranteed to be able to find talent to maintain the code base for years down the road.
On a different tack, Java is an excellent language for developing cross-platform desktop applications...it's just that nobody knows it. Most of Java's dominance is on the server side coupled with a little bit of love from the J2ME crowd. However, if you objectively consider Swing in Java 6uN, it's hard to find a better tool for the job. Don't get me wrong, I see that it has its flaws, but many of those have been fixed in recent releases. Most of the issue now is mindshare: everybody knows that Java is slow and ugly (neither of which is strictly true anymore). The other problem is that Swing is very much a cross-platform UI toolkit. This means that it is inherently much harder to create professional UIs in Swing than in Cocoa or even WinForms.
Finally, a really great reason to pick Java (as opposed to .NET or Objective-C) is the ecosystem. Other answers have mentioned libraries, which really deserve a significant spotlight; but I'm thinking specifically of the rising language diversity. If you write an application in Java today, you can seamlessly transition to Scala at any time. You also have the option to do scripting in Groovy or JRuby, not to mention taking advantage of the powerful concurrency abstractions in Clojure. Because of its portability and high-level nature, the JVM is increasingly the preferred target for language compilers and interpreters (even more than the CLR). Java is really at the center of that nexus, not really benefiting directly from the vast cloud of languages which swarm around it, but certainly deriving value from all of the interoperability, present and future.
My reasons for prefering Java over other programming languages at this time are:
price - it's free
performance - really fast these days thanks to the HotSpot JIT compiler
effectiveness - lots of power with rigorous features like type-safe, sand-boxed, etc.
OOP capability
very good, well-thought out exception handliing; C++ exceptions are the opposite!
portability - it runs on almost everything
tool availability - awesome IDEs like Eclipse & NetBeans are free, as are web servers like Tomcat and application servers (JBoss, Glassfish, Geronimo, etc.)
flexibility - does graphics, desktop GUIs, web user interfaces - all kinds of things in all kinds of runtime environments
aptness - many enterprise apps today have to support HTML, SQL, and XML - Java has good support for all of them built in and you can get third-party libraries for free that make this even easier/better
well-supported - Sun keeps adding improvements and fixing thing going one or two versions back
forward compatibility - unlike something like VB which undergoes wrenching change in its syntax every couple versions or so, Java's syntax and semantics seem about 99.9% upward compatible from version to version
I have been writing programs in Java for over a decade and I am pretty satisfied with it. I have used other languages for almost two decades before that. So I am not biased by describing the one thing I know - it is one of many languages I know intimately.
When upgrades to the JDK/JRE come out, I look the documentation over to see what is changed. Sun is good about telling/explaining this. I have never had an extremely rough time porting from one JDK to the next.
When I have switched from one OS to another as my main OS at home or at work, it has not caused a problem for the Java applications I write - or the tools I use, generally. The one exception is Borland JBuilder, which some Borland marketing or technical genius decided to frequently stop supporting. Eclipse and Netbeans run terrifically on the Mac and probably always will. I have used Java on:
MS-Windows 95, 98, NT4, 2000, XP
Sun Solaris/SunOS Unix
IBM AIX
Mac OS X
Linux
Motorola cell phones (MIDP, CLDC)
Palm Pilot PDA
Java VMs (virtual machines) are everywhere! They are in:
web browsers
cell phones
PDAs
desktop computers
web servers
application servers
I have written programs on all of these. All you have to do is get an IDE with the right plugins, get the API documentation for the target environment you want, and start programming.
The GUI programs I write actually do look & work correctly on different platforms! I cannot tell you how long other vendors promised to do and how often/long they have failed. Just look around, some still exist.
Sun promised this in Java 1.0 and they sort of delivered it with AWT. However, the abstract windowing toolkit used native GUI components and the differences between these components (which followed no unifying standard at all) were too great to get same/nice look/behavior on all platforms.
Sun delivered very well upon this portable GUI promise when the Swing GUI API was delivered a decade ago, back in December 1998.
1) Very good and free documentation
2) Very good developer commercial and free tools
3) good certification and training resources
4) good runtime and free tools
5) good profiling and monitoring tools
6) very good support options from various companies
7) very good open source community with huge amount of libraries
Things not yet mentioned:
Cross-platform Desktop Application, even with sophisticated GUI
bunch of tools
static typing (see GWT)
error messages at compile time
very clear error messages
Java provides a very rich API right out of the box and hands-down produces the most portable applications since there is a Java VM for almost every platform.
BTW: I haven't used Java since I left college since I work for a Microsoft shop, but I can't think of a single thing I can do in C# that I can't do in Java, whether it be enterprise applications, web applications, or desktop applications.
Portability is the key to java. I know that a program that i am coding will run on any system, there is no need to create different releases for different OS's.
Java also offers built in security, making the coding of the safe programs easier.
Java is fast, with clean code java is benchmarking in the same range as C++.
C# is the language that gets compared to java the most often. C# isn't as portable as java, and has very few features that java doesn't. This makes java much more attractive unless the program will ONLY be run on a single OS, in that case i might code it in C++.
I switched from years of C++ to Java because I was working on higher level stuff and needed the benefits of memory management, reflection, and sandboxed execution that I get with Java.
I have tried COM in the late nineties and could not touch it.
.NET looks promising and in many ways is now much better than Java. Unfortunately, being window-centric is a complete dealbreaker for me.
Another benefit is the awesome static analysis tools available e.g. FindBugs. These perform a lot of checking on your code above and beyond those performed by the compiler, and can help identify bugs and/or code smells before testing begins.
Lots of great reasons have already been mentioned. I'd like to add the political part. I trust Suns language a lot more than Microsoft alternatives. It's not because I hate Microsoft, it's just that Sun is going a direction with Java that I really like, and Microsoft is going a direction with .net etc. that I really don't like.
This is very subjective, I know. But to me it seems like Sun really want to create a great language, and try to make money somehow. While Microsoft seems more interested in making money by vendor lock-in and systems that looks great and feels great, but may not be as good as it looks in the long run.
So the way Microsoft is handling it right now, I don't even care about how good or bad it is, technically. I don't care, I'm not going to use it.
Java has everything I want from this kind of programming language, including all the boring political stuff most people just skip. I don't know about any other current language that has all that.
The main reason I use Java for most of my desktop app projects is for cross-platform compatibility. It's quite easy to make your app run on OS X, Windows, and Linux and look native on all platforms.
I use Java for our BPM platform and used Java in the past for enterprise web apps.
It depends on what you want to do. Considering language features, libraries available and IDE experience, I personally would choose C# over Java. C# 3.0 has many useful features that Java lacks, such as LINQ, Lambda expressions, etc. Some people prefer the huge library choice that is available for Java, but I think there are just too many ways of doing things. Java IDEs like Eclipse and NetBeans are getting better, but I think Visual Studio is still much easier to work with.
Of course,if you are not using Windows, you don't have much of a choice but to choose Java. Ruby and Python can be good options for things like utility apps and GUIs, including Web apps, but for enterprise apps that don't use Windows, Java is pretty much the only option.
Please don't follow blindly all java-entousiasts. Java has its own flaws. Java is great for rapid development, enterprise oriented stuff, and "high productivity" project (with the tons of projects, community,...).
And if one guy show me a benchmark highlighting how java code can be as optimal as C stuff doesn't mean the complete java solution is fast and lightweight.
Java will never find its way on some performance critical applications, like games, codecs, web browser. No major game software is developed in java, and not because the developper are not capable of writing one piece of Java code that has the same speed as C or C++, this is because the very limitations of the language involves that performance and memory consuption will never reach a good C/C++ code. Takes VisualStudio and Eclipse. Java is great for one stuff (productivity stuff, enterprise middleware), but if you want to write codecs, games, performance critical libraries, you'd better try knowing C.
But, one the other hand, you'll write the java code faster and safer, with C and C++ you're taking more risk (pointers!) and this takes usually more time.
And don't forget the joke "Write once, Debug everywhere", this is actually true. You have to deal with different JVM implementation nightmare with Java.
Other programming language have their interest, bash/python scripts for local scripts (repetitive action, fast and quick UI,...). Php or ruby for webapplication are very well deployed and documented on the web.
Using it for desktop applications.
Excellent IDEs available, wonderful API, "C-style" syntax makes it easy to pickup. Once the JVM starts, the performance is great.
Why would I choose Java - is it the most popular language out there right now? If not, it's gotta be damn close, so if I'm building a product I might choose this because it would be the easiest to hire developers for.
Why did I choose Java - because it's what I know best.
Why would I choose Java? If I happened to have a team of replaceable code monkeys developers that knew Java better than anything else, that is probably what I'd go with.
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