We Keep Coding

Google App Engine - Go vs. Python recommendations? [closed]

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.
I'm looking into writing my first application of Google App Engine. C# is my 'native' language, and so writing the app in Java would of course be most logical. BUT, I'm a geek and would like to take to opportunity to learn something new.
Therefore its a toss-up between Python and Go.
Do you have a strong preference based on experience (ideally in the context of writing on App Engine).
If you've come from C# (or another similar language), how was the transition?

The recently-released Go runtime for App Engine is labelled experimental for a reason: Both Go and Go-on-appengine are new and in a state of change.
If you want to experiment with Go and running Go apps in the cloud, go for it. If you want to write a production app on App Engine, use Python or Java.

This question is about as subjective as they come, but I'll bite anyway.
Python is easier to learn, has a much larger development community, is mature, and has a lot of third-party libraries available for you to integrate into your application. It's a winner for sure.
That said, Go is an extremely well-designed language. Far, far more so than Python. Go was specifically designed to allow you to catch most mistakes at compile time, while Python is almost legendary for its ability to mask your mistakes. Go code tends to be easier to maintain. Go is also dramatically more efficient than Python -- several times faster or even several orders of magnitude faster, depending on what you're doing.
Both languages are very powerful and very fast to write code in -- you can accomplish a lot in a short amount of space. But Go is unfinished and still in a state of flux, with core APIs still changing. It has a comparatively small developer base, and very few "real world" usage examples. Nonetheless, even this early in its development, it's already shown to be a compelling alternative with a clear use case.

I did a Python app for GAE recently and coming from C# I had no problems/was able to pick it up in a few days tinkering with the docs and playing with the SDK (I had some previous experience with python).
Python is pretty intuitive, it's imperative and OO, might require a slight change in thinking from C# but nothing revolutionary - using the interactive interpreter will allow you to pick it up in a day IMO.
Learning how to use the datastore and figuring out other GAE specific API's (blobstore, image, mail) will probably be more work (it's specifics like transactions/groups, consistency modes ...) but you can figure that stuff out as you go/when you need it in your app.
One thing to note - recently announced pricing scheme makes Python a bad choice on GAE ATM because it cannot handle requests currently and this leads to one "instance" per request. This is also true for Go ATM (as far as I know). JVM OTOH can handle ~20 simultaneous requests per instance if I remember the mailing list conversations correctly. And you will be paying per instance/hour. This makes JVM the most practical choice if you plan on publishing your application in the near future.
Also using JVM you could use Scala (a new/cool language) and a framework like Lift which should theoretically allow you to port your code/avoid lock-in (disclaimer : I say theoretically because I'm only starting out with Scala and have no practical experience with Lift).
So I would recommend to look around the mailing list and see what other people are saying about the recent changes.

Personally I would prefer Python because is much, much more mature than Go.
In the past, I learnt, the hard way, what are the risks of choosing a not-so-mature technology.
Warning, I am biased to recommend Python because I like it but you should also be careful because I heard many complains about how much support does Google put on Python-App-Engine. People are asking for years to upgrade Python support and nobody hears them.
These being said, probably Java would be a smarter choice, especially because you are used to C#.

Go is still experimental on the GAE - so maybe not the best platform to learn a new language. Python is definitely a good choice.
Considering a new language do not forget that by choosing Java you get the JVM which allows not only Java code but also oder languages like: Scala, Grails, Clojure, JRuby any many others.

Python is since long supported on GAE - lots of tested information, infrastructure, etc. Go is new to GAE.
I would decide more on the language level. Coming from C#, choosing Python you go a bit more "high-level", whereas choosing Go goes more into the "low-level" direction. More low-level control, but also more concern about that. Choose Python if your interest is on application development, and Go if it's more about systems development. One important aspect for me would be that Go has actor-style concurrency built in, though I don't know how well supported this on GAE will be.

Should I move from Java programming to Delphi programming? [closed]

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 12 years ago.
over the years i have been employed in a permanent position with firms that did their development work in Windows SDK, VC++, and most recently Java; in my own eyes, I am language independent.
Should I move from Java to Delphi (assuming pay-scale remains unchanged)?
I'm concerned because, for the most part, the net presents a relatively bleak picture for this particular skill.

The TIOBE Index is an often cited source for estimating the popularity of programming languages. Java, C and C++ have been the top 3 for a very long time. As you can see, Delphi is a lot lower on the list (at position 10 at this moment). (Ofcourse you should not take the TIOBE Index as an absolute measure, but it does indicate something).
This can be an advantage as well as a disadvantage. There are probably a lot more Java and C++ jobs than there are Delphi jobs, but there are also a lot more Java and C++ programmers than Delphi programmers, so it's harder to stand out as a Java or C++ programmer among the masses. Having a specialism that not many people have, such as for example Delphi, may help you get a higher salary, though you'll have to search harder to find Delphi jobs.

Depends on what your goals are, but I believe that for regular apps the future bears name "GWT", i.e. Java. (I consider Delphi a history for quite a while, but that's JMO.)

It's definitely worth learning Delphi. A lot of software's still being written in it, stuff which people use and rely on. A lot of companies prefer to keep quiet about it, though, since it presents such a major competitive advantage over other, more popular languages.
For example, you ever work with VOIP on chat programs? In my experience, there are two basic categories: Skype, and The Other Stuff. Skype "just works", while the others tend to be very glitchy and unreliable. And it's no coincidence that Skype's written in Delphi while (AFAIK) none of the other chat programs are. That's just one example among many.

It never hurts to pick up another skill, but I haven't seen any Delphi job listings anywhere. I suspect you would be better suited picking up a new language/framework/platform with more "legs", such as WPF, JavaFX, Objective-C/Cocoa, ActionScript/Flex, or something of the like.

As a technical move, it's probably a good one -- Delphi is better thought out and more enjoyable to use. From a career perspective, however, you're probably right -- Delphi has been rather marginalized for some time now, and doesn't seem to be in the process of making a huge comeback.

I was using Delphi before I swtiched to C++ and then to Java. I don't think that moving from Java to Delphi is wise idea. Why so?
Java is widely used
It's easier to find Java job
More years of Java -> Better chance getting senior position job (java oriented)
Java is definitelly richer as for libraries
Java rocks in enterprise sphere, Delphi doesn't
It's easier to find resources for Java - from tutorials for beginners to manuals for professionals
Java runs on other operating systems by default, remember? (I know Lazarus, but can't compare port to nativeness)
From my exprience, more experienced programmers and software engineers kind of condemn Delphi programmers ...
Java is suitable for larger projects (means bigger money)
The only good reason for preferring Delphi over Java I can actually think of is making Windows GUI application. But since we have .NET and wonderful WPF, Delphi doesn't score even here.
You make your choice, but personally, I'd never switch back to Delphi (ok maybe if payment was too good to reject:))

The way you phrase your question makes me think you've got a job offer already for a Delphi developer position. If the language is the only thing stopping you, I say you should go for it.
It will add experience with another language to your resume besides being fun (learning something new). Just make sure you keep your skills in Java and C++ reasonably up to date when or if you need to move on.

Why limit yourself to one language?
A major problem with Delphi is that some people consider it an "easy" language. So there are Delphi programmers that can drag some controls to a form without any real coding knowledge. So if you are a good developer and skilled in Delphi, you won't have that much trouble finding a job.

Should I study Scala? [closed]

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 10 years ago.
I am an experienced C++ programmer with average Python skills. The reasons I studied Python in the first place were:
to get a different perspective on programming (static vs dynamic, interpreted vs compiled, etc.)
to increase the breadth of projects that I can work on (Python allows me to do web development, develop for Symbian phones or knock up quick system administration scripts)
to complement my C++ skills.
I think that Python is great and I believe that I have achieved the above goals. I will continue to use it for small projects, scripts and web development.
I doubt that I can use it for medium to large projects though. While the dynamic typing is convenient, it allows a certain class of bugs that I find disturbing. Unit testing and linting can alleviate this problem, but static typing completely eliminates it.
After looking at some programming languages, I think that Scala looks like a good candidate:
I like the type inference and it runs on the JVM so it should be available wherever the JVM is available. I can also learn more about functional programming when using it.
But... I also have some doubts, and this is where I hope that the Stack Overflow community can help:
Portability: Linux and Windows at least I hope. What about mobile phones, is it possible to get it to run there?
C++ compatibility: can I mix C++ code with Scala? (JNI?)
Programming paradigm: I don't feel comfortable with switching to functional programming (FP) at this time. Can I use object oriented and procedural with some FP at first and then change the proportions as I learn?
Tool chain maturity: what's your experience with IDEs and debuggers? I'm using Eclipse right now and it seems OK.
Learning speed: considering my experience, how fast do you think that I can reach a workable level with Scala?
Deployment: how exactly do you deploy a Scala program? Is it a jar, is it an executable?
Finally, what do you think that are some of Scalas disadvantages?

Portability: Linux and Windows at least I hope. What about mobile phones, did anyone succeed in getting it to run there?
Yes. There is quite some movement about Scala on Android. As for J2ME, I saw something in that respect, but not much. There is some code pertaining to J2ME on the source code repository. I'm not sure how viable it is, but it looks to me that there isn't much demand for that.
I'll also mention that there is/was a pool on Scala-Lang about the desired target platforms, and J2ME was one of them, very low on the totem pole.
C++ compatibility: can I mix C++ code with Scala? (JNI?)
As well as you can mix C++ with Java, for whatever that is worth. If you haven't any experience with that, you can just read the Java resources, as anything in them will be applicable with Scala with no changes (aside Scala syntax).
Programming paradigm: I don't feel comfortable with switching to FP at this time. Can I use OO and procedural with some FP at first and then change the proportions as I learn?
Definitely, yes. Scala goes out of it's way to make sure you don't need to program in a functional style. This is the main criticism of Scala from functional folks, as a matter of fact: some do not consider a language functional unless it forces the programmer to write in functional style.
Anyway, you can go right on doing things your way. My bet, though, is that you'll pick up functional habits without even realizing they are functional.
Perhaps you can look at the Matrices series in my own blog about writing a Matrix class. Even though it looks like standard OO code, it is, in fact, very functional.
Tool chain maturity: what's your experience with IDEs and debuggers? I'm using Eclipse right now and it seems ok.
IDEA (IntelliJ), NetBeans and Eclipse all have good support for Scala. It seems IDEA's is the best, and NetBeans/Eclipse keep frog-jumping each other, though NetBeans has certainly been more stable than Eclipse of late. On the other hand, the support on Eclipse is taking a very promising route that should produce results in the next 6 months or so -- it's just that it's a bumping route. :-)
Some interesting signs of Scala tooling for these enviroments is the fact that the Eclipse plugin in development uses AOP to merge more seamlessly with the whole IDE, that the NetBeans plugin is being completely rewritten in Scala, and that there's a Scala Power Pack on IDEA that supports, among other things, translating Java code into Scala code.
The EMACS folks have extensive tools for Scala as well, and lots of smaller editors have support for it too. I'm very comfortable with jEdit's support for small programs and scripts, for instance.
There is also good Maven support -- in fact, the standard way to install Lift is to install maven, and then build a Lift archetype. That will pull in an appropriate Scala version. There's an scala:cc target that will do triggered recompilation as well.
Speaking of recompilation, neither Maven, and particularly nor Ant do a good job at identifying what needs to be recompiled. From that problem sprung SBT (Simple Build Tool), written in Scala, which solves that problem through the use of Scala compiler plugin. SBT uses the same project layout as Maven, as well as Maven/Ivy repositories, but project configurations are done in Scala code instead of XML -- with support for Maven/Ivy configuration files as well.
Learning speed: considering my experience, how fast do you think that I can reach a workable level with Scala?
Very fast. As a purely OO language, Scala already introduces some nice features, comparable to some stuff that's present in C++ but not Java, though they work in different fashion. In that respect, once you realize what such features are for and relate them to C++ stuff, you'll be much ahead of Java programmers, as you'll already know what to do with them.
Deployment: how exactly do you deploy a Scala program? Is it a jar, is it an executable?
The same thing as Java. You can deploy JARs, WARs, or any other of Java targets, because the scala compiler generate class files. In fact, you use Java's jar to generate a Scala's JAR file from the class files, and the Maven targets for Lift support building WAR files.
There is an alternative for script files, though. You can call "scala" to run Scala source code directly, similar to a Perl of Shell script. It can also be done on Windows. However, even with the use of a compilation daemon to speed up execution, start up times are slow enough that effective use of Scala in a heavy scripting environment needs something like Nailgun.
As for Scala's disadvantages, take a look at my answer (and other's) in this Stack Overflow question.

Scala is an evolving language well worth to invest in, especially if you are coming from Java world. Scala is widely covered at Artima. See this article from Bill Venners and also read about Twitter and Scala.
Regarding your questions:
Java can run wherever there is a JVM. No luck with the mobile phones however. You need a full JRE, not the subset that is available there.
This is possible with JNI. If something is possible with Java, then it is possible with Scala. Scala can call Java classes.
Functional programming is a strong point of Scala - you do need to learn it. However you could also start using it without taking full advantage of it and work your way with it.
There is a plug-in of Eclipse. It is not best, but it will do the job. More details here.
If you are experienced, I would say really fast. I recommend that you find a book to start with.
See this faq entry for deployment.

Programming paradigm: I don't feel comfortable with switching to FP at this time. Can I use OO and procedural with some FP at first and then change the proportions as I learn?
Scala has full support for imperative programming, writing programs with no FP elements in it is a breeze (however, FP is useful and worth learning anyway).
Learning speed: considering my experience, how fast do you think that I can reach a workable level with Scala?
Quickly. There is a number of interesting features in Scala that may be not familiar to people coming from a C++, Java environment, like for example some of the features of the typing system. Some argue that the fact that there is a lot to learn in Scala before you know all of it is a problem with the language; I disagree. The presence of those feature is an advantage of the language. The more features the merrier. After all, you don't have to use them all at once, just like you don't have to buy everything that is being sold in the store.

Learning speed: considering my experience, how fast do you think that I can reach a workable level with Scala?
I also come from a C++ background, one thing I noticed is that since you will write a lot less code as compared to C++ for a comparable task, your learning will be expedited as you will get more done in the same time period. This was the same phenomenon that I experienced with Ruby.

Actually - if I were you - I'd study programming paradigms instead of languages. Of course you have to study an example language to study the paradigm. Knowing the drawbacks & benefits of different paradigms enables you to view your problems from a different side and makes you a better programmer (even in the languages you already know).
Picking up a language of a paradigm already known is a relativly easy task if needed. Since Scala is FP (at least you mentioned it) and C++/Python is OOP, it's a good language for you, I'd say.

You should register for this course by the Creator of Scala himself.
https://www.coursera.org/course/progfun

James Strachan (productive Java open source developer, for those not in the loop) has an interesting discussion of Scala here, and why he feels it's a progression from Java (the langauge, not the platform).
Scala looks like it's gaining a lot of traction. I don't think it's a flash in the pan, and is currently on my list of languages to learn (partly for the functional aspect)

Here's an anecdotal evidence regarding learnability of Scala.
In our company, we got several interns from U.Waterloo. They were told to write in Scala; never saw it before.
They picked up Scala and Lift remarkably fast; now they are producing Scala code; it may be not perfect, but nobody's perfect.
So, the fact that a manager does not know Scala may be not the best argument when you decide on adoption.

Exception to the Law of Leaky Abstractions [closed]

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 10 years ago.
I've had an argument with a friendly coder who was mildly damaged by Joel's Law of Leaky Abstractions. It is very hard to convince him of using any new framework/toolbox at all. I'm trying to present a point where "abstractions are fine as long as they allow low-level access to abstracted level".
Examples:
GWT - Google's superb Java-to-Javascript compiler, has JSNI - ability to write "native" Javascript if you really want to.
Hibernate - AFAIK has SQLQuery - way to write native SQL.
Java - JNI - if you miss C.
Is it sound?
Am I missing something?
Thanks

What I took from reading the leaky abstractions article wasn't that abstractions were bad, but that you should make it a point to understand what goes on under the hood, so that you can account for "unexpected" behavior, and avoid them.
What does your friend program in? Machine language? :)

Joel's point (as I understand it) is that by abstracting complexity away you are sacrificing the finer control over that underlying complexity. For anything but trivial cases you will eventually need to access that finer granularity of control at which point the abstraction breaks down.
So all abstractions are leaky (almost) by definition :
If there is complexity in a system, it must be there for a reason (or you should find a way to remove it) and so will occasionally be useful/vital.
By abstracting you are limiting the control you have over the underlying complexity.
When those 'occasionally's come along you will have to break the abstraction.

To some extent he has a point. Traditional c/unix development works to a platform that is simple enough to be able to understand more-or-less in its entirety. Modern platforms are orders of magnitude more complex, and understanding how all of the layers interact is much harder, often infeasible.
The law of leaky abstractions mainly applies when the framework does a bad job of managing the underlying complexity. Some of the ways in which a framework may be judged are its transparency (ease of understanding what's going on behind the scenes) and its ability to drop out to a custom workaround for limitations in its functionality.
When a framework does a lot of complex magic behind the scenes, diagnosing and troubleshooting become much harder, often requiring a disproportionately large amount of expertise in the underlying architecture of the framework. This means that productivity gains from the framework get absorbed in the extra effort of training and debugging the code. It also makes the framework difficult to learn and use with confidence, which is what your C programming friend is used to.
When a framework obstructs you from working around its limitations, then it becomes an impediment to development. When this happens often enough, the code base is either boxed in or becomes polluted with ever greater and messier hacks to work around the issues. This also leads to stability and debugging problems,
Examples of frameworks with these flaws abound. MFC was quite famous for failing to hide the underlying complexity of Win32. It also made extensive use of wizards that generated messy code that needed to be manually modified aftwrwards, defeating the purpose of having a code generator in the first place. Early Java GUI toolkits (AWT and early versions of Swing) have very little uptake in desktop applications because they obstructed developeers from implementing a native look-and-feel for the applications. SWT was built in no small part because of these limitations with Swing.
However, now Java has matured a bit, it could be argued that most of its early sins have been fixed in modern frameworks. J2EE is still a large, complex system, and developing a non-triviall user interface in a browser is also quite a substantial undertaking. Becoming proficient in this platform is quite a lot of work. However, it's not beyond the wit of man.

While I think its true that every abstraction is leaky, that is not necessarily a bad thing.
For example in traditional plain C (C#, Java, whatever) code you usually retrieve data from arrays by using loops, ifs etc. But that way you overspecify your solution to a problem.
The way SQL, Linq approach the same problem is more intelligent: You just say WHAT you want, the machine figures out how to do it. This way it is free of any specific ordering of commands from the traditional way and can split the work onto different cpus for example, or reorder stuff to make better use of caches etc.
So yes you give some control to the machine, but the machine has one big advantage over you: It is at the user/customer's place and that way can make on-demand decisions (like using multi-core, using advantage of MMX, whatever).

Scripting in Java [closed]

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 10 years ago.
Me and some friends are writing a MORPG in Java, and we would like to use a scripting language to, eg. to create quests.
We have non experience with scripting in Java. We have used Python, but we are very inexperienced with it. One of us also have used Javascript.
What scripting language should we use?
What scripting language should we not use?

I'm responsible for a fairly large hybrid Java/Jython system. We use java for core API development, then wire Java objects together using Jython. This is in a scientific computing environment where we need to be able to put together ad-hoc data analysis scripts quickly.
If I were starting this system from scratch today, I would not choose Jython as the scripting language. I like Python fine, but I frequently encounter awkward mismatches between the Python type system and the Java type system. For example, if you just want a hashtable, should you use a Python dictionary or a Java HashMap? The decision might be different depending on whether you are just using the data structure locally in Python code or passing it across the Java boundary. Jython does a certain amount of type coercion for you, but it's not perfect. It's annoying to even have to think about issues like this when the purpose of using a scripting language in the first place is to enhance your productivity.
I assume JavaScript or JRuby would have similar issues. Today I would choose a scripting language that is specifically targeted to the JVM and leverages the Java type system. The obvious candidates are Groovy and Beanshell; Groovy seems to have been picking up momentum lately so I'd look most closely at it.

I agree with Viktor's Jython suggestion. Other than that and JavaScript (which you've mentioned, and is built into Java 6+ via the javax.script package), Groovy and JRuby are also worth looking at too.
By the way, you should look at Wyvern, also an MMORPG written in Java and using Jython for scripting. Steve Yegge, its author, has much to say about it from time to time. :-)

Java supports a variety of (scripting) languages, some are listed in Wikipedia here and here. You probably should choose language with powerful DSL and metaprogramming capabilities, such as Clojure.
But if you need something simpler, JavaScript might be a viable alternative.

How about Jython?
http://www.jython.org/Project/

what about creating your own specialized scripting language? If your app is written with java, you can use ANTLR (http://www.antlr.org/) to create your language parsing code.
The reason I say this is because a general purpose scripting language may provide too much power (because the script it to be used for quests only i assume).
But if making your own language is too hard then any of the above suggestions works - you just have to figure out how to bind the game's runtime into the script. I also suggest Lua (http://www.lua.org/) as another choice that lots of games use.

Short version
Don’t use a scripting language! Instead focus on configurability (which is something that a non-programmer can do well).
Longer version
One oft-used argument in favour of having a scripting language is that it allows for lesser programmers to more trivial tasks. Don't belive this, it will not save you any time, since trivial tasks are already accomplished by real programmers in no time. Aim for configurability instead of scripting, and you will have a much lower risk of bleeding over complex algorithms and concepts into the incapable hands of game designers. :)
Lack of hotswapping (edit-and-continue) would have been a reason to implement a scripting language in an MMOG (you don’t want to reload the whole game for a minor code change), but using Java, with built-in hotswap, you really have no reason for adding a scripting language on top.
I have spent years pondering these questions; in the day I implemented a complete scripting language, IDE, VM, debugger, etc for an MMOG myself. Since, I have grown wiser.
If you still choose to go down the infinitely crappy path of no return, keep the following in mind.
Pick a mature language which has been around for a while.
Auto testing, debugging and editing will suck bigtime until you make your own tools/plugins/start hacking around in the VM.
To date, I have never seen a DSL that improved the situation (getting a more maintainable product). Myself, I integrated Python into my indie game engine, but eventually came to my senses and ripped it out. "Stackless Python" is just a way of saying "unmaintainable but fast". Please, anyone correct me if I'm wrong?

See Java: Scripting language (macro) to embed into a Java desktop application

You have quite a few options:
Groovy - http://groovy.codehaus.org/
Jython - http://www.jython.org/Project/
JRuby - http://jruby.codehaus.org/
Possibly even BeanShell (http://www.beanshell.org/)
I'm a fan of Python myself so I'd recommend Jython, but they're probably all reasonable options.

I would have to recommend Javascript for this purpose. Mozilla Rhino http://www.mozilla.org/rhino/ is an excellent implementation that would fit your needs perfectly.
I recommend Javascript over Jython or JRuby because of familiarity. Trivial Javascript follows a very familiar syntax that anybody can use. However if someone wants to do something more intense, Javascript is a very powerful functional programming language.
I regularly use Groovy and Ruby professionally and believe that their purpose is best for writing parts of applications with particularly complex logic where Java is cumbersome to write. Javascript is a much better choice as an embedded, general scripting language to use in a game. I haven't used Python, but it's syntactically similar to Ruby and I would believe it's purpose would also be similar.

LuaJ seems to be a nice way to embed Lua into Java:
http://sourceforge.net/projects/luaj/

I am a big fan of Python/Jython due to the clean syntax - which may suit you if you have some python experience.
Otherwise Groovy which is based on Java syntax and may be an easier learning curve if most of your developers are Java guys. It also has the advantage of closer ties with the Java language and libraries.
Beanshell is good if you have simple scripting in mind - it doesn't support classes. However I don't think it has had any support over the last few years (the JSR seemed to kill it off...) so is perhaps a bad choice if support is important to you.