Smalltalk Tidbits, Industry Rants

Sorry James -- I love Smalltalk, and VW especially, but this just isn't true.

Sure, there was a time when smart Java developers worked in Vim and prided themselves on esoteric shortcuts -- but that time ended in January 2001 when IDEA was released (http://www.jetbrains.com/). Eclipse is sharp too, and others have done a good job appropriating the Eclipse work (especially IBM with their WSAD for WebSphere).

Now you have a legitimate beef with Java OO -- it really is significantly different than doing OO in Smalltalk. Number one on my list of gripes is not being able to add responsibilities to classes in the platform library that should actually house those responsibilities. Number two is that because it's not dynamic we don't have useful abstractions/idioms like code blocks, which can lead to felony violations of the Law of Demeter if folks aren't careful.

Nevertheless, Java really does have a decent toolset nowadays. More importantly, they have the right tools for the corporate environment. I don't want to turn this into another "When will Smalltalk have X so it can be competitive?" complaint. Many Smalltalks have made concerted efforts to remove excess log from their own eyes (and it shows). But there are some mighty big wood chunks still left. Now we all know what we're supposed to do before we removed the slivers from Java, right?

James was right on, as usual, in his analysis here. If you do exactly what everyone else does, you're going to get the same results as everyone else.

The best article on this subject I have ever read is here: http://www.paulgraham.com/avg.html

I believe it should be required reading for anyone in technical management at any level.

It would be so kewl if the title rotated between "Smalltalk Tidbits, Industry Rants" and "Smalltalk Rants, Industry Tidbits" :-)

Comment on Why progress is so slow by James Robertson

Isaac,

Using a text editor to write code is using sharp sticks and pointy rocks. I'm sorry, but there it is. It's anti-productivity, and I think it's a sad thing about this industry that so many developers and managers shrug their shoulders about it.

"sharp sticks and pointy rocks... It's anti-productivity"
The pre-rant response to Chad Dickerson's article would be to ask what work they are doing and what "highly productive" actually means - some mild curiousity.

"Why do so many Java developers opt for a text editor instead of a tool?"
Because they can!

"what a developer can do to optimize their personal development environment. Now imagine an Eclipse developer doing the same thing... When you stop giggling"
Those text fixated Java developers are probably still giggling - they'd just add/remove the "static" keyword ;-)

(Interesting that the "Move/to Protocol..." menu-item still creates new methods but no longer removes the old methods - when we use it to solve Eric Winger's problem. So in class A, we used to be able to move selected methods from the instance side to the class side by "Move/to Protocol..." and specifying the protocol as "A class>someprotocol". VW7.2.1)

(Interesting that the "Move/to Protocol..." menu-item still creates new methods but no longer removes the old methods - when we use it to solve Eric Winger's problem. So in class A, we used to be able to move selected methods from the instance side to the class side by "Move/to Protocol..." and specifying the protocol as "A class>someprotocol". VW7.2.1)

I just wanted a one-click way to move methods back/forth. I found that typing out the class and protocol was cumbersome.

Comment on Why progress is so slow by James Robertson

And again my point - the end developer was able to make a small modification to the system - in order to make his development time more productive - and all without having to go through an overly complex plugin mechanism...

Just because the editor is built in does not remove the fact that you are using an editor !! Is there some other way in smalltalk that I dont know about to write code? Im sure I was using an editor the last time I used VW. Also, most people use an extended editor, not just a MS Notepad type tool, so at least compare that method of development with VW/Smalltalk.

I remember bringing up the point of the image/IDE with James when I met him. I have found that many people that dont use smalltalk dont use it because the whole image/ide is new to them. We also know what it takes to move the "unwashed masses" as James put it to a new environment.

Dont knock the text editor approach, if smalltalk could do this today (as in VW) then it may well be in more use. The text editor approach may not be the best way to go but it is the defactor standard way of doing things.

There may not be something better than Smalltalk or Lisp since the dawn of the software age, but the reason might be because the masses dont think there needs to be.

an overly complex plugin mechanism...
James, have you ever created an Eclipse plugin?
Have you read "Contributing to Eclipse" Erich Gamma, Kent Beck?

Eric: "typing out the class and protocol was cumbersome"
afaict that functionality is now broken :-(

Your fix addresses the symptom and not the problem. The problem is that the UI is modal, and sometimes it isn't obvious enough which mode (class, instance) we are working in. Once we have half a dozen protocols defined, they are enough to remind us that we're looking at the class-side or the instance-side.

A kewl fix would be to show a watermarked (class,instance) background in the source/method/protocol panes ;-)

The IDE is both a strength and a weakness of a system like Smalltalk. Although having a powerful IDE is great, it is also a barrier to entry.

Programmers tend to be passionate about their editors (witness the MANY vi vs emacs debates). People don't want to have to give them up just to use a new language. Even if they would be more productive in the long run, that's just an annoyance in the short term.

The key is, the short term is what matters when it comes to language choice - if you don't like it pretty quickly, you're going to just give up and move on to something else. That is, if you haven't already been turned off on hearing you can't use your favrourite editor and instead have to use some IDE.

I'm not saying it's logical, I'm just saying that's how it seems to be, and it's just one of a long list of socialogical factors that have (and continue to) hold Smalltalk and Lisp back (Lisp is the same in that you basically HAVE to use an editor with good () matching or else you'll go mad).

Comment on Why progress is so slow by Vincent Foley

To James Ladd:
Well, as far as I know, when I edit Smalltalk code, when I accept the method, it is compiled, so if there's an syntactic error or an undeclared variable, I'll know about it. You can also list implementors, senders, bring up the class hierarchy of the class you are editing, format the code automatically (pretty-print it), refactor things out, you can have a code critic, auto-completion, syntax highlighting, etc. You can also test code on the fly, inspect objects and change them live, change the environment, etc.

Sure, some editors have some of those (especially syntax coloring and auto-indenting), however all the features brought by the Smalltalk environment contribute to make programmers more productive. I agree with you, raw text files are far more common -- some people don't even know that there is another way -- but they can hardly bring all that the Smalltalk image system brings. Look at all the work that went into Eclipse and how happy the Java developers are to see that the IDE actually detects error before you compile (due to a background compiling system or I don't know what); well that has been available for a long time in Smalltalk, because the whole design lends itself better to that kind of thing. The Eclipse guys are also happy that for some trivial changes, they can change the code while the application is running and the application will take automatically those changes. This has been in Smalltalk for quite a while too.

I have a theory that the so-called "business=friendly" programming languages are all slowly turning into Smalltalk. Really, I mean it. Let's look at the evolution of C to C to Java and C#. C was procedural, then came C++ which added OO capabilities to C and developers thought OO (as brought by C++, not by Smalltalk) was the best thing since Richard Stallman washed. Then, Java pushed an even deeper object orientation, added a garbage-collector, a virtual machine which could make the "write once, run everywhere" premise possible and again, programmers were delighted. C# took a step even further by blurring the difference between value types and reference types by having auto-boxing. Both C# and Java have reflexion support (although from what I hear, it's still a long shot from what Smalltalk can give you.) The developments in Eclipse and Visual Studio should also be looked as steps in the Smalltalk direction (whether it's adding Edit & Continue support, background compilation to warn you of errors before doing the big compile, refactoring and whatnot)

I admit that I may be totally out of line here, but what I think I see is that as time goes by, the curly-braces crowd adds more and more features to their languages and tools and those are starting to look more and more like Smalltalk.

Vincent

P.S: And as for suggesting of supporting raw text files, I don't know if that's such a good idea, I mean, do you give a lumberjack an ax even if he can have a chainsaw because he's more familiar with the ax?

Hear Hear Shane !

I admit that I may be totally out of line here, but what I think I see is that as time goes by, the curly-braces crowd adds more and more features to their languages and tools and those are starting to look more and more like Smalltalk.

And Paul Graham thinks that languages are gradually becommming lisp. No doubt if you look at other language fans, they think that languages are heading in their direction too.

I don't think it's that simple - languages are influenced by a number of sources. Including features found in another language doesn't mean it's becoming like that language - features don't exist in a vacuum.

PS: What's the deal with "curly brace crowd" slur anyway? Curly braces are hardly the distinguishing feature of the languages the expression is used to deride (C/C++/Java/C#). Pascal is very close to C but lacks curly braces, while JavaScript has more in common with Lisp than Java (its designer considers it to be a dialect of Lisp), yet uses curly braces.

Thanks for your response Vincent. Dont get me wrong, I love Smalltalk and wish more was being done to make it mainstream that was productive and not destructive like using the term "curly brace crowd". I know you did not start that term yourself. Anyways, I wish that Smalltalk was in the position that Java is now. I wish I could get it there. Whilst we can all discuss how some feature is making some language closer to Smalltalk its not helping get Smalltalk used more widely. I know im in the wrong place if I didnt want to hear rants about "how Smalltalk this and Smalltalk that". Is there a way to make it more widely used ?

BTW - Have you seen JOODA ? Its rough last time I looked but provides a "Smalltalk" environment onto of java with the expected Smalltalk browsers etc etc.

I've never programmed Java without an IDE, except as a deliberate exercise in masochism.

I started off using IBM's VisualAge for Java, which was apparently VA Smalltalk tortured until it spoke Java (I'm reminded of that bit from the Lord of the Rings movies where Saruman explains where orcs came from). Then I moved on to WSAD/Eclipse, and then on to IntelliJ IDEA. I don't think I've ever met a Java developer who, having used IDEA or Eclipse for more than a week, ever wanted to go back to using anything else.

People who program Java using text editors are inevitably the ones who loaded up an IDE, tried to use it, ignoring all the debugging, refactoring, code-navigation and auto-complete tools in the process -- i.e. all the things that make it an IDE instead of an underpowered text editor, and then went back to somewhere the keyboard shortcuts were more familiar, happy that he was "more productive" again.

At Atlassian, the policy is that you're allowed to develop using whichever tools you feel work best for you. Everyone in the office ends up using IDEA. Occasionally, someone will start who prefers (and uses) Eclipse, but they usually switch after a few weeks.

So please, don't tar all Java developers with the brush of one idiot, even if he does have his own column in InfoWorld.

As an afterthought, saying "We are a foo shop" is a matter of pragmatism. Picking the "best tool for the job" is easy if you can pick the job, then pick the tool, then pick the developers out of a large pool with mixed skills. If, on the other hand, you have to get the developers before picking the job, you're pretty much forced to pick some value of 'foo' and stick with it. Hiring a team of experienced developers so that you can commit them all to a project would be a nightmare if you didn't know in advance what language the project would be written in.

I'd like to sign up to work in one of Microsoft's new Software Factories - see The Future is Coming for Software Development.

Often wonder whether some languages are designed to require tools, to give the vendor a revenue stream. Seen from that perspective, it might explain why none of the big software houses are seriously backing dynamically typed languages. Conspiracy theories etc. ;)

Modern Java IDEs (eclipse, ideaj and slowly, netbeans) are better than text editors, even clever ones. Code navigation alone is a massive improvement, when you add refactoring tools the improvement becomes so compelling that I wont employ developers who refuse to use them (I probably miss a few genii but there you go).

What is interesting, to me, is the effect on the codebase of the tools you use. I recently worked on a code base developed using vi and a checkout based cm system. It was terrible: huge classes; huge methods; loads of duplicate code; massive, repetetive method names. Once I started working on it I found out why, when your main code analysis tool are find and grep then long repetetive names are what you need. When having 5 classes open at once means 5 disconected windows you tend to keep your changes in one class at a time, when changing multiple classes means manually checking them out (after negotiating with another team member to get it) you quicly learn to cut and paste code into "your" class and do all the work there.

The current code base, built with ideaj and cvs has many, small classes with small methods with appropriately long, meaningful names. Its not as pretty as a smalltalk system but its moving that way. Looking at python codebases, a lot of them have big classes and methods. I suspect this is because Python tools are not very good yet (Mainly they are still clever editors).

So the quality of the tools does make a difference. Much Java development is well beyond the pointy sticks stage. It will be interesting to find if there is a point of diminishing return on making tools more like smalltalk or there are still a few step changes in productivity to go through.

Tom

Comment on Why progress is so slow by James Robertson

Charles,
You make a good point about how and why tools and languages get chosen. I suppose what I'd like to see happen is less "herd thinking", and more real thinking. In particular, I'd like to see these morons recognized as the hacks that they are...

People are always talking about how certain high-level toolsets would make us all so much more productive, and I am very skeptical. For one thing, the reason that programmers / software engineers / title of the month people cling to text editors with such fervor is that intuitively, we realize that the primary technology we are working with is algorithms, and from day one in our (formal or informal) technical education we express such algorithms in LANGUAGES. And it's quite possible that textual languages are the best way to express the ideas, even if the language in question has "objects" as its central principle. I'm more interested in people developing languages that facilitate expression and that execute efficiently than developing all sorts of cumbersome tools on top of those langauges. I'm reminded of the many industry mag articles I've read that fortell the rise of XML-based programming languages as the wave of the future, which is the most backward thing I've ever heard. XML is great because it's easy to parse and has a natural tree structure. This makes it a boon to tool developers, but it ensures that none of us will ever type again and you'll have to forgive me if I'm not excited about the idea of trying to express a complicated algorithm through someone else's vision of a gee-whiz high level tool. Text is flexible, it can be quite elegant and it's not a broken solution, so please stop trying to fix it.

Vincent: "languages and tools... starting to look more and more like Smalltalk"
"We must not forget that the wheel is reinvented so often because it is a very good idea: I've learned to worry more about the soundness of ideas that were invented only once." Why Software Jewels Are Rare pdf

Vincent: "do you give a lumberjack an ax even if he can have a chainsaw"
When the lumberjack is paying you for the axe, you give them what they ask for.
When the lumberjack has a sentimental attachment to their heirloom axe, you set productivity goals and let them choose.

Some lumberjacks think "the user is always smarter than the technology."

Complaining because an organization is a "Java shop" misses a fundamental point - mixed languages cost. To meet deadlines, you have to have more than one person able to work with a given piece of code. Thus, either you use a small set of languages that are well known by your group, or you accept that one good traffic accident will kill your project.

The same issue comes up on a smaller scale when you introduce a new toolkit or API. Once done, you have committed your team to learning it. This does not mean "never introduce a new toolkit", it means "decide consciously where you want to focus the risk of the project." Most projects we are called in on will involve at least one new technology, even if just a previously unused standard library feature, but we choose with malice aforethought what to introduce and when.

Thus, even though I have used Perl, C++, and Matlab in the last year, I would characterize our shop as a Java shop. I came in knowing python, and use it occasionally for personal system admin tasks, but it is not something I would use happily for a team project, because only I know it, and as yet, it has not been worth the effort to evangelize.

As far as IDEs, I introduced the group to Eclipse, I use IDEA, and I know of people using several others. A simple text editor does get hauled out once in a while as well. I am not going to tell someone else that their technique sucks unless I see evidence of it in how fast they work or how good their code is. For me, IDEA is light-years beyond a text editor, but if someone else is getting the same productivity without, well, they have found how to hit the goal with their technique.

Scott

An IDE can always be used like a text editor. Except you do not have to wait for syntax coloring to be added by the next release. And when the IDE is free, like eclipse there is no excuse not to use one. Just type in the code, go back to nature, to the command line that is, and type "javac ..." or "build ..." or whatever.

Trackback from Pensieri di un lunatico minore

Editor mentality

James Robertson wrote some about editors versus IDEs, and a lot of people go on in comments about how passionate......