|Perl: the Markov chain saw|
Re: Re: My number 1 tip for developers.by BrowserUk (Pope)
|on Sep 12, 2003 at 05:12 UTC||Need Help??|
When I first started using SmallTalk, I really liked that too. However, as I started working with it for real and trying to develop projects requiring half a dozen developers, it became a pain.
The first problem was that if you had to sit down at another developers machine and try to work, it was awkward because they had invariably customised the heck out of their "image". EditPanes, keyboard definitions, the works. The nearest analogy I can think of is sitting down and trying to work with an AZERTY keyboard, or on a machine where the OS is configured for a different language.
You can have the same problem with highly configurable editor (like emacs). You sit down to review someones code or see if you can spot their bug, hit Escape-Meta-Alt-Control-Shift-D to scroll the code down, collapsing the previous indented block you just read and expanding the next--just like god designed that key sequence to do:)--only to find that the guy you were trying to help has that key sequence defined to remove all line breaks, comments and extraneous white space, and reduce all variable names to single or double characters.
It's his fault that he didn't code his macro to a) save the code first; b) Checkpoint the changes into the undo stack. :)
The second problem is trying to share code between multiple developers. That the code becomes a part of the environment rather than living in external files makes it quite difficult to synchronise classes between developers. I do remember my client spending a quite large sum of money to purchase a class to synchronise changes from individual developer images to a central "code warehouse"--essentially a CVS type of thing. The only problem was that it took so long for it to search the whole damn class hierarchy to locate and save the changes, this was back when 20MHz 386's where state of the art, that it became a pain to do it regularly, consequently, we spent crap loads of time trying to merge changes that had been effected by two (and more) developers. Painful.
I've never used Lisp, but I heard that you can get a similar situation. A bit like I now have with my site/lib/* tree. lumps of "standard" code that I've modified for one reason or another to suit my purposes, but which make it scary for me to upgrade because of all the little tweaks I've come to rely upon.
I really like the idea of a intereactive development environment that allows for deep introspection and modification of the "system" and its classes/functions, but I would like one where the system itself performs diff-ing and versioning so that a) it becomes easy to back out changes and/ or isolate user modifications from the original system. b) allows me to upgrade the system and have any changes I made to the original system be merged (assuming that the new base system is compatible) automatically and preferably, prompts me when it encounters conflicting changes.
With modern cpu speeds and memory sizes it ought to be possible for this to happen pretty much transparently to the developer.
One final thing that I felt was missing from the versions of SmallTalk I used was some way of automatically removing unused classes from a final application image prior to distribution. Memory is less critical these days, but back then, system managers freaked when you handed them a stack of five 1.44mb floppies for even the simplist of applications. Five MB apps were unusual then. Even Word was only a coupe of hundred Kb at that time.
Who knows. Maybe such an environment will develop for Perl 6--but I won't hold my breath waiting for it:)
Examine what is said, not who speaks."Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
If I understand your problem, I can solve it! Of course, the same can be said for you.