Tool Dependency: good, bad, nonexistent?

Discussions

News: Tool Dependency: good, bad, nonexistent?

  1. Tool Dependency: good, bad, nonexistent? (46 messages)

    In "The Kids are Alright," java.net editor Chris Adamson asks, "Let's face it: one of the most popular knocks against Java complexity, particularly EE's complexity, is the question of tools. Namely: is it wrong for something to be complex, if that complexity can be hidden or managed with tools?" It's questionable whether JavaEE really requires specific tooling, given the simplicity of so many of the revamped APIs - so the question could be better phrased as "good, bad, nonexistent?" Does JavaEE truly rely on tools, and if so, is that good or bad? Which parts of JavaEE really rely on tools? (The title follows Chris' usage of song names for titles, with this week being a week of The Who.)

    Threaded Messages (46)

  2. Depends on the tool[ Go to top ]

    And depends on how transparent things are. I mean, let's be clear. ALL we use is tools. EVERYTHING is tool dependant. Nobody here is toggling bit switches to set electrical signals and poke bytes in to RAM. So, we all rely on tools. But some tools simply get in the way. For example, Back In The Day when JEE descriptors were not XML but serialized blobs of bits. You were reliant on a SINGLE tool to get the job done, the vendors proprietary bit mixer. But when they switched to XML, all of sudden a bunch of tools became usable. You could still rely on the vendors proprietary bit (now XML) mixer. You could hack the file with ed(1), or anything in between -- including scripting, XDoclet, etc. The problem today tho, where the tools are playing more of a role, and where the real friction is showing up, is the interdependency of files. It's not enough to have file X correct, but it needs to be in sync with file Y and file Z. These relationships throw us back in the "proprietary bit mixer" mode. It's not that we can't vi individual XML files, and make them in sync, but the fact that vi isn't the total solution. With a vi, I have to edit, say, 3 files and keep them in sync. With a "custom tool", I make one change and 3 files get updated. So, while I can use vi for the task, it's a particularly lousy tool. So, what it boils down to is not the dependency on tools. That's a given. It boils down to making a system complex enough that it needs tools to be managed using proprietary tools for the platform, rather than the generic, general purpose tools that everyone is familiar with and which we can make dance on a pin. Of course, this all boils down to building "home run" systems that are supposed to simplify systems of arbitrary complexity.
  3. The JCP's fallacy of magical tools, propagated by tool vendors and other members of the JCP, has recurred many times over the years since I've been involved with Java. Every time it fools many who have no prior experience of the disillusionment that follows years of anticipating the arrival of the magic tools. When I started it was in the form of WYSIWYG tools for JSP, which eventually did sort of materialize, spearheaded by Allaire with their JRun Studio and then Macromedia with JSP support in Dreamweaver. But it literally took years. JSP, if you recall, was meant to be a technology for UI developers. JSF followed suit many years later and was designed from the outset as a technology that would absolutely require magic tool support to be realize its ultimate aims. The fallacy works like this: JCP spec authors imply or outright declare that (unnamed) tool vendors will engage in rich competition to produce powerful tools that compensate for complexity in the specifications. It is implied that just about any level of complexity is warranted and justified, as it provides a marketplace for tool vendors. It is also implied that there is a stable of tool vendors ready and waiting to digest these specs and complement them with appropriate and powerful tools, as if the specs were partially designed for the tool vendors themselves, which is rarely the case. The fallacy of magic tools is used as a rhetorical technique of persuasion by spec authors to gain endorsement and acceptance of complexity (and many other short-comings, such as incomplete specification of behavior) that might otherwise have been re-worked, refactored, discarded until a tool existed, and so on. That usable tools rarely materialize within several years of the creation of these specifications is never mentioned in the spec, as if the spec authors were willfully blind to reality.
  4. JSF followed suit many years later and was designed from the outset as a technology that would absolutely require magic tool support to be realize its ultimate aims.
    Sorry, wrong. JSF was designed from the outset as a technology that would be no problem to develop without tools (this is the way I work, and I assume many others do too), but which would also be easy to design tools for.
  5. Read the spec(s)[ Go to top ]

    I guess you haven't read the spec. You should. You will find it enlightening because it is full of allusions to magic tools and the spirit of the spec is all about frameworks and tools for poor "page authors" who, it allows, should be able, at least, to still eek out an app using a plain text editor. I read the 1.1 spec and there was really nothing usable in it for so-called "page developers" -- just a very abstract framework with a (separately downloadable) normative "specification" for HTML, CSS and Javascript component rendering. Here are words right out of the horse's mouth -- the overview section of the spec, second and third full paragraphs. See how many times tools are mentioned and take note of the bottom paragraph: "Most importantly, JSF establishes standards which are designed to be leveraged by tools to provide a developer experience which is accessible to a wide variety of developer types, ranging from corporate developers to systems programmers. A 'corporate developer' is characterized as an individual who is proficient in writing procedural code and business logic, but is not necessarily skilled in object-oriented programming. A “systems programmer” understands object-oriented fundamentals, including abstraction and designing for re-use. A corporate developer typically relies on tools for development, while a system programmer may define his or her tool as a text editor for writing code. "Therefore, JSF is designed to be tooled, but also exposes the framework and programming model as APIs so that it can be used outside of tools, as is sometimes required by systems programmers."
  6. Re: Read the spec(s)[ Go to top ]

    I guess you haven't read the spec. You should.
    I have. I make a point of ensuring that I am informed about such things before I post.
    Therefore, JSF is designed to be tooled, but also exposes the framework and programming model as APIs so that it can be used outside of tools, as is sometimes required by systems programmers.
    Which backs up what I have said. It is designed to be used outside of tools as well as with tools. It is no surprise that tools are mentioned so much - it is one of the things that was new about JSF.
    It is implied that just about any level of complexity is warranted and justified, as it provides a marketplace for tool vendors.
    You can come up with whatever interpretation you want from the spec. I actually use JSF. I have been working with it for some time. It is not complex. It is very easy to work with without tools. It is easy to design web pages with, and easy to extend. There is nothing in the spec to indicate that JSF will "absolutely require magic tool support to be realize its ultimate aims", as anyone who has used JSF for substantial projects will confirm.
  7. Re: Read the spec(s)[ Go to top ]

    Therefore, JSF is designed to be tooled, but also exposes the framework and programming model as APIs so that it can be used outside of tools, as is sometimes required by systems programmers.


    Which backs up what I have said. It is designed to be used outside of tools as well as with tools.
    No, it does not back up what you said. All it claims is extensibility. Pay attention: "it can be used outside of tools, as is sometimes required by systems programmers". In this sentence key word is "system programmers" - very different from "UI programmers that see value in manual coding". Steve, I have read many of your comments and have no doubt that you are a seasoned, strong programmer but having read your past posts regarding JSF, as well - you definitely are not objective about it. You have a very strong preference towards JSF. I understand that you have used it for a very long time and are fluent in it - hence productive, that does not mean JSF is a productive technology, per se. JSF and past specs of EJB (we still have to see how EJB3 turns out) are indeed excellent examples/proof that it is NOT ok technology to be complex and to wish tools will be able to cover up the mess.
  8. Re: Read the spec(s)[ Go to top ]

    No, it does not back up what you said. All it claims is extensibility. Pay attention: "it can be used outside of tools, as is sometimes required by systems programmers". In this sentence key word is "system programmers" - very different from "UI programmers that see value in manual coding".
    Yes, it does back up what I said. Read the original JavaServer Faces proposal. There are 8 design goals listed. Tool use is only mentioned in one of them. In the request, tool use is mentioned as something that can simplify certain tasks, not as something that is necessary for any developer to use JSF.
    I have read many of your comments and have no doubt that you are a seasoned, strong programmer but having read your past posts regarding JSF, as well - you definitely are not objective about it. You have a very strong preference towards JSF.

    I understand that you have used it for a very long time and are fluent in it - hence productive, that does not mean JSF is a productive technology, per se. JSF and past specs of EJB (we still have to see how EJB3 turns out) are indeed excellent examples/proof that it is NOT ok technology to be complex and to wish tools will be able to cover up the mess.
    Sorry, but I keep hearing this kind of thing, but with no good evidence to back it up. Exactly how is JSF supposed to be complex? To use JSF, you put tags into a page. You write POJO beans to handle the events expressed by those tags, and to provide data for the page. You list those beans and express navigation in XML files. It is very straightforward. I simply can't see how this is supposed to be so complex or unproductive, or why tools are needed to cover up any 'mess'. There is one aspect of JSF that is not that simple, and that is writing components; but most developers don't do that. Most developer use the rich sets of components out there. However, even writing components isn't too difficult - it is no big deal. I believe that JSF was marketed wrongly at the start. So many articles described in detail the various stages that JSF goes through to render pages and handle the results. This deep discussion of the inner workings of JSF made the framework look complex. It may be, but for the JSF implementor, but it isn't for the developer.
  9. Re: Read the spec(s)[ Go to top ]

    Sorry, but I keep hearing this kind of thing, but with no good evidence to back it up.
    What evidence do you need other than tons of people (and they are usually *not* members of competing frameworks) saying they find it awkward to work with? Not only on sites like this, which the majority of programmers never post comments on anyway, but also from my experience with just talking to people. Whatever the 'problem' with it is, JSF has a bad image with at least parts of the developer community. BTW, note that JSF wasn't even mentioned in the original article, but somehow it ended up in this thread :) -- Eelco
  10. Re: Read the spec(s)[ Go to top ]

    Sorry, but I keep hearing this kind of thing, but with no good evidence to back it up.


    What evidence do you need other than tons of people (and they are usually *not* members of competing frameworks) saying they find it awkward to work with? Not only on sites like this, which the majority of programmers never post comments on anyway, but also from my experience with just talking to people.
    What I am interested in is what exactly it is that is supposed to be awkward about working with JSF. I am not saying that all these developers are wrong - I am just curious about what the issues are. I accept that there is evidence that many people apparently find it awkward.
    Whatever the 'problem' with it is, JSF has a bad image with at least parts of the developer community.
    Yes, and that puzzles me. I would have thought that a framework with the features of JSF would have been welcomed with enthusiasm.
  11. Re: Read the spec(s)[ Go to top ]

    There is one aspect of JSF that is not that simple, and that is writing components; but most developers don't do that. Most developer use the rich sets of components out there. However, even writing components isn't too difficult - it is no big deal.
    I agree with the first part. Writing components in JSF is challenging. A deep understanding of the JSF model is required to do a good job of it. That's unfortunate because the real benefit of component oriented frameworks is in their ability to create reusable components that are germane to the project at hand. I hold issue with the sentiment
    most developer's don't do that.
    Most developers should do that. Writing components should be just as easy as authoring pages. If you want to boost productivity you cannot put component creation out of reach of so-called mid-level developers. That's why I settled on Tapestry. If you can write a page in Tapestry, you can write a component in Tapestry (no tools required). All developers in my shop write components and it is a huge productivity boost. My problem with JSF is not that simple everyday tasks are complex. It's that things like writing components are complex. Yes you can code JSF without tools, but it sure is easier with tools. And my contention has always been that if it requires tools to be simple, it's not really simple, is it?
  12. Re: Read the spec(s)[ Go to top ]

    It's that things like writing components are complex.

    Yes you can code JSF without tools, but it sure is easier with tools. And my contention has always been that if it requires tools to be simple, it's not really simple, is it?
    I disagree - personally, I find really do find JSF easier without tools. I don't like the idea of code generation - I prefer to explicitly set up data sources for my components and hand-code their interactions. I find code that has been generated by (for example) Studio Creator hard to maintain. So, I disagree with the general idea that JSF requires tools to be generally simple. Tools make certain things simple with JSF - quickly putting together a few pages linkes to a JDBC source for eample. But for more complex sites, I don't find any advantage. And, writing components for JSF is only really complex if you want to allow the use of multiple renderings. If you want to stick to HTML, you can use facelets, and the creating new components is trivial.
  13. Re: Read the spec(s)[ Go to top ]

    There is one aspect of JSF that is not that simple, and that is writing components; but most developers don't do that. Most developer use the rich sets of components out there.
    I entirely disagree
  14. Re: Read the spec(s)[ Go to top ]

    There is one aspect of JSF that is not that simple, and that is writing components; but most developers don't do that. Most developer use the rich sets of components out there.


    I entirely disagree
    And I disagree :) That blog entry expresses your opinion that a framework should easily allow creation of components. It contains no evidence one way or another to show that most developers do this. But anyway, JSF does not prevent component creation, but JSF components can be complex, because JSF is powerful - components can render a range of presentation methods.
  15. Re: Read the spec(s)[ Go to top ]

    That blog entry expresses your opinion that a framework should easily allow creation of components. It contains no evidence one way or another to show that most developers do this.
    Evidence? I don't think I state most developers do. But I think they should. For the reasons I expressed in that entry. But anyway, JSF does not prevent component creation, but JSF components can be complex, because JSF is powerful - components can render a range of presentation methods. Yeah, yeah, we know. Your component will not only work in web browsers, but also in terminals and with XUL. Right. It's the killer feature the world has been waiting for (...) and it something that is utterly impossible with other frameworks (...).
  16. Re: Read the spec(s)[ Go to top ]

    Evidence? I don't think I state most developers do. But I think they should. For the reasons I expressed in that entry.
    I agree with you, and you put forward good arguments. However, I simply think that most developers don't.
    Yeah, yeah, we know. Your component will not only work in web browsers, but also in terminals and with XUL. Right. It's the killer feature the world has been waiting for (...) and it something that is utterly impossible with other frameworks (...).
    It is far more than 'terminals and XUL' or whatever. Just take a look at ICEFaces for example - see how you get AJAX-enabled components with little extra effort from the developer. That is the kind of thing that the JSF component model makes easier to use. I find this an exciting feature of JSF, and think it will mean the framework will find increasing use beyond web browser clients.
  17. Re: Read the spec(s)[ Go to top ]

    It is far more than 'terminals and XUL' or whatever. Just take a look at ICEFaces for example - see how you get AJAX-enabled components with little extra effort from the developer. That is the kind of thing that the JSF component model makes easier to use. I find this an exciting feature of JSF, and think it will mean the framework will find increasing use beyond web browser clients.
    Ok. Still so many ways of achieving the same thing. For instance, in another framework, here is a plain textfield with email validation: TextField f = new TextField(this, "email"); f.add(EmailAddressPatternValidator.getInstance()); and here is how to make it do ajax validation: f.add(new AjaxFormValidatingBehavior(form, "onchange")); All the rendering, addition of javascript to the page header etc is handled by the component and underlying framework. No additional render kit nor meta data used. And creating a custom component that always does this is as simple as public class MyTextField extends TextField { public MyTextField(MarkupContainer parent, String id) { super(parent, id); add(new AjaxFormValidatingBehavior(getForm(), "onchange") } } And from then on use your custom component like: TextField foo = new MyTextField(this, "foo"); That's just one minimal example of where custom components are useful to avoid code duplication, to enforce consistency, etc. But back to the topic, my point again is that the availability of tooling for a framework should not be an excuse for certain things - like creating custom components - to be harder than if the framework wasn't build with tooling support in mind. I just don't think that is a necessity.
  18. Re: Read the spec(s)[ Go to top ]

    All the rendering, addition of javascript to the page header etc is handled by the component and underlying framework.
    Then you are missing the point. The extensibility of JSF is not about what can be already handled by the underlying framework - it is about being able to add rendering to an arbitrary range of client-side technologies - SVG, Flash, even text terminals... I chose the example of Ajax because it is a technology that is widespread.
    But back to the topic, my point again is that the availability of tooling for a framework should not be an excuse for certain things - like creating custom components - to be harder than if the framework wasn't build with tooling support in mind. I just don't think that is a necessity.
    I don't believe that creating custom components in JSF is harder because the framework is build with tooling support. The reason why creating custom components in JSF is somewhat long-winded is because of the possibility of different renderings. However, with an extension to JSF like facelets (again, extensibility is one of the great features of JSF), writing new components (albeit just for HTML) is trivial.
  19. Re: Read the spec(s)[ Go to top ]

    Then you are missing the point. The extensibility of JSF is not about what can be already handled by the underlying framework - it is about being able to add rendering to an arbitrary range of client-side technologies - SVG, Flash, even text terminals... I chose the example of Ajax because it is a technology that is widespread.
    I got that. What I tried to show is that there can be multiple ways of extensibility of framework/ components. I actually wrote a couple of XUL components for fun for that other framework a while ago (and deleted them again, as I didn't want to support them :)). SVG would be just as simple. No render kits needed. However, when I did that I came to the conclusion that it would be very unlikely that I would ever have the need to implement the exact same functionality for totally different clients (such as XUL, HTML and SVG). If I would, and the component model would really be the same, I could have MyPage.java MyPage.html MyPage.svg MyPage.xul And set the markup type according to the client type. The framework would figure out what markup to use, just like it would automatically figure out how to get MyPage_nl.html for the Dutch locale if that would be relevant. Much more likely though, I would simply have different pages/ component structures for different clients. XUL and HTML are so different, that I'd probably design the screens in quite a different way. But, if you find this renderkit thing useful for your projects, that's great. *If* you have the actual use case, I'm sure it helps a lot keeping your apps manageable.
  20. Re: Read the spec(s)[ Go to top ]

    If I would, and the component model would really be the same, I could have
    MyPage.java
    MyPage.html
    MyPage.svg
    MyPage.xul

    And set the markup type according to the client type.
    Oops, I was wrong. In that case I would likely need a different set of components too. So if being able to render the same component tree for different kinds of clients would be an actual requirement, JSF/ renderkit wins the argument. It would actually be interesting to learn how concrete of a requirement that is for people. I can't really see how the same component, with all it's potential state and behavior, could just operate in a different context and still keep the same semantics. We decided against delegating rendering of components for Wicket a long time ago, as we didn't think we'd win anything with the added complexity. Building that in however would be less than a day work, and it would make vary-ing rendering with different clients possible without too much of a hassle. It's just that the more I think about it, the more I am convinced that it wouldn't be a feature people are actually waiting for. Maybe it's time for a poll... :)
  21. Re: Read the spec(s)[ Go to top ]

    It would actually be interesting to learn how concrete of a requirement that is for people. I can't really see how the same component, with all it's potential state and behavior, could just operate in a different context and still keep the same semantics.
    Oracle have shown demonstrations of the same page running on a range of clients - a web browser, a vt100 screen... so it seems to work.
    We decided against delegating rendering of components for Wicket a long time ago, as we didn't think we'd win anything with the added complexity. ... It's just that the more I think about it, the more I am convinced that it wouldn't be a feature people are actually waiting for. Maybe it's time for a poll... :)
    I have not used Wicket, but I hear a lot of good things about it (maybe it is time I tried it out). However, regarding the rendering... I agree that it isn't a widespread requirement, but I like the idea of a framework being innovative, not reactive. I feel that JSF gives a form of security - no matter what new rendering technologies appear client-side, sites based on JSF should be able to adapt. I think it is encouraging that the JCP can (occasionally) come up with specs that are aimed at future requirements and possibilities, and not just the current majority use (HTML).
  22. Re: Read the spec(s)[ Go to top ]

    We had an app that had many many search pages and they all varied by about one field plus or minus. The team was "reusing" the same search criteria widget that was supposed to be reused for all the pages. I was the team lead and I looked at all the pages. And they looked like crap like a kid did them. Widgets just all over the place spacing all messed up, just ugly. When I asked one of the better developers why the pages looked so bad he said "We have to REUSE the search criteria widget" "And it looks bad because it doesnt resize very well when we hide or add a field and we hide/add fields in the middle of the layout or at the end or the beginning" So I said hey man! Is REUSE more important than making a page your mom wouldnt like? Are you PROUD of that? And he recoiled in horror. Reuse of something was more important than a horrible presentation that a child could see. Phony reuse became more important than the result. ANTIPATTERN! ANTIPATTERN!
  23. Re: Read the spec(s)[ Go to top ]

    man thats crap I hope you dont back up that code
  24. Re: Read the spec(s)[ Go to top ]

    I guess you haven't read the spec. You should. You will find it enlightening because it is full of allusions to magic tools and the spirit of the spec is all about frameworks and tools for poor "page authors" who, it allows, should be able, at least, to still eek out an app using a plain text editor.

    I read the 1.1 spec and there was really nothing usable in it for so-called "page developers" -- just a very abstract framework with a (separately downloadable) normative "specification" for HTML, CSS and Javascript component rendering.

    Here are words right out of the horse's mouth -- the overview section of the spec, second and third full paragraphs. See how many times tools are mentioned and take note of the bottom paragraph:

    "Most importantly, JSF establishes standards which are designed to be leveraged by tools to provide a developer experience which is accessible to a wide variety of
    developer types, ranging from corporate developers to systems programmers. A 'corporate developer' is characterized as an individual who is proficient in writing
    procedural code and business logic, but is not necessarily skilled in object-oriented programming. A “systems programmer” understands object-oriented fundamentals,
    including abstraction and designing for re-use. A corporate developer typically relies on tools for development, while a system programmer may define his or her tool as a text editor for writing code.

    "Therefore, JSF is designed to be tooled, but also exposes the framework and programming model as APIs so that it can be used outside of tools, as is sometimes required by systems programmers."
    This whole dividing of programmers into classes is disgusting, and keeping such ideas up is not helpful for companies or the industry at large. Building frameworks around this idea is wrong. It results in many fallacies, for instance the idea that you don't have to make certain areas easier (like creating custom components) because you can just call in the A-Team (whether that are 3rd party component developers or the local component god) to do that for you.
  25. When I started it was in the form of WYSIWYG tools for JSP, which eventually did sort of materialize, spearheaded by Allaire with their JRun Studio and then Macromedia with JSP support in Dreamweaver. But it literally took years. JSP, if you recall, was meant to be a technology for UI developers. JSF followed suit many years later and was designed from the outset as a technology that would absolutely require magic tool support to be realize its ultimate aims.
    You may be interested to know that Dreamweaver now supports JavaServer Faces. Ian Hlavats JSFToolbox - JavaServer Faces for Dreamweaver
  26. Learning, and risk[ Go to top ]

    If programmers can be more productive with tools than without, is that a bad thing? Do we need our libraries to always be hand-codable, at least in theory? Do we think someone is going to come in and take Eclipse and NetBeans away from us?
    The real problem with j2ee complexity is how long it takes to read and internalize the specs. Responsibile developers eventually read the specs, because that's what you need to do in order to debug the most complex issues. So it doesn't help if the spec is 1,000 pages. If you can't even tell what it does, how can you evaluate the risk in using it? A spec which is too complex is also a violation of the very good principle that simple things should be easy to do and hard things should be possible. This was true with the Java _language_ (for example, they put in garbage collection and left out operator overloading.) I would say that the design of the language is an example of leadership, whereas the design of j2ee until ejb3 is not. Rather, it looks from outside like design by committee. And ejb3 ripped off xdoclet and hibernate, which is another example of leadership. So you can see the pattern there. Tools have always existed, but tools come and go. Years ago JBuilder was all the rage, then NetBeans, and now Eclipse. Java is still only one. It's a question of risk management. Guglielmo Enjoy the Fastest Known Reliable Multicast Protocol with Total Ordering .. or the World's First Pure-Java Terminal Driver
  27. The tools and the client of that tools need to be well matched. The tool needs to have a quality and somewhere have a bare minimum version of its interface. It's good to reuse and tools are all about reuse. The best tools I find do the bare minimum things well or has a core quality aspect to it. Tool dependency is usually a necessary thing. What is nice is having some standard protocol published for a tool's basic functions upon which the tool itself is based. This means the implementation of the tool will be predictable and have predictable features with predictable formats for it's data. The more standard, the easier. What mitigates a tool's dependency is the ability to use adapters or utilize them in listeners (or both typically). This means the client of the tools doesn't need to call it directly and that's right where the problem lies.
  28. Namely: is it wrong for something to be complex, if that complexity can be hidden or managed with tools?
    Yes, it is. Complexity is wrong, no matter what, because: "Keep it simple, stupid!" Excusing oneself with the tools argument is a lame attempt of covering up mess
  29. +1
  30. I am with you on this one. The move away from EJBs back to the use of POJO is clear indication that over complicating something can not simply depend on a tool to fix it. All these lovely tools are amazing and almost create the miss guided impression that, any idiot can write software without knowning the inside working of things. This is many ways is very true of most things however, when things start go wrong, and trust me they do, very few tools in this world are going to be a substitute for knowledge.
  31. A good, solid developer with little tooling is worth about a gazillion times more than 10 barely OK developers with fantastic tooling. Experience has proven this over and over again. The problem is that people have perverted the meaning of the word "tool". Any jabronie can pick up a hammer and build a lopsided table, but is it going to be as good as a trained carpenter with that same tool? Almost certainly not. The carpenter uses the same tools, but has more fundamental knowledge and ability than the average joe. The tool is truly augmenting the underlying ability, not taking the place of it. Even if you gave the average joe a super-duper-uber-hammer of some sort that magically did a lot of the work for him, which result will be better in the long-term? Probably still the thing build by the carpenter. The same goes for software engineering. If the developer doesn't have the fundamental knowledge, all the tools are going to do is allow him to churn out more crap in a shorter period of time. I used to say tha a good developer knows, or at one point knew, Assembly to some degree. Not because Assembly is particularly relevant any more (outside a few specialized areas of course), but because it teaches you something fundamental about the machine you are programming. It sounds a little mystical I suppose, but it almost makes you "think like the computer" a little more. I always found, without exception, that developers in that category were "better" than those that didn't have that experience. Go ahead, use an IDE, use this tool or that. Use all the nifty-keen refactoring functions and such they provide, use the creators that generate all that JSF or EJB code for you. No problem. But, if you don't know what they are doing for you, if you couldn't do it yourself if you had to, and if it doesn't look like code you will want to maintain six months down the road, YOU SHOULD NOT BE USING THEM. If you don't understand the basics behind the "magic" they provide, THEY ARE NOT TOOLS. Tools imply that the user of the tool is in control. If your not, then you are doing everyone, including yourself, a disservice. And tangentially, any business that wants to hire more warm bodies and give them tooling to churn out work instead of putting in the extra effort to hire true talent, deserves the disaster they are inviting. Good luck trying to maintain the junk code you get. As for specifically whether JavaEE depends on tools, my answer would be for crap developers, yes, for those that know their a** from their elbows, no. I think overall it probably *is* too complex, but that statement doesn't have much meaning unless you answer the question: too complex for who? Let's not forget, the business wants software engineering to be easy. They want anyone with miminal training to be able to do anything. Guess what? Not gonna happen any time soon. What we do is still, regardless of what anyone wants the reality to be, more art than science. We're slowly creeping towards science of course, and that's as it should be. But that doesn't change what it is TODAY. There is skill involved, there is training involved and there is knowledge involved. But there's also still a lot of... something else. Something intaligible. That's why tooling can't take the place of basic ability: it can't address the full equation. Maybe some day we'll reduce the equation to only those parts that are concrete, at which point maybe any old business person, with their specialized business knowledge, will be able to do our jobs for us. For now though, that's not the reality, and it's not even close to the reality. Bottom line: it doesn't matter whether JavaEE is too complex or not... tooling can make a good developer better, but it can't make a crap developer acceptable. The underlying complexity doesn't matter very much in that equation.
  32. Amen[ Go to top ]

    Good points. Tools can't replace skill and understanding.
  33. Re: Amen[ Go to top ]

    Yes, this is a good point ... having said that, we cannot live with out tools. Even compilers are tools, which allowing us to write in higher-level languages. The RDBMS is a tool that abstracts out data storage and retrieval.
  34. Re: Amen[ Go to top ]

    cant live without tools? Really? Look at Appfuse the only thing even in the ballpark to compare with rails. 30 frameworks vs 2 (rails and active record) I have been developing scripted java web apps far beyond what I could do with appfuse using a text editor even though I have eclipse available. And I dont have to edit 5-10 xml/java files to do a simple web command. My command script on an avg request is a little longer than 12 lines but no much more and its all in the same file (easy maintenance). Oh and did I mention...I dont even need to compile it before I run it through the browser? And before you play the complexity card on me that the app must be so simple, well the functionality is a hell of alot more complex than these stupid db front ends we are all employed doing. I dont have to play .xml config hide and go seek to do every little thing and because I dont have to play that game I can actually produce better functionality and do it in a repeatable fashion.
  35. Tool dependency is usually bad, because it is usually unnecessary. My guess is that the possibility of tool support - like someone else in this thread said, usually more in potential than in reality - does not encourage framework authors to write the best API they can.
  36. Tool dependency is usually bad, because it is usually unnecessary. My guess is that the possibility of tool support - like someone else in this thread said, usually more in potential than in reality - does not encourage framework authors to write the best API they can.
    I could not disagree more :) Some of the most innovative and productive software development environments have been strongly dependent on tools. Perhaps the best example is Smalltalk. It is a neat language, but what makes Smalltalk implementations some of the most exciting, productive (and fun) systems to use is the phenomenal range of tools - object inspectors, debuggers, class browsers, GUI designers, refactoring browsers and so on. Once you have used such a system, trying to work without such facilities can seem painful. Try telling a typical Smalltalk developer that tool dependency is unecessary :) Well-written tools can make developers far more productive.
  37. Tool dependency is usually bad, because it is usually unnecessary. My guess is that the possibility of tool support - like someone else in this thread said, usually more in potential than in reality - does not encourage framework authors to write the best API they can.


    I could not disagree more :)

    Some of the most innovative and productive software development environments have been strongly dependent on tools. Perhaps the best example is Smalltalk. It is a neat language, but what makes Smalltalk implementations some of the most exciting, productive (and fun) systems to use is the phenomenal range of tools - object inspectors, debuggers, class browsers, GUI designers, refactoring browsers and so on. Once you have used such a system, trying to work without such facilities can seem painful.

    Try telling a typical Smalltalk developer that tool dependency is unecessary :) Well-written tools can make developers far more productive.
    I was rather surprised people didn't throw in Smalltalk with the first reply on this thread. If you think Squeak is the greatest thing since sliced bread and you think the Smalltalk language is just of minor importance compared to the environment, well...
  38. I was rather surprised people didn't throw in Smalltalk with the first reply on this thread. If you think Squeak is the greatest thing since sliced bread and you think the Smalltalk language is just of minor importance compared to the environment, well...
    I never said it was of minor importance (hence the phrase 'neat language'), and actually I don't much like Squeak! (I far prefer the more MVC-oriented traditional Smalltalks - my favourite was VisualWorks). The Smalltalk language is expressive and powerful, but there is no doubt that the innovation was the environment - the Smalltalk Image with the rich class libraries and - yes - tools. Personally, I have not found anything to match it for productivity (although IBM's VisualAge for Java came close).
  39. I never said it was of minor importance (hence the phrase 'neat language'), and actually I don't much like Squeak! (I far prefer the more MVC-oriented traditional Smalltalks - my favourite was VisualWorks).

    The Smalltalk language is expressive and powerful, but there is no doubt that the innovation was the environment - the Smalltalk Image with the rich class libraries and - yes - tools.
    Fair enough. it's something to get used to, but nice indeed. Personally I like Ambrai and F-Script a lot, because they nice to-the-point. But I haven't done any real projects with Smalltalk, so that's the humble opinion of a hobby-ist.
    Personally, I have not found anything to match it for productivity (although IBM's VisualAge for Java came close).
    But then again, did you ever try developing serious sized web applications with Smalltalk? I've played around with Seaside a bit, but didn't get further then 'nice, but...'.
  40. But I haven't done any real projects with Smalltalk, so that's the humble opinion of a hobby-ist.
    A major project with Smalltalk is quite a learning experience (in both good and bad ways! Great to develop with, but (in my experience) major performance issues.
    But then again, did you ever try developing serious sized web applications with Smalltalk? I've played around with Seaside a bit, but didn't get further then 'nice, but...'.
    No... I have also played around with Seaside, but I really don't think it is up to coping with a high-volume commercial website.
  41. No... I have also played around with Seaside, but I really don't think it is up to coping with a high-volume commercial website.
    Hmmm. I didn't profile it, so I wouldn't know. I was more concerned about team issues. My current project has a couple of developers and two html/css/designers. I wouldn't know how to work together on one project with Seaside. But that might be my lack of experience with the Smalltalk.
  42. Some of the most innovative and productive software development environments have been strongly dependent on tools. Perhaps the best example is Smalltalk. It is a neat language, but what makes Smalltalk implementations some of the most exciting, productive (and fun) systems to use is the phenomenal range of tools - object inspectors, debuggers, class browsers, GUI designers, refactoring browsers and so on. Once you have used such a system, trying to work without such facilities can seem painful.

    Try telling a typical Smalltalk developer that tool dependency is unecessary :) Well-written tools can make developers far more productive.
    Agree, though, I think tools are a great thing to have and are almost necessary in many environments right now to be more productive, I still think that the developer should know/understand what is truly going on. A good example would be code generation. Though I can't picture living without some of the stub/interface generators for some environments, it's mostly for productivity reasons, as one should know why such interfaces/stubs are generated, etc... Ilya
  43. Over and over again people are writing that JavaEE is too complex. It is not too complex, what is complex is the task it solves. Distributed transactions, clustering etc. are complex problems to solve. It is especially funny to read people that says JavaEE is complex and in the same sentence they says that Spring is the alternative. How do you measure complexity? It can't be the number of classes and interfaces of the framework since Spring has more than both J2EE 1.4 and JavaEE 5. If I get to the topic of tool dependency, there could be one of three answers. Either it is a bad thing, acceptable or a good thing. My answer would be a that it is a good thing and I will motivate my answer below. Why isn't Java EE delivering the help and reusability that was promised? The most significant answer is that developers are focusing to much och the technoloy framework and very little on the business needs. The old egyptians managed to build the magnificant pyramids by using the tools available to the fullest. The Java developer community tries to solve poorly designed systems by throwing in a new tool. So do we want building that lasts 3000 years or 20 years? So why is tool dependency good? By using tools (I mean an IDE kind of tool) there is a possibility to allow some people to work och the business objects and others work on the the technology specific part. In the original EJB spec different roles where defined. Perhaps they where not perfect but the idea is good. One of the curses of Java is that the community consists to a large part of developers that think that vi is the tool to use. Frameworks like JSF and EJB are easy to write tools for. Ant is on the other hand well accepted and can be created from Netbeans but the structure is not defined in a way so that it can be read into another IDE. To summarize: The path to better applications is to use tools that hides the complexity so that developers can concentrate on the business problem but keep the advanced features to be used when needed. If we want to be able to use tools we need frameworks that are designed for tool usage. Stop inventing new frameworks until the old ones have been used to its outer limits.
  44. From an engineer's perspective, I find two kinds of tools to be problematic: a) Tools that introduce hidden complexity b) Tools that hide complexity only by introducing new paradigms a) Suppose I have two projects in my repository: A and B. In my IDE of choice (e.g. Eclipse, IDEA), I check them out, fire up a wizard, define dependencies (B depends on A, A exports its libraries to B etc.), use the internal compiler to build the project, define configurations for tests and so on. Now, what if I want to switch to a shell, maybe to automate that process? Dependencies, compiling, testing - everything is locked up inside the IDE, and I have to start from zero. Why? Because the tool has introduced hidden complexity - in the case of Eclipse: metadata and .classpath files and a bunch of other stuff that is used only by the tool itself. (Maybe we would be better off if project specific settings in every Java IDE were represented in Ant project files...) So while the tool's functionalities may have looked convenient at first, they do not scale well with my tasks getting more and more sophisticated over time. b) Tools that successfully hide complexity are complex themselves. Hiding complexity is justified if you put layers on top of tasks that are simply unmanageable (e.g. compiling, en/decoding) or easy to automate (e.g. being able to browse through the object model of a library without having to manually uncompress or decompile anything). Whereas, a three-step-wizard that modifies a text file is not justified. You better play it straight and give me the file instead of introducing a wizard paradigm. As a developer, I am expected to be comfortable with text files. These paradigm-introducing tools tend to enforce barriers between layers, preventing developers from fiddling with the guts of the system to ensure consistency. I see that often in tools that function as frontends for complex application (like workbenches for app servers), graphical modelling environments, code generators and other applications that make hard tasks appear to be easy. If complexity is hidden this way, the developer a) is likely to fail to get a solid grasp and understanding of the system itself b) is definitely screwed if the tool contains or introduces errors. In extreme cases, depending on tools like this may cause a whole project to fail. On the other end of the complexity scale, there are small and specialized tools that enhance productivity disproportionately while keeping dependencies at a minimum. What these tools seem to have in common is well-defined boundaries, easy I/O and ingeniously simple data structures (a non-Java example being the GNU coreutils). So, while that fancy pneumatic nail-striking facility with integrated battery-driven screwdriver will definitely let you down one day, a hammer is fun for a lifetime.
  45. Re: Tool Dependency: BAD[ Go to top ]

    BAD. BAD. BAD. Having spent a good part of my career writing frameworks. And watching developers ignore or destroy them. I realized that these tools and frameworks are an excuse for knowledge and that they must die. Take any simple issue (especially in Java) and you will see how frameworks for one thing or another cloud your way or make you decide wrong. Simple issue. post and redirect in Webapps. Known technique for 7 years. Almost every java/struts app uses forwards exclusively. Why? Because combining redirects and forwards in a JSP/struts app is near suicide when delivering an app. But if you had developers who knew when to use redirect vs post and when to use get vs post on the client side and didnt have an xml framework at all it would never be a topic of discussion. Interesting that the scripters are trying to teach Java people about this when its been common knowledge for years. Tools and frameworks will not make programmers out of non-thinkers, non-knowers. Hopefully we will get over it someday and write less code as we weed out the handicapped.
  46. Re: Tool Dependency: BAD[ Go to top ]

    I bought the myeclipse pro version and I still cant figure out why Neither can anyone on my team we just did it without thinking. Somehow we all figured out that we were snowed when the plugins didnt do anything we didnt already know how to do. Thats Java. Just do it without thinking. Early on it wasnt that way. But now it is. New java programmers are unemployed VB programmers turned real estate agents turned Java programmers. And the long term guys are trying to figure out byte code manip to sell the newbies a POJO API. WOW, how far weve come.
  47. Re: Tool Dependency: BAD[ Go to top ]

    SUN has followed the model of creating a tools platform rather than providing a true development platform. This is obvious. Every new tool platform SUN comes out with has fewer and fewer takers because it conflicts with the real need to actually develop better. Eclipse is no better its a tools platform. SUN says, YEAH MAN! develop a set of web widgets! and 20 companies spawn to sell JSF stuff. SUN says, YEAH MAN! develop an ORM tool! and 20 JDO vendors fawn over it and then lose to Hibernate beholden to noone. Then SUN makes hibernate the EJB3 persistence layer. Hmmm. who won? SUN or Hibernate. Considering the amount of churn SUN produced with JDO, Gavin King won. And he didnt need a spec. Think people!