From: Austin Ziegler Date: 2005-04-29T22:26:38+09:00 Subject: Re: Ruby and IDE On 4/28/05, Alex the_mindstorm Popescu wrote: >> From: Austin Ziegler [mailto:halostatue@gmail.com ] >> 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. >> Then you are interpreting this incorrectly, at least for Ruby. >> You can use any editor to work with Ruby. > 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 >> There is some support for Ruby in the major cross-language IDEs, >> but Ruby is a notoriously difficult language to provide full IDE >> capabilities for. > 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. >> Can you point me to a Python IDE or three? I'd like to look at >> them to see if they come close to what VisualStudio can do, even, >> for C++. > 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 # 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 -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca