A crotchety old Joel gets close.
rzwitserloot posted in programming on October 13th, 2006
Joel reviews Beyond Java here. For those not in the know, Beyond Java is a book that eschews java in favour of the recently popular scripting languages (python, ruby, you know ‘em). Joel first rightly explains that in many ways programming is just plain hard, and no magic bullet exists that will ever solve that problem.
Joel then goes on to explain ‘accidental difficulty’ - a rather obvious (but nonetheless very correct) view on what programming languages are designed to do.
But now we get to the meaty bits: Joel lists 5 crucial ‘revolutions’ in eliminating accidental difficulty, from the machine code by hand->assembler as the first, to memory managed languages (from LISP to java) as last. Joel then asks what the 6th might be… and then proceeds to bash static typing’s skull in, praising latent typing to the heavens with absolutely no arguments whatsoever.
Shame, because the 6th revolution is already here.
It’s the IDE.
Think about it: You know it’s true. LISP has it in the form of the REPL. Java has it in the form of the big 3 (Eclipse, NetBeans, IDEA).
Python and Ruby don’t have it. Both languages are designed, quite excellently I might add, to be the best most productive tools on the block if you can’t use an IDE, but their very thriftyness that makes them so good if all you get is notepad blows their legs right off in the IDE department. It’s not really the fault of python, or ruby. They were conceived well before seriously cool and useful IDEs were even a glimmer. I also strongly believe java itself sort of lucked into the whole IDE revolution. I doubt Gosling and co decided to dump conditional compilation by the wayside because they realized that NOT having any sort of dynamics whatsoever makes eclipse capable of auto-complete, guaranteed safe refactoring, javadoc popups, errors-as-you-type, and all the other fun goodness.
Latent Typing is a lame duck. It saves you some characters and that’s it. How could it possibly be a ‘revolution’? Assembler has latent typing guys - it isn’t new*.
*) Actually, assembler has both latent typing and weak typing, which means python is still a big improvement. At least you can check types at runtime in python.
October 13th, 2006 at 8:52
Did you try WingWare ? (http://wingware.com/)
It has all of the features you describe (except maybe pythondoc). Beside, the “bicycle repair man” (refactoring) has been much praised from the refactoring crowd. IPython is not a bad REPL for python…etc…
Personally, i don’t use an IDE in python because i don’t need it (I use VIM). Not because there is none.
I found an IDE more useful when working with C++ or pascal. completion does compensate a part of the typing overhead using these languages.
In these languages, I need all the need i can get because more often than not the language forced me into a design which is not the simplest logical design (so mental space is wasted on this conceptual overhead).
Some few domains needs static typing, some for speed (games), some for security (banking, transport) but they are few and far between.
L.
October 13th, 2006 at 16:18
Nope, haven’t. Good to know - if ever I am forced into working with Python again I’ll definitely have a look at it. However, I doubt it can magically perform auto-complete jobs. That just isn’t possible without some hints as to type. Maybe it works when you try something like:
x = “hello”;
x.(hit auto complete button).
De python eclipse button even tried that, and in trivial code it worked, but once the project gets beyond the ‘toying around’ stage, that just fails, monumentally. What’s the type of a parameter for example? What methods should be shown in the popup for this:
def testAutoComplete(x):
x.(hit auto complete button here).
I mean, maybe there is an answer and I’m not seeing it, but how could ANY IDE figure that one out?
There are very few python primitives that aren’t replicatable in java. e.g. java has closures (anonymous inner classes. Yeah, I know, the syntax is besodded ridiculous, but proposals are on the way to address that oversight. If you look beyond the wordy syntax it’s a closures with all bells and whistles (context from outside the closure is accessible).
Certain limited areas where ‘yield’ is used cannot be easily re-created in java short of employing an unneccessary thread as a placeholder for continuation, but I doubt that’s what forcing you into mental space wasted.
October 14th, 2006 at 5:59
Ruby and Python were invented at a time when Smalltalk IDEs already did exist. The designers of these languages chose to ignore IDEs, for whatever reason. Sophisticated IDEs exist for Lisp (Emacs with SLIME gives you auto-completion, cross-referencing, go to definition, etc) and LispWorks (commercial) has even more.
Your auto-completion example only fails because in Python and Ruby methods sit “inside” classes. I believe this model is flawed, regardless of what type system is being used. In languages where functions are top-level entities (scoped by modules) this is not a problem, you can have auto-completion, error checking and so on.
I’m not a big fan of Python and Ruby either but please do not confuse these two with the entire realm of possibility found in dynamic typing.
October 14th, 2006 at 16:09
Slava: Hey! Your name looks familiar. JEdit right? I used that for 2 years before I moved to eclipse. I still recommend it, even. Welcome!
I checked my timelines and you’re absolutely right. Smalltalk’s IDEs had plenty of intriguing features well before 1990. LISP is so far removed from grokkable code that I can understand someone basically looking to create the new Visual Basic doesn’t consider anything interesting about it, but smalltalk gives no such excuses; it’s very easy to read even if you don’t know the language.
You’re right in that language design can alleviate problems caused by latent typing, but you then end up in the unfortunate situation that you start trading readability and flexibility so that your IDE can start helping you. This is normal; java has done it all the time (precompiler statements sure are flexible, Linux is pretty much built on top of them, but java doesn’t have them and can’t), but I wonder if the costs outweigh the benefits here. While you can then auto-complete on function names, there’s still the issue of parameter types - also a very useful thing to have in auto-complete, and a very useful thing to have checked as you write your code. Still wouldn’t work as long as you’re on latent types.
Also note that I’m bashing latent typing. Dynamic typing is technically different. You could for example go with extreme inference, like boo does. Feels like python but everything has a type that’s set in stone at compile-time. It’s just that the moment you add a second return statement to your code, this time with a double instead of an integer, the semantics of the language now dictate that the return type of your method is now ‘number’ instead of ‘integer’, because that’s the ‘greatest common divisor’ of all your return statements.
I hear boo has various clunks, but there’s no reason why a language couldn’t have this kind of inference to help you along. I even imagine a ‘mode’ in eclipse for writing java like that. Eclipse shows you one ‘view’ of the code, mostly stripped of details like exception lists, types, and a couple of other details, and silently maintains a full blown java version on the side. My main beef remains with not having any useful way of figuring out the types of things at compile time. What’s the BENEFIT, I wonder? I know the penalties are enormous. Benefits? I don’t really know of any that aren’t trivially beneficial.
October 14th, 2006 at 20:02
Basically, I think that in theory, static typing is great. I mean, who doesn’t want to find bugs ahead of time, get a bit of free documentation, simpler completion, performance, etc? However in practice, no static type system I’ve used is really expressive enough to be able to typecheck the code I want to write. In Factor, I do document parameter types, however the “types” are often not formal type specifiers in the language, but some kind of “protocol” which objects support. Also dynamic typing makes it that much easier to reload code on the fly without a recompile/restart cycle, inspect objects in the running system, and do meta-programming, all of which are important to my development style. YMMV.
October 14th, 2006 at 20:23
By the way, dynamic typing and latent typing is the same thing. Boo is not dynamically typed — it uses static type inference (just like Haskell, Ocaml, etc).
October 15th, 2006 at 0:08
Hmm, well, what do you call a system whereby you do not have to explicitly type all your variables without implying anything specific about eg aggressive inference?
I’m sure you know about Haskell. That’s a very intense typing system. What I’d like to see at some point is a sublanguage which is not turing complete, but halting problem capable. In this sublanguage you can go quite far in expressing pre and post conditions on types and the like, and due to its nature, the IDE can quickly keep everything checked.
The ONLY output of this language consists of warnings, errors, quickfixes, and type suggestions. It cannot be used for conditional compilation nor does it output anything. It contains no loops (though there are iterators across limited sets) so all programs written in this language are guaranteed to halt fairly quickly. It can probably be a subset of the language for which it exists, peppered with heavy boilerplate avoidance.
It would definitely make this hypothetical language extremely complex but on the plus side, it can be bolted onto an existing language. It’s the very opposite of python/ruby in the sense that you type way more than needed to make your code work, but on the flipside you get -extreme- compile-time bug checking and support. Eiffel already goes quite far with this whole plan, but eiffel doesn’t have the kind of community you need for a serious programming language. (Chicken, meet egg!). Also, eiffel’s system is less focused on IDEs. I’d like something where I can specifically code quickfixes and concepts like ‘deprecation upgrades’ straight into the library itself.