tag:blogger.com,1999:blog-37274183.post7418783150639651891..comments2024-03-14T09:39:31.551+02:00Comments on Java: Developing On The Streets: Mythbusting - Part 3 (The Inherent Paradox)Anonymoushttp://www.blogger.com/profile/15900841850889743147noreply@blogger.comBlogger29125tag:blogger.com,1999:blog-37274183.post-73839856164988765382009-03-09T12:06:00.000+02:002009-03-09T12:06:00.000+02:00Hi Itay,Much as I am loath to re-open this particu...Hi Itay,<BR/><BR/>Much as I am loath to re-open this particular nest of viper, I think it is only fair to let you know that I did revisit some of these issues in my recent <A HREF="http://www.headwaysoftware.com/blog/2009/03/travelin-lite/" REL="nofollow">Travelin' <BR/>Lite</A> post. Long gap I know but, well, I had some other stuff to be doing...<BR/><BR/>I'd tentatively like to think that you could agree with all the general points (e.g. distinction between conceptual baggage and statically detectable dependency), though you may well to choose to draw different conclusions. Also, I suspect you may find it helpful e.g. in understanding the difference between static and runtime views of the world.<BR/><BR/>For the dubious sake of posterity, I should also mention that it makes the same point on reflection as in my garbled comment above, but<BR/>(hopefully) in much clearer fashion.<BR/><BR/>Cheers,<BR/>IanAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-37274183.post-30879137538848257512008-12-07T09:37:00.000+02:002008-12-07T09:37:00.000+02:00Hi Stephan,As I wrote this piece I hoped that I cl...Hi Stephan,<BR/><BR/>As I wrote this piece I hoped that I clearly defined the context and the terms I am using. Obviously, I did a poor job.<BR/><BR/>So, I think that Lint-like tools are useful. However, if I have to choose between writing one more test vs. running PMD/Findbugs, I would go with testing.<BR/><BR/>As for cycle detection in order to allow decomposition - this is a valid usage, but my feeling is that in most cases it does not always work as expected. First, In the integration test you'd still have to test the decomposed parts together. Second, the resulting boundary lines do not always correspond to conceptual decomposition of functionality. <BR/><BR/>I feel that a tool that works in the opposite direction will be more useful: the user will draw the boundaries and the tool will decompose/refactor accordingly.Anonymoushttps://www.blogger.com/profile/15900841850889743147noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-40850036805601983252008-12-04T23:46:00.000+02:002008-12-04T23:46:00.000+02:00I've used static analyzers very successfully in th...I've used static analyzers very successfully in the past.<BR/><BR/>JDepend to find cylces (those are contrary to your post a problem. If you want to split tangled classes into different JARs, building and deploying those can be rather hard - you have to deploy all of them)<BR/><BR/>FindBugs to find bugs, mostly null pointer exceptions.<BR/><BR/>PMD to find lots of general problems with Java code.<BR/><BR/>Peace<BR/>-stephanAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-37274183.post-16603251992265217952008-12-03T15:59:00.000+02:002008-12-03T15:59:00.000+02:00It may very well be the case that a lot of the deb...It may very well be the case that a lot of the debate is about presentation. I tried to make my arguments non religious, but evidently it didn't work very well.<BR/><BR/>Anyway, to clarify things, I made my claim precise in <A HREF="http://javadots.blogspot.com/2008/12/formalizing-paradox.html" REL="nofollow">this post</A>. I believe you'll find it interesting.Anonymoushttps://www.blogger.com/profile/15900841850889743147noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-73041959063543522022008-12-03T14:03:00.000+02:002008-12-03T14:03:00.000+02:00@vinod"you're definitely talking in 2 voices - one...@vinod<BR/>"you're definitely talking in 2 voices - one in the posts thats all fire and brimstone on not just static analysis, but s101 as a poster child of that vile creed; and the other in the comments thats moderate and conciliatory."<BR/><BR/>Good phrasing, summarises the discord I felt nicely.Unknownhttps://www.blogger.com/profile/13469158397493435501noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-6191638296120641792008-12-03T09:18:00.000+02:002008-12-03T09:18:00.000+02:00Dude, you made your point two articles ago: a) sta...Dude, you made your point two articles ago: a) static analysis doesnt catch all the problems, and b) results of static analysis are misuses/misinterpreted/overrated. but that's stating the obvious - unless your posts are intended for a non-technical audience that sees static analysis as a silver bullet.<BR/><BR/>It is indeed ironic that s101 gives you the visualizations to make this case(no connection to headway, just a happy user).<BR/><BR/>anyhow, you're definitely talking in 2 voices - one in the posts thats all fire and brimstone on not just static analysis, but s101 as a poster child of that vile creed; and the other in the comments thats moderate and conciliatory. I'd suggest you let them both meet and post something more coherent, and (as suggested by others) with better examples to buttress your arguments.<BR/><BR/>Even better would be to come up with your answer for: If not static analysis, what? You've hinted that that's testing, and I'd like to see you expand that hint to an essay on how testing can completely supplant a priori analysis (of any kind), especially in the same real-world situations where approximations will be made to certify code as "tested", and true coverage is as impossible to achieve as truly untangled code :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-37274183.post-27054328310702768852008-12-03T00:51:00.000+02:002008-12-03T00:51:00.000+02:00There's a widely held management belief:"You get t...There's a widely held management belief:<BR/><BR/>"You get the behavior you incentivize."<BR/><BR/>For evidence of the truth of this statement, look at the internet bubble, or the current mortgage/banking situation.<BR/><BR/>It seems that the debate covered in the 3 parts of mythbusting is focused on the extremes of the right and wrong of "if" tools like s101 should be applied.<BR/><BR/>It seems to me that everyone would be better served talking about how best to apply tools - unless your position is that we're better off not having data/information about our code.<BR/><BR/>I agree with the point that data produced by tools is frequently misinterpreted or misused, but I find it is better to battle against those specific situations than to paint everything with a broad brush.<BR/><BR/>In my experience, s101 has been an extremely helpful tool at finding design or implementation defects, and at finding opportunities for design enhancements that allowed for greater reuse of existing code.<BR/><BR/>An underlying reason for why the code was not as good as it could have been was that our engineering community was lacking information about the structure of the code. Tools like s101 allowed us to dig thru very complex code and accomplish long standing goals by working smarter, not harder.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-37274183.post-40885201436222558042008-12-02T09:27:00.000+02:002008-12-02T09:27:00.000+02:00@Itay"The List interface does not have a removeFir...@Itay<BR/>"The List interface does not have a removeFirst() method. We will get a "method not defined" compilation error on method g()."<BR/><BR/>Ok, i assumed you'd made a mistake and wanted remove(0). I see your point in this case.<BR/><BR/>We've now moved into a discussion about the utility of static typing rather than a discussion of the utility of dependency analysis.<BR/><BR/>The reason that I feel that you haven't made a case against dependency analysis is that the examples you showed in s101 represented real (conceptual) dependency issues that existed in the various systems presented. The s101 examples you put fwd didn't do any analysis of the tangles in any way. They just showed that tangles were prevalent. This means (amongst other things) that Java packages are not strong enough to detect bad dependencies. This actually makes dependency analysis more useful in Java, as we are constrained in Java to work within the type system. Ideally dep analysis would be built into the core Java language (a la modules). And bad dependencies in those programs prevent reuse of layers and cause programs to be harder to maintain and understand.<BR/><BR/>So, we move onto a discussion of static typing in general, i agree that it does place some constraints on developers. True, it does give false +ves (unlike what i earlier claimed), as all static type systems must necessarily present an approximated (bounded) version of what is acceptable and what is not. It walks a line between convenience (automated checks) and unnecessarily constraining legitimate behaviour. Opinions obviously vary on the utility of this -- i've personally never found it to be an onerous constraint. In fact, one of the worst experiences of my life was being dumped into the middle of a large (and actually well designed) Smalltalk program. I literally had to track back through 20 methods in the calling hierarchy to determine if some of the calls should be valid. Very nasty, and it made me seriously appreciate the benefit of static typing.<BR/><BR/>I can't help but feel that part of the problem here is purely presentational. You've raised fair points about whether static typing overly constrains programs, but they come at the very end of a large set of examples that don't seem to support that point because you've done no actual analysis on whether they represent conceptual problems or just problems with static typing.<BR/><BR/>Further, you haven't shown that the legitimate cases of static overconstraining you've listed are more than side issues. i.e. it's my view that static typing provides mostly correct enforcement, leaving reflection as a way to express the small % that sits outside this. That's in the main an enormous benefit.<BR/><BR/>AndrewAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-37274183.post-42920084442422227572008-12-02T08:33:00.000+02:002008-12-02T08:33:00.000+02:00@Andrew"The 1st example you cite can be solved qui...@Andrew<BR/><BR/>"The 1st example you cite can be solved quite easily by the type system in Nice"<BR/><BR/>Of course, optional types could be of some help, but they cannot solve the general case.<BR/><BR/><A HREF="http://java.sun.com/j2se/1.4.2/docs/api/java/util/LinkedList.html#removeFirst()" REL="nofollow">LinkedList.removeFirst()</A> will throw an exception if the list is empty. <BR/><BR/>Can you devise a type system that will ensure the removeFirst() call never fails? Even on a list whose content I just read from an external data source?<BR/><BR/>"Your 2nd example compiles fine"<BR/><BR/>The List interface does not have a removeFirst() method. We will get a "method not defined" compilation error on method g().Anonymoushttps://www.blogger.com/profile/15900841850889743147noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-26704637337811139202008-12-02T01:40:00.000+02:002008-12-02T01:40:00.000+02:00@Itay"It's not clear what "positive" means in this...@Itay<BR/>"It's not clear what "positive" means in this context (can be either a compiled program or an error message) so here are two counter examples, one for each case:"<BR/><BR/>The 1st example you cite can be solved quite easily by the type system in Nice. The problem here is the weakness of Java's type system.<BR/><BR/>Your 2nd example compiles fine. Did you mean instead putting something like LinkedList of Integer? Then we get into the limitations of the java generics where this is not a subtype of LinkedList of Object. Again, a more powerful type system would solve this.<BR/><BR/>I'm not denying that there exists things outside of the scope of static analysis, i'm saying that I find these types of analysis to be extremely useful (even given that they miss things or have to defer to runtime checks), and that your examples are generally not making the point you want to make.<BR/><BR/>Andrew<BR/><BR/>p.s. apologies for the rudeness of my previous post. I got a bit worked up about it all. I still feel the same way, but that's no excuse for me not to be polite.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-37274183.post-79803966597928717682008-12-01T20:43:00.000+02:002008-12-01T20:43:00.000+02:00Those who agree with me and those who don't: There...Those who agree with me and those who don't: There's a <A HREF="http://javadots.blogspot.com/2008/12/mythbusting-part-4-reflection.html" REL="nofollow">follow-up post</A> which reflects on this discussion from a somewhat philosophical stand.Anonymoushttps://www.blogger.com/profile/15900841850889743147noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-87354783287969405612008-12-01T19:19:00.000+02:002008-12-01T19:19:00.000+02:00Itay Maman,In face of opposition, I should say tha...Itay Maman,<BR/>In face of opposition, I should say that I agree with you and the irony of your article.<BR/><BR/>I see lots of projects where:<BR/>- The client's manager wants an application while minimizing cost<BR/>- The client's technical manager wants an application maximizing technical quality (I suppose to minimize maintenance cost)<BR/>- And so, when such project is large or risky enough, a technical check is done by the client. And sometimes the client tries to use jdepend or structure101 to assess a theoretical level of quality, but these people rarely do coding and rarely understand the severity of a dependency. They do not understand limits of jdepend or structure101: for example, they give severe remarks on some static dependencies while ignoring totally runtime dependencies. The technical check is finally done with unknown criteria chosen by a tool, forgetting the initial goal.<BR/><BR/>That leads us to the irony as I understand it from client vs provider point of view (enhanced from the programmer vs architect one):<BR/>Good but incomplete products such as structure101 or jdepend are often used by providers such as me to assess a technical quality, only based on what is visible in the tool and with the minimal cost. And clients check the same result without understanding what is a problem and what they do not see.<BR/><BR/>I know that there is not much of progress when I finally argue with a client about a bit of cyclic dependencies displayed in a tool (by the way, cyclic dependencies are common in libraries used everywhere as shown in this blog)<BR/><BR/>And yes there is no objective metric of software quality.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-37274183.post-53308677045938522212008-12-01T19:05:00.000+02:002008-12-01T19:05:00.000+02:00@Andrew : "static analysis won't find eve...@Andrew : "static analysis won't find every problem (even structural) but it returns no false +ve's"<BR/><BR/>It's not clear what "positive" means in this context (can be either a compiled program or an error message) so here are two counter examples, one for each case:<BR/><BR/>1. x.f() may fail at run-time with a Null pointer exception.<BR/><BR/>2.<BR/><BR/>void f() {<BR/> LinkedList<Object> ll = new LinkedList<Object>();<BR/> ll.add(1);<BR/> g(ll); <BR/>}<BR/>void g(List<Object> lst) {<BR/> lst.removeFirst();<BR/>}<BR/><BR/>This program is dynamically correct. But it will not compile unless lst is downcsted into a LinkedList.Anonymoushttps://www.blogger.com/profile/15900841850889743147noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-39221550810236511352008-12-01T17:17:00.000+02:002008-12-01T17:17:00.000+02:00@Anonymous: "You could also say that Cobertura "en...@Anonymous: <BR/>"You could also say that Cobertura "encourages" you to evaluate a method and not check its return value just to see the code coverage percent go up."<BR/><BR/>I believe that most people are aware of shortcomings of test coverage tools. On the other hand, the shortcomings of static structural analysis are not that well understood. The most popular (false) assumption is that two unrelated packages can be changed independently.<BR/><BR/>@Peter: "stick to that argument, instead of blaming the tools as well.". <BR/><BR/>When you rely on a false premise (first argument) you get the justification to do all sorts of mistakes (second argument).<BR/><BR/>@Suereth: "Let's ignore that fact that most people don't use arrays anymore, and that with real Collections you don't need an index to iterate..."<BR/><BR/>The list is endless. synchronization, null, IllegalArgumentException, UnsupportedOperationException. When you call LinkedList.removeFirst() is your compiler telling you the list is not empty?<BR/><BR/><BR/>On a more general note. I have no problem with statements such as: "well, we know the shortcomings of the technique we are using, hence its we use it only under the following restrictions".<BR/><BR/>However, this does not seem to be the case WRT static structural analysis. (over) generalized claims seem to be common. Here are few of the trade-offs and issues that users of tools such as Structure 101 will have to consider:<BR/><BR/>(a) How much more time do I put in making my code <A HREF="http://javadots.blogspot.com/2008/11/bulletprooof-ii.html" REL="nofollow">bullerproof</A> vs writing tests?<BR/><BR/>(b) When I introduce a an interface I loose some of the (static) guarantees of a class. Here's an example:<BR/><BR/>public class IntList {<BR/> private final int h;<BR/> private final IntList t;<BR/><BR/> public IntList(int h, IntList t) {<BR/> this.h = h;<BR/> this.t = t;<BR/> }<BR/> public final int getHead() { return h; }<BR/> public final IntList getTail() { return t; }<BR/>}<BR/><BR/>This list makes the static promise of being non-cyclic. If you extract an interface out of it you will loose this guarantee. What's the trade-off between safety (using IntList) and reusability (using the interface)?<BR/><BR/>(c) To what degree do I rely on an analysis technique which cannot distinguish between gruesome code (Reflection) and legitimate code (e.g.: DSL)? <BR/><BR/>(d) Acknowledging the blind spots of static structural analysis, how do I prevent my programmers from gaming the system using *legitimate* techniques (e.g.: using DSLs all over the place)?<BR/><BR/>It all boils down to the fact that we don't have a single-, absolute-, objective-, metric of software quality (we all wish we had). Hence, we are constantly looking for approximation techniques. We must be careful not to mistake the approximation for the real thing. <BR/><BR/>Finally, here is a little thought experiment. Suppose you should decide on a reward plan for the programmer's in your company. The reward should be based on the quality of the code that each programmer produces. What's the weight that should be given to the "Lack of tangled packages" criteria?Anonymoushttps://www.blogger.com/profile/15900841850889743147noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-2677122610194990452008-12-01T15:47:00.000+02:002008-12-01T15:47:00.000+02:00It's worth mentioning 2 points:1. static analysis ...It's worth mentioning 2 points:<BR/><BR/>1. static analysis won't find every problem (even structural) but it returns no false +ve's<BR/>2. things such as spring (which push the dependencies into XML say) are also able to be statically analysed<BR/><BR/>your argument was a non-sequitur because you argue that because static analysis can't find all problems, then it is useless. this is patently not true, because every problem it finds is a real coupling problem.<BR/><BR/>Your argument about spring is spurious also. you argue in a previous article that because most things that integrate with spring have tangles, then if you want to integrate with spring you will need tangles. This thinking is so muddy. Have a look at the Spring core with S101 and you'll find that it had literally no tangles in 125kloc of code. It's astonishingly good quality. The Spring guys use s101 also, by the way.<BR/><BR/>I've got a bit angry with all of this, which is relatively rare for me. I'm a comp sci phd student with 20 yrs s/w experience including full-time work in Smalltalk and Python, and i have no commercial ties back to S101. My anger comes from poor and presumptive titling (you are so certain with little and flawed evidence), and so many of your conclusions are clearly wrong.<BR/><BR/>AndrewAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-37274183.post-77012016943125995922008-12-01T15:24:00.000+02:002008-12-01T15:24:00.000+02:00"As you know, no compiler will be able to statical..."As you know, no compiler will be able to statically detect infinite loops, breach of contracts, array-index-out-of-bounds errors"<BR/><BR/>Let's ignore that fact that most people don't use arrays anymore, and that with real Collections you don't need an index to iterate...<BR/><BR/>The crux of this argument is that "static analysis can't find x% of my problems so it's useless". A side argument is that "I program in a style that makes static analysis useless".<BR/><BR/>To the latter, I say, don't use static analysis if your coding style is that strange. Also, know where static analysis fails and understand what it tells you.<BR/><BR/>To the former, I don't know what to say. If static analysis fails to find x% of programming issues at compile time, then dynamic typing means you fail to find 100% of potential issues. Which would you prefer?<BR/><BR/>(BTW you can still test staticly-typed code, so you end up with much better coverage with the "x%" guaranteed to work and "y%" tested vs. *JUST* "y%" tested)J. Suerethhttps://www.blogger.com/profile/10176429810160937559noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-73989438921463830102008-12-01T15:08:00.000+02:002008-12-01T15:08:00.000+02:00I do think there is a delicious irony here, so for...I do think there is a delicious irony here, so forgive me if I spell out Andrew McVeigh's last point in a little more detail.<BR/><BR/>Your main argument here seems to be that you can trick static analysis tools like <A HREF="http://www.headwaysoftware.com/products/structure101" REL="nofollow">Structure101</A> by writing gruesome, verbose, unmaintainable code using reflection rather than static typing. Yet if the team leady type discovers that one of their junior programmers is producing such garbage, they can swiftly choose to outlaw it. Using ... yep you've guessed it ... static analysis: a rule to say that no-one except {exception-list} may use java.lang.reflect.*.<BR/><BR/>The wider issue of static analysis and e.g. dynamic languages is much more interesting. My basic tenet in the <A HREF="http://www.headwaysoftware.com/blog/2008/11/software-erosion-findbugs/" REL="nofollow">findbugs post</A> (which prompted your's here) was that there is clear evidence that architectural decisions were taken at various points in the evolution of the code, only for these to become blurred and ultimately lost over time. The architecture eroded. <BR/><BR/>This process (design entropy) seems to me almost inevitable as long as all we have is code/IDE on the one hand, and notional design on the other (the architect's head here, a Word doc there), but never the twain shall meet. Seems to me that this phenomenon is likely to become even more prevalent in a dynamic language code-base, though there is doubtless a counter-argument that overall progress in terms of languages, methodologies and paradigms may serve to counter-act this. For an overview of some of the questions here (albeit without the time dimension), see <A HREF="http://blogs.tedneward.com/2008/01/24/Can+Dynamic+Languages+Scale.aspx" REL="nofollow">this post</A> by Ted Neward and specifically the bit about "complexity budget".<BR/><BR/>Finally, it is not quite true to say that static analysis on dynamic languages is impossible, though I'll grant you it's harder. I think there is widespread recognition that advances here will lead to lots of useful tooling (code completion, refactoring support, bug hunting, and, of course, Structure101 and its ilk). See <A HREF="http://pystructure.ifs.hsr.ch/trac/" REL="nofollow">PyStructure</A> for an example research project (type inferencing on Python).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-37274183.post-49078734760790557882008-12-01T14:33:00.000+02:002008-12-01T14:33:00.000+02:00In the first parts you argue that tangles pose no ...In the first parts you argue that tangles pose no problems. In this part, you argue that tooling that detects tangles pose additional problems. Sure, a stupid reaction to prevent tangles will only make the problem worse, but that is a very weak argument. If you really think that tangles are not a problem, stick to that argument, instead of blaming the tools as well.<BR/><BR/>I am also lost on how Spring would encourage reflection based programming and would throw off tools like Structure101. Since all you do is injecting dependencies you still program to statically typed interfaces and classes. In fact, your example seems to prove exactly this, as the dependencies are injected using setters.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-37274183.post-60489058300920610142008-12-01T13:51:00.000+02:002008-12-01T13:51:00.000+02:00[i]However, these tools encourage you to eradicate...[i]However, these tools encourage you to eradicate the information on which they rely. In a sense, they want you to make them blind. This makes no sense.[/i]<BR/><BR/>There is one thing here making no sense and that's that line. You could also say that Cobertura "encourages" you to evaluate a method and not check its return value just to see the code coverage percent go up.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-37274183.post-79927728457575534072008-12-01T10:24:00.000+02:002008-12-01T10:24:00.000+02:00@Andrew"Yes, the static analysis can be gamed."(Pl...@Andrew<BR/>"Yes, the static analysis can be gamed."<BR/><BR/>(Please see my my reply to J. Suereth, above). <BR/><BR/>There are legitimate, mainstream, techniques (which, by the way, seem to be gaining popularity) which will game the static analyzer in the same manner as the reflection-based code.Anonymoushttps://www.blogger.com/profile/15900841850889743147noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-22180550268997617222008-12-01T09:55:00.000+02:002008-12-01T09:55:00.000+02:00@ITay"Static analyzers cannot distinguish between ...@ITay<BR/>"Static analyzers cannot distinguish between the clean solution and the awkward solution."<BR/>...<BR/>"Hence, the credibility of techniques for static dependency analysis is highly questionable."<BR/><BR/>This argument is a non-sequitur. Yes, the static analysis can be gamed. However, the static analysis is a guide to help programmers. That doesn't make it useless. For a programmer looking to static analysis to make their code better, it's very helpful. For a team lead hoping to find bad structure, combine it with reflection inspections (which are static also).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-37274183.post-91822850125118940712008-12-01T09:08:00.000+02:002008-12-01T09:08:00.000+02:00@J. Suereth "Java is not a very "strong" static la...@J. Suereth<BR/> "Java is not a very "strong" static language. Other languages could perhaps grant better help with refactoring/analyzing"<BR/><BR/>As you know, no compiler will be able to statically detect infinite loops, breach of contracts, array-index-out-of-bounds errors, etc. There will always be a great deal of dynamic complexity about which the compiler is completely ignorant.<BR/><BR/><BR/>"The java compiler can warn you were doing something stupid, just not something really stupid when you were trying to be clever (i.e. using dynamic features)"<BR/><BR/>Reflection is an extreme example of a programming techniques that has a dynamic nature (in the sense that it hides a lot of the semantics from the compiler). <BR/><BR/>Here's a partial list of viable, non awkward, techniques that has the same dynamic nature:<BR/><A HREF="http://www.c2.com/cgi/wiki?DataDrivenPrograms" REL="nofollow">data driven programming</A><BR/><A HREF="http://www.martinfowler.com/bliki/DomainSpecificLanguage.html" REL="nofollow">DSL</A><BR/><A HREF="http://steve-yegge.blogspot.com/2008/10/universal-design-pattern.html" REL="nofollow">The Properties Patterns</A><BR/><BR/>People who use these techniques are not trying to "game the system". They just want to have simpler, robust code. Static analysis of such programs is as meaningless as with reflection-based programs.Anonymoushttps://www.blogger.com/profile/15900841850889743147noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-25494873945846740862008-12-01T04:28:00.000+02:002008-12-01T04:28:00.000+02:00Two comments: 1) Java is not a very "strong" stat...Two comments: <BR/><BR/>1) Java is not a very "strong" static language. Other languages could perhaps grant better help with refactoring/analyzing your code. You're also using dynamic features of java that ignore static typing information. You have to help the compiler out sometimes to get better results. The nice thing here is that even in java, it can inform you of potential issues, even if (given some simple, arbitrary rules), it cannot fix them to your liking. I like Matthew Wilson's comment in Imperfect C++, "Make the compiler your batman." (Translated, use the compile to prevent you from screwing up)<BR/><BR/>2) The java compiler can warn you were doing something stupid, just not something really stupid when you were trying to be clever (i.e. using dynamic features). I don't see this as invalidating the entirety of static analysis, just because you used reflection and casting. It would be better to take a "good" example of static analysis and prove how dynamic casting will always beat this "good" example.<BR/><BR/>What you're really complaining about is how people "game the system" to make their metrics look good (according to automated tools) even when their not. People are lazy. That doesn't mean static analysis is not useful to programmers, it just means you shouldn't judge performance from automated metrics.<BR/><BR/>Perhaps I'll make a post doing something clearly silly in Javascript/Groovy/Ruby/Python to prove how dynamic typing is useless....J. Suerethhttps://www.blogger.com/profile/10176429810160937559noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-67889780500826510092008-12-01T01:22:00.000+02:002008-12-01T01:22:00.000+02:00Andrew, masteromd: I am sorry to disappoint you gu...Andrew, masteromd: <BR/><BR/>I am sorry to disappoint you guys, but you were so anxious to say that interfaces can be used here that you missed the irony, and consequently, this post's main point. <BR/><BR/>This post never said that reflection is the only way to solve tangled packages issues. On the contrary. The post says that (a) tangles can be solved using reflection, which clearly is an awkward solution (b) Static analyzers cannot distinguish between the clean solution and the awkward solution. <BR/><BR/>Hence, the credibility of techniques for static dependency analysis is highly questionable.Anonymoushttps://www.blogger.com/profile/15900841850889743147noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-25343048875212286412008-12-01T00:42:00.000+02:002008-12-01T00:42:00.000+02:00Your correction to the tangle problem is INCORRECT...Your correction to the tangle problem is INCORRECT. Thus, your argument fails.Anonymousnoreply@blogger.com