
Ask HN: Enterprise Java guy needs advice on what to transition to - rlawson
I have made my living doing Java enterprise development for big companies for the past 10+ years. I can sense the world is changing (much like when I transitioned from C/C++ to Java) and that I need to make a change. Frankly I am tired of all the complexity and over engineering of enterprise Java. For all the effort, I find most apps are large (1+ MLOC), monolithic, hard to understand and maintained by large groups of onshore/offshore resources who just keep the stuff running by sheer numbers and have no pride in their craft. I want to do something better as I still have about 20 years left in my working life. I have played around with Python and like it but not sure how it will scale up to a large project. Any advice appreciated, especially from those who have already made the transition.
======
brown9-2
_Frankly I am tired of all the complexity and over engineering of enterprise
Java. For all the effort, I find most apps are large (1+ MLOC), monolithic,
hard to understand and maintained by large groups of onshore/offshore
resources who just keep the stuff running by sheer numbers and have no pride
in their craft._

If this is the type of thing you want to move away from, then I don't think
that the problem is teams that use Java - the problem seems to be working for
large enterprises.

I suggest that as a first step, ignore any questions of
language/platforms/tools and instead think about what type of company you
would like to be working for: a small start-up, a more-established medium size
business, etc. Do you want to work in a place where the primary business
product is software (i.e. a software development company), a place where
software is something that is done in support of the primary product being
sold, or are you interested in consulting for others?

Once you decide what type of environment you'd like to work in, then the rest
of the decisions follow naturally from that.

As a single anecdote, I work for a medium-to-large software-as-a-service
company business where most of our work is in Java, but we are very far from
the notion of monolithic apps with 1M LOC and offshore teams.

The language/tools are not the problem, it's the people/organization.

~~~
alavrik
_> The language/tools are not the problem, it's the people/organization._

The language _is_ a problem, because Java was specially created for _this_
type of organizations. And it is not surprising that Java attracts _this_ type
of people (fungible crowds having no pride in their craft).

~~~
brown9-2
I disagree that it's possible to paint all developers using this language with
such a broad brush. By this notion everyone that uses Rails loves being a
"ninja" and monkey patching.

~~~
alavrik
My comment was about the language, not the people. I have no doubt that there
are many good programmers who use Java.

But I'm not sure one can be a good programmer if Java (or any other mediocre
language) is the only thing she knows.

------
tomjen3
Given that you know Java, you could consider transition to Android - it is a
lot simpler than enterprise Java (because it has to run on a phone) and most
of the APIs have been reworked.

But then that is just me.

~~~
jerhewet
Seconded, and extended to languages for other mobile devices. Since most
things are (unfortunately) web-centric nowadays, it's a relatively safe bet
that knowing how to throw code for smart-phones and tablets will keep you
employed (and entertained!) for at least the next decade.

~~~
abp
_Since most things are (unfortunately) web-centric nowadays_

Disagreed. Theres much more that needs to be programmed. Think of devices,
health information systems, traffic routing etc.

"Most things are web nowadays" is often said, but just wrong.

------
jbarmash
I switched to Groovy/Grails a couple of years ago and haven't looked back.
Lots of fun to work with, and allows me to reuse my previous knowledge base.

In addition to reusing my previous expertise, there are four thing I really
like about it:

* Convention over Configuration makes things so much simpler * Groovy Language has a lot of great features, allowing for much more concise code (though it does take some time to get used to dynamic typing) * Plugin ecosystem - over 500 plugins on various topics allow you to get things done much quicker. The plugin architecture is wonderful and allows you to compose your from reusable blocks, which could have their own UI. Best actual (as oppoed to theoretical) code reusability I've ever seen * GORM (object relational mapper) is a thing of beauty. It's fairly implementation-agnostic, so you can use it with Relational DBs, switch to Mongo or Reddis as the persistence backend fairly easily.

Definitely recommend you check it out. In terms of jobs, it's not as big of a
community as Java yet, but I definitely see many jobs advertising those
skills.

------
mgkimsal
As others have mentioned, migrating to something else on the JVM first will
allow you to reuse some of the skills/knowledge you have while you gradually
focus on the 'new' aspects of something else.

JRuby and Jython are both good stepping stones to ruby and python, which would
give you an idea of if you want to head in those directions full time.

I'm partial to Groovy myself, and I'd consider it more a superset of Java
(though technically its not). You can reuse as much or as little of Java as
you want - even in the same file - while picking up the new idioms.

Groovy, JRuby and Jython will all help you dispense with much of the
boilerplate cruft you see in traditional Java, without giving up the
power/libraries you're used to. And they all have good webstacks (Grails,
Rails, Django, for example).

Moving off the JVM, if you're looking in to web work, PHP - as much as it has
a bad rep in certain quarters - is where a lot of work is. The code quality of
projects you may find tends to be hit or miss, but it's certainly possible to
write clean, elegant and scalable code in PHP (and I've seen some pretty piss-
poor rails in my day as well - nothing's perfect). Have you considered looking
at .NET as well?

As someone else said, the 'scalable' thing - don't fret about it. Anything is
scalable, and each platform will have different techniques - they all have
pros and cons, which may not always be apparent until you dig more deeply in
to the constraints of a particular language or platform.

Find a couple platforms that are of some interest, and focus on finding some
communities for those platforms (Django, Rails, Zend Framework, Grails,
ASP.NET, whatever). Getting a feel for how the community thinks about
problems, what they focus on (features, security, etc) will give you a sense
of what you're comfortable with.

------
drKarl
Given your Java background, and that you want something more simple you could
give a try to the Play! Framework, and you could try to learn Scala.

------
petervandijck
Start with Scala. Then try Play! and such. Also look at GWT. And do iOS. Much
better job market than Python etc. <http://blog.getgush.com/>

I'd stay away from Groovy etc.

Also, please get over that "scaling" stuff. PHP scales just fine. Rails scales
just fine. Python scales just fine.

~~~
mgkimsal
Why stay away from Groovy?

~~~
petervandijck
The Java programmers I know consider it bloaty and oldskool.

------
lawn
Here's my take, but keep in mind that I've never worked with programming, I'm
just a hobby programmer for now.

I don't really see why you have to bind yourself so hard to a
language/platform/whatever. You don't have to be a "Java programmer" or a
"Python programmer". Instead aim to become someone who can move around and
choose whatever is best for the job, or whatever the job might require. In the
end it's just programming, different types of programming sure but never
forget that you're basically doing the same thing in a different way. When you
see that you realize languages are just tools for you to use, not the other
way around.

The first step IMO would be to expand your horizon, see what else is out
there. Try out the exotic languages you see everyone rave about, give Python a
blast or drive Ruby for a while. Do things in Erlang or Haskell just because
it's different from Java and mix web development with low level or simply make
a game or a program you've always needed.

When you know what's out there, when you've gotten your feet wet, then you can
focus in on something a bit more. The thing that has kept my interest in
programming alive is I've always done what's fun, and I can only imagine
that's even more important for someone with 10+ in the business actually
working with it. So choose something you feel is fun, oddly for me the
funniest things are the new and different stuff (Haskell for example).

Long story short: Don't be an "X programmer", be a "programmer" and go where
the fun is!

Best of luck to you.

------
swombat
What do you want to do? What do you want to build? What gets you excited?

Try various things, and pick one that actually gets you excited, and makes you
think "wow, this is so cool" - not something that makes you think "well, the
market seems to be moving in this direction, so there'll probably be decent
money there".

------
peterhi
Well you've probably got Java down pat by now, try something new that will put
bread on the table. Learn Ruby and Ruby on Rails.

This should get you away from the overengineering that Java seems to attract
and there are plenty of Rails jobs out there (certainly more than there are
Grails jobs anyway).

Whilst you are at it pick up some new technologies such as mongodb.

It would be good for your soul (and skill as a programmer) to try something
new, completely new. You could of course also learn ObjectiveC++ and become an
iPhone developer. Whatever you pick make sure that it puts fear in your heart,
something that will challenge you. A mountain to climb rather than molehill.

------
buddyw
Clojure. Runs on the JVM, lisp-based, new/exciting, paradigm-ific,
challenging, and elegant. Enjoy.

------
bebeastie
I would suggest experimenting with Groovy/Grails on some weekend projects.
Grails is similar to Rails so you could easily leverage this knowledge if you
ever wanted to move to RoR.

Beyond that I would agree with earlier commentators that the real action over
the next few years will be in JavaScript. Both server and clientside. The
former being particularly interesting.

------
tjansen
I have a similar background and am also working as enterprise Java Dev.
Financially, I don't think that it is a smart idea to transition at the moment
(at least in germany, where I live). Java developers still seem to have the
highest salaries, the most job offers and the best outlook in general.

There are various interesting technologies that COULD replace Java or at least
JEE in the future, and it is certainly a good idea to learn them or do
projects in your spare time. But beside Java, I don't think that there is any
technology that you can be sure that it will be still around in 5-10 years.

If you are just sick of Java and need some change, then try to find a new job
where you can work with whatever you like. Java changes pretty slowly, and you
can still change your mind a few years later and find a Java job. But if you
need to decide for a language as a career-choice, stick with Java, at least
for a few more years.

------
dutchrapley
I couldn't agree more. For most projects today, Java is severe overkill where
a more high level language is better suited. While I'm not a fan of the Java
language, the Java platform is rock solid and we can all agree it's not going
away anytime soon.

I'd recommend taking a look at JRuby. It works nicely with Java libraries and
loading Java classes. You don't have to deal with dependency injection.
Variables aren't typed, values are. Class and instance methods are managed in
the same class declaration. Classes can be easily extended. Classes are loaded
into constants at runtime - instance objects are created (and constructor
called) by calling the "new" method on a class constant (hence no dependency
injection required). Class methods can't be called by an instance objects and
vice versa.

While JRuby would be new to you, it's on a familiar platform.
<http://jruby.org/>

~~~
geebee
I've been thinking about DI in Ruby, and I've been trying to think of how I'd
deal with the absence of DI in Rails. Here's a scenario...

Suppose you have two different ways of gaining information about a logged in
user. Let's say one goes to LDAP, and the other goes to an RDBMS. You'll be
using one or the other depending on where the software is installed.

So in Java, you create an interface that defines the methods you'd need to
identify and retrieve a User, and you write an LDAP and an RDBMS
implementation. The code deals only with the interface, never the
implementation directly. So if you want to switch them, you just create a
setter (assuming we're using setter injection) and notify your DI container of
which implementation should be injected.

I definitely get it that in a language with duck typing, there's no need for
the interface/implementation gymnastics. You can just pass whatever class you
want, and as long as it responds to those method calls, you're golden. So in
that sense, DI isn't really an issue.

But what about the nice decoupling you get - is there any easy way to swap out
a particular implementation in Rails? I'm trying not to think too much in Java
here, it's more of a general problem, definitely doesn't mean I'd necessarily
want to force DI onto a language that takes a completely different approach to
things...

Sorry to get so technical here, just seems like you might have some insights
into this.

~~~
dutchrapley
Your question is more in regards to Ruby itself, and not Rails. You don't have
to swap out implementations in Ruby.

Implementations aside, when you do DI in Java, it serves two purposes: 1)
instantiates an object and 2) wires it into another object. Remember that in
Java, each class is in it's own file. In ruby, you can break classes into
several files, but you don't have to. Ruby simply reads class declarations at
runtime and instantiates those classes into constants. This means that your
classes are always available. If you've defined a class method, you can call
SomeClass.some_class_method. If you want to work with an instance of that
class, you would call SomeClass.new - to which you can pass args to a
constructor.

In your instance, you could have three classes - User, UserLdap, and UserDb.
You might call User.find( person ), and in the find method you would test your
conditional on whether to use UserLdap or UserDb. If you had common methods
you wanted to share between the two, you could place those in User and extend
that class for use with an instance object. Another option for sharing methods
cold be to place them in a module, which you can then include in your class.

It's hard for me the make a recommendation for your specific problem at hand.
My best advice is to read up and Ruby a little and begin to put what you learn
into practice. Here's a couple of recommendations:

<http://www.humblelittlerubybook.com/>

<http://mislav.uniqpath.com/poignant-guide/>

My light bulb moments were realizing that all class declarations are loaded as
constants at runtime and class & instance methods are also managed in the same
class declaration. HTH.

~~~
geebee
Thanks for your reply...

I'm kind of following you - unfortunately, I don't know ruby well enough to
understand what you mean when you say class declarations are loaded as
constants at run time, but I'll definitely look into it.

I think there's a third purpose to DI that you didn't mention. The container
does instantiate an object and inject it ("wire it") into another object, but
the real benefit is that you can externally configure which object to swap in.
That last part might matter less in a language that doesn't have to be
compiled but it can still be valuable if you have a lot of different
implementations that need to be swapped in/out in different deployments.

The method you described for person - testing a conditional - do you mean
you'd create a method with a conditional, and choose which implementation to
use based on that conditional? I've done this, and it certainly works, but it
isn't really a placement for DI (this sounds more like a factory method,
though again I don't think that those really exist to the same extent in ruby
since duck typing is much more flexible than static typing). My problem with
this approach (if I understand it right, which I'm not sure I do) is that this
would lead to a very long series of conditionals to load the right class. In
rails, I'd probably be looking to pull them out into a yaml file (something
like the applicationContext file in Spring).

~~~
dutchrapley
"class declarations are loaded as constants at run time"

Let's say I create a class called User. When ruby sees that declaration, it
creates a constant called User to contain that object. When I create a new
instance:

user = User.new

"User" is a constant whose value is the object/class. "new" is a method that
calls the constructor (if one exists) and creates a new instance. The same
applies when you call something like:

User.find

You're not calling find() on an instance, you're calling it on the object
that's loaded into the constant "User". The class declaration "class User" is
saying User is the name of the class; User is also the constant in which it's
stored. It's also what allows you to reopen a class on the fly to extend it
with more methods.

"I think there's a third purpose to DI that you didn't mention. The container
does instantiate an object and inject it ("wire it") into another object, but
the real benefit is that you can externally configure which object to swap
in."

True, but I've never found myself switching objects out on a regular basis.

As you mentioned, the conditional approach probably isn't the best. What I'm
assuming now is that you're based on your deployment, you might use a
different bean factory configuration file? And this works as long as UserLdap
and UserDb implement the same interface?

That being said, instead of sprinkling conditionals throughout user, you can
dynamically assign User initially.

User = UserDb

OR

User = UserLdap

and as long as UserDb or UserLdap had a find() method, you could then call

User.find

Remember, User is now a constant that references the same value as UserDb or
UserLdap

Does that help clarify?

~~~
geebee
Responding very late, sorry...

It does help clarify this, thanks. It does still leave the problem that you
have to specify the "type" in the code and can't swap it out. That said, I
think this could probably be handled easily with a yaml file (just specify the
class you want to instantiate every time a user is created)? I may try that
some time.

------
smharris65
The future in the next 20 years is mobile development. Currently, for software
on the actually device that means Objective-C for iOS(iPhone) development, or
Java for Android. Of course, HTML5 and CSS3 are going to important for web
pages viewed on the device. Find something you like in this area and stick
with it!

~~~
djipko
I just wanted to reply "20 years?! Realy! Very bold prediction", but then I
thught to myself - if someone said in 1991 that the future in the next 20
years would be web... he would have been right... interesting, isn't it.

------
zorkerman
As a recovering java enterprise developer I'd say pick a small project you are
interested in and another language you are not familiar with and try it out. I
found ruby an easier transition from java than python, Go might be interesting
for you if you are coming from c++. Just make a small app in your free time
and realize that a ridiculous number of startups these days have code bases
measured in thousands of lines of code rather than millions. It is wonderful
to live in a world where you can hope to understand the whole system.

~~~
uriel
> Go might be interesting for you if you are coming from c++

Go might be more interesting if you are coming from C. Go and C++ are pretty
much antithetical.

For some reason Go also seems to interest people coming from Ruby.

------
lucaf
"Enterprise" Java does not need to be the way you have experienced it. We are
getting ready to release a fairly complex Java application that addresses a
very significant pain point. The major components of the entire application
are highly decoupled. Our team is currently two developers, and we do not
envision it to grow over three. The whole development process took only 8
months.

So... don't blame Java for poor architects or poor engineering/business
leadership...

(And, btw, I'd love to talk to you if you are in the Boston area.)

~~~
rlawson
good point. Unfortunately, I have ended up working on big apps that were
written early 2000's during the big Java migration which means Jsp/Struts
1/EJB 1&2\. The apps tended to be developed under a short timeline by a lot of
developers so the lack of clear direction really shows.

Sorry I'd like to meet up but in sunny South Carolina (go gamecocks !)

------
div
I've done a ton of spring / hibernate enterprisey stuff and am now focusing on
iOS and Android development.

For one off stuff I usually use ruby nowadays, and if mobile would not be my
thing, I'd definitely be delving in to Rails (have some previous experience
here) and Node.js.

I've done some projects in Django but didn't really dig that as much. There's
a ton of Python frameworks out there though, and Python the language is pretty
cool to work with and a breath of fresh air if Java has been your mainstay for
the last decade.

------
eccp
I'm walking the same road, been working on the Java platform for 8+ years. The
recent trend of new languages on top of the JVM is really exciting, so you
have several options to investigate without trowing away all your existing
Java knowledge.

Groovy + Grails is a great platform and it feels like a grasp of fresh air,
but there is also Clojure (with an emerging ecosystem), JRuby (and you can run
Rails on it), Jython and Scala to name a few other options.

------
nl
There is plenty of work doing GWT+(Spring|Guice) apps in areas more
interesting than traditional enterprise Java.

Also, there are a lot of interesting infrastructure projects written in Java
(Hadoop, Lucene, Cassandra etc). It's pretty easy to get started in any of
them.

If you really want to do a new language then I doubt you'll find many people
arguing against Python. But the real action is in Javascript (both server &
clientside)

------
brudgers
> _"I have played around with Python and like it but not sure how it will
> scale up to a large project."_

Which is more important - a new language or a new career path? In other words,
would "Enterprise Python" or "YC Java" provide more of the change you are
seeking? From your post, I get the sense it is the latter. Good luck.

------
checker
I'm surprised that more people haven't mentioned javascript as a new language
to get into. Becoming an expert at it looks like it could become extremely
valuable very quickly, simply because it's everywhere on the web now. It
doesn't matter what backend a site has, 'every' client is using javascript.

------
nextparadigms
Mobile markets are going to explode over the next few years. There's a lot of
potential growth there and mobile developers are in high demand. But the best
would probably be to try making your own app and become an entrepreneur. You
should start with Android since you already know Java.

------
bensummers
Look into JRuby and Ruby on Rails.

You'll get a fun development environment, a less formal language. The big plus
for you is that JRuby has wonderful Java integration, so you'll be able to use
all the Java libraries and infrastructure you've learnt over the years where
they make sense for your project.

------
gsk
>I have played around with Python and like it but not sure how it will scale
up to a large project.

If by scaling you mean how to organize a large codebase, IMO, it is not hard
at all and usually the python codebase is much smaller than a similar java
project.

------
noodle
ruby/rails, unless you have anything specific in mind.

everything you've heard about it is true. its great, and the learning curve
for someone who isn't a cut-and-paste coder is small. i made the same switch a
while ago, java/c to ruby, and it was like a weight lifted off my shoulders.

------
geebee
Would you be willing to elaborate a little more on what you hate about Java?
You mentioned "complexity and over engineering", which is what I hate about it
these days too.

The thing is, I used to _like_ Java. While I've been mainly interested in
Ruby/Rails for personal projects, I've had to keep coding in Java for my work,
and I've started to hate it too. But there are a lot of things I still like
and miss about it, including moments when I think I'd actually still choose to
use Java for a project.

Looking back, I think my enjoyment of Java ended around 2005, which was when
Servlets and JSP were replaced with Struts, Spring, and Hibernate. I know a
lot of people felt this was a huge improvement over the original EJB, but
personally, I was astonished that people thought Spring, Struts, and Hibernate
were "lightweight" (I never even bothered with EJB). While these frameworks
have improved greatly and aren't nearly as hard to use as they were a while
back, but I still don't like coding in them.

I think I miss the "recipe" approach prevalent prior to 2005, where you stuck
closer to the "low level" servlet/jdbc approach, and you either brought in a
new library for a specific task, or decided to write the code yourself. It was
a bit laborious, but there wasn't much you couldn't do if you were willing to
do a lot of typing. This approach seems to be an evolutionary dead end now -
people generally start their projects in a framework (rails, django, spring),
and stay within it for the remainder of the project. So there isn't really any
point to a servlet "cookbook" anymore. It's either a Spring cookbook, or a
Struts cookbook...

I think some new technologies have made Java more enjoyable - especially
Maven, but I felt that Spring made Java far less enjoyable. It's a personal
opinion, but to get a sense of it, I recommend you try working through the
SpringMVC tutorial on the SpringSource site. Like I said, this is pretty much
just a personal preference of mine - if, after doing the tutorial, this seems
like a great way to write web apps, then by all means, go for it. But
personally, I can't stand it.

I've been wondering if maybe there's a niche out there for people who like to
use java at the low level. The funny thing is, I obviously do like frameworks,
since I'm pretty enthusiastic about Rails. I think that it's just that _if_
I'm going to use Java instead of Rails, then obviously there's a reason, and
it's probably because my tasks are taking me outside the normal operations of
a framework.

I think this comes down to wanting to be either at a very effective and
efficient high level of abstraction, or wanting to get down into the grit of
the problem and be able to do anything. While there was a time that it would
have seemed funny to refer to anything Java related as "low level", pure
servlets and jdbc seem to be taking that role in the middle tier (not just
within SpringMVC or JPA/Hibernate, even non-java languages seem to be
compiling to Java to run on the JVM).

Ok, this is a long rant, maybe it should have been a separate post completely.
It just seems like we're in the same spot, and I want to ask you - do you
think you might enjoy Java more if you dropped back from the enterprise-
framework thing and started using it where (in my opinion) it still excels,
the "low-ish" level of the middle tier? I wonder if other people are starting
to feel the same way I do about this - that Java has its place, but when it
does, your probably going to want to be going in as low level as you can with
the language - otherwise, you'd be using something else.

~~~
rlawson
Sure. First I like Java the language. I dislike Java the enterprise platform.
I don't like XML as another programming language, I don't like having to fire
up a giant container to test a piece of code (looking at you weblogic). Now
things are probably moving in the right direction - I did try EJB3/JPA and it
was ok. But I'd hate to be a new programmer coming to Java and being
confronted with Spring, EJB, Hibernate, JSF and an app server just to shove
some data in and out of a database.

~~~
geebee
I agree that things have moved in a better direction lately. I recently wrote
an app using Struts 2, Spring, and JPA (backed with hibernate), and I made
heavy use of annotations that did greatly reduce the amount of XML. I'd agree
with you, though, that this would be a nearly impossible (and probably
pointless) task for a newcomer (including experienced developers who haven't
done much Java). I almost have to wonder who even uses these things anymore...
they're too complicated for programming newbies, and I have trouble believing
that an experienced programmer from Rails or Django would be willing to put up
with it. Are the only people who use this stack existing Java developers who
learned java back when it was manageable? I can see someone slowly backing
into these frameworks incrementally (like you and I did), but if you're new to
Java, it's got to be a thousand pages of reading. I'm prepared to believe that
a smart, studious person still wouldn't be there in six months.

What do you think about my other suggestion - dropping back to a lower level
of code for java applications? I don't think the servlet/jsp approach is
anywhere near as hard to learn, and I think it can be effective. As for not
reinventing the wheel... well, I'm all for bringing in components
incrementally as you need them - MVC, web service APIs, DI containers.

What do you think - could Java be more popular if the "java community"
embraced the lower level approach, starting with Servlets/JDBC, and leaned
toward gradual integration of technologies as needed? (I know, it's hard to
speak of a "community", it's really just a collection of individuals, but it
seems like the overwhelming thrust of the Java world has been starting within
frameworks that add tremendous overhead at the start and actually sometimes
become a hinderance as the app grows).

~~~
rlawson
yeah you are right, I learned servlets / jsps from Marty Hall's book and then
just progressed from there. For smaller projects I usually start with Tomcat +
Stripes + iBatis Sql Maps in order to minimize the learning curve. But no self
respecting corporation would consider that stack (even though it is free, easy
to learn and very fast).

~~~
geebee
What do you think are some of the factors behind the resistance to some of
these alternative frameworks? I've heard good things about stripes. But it
seems like almost every MVC framework other than Spring MVC is losing
mindshare. I actually think Struts 2 is a nicely designed framework, but the
association with Struts (which is actually an almost completely different
framework) may have doomed it.

Almost everyone using Spring for DI seems to be leaning toward Spring MVC
these days, probably because they don't want to do too much pick-and-choosing.
And the default choice for a DI framework seems to be Spring as well, which
means a Java programmer is now a Spring programmer.

This is probably why the "java cookbook" style books haven't been updated
since 2004. They're treated as an evolutionary dead end, though I don't think
they should be.

~~~
rlawson
You hit the nail on the head. Java EE programming is consolidating into Spring
programming. I think it is because Spring gives you a layer on top of the app
servers that finally achieves the write once run anywhere as long as you stick
with Spring. That part is good but it is a shame that you need so much _stuff_
to achieve this. I always cringe when maven pulls down all spring jars (20 or
30 ???)

------
JunkDNA
It all comes down to what kind of software you intend to make (and frankly,
who you intend to make it for). If you want to write a 3D video game, Python
and Ruby aren't exactly your best bet for example. Likewise, if you're inside
some company with a JVM mandate, your options can be limited as well. I can
only comment on web app development since that's what I do most. My advice
would be to pick up Ruby (and Rails) or Python (and Django). You might also
try out Scala. Lift appears to be a pretty nice alternative to the morass of
heavy Java web frameworks, though it's much less mature than something like
Django or Rails. Coming from Ruby and Python though, when I work in Scala, it
still feels a tiny bit heavy to me. I think for you, a clean break from the
Java world sounds like it's what you need.

Managing a substantial Python (or Ruby) project is easier than you'd imagine
because there is so much less code and configuration. There is also less
"architecture astronautism" with all the layers of abstraction hiding what's
really going on. You can still have some of that, but in my experience, it's
pretty rare.

The biggest issue when stepping outside the JVM (in my opinion anyway), is
dependency management. The libraries you want may often not be pure Python or
Ruby, but have C/C++ stuff in there too. This can make setting up an
environment on multiple OS platforms tricky, since you need to install (and
maybe even compile) all that stuff. There's something to be said for throwing
a jar on a classpath and being done. However, I suspect you'll find these
languages cut development time so much that you're still ahead of the game
after burning a little extra time installing some dependencies.

Performance-wise, both Python and Ruby are probably "fast enough", certainly
when developing apps that are not used by large numbers (i.e. web-scale
numbers) of people. Internal apps in particular run perfectly fine with no
exotic caching, partitioning, parallelization, etc... There are also plenty of
companies out there that operate very busy, successful public websites with
both Ruby and Python, so in general, the performance should be the least of
your worries. Obviously, if you're looking to do scientific simulation or some
other compute-heavy work, your mileage may vary.

Editors are another thing that trip people up going to Ruby and Python from
Java. Take my advice: ditch your IDE and use a regular text editor with syntax
highlighting. There's no way I write Java code without an IDE, but for
languages like Ruby and Python, it's not necessary and the IDE just gets in
the way. Keeping an interpreter window open when dealing with a library you
haven't used before is far more productive. You can create some fake classes,
try out some methods, and once you have a feel for the thing, move over to
your editor and code up what you want. That beats the pants off autocomplete
any day (and the inevitable compile, run, test cycle that goes with it).

EDIT: Oh, and learn JavaScript if you don't already know it. It's only going
to get more important.

------
bkmrkr
Do you live in NY?

~~~
rlawson
no, I'm in the high tech mecca of South Carolina. New York is frightening to
us southerners.

------
shareme
Delicious Bookmarking site I believe is Django/Python

As far as scaling to a big enterprise project, not sure yet.

Given your java background have you compared groovy/scala/erlang to python
yet?

While I do code android applications I am going through the same evaluation
process for my server side development.

Groovy is nice in that I get to re-use Spring/Hibernate EJB, etc while having
the features of an object oriented scripting language DSL and Grails has a
good set of MVC features.

Python seems a little rough if you are re-using legacy java however jython
does function and I guess one could build up jython stuff to handle legacy
java enterprise.

Scala and Erlang seem interesting both attempting to solve same and similar
problems in different ways implementation language wise.

Zed Shaw has some notes on enterprise coding with python, which are worth a
read. I would also not rule out new C++ frameworks as Google still uses a lot
of C++ in enterprise with good results.

------
johnfrank2011
i wanna get software

