5 ms·
> Higher quality code. Java is easier to refactor than Ruby, which makes up for the lower language power. Let me rephrase: "It's easier in Java to rename iden
by irahul 14y ago
> Higher quality code. Java is easier to refactor than Ruby, which makes up for the lower language power.
Let me rephrase:
"It's easier in Java to rename identifiers than ruby, because my IDE does it for me."
Now that's fine, but I don't see how do you conclude:
Easier to rename identifiers => Higher quality code. How on earth?
Easier to rename identifiers => Makes up for lower language power. What language deficiencies does renaming identifiers make up for?
Other than renaming(which can be done for ruby, though it requires manual effort), there is no refactoring which Java does better than Ruby.
> Actual concurrency!
Am curious. Where in basic web development does concurrency help? As far as servers go, evented servers(thin, mongrel) will perform as good as, if not better, than a threaded server. And evented servers can handle much more concurrent requests than threaded servers.
As far as concurrency at language level goes, very rarely have I needed to spawn a thread(I go for gevent) in the controller. Controller's job is to dispatch ASAP - everything else goes in the queue where you use EventMachine or gevent or whatever if you need concurrent processing.
> Faster server spinup and incremental changes. Rails with 20 gems in development mode is super sluggish.
Rails is more sluggish compared to "stop the world. I am compiling" Eclipse?
> Better library ecosystem!
> Better dependency management system (maven > rubygems)
As long as we are just throwing out claims without backing them, ruby library and bundler/gem are 1000x better than mvn.
> Better debuggers
> Better profilers
Not everyone is a fan of graphical everything. Going by this line of reasoning, Windows has better support for git because gui?
> Easier deployment and ops environment(java -jar myjar, vs bundle install, ruby/passenger/unicorns)
`java -jar myjar` starts your app server, your web server, minifies your css, js, migrates the db....? You can very well bundle the dependencies along with your app for rails, but I don't see why I would do it for a webapp. Also, your jar works only when you don't have java calling into native code. If you don't have native extensions, ruby is platform independent as well(i.e can be bundled).
> Reasonable in-process metrics
No ideas. What's that?
- sterwill 14y agoYour Java IDE also lets you move methods and fields, extract interfaces from concrete classes, push members up or down, find all references to a member (reliably), view inheritance relationships, and much more. And it can do all of those safely, warning you if you'll shadow another name. I wish I had that stuff in a Ruby IDE. I've used Eclipse for a long time, but not for JEE projects, and I don't see any "stop the world" behavior when it's compiling Java. Java compile jobs run at a low priority and rarely block another workspace job. If you want to save a file that's being compiled, Eclipse will let you and restart the build. Maybe you mean "stop the world I'm launching a JEE app?"
- irahul 14y ago> Your Java IDE also lets you move methods and fields, extract interfaces from concrete classes, push members up or down, find all references to a member (reliably), view inheritance relationships, and much more. And it can do all of those safely, warning you if you'll shadow another name. I wish I had that stuff in a Ruby IDE. Some of it isn't applicable to Ruby, and some of it has to be done manually. True that you will have to rely on tests or something to make sure you didn't shadow anything, or you renamed at all places, or you didn't rename something which shouldn't have been renamed. > I've used Eclipse for a long time, but not for JEE projects, and I don't see any "stop the world" behavior when it's compiling Java What machine do you use? I was using a 4 gigs, dual core machine, and eclipse regularly stalled while compiling and launching.
- sterwill 14y agoI'm usually in a 64-bit Linux VM (in VMware Workstation) on a 4 core i5 Xeon from about 3 years ago. 5 GB RAM total, Oracle Java 7 with -Xmx800M for Eclipse. My workspace includes 50 projects, most of them are Eclipse plug-ins themselves. In my experience, if Eclipse "stops the world", Java is collecting garbage. Java 6 and 7 have become much better at doing incremental collection more often (maybe parallel is the default now?) and the result is a more responsive UI. To me, Eclipse itself feels snappier over time (each release from 3.3 to 3.7 has felt better on similar hardware). Another thing I've noticed is that Eclipse is significantly faster cleaning/building large workspaces on Linux compared to Windows on the same hardware. I assume this is a result of Linux's aggressive filesystem caching.
- kamaal 14y agoI thing the core point is, Large Java application development seems to be possible/doable only because eclipse is doing 90% of the work for you. Without eclipse 90% of the Java dev work would come to a grinding halt. And that says a lot of about Java and its ecosystem. And not to mention its developers.
- democracy 14y ago''Am curious. Where in basic web development does concurrency help? As far as servers go, evented servers(thin, mongrel) will perform as good as, if not better, than a threaded server. And evented servers can handle much more concurrent requests than threaded servers.'' I don't know what is 'basic web development', but the argument 'why do we need concurrency if I rarely use it' doesn't work. I mean if you are a front-end developer/designer and mess with CSS/JS/HTML all day (without format CS education), you are probably wondering why concurrency even exists, but in real-world programming you can't go far without it.
- irahul 14y ago> I don't know what is 'basic web development', The type of web development where your controller renders a page. BTW I was quoting OP, where he mentioned he uses Java for basic web development. > I mean if you are a front-end developer/designer and mess with CSS/JS/HTML all day (without format CS education), you are probably wondering why concurrency even exists, but in real-world programming you can't go far without it. I said evented servers out-perform threaded servers. Threaded servers will eat more RAM and have higher cost of context switching. As far as application code goes, your controller isn't supposed to spawn threads(at least mine doesn't). The heavy-lifting should be done by the background services, and you can very well do concurrency in Ruby/Python(EventMachine, gevent). Generally, threaded code doesn't cut it where number of threads are large. And I am pointing this out for the second time. You ignored it all and went on a tangential regarding how I am a frontend developer/designer without formal cs education, and am wondering why concurrency even exists. > but in real-world programming you can't go far without it. Yay. No true scottsman. All programming is real world programming, and you can go far without concurrency. Are templating engines real-world programming per your certification institute?
- democracy 14y ago""Yay. No true scottsman. All programming is real world programming, and you can go far without concurrency. Are templating engines real-world programming per your certification institute?"" Oh yes, part of the real-world where concurrency (via threads) is the core of the system, not some niche sub-technology like 'slow templating PHP engine'. Now we are not talking about events vs threads, I still can't understand why someone should be stopping from starting a thread in any point of code, front-end or back-end. ""As far as concurrency at language level goes, very rarely have I needed to spawn a thread(I go for gevent) in the controller. Controller's job is to dispatch ASAP - everything else goes in the queue where you use EventMachine or gevent or whatever if you need concurrent processing."" If your language of choice is bad at threads (and threads are hard to implement, hard to use, hard to debug, we know that) then you are lucky you can use something else to hack your way out. But to push it as a normal standard way of doing things... what for? Java is great at concurrency. It also has 'event' frameworks for those who really need it for some very specific use-cases like networking (netty, grizzly,something from apache, etc ). For the majority of us? Threads do just fine...
- rabbitfang 14y agoYou do realise there is more than "renaming variables" to refactoring don't you?!?
- irahul 14y ago> You do realise there is more than "renaming variables" to refactoring don't you?!? You do read before responding, don't you? >> Other than renaming(which can be done for ruby, though it requires manual effort), there is no refactoring which Java does better than Ruby.
- rabbitfang 14y ago>> Other than renaming(which can be done for ruby, though it requires manual effort), there is no refactoring which Java does better than Ruby. Perhaps you could name this mysterious IDE which you claim provides reliable refactoring support for Ruby which is equivalent to the refactorings provided by Java IDEs? RubyMine is the best one I've seen http://www.jetbrains.com/ruby/features/index.html http://www.jetbrains.com/ruby/features/index.html, but it doesn't match what can be done in Java.
- irahul 14y ago> Perhaps you could name this mysterious IDE Is it just you, or does everyone using eclipse take "what eclipse does" to be refactoring? I didn't mention IDE even once. A small part of refactoring can be done by eclipse. Rest of it is to be done by the programmer. I am not a Fowlerian, but this is the only reference I could find. http://www.refactoring.com/catalog/index.html http://www.refactoring.com/catalog/index.html Eclipse helps with a small subset - rest has to be done by the programmer. And most of it is easier to do in Ruby than in Java. Compare the ruby edition http://www.amazon.com/Refactoring-Ruby-Edition-Jay-Fields/dp/0321603508 http://www.amazon.com/Refactoring-Ruby-Edition-Jay-Fields/dp... to the java edition http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672 http://www.amazon.com/Refactoring-Improving-Design-Existing-... On an average, ruby code ends up easier to modify and concise.
- rabbitfang 14y agoI've used both Java and Ruby and Java is by far the more advanced runtime with better support. Ruby may have much cleaner syntax than Java, but better tooling is NOT one of Ruby's strengths. Reading your post I suspect you've had very little exposure outside of Ruby.
- irahul 14y ago> Reading your post I suspect you've had very little exposure outside of Ruby. Reading your post, I see that you just throw claims around. > I've used both Java and Ruby Congratulations. You aren't the first or the only one. > Java is by far the more advanced runtime with better support. There are a lot of good things about JVM. I never contended that. > but better tooling is NOT one of Ruby's strengths. I don't remember saying it. I said "easier to refactor => high quality code" or "mvn is better at dependency management than bundler/gem"...is bullshit.
- rabbitfang 14y agoOn a large project the ability to refactor is important. Making structural changes to a large Ruby project is extremely time consuming and error prone. Pretty much anything is better at dependency management than bundler/gem. If you have to compile your dependencies at install time you're probably doing something wrong. Not to mention the version incompatibilities between gem versions and syntax changes.
- rbanffy 14y agoYou do, of course, understand that when a Ruby project gets large, it's still about 10% the size of a similarity functional Java project, right? I don't like all the magic involved in Ruby for web (in particular Rails), but it's much more concise than Java.
- thebluesky 14y agoThat doesn't mean that Ruby is so compact that it's impossible to get a large code base in it. When Ruby projects get large making changes to the code is both painful and scary (I would know since I've had to do just that).
- kamaal 14y ago>>"It's easier in Java to rename identifiers than ruby, because my IDE does it for me." This has got to be the most honest statement in this thread.