Edit Rename Changes History Upload Download Back to Top

Source code in files. How quaint!

(Continues Niall Ross' contribution to Smalltalk for Java Programmers.)

Alice is happy with the way the Smalltalk IDE organises classes and methods. She'd much rather have the IDE identify these for her than hunt for them in a text file. Bob, by contrast, is worried that this environment is going to hurt, not help, his productivity. He's convinced that Alice' enthusiasm is just a newbie mistake that his greater experience warns him against.

Bob is concerned that storing source in a respository will block refactoring. He may have had tools that offer some standard refactorings in the environments he's used to but for anything non-standard, he's accustomed to supplementing these with text editors. The editor has some metachars and find/replace abilities. With great ingenuity, Bob can (sometimes) map the project-specific code rewrite that he wants from his mental metamodel of Java or C++ code to the utterly different and far simpler metamodel of text understood by the editor. He's developed considerable skill over the years in expressing what he wants in the metacodes of the text editor, and in finding ways to match what the editor can recognise to what he wants. More than once, this has saved him in late night sessions when hitting 'replaceAll' has done something that would have taken far longer if he'd had to find and fix each affected line of code individually. Hence to show Bob source code that is not in files, but hidden behind some editor that seems to force the user to select each method in turn before editing it, is to worry him.

The tutor can reassure Bob by explaining that Smalltalk's Refactoring Browser also provides a Rewrite Editor (similar to a text editor's find/replace but with a far more powerful understanding of the code). After impressing him with what that can do, he can go on to show Bob the refactoring methods behind these tools, e.g.

    myParseTreeRewriter
	replace: codeExpresion
	with: refactoredExpression
	when: conditionsInWhichToReplace

along with their metacode matching characters, nesting abilities, sequence abilities, etc. (just like Bob's text editor's macros but again with a far more powerful understanding and capabilities), all of which Bob can invoke directly from workspaces or even in his code, instead of, or in conjuction with, the Refactoring Browser and Rewrite Editor UIs.

If he can be persuaded to take time to investigate all this, Bob will realize that the Smalltalk IDE is not less capable at refactoring than his prior environment but more capable. The problem is that all this, which Alice doesn't know she needs to know and so is willing to wait for, starts bothering Bob early in the course, yet cannot easily be taught him until late in the course. Until then, Bob is going to need to trust the tutor.

(Written by Niall Ross as part of Smalltalk for Java Programmers.)


Review comment by Charles Miller

(I originally objected here because I felt this page was offering a straw man of the real objections to keeping code in images instead of text-files. Here's my attempt to present more accurately the kind of arguments a Smalltalk advocate would have to deal with. It's not an exhaustive list (I haven't dealt with the management of third-party libraries, for example), but I think it's a more realistic view than the above

The below was written from a significant position of ignorance of Smalltalk, but that's the point: these are the points a Java programmer would need to be educated in the "Smalltalk way" of doing things.)

Charles is neither Alice nor Bob. While he has never used Smalltalk professionally, he has heard a lot about it, worked with a couple of ex-Smalltalkers, and played with Squeak once or twice. He also has experience of VisualAge for Java, and is willing (for the sake of argument) to believe that all the cool things about VAJ were due to Smalltalk, and all the bad things the fault of Java.

Charles has a simple philosophical problem with all his code residing in an image: with code in files, in a standard format, his IDE can at least theoretically do anything that an image-based development environment can. Modern Java IDEs keep a skeleton image in memory to provide visual feedback and source navigation, and can drill down to the AST if necessary for things like refactoring.

Practically, of course, Charles knows Java's not really there yet. No Java IDE exposes refactoring in as flexible a way as the Refactoring Editor, and things like Java's fix-and-resume support are also lacking (even compared to what he remembers from VAJ!) The refactoring support has, however, reached the 80% mark where most of what he wants to do on a day-to-day basis are supported in a couple of mouse-clicks.

Philosophically, however, an image is a limitation. A development environment can always build an image from text files, if necessary, but the existence of those text files gives us a portable representation of our code that can be manipulated by a host of tools that may or may not need to understand the language the code is written in. Charles knows that Java development environments will continue to adopt whatever image-like behaviours are necessary to deliver desired functionality, but the text files will always be there to back them up.

By choosing an image format, and not to have your source-code in files, you are limiting yourself to using only those tools that understand that particular image format. Admittedly, Smalltalk itself is a very powerful tool, but he is just not ready to believe it is the be all and end all of tools that he may want to use to manipulate, manage or store his code.

For example, he has used four different Java IDEs in the last five years: Java has a number of IDEs that compete in the market, and when one gets better than another he can switch, and be able to move his source from one to the other with no effect on the code he is producing. He is not aware this is possible in the Smalltalk world because there the development environment and the Smalltalk environment are wedded together by the image: if you want to change your development environment to one that is more capable, you also have to change virtual machines, and probably even class libraries.

He also remembers using ENVY with VAJ, and the incredible sense of relief when he moved back to to plain text files that could be stored in CVS. Sure ENVY did some neat things like method-level versioning, but it was pure hell on the development process, creating painful merges and artificial development practices where you get a queue of people waiting to commit code to the main branch. And when the server went down, development stopped entirely. It was also impossible to use ENVY efficiently remotely, which made it hard to work from home. Now, he can consider switching to Subversion, without changing any other part of the development process. Again, plain text gives him a choice of tools that don't have to understand the image format, or even the language the code is written in.

(Note, the point here isn't really ENVY vs CVS, it's the fact that switching to an alternate version control tool such as CVS wasn't even an option, because only ENVY would understand The Image)

Charles routinely installs software on servers on the other side of the world. Occasionally, this software goes wrong, and he needs to patch it in a hurry. This has happened twice this month: one problem he fixed by ssh-ing into the server, editing a file in vi, and launching the build from the command-line. The second he fixed by changing a third-party library (once again in vi), compiling just that library, copying it into the server, and restarting the application. He doesn't think either of these approaches would be available if he were doing image-based development, since he performed both fixes from home where he didn't have a development environment set up.

-- Charles Miller


Discussion by Niall Ross

I'm grateful for Charles' detailed analysis. While text addressed to the Bobs of this world is needed (and will continue to be the main focus of these pages), Charles has expressed well some issues that occur to those whose experience is well beyond Bob's. (Also, it is very considerate of him to have a name beginning with C, so his text fits into my storyline so well. :-)

(In what follows, 'Charles', like 'Alice' and 'Bob' in the other pages, will refer to the 'Charles' of Charles Miller's text above, a hypothetical person of given experience and attitudes, and does not mean Charles Miller as such.)

I believe the above divides into real concerns, albeit ones that I would argue are well outweighed by compensating advantages in normal cases, and points that can be fully addressed. In all cases, I hope to indicate that there are answers, and what they are, rather than provide a complete rigorous analysis.

Real concerns

Although porting between Smalltalk dialects at the model layer is straightforward, when it comes to the UI Smalltalk dialects differ significantly. Most Smalltalk projects pick one UI and stay there unless there is a significant reason to move. Moving the UI of a large Smalltalk project may be much easier than moving it to/from another language but it is still work. (For example, statistics quoted for one current automated converter are 80% fully-automatic, 16% minor user intervention, i.e. answer the wizard's questions, and 4% significant user intervention; and while that one is free with the dialect, some combinations must be bought and some dialect combinations have no conversion utility either free or purchasable.) The range of Smalltalk vendors and dialects can be seen as a strength in other ways, but Charles' point is perfectly valid.

The usual Smalltalker's response is to ask how significant is the fact that moving to another Smalltalk dialect and vendor is less trivial than changing vendors in the rival language? 'You won't need it', is the cry of Agile Methods; in this case, the ability to move is what you won't need. If you think your Smalltalk dialect is making you more productive than Smalltalk's rivals then forgoing that for the ability to switch easily between these rivals is forgoing a certain advantage for an unlikely need. And if you don't think Smalltalk gives you advantage, you won't be using any Smalltalk dialect anyway.

I think this is a sensible question. However I don't contest that, for the UI at least, dialect and vendor switching in Smalltalk is less easy than for SUN-standardised Java.

Points that can be fully addressed

Charles fears that switching configuration management systems, e.g. to CVS, isn't an option. One Dolphin Smalltalk CMS uses CVS as the backend for its system. VisualWorks Smalltalk can use any relational database as the backend for its Store CMS, and its parcels or code can also (or instead) be stored in CVS or other file-management systems if desired. VisualAge Smalltalk has demonstrated running in Eclipse instead of its own IDE to show it can be done, and to provide a route whereby IBM customers accustomed to Eclipse can use Smalltalk in Eclipse if they wish.

Generally, it seems to me to be a trueism that a file-based CMS cannot give as detailed information about the code as an object-based CMS. If someone wants to use a file-based system, and accepts the less-code-aware views it gives, they can do so. If they are happy with a Store-like 'publish when you choose' approach then it is probably a trivial matter of putting the text-oriented files (e.g. parcel .pst) that all Smalltalks can produce under version control. If they want an Envy-like 'I version your every code save' behaviour then they may need to add an appropriate call into the appropriate Smalltalk mechanism (e.g. change lists). In the case of Envy itself, the harder part would probably be switching Envy off in the image rather than switching the other system on; doubtless the IBM team that did the Eclipse work could advise any customer with a specific interest.

Charles is also concerned about patching systems remotely. This was a very interesting point for me because it was a good example of how the Smalltalker can fail to guess what the non-Smalltalker is thinking. Smalltalkers are so aware of Smalltalk's unrivalled strengths when it comes to updating running systems that it simply never occurred to me that someone could be worried about doing it. (I was aware that not everyone appreciated the need to do it but while that might be Bob's problem it is clearly not Charles'.) Many points, more than I will cover here, are raised by this. Briefly:

(To be completed.)

Niall Ross


Edit Rename Changes History Upload Download Back to Top