From: Austin Ziegler [mailto:
[email protected] ]
How many of your 2000 classes are *useful* classes that do real
work? How many of your 2000 classes are necessary because of the
nightmare that is Java enterprise application programming? (When
I looked at "Code Generation in Action", I was amazed at how many
classes had to be generated for a single table/view combination.)
Are we questioning here the value of the project?
No. What I'm questioning is how many of those 2,000 classes are
providing value to your project? Remember -- Java tends to require a
lot of "framework" code. Ruby requires much less. Ruby projects are
significantly smaller than Java projects that do similar things.
There was a comparison, recently, between a Java first-pass
implementation and a Ruby second-pass implementation. The Ruby one
was about a fifth the size, IIRC.
With this, the overwhelming need for an IDE for project management
is *reduced*. Not eliminated, mind you, but significantly reduced.
Yes I know this. I am not talking about writing code in notepad
;-). Surely you can do that. But efficiency is something very
important.
Yes, and as yet, I don't think that many people have found the
heavyweight nature of an IDE to be beneficial to Ruby development.
This may change. When that happens
This is the point I have agreed from the beginning. Still I
believe that with the right effort, something can be done.
I doubt it, personally. Ruby will screw things up for just about any
IDE with the mere existence of #method_missing. On the other hand,
if Ruby had a system image -- like Smalltalk -- then it would be
easier. Not easy, mind you, but easier.
I am not doing development with Python, but a branch of my co. is
using Komodo (ActiveState if I remember well) and they are happy
with it. Take a look.
I remember playing with Komodo and being unimpressed. Maybe it's
been improved. I will look at it again.
[Christian Neukirchen]
Well, you obviously forgot that Java forces you to use one file
per class (or did they change that stupid requirement recently?).
I couldn't deal with 2000 files in Emacs either, but 35 files and
the same LOC would be no problem (esp. as you focus on a handful
at once only).
sorry I don't get you. I can obviously write down a 50k source,
but is this the solution? No it is not. Every language has its own
stuff. I was not asking about doing Java dev with Ruby. Still I
can assume there are projects that are bigger than 50 sources.
What he's saying is what I said, in part. In PDF::Writer, recently,
I did the following:
class SimpleTable
class Column
...
end
...
end
To do this in Java -- especially since Column is accessible as
SimpleTable::Column (it's a full blown class, not just a nested
class, if that's even possible in Java -- it's been a long time) --
I think that I'd have to do:
simpletable.java
class SimpleTable { ... }
simpletable/column.java
class SimpleTable.Column { ... }
Forgive me if I got the syntax specifics wrong. Because Column is
something that is specific to SimpleTable (but can be created and
used separately), I can define them in the same source file. It
keeps things conceptually closer together, whereas in Java, I have
to put them in separate files, which makes things *harder* to deal
with.
Let me explain my thoughts again:
1/ I am not questioning the power of a language vs its tool
support. I think I can find good points/bad points everywhere.
Any ratio comparison will not help. There will be always very
large projects.
2/ I am not questioning the correctness of a project design.
I disagree. I can far more easily deal with a logically structured
400-class Ruby project (especially since, as would probably happen,
I would factor out those 400 classes into as many libraries, utility
classes, and modules as possible) than a 2000-class Java project.
Let's play a mental game for a moment. With a database-bound
project, you will typically need several classes per table in Java,
each of which is pretty heavy-weight (some frameworks may *help*
with this, but they don't eliminate it, AFAIK). In Ruby, you will
still need a couple of classes (presentation, ORM, etc.), but the
main code can probably be factored out into modules and utility
classes. Look at ActiveRecord. I don't agree with its chosen
"correct" semantics, but it's an amazing class nonetheless.
If you're able to take the common code and make it dynamically
generable, or dynamically extendable, then you can factor out that
common code into a library *and maintain that library separately*.
That's big. That's bigger than big. And it indicates that both (1)
and (2) in your points *matter* as far as the need for an IDE is
concerned. If your language is powerful enough (1) to make it *easy*
to break the big project into smaller parts, then the project design
changes (2).
I don't use an IDE in Ruby -- even for some big projects that I'm
working on -- because I don't *need* an IDE in Ruby. When I *need*
an IDE in Ruby, then I'll start caring. And that's where I'm really
taking issue with what you're saying: so far, Ruby doesn't *need* an
IDE.
3/ I agree dynamic typed languages are hard to support features
from static typed languages. Pls read John Wells' answer. There
is value in there ;-).
This statement is, IMO, confused. (1) John Wells' answer works only
if you can logically run the application in the IDE. (2) Dynamically
typed languages tend to support far more than statically typed
languages, but are harder for things like IDEs to support.
4/ I see the power in vim (and believe the guys talking about
Emacs power). I am only saying that I feel something more can
be done.
Maybe. I think things are being done. Ruby offers a very different
development paradigm. It's like a conversation I was having with
someone on #ruby-talk the other day. The question was raised about a
module that requires a particular method to work. For example,
Enumerable requires #each.
This person's suggestion was (roughly -- this is my interpretation)
that there should be both Enumerable and IEnumerable.
class SubclassResponsibility < RuntimeError; end
module IEnumerable
def each
raise SubclassResponsibility
end
end
module Enumerable
include IEnumerable
end
This way, when I do:
class Foo
include Enumerable
end
If I try to use #inject I will get a SubclassResponsibility error.
There's a problem, though. If Foo is a delegator class that uses
#method_missing to do delegation, I have to *manually* define #each
so that I don't get SubclassResponsibility (or I have to undef
each). Enumerable shouldn't care that #each is *defined* --
Enumerable should care that it's responded to.
Why do I need an IEnumerable that enforces the idea of sub-class
responsibility? This thing that makes it supposedly "easier" for the
module developer makes it harder for the module user. What's hard to
understand about:
irb(main):006:0> foo.inject(0)
NoMethodError: undefined method `each' for #<Foo:0x2b5eb28>
from (irb):6:in `inject'
from (irb):6
This applies to both why Ruby doesn't -- yet -- *need* an IDE and
why an IDE would be nearly impossible to use, given what's possible
in redefining Ruby.
-austin
