Smalltalk Tidbits, Industry Rants

Rain, rain, and more rain. The only positive to all this is that the air conditioning for our upstairs is out, and this nasty weather pattern is holding the temperature down. Bleah

Here's something I didn't expect to see:

Sammy Sosa of the Chicago Cubs was ejected when umpires found illegal cork in his shattered bat during Tuesday's 3-2 Interleague win over the Tampa Bay Devil Rays.

Sosa broke his bat in the first inning on a grounder to second base with Chicago runners at second and third.

But crew chief Tim McClelland examined the bat along with the three other umpires immediately after the out was called and the run scored.

Huh. Sammy Sosa isn't somone I would have suspected of that kind of thing....

via Manageability comes an interesting exchange on Java and language features:

We are catering to the Java culture, while trying to manage things well on the technical side at the same time. In general, once can contrast the Scheme-like philosophy of using a small number of very general constructs, with the more mainstream approach of having a great many highly specialized constructs, as in C or Modula style languages.

Java is clearly in the latter camp. Most Java developers are happy to have dedicated, narrowly focused solutions that are tailored to a specific problem. I am keenly aware of the drawbacks of such an approach, but I don't see it changing very quickly.

...

Dumbing down the language at the expense of providing more powerful expressions is a way of preserving a wider audience. However, is it the only way of supporting communities?

The interesting thing to me is that Java, while very popular, is not as widely used as VB, nor as widely used as Cobol once was. If they were aiming for simplicity, they missed.

Via Clarence Westberg's blog comes some fascinating Scientific American reporting on the Sun.

Here's an interesting piece via Windley on using blogs for project management

In a traditional large corporate IT department the following happens when the CIO asks why a project went from green to red since the last program review meeting:

1. The program manager who owns the project would dig through his email for the last couple project status reports (most likely an attached Word doc form).
2. The program manager would then call the PM to get additional details of the problem.
3. The PM would likely dig through HIS email to find the right thread from his development team.
4. The PM and development team would likely pull together a meeting to ensure that they have a clear risk management plan and communicate that back to the program office (in a widely cc:ed email)
5. The program manager asks a couple questions, updates a batch of cross-project timeline graphics and reworks their Powerpoint deck for the next program review meeting.

Now lets look at a blogged IT organization:

1. Each developer and/or development team would keep a project blog with RSS.
2. The PM would subscribe to all those blogs and would publish a roll-up blog with links to details of various issues.
3. The program manager would subscribe to the RSS feeds for every project or team that impacts his project portfolio and would publish his own blog.
4. The Powerpoint deck would now have live links to blog entries at the program office level.

Interesting idea. You would have to get all the project leads to participate - but then again, you have to do that anyway. I think it's likely that the RSS feed and tracking that you can get out of that would be the biggest value; you might well get the same benefit from a Wiki if you had a proper RSS feed coming out of it.

Periodically I troll through Feedster for Smalltalk links. I just stumbled across this one, where the author calls both CORBA and SOAP worthless:

Who said anything about SOAP? DCOM/SOAP/CORBA are based on a myth. They're based on a myth that one day you'll just expose things and not care about performance and some how the loose coupling will work. Again...

So what should we all use to develop scalable crossplatform applications ?

Java.

The problem is that these toys (CORBA/et al) are solving a problem that isn't particularly hard and ignoring the hard stuff. The hard part is the business side. The second hard part is the granularity of the data (meaning if you send NAME and I need FIRST and LAST_NAME, then anything we have is a leaky abstraction). CORBA is too much of a big fat heavy overcomplicated beast with incompletely compatible implementations to be of much use. DCOM == Windows only. SOAP is too slow. But the protocol isn't the hard part and in a world dominated by Java is the smallest part of the concern. This isn't to say that we don't need to have a distributed information exchange protocol. Its just that CORBA is freaking useless and overly complex and inflexible. SOAP is XML...it is FAT. DCOM is as freaking useless as CORBA unless you are a Micksee in a land of Micksees. I haven't seen one thats worth its salt yet.

That's not the funny part. He's saying that one should use Java for all distributed applications (presumably because proxies are so easy in Java - snort). Ok, so Java is the one true language for this guy - fair enough, everyone has their language opinions. The funny part comes further down, when he lets loose with this:

Of course arguing this with CORBAites, is like arguing for giving up Hebrew to a band of Orthodox Jews... Like trying to tell the whole world to give up their spoken languages for Lojban.. . or worse, like arguing giving up the idea that SmallTalk is the OneTrueLanguage to a bunch of SmallTalk zealots.

ROTFL. First, learn to spell the language before you make fun of it - it's Smalltalk. Second, wasn't there a part above in this post where you implied that Java is the one true language for distribution? So who's the fanatic here?

And by the way, using CORBA doesn't need to be complex. Oh sure, if you use blunt instruments like Java or C++, it surely is. Some of us prefer the power tools, but to each his own - enjoy your sharpened sticks :)

Keith Ray has some pointers on refactoring code - well worth your time

Keith Ray has some pointers on refactoring code - well worth your time

Looks like personality problems have cropped up on the JBOSS team. Via Matt Croyden comes word of a large fork in the project:

8:00 am -- Seven consultants for The JBoss Group publicly announced the immediate termination of their contracts and the foundation of their new company, Core Developers Network. Their charter "is to provide a commercial infrastructure to enable open source contributors to deliver their professional expertise to the marketplace, independent of their contributions to open source projects".

Matt worries that this might create uncertainty around Open Source development, but I doubt it. People are people, and personality conflicts are nothing new.

I posted some comments by Bob Lewis on outsourcing awhile back. Today Bob Lewis tackles some comments on his post:

A reader comments that the field isn't level (i.e., costs are far lower for the offshore teams). Bob Lewis responds:

And an offshoring firm might complain, "Do you know the advantages American firms have? It isn't even close to a level playing field. First of all, they're located just down the street from their clients. They can take the decision-makers to play golf any time they want. Beyond that, there's still a lot of cultural bias in the United States, and it's a lot easier for a U.S.-based company to place people who know the culture in front of their clients than it is for us.

"Not only that, but all the code, and the entire user interface for every application that runs in a U.S. company is written in English. For American programmers that's their native language. For all of our staff it's their second or third language, but it all still has to be written as if we were Americans. And speaking of language, Americans speak a wide variety of them. Have you ever tried to communicate with a New Yorker? They speak so fast it makes my ears hurt ... and they've apparently never encountered the letter 'R', either."

Get the picture? It's smart for companies to exploit their natural advantages over their competitors. That doesn't mean the playing field is tilted. It means American companies ... and individual programmers ... had better wake up and start finding ways to exploit their own advantages, of which there are many if we only had the wit to use them.

About right - the field isn't level in either direction - depending on how well you sell the advantages you have, the glass will either be half empty or half full. This is going to play out just like manufacturing did 20-30 years ago, so developers are just going to have to buckle down and figure out how best to deal with it. whining isn't going to accomplish a lot.

It's June 4th, and I live in Maryland. So why the heck do I need the heat on in the house? Yeesh....

Point your browser here to get the latest information on Smalltalk Solutions 2003 from STIC

Here's evidence that anything that can be coded, will be coded:

In an earlier life I engaged in a war with an enemy known as "6502 machine code". Via Don Park I found Crass - a 6502 cross assembler written in Python. I don't know whether to applaud, laugh or cry. I think I'll cry.

a 6502 assembler, in Python. Some peoplejust have eway, way too much free time on their hands :)

Charles Miller gets bitten by static typing:

This one hit me at work. I was modifying the facade of the subsystem I'm working on. I needed to go from: public RegistrationId register(User user, String param1, String param2) to public RegistrationId register(User user, String param1, Long param2). I wanted to do this without breaking anyone else's code, so I deprecated the first method, wrote the second, and checked it in.

I figured that was a pretty safe bit of interface evolution. I was wrong. Half an hour later, I was informed I'd broken the build.

The problem was: "null" was a valid value for param2. Because null has an indeterminate type, the compiler couldn't tell which of the two selectors was being referred to by the calling code. New code could get around this by casting null to the appropriate type: (foo.register(myUser, "blah", (Long) null);), but existing code didn't have that cast.

Now a set of unit tests would have discovered this problem easily enough, whereas the "safe" type checking couldn't. Also note the casting solution used for new code. Yes, this example makes me see the inherent safety in static typing, yes......

I've posted a few times on the SCO mess - now via Swaine we see that it's even more confusing:

It gave 'all rights and ownership' to SCO (actually to the Santa Cruz Operation) but retained all patents and copyrights. "This agreement is kind of murky.... You end up with a lot of questions, to put it mildly." -Shankland/Cnet 6/5/03

Does this rabbot hole have a bottom?

I've been busy working on some potential partner deals today, and in between all of that, working on the blog - the posting tool in particular. I've actually posted a version of it up with the dev builds for BottomFeeder - it works as a plugin, and also uses any relevant information in BottomFeeder for things like trackbacks, pingbacks, etc. The tool supposedly supports the Blogger API and the MetaWebLog API, but I only have my own implementations of those to test against - and I don't use them in production anyway.

Sean McGrath gets it:

So it boils down to this - do you want to be constrained in terms of flexibility or provably, formally, "correct" at some probably academic level? I'll take flexibility thank you very much!

... Here is a bold statement. By 2010 "compilers" will be a quaint anachronism. A throwback to the days when illusions of speed and illusions of correctness held sway over real speed (massive parallelism such as XGrids) and flexibility-based-design.

Go read the whole thing

Y. B. Normal talks about one of the common knocks on Lisp - the syntax:

This is bound to come up every now and then. Graham Glass writes:

LISP was an incredible work of art. so simple and so reflexive. but an absolutely crap syntax that doomed it.

In response, he got some of the expected "stupid, the syntax is what makes Lisp so powerful" comments (which I'll not link to), and some interesting ones (see his comments page). This debate comes every often, with Lisp gurus telling everybody else not to worry about the syntax and that they'll get used to it, and everybody else saying how they like Lisp, except for its syntax.

You hear some of the same about Smalltalk. Scratch the surface of this complaint, and you'll almost alwaysfind "but why can't it use curly braces and semi-colons like a normal language?" Inertia explains everything you need to know about this complaint.

I've been working on the posting tool for this blog the last two days,and it's finally in a state I'm mostly happy with. I'm bundling it as a plugin with BottomFeeder now as well. That means I will now shift back to Bf, for some work I've been letting slide. I still neeed to have a look at the NullSoft installer, and have some work to do on various other bits that need cleanup.

I run the dev version of BottomFeeder so that I can tell what I've messed up as I go. Recently, I noticed that a bunch of blogs I read regularly didn't seem to be updating. Taking a look, I found flaws in my module support, which is the biggest new thing in the development code. I'm now fixing those flaws; there will likely be a number of new dev builds posted today.

I've posted on SCO a few times now - it just keeps getting weirder. Now we get this:

SCO has come up with a document that appears to refute Novell's claim to the Unix copyrights that SCO is holding over the Linux community's head. But if SCO only learned of this document yesterday, it can't have been the basis for its billion dollar lawsuit against IBM or its threats against other Linux vendors and users. "A SCO paralegal found the amendment Thursday in a filing cabinet, Stowell said."

This is just getting stranger and stranger.

I have another Cincomer interested in running a blog - internally at first. That meant that I had to make the tools more easily usable by someone who isn't me :). I now have a start on that, and we'll see how it goes next week.

A reader pointed me to this interesting column. It traces the history of development, from the pre-assembly days to the present. I liked this comment on the invention of high level languages:

With Fortran and the languages that followed, programmers finally had the tools they needed to get into really serious trouble. By the 1960s large software projects were notorious for being late, overbudget and buggy; soon came the appalling news that the cost of software was overtaking that of hardware. Frederick P. Brooks, Jr., who managed the OS/360 software program at IBM, called large-system programming a "tar pit" and remarked, "Everyone seems to have been surprised by the stickiness of the problem."

Heh. The article examines AOP, patterns, and XP as follow ons from OOP; it's not detailed, but does make a few points. The summary is perhaps the best part of the whole thing, with this observation:

After several weeks' immersion in the how-to-program literature, I am reminded of the shelves upon shelves of diet books in the self-help department of my local bookstore. In saying this I mean no disrespect to either genre. Most diet books, somewhere deep inside, offer sound advice: Eat less, exercise more. Most programming manuals also give wise counsel: Modularize, encapsulate. But surveying the hundreds of titles in both categories leaves me with a nagging doubt: The very multiplicity of answers undermines them all. Isn't it likely that we'd all be thinner, and we'd all have better software, if there were just one true diet, and one true programming methodology?

Cynical or observant?

Yes, shipping code that is too slow to deal with is a problem. However, this post gives me the willies:

I was very excited to see two great articles on MSDN starting to address the performance implications of managed code.  For the last two years there has not been a lot of information on what managed operations actually cost. There has always been the Managed Profiling API for the hardcore but the general tendency in .NET is to make things radically easier for the programmer ("Let Go and Let the Runtime") and abstract things away to the level where some forget that there is even a runtime. Forgetting about some of this and not understanding GC, Finalizers, and the basics of the CLR leads to many problems including bad performance.

summarized by this:

The second article, Writing Faster Managed Code: Know What Things Cost goes even further with tables showing times for each of the IL primitives!  I love the way Jan starts this:

Don't do it. Instead, stand up and pledge along with me:

"I promise I will not ship slow code. Speed is a feature I care about. Every day I will pay attention to the performance of my code. I will regularly and methodically its speed and size. I will learn, build, or buy the tools I need to do this. It's my responsibility."

This is putting the cart way, way before the horse. The old adage applies:

• Make it work
• Make it fast

Modify the second part with - if it matters. Worrying about how fast code is while you write it is a recipe for dangerously unmaintainable code. Create natural code, and if there are problems - use a profiler. See if what you think is slow is actually what's slow. In many cases, it won't be. The very last thing you should consider while writing code is how much it "costs" in performance terms - at least for the vast majority of business applications. Yes, there are exceptions. No, most of us aren't involved in development of one of those exceptions. If this is the sort of advice Microsoft is peddling, I foresee a plethora of unmaintainable monsters coming down the .NET pike.

SCO has shown some cards in the Linux fight:

PARK RIDGE, Ill. -- SCO Group revealed the foundation of its legal battle with the Linux community, when it rolled out evidence of large blocks of Linux code that it contends were stolen from Unix. Analysts who saw the samples of the allegedly stolen code said the evidence is damaging and that SCO Group has a formidable legal case.

"If everything SCO showed me today is true, then the Linux community should be very concerned," said Bill Claybrook, research director for Linux and open-source software at the Aberdeen Group (Boston).

The see-saw keeps tipping back and forth in this one. The reason SCO has gone this route is made clear later in the article:

SCO contends that by co-opting code from Unix, Linux has severely damaged SCO's intellectual property. According to some estimates, the company collected annual revenue of between $200 million and $250 million on Unix System 5 software before the rise of Linux. After Linux reached the mainstream, those revenue figures dropped to about $60 million a year.

It's all about trying to get license revenue. Will it work? Who knows - I'm not even going to try to make predictions involving the US legal system...

One of the things that the BottomFeeder project has really gotten across to me is how hard the finishing touches of a softtware project are. Building something suitable for your own use is easy. Whatever warts or issues the software has - you'll be willing and able to just overlook them. Once you decide to let other people start usiing your software, the rules change - dramatically. The sharp corners become obvious - the issues you consider irrelevant start to loom large.

This hit home for me again at the end of last week. One of the marketing folks here at Cincom has decided to run an internal blog as a way of sharing project information between and among groups - pretty much what this post was all about. So what I had to do is package up my blog and blog posting stuff in a way that someone else could make use of. Fortunately, the whole BottomFeeder project gave me some worthwhile experience (and packaging tools) for this. So yesterday, I got the blog and the blog posting tool packaged up as double clickable Windows applications. All I'll really have to do is help the interested party get the ini files set up, and they should be good to go. I've also got it all set to start up from a base image that loads the appropriate parcels, so getting updates out will be simple.

Everyone who develops software should really go through the experience of releasing code for other people's use - there's really no other way to have a solid appreciation for the difficulties, both large and small.

Keith Ray makes some points about Smalltalk that more of us in the Smalltalk community should be paying attention to.

Here's the announcement for the next WOAD meeting - note that they are asking for RSVPs!

WOAD Thursday 6/19 - Agile Programming and the CMM - Note: this WOAD is a Thursday - Space WILL be limited to those who RSVP.

WHAT	WOAD (Washington Object-Oriented Architecture and Design)
WHEN	Thursday, June 19th, 2003 at 7:00 PM
WHERE	Best Western of Rockville (in the Restaurant)
DINNER	Buffet $12.50 (includes tax $ tip - to get the space, we have to eat)
TOPIC	Agile Programming and the CMM: Anti-Matter and Matter or Reconcilable Differences?
SPEAKER	David Kane

The Department of Defense and many other government agencies have made investments in the Capability Maturity Model (CMM). Increasingly, it is common for CMM capability to be required of bidders for RFP's. However, while the CMM has been a focal point for process improvement for the past decade, there has been a surge in interest in "lightweight" or "agile" methodologies such as eXtreme Programming, Adaptive Programming, SCRUM and Crystal. At first glance, these agile methodologies would appear to be at odds with the goals and approaches of the CMM. Make no mistake -- there are major differences. The CMM is often described as replacing the cowboy programmers archetype with repeatable processes, while the Agile Manifesto specifically calls for an emphasis of people over process. Ironically, if you examine many of these agile processes in detail, you find most, if not all of the characteristics of a "mature" software development organization. How do we resolve this conflict? Is there a role for agile methods in major government software development activities?

About Our Speaker:

David Kane is a Software Architect at SRA International in Fairfax Virginia. He is an author of Software Architecture: Organizational Principles and Patterns from Prentice Hall. Additionally David has authored numerous articles and talks for process conferences and publications. He has developed and taught courses in XML, Java and Software Architecture as well. David is currently developing genomics software for the Laboratory of Molecular Pharmacology in the National Cancer Institute of the National Institutes of Health. David's Home Page

RSVP

Put WOAD-RSVP in the subject line. RSVP by email to. Space WILL be limited to those who RSVP.

LAST WOAD / Handouts: In April, WOADees participated in the first WOAD Patterns Game. Participants of all levels found the game fun and educational. A few handouts from the game will be available for those attending the June WOAD meeting.

DIRECTIONS TO WOAD: Just off 270 FROM THE SOUTH: Take your best route to 270 North. Take the 2nd ramp at the Route 28exit (exit 6B) (Darnstown/Poolsville). This will put you on Route 28 going the opposite direction from Ledo's. Cross over 270 (one light) and turn right just before the second stop light (Shell gas station on your left, Best Western sign on your right). This will take you onto a long driveway for Best Western. Park and join us in the restaurant.

FROM THE NORTH: Take your best route to 270 South. Take the Route 28 exit. Turn right at the light. This will put you on Route 28 heading the opposite direction from Ledo's. Turn right just before the first stop light (Shell gas station on your left, Best Western sign on your right). This will take you onto a long driveway for Best Western. Park and join us in the restaurant.

This looks like it will be interesting - I plan to attend, taking notes!

I just realized that I've been blogging for a year now. When I started this, I had no idea where it would go, and I had virtually no traffic - during the first few months I had this running, I was getting in the single digits of unique visitors per day. Then in August, one of that handful of readers asked me about an RSS feed - and my response back was - "what's RSS?"

Skip forward, and I not only know what RSS is, I'm crazy enough to work on BottomFeeder - a VisualWorks based RSS Reader. The blog unwittingly exposed me to the whole range of things going on in the Blogosphere - I now have 135 subscribed feeds in BottomFeeder, and can't imagine trying to keep up in this field without an aggregator. And it all started with the blog, and a small question about providing an RSS feed. It's been a great year!

Manageability compares IRC to blogs - and I think he has a misunderstanding:

IRC is like a chat room but with more listeners at a given time. Not everyone really speaks, in fact the vast majority are lurkers. This got me thinking of the inefficiency of it all. See with blogging I've been averaging 534 unique visitors a day, however if I wanted the same kind of audience for IRC, I would have to be online 24 hours a day.

The two really aren't the same, and you don't us them for the same thing. I'm on the Smalltalk IRC channel all the time - and it's really not the same thing as blogging. IRC allows for instant communications - it's especially useful (IMHO) for those of us who work at home - it works like a virtual "water cooler". During the day, it affords an opportunity for conversation if I want it to. It also allows me to interact with people all across the globe. The bottom line is, sometimes you want asynchronous; other times you want synchronous. It all depends on the nature of the conversation.

I found myself wanting to disagree with this post, but instead came away thinking it made a lot of sense. Charles Miller points out the potential issues with systems that allow voting on bug priorities:

This leads to a dilemma. If the software writers do not have the courage of their convictions, they will waste time fixing bugs that should be low priority, but that attract the attention of a vocal minority: (Linux or Mac users, for example1). If the writers stick to their guns, they will be feeding a public resentment among users that will spill over into newsgroups, user groups, Slashdot, you name it. The "This is the most voted-on, commented-on bug, why isn't it fixed!" syndrome comes into play.

While you don't want to ignore users - after all, they pay your salary - you don't want to be swayed by a small (but loud) minority either. Go read the whole thing and see what you think...

I've put new snapshots of the blog code here on the Wiki. In particular, I've got Windows executable for the blog and the blog posting tool. The settings arenot nearly as easy to set up as I would like, and there's a lot of cruft there as well - I've mostly just added stuff as I've needed it.

Alan Knight's comment here led me to ambrai.com - not a lot of details, but it looks like a native Macintosh Smalltalk is busy being born!

via Matt Croyden, we get news that Richard Stallman will speak in the DC area:

When	Thursday June 12, 6:10pm
Where	Phillips Hall, Rm 415, The George Washington University, 801 22nd Street, Washington, DC

I had noticed recently that as BottomFeeder ran, the memory consumption slowly rose - over the course of a day it was closing in on 100MB, after starting out around 34 MB. I spun up a development image with the application running to see if I had a leak - and I didn't. So it was back to the MemoryPolicy tuning drawing board.

In this case, there are two variables of interest to us:

• growthRegimeUpperBound - this is checked when the system is trying to decide, in the abstract, whether it should scavenge memory or grow. It's a soft limit on upwards growth
• memoryUpperbound - this is the hard limit - whatever this is set to (SmallInteger maxVal by default), the system won'tgo beyond.

You want to be very careful with these. Set them too low, and you could get thrashing or completely unresponsive applications. Set them too high and you could have an application that cheerfully allocates its way to complete ownership of your system. Here's what I did for BottomFeeder - I created two new settings, under the memory tab in the settings tool. The soft limit can't be set lower than 32MB, and the hard limit can't be set lower than 40 MB. They default to 40MB and 96 MB respectively; you can twiddle them to better suit how much space you want Bf to take up on your system.

Via Ted Leung, I see that Sun has created a community site with blogs and wikis. It's a lot like gotdotnet.com from MS- except that MS, having a larger cluestick, has RSS feeds. That's Sun for you - they always understand exactly half of any good idea that stumbles by them...

I've posted on this before - the whole ugly issue of outsourcing. This post makes a lot of sense to me:

To someone like myself, who's been in the computer business for more than a quarter of a century (and always in demand), the prospect of becoming unemployable at 40-something is downright frightening. In the current IT labor market, I'm too expensive to hire. A company can get five people offshore for the cost of one of me.

Now, the standard reaction here would be to call for action to block this trend, legislate against it, restore things to the way they used to be. But, pragmatist that I am, I think that's an exercise in futility. The market does what the market does - it's that simple. The only way to influence the market is to offer a better value proposition

That's about right - if you think legislation the the way to go, go look at how well that workd out for the large steel firms that started getting slapped around in the 70's - they spent mountains of money on legislation, and still got waxed. Ron Hitchens is onto the better answer:

The offshore operations, of necessity to keep costs down, will become rigidly structured, assembly line operations (if they aren't already). You need an accounting system? Fine they can do that and do it very well. Inventory? Financials? No sweat, done it a million times. But if you need highly customized, innovative, ground-breaking stuff; software that's integral and vital to a new hardware device or business process or biological model or whatever, you need a tightly focused team onsite that can adapt and react and make it work right now.

It strikes me that this pattern echoes the Agile vs. DBUF debate. Offshore by its very nature has a high communication latency and the customer, almost by definition, is disconnected from the development process. This favors the Big Design UpFront approach. For well-understood business processes, like accounting, inventory, etc, this can and surely will work out fine.

And for the more custom jobs? It'll work out just as well for the offshore guys as it has for the large IT shops here. If you think all work is going to trend towards the assembly line - well, I have this bridge....

Go read the whole thing

Via Gordon Weakliem comes this link to Dave Thomas' site - follow that to this prsentation, which has some concrete proposals. Good reading there.

Periodically, people make comments about the bloat of Smalltalk. In fact, just recently Sam Ruby left this rather uninformed comment on my blog, which talks about the supposedly abysmal performance of Smalltalk. This is of a piece with the theory that Smalltalk is bloated.

I ran up against this in development recently - BottomFeeder was continuously growing - after a day of running, it was chewing 150+ MB! That wasn't acceptable, so I built a clean dev image with Bf loaded (just one of the many cool things about Smalltalk - real live objects). After a few updates it was clear that I wasn't leaking memory at the application level - I thought I might have

• Extra XML docs from the read/update loop
• Extra RSS Items from the same thing

Nope. Turned out to be a combination of two things. First, I had to play with the memory growth parameters. That solved some of my problem, but BottomFeeder was still growing slowly. Then it dawned on me - The Transcript!.

For development purposes, we toss lots of messages to the Transcript - it's an easy way to see what a feed or item has without stopping the update process. The problem is, I left that in the runtime - so as each update loop ran, the Transcript grew. I have a lot of feeds, so it grew a fair bit. Combine that with the generous memory settings I had on by default, and it was easy to see how the application just kept growing and growing. Now it's much better - I just had a look, and it's standing at 26MB. That's pretty nifty, especially after I saw this post, where SharpReader was consuming 74 MB for that user. I'm feeling pretty good about Bf's memory consumption now.

I've updated the TypeLess plugin for BottomFeeder to the latest code released by the TypeLess guys. There are a bunch of fixes, not all of them visible. It's been pushed out both in the 2.9 and the 3.0 dv stream, so enjoy!

I got my 15 seconds of fame earlier this year - now Eric Clayberg gets his airtime - but for a decidedly non-Smalltalk topic:

If you ever wondered what kinds of non-Smalltalk hobbies Smalltalker's enjoy...

http://www.smalltalksystems.com/clayberg/arcade/arcade.htm

On December 12th of last year, a production crew from HGTV descended on my basement to film a segment for their upcoming special, "Incredible Basements". They were here for nine hours and recorded about three hours of tape which was condensed down to a six minute segment in the show (my basement is one of seven segments). Here are some pics I took the day they were here:

http://www.smalltalksystems.com/clayberg/arcade/HGTV/

HGTV's "Incredible Basements" will air this coming Sunday, June 15th at 9:00pm (both EST and PST): http://www.hgtv.com/hgtv/spcl_prsntn/episode/0,1806,HGTV_3909_22534,00.html

I tried to place a few recognizable Smalltalk artifacts around my basement and office, but I don't know whether any of those shots made the cut. LMK what you think, if you get a chance to see it!

Tune your DVRs...

Loosely Coupled has an interestting take on the rise SOA (Service Oriented Architecture), and its implications for IT consultants:

His implication that IT consultants will simply be able to turn to business process consulting is misleading. Business consultants, not IT consultants, will perform business process consulting (as they always have done). If IT consultants want to hold onto their livings when integration work disappears, they'll have to do more than retrain: they'll have to join a completely different profession.

hmm. I tie this all in with the trend towards outsourcing and offshore work more than I do with SOA. As the mega IT shops get "right sized" - and much of the work disappears offshore - what are the large body shops going to do? I suspect that they are going to bleed. Stop and think about that for a moment - because there are some larger implications. A lot of people seem to think that open source projects will thrive in this environment, but I'm not so sure. A lot of the big OS projects are funded by big companies - like IBM - that get a lot of their money from services. If the outsourcing wave impacts that, OS will be one of the things impacted by the ripples. It's all guesswork at this point, but there's little doubt that a sea change is happening in the IT sector. The go go days of the 90's are not coming back.

Via Managability I saw this from Richard Gabriel of Sun:

Many of Sun's Java activities have never made a profit and never were intended to. This had always been justified by the phrase, "Church versus State." "State" was the part of Sun trying to make money with Java, and "Church" was the part that pushes and maintains the values Java represents. And the latter was never intended to make money. Think of how many companies would ever embrace an idea like "Church?"

That's interesting, and quite a few people have been reassured by this comment (based on things I see blogged). If Sun's revenues continue to have trouble, it will be very interesting to see the reaction if/when Sun can no longer support this.

Manageability seems to have a preference for loosely coupled, dynamically typd systems - in the abstract - but comes down on the static side for tool reasons. Hmmm -

If you recall however, my arguments were not for more correctness rather it was a realization that being more explicit allows a compiler to do a lot of the thinking for you. That is, the navigation, auto completion, on the fly checking, quick fix capabilities that you find in Eclipse and IDEA outweigh the productivity benefits of any dynamic typed language. People who program in both environments know this as a fact.

Navigation? You mean like senders/implementers, etc? Invented in Smalltalk. On the fly checking? I can run my tests before, during and after I write the code, and fix any issues on the fly. Quick Fix? I apply quick fixes to Smalltalk apps that are deployed. I love the "know this for a fact" when it's clear that he knows very little about dynamic systems - or perhaps, his knowledge is woefully out of date....

From John O'Keefe:

IBM will once again sponsor and participate in the Smalltalk Solutions conference. The conference is being held at the Crown Plaza Toronto Centre in Toronto, Canada. The show starts promptly at 8:30 a.m. Monday, July 14th, and includes three full days of keynotes, tutorials, experience reports and exhibits from various Smalltalk vendors and users.

IBM will present a session on Smalltalk Development Tools for Eclipse, a new addition to this already rich development environment. This talk will examine IBM's direction for an open-source Smalltalk environment.

At the IBM booth, there will be demonstrations of VisualAge Smalltalk Web Services framework, integration with WebSphere and other new features that help Smalltalk developers be successful.

You will also have the opportunity to talk with the lead developer on the new Smalltalk Development Tools for Eclipse.

For additional information on Smalltalk Solutions 2003, including how to register, please go to http://www.smalltalksolutions.com.

John O'Keefe IBM Smalltalk Group

Sam Gentile posted a great summary of the whole discussion, which I had originally commented on here. It's a solid wrap up with lots of good links - check it out

Jump into the wayback machine (courtesy of Bob Westergaard), and have a look at Smalltalk in 1977 - when a California high school student used it to build a flight simulator!

PC Magazine has noticed the blogosphere:

Once the pastime of only dedicated Internet surfers and amateur writers, blogs (short for Weblogs) have become mainstream. More people than ever are getting news, information, and opinions from them. Similarly, blog writers are becoming more diverse, including traditional journalists, soldiers in the field, citizens in a disaster area or war zone, and average people yearning to express themselves. In many cases, content can be compelling because it is so personal and timely.