Forum: Ruby on Rails I forgot. Why do we hate* Java?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Peter M. (Guest)
on 2006-02-18 19:29
(Received via mailing list)
Hi,

I've started reading some Java books. Gasp! What makes website
development with Java so bad? I haven't looked at Struts but I'm
reading about Hibernate. Compared to ActiveRecord, Hibernate seems
like some extra typing to explicitly define the model fields, getters
and setters. I know that these are things that you can do in
ActiveRecord when things get complicated but generally it is not
necessary. More agility since the DDL and ORM don't duplicate. It that
the main reason we hate* Java? What are all these XML situps I've read
about? Is that a Struts issue?

Thanks,
Peter

*I realize we don't hate Java.
matthew collins (Guest)
on 2006-02-18 19:44
(Received via mailing list)
i don't *hate* java because i never learned it enough to use.

that's why i liked php for so long -- you could step into it with no
knowledge and start using it for the web, improving as you go.

whenever i looked at java, i felt like i needed to know ALL of it before
i could begin to use it.
Karl B. (Guest)
on 2006-02-18 19:53
(Received via mailing list)
Hating Java is an individual attitude.
I do not hate it at all and I think it will be around for some time.

But:  I consider Ruby (and btw. also Perl and Python) as superior to
Java as languages.
They are more expressive, more flexible and more dynamic.  You have to
write a lot in
Java to cover Java's complexity, but you should write to advance your
application.

Still, this does no way nullify the usefulness of Java for a long time
to come:
- There are a lot of legacy apps in Java.  So they are extended in Java,
apps
   around them are done in Java and apps done by the same team of
Java-guys are
   also done in Java.  For quite a time to come.  (just put Cobol for
Java and you get my point).
- Java has quite a decent performance in some cases.  Java-guys claim it
to be
   as good as C++, but I have my doubts about that.  Anyway, well done
Java-apps
   can still outperform Ruby-apps.  Be very careful with this one
though.  The
   danger is that you drown in the inherent Java-complexity and don't
get a handle
   for optimizing performance, where in the case of a Ruby app you have
much
   more time to provide quality, because development itself is much more
productive.
   If performance is such an issue, I would consider writing critical
parts of the
   application in C and combine this with Ruby.  There might be a chance
to beat
   the 100%-pure Java-app in terms of both development time and
performance.  But
   this has to be proven by experience.
- Java has very good libraries.  Ruby does not have this now, but off
course,
   rubyforge.org is growing rapidly.
- Java has a lot of "infrastructure", frameworks etc.
- Java is known by many guys, training for Java is relatively cheap and
easily
   available.
- Java-stuff is well documented.  For some Ruby-issues it is still hard
to get
   books or even online-documentation.
- Nobody has ever been fired for swimming with the well established main
stream.

As time goes on, some of these will fade away, but Java will retain at
least
some kind of Cobol-like importance in the long run.

Best regards

Karl
Peter M. (Guest)
on 2006-02-18 20:05
(Received via mailing list)
Karl Thanks for the reply. I've been thinking some of these things too.

On 2/18/06, Karl B. wrote:
> - Java has very good libraries.  Ruby does not have this now, but off course,
>    rubyforge.org is growing rapidly.

This is what is making me think Java could be faster for some
application development. Ruby may be a nicer language to program in
but you have to develop libraries along the way.

- Peter
Karl B. (Guest)
on 2006-02-18 21:03
(Received via mailing list)
Peter M. wrote:


> This is what is making me think Java could be faster for some
> application development. Ruby may be a nicer language to program in
> but you have to develop libraries along the way.

This can happen.  If you have a library that is already 80% of your app,
using java with that library becomes efficient.
Joe (Guest)
on 2006-02-18 22:18
I attended some Hibernate, Spring, and EJB3 presentations the other day
and had to hit the caffeine to keep from nodding off - slide after slide
of XML configurations. Compared to Ruby and Rails, Java just seems so
tedious and so much more work. .Net too.

Joe
David N. Welton (Guest)
on 2006-02-18 22:22
(Received via mailing list)
Peter M. wrote:

> This is what is making me think Java could be faster for some
> application development. Ruby may be a nicer language to program in
> but you have to develop libraries along the way.

One language is better for some situations... news at 11:-)

The reason I prefer Ruby, Tcl, Python, Perl et al. is that they "scale
down":

http://dedasys.com/articles/scalable_systems.html

And Rails happens to hit a sweet spot - it scales down quite well,
without being 'disorganized' or messy.  At least that's been my
experience so far.

--
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/
Karl B. (Guest)
on 2006-02-18 22:43
(Received via mailing list)
Joe wrote:
> I attended some Hibernate, Spring, and EJB3 presentations the other day
> and had to hit the caffeine to keep from nodding off - slide after slide
> of XML configurations. Compared to Ruby and Rails, Java just seems so
> tedious and so much more work. .Net too.

That's exactly the point.

But don't forget:  There are a lot of guys that have gone far to learn
all
of this stuff.  A huge investment.  So they will find a lot of good
reasons
to remain on the Java-side, just in order to justify this investment.
(c#/dotnet too, off course)
Matthew F. (Guest)
on 2006-02-18 22:49
(Received via mailing list)
"*I realize we don't hate Java."

Au contraire!
1.) wrist unfriendly
2.) wrist unfriendly



some of my little petty side  annoyances though are constantly
recompiling and an IDE bigger than X-Window and slower than a slug.
in general though, java gives you a language then you add on spring,
hibernate, maybe some JCA or JBI or some other componentization system
and yada yada yada.  its a big fractured mess of standards.

rails is nice because its just rails.  all on top of ruby, which is
wrist friendly.
Matthew F. (Guest)
on 2006-02-18 22:55
(Received via mailing list)
"As time goes on, some of these will fade away, but Java will retain at
least
some kind of Cobol-like importance in the long run."

Someone's been rocking the ITConversations.  =]

Java is pretty much at an evolutionary dead end.  Its in many ways the
culmination of C++; wrapped with garbage collection, sandboxing &
metadata.  But where Java can go now, what new and innovative could be
derived from java?  Not much,Java has basically grown to be all it can
be.

There's nothing wrong with the mainstream.  Sometimes its just more
interesting on the edge though.  Eventually, those rebels who are just
never happy with the status quo will eventually see pop eat itself,
sure enough as Cobol eventually was replaced with Java.  One
culmination replaced with another.
Nic W. (Guest)
on 2006-02-18 23:01
(Received via mailing list)
On 2/18/06, Peter M. <removed_email_address@domain.invalid> wrote:
 Compared to ActiveRecord, Hibernate seems
> like some extra typing to explicitly define the model fields, getters
> and setters. I know that these are things that you can do in
> ActiveRecord when things get complicated but generally it is not
> necessary

>From my experience, Hibernate/etc does do all the things AR does, but
AR does it *by default*. It takes time to match up every layer, decode
error messages from typos and then test your results....you are
constantly jumping from one layer to another everytime you make a
change to enforce the mapping.

With anything, you will learn faster if you can run simple tests, put
scaffolding together, and just play! As someone else mentioned, I felt
like you had to know it *all* to be able to do anything in Java.

Not to mention you have a different language for the View, JSTL
whereas erb is Ruby.

- Nic

--
- Nic
Joe (Guest)
on 2006-02-18 23:41
Karl B. wrote:
> Joe wrote:
>> I attended some Hibernate, Spring, and EJB3 presentations the other day
>> and had to hit the caffeine to keep from nodding off - slide after slide
>> of XML configurations. Compared to Ruby and Rails, Java just seems so
>> tedious and so much more work. .Net too.
>
> That's exactly the point.
>
> But don't forget:  There are a lot of guys that have gone far to learn
> all
> of this stuff.  A huge investment.  So they will find a lot of good
> reasons
> to remain on the Java-side, just in order to justify this investment.
> (c#/dotnet too, off course)

Yeah, but Java's come a long way and I think it's continuing to improve.
Technologies like Hibernate, Struts, Spring, et al ease a lot of the
pain, but I think it'll be many years, if ever, before it approaches the
succinctness and ease of Ruby and Rails.

Another reason (mentioned several times at the presentations) for
staying with Java/.Net is the professional support, which companies like
JBoss offer.

Joe
Sky Y. (Guest)
on 2006-02-19 00:11
(Received via mailing list)
>
>
> Another reason (mentioned several times at the presentations) for
> staying with Java/.Net is the professional support, which companies like
> JBoss offer.
>
>
Agreed. I'm looking forward a company like Zend or JBoss to offer
commercial
support for Rails application. This definitely would push the enterprise
adoption of Rails.
Robert Isaacs (Guest)
on 2006-02-19 00:17
(Received via mailing list)
On 2/18/06, Matthew F. <removed_email_address@domain.invalid> wrote:
>
> Java is pretty much at an evolutionary dead end.  Its in many ways the
> culmination of C++; wrapped with garbage collection, sandboxing &
> metadata.  But where Java can go now, what new and innovative could be
> derived from java?  Not much,Java has basically grown to be all it can
> be.
>

That sounds like a little bit of a lack of imagination.  The language
(java)
just got enums, annotations (attributes), generics, iterators, etc.

C# is getting implicitly typed variables, lambda expressions, query
expressions, expression trees.

To me it seems like they are really trying to bridge the productivity
gap
(or.. expressional gap) between static and dynamic languages.

Rob
Ken K. (Guest)
on 2006-02-19 01:21
(Received via mailing list)
Bruce Tate in his very interesting (and highly controversial) O'Reilly
book
_Beyond Java_ makes the case for alternatives.  It's a quick and easy
read,
not to mention a good history of how we got here.  Frankly, his book is
how
I first heard about RoR.

The biggest problem I have with Java these days is that it's so large I
never feel like I know enough to do a decent job.  There's Java itself,
of
course, then Ant, JUnit, all the J2EE specs (EJB, JMS, JSTL, JNDI, JDBC,
...), app server deployment and administration, frameworks (Hibernate,
Struts -- now Shale, JSF, Spring, Tapestry)...  The list just goes on
and
on.  I've spent years in it and still use it all the time, but RoR is so
much simpler for simple problems that it makes development fun again. :)
It's also a "full stack" solution -- everything I need is there.

That's the basics, anyway.  See the book for lots more.

Ken

--
Kenneth A. Kousen, Ph.D.
President
Kousen IT, Inc.
http://www.kousenit.com
removed_email_address@domain.invalid
Dan H. (Guest)
on 2006-02-19 03:55
(Received via mailing list)
Ken K. wrote:
> The biggest problem I have with Java these days is that it's so large I
> never feel like I know enough to do a decent job.  There's Java itself, of
> course, then Ant, JUnit, all the J2EE specs (EJB, JMS, JSTL, JNDI, JDBC,
> ...), app server deployment and administration, frameworks (Hibernate,
> Struts -- now Shale, JSF, Spring, Tapestry)...  The list just goes on and
> on.  I've spent years in it and still use it all the time, but RoR is so
> much simpler for simple problems that it makes development fun again. :)
> It's also a "full stack" solution -- everything I need is there.
>
I recently switched from Java to Rails.  I find Java is fantastic for
desktop client (only with SWT toolkit mind you) and network server
development.  As far as web development goes, I've tried many times,
using many diverse frameworks, but it's just a mess of acronyms that no
one really knows how to fully use.  In addition to this, every year or
so, a new bunch of acronyms joins the party offering so much more that
no one really understands.

Struts is terrible.  Don't even attempt to go there.  I think one of the
major drawbacks to web development in Java is that it's all bolted on.
Rails on the other hand, is designed from the ground up to be what it
is, and it does it very well.

Guys make large investments into Java because that is what it takes to
learn it, a very large investment.  It is unproductive and just not
worth it.

Dan
Roustem K. (Guest)
on 2006-02-19 07:18
(Received via mailing list)
On Saturday, February 18, 2006, at 9:26 AM, Peter M. wrote:

>*I realize we don't hate Java.

It is ok... as long as I don't have to code in it.

7 years was too much -- Now I need a long rehab:
http://www.cafepress.com/javarehab
David M. (Guest)
on 2006-02-19 08:12
(Received via mailing list)
I read somewhere that the number of bugs per line of code is
reasonably constant, across all programming languages, for a given
programmer/team.  In other words, if a team is going to average e.g. 5
bugs per 1000 lines of Java code, they'll also have ~5 bugs per 1000
lines of Ruby/Python, C#, assembler, ... code.

Given that's true, and it kind of "feels" true, the fact that RoR
accomplishes many tasks with a fraction of the code it would take for
an equivalent Java app makes the "bug-free-ness" of RoR a compelling
factor.

I know my Ruby/Rails code has many less simple-but-obscure bugs than
my Java code, but that may be because I'm a really bad Java coder.  As
an example, personally I've found that, regardless of the language
used, if a given block of code spans > 1 screen, I start to get many
more typos in that block - just being able to view an entire block of
code onscreen without scrolling seems to almost eliminate an entire
range of errors for me.

Regards

Dave M.

On 19 Feb 2006 04:45:28 -0000, Roustem K.
James L. (Guest)
on 2006-02-19 08:55
(Received via mailing list)
On 2/18/06, Dan H. <removed_email_address@domain.invalid> wrote:
> Struts is terrible.  Don't even attempt to go there.  I think one of the
> major drawbacks to web development in Java is that it's all bolted on.
> Rails on the other hand, is designed from the ground up to be what it
> is, and it does it very well.

Used properly, Struts is far from terrible.  It's actually quite a
good tool.  It also has a very steep learning curve.  Used poorly by
people who haven't made it up this curve yet, it can certainly produce
some terrible results.

I've been building enterprise web apps (for lack of a better term) in
Java for about 6 years now.  I'm also always trying to learn something
new, which is where Ruby comes in for me.  It seemed more exciting
than learning EJB 3.0 and Java 1.5.  I'll eventually have to pick
these up, but for now I'm having a good time with RoR.

-- James
Zed S. (Guest)
on 2006-02-19 16:56
(Received via mailing list)
You know it wasn't always like that with Java.  Back in the day things
were
very simple and great to use.  I know since I was one of the first
people to
write a web application in Java.  I actually used CGI before servlets
came
out, then switched to servlets since they were better.

It just started happening that vendors would create these JCP
"committees"
and create standards that helped them sell their products.  I remember
getting really pissed off when I worked on the uPortal project and
realized
that a recent version of the Servlet API removed almost all management
interfaces.  You can *still* access deprecated APIs in servlets but the
vendors removed these management interfaces with a vengeance.  I think
that
was the first example of the so called "community process" being used to
the
advantage of the vendors.

Some people I mention this to have said it has no "reality" to it, but
take
a look at the current state of things.

I have an IBM product at work called INS.  We were pretty much forced to
use
it.  This thing requires a ton of IBM software to run.  It uses WEA,
WebSphere, WebSphere Portal, maybe 10 Lotus products we have no clue
about,
and then finally INS.  It's got to be like a cool million in software
and
hardware to run this thing.  When you call to get help for it they have
to
read an org chart to tell you who to call next (since nobody at IBM can
actually just solve your problem).

We had problems installing the 5.x release and IBM had to send out a
core
INS developer from England and several of their WebSphere gurus and
still
couldn't install the thing according to the documentation.  It finally
took
them about a week to get it installed cleanly.  It also requires Windows
because of a bunch of features we don't even use.  When we run the
application it has to keep a cmd window open on the desktop and we can't
log
the administrator out.  Now that's enterprise!

What does it do?

It reads RSS feeds and sends e-mail notifications.

I'm not kidding or exaggerating here.  That's all it does.  They claim
it
does more but when you ask for these other features IBM says, "Oh, you
need
to write a connector for that."  It took our developers almost 1 month
to
just *use* the RSS connector it already has.  Writing a new connector
took
almost another 3 months.

One of our team members had a great quote about INS, "It's like you're
buying the elephant to watch it's tail wag."

The best part of this story?  We asked if just the INS part ran on Linux
without all the other crap.  IBM told us it didn't and that we had to
buy
the whole package.  I later found out that IBM actually did sell just
INS to
another company in EU that wasn't bundled and ran on Linux just fine.
They
just used INS as a means of selling a ton of crap we didn't need.

This is why there's a backlash against Java.  I don't think it's the
language as much as how vendors took Java's popularity and started
bundling
everything they possibly can or setting up the "standards" so their
products
are in a prime position to take the market.  This disregard for the end
implementers and using the JCP to sell their stuff just eventually set
the
stage for something simpler to come along and take them on.

Anyway, that's my thoughts on it.  Talk amongst yourselves.  :-)

Zed A. Shaw
http://www.zedshaw.com/
Anton K. (Guest)
on 2006-02-19 17:06
(Received via mailing list)
Offtopic:
Hello Zed. I maintain a weblog about web development in Uzbekistan and
I want to translate and post your story there. I think, it will be
very helpfull for our local managers and web developers.

So, do you mind if I do this?
Zed S. (Guest)
on 2006-02-19 18:16
(Received via mailing list)
On 2/19/06 10:05 AM, "Anton K." <removed_email_address@domain.invalid> wrote:

> Offtopic:
Hello Zed. I maintain a weblog about web development in Uzbekistan
> and
I want to translate and post your story there. I think, it will be
very
> helpfull for our local managers and web developers.

So, do you mind if I do
> this?


Go ahead.  I work for the NYC Department of Correction so I'm allowed
through American free speech laws to talk about my daily work and the
products I use as a "public worker".  In the US since tax payers pay my
salary they have a right to read and learn about my daily work and how
the
DOC operates.

Also I've never signed an NDA and that message has no trade secrets.
All
the statements are true according to my observations and I can backup
everything using IBM's own support request system (we put in a lot of
tickets) and other interactions via e-mail with IBM.  There are also
about
10 people who were connected to that project who will probably back up
what
I've said.

Basically, feel free to publish it as something I've said but don't
claim
it's your statements or else they might go after you.

Zed A. Shaw
http://www.zedshaw.com/
Anton K. (Guest)
on 2006-02-19 18:37
(Received via mailing list)
On 2/19/06, Zed S. <removed_email_address@domain.invalid> wrote:
>
> Go ahead.
>

Thanks.

>
> Basically, feel free to publish it as something I've said but don't claim
> it's your statements or else they might go after you.
>

Sure.
Joe (Guest)
on 2006-02-19 21:38
Heh, Zed's story makes me think of Java like the tax code: it's
complicated, convoluted, and boring enough to keep the tax professionals
in business and obscure just how much you're really paying. Also pointed
out at the Java presentations is that many of these open-source
technologies (like Hibernate) are simply teasers for companies' (like
JBoss) full-fledged, proprietary, for-purchase software.

Joe
Karl B. (Guest)
on 2006-02-20 00:17
(Received via mailing list)
Joe wrote:

> Also pointed
> out at the Java presentations is that many of these open-source
> technologies (like Hibernate) are simply teasers for companies' (like
> JBoss) full-fledged, proprietary, for-purchase software.

Let's stay fair: JBoss is a company, but their product (also called
JBoss) is OpenSource (LGPL).
James L. (Guest)
on 2006-02-20 03:41
(Received via mailing list)
On 2/19/06, Karl B. <removed_email_address@domain.invalid> wrote:
> Let's stay fair: JBoss is a company, but their product (also called JBoss) is OpenSource 
(LGPL).

No kidding.  To say that JBoss doesn't support open source software
shows a complete lack of understanding about this topic.  It would
make about as much sense as someone deciding that Linux is terrible
and proprietary because Red Hat offers paid support services.

-- James
Joe (Guest)
on 2006-02-20 04:17
James L. wrote:
> On 2/19/06, Karl B. <removed_email_address@domain.invalid> wrote:
>> Let's stay fair: JBoss is a company, but their product (also called JBoss) is 
OpenSource (LGPL).
>
> No kidding.  To say that JBoss doesn't support open source software
> shows a complete lack of understanding about this topic.  It would
> make about as much sense as someone deciding that Linux is terrible
> and proprietary because Red Hat offers paid support services.
>
> -- James

LOL, complete? Actually, they said it was IBM.

Joe
Joe (Guest)
on 2006-02-20 04:20
James L. wrote:
> On 2/19/06, Karl B. <removed_email_address@domain.invalid> wrote:
>> Let's stay fair: JBoss is a company, but their product (also called JBoss) is 
OpenSource (LGPL).
>
> No kidding.  To say that JBoss doesn't support open source software
> shows a complete lack of understanding about this topic.  It would
> make about as much sense as someone deciding that Linux is terrible
> and proprietary because Red Hat offers paid support services.
>
> -- James

I'll let the Java group - which consists of many enterprise developers -
know that you'll be speaking at the next meeting to inform them on just
how wrong their assertion was.

Joe
Dylan S. (Guest)
on 2006-02-20 04:29
(Received via mailing list)
Sun is Evil :)
Erik van Oosten (Guest)
on 2006-02-20 08:52
(Received via mailing list)
Zed,

You're right.
But if you avoid the JCP standards, Java can still be fun! There are
lots of nice open source libraries for almost anything that work the way
you expect them to work. Still, I must admit that having fun is a lot
easier in RoR.

But, this is a RoR list, so lets not stray too much :)

Regards,
     Erik.
Derek C. (Guest)
on 2006-02-20 14:04
(Received via mailing list)
On 18 Feb 2006, at 19:01, Karl B. wrote:

>> This is what is making me think Java could be faster for some
>> application development. Ruby may be a nicer language to program in
>> but you have to develop libraries along the way.
>
> This can happen.  If you have a library that is already 80% of your
> app,
> using java with that library becomes efficient.

Except that then you have to maintain it.
Peter M. (Guest)
on 2006-02-20 17:42
(Received via mailing list)
On 2/20/06, Derek C. <removed_email_address@domain.invalid> wrote:

> Except that then you have to maintain it.

My options are
1) writting and maintaining huge long JavaScript files to create a rich
GUI
2) Using Java Swing libraries which I won't have to maintain
Gregory S. (Guest)
on 2006-02-20 20:49
(Received via mailing list)
On Mon, Feb 20, 2006 at 07:39:43AM -0800, Peter M. wrote:
} On 2/20/06, Derek C. <removed_email_address@domain.invalid> wrote:
}
} > Except that then you have to maintain it.
}
} My options are
} 1) writting and maintaining huge long JavaScript files to create a
rich GUI

Fortunately, other people have designed good JavaScript GUI libraries.
Since they are mostly interacting with HTML and CSS, the well-written
ones
are pretty easy to understand, modify, and maintain.

} 2) Using Java Swing libraries which I won't have to maintain

...but suck greatly to develop against. Ugh. I have spent entirely too
much
of my life convincing the Swing API to produce the results I desired,
and
that doesn't count the time and effort involved in using the worst
syntactic sugar ever (anonymous classes) to implement callback code
blocks.

--Greg
Peter M. (Guest)
on 2006-02-20 21:11
(Received via mailing list)
On 2/20/06, Gregory S. <removed_email_address@domain.invalid> wrote:
> On Mon, Feb 20, 2006 at 07:39:43AM -0800, Peter M. wrote:
>
> } 1) writting and maintaining huge long JavaScript files to create a rich GUI
>
> Fortunately, other people have designed good JavaScript GUI libraries.
> Since they are mostly interacting with HTML and CSS, the well-written ones
> are pretty easy to understand, modify, and maintain.

Something that can do multiple drag and drop with auto scrolling,
resizable spreadsheet columns, menu bar, context menu, directory tree,
...?
Gregory S. (Guest)
on 2006-02-20 21:30
(Received via mailing list)
On Mon, Feb 20, 2006 at 11:11:02AM -0800, Peter M. wrote:
} On 2/20/06, Gregory S. <removed_email_address@domain.invalid> wrote:
} > On Mon, Feb 20, 2006 at 07:39:43AM -0800, Peter M. wrote:
} >
} > } 1) writting and maintaining huge long JavaScript files to create a
rich GUI
} >
} > Fortunately, other people have designed good JavaScript GUI
libraries.
} > Since they are mostly interacting with HTML and CSS, the
well-written ones
} > are pretty easy to understand, modify, and maintain.
}
} Something that can do multiple drag and drop with auto scrolling,
} resizable spreadsheet columns, menu bar, context menu, directory tree,
} ...?

A lot of that is out there. The rest should be written. I wrote a
context menu with relative ease, and repurposing it for a menu bar would
be
pretty simple. A directory tree is no problem, and I know of one that is
available commercially. I don't know what you mean by "multiple drag and
drop" unless you mean selecting multiple items then dragging them; in
that
case, it's pretty easy. Autoscrolling is a bit of work, but definitely
doable. I'm pretty sure a data table or two are out there, and I would
be
surprised if you can't resize its columns.

If you really can't find any one of those, I'd be happy to develop them
for
a small fee and release them under the LGPL.

--Greg
Peter M. (Guest)
on 2006-02-20 22:32
(Received via mailing list)
Hi Gregory,

Thanks for the responses.

Yes, probably most of it is out there in the DHTML world but I'm
getting frustrated that it is scattered, incomplete, coded with
different styles, and full of work arounds for browsers. Dealing with
CSS is not exactly a pleasure with all the different browser
compliance levels. It all just seems like a mess.

Perhaps the solution to the mess will be a for-pay company dedicated
to making a cohesive DHTML library that is coded in a uniform style.

Peter
Bill G. (Guest)
on 2006-02-20 23:58
(Received via mailing list)
On 2/20/06, Peter M. <removed_email_address@domain.invalid> wrote:
> Perhaps the solution to the mess will be a for-pay company dedicated
> to making a cohesive DHTML library that is coded in a uniform style.

Well, there is Flex (or there will be soon), but I doubt that's what
you're looking for.
http://labs.macromedia.com/

> Peter
> _______________________________________________
> Rails mailing list
> removed_email_address@domain.invalid
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
Bill G. (aka aGorilla)
The best answer to most questions is "it depends".
Peter M. (Guest)
on 2006-02-21 00:14
(Received via mailing list)
Hi Bill,

The Flex business looks like it has a nice interface. Maybe it is
Rails for Flash. I'm going to read more about it.

I bet you've started thinking "this Peter guy never gets anything done
on store.rb". Well it seems like it is true but I want to build a good
product. Especially for those who have to admin the store. I don't
want to build osCommerce or Miva for Rails.

I wonder what you think of the options for building a backend.
1) Spend the time to build the DHTML libraries necessary for a rich
gui interface.
2) Write a Java app that interfaces with the rails site by web services.

Peter
Bill G. (Guest)
on 2006-02-21 00:57
(Received via mailing list)
On 2/20/06, Peter M. <removed_email_address@domain.invalid> wrote:
> Hi Bill,
>
> The Flex business looks like it has a nice interface. Maybe it is
> Rails for Flash. I'm going to read more about it.
>
> I bet you've started thinking "this Peter guy never gets anything done
> on store.rb". Well it seems like it is true but I want to build a good
> product. Especially for those who have to admin the store. I don't
> want to build osCommerce or Miva for Rails.

Understandable, but they're both pretty successful, so they can serve as
guides.

> I wonder what you think of the options for building a backend.
> 1) Spend the time to build the DHTML libraries necessary for a rich
> gui interface.
> 2) Write a Java app that interfaces with the rails site by web services.

I'd pick 1.  Must admit, I am watching Flex since it could make a
pretty powerful admin.

> > > Yes, probably most of it is out there in the DHTML world but I'm
> > http://labs.macromedia.com/
> > Bill G. (aka aGorilla)
>
--
Bill G. (aka aGorilla)
The best answer to most questions is "it depends".
Karl B. (Guest)
on 2006-02-21 03:09
(Received via mailing list)
> 2) Write a Java app that interfaces with the rails site by web services.

Sorry, but this feels just wrong.

If you develop part of your application in Java and part of your
application in something else, why do you want to use Java
in the part where it is really causing a lot of trouble and
very expensive to use?

Swing is *very* powerful.  No doubt about that.
But it is very complex and you will need a lot of effort to tame
this beast.  You will need a lot more effort than you expect
to maintain the Java-installations on your client PCs, unless these
machines are intranet and kind of under your control.
If you do go for Java-Webstart with Swing, I think you should go
for Java on the server as well.  That saves you at least some of
the pain with the inter-language-interfaces and you can just go
for RMI, EJB, JMS etc. as communcations mechanism, which is much
easier to tame than Soap or something like that.  And it saves
you from implementing the classes that go over the network twice.

No way can you collect the benefit of RoR, if you combine it with a
Java-Swing-GUI.  If you need such a rich GUI which can't be done
with HTML, just get used to having to pay a high price for the
development.  And go for it.  It's ok, if you are honest to your
self.  It's not ok if you think you can reproduce any of the success
stories in terms of enormous productivity of RoRs-project with
this combination.  That will not work.

The combination of Ruby and Java that I actually do see is like this:
Build components providing a service using Java (or C or C++).
Think of these running on the DB-Server or Application server or so,
close to the database.  Then have a web-application in Ruby that
connects to these components to get stuff done.  This does make sense
if you have to do operations that are extremely resource hungry
so that Ruby would (today) be too slow.  You pay your price but
sometimes it is needed.

Would you see that Ruby on Rails would support this kind of architecture
already or is there still some way to go?

Best regards,

Karl
Alex Zhukov (Guest)
on 2006-02-21 03:36
(Received via mailing list)
I think I've missed the start of this topic. What was the original
web app? e-commerce?
Anyway, in my experience all fat GUI clients to manage a website suck :)
And it's not only the language or libraries that they're built in or
even the app itself.
Building a desktop GUI client is more expensive than building a web
management interface
and you will have to deal later with all kind off end user problems -
crashes, different platforms,
different setups, different runtime versions, hard-to-reproduce
segfaults or memory leaks (yeah, even in managed java or dot net
code). And then you will have to keep the clients up to
date or maintain backwards compatibility in the protocols.
It's a real pain in the ass, been there - not good.
IMO modern browsers can offer decent user experience with AJAX &
stuff. And if you
really need more advanced UI features - take a look at mozilla XUL.
It's a kind of ajax on
steroids - you can still use HTML & CSS for layout and interface and
use advanced XUL
widgets if necessary. And it can still be a web app served like an
html page from the server.

--
best regards,
Alex Zhukov
removed_email_address@domain.invalid
Derrick S. (Guest)
on 2006-02-21 07:12
(Received via mailing list)
> architecture
> already or is there still some way to go?
>
> Best regards,
>
> Karl

This is certainly a valid architecture.  The Ruby language has a
_very_ nice C extension library.  (And having wrestled with the Perl
equivalent, I can't stress the "very" hard enough).  What you would
do is develop your C service, wrap it into a Ruby library using the
extension api, and then require 'my_cool_library' in your rails app.


-Derrick S.

"[The Perl source is] an interconnected mass
of livers and pancreas and lungs and little
sharp pointy things and the occasional
exploding kidney." -Nat Torkington
Kenneth L. (Guest)
on 2006-02-21 10:01
(Received via mailing list)
These days, I've been leaning towards favoring some of the more
flexible languages/frameworks for the user-facing portions of
applications and more formal/rigid frameworks for integration with
other enterprise resources.

If we had time and budget, I'd love to redo our user interfaces with
Ruby/PHP/Ajax and have that talk to our Weblogic infrastructure, which
integrates w/ our enterprise message bus.  Too many of our apps have
been J2EE front-to-back.  While I appreciate the stricter typing,
well-defined framework, it also pains me to hear users complain about
how long it takes to do UI changes.

However, I haven't quite figured out where exactly to draw the line...
Karl B. (Guest)
on 2006-02-21 11:17
(Received via mailing list)
Derrick S. wrote:

> This is certainly a valid architecture.  The Ruby language has a  _very_
> nice C extension library.  (And having wrestled with the Perl
> equivalent, I can't stress the "very" hard enough).  What you would  do
> is develop your C service, wrap it into a Ruby library using the
> extension api, and then require 'my_cool_library' in your rails app.

I have heard it multiple times and this is something that can be useful.
The restriction is that it is based on C and it is really a drawback
against
C++ for many things.  I mean C++ used *carefully* and *in a pragmatic
way*.
I want to have Strings, Hash Tables, Arrays with dynamic length and
numbers with arbitrary precision that can be used for arithmetic with
+,-,*,...
C does not provide this in a easy to use and general way.  I know that
C++ can become a pain when it is done overly dogmatic by creating tons
of useless object just to be object oriented.  (For being fully object
oriented
I use Ruby, not C++.)  Then again, the bridge for calling C++ from C
is not trivial to my understanding.  So:  for small stuff or stuff
existing
in C the C-Api of Ruby is great.  For bigger stuff it might be
considered
to have a look at the C/C++-bridging.

But again, this is one approach.  The other one is to run the
C++-app as a daemon or service or so and to connect to it from
Ruby using Corba, RPC, XML-RPC, Soap or your homegrown
TCP/IP-communication.
Karl B. (Guest)
on 2006-02-21 11:30
(Received via mailing list)
Kenneth L. wrote:

> how long it takes to do UI changes.
>
> However, I haven't quite figured out where exactly to draw the line...

I see two approaches:
1. leave everything that is done by EJB in place and replace everything
that is done by Servlets and JSP by Ruby and Rails.  If the EJB-stuff is
pretty static or is almost completely bound to Java for some good
reasons
that is the way to go.

2. have a look at the EJBs as well.  What can be done better in Ruby,
what
can be done better in Java, what has to be done in Java?  Move some of
that
stuff to Ruby as well.  If some parts of the business logic keep
changing
rapidly and these parts are not extremely performance critical, that
might
be a good way to go.  You have to invest a lot into architecture and
documentation
in this case, because you do not follow the obvious line of 1.

I have to add something concerning Java:
A. I said EJB, but it does not have to be EJB.  You can also use Spring,
Hybernate
or a standalone Java-App.  I just assumed it is EJB in your case
already.

B. If you do a lot of numeric calculations, Java has the *huge*
disadvantage
of obfuscationg the code by the necessity to write
a = (b.multiply(c).add(d.multiply(e))
instead of
a = b*c+d*e
(unless you can work with Java's primitive types).  This really hurts
and
causes a lot of bugs.  But you can possibly get a preprocessor for Java
that allows you to write the code in a more natural way even for
BigInteger,
Rational etc.
This topic is locked and can not be replied to.