5 ms·

This is esp. true for dynamically typed languages. An IDE helps a lot more deterministically for a static typed language like Java.

• randyrand 13y ago
  This has always been my major complaint with dynamically typed languages. This and bad optimization - its a wonder that dynamic languages are so popular. GO is a good compromise though.
• mcphilip 13y ago
  I took over a large Groovy codebase that was damn near unreadable since it's controller and service layers heavily abused Groovy 'features': the def keyword (basically never defining intended types at all); not declaring return or argument types; implicit return statements; etc. My first project was to spend a few days and literally remove all possible occurrences of def and add back in return and parameter types everywhere. It was possibly the best decision I've made since it didn't involve throwing away any code and made existing code much more readable. It's just sad that the highly capable developers that wrote the original code base didn't take the extra few seconds to declare their types.
  • Roboprog 13y ago
    Groovy 2.x makes a bit of a nod in that direction. There are annotations to turn static typing on (or off) on classes and methods as needed. This allows you to be "safe" in most of the code, and explicitly label the parts with needed "magic". I agree with you that it's probably best to limit def or type-inference-like operations to local variables within functions/methods. Tangent: I like how Go does strict typing with interfaces, but still allows duck typing of parameters by not binding classes to interfaces at class definition time.
    • vorg 13y ago
      The static typing features in Groovy 2 were written by just 1 person only 1 year ago, Grails doesn't use them in its codebase, and Groovy's only other user with any traction, Gradle, still ships with Groovy 1.x. Best not to trust its features until Grails does.
      • Roboprog 13y ago
        Hmm. Thanks for the tip. I've been working on trying to graft Groovy 2.1 onto an old Java app. The static type annotations don't work with Java 1.5. You have to have at least Java 1.6. (I discovered today) So, if you have Java 1.5, you can really only use Groovy 1.x language features, as well. Otherwise, it turned out to be not so hard to start putting little Groovy seeds into a Java garden, which I'm not going to rewrite as Grails. Just being able to use closures with the Groovy Collection extensions is pretty useful.
• kyllo 13y ago
  Say what you want about Java, its awful "kingdom of nouns" paradigm, its lack of nice functional features, etc., but it is a highly readable programming language.
  • jeremyjh 13y ago
    I think all the boilerplate really does detract from the readability. Your eyes sort of glaze over and you can miss small departures from the boilerplate you expect to see.
    • kyllo 13y ago
      Perhaps, but I think the fact that it's such a boilerplate-oriented language, requiring explicit type declarations, arguments, and returns, and lacking lambda expressions, it really discourages cleverness and subtlety, making it easier to read than dynamic and functional languages. It also lacks the pointer arithmetic, bit shifting, and operator overloading of C/C++ that make those languages so difficult to read. Java may be repetitive, verbose, and dumbed-down, but that definitely keeps it from being a "write-only" language. I do agree that Go is a good compromise, very readable but with less boilerplate, and probably an improvement on the Java paradigm, but the lack of generic data structures makes it kind of hard to use Go as a Java replacement.
      • Gravityloss 13y ago
        Perhaps java is fast to read in characters per minute. But for actual functionality, I'll take something like Ruby any time.
    • crucini 13y ago
      Really? You have trouble with code like this? RegistrarInstallationsChoicesSubclass registrarInstallationsChoicesSubclass = millisDOMX509Grow.getRegistrarInstallationsChoicesSubclass(); KeyedGSSPolygons keyedGSSPolygons = new KeyedGSSPolygons(incompatibleTransliterationNoPerfCombiningContention, iSO885915ConnectionlessAsyncDiagonal, dotDataetJDIMarshallingResourceszhObservablesDiagonal, native2asciizhDelegateEnvarLearned, insertStrategyRTFLearned); keyedGSSPolygons.addISO885915ConnectionlessAsyncDiagonal(iSO885915ConnectionlessAsyncDiagonal); AppendingGuiceJustificationMarshalling appendingGuiceJustificationMarshalling = instantiatorParenthesisForeachOutlineCounted.getAppendingGuiceJustificationMarshalling(); AdaptiveReflogMerges adaptiveReflogMerges = new AdaptiveReflogMerges(); adaptiveReflogMerges.addIishCoolbarTuple(iishCoolbarTuple); AppendingGuiceJustificationMarshalling appendingGuiceJustificationMarshalling = keyedGSSPolygons.getAppendingGuiceJustificationMarshalling(); RanksPessimisticSeparableDialFirst ranksPessimisticSeparableDialFirst = new RanksPessimisticSeparableDialFirst(native2asciizhDelegateEnvarLearned, colorizeHmacComplexJanitorEnvar); ranksPessimisticSeparableDialFirst.removeIncompatibleTransliterationNoPerfCombiningContention(incompatibleTransliterationNoPerfCombiningContention); AdaptiveReflogMerges adaptiveReflogMerges = fixerAppletPerfEs.getAdaptiveReflogMerges(); ReferencerBreakingViewersvAes256RenderingsGJ referencerBreakingViewersvAes256RenderingsGJ = new ReferencerBreakingViewersvAes256RenderingsGJ(membershipDriverConsistency, iishCoolbarTuple, sectorPartsGJForking, ranksPessimisticSeparableDialFirst); referencerBreakingViewersvAes256RenderingsGJ.addISO885915ConnectionlessAsyncDiagonal(iSO885915ConnectionlessAsyncDiagonal); DitherTWSDLGraphemeInserting ditherTWSDLGraphemeInserting = cnxnsCNTWSDL.getDitherTWSDLGraphemeInserting(); Message12DL2ExposeReconcilablePerfEditionUnaligned message12DL2ExposeReconcilablePerfEditionUnaligned = new Message12DL2ExposeReconcilablePerfEditionUnaligned(dotDataetJDIMarshallingResourceszhObservablesDiagonal, sAXXMINamessvInconsistencyAnswerLoopingCommunicatorEdition, insertStrategyRTFLearned, dotDataetJDIMarshallingResourceszhObservablesDiagonal, nIDiffuseGraphemeINAes256Kind);