Rumor has it IDEA is working on a C# version.... :) Don
On Fri, 13 Jun 2003, David Graham wrote: > >the .NET heads ( is there a term used to describe them? ) come back and say > >that it is easier and faster to build in C# then Java. They say that the > >tools to work with C# are better ( I don't agree ). > > Having worked with VS.NET and various Java IDEs I can say that .NET > developers don't know what they're missing. They might have easy gui > construction but VS is woefully lacking in ease of use and features (the > most noticeable to me is the lack of automated refactorings). > > David > > > >In fairness, we should > >not assume that .NET developers are going to skip design or write GUIs with > >no functionality. We should look at the total cost of development. > > > >I must take issue with your point that > > "It's this complexity that goes begging when UI construction is the sole > >(or even majority) measure of productivity." > > > >The fact is that as of right now you can build and maintain a GUI using > >.NET > >faster and easier (read productivity). You can build rich and complex > >functionality using C#. The building the business functionality is > >basically > >on par between Java and C#. Is it not fair to say that the productivity > >gained in the GUI construction is a clear win for .NET? > > > >If you take two groups one for Java/Struts/et. al. and one for .NET, where > >they are equally proficient in their respective technologies, and give them > >the same application to build, which will be done first? Bottom line who > >gets the job done first? The business world has decided that the .NET team > >will be done first. From what I have seen myself I have little reason to > >doubt this. > > > >I have made the argument about how much richer Java is as a language, and > >what I hear back is that the difference between Java and C# is like the > >difference between Coke and Pepsi. Again, perception is reality. > > > >Good tools do have a direct impact on development schedules. When are we > >going to have JSF and the tools to support it? Are the anti-Microsquish > >league (IBM, SUN, Oracle, et. al.) going to come up with tools to match > >.NET? > > > >Lastly, one of our teams here is writing a .NET front-end talking to Web > >Services supplied by a Java J2EE middle tier. The say they are having their > >cake and are able to eat it too. The interesting thing is they are > >succeeding and are getting their applications to the users faster and > >management has noticed. > > > >Glenn > > > > > >-----Original Message----- > >From: Chris Gerrard [mailto:[EMAIL PROTECTED] > >Sent: Friday, June 13, 2003 1:48 PM > >To: Struts Developers List > >Subject: RE: Struts can't "get its act together" - JavaPro > > > > > >Glenn, > > > >I'm continuously unimpressed by the implicit assumption that "Developer > >Productivity" == "GUI construction". The blind acceptance of this hoary old > >chestnut has been a huge impediment to real progress in developing better > >systems. > > > >Given that the rapid construction of a UI is a good thing, what's my beef? > > > >Simply put, there's a whole world of complexity behind the UI that needs to > >be conceived of, designed, and implemented before the application is > >useful. It's this complexity that goes begging when UI construction is the > >sole (or even majority) measure of productivity. > > > >There are levels of productivity. GUI building is on the surface, easy to > >see. But it's thin, and not nourishing. Real productivity lies in the > >ability to provide rich, complex functionality that supports real people in > >getting real things done. > > > >GUI tools tend to concentrate on the thin layer on top, providing some > >hardwired mechanism(s) underneath to support the UI. This is an extreme > >limitation in real productivity in that it limits the access the developers > >have to the underlying bits. Struts provides the framework that lets us > >deal with the UI and get past it into the Java world where we're really > >limited only by our own skills and knowledge. > > > >Like Vic said in his post, I provide training in Struts (and other stuff) > >to corporate clients. I recently mentored a bunch of mainframe programmers > >starting up with Java/Struts in order to reimplement their existing FoxPro > >application. It's a simple customer info collection application - get some > >info into a form, save it, find it, update it, save the changes. The UI > >side of things is straightforward with Struts, as it would be with other > >technologies. BUT, real complexity lies unspoken in the "find it" > >functionality. > > > >The naive approach is to provide a single-field input form accepting a > >client ID# which is used to look up the info. Next up is the "search form" > >approach: "Let's give them a form that looks like the input form, let them > >fill in some value(s) and then search for their info". OK, now we're > >talking. What fields are on the form? How do the values entered interact > >with one another - implicit ANDs or ORs, or do we try to give them a real > >query builder? And so it goes. Even better, as the user population gains > >experience with the application, having a flexible powerful language and > >platform underneath employed via strong, supple frameworks and > >architectures makes it much, much easier to continually improve things than > >is the case for systems built from GUI-oriented tools lacking Java's access > >to the machinery. > > > >Up until now the Java world has concentrated on core technology, and > >thereby enabled core productivity. Struts has brought us up to the surface, > >and things have always improved. I'm really hoping that JavaServer Faces > >will provide the rapid UI-building experience other tools and technologies > >enjoy. Once that happens the world will change. It'll be Java all the way > >down. > > > >Chris > > > >At 03:14 PM 6/11/2003, you wrote: > > >Chris, > > >I tend to agree with your assessment of JavaPro but I'd like to open this > >up > > >a little. Right now we are faced with two choices for web development > >.Net > > >or not .Net. I can over-simplify the arguments for and against .Net as > >the > > >following: > > > > > >.NET > > >Pluses > > >Developer Productivity > > >Negatives > > >Vendor lock in. > > > > > >Others (including Struts) > > >Pluses > > >No vendor lock in > > >Negatives > > >Less developer Productivity > > > > > >It seems like many if not most companies are more interested in developer > > >productivity. > > > > > >Does anyone know of, or foresee any means by which we (developers) will > >be > > >able to be as productive using Struts/JSP/DHTML/JavaScript etc. as people > > >are using .Net? I'd love to be able to make a case against .Net . > > > > > >Thanks > > > > > >Glenn > > > > > > > > >-----Original Message----- > > >From: Chris Gerrard [mailto:[EMAIL PROTECTED] > > >Sent: Wednesday, June 11, 2003 12:07 PM > > >To: [EMAIL PROTECTED] > > >Subject: Stuts can't "get its act together" - JavaPro > > > > > > > > >I found this announcement today on JavaPro's August Issue online "In > >Brief" > > >site: > > >http://www.ftponline.com/javapro/2003_08/magazine/departments/inbrief/defau > >l > > >t.asp > > > > > >The blurb: > > >Developer Tools > > >TurboM2 > > >Tired of waiting for The Apache Group to get its act together with the > > >Struts initiative, Virtuas has launched a framework of its own. Virtuas > > >released TurboM2 previously under the name Web Application Model (WAM). > > >Since then, the company decided to alter the product to perform many of > >the > > >features Struts offers, and like Struts will be released under the open > > >source model. > > > > > >There's more, but on casual inspection it appears that JavaPro has simply > > >regurgitated some marketing poo from Virtuas intended to convey the > > >impression that Struts is in a funk and not moving forward. (so one > >should > > >naturally move to Virtuas' TurboM2 product) > > > > > >Upon casual inspection it appears that TurboM2 is a fairly direct clone > >of > > >Struts. On of Virtuas' value-added claims is that TurboM2 has available > > >support and training that Struts does not. > > > > > >Links: > > >Virtuas TurboM2: http://www.turbom2.org/index.html > > >Struts/TurboM2 comparison: http://www.turbom2.org/docs/Comparison.pdf > > > > > >The part that disturbs me is JavaPro's presenting this whole pile as if > >it > > >were truth. Someone reading this article could well be persuaded that > >yes, > > >indeed, Struts is in trouble and they should look elsewhere. I've been > >less > > >than impressed with JavaPro's content for some time, and this erodes my > > >confidence in their editorial control and knowledge of the Java world > >even > > >further. > > > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > _________________________________________________________________ > Tired of spam? Get advanced junk mail protection with MSN 8. > http://join.msn.com/?page=features/junkmail > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
