Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I would like to simulate some scenarios using the multiagent
paradigm, and it seems NetLogo and Repast are the most popular tools for that.
I'd like to know if anyone has had any experience with either one and could tell me more about them? For example, I've noticed that there is a fluxogram-like modeling option for Repast, but I believe it is rather limited. I've looked around the tutorials and documentation in the official site, and the documentation seems to be lacking. While there are some examples with it, I'd say extending it to simulate an ambient which it has not been specifically prepared to seems like an unreachable goal at the moment, despite Repast obviously being very robust and apparently able to handle it, given enough familiarity with it.
On the other hand, NetLogo has more examples and overall I've liked it more for its simplicity, but it seems to be more focused on the simulating propagation of diseases or similar models. I've found a programming book teaching Logo, so I figure it'd be easier to get started with it too.
Currently, I am thinking of simulating botnets and IDSes as multiagents. The problem, however, is that I would have to abstract the network and transport layers to an extent to be able to do it, as well as generate traffic between the nodes. Repast is apparently more fitting for this, but given its complexity and lack of documentation I'm thinking of using NetLogo. While there are some examples of NetLogo with traditional applications (ex: Tetris or Pac-Man), I'm not sure about how appropriate it'd be for that.
I have a webpage with a couple dozed netlogo multiagent simulations. I use netlogo for teaching and I have found that, once you get past the learning curve, you can develop simulations amazingly fast. Stuff that would take you 80 man-hours in other so-called agent environments (Jade, Repast, which are really mostly just programming libraries) can be done in 2 hours.
On the other hand, netlogo is not really good for simulations that require immense amount of details, like say simulating a network all the way from TCP/IP to HTTP. That would just require large amounts of code, regardless of programming language, and netlogo currently sucks if your program ends up being more that 10 pages long. Having said that, most people would be amazed at what you can get done in 10 pages of netlogo code.
Short answer: it depends on the programming paradigm or language you want to use, and the design you want for your agents:
If you want a low-entry-high-ceiling language allowing quick prototyping but sophisticated simulations, and are willing to learn a new paradigm (avoiding loops) use NetLogo. Good documentation.
If you want to make a real application to use on highly-parallelized clusters or just want to use Java Groovy or need a specific Java library for your purpose, use Repast or better Repast for High Performance Computing (but avoid ReLogo which is very slow). Mild documentation.
If you want to model cognitive agents (instead of reactive) with FIPA communications, better use Jason or better JaCaMo which supports AgentSpeak + Java (so you can also use your favourite Java libraries), and there's no Groovy required. Bad documentation (a lot of non detailed features and commands and bad too-complex-not-commented examples).
Long answer:
Disclaimer: I am more experienced with NetLogo but I also used Repast and a few others like Jason.
Basically, the difference between NetLogo and Repast is that with NetLogo you will have a simpler framework but you'll need to learn how to program in a turtle-and-patch-oriented paradigm, while in Repast you will have to learn that + the mechanisms behind Java Groovy but you will eventually get more flexibility. Speed isn't really a criteria here (see below).
To be more clear, you can program efficiently in NetLogo if you use to a maximum the turtles and the patchs native functions. For example, if you want to implement A*, instead of implementing a list of nodes, you should directly use the patchs and filter them using stuffs like this:
ask patchs with [criteria1 = value and criteria2 = value2] [do-some-stuff]
ask patchs with-min [criteria][do]
let var [somevalue] of min-one-of patches [criteria]
Also if you can't find a way to efficiently do what you want, be sure to check if maybe an extension exists (check also here under Libraries and Tools) for your purpose, like the now native matrix extension which allowed me to make an efficient neural network in NetLogo.
On the other hand, Repast is potentially more flexible than NetLogo (since you have access to the whole range of Java libraries), but a bit more complex since you have to know how to handle Groovy.
If you are solely interested in speed, do NOT use ReLogo (NetLogo-like syntax for Repast) which has been shown to be a whole lot slower than NetLogo (see the 2012 paper below). In any cases, your best bet would either to try an implementation with NetLogo using the tricks above, or if you want to use your application for real later, there is also a distribution called Repast for High Performance Computing which removes most of the overload that come with turtles and patchs objects, and thus it can be used for real applications. A similar extension exists for NetLogo to compute in clusters with parallelization but it's not an official distribution.
If you want more infos about the diverse platforms, here is a nice review of 2006:
Railsback, S. F., Lytinen, S. L., & Jackson, S. K. (2006). Agent-based Simulation Platforms: Review and Development Recommendations. SIMULATION, 82(9), 609-623.
And an updated version of this paper in 2012 dealing with NetLogo vs ReLogo:
Lytinen, S. L., & Railsback, S. F. (2012, April). The evolution of agent-based simulation platforms: A review of netlogo 5.0 and relogo. In Proceedings of the Fourth International Symposium on Agent-Based Modeling and Simulation.
/EDIT: I cited Jason but didn't give any more details. If you want to model cognitive agents (instead of reactive agents), you can do that in NetLogo using the unofficial BDI extension which works well but is a bit limited (but it's easily extensible since it's pure NetLogo), but your best bet is to use a framework specifically designed to model cognitive agent with full support of AgentSpeak.
Jason is very nice since you have access to a full AgentSpeak language + JAVA to implement the technical side. In fact, you can do whole projects using only AgentSpeak (which I did), but you can also make more Java-oriented versions, it's up to you how you want to design your program, the result will be more or less the same. This offers you a lot of flexibility in your design workflow.
Tip: search for "Jason internal actions" in the documentation to get a good description of the available AgentSpeak commands.
Also if you are interested in Jason, you might be interested in JaCaMo (= Jason + Cartago + Moise) which is the result of a cooperation of three projects authors to make a full-fledged cognitive agents framework which also can model complex environments (with artifacts theory) and multi-agents organisations (roles, groups, missions, etc.).
A last framework I know of but didn't have a chance to try is Mason which supports 2D and 3D environments. Never had a chance to try this one so I don't know how this compares with the others but you can try it out.
Here's a generic comparison.
http://www.duncanrobertson.com/research/AMLE.pdf
I had more or less the same problem a few months ago when I had to choose a framework for my simulation. I look at Repast, NetLogo, Swarm and Jade.
NetLogo was nice and I tried to write some simple test applications but since I wanted to use Java as my programming language, NetLogo wasn't the best candidate. Repast has pretty much everything you need to write larger simulations and there are many projects (especially in social sciences) where Repast is used. My problems with Repasts were: bad API documentation, parameters that are passed to methods or constructers that are never used and don't make any sense at all (have a look at the source code) and a lot of boilerplate code.
I'm using Jade (http://jade.tilab.com/) now and I'm really happy with it. The community is good and their mailing list is VERY active. Okay, Jade is just a library and a framework for agent-based modelling. You don't get anything like those visual editor in Repast and you'll have to write your own tool for visualising the results.
Cheers
You could simulate the traffic using a agent type called "packet" that will be spawned and send from a agent called "bot" to another agent called "bot" or "server". Instead of sending the packets to a IP address, you would be sending them to a pair of X and Y coordinates.
Netlogo has an example of how a virus spreads in a network, this might be a good starting point.
I have never tried NetLogo, but have I tried Repast-J and Simphony. It seems Simphony is good, but at the moment I am stuck at changing the Edge type from straight line to curved one. There is not enough documentation and examples available.
Once I tried Mason which is based on java, too. It is similar to Repast-J, yet it was faster. But recently there is not much development in Mason.
I would like to try out Jade later.
If you can already code in Java, you can also look at the following paper for a comparison between RePast, Swarm, Quicksilver, and VSEit, different freely available programming libraries for support of social scientific agent based computer simulation
Tobias, Robert, and Carole Hofmann. "Evaluation of free Java-libraries for social-scientific agent based simulation." Journal of Artificial Societies and Social Simulation 7.1 (2004).
Repast is definitely more flexible than NetLogo but the documentation is not very detailed for RePast Symphony
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.
I was wondering whether Scala will get the takeup it deserves without explicit corporate backing (I was thinking by Sun/Oracle but I suppose it could be someone else, such as Google).
With Sun's recent decision not to include closures in JDK7, couldn't they put their weight behind Scala as the Java alternative for those wishing to have a more expressive language? After all, it seems to me that they should care most about the JVM, not Java per se. Does anyone think this is likely?
Apart from the examples of previous languages that have succeeded without initial corporate backing, I think Microsoft's promotion of functional programming on the .NET platform may indirectly help Scala gain adoption. Since the Java and .NET ecosystems are seen as close rivals, people aware of F# and the functional additions to C# may be inclined to look for JVM analogs, and to me Scala seems best equipped to fill that role.
You need to be more specific. Thrive in what context?
I think Scala's community is near the critical mass that it needs to be a self-sustainable open source project even if its primary institutional backer, the EPFL, suddenly had a change of heart; and there is currently every sign that it will reach this critical mass. I think Scala will be with us and actively maintained for a long time.
A more pressing issue if the type of uses for which it is suited. The Scala compiler and standard library are far from perfect. When you start pushing the language or a portion of the library there is still a decent chance that you will find bugs. This is improving by leaps and bounds, but it in itself isn't the core of the problem.
The problem is in order to get fixes you pretty much have to upgrade to the next version of Scala as upgrades come out. The problem with that is that most version upgrades contain breaking changes, thus in order to obtain fixes you are likely to have to change your own code. There's also the binary incompatibility problem, which means all your Scala dependencies have to change versions, too.
This could be severe problem if you have a lot of dependencies on other Scala libraries (unlikely - there aren't many yet), if you are subject to severe infrastructure bureaucracy, or worse, you're a product-oriented company that needs to distribute fixes to customer with severe infrastructure bureaucracy.
In order for Scala to be viable in such situations long-term, someone will have to start back porting fixes to earlier versions so that people don't have to perform breaking upgrades just to get some fixes. I'm sure this will happen, because it really wouldn't be that hard, but it will probably require someone seeing a business opportunity, because let's face it, backporting changes and doing regression testing isn't exactly exiting work.
I think Scala will be fine. It has a lot of mind share now that Twitter has partially moved to it. I think it's unlikely Sun will concentrate on anything but Java, but they are probably happy that other languages are targeting the JVM.
I think the closure thing is lame, by the way. I love closures.
I think it will thrive because it doesn't have corporate bozos 'backing' them. I personally like the idea that a language is so independent, and yet very good and well planned and thought out.
I think Google is likely to pick it up, but I don't think it will be an official backing. I'm sure Google will find a cool project to use Scala with.
Corporate backing is only necessary for a language to succeed if it doesn't have a lot of support from working programmers. Perl, Python, and Ruby all grew up without support from the Man (well, Ruby had the Japanese Man, but it wasn't a lot of help in the US).
I've not used Scala, but Twitter's endorsement of it suggests that it has enough programmer support to thrive even without a corporate big brother.
Of course it will survive.
There are bundles of languages lying around, being supported by univerities, working groups, hobbiests, and programmers, up and down the world, and out in the wild. In some cases the fact their not supported by the Man, means they have some chance of survival, perhaps more to do with their cachet or maybe they server an important reserarch aspect.
A friend of mine uses in his company an ERP software written in PowerBuilder. Unfortunately the (one and only) developer is going into retirement soon. My friend really likes the software and wants to keep using it for at least ten more years, so my friend decided to buy the source code.
He wants to start a business to maintain the software and develop new features. At the moment there are probably about 50 installations of that software out in the wild and he already knows of a bunch of potential buyers.
Now he's searching for a developer and asked me... I did a little C/C++ programming, a bit of VB and a bunch of other languages but in the last years I earned my money by writing Java web applications.
From what I read, PowerBuilder looks quite antiquated to me, there are hardly any tutorials out there, no open source frameworks, awkward version control, didn't even read about any test frameworks. People here on StackOverflow say they hope, the language/IDE is dead. Additionally the code I'd maintain is completely undocumented and untested.
Do you think it's possible, for someone who never even heard of PowerBuilder before, to maintain such a software?
EDIT: okay, thanks for your answers. We decided to kick the old application completely and re-write it in an up-to-date-language.
Yes, it's possible. Powerbuilder is not a hard language to pick up, particularly if you have used VB already.
The Powerbuilder community is far smaller than what you may be used to with e.g. Java, but it does exist. The best place (other than SO!) to ask questions are the sybase.public.powerbuilder.* newsgroups.
For unit testing, try PowerUnit, and for source control, you can use Subversion via PBSCCProxy, TamTam SVN SCC, or PushOK SVN SCC proxy.
It's been a niche language for a long time now. In my opinion this is due the upfront cost of the tools required, which is essentially blocking anyone new from considering it.
The future is reasonably bright though: Sybase is flourishing, committed to PowerBuilder, and regularly announcing progress towards version 12, which will be a full .NET language like C# and VB.NET, and will ship with an IDE based on VisualStudio. You will be able to directly migrate your code to version 12, no rewrites required.
I started my career as a PowerBuilder developer, but quickly changed to java and python, as soon as I realized PB was almost a dead language.
Also, even if there are tools that can be used to apply programming "good practices", they are not widely known and somewhat expensive, so I've had to work even without version control (!!), left aside automated testing or continuous integration.
It is a language in which almost anyone can start to build usable apps in a short period of time and with little training, and the apps are built really fast, in contrast with java, that demands a period of learning until a developer can be productive, and even then, a webapp takes time to be developed.
But the payback is with maintenance, that quickly becomes a nightmare. Even a minor change in the database like a type change in a database column can destroy every datawindow (the PB ubiquitous data-access component) that refers to it.
It's pretty much similar to VB, in that as almost anyone can develop applications in it, with very little programming knowledge, the average quality of applications is very low, with unmanageable database coupling and plagued of bad coding practices.
My advice is not to build a Developer career in such kind of language unless the money justifies it, and in that case, continue training yourself in alternative technologies as a "plan b" to not become obsolete along with the language.
And always work to keep your coding and problem solving skills "in good shape" as this kind of language does not help in that.
Yes, any competent programmer, and even some not-so-competent ones can use PowerBuilder. However, I'd disagree somewhat with one of the earlier answers. It is different from pre-.Net VB in one sense: it supports true OO principles (encapsulation, inheritance, and inclusional polymorphism [but not operational polymorphism via Interfaces as in C# and Java]). Classic VB didn't have inheritance.
Other answers from Paul Lefebvre and Colin Pickard are correct: PB is still alive though more of a niche language than it used to be, and Sybase is indeed moving it in the direction of .Net. As for source control, PB supports some interfaces (we use it with VSS) but I'm thankful for Colin's nice set of links, which may come in handy in the future.
Frameworks: the most common one is the PowerBuilder Foundation Class, which Sybase open sourced years ago.
My caveat to you is this: I said above that people didn't have to be particularly strong programmers to write PB. PB is easy to learn but takes time to master. It had its biggest days in the late 90's, when anyone that could double-click on a Windows icon to launch an app thought they were a programmer. Despite truly supporting OO, most PB apps are not well designed and well written apps. They're usually total hack jobs (a criticism of the lack of experienced developers and immaturity of software development at the time, not of PB itself, which is still a very powerful tool). If you are inheriting a code base that is truly easy to maintain and manage, you are in the minority. PB code can nearly always be classified as legacy code. The good news is that there is plenty of challenge. You will have many quick-win refactoring opportunities and plenty of production support.
With the risk of sounding biased I think PB is one of the better RAD tools out there and the new version PB12 scheduled next year will make it once again interesting since it uses the VSShell from Visual studio as its new IDE (Intellisense etc). I am currently busy working in the compiler team adding all the .NET goodies to PowerScript that one is used to from C# like delegates, interfaces, attributes etc but still keeping the language simple to use. PB is also one of the few development platforms that provide migration from older to newer versions and the new PB12 is no exception. The applications generated by PB12 will be modern looking using WPF and later Silverlight for post PB12 so I am quite excited. I am not a PB developer per se (C++) but I still think for producing C/S apps fast its hard to beat.
It depends on the technical quality of the original application whether migrate to another language is feasible at all.
BEFORE YOU READ MY "PB IS GOOOD": I'm a PowerBuilder developer since '93. PowerBuilder is very much alive and kicking. Yes a lot of people left the language shortly after the millenium but quite a few have returned later. No I don't earn money selling PB!
The biggest differentiator between PowerBuilder applications and any other tool is the DataWindow technology. It is such a strong tool in the hands of an knowledgeable developer. Examples: Dynamic creation of optimal SQL for INSERT/UPDATE/DELETE. Close to every property of everything can be an expression using data in the DW buffers. DropDown DWs are so cool. DW and the rest of PB is truly DBMS independent!
How important is code completion when many of my DataWindows only need 4 function calls anyway?
Define DB connection >> dwData.SetTransObject(SQLCA)
Read all data from DB >> dwData.Retrieve()
Write data to DB >> dwData.Update(true, false)
Reset when committed >> dwData.ResetUpdate( )
My bet: If the original developers knew how to really exploit DataWindows - any estimates you make on migration to Java or C# will not even come close to what will actually happen. If they didn't: The application is just another application that does data binding differently than your new tool.
What you loose when using PowerBuilder? You need to accept that the 4GL and its VM are designed as they are - no access to the source code of the VM so you can't make your own VM customizations. No turning off the NULL support to increase speed. No changing the event order by rewriting the VM's event manager. 4GL means less lines of code. DataWindow means a lot less LOC. 4GL means less geaky bit tweaking.
/MicKr-
BTW: PocketBuilder is PB for Windows Mobile - cool idea!
Yes, you would certainly be able to learn PowerBuilder. Whether you want to is a question only you can answer, though.
I used PowerBuilder for many, many years (versions 4 through 9). There were parts I truly liked. It's a great way to build business applications. It's object-oriented and the DataWindow is a wonderful technology.
But it has its bad points as well. The IDE is archaic. The code editor is simplistic (no code completion, for example). Integration with source control is annoying and the community is pretty small. And it's Windows-only.
There is a magazine (PowerBuilder Developer's Journal - SYSCON), but it's pretty thin these days. Sybase does appear to have some neat things up their sleeves for future versions of PowerBuilder, however.
Personally, I liked it enough that I would go back to it if an opportunity arose.
I worked on powerbuilder quite sometime back, version 6.5
Its quite easy to use and one can compare it to VB.
I feel it would be quite easy to maintain an application and do small fixes and enhance the system.
There are quite a few companies that still use powerbuilder and maintain old application.
Powerbuilder is very easy, and you will find datawindows objects very helpfull to make reports, interfaces, forms, etc..
If you know visual basic, it will be easier
i learned powerbuilder in 2 months.
A disadvantage of powerbuilder is the cost per license.
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.