I heard this on the IRC Channel today
[Steve] Jobs has a reality distortion field that warps space around him, our management has a reality disruption field that keeps reality from entering their awareness
I heard this on the IRC Channel today
[Steve] Jobs has a reality distortion field that warps space around him, our management has a reality disruption field that keeps reality from entering their awareness
I read with interes Mark's comments here:
Java rules the server side. While some Smalltalk environments like VisualWorks have absolutely awesome web services support, the quality of free Java server side tools like Jakarta Tomcat, JBoss, Enhydra application server (not to mention many good, but expensive commercial products) make Java's use on the server a no-brainer. As per item 2, if you design and implement a Java based web application, don't you want to feel confident that your customer can find people to modify and maintain it?
By this argument, no one should have adopted Java in 1995, or 1996, or 1997 for that matter. Likewise, we should just give up advocating what we truly believe to be better solutions to problems, and just "get with the program". I'll note in passing that Mark posted heavily on politics a few months back - would he advise the same course of action with respect to that field? If not, why not?
What Mark's argument boils down to is "everyone does it, get with the program". I seem to recall my mother having words with me on that subject, a long, long time ago :)
Sun is lending verbal support to SCO - check out what Jonathan Schwartz is saying about the mess:
"IBM has been using Linus [Torvalds] like a tool and exploiting the open-source community." Those fightin' words come from Jonathan Schwartz, executive vice president for Sun's software group. He doesn't think IBM's Linux sales have been kind to CIOs, either. "They've been spreading IP [intellectual property] radiation" to companies that get their Linux from IBM because of Big Blue's contract problems with SCO Group. Sun, he hastened to add, has crossed all its t's and dotted all its i's with SCO just in case the Unix/Linux legal claims have merit
Meanwhile, ComputerWorld reports that wags at the JavaOne show were saying that IBM needed to buy Sun in order to save Java. Sun counters that with all the money they have in the bank, it's a non-issue. I seem to recall that ParcPlace had plenty of money circa 1996. Somehow, it wasn't enough to make it through 1999. Sun has more cash on hand - but they have a bigger run rate as well. Time will tell.
The NYC Smalltalk Group has announced their upcoming schedule of events -
We have the following events scheduled:
When What June 2003 Not meeting, postponed to early July July 9, 2003 Using PostgreSQL from Smalltalk - Bruce Badger, Openskills August 2003 Summer break , as is our custom September 17, 2003 Part 1 - Reuse through Totally Objects Frameworks
David Pennington, Totally Objects - The Smalltalk Resource
Part II - Round Trip Objects - an Emergency Claims system experience report
Dan Antion, American Nuclear Insurers, West Hartford CT
Check it out if you are in NYC!
Interesting post from Ara at Memory Dump:
Many OS projects just don't look clean and shrink wrapped. Working with many of them is like doing a open heart surgery! That was exactly the feeling I had when I ran JBoss for the first time with all those endless logs it spits!
I think the reason for this problem is that OS attracts geeks/elites only, but you can't create a successful product by just employing elites or charismatic frontiers. You need a mix of challenge and deep thought, plus some get-it-done kind of guys that view the thing from client's perspective and try to soften the hard edges of the product. With geeks you have some guys who can just draw amazingly beautiful sketches, but it's not a painting. With only get-it-done guys you just have some beautiful colors on the board, but it's not a painting either. Only a combination of both parties can create a beautiful Van Gogh painting :-)
That's probably true for an awful lot of the OS projects out there, and I'm not sure that there's a decent answer to the problem.
So far, SCO's increasingly threatening noises don't seem to be fazing anyone:
So far, however, AIX users seem completely indifferent to all of this legal wrangling. In a quick survey of half-a-dozen AIX system administrators working in businesses, none of them expressed the least concern about McBride declaring that they no longer had the right to use AIX. In AIX circles, at least, SCO's actions continue to be seen as idle threats.
So, is this just blowing by?
"Now, it seems to be quite likely that the matching Linux-System V code shown to the "experts" by SCO came from one of these files. And all because this is the original BSD code, which got copied everywhere."
This isn't a new theory. Ever since SCO first filed its lawsuit against IBM there has been speculation that they're basing that on old BSD code that was added to both AT&T System V Unix and many other Unix versions. But what's different here is that a process is proposed to identify all such common BSD code, eliminate it, and perhaps do some other things.
interesting, and entirely plausible.
The Register has some issues with XML. Mostly, it boils down to efficiency over the wire:
But according to some, it's not wonderful at all. XML and its close relatives Web Services come with three major problems: fat, bandwidth-eating formats, poor security, and high server loads.
All these issues are addressable, but don't fool yourself. XML may easy to write, but it could prove hard, very hard, to deploy successfully.
Many industry figures, like Steve Vinoski, Iona's chief architect and vice president of platform technologies, are worried about Web services performance. The main reason is that XML, unlike less popular, older binary-based interoperability standards like CORBA's Internet Inter-ORB Protocol (IIOP) and Microsoft's Distributed Component Object Model DCOM), is text-based, which means that data transmitted in XML format is bulky.
How much bulkier than binary? Schmelzer says XML formatting can fatten up a file by as much as 10 to 20 times. That's a lot of bytes to transfer even at Gigabit Ethernet speeds
Yes, Iona has a bone to pick as a CORBA vendor. Doesn't mean their wrong though. They also point out that compression is only a partial answer, since the compressed data will be converted to Base64 at a 30% volume markup. Then there's security, for which the only current answer is SSL.
Actually, the more I think about this, the more I agree with this post from a few days ago. Web Services is treading the same path, with most of the same big issues, as CORBA did.
Loosely Coupled has a post on how to fix Sun - I'm not sure I agree with his take:
As a systems manufacturer, Sun has one huge advantage over its main competitors IBM and HP, who are saddled with huge professional services organizations (IBM in particular). With spending on IT services plunging through the floor, those overheads are going to look more and more of a liability in the coming months. That in turn will make customers wary of being sold propositions that are designed to maximise services revenues, thus driving business into the arms of rivals who don't have such a huge consulting burden to bear.
I'm not sure I'd call it saddled with a consulting group. Both of those outfits have been building up their world-wide consulting staffs, and getting a fair bit of their revenue from them. But the next paragraph makes no sense to me:
Sun could do well out of promoting itself as the champion of lean, low-maintenance, consulting-lite computing platforms. The fact that its underlying hardware is actually proprietary is neither here nor there. As IDC analyst Dan Kusnetzky recently explained, it won't even matter what operating system people are running: "Widespread virtual-environment adoption will speed the current trend toward OS commoditization and decrease OS importance in IT infrastructures, he said," reports searchEnterpriseLinux.com. "IDC is certain that businesses will move to on-demand and virtual computing," and neither operating systems nor the flavor of the underlying hardware will matter any more, provided they do their job well enough.
How does commoditization of hardware and the OS help Sun? They have a high end OS and expensive boxes; the industry trends work against them, not for them. The Java group only makes it worse - it's a big boat anchor, likely costing more than it brings in, and promotes the following message: the hardware and OS are irrelevant. This is the very last message Sun should have been promoting over the last few years. Then the suggestion comes that Sun should buy Dell. Why? So that Dell's low cost operations could become high cost? Sun has less than no experience at the low end; they wouldn't have the slightest idea of how to deal with Dell. And I seriously doubt that Dell would want to be bought by Sun anyway. I just don't follow this post at all.
Next up is a talk on Struts. This is being given by Peter Campbell of Java Enterprise Solutions. He's going to explain Struts from a "what is it" standpoint, which is of great interest to me. VisualWorks now has the Web Toolkit, which is equivalent to ASP/JSP/Servlets. Is Struts something of interest?
Struts is a control layer based on Servlets, EJB, Resource Bundles, XML, and Jakarta Commons. Struts is a variant of MVC for web apps. Uses Servlets and JSP. It's an app framework that you build web apps on top of. Struts is basically the Controller - it relies on other things for the Model and the View. More or less, it wraps the Request and Response objects, and handles communication between the back end (Model) and the Request/Response.
For the model, Struts can talk to EJB, JDBC, some O/R layers. For the view, it's typically JSP (Could be XML, etc). From the front (HTML) end, the struts interface appears as a tag. So the HTML guys will be able to work with it fairly easily. The heart of this appears to be the configuration file, which is an xml file specifying the association of page actions to domain model actions. It specifies allowable page transitions. It does not do transactions; that's presumed to all happen at the model layer. The actual controller is some subclass of ActionServlet, which specifies what we are going to do, and via the configuration file, delegates actual actions (Command Pattern) to the model. The biggest hurdle is trying to share the configuration file - the latest version of struts allows for sub-config files. Another possible limitation - one cannot chain actions in the config file - you specify an entry point.
The model is your application. In this world, it's generally a set of one or more Java Beans. This doesn't imply all EJB's (and in fact, this speaker is arning people off of that). Heh. There's an admission that when you do this, you don't want to allocate objects too quickly, because the JVM won't easily keep up.
I'll say this - the tags you put on the page to deal with data transfer from form to application look really nice. I'm sure this simplifies the front end construction of forms a lot for the HTML guys. Not that it's difficult to do that transition in Smalltalk; here's how I typically grab form data in a VW servlet:
model := BlogUser new. model getInputFrom: request parameters.
getInputFrom: aDictionary aDictionary keysAndValuesDo: [[:key :value | self setAspectFor: key to: value].
setAspectFor: key to: value | selector | selector := (key, ':') asSymbol. (self respondsTo: selector) ifTrue: [[ self perform: selector with: value first].
However, having a standard set of tags for the HTML guys is not to be underestimated. Using JSP 1.1 standard tag libraries and these mappings is likely to allow for very quick mock ups and front end implementations. The way this is set up, it looks like the web toolkit should be able to support struts, given the appropriate back end framework - since we already support JSP style tags and servlets. So what we would need is an equivalent to the ActionServlet and the associated library. The hard part looks to be in the creattion of the XML file - you get examples, and have to customize. Presumably, you use some xml editor to do that.
In the Action class, you implement an execute method. This is where things flare off from. Hmm. What would be fascinating would be a conversation between someone advocating a Struts type approach versus someone advocating a Seaside based approach. Anyway, Struts is pretty small - about 100 classes. I guess we should have a look at this approach.
So here am in northern Baltimore at at a WebSphere seminar hosted by a local company, Noospherics. I actually know the speaker - George Kosmides - from way back. He was a Smalltalk guy back in the day, and is now working with Java. My presence here has already done some good - he's identified Smalltalk as the source of many ofthe ideas behind Java. This is going to be a stream of consciousness kind of report.
Now he's relating J2EE as a natural progression up from JSP and Servlets - i.e., something to simplify and scale the back end. The explanation offered is that the business model belongs in the EJB layer. Side note; I've heard this presentation. Heck, back in 1997 I was giving this presentation as D-Wave (Distributed VisualWave). There's truly nothing new under the sun; we just keep re-inventing the same wheels....
Hmm. Now we have some JDBC, and the fact that we can easily plugin any back end database. Well. One, that depends on the SQL being used. Two, what about O/R mapping? I'm not sure the explanation of JSP as a "refinement" of servlets is a good one; more of a complementary item, I think. Also no warning about the possible unmitigated growth of code on pages being a bad thing - something I learned the hard way in the implementation of this blog...
Now onto JTA - the transaction mapping piece. No mention that the vendors tend to value add this into proprietary heck.... JMS as a mapping on top of messaging services like MQ. Kind of amazing to me just how many of these things Sun has implemented. JMS actually sounds useful - having a standard messaging mapping for Smalltalk would be highly useful.
Now that we have the buzzwords out of the way, he's moving up to the architecture level. Heh. The supposed existence of XML standards between suppliers and vendors. I've got customers who live in the middle of the supply chain; they tell me that more than half the work is writing adaptors between systems, as standards are followed mostly in the breech. Ho ho - J2EE makes it easier to build a standard application architecture. Never mind the analyst reported high failure rates in this - which, I think, is more related to the attempt to build "the one true architecture" than to anything else. I think he over simplifies the "auto-scaling" of J2EE applications. Sure, if the application was written properly. Scaling is almost never a matter of "just" adding a server to the mix.
On to process. I don't take it as a great sign that RUP was on the last slide, and UML is on this one. Sounds heavyweight to me. Here we go - one must do modeling first (and I don't think this sounds like Scott Ambler's agile modeling). Here we have a big emphasis on UML and a process (RUP). We are about to cover the most commonly used diagrams in the UML. I've seen this before - a subset of the developers get so enticed by the diagramming that they never come back out..... So what are the most commonly used?
One of the things I disagree with here is that a design really can't be done withut regard to the implementation. You'll make different choices based on deployment platform (OS), network connectivity, language, database, etc. At the highest level, you can be abstract. Once you start getting to the level of specificity detailed in UML (down to class and sequence diagrams), it makes a difference.
Interesting. As the straw man for analysis and design, he's presenting waterfall as the alternative to be avoided. I'm sure there are still waterfall projects; but is anyone still advocating it? Ok, this sounds better - he's emphasizing testing and spiral development. On the other hand, RUP is what he's sayiing "we've all moved towards in the last five years". That was true from a mindshare standpoint 3 years ago. Is it still true? The supposed ease with which we can add new layers into our component model is being overstressed, IMHO. It almost never actually works out that easily. What about XP and Agile? Ahh - he's saying we need RUP, but we need testing from XP. Hmm. He doesn't seem to know a lot about XP/Agile - for instance, he's implying that test-first is optional. Bottom line, he's sure you need the RUP process.
For those of you wondering after last night's post, this qualifies as early for me. No snickering :)
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 email@example.com 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:
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...