Over a million developers have joined DZone.

Tooling is Holding Back Dynamic Languages

DZone's Guide to

Tooling is Holding Back Dynamic Languages

"Why Java? Tales from a Python Convert" was a huge article on the web this week. But perhaps its only tooling that's holding back dynamic languages like Python from being just as good as Java.

· Java Zone ·
Free Resource

How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.

Skip to “PyCharm’s sucky refactorings” if you don’t have much time.

Why Java? Tales from a Python Convert was discussed three times on Reddit:

Why Java? Tales from a Python Convert 109 points 68 comments submitted 3 days ago by AxiomShell to /r/java

Why Java? Tales from a Python Convert : sookocheff.com 128 points 56 comments submitted 2 days ago by javinpaul to /r/coding

Why Java? Tales from a Python Convert 20 points 42 comments submitted 3 days ago by lukaseder to /r/programming

Then there was The End of Dynamic Languages by Elben Shira, a follow up – Have Static Languages Won? by Maxime Chevalier-Boisvert, and one more – THE SKY IS NOT FALLING by Dmitri Sotnikov.

All good reads. Elben Shira focused on DSLs and then Clojure as problematic, and I think that really detracted from his strong point about dynamic languages:

“Every library function you call, unless you have it memorized, requires hunting down the source or test files for examples on how to use it”

That echos with my frustration as I am improving my Python – slower by far than my speed at developing with Java (even if ultimately the libraries are easier to use).

Example Code by the Shovelful, People!

I rely on the intellisense of the JetBrains products to get me there generally, but sometimes I’m off to google or stackoverflow for how-to. Some language/librrary/framework authors don’t like to include examples in their API documentation. Sure railroad diagrams are pretty, but if you don’t have a few examples of use inlined with your API doc you just disenfranchised significant percentage of programmers who learn exclusively by looking at good examples of use. Yes, people learn things differently. Some like tutorials, yet some no love for them. Some like API docs, yet some feel naked if that’s all they have. Some people need examples (and permutations thereof) to get there.

PyCharm’s Sucky Refactorings

Note: Jetbrains’ IDEs have been the worlds best for 16 years straight.

Here’s the high bar for refactoring – Danio Sato moving code like it were wet paint perfectly safely (ffwd 2.5 minutes to skip the explanation of the experiment). This is only 12 mins of your time, and you should be changed if you’ve never seen Intelli IDEA in action before, in the hands of an expert at least. Danilo’s blog entry on the same.

Except you can’t do more than 20% of that in PyCharm (sister product to Intellij IDEA – compiled from the same codebase).

Extract Parameter

I’ve taken Shane Engelman’s Python OO example from Github for a discussion. I’m going to try to “extract parameter” (Danilo showed that ten times or so in 12 minutes):

PyCharm knows that Dog is a subclass of Animal (look in the left margin), and that the sleep() method is overridden. Yet when I do the refactoring operation, it is only offering an optional parameter refactoring. It is not asking me if I want to make it non optional. It is not asking if I want to do it in subclasses too (related to that last). In IntelliJ I would see callers pass in “zzz”. I would have to then review the Dog usage to see if I wanted to use the parameter, given it is also doing a print with a different string (IDEs could never know my intentions re the use of that parameter).

I added a “hours” var too. I mean versus Shane Engelman’s GH version. Try to Extract-Parameter that one. PyCharm 5.0.1 does nothing at all. Weird.

There are many other refactorings that are weaker than their equivalents in IDEA. There are many refactorings that are missing too:

Solution (That Only the JetBrains Folks Can Do)

PyCharm (etc), as well as the AST it has of the parsed source, needs to retain type and usage information from the last invocation of the application/service/solution. Better still, it should glean type and usage information from invocations of tests. Python wouldn’t be Python if it has static typing adornments, but JetBrains could make perfectly hidden type info, and it would be a significant boost to PyCharm’s capabilities. The downside is the programmer using PyCharm has to run that test suite. Most likely, there would a social contract for you to run it at intervals as you are working on the codebase.

If that meta info were collected, then hovering over a variable name could cause a tool-tip that would say what type it is. Of course duck-typing might mean that a variable used at a certain scope may have one of a number of alternates of types (again collected from test runs).

A Final Reminder

If you’re not refactoring towards “most stable”, then your solution isn’t going to be maintainable in the future.

If your IDE does not have refactoring support it is pretty easy to predict that refactoring is a rare event for your team.

How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.

java ,python

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}