There's a seminar in Baltimore tomorrow on WebSphere and such. I decided to have a look after getting encouragement from a former customer at the St. Paul Companies (used to be USF&G, and a VSE customer). I'll have the laptop, and expect to be taking notes during the talks. If there's Wireless access, I'll post, but who knows. I have to get up at an unnaturally early (for me) hour as well - it's been many years since I've driven into Baltimore during rush hour.
I'm changing that old standby based on this year's weather. There are lies, damn lies..... and Doppler Radar
If you are in Ottawa July 3rd, make sure to visit the local STUG:
The Ottawa Carleton Smalltalk Users Group is happy to announce the next meeting on July 3, 2003:
A new MacOS X Smalltalk
Dorin Sandu, Mark Suska, Ambrai.com
Date: Thursday, July 3, 2003 Time: 6:30 PM Location: Carleton University (see details below)
We will introduce a brand new Smalltalk system that runs natively under MacOS X. After a tour of the development environment, we will cover the design and implementation of the user interface framework including the native interface to the OS. Time permitting, we will review VM design issues and discuss future development plans.
The meeting will be held in Room 5115, Herzberg Laboratories (building 13 on the map - (http://www.carleton.ca/cu/campus/map.htm )). Pay-parking is available in Lot 1, 2, and parking meters can be found along University Drive. Free parking is available across Bronson Avenue opposite Lot 5.
Please RSVP to firstname.lastname@example.org if you plan to attend.
Enjoy - the Ottawa group is a great bunch!
Here's what customers like to here:
Oracle's $5.1 billion takeover play for PeopleSoft, a rival software company, undoubtedly puts Mr. Ellison in the middle of a bloody corporate battle. But whether he eventually leaves the ring in control of PeopleSoft or not, he may already be the winner just by making the hostile bid.
If Oracle ever reaches a deal to buy PeopleSoft, Mr. Ellison has said he intends to shut it down and transfer its customers to Oracle's eBusiness Suite software. But a takeover is viewed as remote because of possible antitrust objections and since PeopleSoft's board has already rejected the offer and filed a lawsuit on Friday against Oracle, accusing it of unfair trade practices.
I'm sure that makes the end customers feel all warm and fuzzy. And the analysts are already helping out:
Ted Kempf, an analyst at Gartner Research who advises companies about software purchases, told his clients last week to avoid PeopleSoft until the takeover fight was resolved
There's been a "why are you bothering to advocate Smalltalk - Java won" thread going on in comp.lang.smalltalk and comp.lang.java.advocacy. It was the usual blend of time-wasting until this came up:
Technically Java the language is now well out of date.
There are better languages out there now - but they lack Java's volume and momentum.
I don't know how far its initial surge will carry Java - I currently expect it to last for quite an extended period.
Which is interesting. The poster is saying - "we know there are better answers. But this is somehow more comfortable". That's worthy of comment all by itself, but the follow-on comment cemented it:
and there's the key, lady and gents!
So it's all about momentum then? I wonder how happy these people would be in a skyscraper built under that philosophy, or a bridge. "We know these materials are second rate, but golly, everyone uses them!". This is one of the major reasons, IMHO, that the public in general, and engineers in particular, don't take software developers seriously. As a community, we like fads better than we like facts. We like trends better than we like things that work well. We would rather drop what w have, even thought it's working, and go with some new, trendy thing. The funny thing is, developers tend to sneer at this sort of sheep-like behavior in other domains, from politics to fashion. Interesting how they conform, just like most people, within their own domain.
If the VW GUI - codenamed Pollock - work is of interest to you, then head to Smalltalk Solutions and register for these two talks:
SCO says they have pulled IBM's Unix license. Now it gets ugly...
This morning McNealy let loose with more silliness:
"Consumers more and more will demand Java based mobile devices like phones and PDAs essentially ending the consumer era of software sold separately," McNealy said. This is especially important for the gaming industry. Those guys get really mean when they can't play their Java-enabled games."
This is truly amazing. Most consumers of phones have barely heard of Java, or C, or VB. Or Smalltalk. Nor do they care. What they care about is that the application/game mix on the device they bought works, and solves whatever problem they want them to solve. If McNealy really thinks that consumers are clamoring for Java, he needs to have his meds adjusted. The makers of phones may care. The end users most certainly do not.
With MS announcing that IE is going to be part of the OS, period - a few questions come up. The .NET guy puts his finger on them:
Last month, they announced the cancellation of IE for Windows, saying that new versions would only be part of OS upgrades and that their stand-alone browser was dead. Assuming they manage to ship Longhorn in 2005 (doubtful, given their deadline track record), and it takes 2 years to get good upgrade penetration, that means it'll be 2007 before we can assume something besides the fairly buggy and only moderately standards-compliant IE 6 -- assuming they're even interested in increasing their standards compliance.
This month, they announced the cancellation of IE for Mac (which was a far better browser than IE for Windows). Their claim is that user-requested features require tie-in into the OS, and since they don't control the OS, they're giving up altogether.
This is what Microsoft thinks will help them hold the browser market? Getting off of one platform entirely, and leaving an already 3 year old browser to sit for ANOTHER 4 years before it has good penetration? I've noticed a steady slide already of visitors to my site. Six months ago, the visitors were using Netscape/Mozilla about 1% of the time. Now it's 7%.
I see the same uptick of Mozilla users here. Apparently, MS doesn't think that the 4 year gap from Netscape 4.7x to Netscape 6 was a significant factor in their decline. I think that's the most significant factor. Sure, a browser that ships with the OS makes for a nifty default. But if the default is stagnant long enough, some percentage of your user base will wander off the reeservation. Either MS doesn't care what browser you use, or they have made a serious mis-calculation. The traffic numbers over the next few years will tell the tale.
There's an interview of James Gosling in ComputerWorld discussing the IBM backed SWT GUI framework for Java. I'm amused by the interviewer's consistent complaints that the SWT is "proprietary" - is he clear on what that means? Java itself, while freely available, is proprietary. In what way is availability of the SWT different than anything else in Java? The fact that it's an idea that didn't originate at Sun, maybe?
Q: Is it dangerous for that proprietary elements are surfacing for Java?
A: The SWT folks, because it is so proprietary, it's very nonportable and lots of people actually care about portability. So it hasn't been getting the uptake. It's been annoying rather than alarming.
It's interesting to me how SOAP has so much hype, and (apparently) so little actual usage. The blogging world has adopted XML-RPC and simple post mechanisms; Amazon sports two API's - SOAP and a simple url based system. The latter is much more heavily used. This seems to mirror what happened with CORBA - a lot of hype, a few vendors got heavily into it, and a few IT shops made heavy use of it. The rest yawned. Manageability explains it like this:
I also think that standards groups tend to choose the lowest common denominator of innovation. That is, standards groups tend to only approve innovation that they all collectively grasp, however in most cases innovation tends to be grasped only by a few.
Another problem with standards groups tend to create documentation rather than implementation. That is a fatal flaw which I explored in "Be Liberal in What You Accept, Conservative in What You Send". The lack of a standard compliance implementation undermines interoperability, the core essence of standardization.
It's interesting that standards groups give the participants an illusion of choice. Unfortunately, history clearly shows their fate is preordained.
There's something to this. Standards that grow up around actual usage patterns are going to fare better than the "theoretical" ones.
According to CNet, The Council of Europe is trying to put in place a media-wide version of the old "Fairness Doctrine". The theoretical goal is to ensure that someone being criticized can have their response; the likely actual result will be that controversial topics will be avoided in order to avoid trouble. Go read the article - it could affect all manner of online communications in Europe soon.
We actually got through a day without rain here - and a good thing too, since my daughter's end of the year girl scout picnic was today. That went off without a hitch - we had clouds, but no rain.
I've been reading and hanging out all day, not doing a lot. Except waiting (sigh) for the rains to return....
A friend of mine who attended Java One said that the whole vendor area was smaller than he expected - this may well just be a sign of the ongoing down turn in vendor participation at trade shows. Still, this story from InfoWorld is interesting:
This year, IBM dropped its sponsorship of the show after last year being a platinum sponsor, which is the highest level available, and had a reduced presence on the show floor where it demonstrated its Rational developer tools and Pervasive Computing offerings, but omitted its popular WebSphere product line.
IBM speakers also kept a small footprint at the event, appearing in none of the keynote addresses and in only about a dozen of the more than 400 technical sessions
So does it mean anything? Hard to say.
I've noticed that BottomFeeder could, with enough feeds, start taking up large amounts of RAM. Running in a development environment showed that I wasn't generating any leaks, so it was either MemoryPolicy, ObjectMemory settings, or both. I've been twiddling with the MemoryPolicy settings for a couple of weeks now (with some good help from Terry Raymond) - but that wasn't solving the whole problem.
Then it occurred to me what was probably happening - premature tenuring. VisualWorks allocates new objects in Eden (and uses the two survivor spaces to manage new objects). When survivor space fills up, and new objects aren't ready to die yet - they survivors have to go somewhere to make room for the new stuff. That somewhere is Old Space. So what if you allocate a lot of new objects quickly, and they keep filling up the survivor spaces? You'll get rapid tenuring of objects that would otherwise die. These end up in Old space, where they won't die until you your system runs against a memory limit (either the one imposed by MemoryPolicy or a hard system limit). At that point, you'll see the compaction and GC icons a lot if the allocation pattern continues, because those new and survivor spaces still aren't big enough - and growth is capped. I've talked about this issue before; this is kind of a continuation of that earlier post.
So what do you do? You go look at ObjectMemory class - #spacesAtStartup:. I had to create a new base for this because changing the settings here require an image save, and BottomFeeder (and most end user Smalltalk apps) never save the image at runtime. What the settings allow you to do is scale the various space sizes up. Now, why is this a problem in an application like BottomFeeder?
Consider what BottomFeeder does - every N minutes, it wakes up and trawls through your subscriptions, looking for new content. That means do an HTTP query (grab text). Parse the results into an XML document (a largish new object). Then create item objects from the xml, and check against what we have (more new objects). I am currently subscribed to 140 channels, which makes for a lot of new objects - fairly quickly - during an update scan. So with eden and the survivor spaces set to their default sizes, lots of these objects end up in old space, which is not where they should be - none of them are really "permanent" from an application perspective.
I ended up sending this message as part of the new build:
ObjectMemory sizesAtStartup: #(10.0 10.0 3.0 1.0 1.0 2.0 1.0).
The important numbers are the first two - they ask the system to make eden and the survivor spaces 10x bigger than they normally would be - and with that increased size, there's less chance of premature tenuring. This is an important thing to keep in mind for all kinds of applications - what looks like an application level memory leak may well have a system level root. Now, it's always a good idea to look at what's going on before you start mindlessly twiddling these numbers - if you have a dependency issue, where lots of objects are ending up in the DependentsFields shared variable, for instance, you have an entirely different problem. So keep this technique in mind, but look at the behavior of your application before applying it.
I upgraded this server from V 7 to vW 7.1 yesterday, and that meant a few changes to the applications here - one critical one to the piece that reads in the initialization files, since I had made a change to that application a few months ago. I got everything updated except the NC app. Sorry for the problem; it's all better now
Ara Abrahamian lets loose with a UML rant:
Imho the biggest problem of UML and MDA-based software development is that, well, the code isn't even close to what you've diagrammed! I mean take a look at buildings around you. It's easy to map what the architect drew on his board to the real tangible building. With UML the diagrams are something the designer guy draws and understands but the real program has very little resemblance to it! The designer prefers to speak a more engineering-oriented language, UML, while the masons (developers) don't like or understand it because they have to build the damn building and the architecture they are given by the modeling guy is so different from what they build. They speak two different languages. That said there is value in a engineering-oriented bureaucratic approach too, after all the civilization is built by architects rather than masons, right? So fix the gap otherwise just shut up and don't preach it :-)
I can't say I disagree with his assessment of the value of UML...
So Slashdot has a story on Jackpot, Gosling's latest take on devlopment. It's occurred to him that having the program parse tree around makes things like refactoring easier. Gee, he could have called Don and John and had them explain it. I bet they would have even been willing to use small words.
Even if his view is limited to Java, you don't suppose he's ever heard of Eclipse or IntelliJ?
I spotted this on Being Effective:
My ability to be an effective change agent depends completely on my ability to influence my teammates and management. They aren't going to do anything differently just because I say so.
I need creditability with people who are managers. And that creditability takes many forms -- it could be about my knowledge and skills; it could be about who I am as a person; it could be about a shared interest. Whatever it is, that person will invest more time in communication with me than someone else.
Let's say I have creditability with Noel who is a third-level manager. Now I have periodic opportunities to make proposals to Noel. If our interactions create a return for Noel, I'll continue to have opportunities to speak with him. Otherwise, I'll lose access.
One way I can lose access to Noel is to tell him that things aren't working because he doesn't know what is really happening. That's like yelling "Fire!" in a crowded building. You are going to get arrested.
Yeah, I've wasted plenty of time complaining about things that just deflate me in the eyes of management. It's too easy to do - all you need to do is feel strongly about something, and then fail to translate it into language that the other guy can deal with. pick your battles
There was another brief server hiccup this morning - I just updated the application server that runs this site from VW 7 to VW 7.1. Sorry for any inconvenience this may have caused...
Wired has a story on Sun's problems. The basic problem is simple:
Share prices of nearly every publicly traded Silicon Valley firm have plummeted since 2000, of course, but few have fallen as precipitously as Sun's. As of early May, its stock, down 94 percent from a 2000 high, was trading pretty much exactly where it was in 1996, when the computer maker was in the early arc of its dotcom-fueled rocket ride. In its heyday, Sun sometimes sold as much as $5 billion worth of computer equipment, software, and services in a single quarter, but over the past few years quarterly revenue has dropped to nearly half that. Revenue fell an additional 10 percent in the first three months of 2003, marking the eighth consecutive quarterly decline.
The interesting thing, to me, is the "build it and they will come" attitude that sems to pervade Sun's strategy - Java is simply the biggest part of that view. Heres's the attitude in all its glory:
Forget the stock price and flagging sales, he argues, and focus on Sun's record of innovation. Technology, he insists, will turn the company around. He talks up a next-generation chip potentially 30 times faster than the microprocessors currently running Sun's most powerful machines. He and his team also point to a pair of software initiatives, N1 and Project Orion, that some of the company's biggest brains are hard at work on. "With all we've got up our sleeves, mate," declares Andy Lark, the New Zealand-born marketing chief, "we've got the competition quaking in their boots." That's quintessential Sun: The tech industry is ready to write off the computer maker, but McNealy and company are smugly imagining future glory.
I've seen this "our technology is so good that nothing else matters" business theory before - at ParcPlace. ParcPlace didn't have nearly the pile of cash that Sun does, but it also didn't have the burn rate. I suspect that what Sun needs more than anything else is what ParcPlace needed - new executive management. ParcPlace got it too late, and it's looking more and more like Sun will suffer the same fate. Watch the Java crowd be utterly baffled by this, since they still seem unclear on the "who controls Java" concept.
I was trying a quick update of the blog, and it took longer than I thought - if you got an error, it's because of the twiddling I as doing...
If you've wondered why VW 7 made strings immutable, read this explanation of the concept by Andy Bowers of Object-Arts:
The literal String object that contained the characters ($s $m $a $l $l $t $a $l $k) is still there it is just that you have replaced the first indexed element of the object with $S. Then anything that referred to that String will now be referring to the new form, i.e. 'Smalltalk'.
So in LearningWorks, and earlier versions of some modern Smalltalks, you could try this:string1 := 'smalltalk'. string2 := string1. string1 at: 1 put: $S. string1 "Display it" -> 'Smalltalk' string2 "Display it" -> 'Smalltalk'
While it looks like two variables, string1 and string2 have been oddly modified by this seemingly innocous act of modifying one of them this is not really the case. The key point is that Smalltalk treats variables differently from other languages. I only really "got" this point originally when someone explained that Smalltalk variables don't actually contain the object data (as they do in C++ for eg.) but actually they are "slots" that hold pointers to their objects. So effectively, Smalltalk variables are a bit like references in C++ (if that helps). So in the example above, string1 and string2 are holding a reference to the same object (the literal string 'smalltalk').
You might then wonder why modern implementations have made the modification of literal strings illegal. Well an example from early Dolphin Smalltalk might serve to illustrate this:
You may already know that you can use the #, message to concatenate one or more Strings together (in fact you can use this message to concatenate any sequenceable collections).string1 := 'Smalltalk', ' is ', 'Great'.
However, if you take a look at the implementation of the #, message in SequenceableCollection then you'll see that, because it has to take a copy of the source string each time, then this might become rather inefficient for a large number of concatenations. So, most of the time, you'll be advised to use Streams when concatenating large amounts of text. This is how you do it:stream := WriteStream on: String new. stream nextPutAll: 'Smalltalk'; nextPutAll: ' is '; nextPutAll: 'Great'. string1 := stream contents.
This may seem a rather long-winded procedure to tag a few strings together but, trust me, it's not really that bad in practice. Anyway, the point of this anecdote is that the above is almost the same as:stream := WriteStream on: ''. stream nextPutAll: 'Smalltalk'; nextPutAll: ' is '; nextPutAll: 'Great'. string1 := stream contents.
And we found that several of the Dolphin developers used this form and got into a terrible mess. To be honest, I'm not sure it was their fault since I think that some early Smalltalk texts may have suggested it. So, what is wrong with creating a WriteStream on a literal empty string? Well, possibly nothing in some Smalltalk implementations. However, when we were designing Dolphin we took a leaf out of IBM Smalltalk's book and decided that it would be a good idea to share identical literal strings wherever possible. So, if you use the same literal string in more than one place in a method we only create one instance of the string and both places that use it share the same object. We also discovered that in the entire image there were initially a lot of empty literal string ('') objects. Hence, we made the Dolphin compiler, when it saw '' inside some Smalltalk source, always refer the same single instance of THE empty literal string (i.e. there is only one empty literal string object in the entire image).
This means that, if you did a (WriteStream on: ''), you would be writing over the top of the contents of the single empty literal string. This in turn meant that, if you ran the above code, every reference to an empty string in the entire system would suddenly turn into a reference to "Smalltalk is Great". Although most of our users would have agreed with the general sentiment of this phrase, few who tried the above code snippet would have agreed with it when their code browsers suddenly started filling the contents of empty methods with "Smalltalk is Great"!!
Anyway, the result is that Dolphin now throws an "Attempt to update read-only object" exception if any attempt is made to modify a literal string. I believe that the recent change to VisualWorks to throw an exception in similar circumstances now brings all the mainstream Smalltalks into line with one another.
I hope this helps rather than hinders....
Andy Bower Object Arts Ltd.
Sun posts some irony:
Innovation happens everywhere. That's the nature of life. Alas, it just so happens that it often gets ignored or otherwise overrun by various kinds of steamrollers
Yeah, that Java steamroller has developers everywhere using sub-standard solutions.....
Spotted in cls and the vwnc mailing list:
SIXX 0.1g is now available for all major Smalltalks - Squeak, VW, and Dolphin XP. http://www.mars.dti.ne.jp/~umejava/smalltalk/sixx/index.html
For Squeakers, there is also a SAR version
SIXX is a XML serializer/deserializer for Smalltalk. You can exchange almost all Smalltalk objects among images.
- SixxReadStream can now read corrupt SIXX files with best effort (recovery mode).
- Now SIXX avoids sending readFrom: with String parameter.
- A SIXX Time generation test fix for different locales.
SIXX is driven by many users' feedback. I would like to say thank you to all of the contributors...
[:masashi | ^umezawa]
The SCO suit may give us a test of the GPL. CNet reports that SCO GPL'd their unix by shipping it with bits of Linux in it:
Several organizations argue that SCO Group's shipment of a Linux product undermines its current attack on the operating system's intellectual-property underpinnings, but SCO says the argument is baseless.
SCO says proprietary source code underlying Unix has been illegally copied into the Linux kernel. SCO critics argue that because the company shipped a Linux product under an open-source license, that Unix code no longer is proprietary.
But SCO, which has staked its future on its Unix intellectual property and how it's licensed, believes opening the source code would require a deliberate act the company didn't in fact undertake
Two things come to mind. First, will this mean a legal test of the GPL? If so, it should be interesting to see how that falls out. Second, I'd like to see SCO apply that "deliberate act" theory to the other side of their suit.
Once you get past that pledge, the order of this essay goes quickly off the rails. Gray deals out several thousand words of detailed and useful information about performance issues in CLR, and only halfway through the essay does he introduce the "CLR Profiler" and give advice on how to measure what your code is actually doing. This is probably wrong, because I think the way to write fast code is simple and has been well-known for a long time. Here it is:
- Design and code your app, trying hard not to do anything really stupid, and striving for flexibility.
- If it's fast enough, don't worry any more.
- If it's slow, get out your profiler and measure things until you understand where the problem is.
- Fix the problem, which may well require major refactoring, but that's OK because that's probably coming at you pretty soon anyhow with the next batch of requirements. Furthermore, you couldn't have avoided it because nobody is smart enough to predict where the bottlenecks will be in a complex application before it's running.
That's a perfect summary of how to go about getting a clean, maintainable application that is as fast as it needs to be.
I see that Sun is still not getting it at Java One. Via Simon Phipps comes this statement from Jonathan Schwartz's keynote:
The threshold that we call someone a developer, is going to be dropped significantly ... Sun have historically treated the developer with respect. Giving them the attention and kudos they solely craved. Java developers are real developers; they don't want to be labelled with the Microsoft VB/Marco crowd. Sun will have to be very careful in how they are going to take this forward without alienating and devaluing the current developer base
This comes in the context of talking about expanding the base of Java developers. That's just brilliant - a call to attract mor people that calls the users f the most popular toolset "not real programmers". This is actually one of the many reasons I dislike Sun more than MS - they come across as far more arrogant. Simon believes that the answer is to expand the range of languages on the JVM:
My personal view is that the way to expand the developer community is not to 'drop the threshold' but rather to expand the range of languages that target the Java platform. That's why the discussion in this morning's keynote concerning the embrace of programming languages like PHP and Jython (Sean will be pleased!) is so important. PHP and Jython programming isn't dumbed-down - it's just the use of the tools that are fit for the job, and embracing a wider range of tools simply expands the scope rather than lowers the bar.
There are two problems with this:
- The JVM is just horrible for dynamic languages (Smalltalk, Lisp, et. al.). I suppose most of the Java elite doesn't care, but they should - interest iin dynamic languages seems to be increasing. Watch Sun continue to not get it here
- As Ted Leung points out, this many languages idiom is what MS is pushing. Ted says: One of the supposed benefits of Java is that there is only one language that you need to know
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.
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!
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
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....
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.
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.
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...
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:
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...
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.
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....
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 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'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.
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...
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.