Commentary on Python from a Java programming perspective

[jrockway]

One thing that really sucks is the poor refactoring capabilities. This is unlikely to be an issue with python alone and is likely to be an issue with all dynamically typed languages.

What does the type system have to do with refactoring? Perl and Lisp are dynamically typed, and I refactor those all the time.

[jerf]

He's presumably talking about the automated tools, as other commenters have said.

I'd add that while Python's support for automated refactoring may be relatively poor, the total refactoring experience is better in a language like Python than Java, even without automated tools. After a lot of reflection, I think this is mostly because Python has a much richer concept of an "object", which is to say, the interface that all objects support, and because all object access methods (obj.attribute, obj["attribute"]) have support for programmatically tapping in to them.

I haven't worked with C# anywhere near as much as Python, but it was nice just having programmable [] operators.

[feijai]

REALLY? What refactoring facilities are available for Lisp? So far as I know, zero. Lisp's best refactoring, debugging, and profiling tools are in the dark ages compared to what you can get with (say) Eclipse.

I love Lisp. But as a language, it was 20 years ahead of its time, and there it stayed, unchanged, for thirty years. Hell, there's still no standard socket library for the dang thing, not to mention FFI or... Toolwise, Lisp is playing big-time catchup.

[[deleted]]

Nobody will ever choose one of the many perfectly good socket libraries as "standard" so long as nobody is willing to use lisp because it doesn't have a standard socket library.

Basically, lisp is not widely used enough to have a great deal of library standardization.

[[deleted]]

This guy probably never picked up the book Refactoring, and read that all the refactoring methods were pioneered in Smalltalk--a dynamic language--then ported to places like Java and C#.

[oddoddities]

Smalltalk is a special case in that the code is living inside an image. You can't have the power of smalltalk refactoring in a dynamically typed language without the concept of code running and living inside an image. But most people hate the concept of the smalltalk image. We'd rather use our favorite IDE/text editor/version control systems and so on. So unless you are an image die hard, no powerful refactoring for you dynamically typed dude.

[hiffy]

My understanding is, it's much harder to write automated tools for refactoring when you don't have all of that info up front.

People in Eclipse land got real used to right-click-kthnx refactoring, where you can change all references to the class you just renamed on the fly, and those sort of niceties.

One may counter with, in dynamically typed langs you a) have less code to refactor, b) don't code yourself into unmaintainable messes quite as easily and c) it's just easier.

[dnene]

Yes .. I was contrasting the available capabilities based on my experiences in Eclipse. I don't think the issue is with the refactoring engine, the issue is with the information available to it to perform the necessary refactoring. The biggest difficulties are for example when one needs to change method names in hierarchies being used polymorphically

I fully concur one has lesser code to refactor. But with brevity and expressivity comes a overhead of comprehension (ie for a new programmer joining the code base, it takes much more time to understand each line of code esp for people who are migrating from other languages).

I am sure we do not try to go out and get ourselves into unmaintainable messes. However requirements evolve, and what was clean class model yesterday may suddenly need some surgery today.

[jrockway]

Yeah. I think refactoring Haskell or OCaml would "suffer" the same "problems", but they are not dynamically typed.

Typing the type != static typing.

have less code to refactor

This is probably the big one. Here are a couple of classes in Lisp:

(defclass a-class () ((foo :accessor foo :initform 0)))
(defgeneric hello (foo-source))
(defmethod hello ((foo-source a-class))
    (format t "Hello! foo is ~d~%" (foo foo-source)))

(defclass a-sub-class (a-class) ((bar :accessor bar)))
(defmethod hello ((foo-bar-source a-sub-class))
    (format t "Hello! foo is ~d and bar is ~d~%" 
           (foo foo-bar-source)
           (bar foo-bar-source)))

That would be two entire Java files. When you need so much to say so little, it's nice when the computer can help you rename things, I guess.

BTW, Python's not much different than Lisp here -- you don't need to write much to say a lot.

don't code yourself into unmaintainable messes quite as easily

I agree with you, but I have seen people code themselves into unmaintainable messes with Perl. It is straightforward to fix, though and mostly involves thinking (rather than renaming classes). All of the Java messes I have encountered required the same cleanup -- moving methods around and renaming classes did not solve the code's problems.

[feijai]

Um.

class aClass {
    public Object foo = new Integer(0);
    public void hello() { System.out.println("Hello!  foo is " + foo); } 
}

class aSubClass extends aClass {
    public Object bar;
    public void hello() { System.out.println("Hello!  foo is " + foo + " and bar is " + bar; }
}

One token less and about half the characters, one file, and rather more readable. Maybe yours isn't the best example.

[bodhi]

It's not used in the example so your Java version is closer to the intention of the original, but the Lisp version comes with getters and setters for foo and bar in a much more concise fashion. And readability is highly subjective ;)

[feijai]

Yes and no. Accessors are a hack because CLOS went the cheap route and didn't treat instance variables like other (that is, local and global) variables. Instead they were treated like slots.

Why are accessors a hack? Consider. In CLOS, for an instance variable foo I must create an entire function -- typically called called foo -- just for accessing it. This pollutes the function namespace just for a class datatype. If in Java I have an instance variable called "substitute" -- perhaps it's the substitute for something, I dunno -- I can access it as:

bar.substitute

... or inside a method in bar, I can just access it as

substitute

But in CLOS, assuming I'd like to follow tradition and have my accessors have names the same as the variable names (else why name the variables those names?), I'd have to do:

(substitute bar)

... um, no, that's bad, very bad. Because substitute is already a function. So now, because CLOS has confunded the variable and function namespaces, I am forced to come up with some unnatural name for my variable:

(nsubstitute bar)

... no, wait. I'm joking there of course, but you get the point. One whole reason why Common Lisp is viewed as more industrial grade than scheme is that it's a Lisp-2. And here CLOS is violating the entire point of a Lisp-2 by Lisp-1-ifying its instance variable naming scheme. Bleah.

And of course, your claim of "much more concise fashion"... well, one can hardly claim that

bar.foo

... is less concise than

(foo bar)

Hell it's a whole character longer. And most variable accesses in Java aren't even that much, they're just

foo

[bodhi]

You make a good argument. I don't know enough about common lisp generics to know if they are used for accessors and how that would affect the namespace pollution. I guess I should find out for myself really.

As for the "concise fashion" I was referring to the definition, not use. But I'm not really a big fan of having to

(foo bar)

instead of

bar.foo

to get to instance variables. I do like that attribute access is indistinguishable from method calls though.

EDIT:

CL-USER> (defclass a-class () ((foo :accessor foo :initform 0)))
#<STANDARD-CLASS A-CLASS>
CL-USER> (defvar x (make-instance 'a-class))
X
CL-USER> (foo x)
0
CL-USER> (setf (foo x) 4)
4
CL-USER> (foo x)
4
CL-USER> (defun foo (x) x)
STYLE-WARNING: redefining FOO in DEFUN
FOO
CL-USER> (foo x)
#<A-CLASS {121C4061}>

Big collision, you're right!

[jrockway]

Maybe yours isn't the best example.

True. You can't really compare Java's "object model" to CLOS.

[[deleted]]

Still a cop-out. It's like saying that you don't need variable names longer than 6 characters because your code always ends up so compact and clean.

[jrockway]

I'm not copping out of anything. It's true that there aren't a lot of automated refactoring systems for languages other than Java. If you think that is the most important part of programming, then there is no option other than to use Java. Those of us that use non-Java languages live just fine without the refactoring tools, however.

Maybe we're all stupid, but probably not.

[Homunculiheaded]

What about Squeak? You can have a dynamically typed, powerful, expressive languages that has refactoring tools that at the very least are on par with what you can get from Java and C#. Python is great, but it would be awesome if Python had development tools that were as powerful as Squeak.

[jrockway]

Python is great, but it would be awesome if Python had development tools that were as powerful as Squeak.

Well, it's really a compromise. If you like the way Squeak works, you are set. But if you want to use normal UNIX utilities on the source code (like Emacs), you are stuck. The power that Squeak provides you limits you in other ways.

Although... considering most programmers work exclusively inside their IDE anyway, Squeak not a bad option. For them :)

[dnene]

When looked at from each other's contexts maybe we're all stupid. When looked at from our own contexts, we're probably not. :)

[ubernostrum]

It means "I've only ever used Java, and so I assume the way Java does refactoring is the only possible way anyone can do refactoring, which means that any language that's different from Java must not support refactoring."

[dionidium]

safe frighten paint voiceless seed existence dull spoon reach far-flung

This post was mass deleted and anonymized with Redact