All the Perl that's Practical to Extract and Report

Languages and IDEs

ziggy on 2002-07-15T15:20:32

Jose Mojica writes that .NET (in particular VB.NET) wouldn't be able to fly one millimeter off the ground without VisualStudio.NET. Why? Because of basic system classes like System.Runtime.Serialization.Formatters.Binary.BinaryFormatter demand the kind of IDE provided by VS.NET:

I was teaching Visual Basic .NET last week and I jokingly made the following statement about intellisense: “I believe that without intellisense .NET programming would not be possible.” I said that after typing something in the order of System.Runtime.Serialization.Formatters.Binary.BinaryFormatter, which caused a few students to chuckle and say, “There is no way I will ever remember that.” I told them that the only way I remembered that was because of intellisense. I had memorized System.Runtime and intellisense helped me remember Serialization, then Formatters, then Binary, etc.

I was joking at the time but then I started thinking about the statement. How successful would a class hierarchy in which classes are buried five namespaces deep be without features like intellisense and the object browser? Don’t take me wrong, I love the way the classes are grouped in .NET and namespaces are definitely a good thing, but would we be able to be productive without features like intellisense, the object browser, and even dynamic help to a certain extent?

There's something fundementally wrong with this approach. Really great programming languages foster a culture of problem solving by Getting Out Of Your Way. Perl does this, as does Lisp, Smalltalk and a few other notable languages. The general thread is that a great programming languages are great levers[*]: they allow a programmer to lift a heavy load with very little effort. (Try and do my @list = map {s/\b(\w)/\U$1/g; $_} reverse sort @input; with an array of C strings...) This is possible because the language [environment] itself is powerful, yet easy to use.

Jose's description of VB.NET (or, more specifically the CLR) goes in the opposite direction: Start with a mediocre tool, add a couple of hydraulic lifts (intellisense, dynamic help and a class browser), and you too can lift heavy loads. The difference here is that the power is with the tool, not with the language environment. The net effect isn't to lift heavy loads with little effort, but to ease the great effort needed to lift heavy loads.

Then again, who am I to judge? Microsoft has made billions more than I can hope to make in a hundred lifetimes. They have designed more programming languages, tools, and IDEs than I can count. And every year or two, when they introduce some sort of must-have productivity enhancing technology, I find myself still happily using the same well-worn tools that I have used for years, still crafting solutions with nary a complaint.

*: Many thanks to mjd for this analogy.

IDEs matter...

pdcawley on 2002-07-16T07:32:16

I you think about the list you gave, Smalltalk, Lisp and Perl, then Smalltalk has one of the great IDES in its system of browsers and the refactoring browsers. Many lisp programming environments are full blown IDEs too, complete with a read eval print loop. Take a look at tools like DrScheme, or the various emacs lisp modes that support common lisp and provide completion, browsers, the ability to drill down from a function name to its source code, or just pop up the function's documentation.

Perl is actually the odd one out in that it doesn't have a great IDE. I'm just not sure whether it lacks a great IDE because it's so hard to do syntactical analysis of perl code, or because nobody wants one badly enough.

there are some good IDEs

TeeJay on 2002-07-16T11:24:11

I have used a SmallTalk IDE and yes it was great - much much faster and easier than VisualStudio.

You can do Perl in Visual Studio, or in Komodo both with the aid of ActiveState. But I find myself doing more with emacs and quicker.

Perl has a simple enough name space, that I have never needed auto-completion for classes, etc.

Emacs provides brace matching, auto-indentation, regular expression based searches, flymode spellchecks, version control, debug and even a shell all in one space without the need for a mouse. In fact using VIM I was more productive than using Visual Studio.

A.

Re:there are some good IDEs

ziggy on 2002-07-16T13:10:48

Perl has a simple enough name space, that I have never needed auto-completion for classes, etc.
Yep. This is a variant of Paul Graham's thesis: succinctness is power.
Emacs provides brace matching, auto-indentation, regular expression based searches, flymode spellchecks, version control, debug and even a shell all in one space without the need for a mouse. In fact using VIM I was more productive than using Visual Studio.
Yep. None of these features are absolutely necessary to help you write code. All of them are nice because they make it easier to write code. Jose's point is that VB.NET/VisualStudio are the opposite: it's effectively a requirement to use "intellisense" just to use the system classes.

Re:IDEs matter...

ziggy on 2002-07-16T13:04:37

I wanted to mention Lisp and Smalltalk. But the more I thought about it, the more it seemed that the IDEs (REPL, code browsers) weren't in the 20% of the features that provide the 80% of the power. They're the icing on top of a really tasty cake that makes it even more delicious. Put another way, you add REPL or the object browser to C to make it roughly as powerful as Lisp or Smalltalk.[*] Furthermore, you're not required to use the default environment: Lisp's REPL is easily reimplemented, and sometimes improved as seen by various Emacs lisp modules.

By comparison, Jose's observation is that the IDE is effectively tied to the hip to the language with C#/VB.NET. My comment is that this sounds like a language+IDE combination in the sense of Lisp and Smalltalk, but doesn't have the same properties of a great coding environment. The example I offer as proof is Jose's comment: you really don't want to code in VB.NET without VisualStudio, whereas you can still be very productive with a command line, vi and lisp/smalltalk/perl.

[*] Yes, I know about the code browsers going back to Visual C++ 1.x. They were an improvement over managing a series of source files, but don't offer the same amount of "leverage" that Smalltalk does.

Red herring

jand on 2002-07-17T18:22:37

I think this whole long namespace names thing is a red herring. You just "import" the namespace once, like "use Foo::Bar::Baz" and then write your code normally. I wrote lots of C# code during the last 2 years, all of it in Emacs and never realized that namespace names are a problem. Besides, you normally just cut and paste the "use" blocks anyways. :)

IDE features that are useful

koschei on 2002-07-17T01:24:43

About the only feature I can think of that I want from an IDE is really more a feature of the editor and is part of IntelliSense type stuff. It's useful being able to see what the parameters of a sub/method are when writing.

I recently had to write some C code that used the OpenLDAP libraries and found such a feature very useful.

Naturally, it'd be a bugger to do in Perl where the idea of parameters is "handle @_ somehow".

parameter hints

TeeJay on 2002-07-18T10:54:14

Actually you could always use hints sucked either from a comment at the start of the sub or from the perldoc.

If you are writing perl libraries, then the arguments should be documented somewhere and naturally it could be fetched - I find the argument prompting in VisualStudio deeply annoying.

If emacs had a comment from the module or perldoc in the status bar then I would be a very happy bunny indeed.

In fact I am working on finding 'most' arguments, most of the time in AutoDia by looking for shift and @_ in the first few lines as well as doxygen or other comments containing metadata.