Find an old Lisp hacker who has written code in Lisp for the last 30 years and I'm pretty sure they will find nothing about Java intuitive. If you don't think that's true, just see the problem that some lisp guys have with concepts like class paths when trying to get started with Clojure. And don't even get me started on why I have to tell the compiler a bunch of type information it could quite easily infer (see Scala for a good example of a strongly typed language with low ceremony and good type inference).
I agree with this. Java is not perfect, but the language is simple.
Yes, you have to redefine types multiple times (and I'm aware that
Scala fixes this... I love Scala), but at least it's consistent. You
never have to ask: "should I or shouldn't I add the type?" The answer
is: "you always add the type"
I know that sounds silly, but you'd be amazed at how simple things
become. You never have to worry about passing in an object compared to
passing in an array where the first argument is a symbol and the
second argument is an object.
As for classpaths - I hear you. Classpaths were designed really
stupidly, and to compound the problem, the rules are different on your
local machine on Windows from deploying on Tomcat under Linux (trust
me, I know).
Classpath loading didn't have to be this way, but is - and Sun (now
Oracle I guess) has a history of supporting every broken standard,
api, and design decision to the bitter end
I'm still getting up to speed in Ruby and Rails and continually find things that don't seem intuitive to me - despite a decent grounding in dynamic languages like Groovy and Python and a programming career encompassing a lot of languages. But I don't immediately assume that to be an issue with Ruby or Rails, but rather a limitation of my intuition due to the lack of experience with the idioms of Ruby and Rails. (Side note - get a copy of Eloquent Ruby - it'll help a lot. Also read The Rails 3 Way, Crafting Rails Applications, the Rspec book and everything else you can get your hands on about Rails and try to pair and attend hackfests to get a feel for how Rails developers write code)
I admit that sometimes I am at fault. I tried sub-classing Users, and
while this might remove some duplication and put things in the right
place... it's not the correct way to do it with Rails. The amount of
"Pushback" I get from doing this at all stages (routes, controllers,
etc.) is not worth the hassle.
Still, I think the two problems I highlighted don't have much to do
with "common idioms". The common idiot in rails is to use parameter
hashes, yet [:admin, @user] is far from that. The word ":as" has a
ambiguous meaning too when it's applied to subclasses... which is
(probably) the only time you'd ever want or need to use it.
Get to know some excellent Ruby devs at RubyConf (you just missed RailsConf last week in Baltimore if you weren't there - it was a blast), regional conferences and local meetups. Ask them some questions including why they use the language. I moved to Ruby and Rails because many great developers I know from other language communities told me they found it to be more productive and fun. My experience (despite the occasional frustration) bears that out. Also, build a deep network of Ruby devs so when you *have* an issue you can IM someone and figure it out in 5 minutes. Software engineering is fundamentally a social endeavor.
My network stinks. I'm pretty much doing this all by myself. I have no
problem with that - I work better on my own for the most part. This is
an individual project by me and myself and I.
Or you can always go back to Java. The Play framework isn't bad and Spring Roo does an awesome job of using best practices in code generation and providing a command line experience that even Rails should envy. Spring gives you DI and AOP which are useful. Groovy is an awesome language with AST transforms that provide an amazing set of metaprogramming capabilities, and while it isn't quite as mature as Rails, I've successfully built a number of projects using Grails and it's an excellent tool for developing Java centric apps on the JVM (although if you just need to deploy to war files, you should also look at running Rails using JRuby).
I thought about going back to Java, but that means scrapping 2 weeks
of work. I'm trying to look at it objectively - would I make up the 2
weeks in the long-run by going back to Java world? Or would I still be
a productivity gain if I stick with Rails?
Knowing what I know now... I *should* have stayed with Java if I want
to finish in ~1.5 to 2 months. I didn't realize I'd run into so many
problems. It's not like I am actually learning web development
concepts... I am just being slowed down by trying to learn the *how*
with respect to ruby/rails.
The app I am building isn't simple, so almost all of the test examples
and code examples look pretty, but they are not very applicable to me
unless it's the simplest case. Ruby/Rails definitely has the features
to do what I want, but there's an obvious time-sink or lag or learning-
curve (whatever you want to call it) that I need to overcome in order
to be as productive or even more productive than I was using Java/
One of the reasons I find Ruby/Rails appealing is that there is
clearly more innovation going on. While Java/Spring can do most of
what Rails can do, it's harder to do it. I think in 5 years, there's a
good chance Java is going to be so far behind. That is why I switched.
I can see a sinking ship when it's happening.
Scala also hasn't really taken off like "everyone said it would". Ruby
seems to be that language instead. And I can understand why too - it's
being pushed far too much into academia and not into real world
problem solving/applications. Ruby understands this, Scala doesn't.
So that's where I am