Software will save us

Hmm. Reminds me of The IDE Divide. Personally, I’d much rather have a language that keeps my typing to a minimum than an IDE that enables me to type very very fast.

Of course, Perl6 supports formal parameters, typed with varying strength, and formally defined classes including data inheritance, and it’s easily parsable; all in contrast to predecessors. :) So the only issue is to get someone to write an IDE for it. :)

But my personal next stop in this arena will be learning Haskell. At least, watching the breakneck speed at which the Pugs hackers make progress on any given single day, attributed mainly to Haskell and its libraries by Autrijus himself, makes it seem foolish not to take note of the language.

I had some Haskell in a CS 101 course years ago. I cannot imagine how someone would go about writing anything serious in Haskell (or any other functional language), but clearly people are doing it every day. Maybe enlightenment will reach me one day.

After some further research it appears this is nothing particular to Java? Emacs has it, of course, and so does vim, and it works with any kind of file. I’ve used it before, but never in anger. Maybe the default shortcut for it in Vim is just too inconvenient for me; I should look into that.

How can this work in a language like Ruby? Say you're working with Ruby on Rails, and Rails dynamically adds about a trillion new methods to every object after compilation. None of that information is available in a place where Emacs could grab it. Basically auto-completion is hard to make useful whenever the language has eval().

Some months ago I was trying out several Perl IDEs and they all "solved" this problem by only suggesting symbols you already typed out in the current block, which is just not enough.

Well, Vim and Emacs will look at the buffer, then at other open buffers, then at included files if they can parse out any include statements, etc.

eval() isn’t even necessary for dynamic shenanigans; in Perl you can do lots with just symbol table twiddling and closures, and I assume the same is true for Ruby. When that is the case, though, then the necessary information should be available somewhere in editor-consumable form, at least as strings. And with hippie completion the editor doesn’t really care too much about what sort of symbol the suggestion came from.

Maybe what we’re all really after is an invention from the ’70s, called Smalltalk. I’ve heard its proponents clamoring over their apparently highly intelligent editors and over live image versioning that purportedly makes any version control system seem like stone age technology. I don’t know.

Oh, and as for the benefits of typing in and of itself? Again an area where Haskell (and the ML family shine) shine: inferrential typing. Read the writeup of Mark Jason Dominus’ “Strong Typing and Perl” talk, wherein he uses inferrential typing to buttress the theory that “Strong Typing Doesn’t Have to Suck.” Particularly the “spectacular example” (slide 27 onward, but read the whole thing in sequence) is extremely impressive.

I'm still not quite convinced that nicer forms of doing an eval() make the problems go away. If you have Rails create accessors from looking at your database tables, there's no sane way for your editor to know.

Another example that doesn't involve Rails or eval(): You want one object of class A to delegate messages to another object of class B. To do that you'd probably just override A.method_missing to reroute any incoming calls to a B (think AUTOLOAD in Perl). Now to the editor it looks like an A cannot take a lot of messages, when it can actually do anything a B can do.

AUTOLOAD and such mechanisms are a problem indeed – and not only for editors, either. Try introspecting a class hierarchy that uses AUTOLOAD. The class library designer will have to expend a lot of effort to vaguely accomodate that. I’m not a huge fan. In general I dislike using dynamism just because it’s available. Self-modifying code is still a dangerous tool. It is sometimes extremely effective, but it needs to be used with a lot of care.

What Rails does certainly isn’t sanely deductible for an editor without any help (at least one not itself written in Ruby… we get to the whole Smalltalk thing again). But then I don’t think Rails is a good example for what an editor should be able to contend with. I have yet to see an object-relational mapper that worked well for anything beyond toy examples, to begin with. But deducing the form of your classes from the database schema at runtime, on top of all this, has to be one of the worst ideas around. Sure saves you some typing, and looks like Once And Only Once, but it neither is true: if you make any significant change to the schema then the code will break anyway, so there are always two components to keep in synch. I also happen to think that SQL is a nice query language. I prefer a design where you put all your hand-written SQL in a module/class/whatever, where the functions/methods are business logic units. The rest of the code then talks to this blackbox, and when you make changes to the structure of the database, even deep ones, then the breakage is localized to this module. Makes it actually possible to write the app at large independently of the database schema, as opposed to the false promises of object-relational mapping prophets. And there are hand-written SQL queries in there that you can sic a DBA onto.

Anyway, this has gotten far off track. :)

I guess if worst comes to worst, the framework could/should include a tool to produces ctags-ish tagfiles? Vim and Emacs grok those and can use them for their completion. In essence this a way of adding framework-specific smarts to a generic editor. If your framework is so dynamic that even this must fail, then something has gone horribly wrong…

Self-modifying code: You can shoot yourself in the foot with it no doubt, but it's also the single reason for me to use dynamic languages.

Rails: You always need to keep your code and database schema in sync, whether you use an O/R mapper or some sort of phrasebook. Working with Rails involves a surprisingly heavy emphasis on validations and tests, so localizing changes is not as much a problem as it might seem. I think the problem with phrasebooks is that you start saving on relations because they're so much work. They also make you view your database as a huge bag of atomic data and that's not the way I personally like to work.

Tagfiles: Shouldn't that sort of thing be pretty easy to accomplish in a generic fashion? Say you had some function update_tags which you could call at a point where you know all dynamic magic has already been applied. It would walk through each class and compile a list of messages it responds to. Autoloading would still be tricky, but most self-modifying code trickery could be captured.

Ironically, Rails would make this kind of tagging ridiculously easy because it allows you to open an interactive Ruby shell, load the whole environment in a single line and then lets you fool around in your model.

That’s pretty much what I was thinking of WRT tagfiles.

My main attractions to dynamic languages are, well, probably LISPish: first-class lists and closures. I suppose passing closures around qualifies as self-modifying code on some abstract level, but to me it doesn’t at all the feel like the same thing.

Do you know what bugs me about dynamic languages? There's so much to type! I'm most serious.

Have you tried Smalltalk? If typing alot of code is bothersome for you, Smalltalk is your answer. Built back in the 70's, it's still the easiest to program language I've experienced (considering C, C++, Java, PHP, LISP, PERL, PHP, Javascript, Microsoft stuff, Pascal, et al.) Well, one possible exception, but with far less functionality, is COBOL. Productivity is the aim of the future IMO, and while the curly-braces will surely die, Smalltalk will live on due to it's purety, simplicity, grace, power, and performance.

Sadly, none of the languages I've listed can satisfy the same list of attributes. Java and C# are steps backward, not forward. Ruby made some poor choices in trying to satisfy the curly-brace crowd and thus removed it's ability to claim purety. I'm picky though.

As for IDE's, there is nothing that compares to the VisualAge or VisualWorks Smalltalk environments. The power, simplicity, and productivity is astounding. The file-based IDEs like ... well, everything else out there, are combersome, unwieldy, difficult to configure, and cause a loss in productivity.

These are just my opinions. Few curly-brace programmers (I used to be one) ever get the opportunity to bask in the joy that is Smalltalk. Mainly, I suppose, because of marketing and VisualAge's cost. I hope you all get to someday though, it'll put a smile on your face, I promise.

There are some free IDE's to play with here: http://smalltalk.org/main/

My apologies if I missed the point of this discussion, kinda in a hurry and only skimmed the other posts.

Hey, now have a look at this: Custom keyword completion in Vim 7

Nice idea for the script. Sort of how you open types in Eclipse. They should have it for vanilla text editing as well.

Thanks for signing in, . Now you can comment. (sign out)

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

URL:
Remember me? YesNo

Comment (no HTML, URLs will be auto-linked):