Everyone seems to agree that TogetherJ is big, bloated, slow tool, and they keep comparing Idea to it. Well guess what? The IntelliJ founders *left* Together because they felt the exact same thing! It's pointless to argue about Idea becoming a bloated IDE because one of the reasons the company was founded was to build the exact oppposite! They've been through it before, and they don't need us to tell them how to get it right.
And stop getting so worked up over feature suggestions! Quite frankly, the vast majority of *good* feature requests people put forth just reinforce the feature selections that IntelliJ has *already* made for the next version, and the version after that! Quit littering the list with drama, and go get some work done people! IntelliJ knows what they are doing, and all worrying about the future of Idea does is give you a stomach ulcer. Just my 2c. Jason Boehle [EMAIL PROTECTED] -----Original Message----- From: Hani Suleiman [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 5:51 PM To: [EMAIL PROTECTED] Subject: Re: [Eap-features] type 1 people are wrong > >> we don't want IDEA to be another JBuilder > > Neither do I : I left JBuilder for IDEA a few months ago. > So stop trying to switch back to the same environment, with a different product name! > > Let's remember what is the object of our love : > the CODE. > I want my code simple and clean. Why not just write simple and clean code then? IMHO the functionality present lets you ensure your code is perfectly clean, all you need is fine usages and rename and some of the other refactorings. IDEA will not, and should not dictate what makes a good developer. If a developer is unable to write clean, elegant code, then frankly, the sooner the crutches are removed from such people the better. > >> BIG=SLOW...unless you have unlimited memory. > > You could ship Tomcat, 3 JVM and the entire J2EE to the build without > making it run a tad slower. It could just become a little more > integrated, and stable. BTW, will the Tomcat integration come back > some day? > NEVER, I hope! Tomcat is the single WORST servlet engine out there. It manages to not be complaint to the spec that it was written as a reference for! Besides, IDEA developers aren't children, and frankly, I have yet to see an IDE that ships with tomcat and/or a JVM to prove that it's written for competent developers, instead of lazy ones. I like my IDE's to assume that I know what I'm doing, and provide me with tools to make my tasks easier, rather than assume I'm an idiot and can't set up simple things like a servlet engine for debugging. > > Well guys, make your choice : is it an editor, or is it an IDE. If > it's just an editor, then it's pricey, and it misses macros. If it's > an IDE, then it's OK, but it's not finished. > Like others have said, it's not a black and white situation. It's somewhere in between, and should always remain so. > I don't want a wizard to deploy to WebSpere, or create a Swing UI. > but, I'd like a simple way to create a project with enough default > stuff in it, based on its type (applet, application, web site, ..), to > make a quick start. Currently, I use a zipped skeletton with Tomcat, > JUnit, log4j, some simple templates for Velocity, that I uncompress > copy over the default project created > by IDEA. > I wouldn't. What if I don't use tomcat (which I most definitely do not, nor ever will), what if I want a logging toolkit other than log4j? Or a unit testing framework other than JUnit? What if I'm writing a full blown J2EE app that has appclients (swing), AND web/ejb components? What if I like to lay my source out in a particularly non-conformant way, and prefer to delegate bundling and packaging to an ant script? > > > To conclude, this is about CODE, CODE, CODE, and CODE. > CODE is not UML diagrams, incidentally. > > To create a new project, I could use some form of templating. Why does > IDEA only create the /src directory, and not /classes, /javadoc,... > Well, idea suggests a src directory. I don't want a /javadoc directory, so again, I'd start feeling resentful if IDEA suddenly decided that I need to generate javadocs, and tells me where to generate them to. > To understand better the code, I can use some higher level viewing > tool : > - the class/method browser > - UML class diagram > Why not use the right tool for the right job, and go to togetherJ for UML stuff? There's no implicit relationship between UML and Java, as you seem to be implying. > To refactor better, I'd need to find code hot spots, with bad smells > - dead code finder (not remover !!) Buy a source coverage tool, plenty of those exist. > - metrics based code smell detector Again, get a tool that already does the job. Picture the following scenario: - I have TogetherJ, which fits my needs perfectly for all sorts of UML modelling. - The IDEA team spends a few months perfecting UML modelling stuff. - New version of IDEA is released, with the major feature being UML modelling. Gee, after all these months, I get a feature which another product already meets, perfectly. I didn't choose IDEA because it does what other tools do. I chose it for its unique set of features, the same reason I choose all of my tools. > > To manage projects better, I'd like some more team features. > -1, more IDE integrated team features invariably means more draconian measures in enforcing that IDE on your developers. A project should allow for all developers to pick whatever tool they feel more comfortable with. > > And I didn't even mention my ideas around XP > - Acceptance tests results reporting > - Mock Objects > - construct from call on STEROIDS > http://www.intellij.com/pipermail/eap-features/2001-October/000816.html > ... Argh! -1 again. This is not an XP tool! Nor should it be! Unit testing is there because it's a good idea (even if I personally feel it doesn't really belong, but hey, that's the fun of being on the IDEA team, you get to put in stuff you think is cool!). However, the presence of unit testing does not imply that IDEA will now open the floodgates to the latest development model fad (XP, in this case). Hani _______________________________________________ Eap-features mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-features _______________________________________________ Eap-features mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-features
